[PATCH v3 3/3] dt-bindings: dw-apb-ictl: support hierarchy irq domain

[Zhen Lei]

Add support to use dw-apb-ictl as primary interrupt controller.

Signed-off-by: Zhen Lei 
---
 .../interrupt-controller/snps,dw-apb-ictl.txt  | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt 
b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
index 086ff08322db..2db59df9408f 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
@@ -2,7 +2,8 @@ Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
 
 Synopsys DesignWare provides interrupt controller IP for APB known as
 dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs with
-APB bus, e.g. Marvell Armada 1500.
+APB bus, e.g. Marvell Armada 1500. It can also be used as primary interrupt
+controller in some SoCs, e.g. Hisilicon SD5203.
 
 Required properties:
 - compatible: shall be "snps,dw-apb-ictl"
@@ -10,6 +11,8 @@ Required properties:
   region starting with ENABLE_LOW register
 - interrupt-controller: identifies the node as an interrupt controller
 - #interrupt-cells: number of cells to encode an interrupt-specifier, shall be 
1
+
+Additional required property when it's used as secondary interrupt controller:
 - interrupts: interrupt reference to primary interrupt controller
 
 The interrupt sources map to the corresponding bits in the interrupt
@@ -21,6 +24,7 @@ registers, i.e.
 - (optional) fast interrupts start at 64.
 
 Example:
+   /* dw_apb_ictl is used as secondary interrupt controller */
aic: interrupt-controller@3000 {
compatible = "snps,dw-apb-ictl";
reg = <0x3000 0xc00>;
@@ -29,3 +33,11 @@ Example:
interrupt-parent = <&gic>;
interrupts = ;
};
+
+   /* dw_apb_ictl is used as primary interrupt controller */
+   vic: interrupt-controller@1013 {
+   compatible = "snps,dw-apb-ictl";
+   reg = <0x1013 0x1000>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   };
-- 
2.26.0.106.g9fadedd

[PATCH v3 2/3] irqchip: dw-apb-ictl: support hierarchy irq domain

[Zhen Lei]

Add support to use dw-apb-ictl as primary interrupt controller.

Suggested-by: Marc Zyngier 
Signed-off-by: Zhen Lei 
Tested-by: Haoyu Lv 
---
 drivers/irqchip/Kconfig   |  2 +-
 drivers/irqchip/irq-dw-apb-ictl.c | 76 +++
 2 files changed, 69 insertions(+), 9 deletions(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index bfc9719dbcdc..7c2d1c8fa551 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -148,7 +148,7 @@ config DAVINCI_CP_INTC
 config DW_APB_ICTL
bool
select GENERIC_IRQ_CHIP
-   select IRQ_DOMAIN
+   select IRQ_DOMAIN_HIERARCHY
 
 config FARADAY_FTINTC010
bool
diff --git a/drivers/irqchip/irq-dw-apb-ictl.c 
b/drivers/irqchip/irq-dw-apb-ictl.c
index 5458004242e9..3c7bebe1b947 100644
--- a/drivers/irqchip/irq-dw-apb-ictl.c
+++ b/drivers/irqchip/irq-dw-apb-ictl.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define APB_INT_ENABLE_L   0x00
 #define APB_INT_ENABLE_H   0x04
@@ -26,6 +27,27 @@
 #define APB_INT_FINALSTATUS_H  0x34
 #define APB_INT_BASE_OFFSET0x04
 
+/* irq domain of the primary interrupt controller. */
+static struct irq_domain *dw_apb_ictl_irq_domain;
+
+static void __irq_entry dw_apb_ictl_handle_irq(struct pt_regs *regs)
+{
+   struct irq_domain *d = dw_apb_ictl_irq_domain;
+   int n;
+
+   for (n = 0; n < d->revmap_size; n += 32) {
+   struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, n);
+   u32 stat = readl_relaxed(gc->reg_base + APB_INT_FINALSTATUS_L);
+
+   while (stat) {
+   u32 hwirq = ffs(stat) - 1;
+
+   handle_domain_irq(d, hwirq, regs);
+   stat &= ~BIT(hwirq);
+   }
+   }
+}
+
 static void dw_apb_ictl_handle_irq_cascaded(struct irq_desc *desc)
 {
struct irq_domain *d = irq_desc_get_handler_data(desc);
@@ -50,6 +72,30 @@ static void dw_apb_ictl_handle_irq_cascaded(struct irq_desc 
*desc)
chained_irq_exit(chip, desc);
 }
 
+static int dw_apb_ictl_irq_domain_alloc(struct irq_domain *domain, unsigned 
int virq,
+   unsigned int nr_irqs, void *arg)
+{
+   int i, ret;
+   irq_hw_number_t hwirq;
+   unsigned int type = IRQ_TYPE_NONE;
+   struct irq_fwspec *fwspec = arg;
+
+   ret = irq_domain_translate_onecell(domain, fwspec, &hwirq, &type);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < nr_irqs; i++)
+   irq_map_generic_chip(domain, virq + i, hwirq + i);
+
+   return 0;
+}
+
+static const struct irq_domain_ops dw_apb_ictl_irq_domain_ops = {
+   .translate = irq_domain_translate_onecell,
+   .alloc = dw_apb_ictl_irq_domain_alloc,
+   .free = irq_domain_free_irqs_top,
+};
+
 #ifdef CONFIG_PM
 static void dw_apb_ictl_resume(struct irq_data *d)
 {
@@ -75,13 +121,20 @@ static int __init dw_apb_ictl_init(struct device_node *np,
void __iomem *iobase;
int ret, nrirqs, parent_irq, i;
u32 reg;
-   const struct irq_domain_ops *domain_ops = &irq_generic_chip_ops;
-
-   /* Map the parent interrupt for the chained handler */
-   parent_irq = irq_of_parse_and_map(np, 0);
-   if (parent_irq <= 0) {
-   pr_err("%pOF: unable to parse irq\n", np);
-   return -EINVAL;
+   const struct irq_domain_ops *domain_ops;
+
+   if (!parent || (np == parent)) {
+   /* It's used as the primary interrupt controller */
+   parent_irq = 0;
+   domain_ops = &dw_apb_ictl_irq_domain_ops;
+   } else {
+   /* Map the parent interrupt for the chained handler */
+   parent_irq = irq_of_parse_and_map(np, 0);
+   if (parent_irq <= 0) {
+   pr_err("%pOF: unable to parse irq\n", np);
+   return -EINVAL;
+   }
+   domain_ops = &irq_generic_chip_ops;
}
 
ret = of_address_to_resource(np, 0, &r);
@@ -144,10 +197,17 @@ static int __init dw_apb_ictl_init(struct device_node *np,
gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
gc->chip_types[0].chip.irq_unmask = irq_gc_mask_clr_bit;
gc->chip_types[0].chip.irq_resume = dw_apb_ictl_resume;
+   if (!parent_irq)
+   gc->chip_types[0].chip.irq_eoi = irq_gc_noop;
}
 
-   irq_set_chained_handler_and_data(parent_irq,
+   if (parent_irq) {
+   irq_set_chained_handler_and_data(parent_irq,
dw_apb_ictl_handle_irq_cascaded, domain);
+   } else {
+   dw_apb_ictl_irq_domain = domain;
+   set_handle_irq(dw_apb_ictl_handle_irq);
+   }
 
return 0;
 
-- 
2.26.0.106.g9fadedd

[PATCH v3 0/3] irqchip: dw-apb-ictl: support hierarchy irq domain

[Zhen Lei]

v2 --> v3:
1. change (1 << hwirq) to BIT(hwirq).
2. change __exception_irq_entry to __irq_entry, so we can "#include 
"
   instead of "#include ". Ohterwise, an compilation error 
will be
   reported on arch/csky.
   drivers/irqchip/irq-dw-apb-ictl.c:20:10: fatal error: asm/exception.h: No 
such file or directory
3. use "if (!parent || (np == parent))" to determine whether it is primary 
interrupt controller.
4. make the primary interrupt controller case also use function 
handle_level_irq(), I used 
   handle_fasteoi_irq() as flow_handler before.
5. Other minor changes are not detailed.

v1 --> v2:
According to Marc Zyngier's suggestion, discard adding an independent SD5203-VIC
driver, but make the dw-apb-ictl irqchip driver to support hierarchy irq domain.
It was originally available only for secondary interrupt controller, now it can
also be used as primary interrupt controller. The related dt-bindings is updated
appropriately.

Add "Suggested-by: Marc Zyngier ".
Add "Tested-by: Haoyu Lv ".


v1:
The interrupt controller of SD5203 SoC is VIC(vector interrupt controller), it's
based on Synopsys DesignWare APB interrupt controller (dw_apb_ictl) IP, but it
can not directly use dw_apb_ictl driver. The main reason is that VIC is used as
primary interrupt controller and dw_apb_ictl driver worked for secondary
interrupt controller. So add a new driver: "hisilicon,sd5203-vic".

Zhen Lei (3):
  irqchip: dw-apb-ictl: prepare for support hierarchy irq domain
  irqchip: dw-apb-ictl: support hierarchy irq domain
  dt-bindings: dw-apb-ictl: support hierarchy irq domain

 .../interrupt-controller/snps,dw-apb-ictl.txt | 14 ++-
 drivers/irqchip/Kconfig   |  2 +-
 drivers/irqchip/irq-dw-apb-ictl.c | 85 ---
 3 files changed, 87 insertions(+), 14 deletions(-)

-- 
2.26.0.106.g9fadedd

Re: [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support

[Sam McNally]

On Wed, 2 Sep 2020 at 04:12, Lyude Paul  wrote:
>
> Super minor nitpicks:
>
> On Tue, 2020-09-01 at 16:22 +1000, Sam McNally wrote:
> > From: Hans Verkuil 
> >
> > Signed-off-by: Hans Verkuil 
> > [sa...@chromium.org:
> >  - rebased
> >  - removed polling-related changes
> >  - moved the calls to drm_dp_cec_(un)set_edid() into the next patch
> > ]
> > Signed-off-by: Sam McNally 
> > ---
> >
> >  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  2 +-
> >  drivers/gpu/drm/drm_dp_cec.c  | 22 ++-
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
> >  drivers/gpu/drm/nouveau/nouveau_connector.c   |  2 +-
> >  include/drm/drm_dp_helper.h   |  6 +++--
> >  5 files changed, 19 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > index 461fa4da0a34..6e7075893ec9 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > @@ -419,7 +419,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> > amdgpu_display_manager *dm,
> >
> >   drm_dp_aux_init(&aconnector->dm_dp_aux.aux);
> >   drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
> > -   &aconnector->base);
> > +   &aconnector->base, false);
> >
> >   if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
> >   return;
> > diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> > index 3ab2609f9ec7..04ab7b88055c 100644
> > --- a/drivers/gpu/drm/drm_dp_cec.c
> > +++ b/drivers/gpu/drm/drm_dp_cec.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  /*
> >   * Unfortunately it turns out that we have a chicken-and-egg situation
> > @@ -338,8 +339,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> > struct edid *edid)
> >   if (aux->cec.adap) {
> >   if (aux->cec.adap->capabilities == cec_caps &&
> >   aux->cec.adap->available_log_addrs == num_las) {
> > - /* Unchanged, so just set the phys addr */
> > - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> >   goto unlock;
> >   }
>
> May as well drop the braces here
>
> >   /*
> > @@ -364,15 +363,16 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> > struct edid *edid)
> >   if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
> >   cec_delete_adapter(aux->cec.adap);
> >   aux->cec.adap = NULL;
> > - } else {
> > - /*
> > -  * Update the phys addr for the new CEC adapter. When called
> > -  * from drm_dp_cec_register_connector() edid == NULL, so in
> > -  * that case the phys addr is just invalidated.
> > -  */
> > - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> >   }
> >  unlock:
> > + /*
> > +  * Update the phys addr for the new CEC adapter. When called
> > +  * from drm_dp_cec_register_connector() edid == NULL, so in
> > +  * that case the phys addr is just invalidated.
> > +  */
> > + if (aux->cec.adap && edid) {
> > + cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> > + }
>
> And here
>
> >   mutex_unlock(&aux->cec.lock);
> >  }
> >  EXPORT_SYMBOL(drm_dp_cec_set_edid);
> > @@ -418,6 +418,7 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> >   * drm_dp_cec_register_connector() - register a new connector
> >   * @aux: DisplayPort AUX channel
> >   * @connector: drm connector
> > + * @is_mst: set to true if this is an MST branch
> >   *
> >   * A new connector was registered with associated CEC adapter name and
> >   * CEC adapter parent device. After registering the name and parent
> > @@ -425,12 +426,13 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> >   * CEC and to register a CEC adapter if that is the case.
> >   */
> >  void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> > -struct drm_connector *connector)
> > +struct drm_connector *connector, bool 
> > is_mst)
> >  {
> >   WARN_ON(aux->cec.adap);
> >   if (WARN_ON(!aux->transfer))
> >   return;
> >   aux->cec.connector = connector;
> > + aux->cec.is_mst = is_mst;
>
> Also JFYI, you can also check aux->is_remote, but maybe you've got another
> reason for copying this here
>

I think this was just an artefact of this patch originally being
written before aux->is_remote was added. Switching to it mostly
removes the need for this patch, and leaving drm_dp_cec_set_edid()
unchanged, as Hans suggests, removes the rest.

> Either way:
>
> Reviewed-by: Lyude Paul 
>
> ...Also, maybe this is just a coincidence - but do I know your name from
> somewhere? Perhaps

[PATCH v3 1/3] irqchip: dw-apb-ictl: prepare for support hierarchy irq domain

[Zhen Lei]

Rename some functions and variables in advance, to make the next patch
looks more clear. The details are as follows:
1. rename dw_apb_ictl_handler() to dw_apb_ictl_handle_irq_cascaded().
2. change (1 << hwirq) to BIT(hwirq).

In function dw_apb_ictl_init():
1. rename local variable irq to parent_irq.
2. add "const struct irq_domain_ops *domain_ops = &irq_generic_chip_ops",
   then replace &irq_generic_chip_ops in other places with domain_ops.

No functional change.

Signed-off-by: Zhen Lei 
Tested-by: Haoyu Lv 
---
 drivers/irqchip/irq-dw-apb-ictl.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/irqchip/irq-dw-apb-ictl.c 
b/drivers/irqchip/irq-dw-apb-ictl.c
index e4550e9c810b..5458004242e9 100644
--- a/drivers/irqchip/irq-dw-apb-ictl.c
+++ b/drivers/irqchip/irq-dw-apb-ictl.c
@@ -26,7 +26,7 @@
 #define APB_INT_FINALSTATUS_H  0x34
 #define APB_INT_BASE_OFFSET0x04
 
-static void dw_apb_ictl_handler(struct irq_desc *desc)
+static void dw_apb_ictl_handle_irq_cascaded(struct irq_desc *desc)
 {
struct irq_domain *d = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
@@ -43,7 +43,7 @@ static void dw_apb_ictl_handler(struct irq_desc *desc)
u32 virq = irq_find_mapping(d, gc->irq_base + hwirq);
 
generic_handle_irq(virq);
-   stat &= ~(1 << hwirq);
+   stat &= ~BIT(hwirq);
}
}
 
@@ -73,12 +73,13 @@ static int __init dw_apb_ictl_init(struct device_node *np,
struct irq_domain *domain;
struct irq_chip_generic *gc;
void __iomem *iobase;
-   int ret, nrirqs, irq, i;
+   int ret, nrirqs, parent_irq, i;
u32 reg;
+   const struct irq_domain_ops *domain_ops = &irq_generic_chip_ops;
 
/* Map the parent interrupt for the chained handler */
-   irq = irq_of_parse_and_map(np, 0);
-   if (irq <= 0) {
+   parent_irq = irq_of_parse_and_map(np, 0);
+   if (parent_irq <= 0) {
pr_err("%pOF: unable to parse irq\n", np);
return -EINVAL;
}
@@ -120,8 +121,7 @@ static int __init dw_apb_ictl_init(struct device_node *np,
else
nrirqs = fls(readl_relaxed(iobase + APB_INT_ENABLE_L));
 
-   domain = irq_domain_add_linear(np, nrirqs,
-  &irq_generic_chip_ops, NULL);
+   domain = irq_domain_add_linear(np, nrirqs, domain_ops, NULL);
if (!domain) {
pr_err("%pOF: unable to add irq domain\n", np);
ret = -ENOMEM;
@@ -146,7 +146,8 @@ static int __init dw_apb_ictl_init(struct device_node *np,
gc->chip_types[0].chip.irq_resume = dw_apb_ictl_resume;
}
 
-   irq_set_chained_handler_and_data(irq, dw_apb_ictl_handler, domain);
+   irq_set_chained_handler_and_data(parent_irq,
+   dw_apb_ictl_handle_irq_cascaded, domain);
 
return 0;
 
-- 
2.26.0.106.g9fadedd

Re: [PATCH 02/19] amiflop: use bdev_check_media_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> The Amiga floppy driver does not have a ->revalidate_disk method, so it
> can just use bdev_check_media_change without any additional changes.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/block/amiflop.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/block/amiflop.c b/drivers/block/amiflop.c
> index 226219da3da6a7..71c2b156455860 100644
> --- a/drivers/block/amiflop.c
> +++ b/drivers/block/amiflop.c
> @@ -1670,7 +1670,7 @@ static int floppy_open(struct block_device *bdev, 
> fmode_t mode)
>   }
>  
>   if (mode & (FMODE_READ|FMODE_WRITE)) {
> - check_disk_change(bdev);
> + bdev_check_media_change(bdev);
>   if (mode & FMODE_WRITE) {
>   int wrprot;
>  
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH 04/19] floppy: use bdev_check_media_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Switch to use bdev_check_media_change instead of check_disk_change and
> call floppy_revalidate manually.  Given that floppy_revalidate only
> deals with media change events, the extra call into ->revalidate_disk
> from bdev_disk_changed is not required either, so stop wiring up the
> method.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/block/floppy.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH 05/19] swim: use bdev_check_media_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Switch to use bdev_check_media_change instead of check_disk_change and
> call floppy_revalidate manually.  Given that floppy_revalidate only
> deals with media change events, the extra call into ->revalidate_disk
> from bdev_disk_changed is not required either, so stop wiring up the
> method.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/block/swim.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: Question: Why is there no notification when a file is opened using filp_open()?

[Xiaoming Ni]

On 2020/9/9 11:44, Amir Goldstein wrote:

On Tue, Sep 8, 2020 at 8:19 PM Matthew Wilcox  wrote:


On Tue, Sep 08, 2020 at 04:18:29PM +0300, Amir Goldstein wrote:

On Tue, Sep 8, 2020 at 3:53 PM Xiaoming Ni  wrote:

For example, in fs/coredump.c, do_coredump() calls filp_open() to
generate core files.
In this scenario, the fsnotify_open() notification is missing.


I am not convinced that we should generate an event.
You will have to explain in what is the real world use case that requires this
event to be generated.


Take the typical usage for fsnotify of a graphical file manager.
It would be nice if the file manager showed a corefile as soon as it
appeared in a directory rather than waiting until some other operation
in that directory caused those directory contents to be refreshed.


fsnotify_open() is not the correct notification for file managers IMO.
fsnotify_create() is and it will be called in this case.

If the reason you are interested in open events is because you want
to monitor the entire filesystem then welcome to the future -
FAN_CREATE is supported since kernel v5.1.

Is there another real life case you have in mind where you think users
should be able to get an open fd for a file that the kernel has opened?
Because that is what FAN_OPEN will do.



There are also cases where file is opened in read-only mode using 
filp_open().


case1: nfsd4_init_recdir() call filp_open()
filp_open()
nfsd4_init_recdir() fs/nfsd/nfs4recover.c#L543

L70: static char user_recovery_dirname[PATH_MAX] = 
"/var/lib/nfs/v4recovery";
L543: nn->rec_file = filp_open(user_recovery_dirname, O_RDONLY | 
O_DIRECTORY, 0);



case2: ima_read_policy()
filp_open()
kernel_read_file_from_path()  fs/exec.c#L1004
ima_read_policy()  security/integrity/ima/ima_fs.c#L286
ima_write_policy() security/integrity/ima/ima_fs.c#L335
ima_measure_policy_ops   security/integrity/ima/ima_fs.c#L443
sys_write()

case3: use do_file_open_root() to open file
do_file_open_root()
file_open_root()   fs/open.c#L1159
kernel_read_file_from_path_initns()  fs/exec.c#L1029
fw_get_filesystem_firmware()  drivers/base/firmware_loader/main.c#L498

Do we need to add fsnotify_open() in these scenarios?

Thanks
Xiaoming Ni

RCU: Question rcu_preempt_blocked_readers_cgp in rcu_gp_fqs_loop func

[Zhang, Qiang]

When config preempt RCU,  and then  there are multiple levels  node,  the 
current task is preempted  in rcu  read critical region.
the current task be add to "rnp->blkd_tasks" link list,  and the 
"rnp->gp_tasks"  may be assigned a value .  these rnp is leaf node in RCU tree.

But in "rcu_gp_fqs_loop" func, we check blocked readers in root node. 

static void rcu_gp_fqs_loop(void)
 {
.
struct rcu_node *rnp = rcu_get_root();
.
if (!READ_ONCE(rnp->qsmask) &&
   !rcu_preempt_blocked_readers_cgp(rnp))
--> rnp is root node
 break;

}

the root node's blkd_tasks never add task, the "rnp->gp_tasks" is never be 
assigned value,  this check is invailed.
 Should we check leaf nodes like this 

--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1846,6 +1846,25 @@ static bool rcu_gp_init(void)
return true;
 }
 
+static bool rcu_preempt_blocked_readers(void)
+{
+   struct rcu_node *rnp;
+   unsigned long flags;
+   bool ret = false;
+
+   rcu_for_each_leaf_node(rnp) {
+   raw_spin_lock_irqsave_rcu_node(rnp, flags);
+   if (rcu_preempt_blocked_readers_cgp(rnp)) {
+   ret = true;
+   raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
+   break;
+   }
+   raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
+   }
+
+   return ret;
+}
+
 /*
  * Helper function for swait_event_idle_exclusive() wakeup at 
force-quiescent-state
  * time.
@@ -1864,7 +1883,7 @@ static bool rcu_gp_fqs_check_wake(int *gfp)
return true;
 
// The current grace period has completed.
-   if (!READ_ONCE(rnp->qsmask) && !rcu_preempt_blocked_readers_cgp(rnp))
+   if (!READ_ONCE(rnp->qsmask) && !rcu_preempt_blocked_readers())
return true;
 
return false;
@@ -1927,7 +1946,7 @@ static void rcu_gp_fqs_loop(void)
/* Locking provides needed memory barriers. */
/* If grace period done, leave loop. */
if (!READ_ONCE(rnp->qsmask) &&
-   !rcu_preempt_blocked_readers_cgp(rnp))
+   !rcu_preempt_blocked_readers())
break;
/* If time for quiescent-state forcing, do it. */
if (!time_after(rcu_state.jiffies_force_qs, jiffies) ||
-- 


thanks
Qiang

Re: [PATCH v1] driver core: Annotate dev_err_probe() with __must_check

[Greg Kroah-Hartman]

On Wed, Sep 09, 2020 at 08:29:25AM +0200, Krzysztof Kozlowski wrote:
> On Wed, 26 Aug 2020 at 18:18, Joe Perches  wrote:
> >
> > On Wed, 2020-08-26 at 18:55 +0300, Andy Shevchenko wrote:
> > > On Wed, Aug 26, 2020 at 08:44:30AM -0700, Joe Perches wrote:
> > > > On Wed, 2020-08-26 at 13:44 +0300, Andy Shevchenko wrote:
> > >
> > > ...
> > >
> > > > > -int dev_err_probe(const struct device *dev, int err, const char 
> > > > > *fmt, ...);
> > > > > +int __must_check dev_err_probe(const struct device *dev, int err, 
> > > > > const char *fmt, ...);
> 
> +Cc Stephen and Greg,
> 
> Hi Andy,
> 
> Did this patch ended up in next somehow? I am surprised because now I
> got warnings for perfectly fine code:
> https://lore.kernel.org/linux-next/20200909155654.76fe3...@canb.auug.org.au/T/#u
> 
> This creates simply false warnings instead of hints for "optimization".

Yes, it got merged into m y driver core tree.

I'll fix up the tty build warning, should be easy enough, the patch is
below.

thanks,

greg k-h
--

diff --git a/drivers/tty/serial/8250/8250_bcm2835aux.c 
b/drivers/tty/serial/8250/8250_bcm2835aux.c
index fd95860cd661..cd1880715bad 100644
--- a/drivers/tty/serial/8250/8250_bcm2835aux.c
+++ b/drivers/tty/serial/8250/8250_bcm2835aux.c
@@ -151,7 +151,7 @@ static int bcm2835aux_serial_probe(struct platform_device 
*pdev)
/* register the port */
ret = serial8250_register_8250_port(&up);
if (ret < 0) {
-   dev_err_probe(&pdev->dev, ret, "unable to register 8250 
port\n");
+   ret = dev_err_probe(&pdev->dev, ret, "unable to register 8250 
port\n");
goto dis_clk;
}
data->line = ret;

Re: [PATCHv3] soc: qcom: llcc: Support chipsets that can write to llcc registers

[Sai Prakash Ranjan]

Hi,

On 2020-09-09 00:02, Stephen Boyd wrote:

Quoting Sai Prakash Ranjan (2020-09-07 22:36:48)

From: "Isaac J. Manjarres" 

Older chipsets may not be allowed to configure certain LLCC registers
as that is handled by the secure side software. However, this is not
the case for newer chipsets and they must configure these registers
according to the contents of the SCT table, while keeping in mind that
older targets may not have these capabilities. So add support to allow
such configuration of registers to enable capacity based allocation
and power collapse retention for capable chipsets.

Reason for choosing capacity based allocation rather than the default
way based allocation is because capacity based allocation allows more
finer grain partition and provides more flexibility in configuration.
As for the retention through power collapse, it has an advantage where
the cache hits are more when we wake up from power collapse although
it does burn more power but the exact power numbers are not known at
the moment.

Signed-off-by: Isaac J. Manjarres 
(sai: use existing config instead of dt property and commit msg 
change)


Should be the following format:

[saiprakash.ran...@codeaurora.org: use existing...]



Hmm, is this documented somewhere because a quick grep shows
quite a few places where just the first name is added. Plus
there is already a signed-off-by line below this, so we know
that it is this 'sai' who made the extra changes.


Signed-off-by: Sai Prakash Ranjan 
---
diff --git a/drivers/soc/qcom/llcc-qcom.c 
b/drivers/soc/qcom/llcc-qcom.c

index 429b5a60a1ba..b908656ce519 100644
--- a/drivers/soc/qcom/llcc-qcom.c
+++ b/drivers/soc/qcom/llcc-qcom.c
@@ -45,6 +45,9 @@
 #define LLCC_TRP_ATTR0_CFGn(n)(0x21000 + SZ_8 * n)
 #define LLCC_TRP_ATTR1_CFGn(n)(0x21004 + SZ_8 * n)

+#define LLCC_TRP_SCID_DIS_CAP_ALLOC   0x21F00
+#define LLCC_TRP_PCB_ACT  0x21F04


Use lowercase hex please. LLCC_COMMON_STATUS0 is using lowercase.



Ok


+
 #define BANK_OFFSET_STRIDE   0x8

 /**
@@ -89,6 +92,7 @@ struct llcc_slice_config {
 struct qcom_llcc_config {
const struct llcc_slice_config *sct_data;
int size;
+   bool need_llcc_cfg;
 };

 static const struct llcc_slice_config sc7180_data[] =  {
@@ -122,11 +126,13 @@ static const struct llcc_slice_config 
sdm845_data[] =  {

 static const struct qcom_llcc_config sc7180_cfg = {
.sct_data   = sc7180_data,
.size   = ARRAY_SIZE(sc7180_data),
+   .need_llcc_cfg  = true,
 };

 static const struct qcom_llcc_config sdm845_cfg = {
.sct_data   = sdm845_data,
.size   = ARRAY_SIZE(sdm845_data),
+   .need_llcc_cfg  = false,


false is the default so just leave it out?



Done on purpose as I wanted to be explicit here so that
anyone reading it knows that it doesn't support configuring
in kernel. Yes the default is false but it won't hurt to be
explicit here to avoid confusion.


 };

 static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;
@@ -327,6 +333,7 @@ static int qcom_llcc_cfg_program(struct 
platform_device *pdev)

u32 attr0_val;
u32 max_cap_cacheline;
u32 sz;
+   u32 disable_cap_alloc, retain_pc;
int ret = 0;
const struct llcc_slice_config *llcc_table;
struct llcc_slice_desc desc;
@@ -369,6 +376,21 @@ static int qcom_llcc_cfg_program(struct 
platform_device *pdev)

attr0_val);
if (ret)
return ret;
+
+   if (drv_data->need_llcc_config) {
+   disable_cap_alloc = 
llcc_table[i].dis_cap_alloc << llcc_table[i].slice_id;


Can we move u32 disable_cap_alloc, retain_pc here? That would keep it
local to this if condition. Or make llc_table[i].slice_id into a local
variable so the shift line isn't so long? Or make the body of this 
while

loop a new function that takes an llcc_table[i] pointer so that lines
are easier to read?



The whole function qcom_llcc_cfg_program() is just a loop so
adding another function moving that loop wouldn't look good.
llc_table[i].slice_id is already used elsewhere in this function
and changing everywhere is not related to this patch. So I will
go with your suggestion to move disable_cap_alloc and retain_pc
to if block.

Thanks for the review.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 03/19] ataflop: use bdev_check_media_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Switch to use bdev_check_media_change instead of check_disk_change and
> call floppy_revalidate manually.  Given that floppy_revalidate only
> deals with media change events, the extra call into ->revalidate_disk
> from bdev_disk_changed is not required either, so stop wiring up the
> method.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/block/ataflop.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support

[Sam McNally]

On Tue, 8 Sep 2020 at 18:41, Hans Verkuil  wrote:
>
> On 01/09/2020 08:22, Sam McNally wrote:
> > From: Hans Verkuil 
> >
> > Signed-off-by: Hans Verkuil 
> > [sa...@chromium.org:
> >  - rebased
> >  - removed polling-related changes
> >  - moved the calls to drm_dp_cec_(un)set_edid() into the next patch
> > ]
> > Signed-off-by: Sam McNally 
> > ---
> >
> >  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  2 +-
> >  drivers/gpu/drm/drm_dp_cec.c  | 22 ++-
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
> >  drivers/gpu/drm/nouveau/nouveau_connector.c   |  2 +-
> >  include/drm/drm_dp_helper.h   |  6 +++--
> >  5 files changed, 19 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > index 461fa4da0a34..6e7075893ec9 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > @@ -419,7 +419,7 @@ void amdgpu_dm_initialize_dp_connector(struct 
> > amdgpu_display_manager *dm,
> >
> >   drm_dp_aux_init(&aconnector->dm_dp_aux.aux);
> >   drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
> > -   &aconnector->base);
> > +   &aconnector->base, false);
> >
> >   if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
> >   return;
> > diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> > index 3ab2609f9ec7..04ab7b88055c 100644
> > --- a/drivers/gpu/drm/drm_dp_cec.c
> > +++ b/drivers/gpu/drm/drm_dp_cec.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  /*
> >   * Unfortunately it turns out that we have a chicken-and-egg situation
> > @@ -338,8 +339,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
> > struct edid *edid)
> >   if (aux->cec.adap) {
> >   if (aux->cec.adap->capabilities == cec_caps &&
> >   aux->cec.adap->available_log_addrs == num_las) {
> > - /* Unchanged, so just set the phys addr */
> > - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> >   goto unlock;
> >   }
> >   /*
> > @@ -364,15 +363,16 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, 
> > const struct edid *edid)
> >   if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
> >   cec_delete_adapter(aux->cec.adap);
> >   aux->cec.adap = NULL;
> > - } else {
> > - /*
> > -  * Update the phys addr for the new CEC adapter. When called
> > -  * from drm_dp_cec_register_connector() edid == NULL, so in
> > -  * that case the phys addr is just invalidated.
> > -  */
> > - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> >   }
> >  unlock:
> > + /*
> > +  * Update the phys addr for the new CEC adapter. When called
> > +  * from drm_dp_cec_register_connector() edid == NULL, so in
> > +  * that case the phys addr is just invalidated.
> > +  */
>
> The comment is no longer in sync with the code: if EDID == NULL, then
> nothing is done due to the edid check in the 'if' below.
>
> > + if (aux->cec.adap && edid) {
>
> I think this should just be: if (aux->cec.adap)
>
> Also, the {} aren't necessary here.
>
> > + cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> > + }
> >   mutex_unlock(&aux->cec.lock);
> >  }
> >  EXPORT_SYMBOL(drm_dp_cec_set_edid);
>
> Frankly, the changes to this function should be dropped completely, from
> what I can see they are not necessary. It was done in my original patch
> because of the way I handled mst, but you did it differently (and I think
> better), so these changes are no longer needed.
>
> I know I am actually commenting on my old patch, but that patch was from a
> work-in-progress git branch and was never meant as a 'proper' patch.
>
> However, what complicates matters is that after digging a bit more I 
> discovered
> that commit 732300154980 ("drm: Do not call drm_dp_cec_set_edid() while 
> registering
> DP connectors") changed drm_dp_cec_register_connector() so that it no longer
> calls drm_dp_cec_set_edid(), but the comments there and in this function were
> not updated. It would be nice if you can add a patch fixing these outdated
> comments.
>
> Regardless of that change in commit 732300154980, the edid pointer can still 
> be
> NULL and the existing behavior should be kept (i.e. create a CEC device, but 
> with
> an invalid physical address since there is no EDID for some reason).
>
> Regards,
>
> Hans
>

Thanks. Leaving drm_dp_cec_set_edid() unchanged combined with Lyude's
suggestion to use aux->is_remote removes the need for this patch
entirely.

> > @@ -418,6 +418,7 @@ EXPORT_SYMB

Re: [PATCH 01/19] block: add a bdev_check_media_change helper

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Like check_disk_changed, except that it does not call ->revalidate_disk
> but leaves that to the caller.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  block/genhd.c | 29 -
>  fs/block_dev.c| 17 +++--
>  include/linux/genhd.h |  2 +-
>  3 files changed, 32 insertions(+), 16 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [RFC PATCH 00/16] 1GB THP support on x86_64

[Michal Hocko]

On Tue 08-09-20 10:41:10, Rik van Riel wrote:
> On Tue, 2020-09-08 at 16:35 +0200, Michal Hocko wrote:
> 
> > A global knob is insufficient. 1G pages will become a very precious
> > resource as it requires a pre-allocation (reservation). So it really
> > has
> > to be an opt-in and the question is whether there is also some sort
> > of
> > access control needed.
> 
> The 1GB pages do not require that much in the way of
> pre-allocation. The memory can be obtained through CMA,
> which means it can be used for movable 4kB and 2MB
> allocations when not
> being used for 1GB pages.

That CMA has to be pre-reserved, right? That requires a configuration.

> That makes it relatively easy to set aside
> some fraction
> of system memory in every system for 1GB and movable
> allocations, and use it for whatever way it is needed
> depending on what workload(s) end up running on a system.

I was not talking about how easy or hard it is. My main concern is that
this is effectively a pre-reserved pool and a global knob is a very
suboptimal way to control access to it. I (rather) strongly believe this
should be an explicit opt-in and ideally not 1GB specific but rather
something to allow large pages to be created as there is a fit. See
other subthread for more details.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH V2 2/5] iommu: Add iommu_dma_free_cpu_cached_iovas function

[Christoph Hellwig]

> +static inline void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
> +  struct iommu_domain
> *domain)

This adds a crazy long line.  Which is rather pointless as other
bits of code in the patch use the more compact two tab indentations
for the prototype continuation lines anyway.

Re: [PATCH V2 5/5] DO NOT MERGE: iommu: disable list appending in dma-iommu

[Christoph Hellwig]

On Wed, Sep 09, 2020 at 09:43:09AM +0800, Lu Baolu wrote:
> +   /*
> +* The Intel graphic device driver is used to assume that the
> returned
> +* sg list is not combound. This blocks the efforts of converting
> the

This adds pointless overly long lines.

> +* Intel IOMMU driver to dma-iommu api's. Add this quirk to make the
> +* device driver work and should be removed once it's fixed in i915
> +* driver.
> +*/
> +   if (dev_is_pci(dev) &&
> +   to_pci_dev(dev)->vendor == PCI_VENDOR_ID_INTEL &&
> +   (to_pci_dev(dev)->class >> 16) == PCI_BASE_CLASS_DISPLAY) {
> +   for_each_sg(sg, s, nents, i) {
> +   unsigned int s_iova_off = sg_dma_address(s);
> +   unsigned int s_length = sg_dma_len(s);
> +   unsigned int s_iova_len = s->length;
> +
> +   s->offset += s_iova_off;
> +   s->length = s_length;
> +   sg_dma_address(s) = dma_addr + s_iova_off;
> +   sg_dma_len(s) = s_length;
> +   dma_addr += s_iova_len;
> +   }
> +
> +   return nents;
> +   }

This wants an IS_ENABLED() check.  And probably a pr_once reminding
of the workaround.

Re: [PATCHv3] soc: qcom: llcc: Support chipsets that can write to llcc registers

[Sai Prakash Ranjan]

Hi,

On 2020-09-08 20:30, Doug Anderson wrote:

Hi,

On Mon, Sep 7, 2020 at 10:36 PM Sai Prakash Ranjan
 wrote:


--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -73,6 +73,7 @@ struct llcc_edac_reg_data {
  * @bitmap: Bit map to track the active slice ids
  * @offsets: Pointer to the bank offsets array
  * @ecc_irq: interrupt for llcc cache error detection and reporting
+ * @need_llcc_config: check if llcc configuration is required
  */
 struct llcc_drv_data {
struct regmap *regmap;
@@ -85,6 +86,7 @@ struct llcc_drv_data {
unsigned long *bitmap;
u32 *offsets;
int ecc_irq;
+   bool need_llcc_config;


Do you really need to add this into "struct llcc_drv_data"?  You use
it once at probe time and you could just pass it in to
qcom_llcc_cfg_program(), or just pass the "struct qcom_llcc_config" to
qcom_llcc_cfg_program()?  It's not a huge deal, but it would make your
patch simpler and keep an extra element out of the include file.



I just kept it following how other properties were passed to
qcom_llcc_cfg_program(), but yes its better to just pass
qcom_llcc_config to qcom_llcc_cfg_program() so that any future
additions also can use it, will change it in the next version.


In any case:

Reviewed-by: Douglas Anderson 


Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v1] driver core: Annotate dev_err_probe() with __must_check

[Krzysztof Kozlowski]

On Wed, 9 Sep 2020 at 09:02, Greg Kroah-Hartman
 wrote:
>
> On Wed, Sep 09, 2020 at 08:29:25AM +0200, Krzysztof Kozlowski wrote:
> > On Wed, 26 Aug 2020 at 18:18, Joe Perches  wrote:
> > >
> > > On Wed, 2020-08-26 at 18:55 +0300, Andy Shevchenko wrote:
> > > > On Wed, Aug 26, 2020 at 08:44:30AM -0700, Joe Perches wrote:
> > > > > On Wed, 2020-08-26 at 13:44 +0300, Andy Shevchenko wrote:
> > > >
> > > > ...
> > > >
> > > > > > -int dev_err_probe(const struct device *dev, int err, const char 
> > > > > > *fmt, ...);
> > > > > > +int __must_check dev_err_probe(const struct device *dev, int err, 
> > > > > > const char *fmt, ...);
> >
> > +Cc Stephen and Greg,
> >
> > Hi Andy,
> >
> > Did this patch ended up in next somehow? I am surprised because now I
> > got warnings for perfectly fine code:
> > https://lore.kernel.org/linux-next/20200909155654.76fe3...@canb.auug.org.au/T/#u
> >
> > This creates simply false warnings instead of hints for "optimization".
>
> Yes, it got merged into m y driver core tree.
>
> I'll fix up the tty build warning, should be easy enough, the patch is
> below.

Yes, this fix suppresses the warning but the question is whether we
really want the warning?
Such fixes mean additional code which the compiler might not optimize
(unless it inlines the dev_err_probe()). This additional code is
purely for suppressing the warning, without any meaning on its own.
Actually it might be even confusing for someone to see:
if (ret)
  ret = dev_err_probe(ret);

warn_unused_result should point errors, not "optimization
opportunities". If you want to have opportunity, add a coccinelle
rule. Or a checkpatch rule. Not a compiler warning.

Best regards,
Krzysztof

Re: [PATCH v4 9/9] mfd: mt6360: Merge different sub-devices I2C read/write

[Gene Chen]

Lee Jones  於 2020年9月8日 週二 下午7:48寫道：
>
> On Tue, 01 Sep 2020, Gene Chen wrote:
>
> > Lee Jones  於 2020年8月28日 週五 下午6:40寫道：
> > >
> > > On Mon, 17 Aug 2020, Gene Chen wrote:
> > >
> > > > From: Gene Chen 
> > > >
> > > > Remove unuse register definition.
> > >
> > > This should be in a separate patch.
> > >
> > > > Merge different sub-devices I2C read/write functions into one Regmap,
> > > > because PMIC and LDO part need CRC bits for access protection.
> > > >
> > > > Signed-off-by: Gene Chen 
> > > > ---
> > > >  drivers/mfd/Kconfig|   1 +
> > > >  drivers/mfd/mt6360-core.c  | 260 
> > > > +++--
> > > >  include/linux/mfd/mt6360.h | 240 
> > > > -
> > > >  3 files changed, 226 insertions(+), 275 deletions(-)
> > > >  delete mode 100644 include/linux/mfd/mt6360.h
> > > >
> > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > > index a37d7d1..0684ddc 100644
> > > > --- a/drivers/mfd/Kconfig
> > > > +++ b/drivers/mfd/Kconfig
> > > > @@ -913,6 +913,7 @@ config MFD_MT6360
> > > >   select MFD_CORE
> > > >   select REGMAP_I2C
> > > >   select REGMAP_IRQ
> > > > + select CRC8
> > > >   depends on I2C
> > > >   help
> > > > Say Y here to enable MT6360 PMU/PMIC/LDO functional support.
> > > > diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
> > > > index 677c974..e995220 100644
> > > > --- a/drivers/mfd/mt6360-core.c
> > > > +++ b/drivers/mfd/mt6360-core.c
> > > > @@ -14,7 +14,53 @@
> > > >  #include 
> > > >  #include 
> > > >
> > > > -#include 
> > > > +enum {
> > > > + MT6360_SLAVE_TCPC = 0,
> > > > + MT6360_SLAVE_PMIC,
> > > > + MT6360_SLAVE_LDO,
> > > > + MT6360_SLAVE_PMU,
> > > > + MT6360_SLAVE_MAX,
> > > > +};
> > > > +
> > > > +struct mt6360_ddata {
> > > > + struct i2c_client *i2c[MT6360_SLAVE_MAX];
> > > > + struct device *dev;
> > > > + struct regmap *regmap;
> > > > + struct regmap_irq_chip_data *irq_data;
> > > > + unsigned int chip_rev;
> > > > + u8 crc8_tbl[CRC8_TABLE_SIZE];
> > > > +};
> > >
> > > This is not a new structure, right?  Where was this before?  Surely it
> > > should be removed from wherever it was in the same patch that places
> > > it here?
> > >
> >
> > No, it is merge from header file to source code for unuse in other 
> > sub-module.
>
> So where did it come from and why don't I see the removal in this
> patch?
>

Change is in the bottom of this patch.
There is a little confuse part in "[PATCH v4 5/9] mfd: mt6360: Rename
mt6360_pmu_data by mt6360_ddata"
The "PATCH 5/9" change mt6360_pmu_data to mt6360_ddata instead of mt6360_data.
I will update PATCH v5 to fix it.

[PATCH v4 9/9]
diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h
-struct mt6360_data {
-   struct i2c_client *i2c[MT6360_SLAVE_MAX];
-   struct device *dev;
-   struct regmap *regmap;
-   struct regmap_irq_chip_data *irq_data;
-   unsigned int chip_rev;
-};

[PATCH v4 5/9]
diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h
-struct mt6360_pmu_data {
+struct mt6360_data {
struct i2c_client *i2c[MT6360_SLAVE_MAX];
struct device *dev;
struct regmap *regmap;


> [...]
>
> > > > -static const unsigned short mt6360_slave_addr[MT6360_SLAVE_MAX] = {
> > > > - MT6360_PMU_SLAVEID,
> > > > +static const u16 mt6360_slave_addrs[MT6360_SLAVE_MAX] = {
> > >
> > > Why are you changing the data type?
> > >
> >
> > Easy to read.
> > I think it's the same?
>
> It's an unrelated change and should not be in this patch.
>
> Please separate patches into functional changes.
>

ACK. It's not very important change. I will revert it.

> > > > + MT6360_TCPC_SLAVEID,
> > > >   MT6360_PMIC_SLAVEID,
> > > >   MT6360_LDO_SLAVEID,
> > > > - MT6360_TCPC_SLAVEID,
> > > > + MT6360_PMU_SLAVEID,
> > > > +};
>
> [...]
>
> > > >  static int mt6360_probe(struct i2c_client *client)
> > > > @@ -329,9 +521,23 @@ static int mt6360_probe(struct i2c_client *client)
> > > >   return -ENOMEM;
> > > >
> > > >   ddata->dev = &client->dev;
> > > > - i2c_set_clientdata(client, ddata);
> > > >
> > > > - ddata->regmap = devm_regmap_init_i2c(client, 
> > > > &mt6360_pmu_regmap_config);
> > > > + for (i = 0; i < MT6360_SLAVE_MAX - 1; i++) {
> > > > + ddata->i2c[i] = devm_i2c_new_dummy_device(&client->dev,
> > > > +   client->adapter,
> > > > +   
> > > > mt6360_slave_addrs[i]);
> > > > + if (IS_ERR(ddata->i2c[i])) {
> > > > + dev_err(&client->dev,
> > > > + "Failed to get new dummy I2C device for 
> > > > address 0x%x",
> > > > + mt6360_slave_addrs[i]);
> > > > + return PTR_ERR(ddata->i2c[i]);
> > >
> > > Do you have to free the new dev

Re: [PATCH 06/19] swim: simplify media change handling

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> floppy_revalidate mostly duplicates work already done in floppy_open
> despite only beeing called from floppy_open.  Remove the function and
> just clear the ->ejected flag directly under the right condition.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/block/swim.c | 24 ++--
>  1 file changed, 2 insertions(+), 22 deletions(-)
> 
What a convoluted driver.

Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH] block: Fix potential page reference leak in __bio_iov_append_get_pages()

[Johannes Thumshirn]

On 05/09/2020 11:41, Miaohe Lin wrote:
> When bio_add_hw_page() failed, we left page reference still held in pages.

I'd add "from iov_iter_get_pages()" to the above sentence.

Otherwise
Reviewed-by: Johannes Thumshirn 

Re: [PATCH 5/5] drm_dp_cec: add the implementation of MST support

[Sam McNally]

On Tue, 8 Sep 2020 at 18:08, Hans Verkuil  wrote:
>
> Hi Sam,
>
> On 01/09/2020 08:22, Sam McNally wrote:
> > With DP v2.0 errata E5, CEC tunneling can be supported through an MST
> > topology.
>
> Oh wow, this is finally supported in the spec. Very nice to see this.
> Also very nice to see that my old experimental patches attempting to
> support CEC on MST didn't go to waste!
>
> Do you know of any MST HW that supports this? I'd love to experiment
> with this.

A Realtek RTD2142 with the right firmware can support CEC over MST.
There's nothing released with it that I know of though.
>
> Regards,
>
> Hans
>
> >
> > There are some minor differences for CEC tunneling through an MST
> > topology compared to CEC tunneling to an SST port:
> > - CEC IRQs are delivered via a sink event notify message
> > - CEC-related DPCD registers are accessed via remote DPCD reads and
> >   writes.
> >
> > This results in the MST implementation diverging from the existing SST
> > implementation:
> > - sink event notify messages with CEC_IRQ ID set indicate CEC IRQ rather
> >   than ESI1
> > - setting edid and handling CEC IRQs, which can be triggered from
> >   contexts where locks held preclude HPD handling, are deferred to avoid
> >   remote DPCD access which would block until HPD handling is performed
> >   or a timeout
> >
> > Register and unregister for all MST connectors, ensuring their
> > drm_dp_aux_cec struct won't be accessed uninitialized.
> >
> > Signed-off-by: Sam McNally 
> > ---
> >
> >  drivers/gpu/drm/drm_dp_cec.c  | 67 +--
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++
> >  include/drm/drm_dp_helper.h   |  4 ++
> >  3 files changed, 90 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> > index 04ab7b88055c..9f6aeaa27f00 100644
> > --- a/drivers/gpu/drm/drm_dp_cec.c
> > +++ b/drivers/gpu/drm/drm_dp_cec.c
> > @@ -249,6 +249,10 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux)
> >   if (!aux->transfer)
> >   return;
> >
> > + if (aux->cec.is_mst) {
> > + schedule_work(&aux->cec.mst_irq_work);
> > + return;
> > + }
> >   mutex_lock(&aux->cec.lock);
> >   if (!aux->cec.adap)
> >   goto unlock;
> > @@ -277,6 +281,24 @@ static bool drm_dp_cec_cap(struct drm_dp_aux *aux, u8 
> > *cec_cap)
> >   return true;
> >  }
> >
> > +static void drm_dp_cec_mst_irq_work(struct work_struct *work)
> > +{
> > + struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
> > +   cec.mst_irq_work);
> > + struct drm_dp_mst_port *port =
> > + container_of(aux, struct drm_dp_mst_port, aux);
> > +
> > + port = drm_dp_mst_topology_get_port_validated(port->mgr, port);
> > + if (!port)
> > + return;
> > + mutex_lock(&aux->cec.lock);
> > + if (aux->cec.adap)
> > + drm_dp_cec_handle_irq(aux);
> > +
> > + mutex_unlock(&aux->cec.lock);
> > + drm_dp_mst_topology_put_port(port);
> > +}
> > +
> >  /*
> >   * Called if the HPD was low for more than drm_dp_cec_unregister_delay
> >   * seconds. This unregisters the CEC adapter.
> > @@ -298,7 +320,8 @@ static void drm_dp_cec_unregister_work(struct 
> > work_struct *work)
> >   * were unchanged and just update the CEC physical address. Otherwise
> >   * unregister the old CEC adapter and create a new one.
> >   */
> > -void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> > +static void drm_dp_cec_handle_set_edid(struct drm_dp_aux *aux,
> > +const struct edid *edid)
> >  {
> >   struct drm_connector *connector = aux->cec.connector;
> >   u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> > @@ -307,10 +330,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
> > struct edid *edid)
> >   unsigned int num_las = 1;
> >   u8 cap;
> >
> > - /* No transfer function was set, so not a DP connector */
> > - if (!aux->transfer)
> > - return;
> > -
> >  #ifndef CONFIG_MEDIA_CEC_RC
> >   /*
> >* CEC_CAP_RC is part of CEC_CAP_DEFAULTS, but it is stripped by
> > @@ -321,6 +340,7 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
> > struct edid *edid)
> >*/
> >   cec_caps &= ~CEC_CAP_RC;
> >  #endif
> > + cancel_work_sync(&aux->cec.mst_irq_work);
> >   cancel_delayed_work_sync(&aux->cec.unregister_work);
> >
> >   mutex_lock(&aux->cec.lock);
> > @@ -375,6 +395,18 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
> > struct edid *edid)
> >   }
> >   mutex_unlock(&aux->cec.lock);
> >  }
> > +
> > +void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> > +{
> > + /* No transfer function was set, so not a DP connector */
> > + if (!aux->transfer)
> > + return;
> > +
> > + if (aux->cec.is_mst)
> > + sched

Re: [PATCH 07/19] swim3: use bdev_check_media_changed

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Switch to use bdev_check_media_changed instead of check_disk_change and
> call floppy_revalidate manually.  Given that floppy_revalidate only
> deals with media change events, the extra call into ->revalidate_disk
> from bdev_disk_changed is not required either, so stop wiring up the
> method.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/block/swim3.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH 08/19] xsysace: use bdev_check_media_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Switch to use bdev_check_media_change instead of check_disk_change and
> call ace_revalidate_disk manually.  Given that ace_revalidate_disk only
> deals with media change events, the extra call into ->revalidate_disk
> from bdev_disk_changed is not required either, so stop wiring up the
> method.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/block/xsysace.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

RE: [PATCH 2/2] arm64: dts: lx2160a: add device tree for lx2162aqds board

[Meenakshi Aggarwal]

> -Original Message-
> From: Shawn Guo 
> Sent: Saturday, September 5, 2020 1:24 PM
> To: Meenakshi Aggarwal 
> Cc: robh...@kernel.org; Varun Sethi ; Leo Li
> ; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ioana Ciornei
> ; Kuldeep Singh 
> Subject: Re: [PATCH 2/2] arm64: dts: lx2160a: add device tree for lx2162aqds
> board
> 
> On Wed, Sep 02, 2020 at 08:43:30PM +0530, meenakshi.aggar...@nxp.com
> wrote:
> > From: Meenakshi Aggarwal 
> >
> > Add device tree support for LX2162AQDS board.
> > LX2162A has same die as of LX2160A with different packaging.
> >
> > Signed-off-by: Ioana Ciornei 
> > Signed-off-by: Kuldeep Singh 
> > Signed-off-by: Meenakshi Aggarwal 
> > ---
> >  arch/arm64/boot/dts/freescale/Makefile|   1 +
> >  arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts | 336
> > ++
> >  2 files changed, 337 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > b/arch/arm64/boot/dts/freescale/Makefile
> > index a39f0a1..ab9fbd3 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -27,6 +27,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) +=
> > fsl-lx2160a-clearfog-cx.dtb
> >  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-honeycomb.dtb
> >  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-qds.dtb
> >  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
> > +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2162a-qds.dtb
> >
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb diff --git
> > a/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
> > new file mode 100644
> > index 000..a81c6a4
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
> > @@ -0,0 +1,336 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) // // Device Tree file
> > +for LX2162AQDS // // Copyright 2020 NXP
> > +
> > +/dts-v1/;
> > +
> > +#include "fsl-lx2160a.dtsi"
> > +
> > +/ {
> > +   model = "NXP Layerscape LX2162AQDS";
> > +   compatible = "nxp,lx2162a-qds", "fsl,lx2160a";
> > +
> > +   aliases {
> > +   crypto = &crypto;
> > +   serial0 = &uart0;
> > +   };
> > +
> > +   chosen {
> > +   stdout-path = "serial0:115200n8";
> > +   };
> > +
> > +   sb_3v3: regulator-sb3v3 {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "MC34717-3.3VSB";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   regulator-boot-on;
> > +   regulator-always-on;
> 
> I do not see any point to have regulator-boot-on or regulator-always-on for a
> regulator that doesn't have on/off control.
[Meenakshi Aggarwal] Properties are added to specify that platform firmware's 
out of reset configuration enabled the regulator and 
regulator should never be disabled or change its operative status.

Can you help in understanding why these optional properties cannot be used 
together
> 
> > +   };
> > +
> > +   mdio-mux-1 {
> > +   compatible = "mdio-mux-multiplexer";
> > +   mux-controls = <&mux 0>;
> > +   mdio-parent-bus = <&emdio1>;
> > +   #address-cells=<1>;
> > +   #size-cells = <0>;
> > +
> > +   mdio@0 { /* On-board RTL8211F PHY #1 RGMII1*/
> > +   reg = <0x00>;
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   rgmii_phy1: ethernet-phy@1 {
> > +   compatible = "ethernet-phy-id001c.c916";
> > +   reg = <0x1>;
> > +   eee-broken-1000t;
> > +   };
> > +   };
> > +
> > +   mdio@8 { /* On-board RTL8211F PHY #2 RGMII2*/
> 
> Missing one space before closing comment.
[Meenakshi Aggarwal] will correct in next version
> 
> Shawn
> 
> > +   reg = <0x8>;
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   rgmii_phy2: ethernet-phy@2 {
> > +   compatible = "ethernet-phy-id001c.c916";
> > +   reg = <0x2>;
> > +   eee-broken-1000t;
> > +   };
> > +   };
> > +
> > +   mdio@18 { /* Slot #1 */
> > +   reg = <0x18>;
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   };
> > +
> > +   mdio@19 { /* Slot #2 */
> > +   reg = <0x19>;
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   };
> > +
> > +   mdio@1a { /* Slot #3 */
> > +   reg = <0x1a>;
> > +   #address-cells = <1>;
> > +   #size-cells =

RE: [PATCH v5 2/2] misc: rtsx: Add power saving functions and fix driving parameter

[吳昊澄 Ricky]

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Wednesday, September 09, 2020 6:29 AM
> To: 吳昊澄 Ricky
> Cc: a...@arndb.de; gre...@linuxfoundation.org; bhelg...@google.com;
> ulf.hans...@linaro.org; rui_f...@realsil.com.cn; linux-kernel@vger.kernel.org;
> puranja...@gmail.com; linux-...@vger.kernel.org;
> vailbhavgupt...@gamail.com
> Subject: Re: [PATCH v5 2/2] misc: rtsx: Add power saving functions and fix 
> driving
> parameter
> 
> On Mon, Sep 07, 2020 at 06:07:31PM +0800, ricky...@realtek.com wrote:
> > From: Ricky Wu 
> >
> > v4:
> > split power down flow and power saving function to two patch
> >
> > v5:
> > fix up modified change under the --- line
> 
> Hehe, this came out *above* the "---" line :)
> 
> > Add rts522a L1 sub-state support
> > Save more power on rts5227 rts5249 rts525a rts5260
> > Fix rts5260 driving parameter
> >
> > Signed-off-by: Ricky Wu 
> > ---
> >  drivers/misc/cardreader/rts5227.c  | 112 +-
> >  drivers/misc/cardreader/rts5249.c  | 145
> -
> >  drivers/misc/cardreader/rts5260.c  |  28 +++---
> >  drivers/misc/cardreader/rtsx_pcr.h |  17 
> >  4 files changed, 283 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/misc/cardreader/rts5227.c
> b/drivers/misc/cardreader/rts5227.c
> > index 747391e3fb5d..8859011672cb 100644
> > --- a/drivers/misc/cardreader/rts5227.c
> > +++ b/drivers/misc/cardreader/rts5227.c
> > @@ -72,15 +72,80 @@ static void rts5227_fetch_vendor_settings(struct
> rtsx_pcr *pcr)
> >
> > pci_read_config_dword(pdev, PCR_SETTING_REG2, ®);
> > pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
> > +   if (rtsx_check_mmc_support(reg))
> > +   pcr->extra_caps |= EXTRA_CAPS_NO_MMC;
> > pcr->sd30_drive_sel_3v3 = rtsx_reg_to_sd30_drive_sel_3v3(reg);
> > if (rtsx_reg_check_reverse_socket(reg))
> > pcr->flags |= PCR_REVERSE_SOCKET;
> >  }
> >
> > +static void rts5227_init_from_cfg(struct rtsx_pcr *pcr)
> > +{
> > +   struct pci_dev *pdev = pcr->pci;
> > +   int l1ss;
> > +   u32 lval;
> > +   struct rtsx_cr_option *option = &pcr->option;
> > +
> > +   l1ss = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_L1SS);
> > +   if (!l1ss)
> > +   return;
> > +
> > +   pci_read_config_dword(pdev, l1ss + PCI_L1SS_CTL1, &lval);
> 
> This looks a little problematic.  PCI_L1SS_CTL1 is an architected
> register in the ASPM L1 PM Substates capability, and its value may
> change at runtime because drivers/pci/pcie/aspm.c manages it.
> 
> It looks like the code below does device-specific configuration based
> on the current PCI_L1SS_CTL1 value.  But what happens if aspm.c
> changes PCI_L1SS_CTL1 later?
> 

We are going to make sure and set the best configuration on the current time, 
if host change the capability later, it doesn't affect function, only affect a 
little power saving   

> > +   if (CHK_PCI_PID(pcr, 0x522A)) {
> > +   if (0 == (lval & 0x0F))
> > +   rtsx_pci_enable_oobs_polling(pcr);
> > +   else
> > +   rtsx_pci_disable_oobs_polling(pcr);
> > +   }
> > +
> > +   if (lval & PCI_L1SS_CTL1_ASPM_L1_1)
> > +   rtsx_set_dev_flag(pcr, ASPM_L1_1_EN);
> > +   else
> > +   rtsx_clear_dev_flag(pcr, ASPM_L1_1_EN);
> > +
> > +   if (lval & PCI_L1SS_CTL1_ASPM_L1_2)
> > +   rtsx_set_dev_flag(pcr, ASPM_L1_2_EN);
> > +   else
> > +   rtsx_clear_dev_flag(pcr, ASPM_L1_2_EN);
> > +
> > +   if (lval & PCI_L1SS_CTL1_PCIPM_L1_1)
> > +   rtsx_set_dev_flag(pcr, PM_L1_1_EN);
> > +   else
> > +   rtsx_clear_dev_flag(pcr, PM_L1_1_EN);
> > +
> > +   if (lval & PCI_L1SS_CTL1_PCIPM_L1_2)
> > +   rtsx_set_dev_flag(pcr, PM_L1_2_EN);
> > +   else
> > +   rtsx_clear_dev_flag(pcr, PM_L1_2_EN);
> > +
> > +   if (option->ltr_en) {
> > +   u16 val;
> > +
> > +   pcie_capability_read_word(pcr->pci, PCI_EXP_DEVCTL2, &val);
> 
> Same thing here.  I don't think the PCI core currently changes
> PCI_EXP_DEVCTL2 after boot, but it's not a good idea to assume it's
> going to be constant.
> 

The same reply

> > +   if (val & PCI_EXP_DEVCTL2_LTR_EN) {
> > +   option->ltr_enabled = true;
> > +   option->ltr_active = true;
> > +   rtsx_set_ltr_latency(pcr, option->ltr_active_latency);
> > +   } else {
> > +   option->ltr_enabled = false;
> > +   }
> > +   }
> > +
> > +   if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN
> > +   | PM_L1_1_EN | PM_L1_2_EN))
> > +   option->force_clkreq_0 = false;
> > +   else
> > +   option->force_clkreq_0 = true;
> > +
> > +}
> 
> --Please consider the environment before printing this e-mail.

Re: [PATCH 09/19] xsysace: simplify media change handling

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Pass a struct ace_device to ace_revalidate_disk, move the media changed
> check into the one caller that needs it, and give the routine a better
> name.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/block/xsysace.c | 26 ++
>  1 file changed, 10 insertions(+), 16 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH for-next] io_uring: return EBADFD when ring isn't in the right state

[Stefano Garzarella]

On Tue, Sep 08, 2020 at 11:02:48AM -0600, Jens Axboe wrote:
> On 9/8/20 10:52 AM, Stefano Garzarella wrote:
> > This patch uniforms the returned error (EBADFD) when the ring state
> > (enabled/disabled) is not the expected one.
> > 
> > The changes affect io_uring_enter() and io_uring_register() syscalls.
> 
> I added a Fixes line:
> 
> Fixes: 7ec3d1dd9378 ("io_uring: allow disabling rings during the creation")

Oh right, I forgot!

> 
> and applied it, thanks!
> 
> > https://github.com/stefano-garzarella/liburing (branch: 
> > fix-disabled-ring-error)
> 
> I'll check and pull that one too.
> 

Thanks,
Stefano

Re: [f2fs-dev] Question about STEP_DECOMPRESS_NOWQ

[Chao Yu]

Hi Daeho,

On 2020/9/9 12:43, Daeho Jeong wrote:

Hi Chao,

I have a question about the below flag for decompression.

STEP_DECOMPRESS_NOWQ,   /* handle normal cluster data inplace */

According to the comment, you added this for using inplace


I added this for the condition that: in compressed inode, partial clusters are
written as normal (non-compressed) one due to bad compress ratio, during reading
data in normal cluster, we don't need to queue them in workqueue, instead, we
can just handle them in IRQ context (end_io()).

That says, if all pages in bio are non-compressed, we tag step w/ 
STEP_DECOMPRESS_NOWQ,
once there is at least one page is compressed, we change step to
STEP_DECOMPRESS.


decompression but inplace decompression mode is not being activated


'inplace decompression' means decompress in
a. reader thread or
b. IRQ context ?

Thanks


now, since we are setting STEP_DECOMPRESS right after bio_add_page().

 if (bio_add_page(bio, page, blocksize, 0) < blocksize)
 goto submit_and_realloc;

 /* tag STEP_DECOMPRESS to handle IO in wq */
 ctx = bio->bi_private;
 if (!(ctx->enabled_steps & (1 << STEP_DECOMPRESS)))
 ctx->enabled_steps |= 1 << STEP_DECOMPRESS;

Did you mean to deactivate inplace decompression mode on purpose,
since it had an issue? I am a little bit confused about this.


___
Linux-f2fs-devel mailing list
linux-f2fs-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
.

Re: [RFC PATCH 00/16] 1GB THP support on x86_64

[Michal Hocko]

On Tue 08-09-20 12:58:59, Roman Gushchin wrote:
> On Tue, Sep 08, 2020 at 11:09:25AM -0400, Zi Yan wrote:
> > On 7 Sep 2020, at 3:20, Michal Hocko wrote:
> > 
> > > On Fri 04-09-20 14:10:45, Roman Gushchin wrote:
> > >> On Fri, Sep 04, 2020 at 09:42:07AM +0200, Michal Hocko wrote:
> > > [...]
> > >>> An explicit opt-in sounds much more appropriate to me as well. If we go
> > >>> with a specific API then I would not make it 1GB pages specific. Why
> > >>> cannot we have an explicit interface to "defragment" address space
> > >>> range into large pages and the kernel would use large pages where
> > >>> appropriate? Or is the additional copying prohibitively expensive?
> > >>
> > >> Can you, please, elaborate a bit more here? It seems like 
> > >> madvise(MADV_HUGEPAGE)
> > >> provides something similar to what you're describing, but there are lot
> > >> of details here, so I'm probably missing something.
> > >
> > > MADV_HUGEPAGE is controlling a preference for THP to be used for a
> > > particular address range. So it looks similar but the historical
> > > behavior is to control page faults as well and the behavior depends on
> > > the global setup.
> > >
> > > I've had in mind something much simpler. Effectively an API to invoke
> > > khugepaged (like) functionality synchronously from the calling context
> > > on the specific address range. It could be more aggressive than the
> > > regular khugepaged and create even 1G pages (or as large THPs as page
> > > tables can handle on the particular arch for that matter).
> > >
> > > As this would be an explicit call we do not have to be worried about
> > > the resulting latency because it would be an explicit call by the
> > > userspace.  The default khugepaged has a harder position there because
> > > has no understanding of the target address space and cannot make any
> > > cost/benefit evaluation so it has to be more conservative.
> > 
> > Something like MADV_HUGEPAGE_SYNC? It would be useful, since users have
> > better and clearer control of getting huge pages from the kernel and
> > know when they will pay the cost of getting the huge pages.

The name is not really that important. The crucial design decisions are
- THP allocation time - #PF and/or madvise context
- lazy/sync instantiation
- huge page sizes controllable by the userspace?
- aggressiveness - how hard to try
- internal fragmentation - allow to create THPs on sparsely or unpopulated
  ranges
- do we need some sort of access control or privilege check as some THPs
  would be a really scarce (like those that require pre-reservation).

> > I would think the suggestion is more about the huge page control options
> > currently provided by the kernel do not have predictable performance
> > outcome, since MADV_HUGEPAGE is a best-effort option and does not tell
> > users whether the marked virtual address range is backed by huge pages
> > or not when the madvise returns. MADV_HUGEPAGE_SYNC would provide a
> > deterministic result to users on whether the huge page(s) are formed
> > or not.
> 
> Yeah, I agree with Michal here, we need a more straightforward interface.
> 
> The hard question here is how hard the kernel should try to allocate
> a gigantic page and how fast it should give up and return an error?
> I'd say to try really hard if there are some chances to succeed,
> so that if an error is returned, there are no more reasons to retry.
> Any objections/better ideas here?

If this is going to be an explicit interface like madvise then I would
follow the same semantic as hugetlb pages allocation - aka try as hard
as feasible (whatever that means).

> Given that we need to pass a page size, we probably need either to introduce
> a new syscall (madvise2?) with an additional argument, or add a bunch
> of new madvise flags, like MADV_HUGEPAGE_SYNC + encoded 2MB, 1GB etc.

Do we really need to bother userspace with making decision about the
page size? I would expect that the userspace only cares to get huge
pages backed memory range. The larger the pages the better. It is up to
the kernel to make the resource control here. Afterall THPs can be
split/reclaimed under a memory pressure so we do not want to make any
promises about pages backing any mapping.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 1/2] dt-bindings: mfd: syscon: Merge Samsung Exynos Sysreg bindings

[Lee Jones]

On Wed, 02 Sep 2020, Krzysztof Kozlowski wrote:

> The Samsung Exynos System Registers (Sysreg) bindings are quite simple -
> just additional compatible to the syscon.  They do not have any value so
> merge them into generic MFD syscon bindings.
> 
> Suggested-by: Sylwester Nawrocki 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. New patch
> ---
>  .../bindings/arm/samsung/sysreg.yaml  | 45 ---
>  .../devicetree/bindings/mfd/syscon.yaml   |  2 +
>  2 files changed, 2 insertions(+), 45 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/samsung/sysreg.yaml

Applied, thanks.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

[Greg Kroah-Hartman]

On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote:
> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
> always set to 0 by hardware. This is far from beautiful (and confusing),
> and the bit only applies to SYSRAM. So let's move it out of the
> bus-specific (PnP) defined bits.
> 
> We'll add another SYSRAM specific bit soon. If we ever need more bits for
> other purposes, we can steal some from "desc", or reshuffle/regroup what we
> have.
> 
> Cc: Andrew Morton 
> Cc: Michal Hocko 
> Cc: Dan Williams 
> Cc: Jason Gunthorpe 
> Cc: Kees Cook 
> Cc: Ard Biesheuvel 
> Cc: Pankaj Gupta 
> Cc: Baoquan He 
> Cc: Wei Yang 
> Cc: Eric Biederman 
> Cc: Thomas Gleixner 
> Cc: Greg Kroah-Hartman 
> Cc: ke...@lists.infradead.org
> Signed-off-by: David Hildenbrand 
> ---
>  include/linux/ioport.h | 4 +++-
>  kernel/kexec_file.c| 2 +-
>  mm/memory_hotplug.c| 4 ++--
>  3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 52a91f5fa1a36..d7620d7c941a0 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -58,6 +58,9 @@ struct resource {
>  #define IORESOURCE_EXT_TYPE_BITS 0x0100  /* Resource extended types */
>  #define IORESOURCE_SYSRAM0x0100  /* System RAM (modifier) */
>  
> +/* IORESOURCE_SYSRAM specific bits. */
> +#define IORESOURCE_SYSRAM_DRIVER_MANAGED 0x0200 /* Always detected 
> via a driver. */
> +

Can't you use BIT() here?

thanks,

greg k-h

Re: [PATCH v2 2/2] dt-bindings: mfd: syscon: Document Exynos3 and Exynos5433 compatibles

[Lee Jones]

On Wed, 02 Sep 2020, Krzysztof Kozlowski wrote:

> Document Samsung Exynos3 and Exynos5433 compatibles for system
> registers.
> 
> Reviewed-by: Sylwester Nawrocki 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Rebase on first patch
> ---
>  Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>  1 file changed, 2 insertions(+)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

linux-next: build warning after merge of the staging tree

[Stephen Rothwell]

Hi all,

After merging the staging tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/iio/adc/stm32-adc-core.c: In function 'stm32_adc_core_switches_probe':
drivers/iio/adc/stm32-adc-core.c:598:5: warning: ignoring return value of 
'dev_err_probe' declared with attribute 'warn_unused_result' [-Wunused-result]
  598 | dev_err_probe(dev, ret, "can't get booster\n");
  | ^~

Introduced by commit

  ce30eeb613cb ("iio: adc: stm32: Simplify with dev_err_probe()")

-- 
Cheers,
Stephen Rothwell


pgpkXTrPpqzVV.pgp
Description: OpenPGP digital signature

[Linux-kernel-mentees] [PATCH net v2] Bluetooth: Fix slab-out-of-bounds read in hci_le_direct_adv_report_evt()

[Peilin Ye]

`num_reports` is not being properly checked. A malformed event packet with
a large `num_reports` number makes hci_le_direct_adv_report_evt() read out
of bounds. Fix it.

Cc: sta...@vger.kernel.org
Fixes: 2f010b55884e ("Bluetooth: Add support for handling LE Direct Advertising 
Report events")
Reported-and-tested-by: syzbot+24ebd650e20bd263c...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=24ebd650e20bd263ca01
Signed-off-by: Peilin Ye 
---
Change in v2:
- add "Cc: stable@" tag.

 net/bluetooth/hci_event.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 4b7fc430793c..aec43ae488d1 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -5863,21 +5863,19 @@ static void hci_le_direct_adv_report_evt(struct hci_dev 
*hdev,
 struct sk_buff *skb)
 {
u8 num_reports = skb->data[0];
-   void *ptr = &skb->data[1];
+   struct hci_ev_le_direct_adv_info *ev = (void *)&skb->data[1];
 
-   hci_dev_lock(hdev);
+   if (!num_reports || skb->len < num_reports * sizeof(*ev) + 1)
+   return;
 
-   while (num_reports--) {
-   struct hci_ev_le_direct_adv_info *ev = ptr;
+   hci_dev_lock(hdev);
 
+   for (; num_reports; num_reports--, ev++)
process_adv_report(hdev, ev->evt_type, &ev->bdaddr,
   ev->bdaddr_type, &ev->direct_addr,
   ev->direct_addr_type, ev->rssi, NULL, 0,
   false);
 
-   ptr += sizeof(*ev);
-   }
-
hci_dev_unlock(hdev);
 }
 
-- 
2.25.1

Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

[Greg Kroah-Hartman]

On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
> We soon want to pass flags, e.g., to mark added System RAM resources.
> mergeable. Prepare for that.

What are these random "flags", and how do we know what should be passed
to them?

Why not make this an enumerated type so that we know it all works
properly, like the GPF_* flags are?  Passing around a random unsigned
long feels very odd/broken...

thanks,

greg k-h

[PATCH V4 0/3] percpu_ref & block: reduce memory footprint of percpu_ref in fast path

[Ming Lei]

Hi,

The 1st patch removes memory footprint of percpu_ref in fast path
from 7 words to 2 words, since it is often used in fast path and
embedded in user struct.

The 2nd patch moves .q_usage_counter to 1st cacheline of
'request_queue'.

Simple test on null_blk shows ~2% IOPS boost on one 16cores(two threads
per core) machine, dual socket/numa.

V4:
- rename percpu_ref_inited as percpu_ref_is_initialized

V3:
- fix kernel oops on MD
- add patch for avoiding to use percpu-refcount internal from md
  code
- pass Red Hat CKI test which is done by Veronika Kabatova

V2:
- pass 'gfp' to kzalloc() for fixing block/027 failure reported by
kernel test robot
- protect percpu_ref_is_zero() with destroying percpu-refcount by
spin lock  


Ming Lei (3):
  percpu_ref: add percpu_ref_is_initialized for MD
  percpu_ref: reduce memory footprint of percpu_ref in fast path
  block: move 'q_usage_counter' into front of 'request_queue'

 drivers/infiniband/sw/rdmavt/mr.c |   2 +-
 drivers/md/md.c   |   2 +-
 include/linux/blkdev.h|   3 +-
 include/linux/percpu-refcount.h   |  46 --
 lib/percpu-refcount.c | 137 +++---
 5 files changed, 126 insertions(+), 64 deletions(-)

Cc: Veronika Kabatova 
Cc: Sagi Grimberg 
Cc: Tejun Heo 
Cc: Christoph Hellwig 
Cc: Jens Axboe 
Cc: Bart Van Assche 
-- 
2.25.2

[PATCH V4 2/3] percpu_ref: reduce memory footprint of percpu_ref in fast path

[Ming Lei]

'struct percpu_ref' is often embedded into one user structure, and the
instance is usually referenced in fast path, however actually only
'percpu_count_ptr' is needed in fast path.

So move other fields into one new structure of 'percpu_ref_data', and
allocate it dynamically via kzalloc(), then memory footprint of
'percpu_ref' in fast path is reduced a lot and becomes suitable to put
into hot cacheline of user structure.

Tested-by: Veronika Kabatova 
Reviewed-by: Christoph Hellwig 
Cc: Sagi Grimberg 
Cc: Tejun Heo 
Cc: Christoph Hellwig 
Cc: Jens Axboe 
Cc: Bart Van Assche 
Signed-off-by: Ming Lei 
---
 drivers/infiniband/sw/rdmavt/mr.c |   2 +-
 include/linux/percpu-refcount.h   |  45 --
 lib/percpu-refcount.c | 131 ++
 3 files changed, 116 insertions(+), 62 deletions(-)

diff --git a/drivers/infiniband/sw/rdmavt/mr.c 
b/drivers/infiniband/sw/rdmavt/mr.c
index 2f7c25fea44a..8490fdb9c91e 100644
--- a/drivers/infiniband/sw/rdmavt/mr.c
+++ b/drivers/infiniband/sw/rdmavt/mr.c
@@ -499,7 +499,7 @@ static int rvt_check_refs(struct rvt_mregion *mr, const 
char *t)
rvt_pr_err(rdi,
   "%s timeout mr %p pd %p lkey %x refcount %ld\n",
   t, mr, mr->pd, mr->lkey,
-  atomic_long_read(&mr->refcount.count));
+  atomic_long_read(&mr->refcount.data->count));
rvt_get_mr(mr);
return -EBUSY;
}
diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index 2dfdf870f2d0..8eb072f54c8a 100644
--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -92,18 +92,23 @@ enum {
PERCPU_REF_ALLOW_REINIT = 1 << 2,
 };
 
-struct percpu_ref {
+struct percpu_ref_data {
atomic_long_t   count;
-   /*
-* The low bit of the pointer indicates whether the ref is in percpu
-* mode; if set, then get/put will manipulate the atomic_t.
-*/
-   unsigned long   percpu_count_ptr;
percpu_ref_func_t   *release;
percpu_ref_func_t   *confirm_switch;
boolforce_atomic:1;
boolallow_reinit:1;
struct rcu_head rcu;
+   struct percpu_ref   *ref;
+};
+
+struct percpu_ref {
+   /*
+* The low bit of the pointer indicates whether the ref is in percpu
+* mode; if set, then get/put will manipulate the atomic_t.
+*/
+   unsigned long   percpu_count_ptr;
+   struct percpu_ref_data  *data;
 };
 
 int __must_check percpu_ref_init(struct percpu_ref *ref,
@@ -119,6 +124,7 @@ void percpu_ref_kill_and_confirm(struct percpu_ref *ref,
 percpu_ref_func_t *confirm_kill);
 void percpu_ref_resurrect(struct percpu_ref *ref);
 void percpu_ref_reinit(struct percpu_ref *ref);
+bool percpu_ref_is_zero(struct percpu_ref *ref);
 
 /**
  * percpu_ref_kill - drop the initial ref
@@ -192,7 +198,7 @@ static inline void percpu_ref_get_many(struct percpu_ref 
*ref, unsigned long nr)
if (__ref_is_percpu(ref, &percpu_count))
this_cpu_add(*percpu_count, nr);
else
-   atomic_long_add(nr, &ref->count);
+   atomic_long_add(nr, &ref->data->count);
 
rcu_read_unlock();
 }
@@ -232,7 +238,7 @@ static inline bool percpu_ref_tryget_many(struct percpu_ref 
*ref,
this_cpu_add(*percpu_count, nr);
ret = true;
} else {
-   ret = atomic_long_add_unless(&ref->count, nr, 0);
+   ret = atomic_long_add_unless(&ref->data->count, nr, 0);
}
 
rcu_read_unlock();
@@ -280,7 +286,7 @@ static inline bool percpu_ref_tryget_live(struct percpu_ref 
*ref)
this_cpu_inc(*percpu_count);
ret = true;
} else if (!(ref->percpu_count_ptr & __PERCPU_REF_DEAD)) {
-   ret = atomic_long_inc_not_zero(&ref->count);
+   ret = atomic_long_inc_not_zero(&ref->data->count);
}
 
rcu_read_unlock();
@@ -306,8 +312,8 @@ static inline void percpu_ref_put_many(struct percpu_ref 
*ref, unsigned long nr)
 
if (__ref_is_percpu(ref, &percpu_count))
this_cpu_sub(*percpu_count, nr);
-   else if (unlikely(atomic_long_sub_and_test(nr, &ref->count)))
-   ref->release(ref);
+   else if (unlikely(atomic_long_sub_and_test(nr, &ref->data->count)))
+   ref->data->release(ref);
 
rcu_read_unlock();
 }
@@ -340,21 +346,4 @@ static inline bool percpu_ref_is_dying(struct percpu_ref 
*ref)
return ref->percpu_count_ptr & __PERCPU_REF_DEAD;
 }
 
-/**
- * percpu_ref_is_zero - test whether a percpu refcount reached zero
- * @ref: percpu_ref to test
- *
- * Returns %true if @ref reached zero.
- *
- * This function is safe to call as long as @ref is between init and exit.
- */
-static inline bool percpu_ref_is_z

[PATCH V4 1/3] percpu_ref: add percpu_ref_is_initialized for MD

[Ming Lei]

MD code uses perpcu-refcount internal to check if this percpu-refcount
variable is initialized, this way is a hack.

Add percpu_ref_is_initialized for MD so that the hack can be avoided.

Acked-by: Song Liu 
Suggested-by: Jens Axboe 
Tested-by: Veronika Kabatova 
Cc: Song Liu 
Cc: linux-r...@vger.kernel.org
Cc: Sagi Grimberg 
Cc: Tejun Heo 
Cc: Christoph Hellwig 
Cc: Jens Axboe 
Cc: Bart Van Assche 
Signed-off-by: Ming Lei 
---
 drivers/md/md.c | 2 +-
 include/linux/percpu-refcount.h | 1 +
 lib/percpu-refcount.c   | 6 ++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 9562ef598ae1..3c711f2968a9 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -5632,7 +5632,7 @@ static void no_op(struct percpu_ref *r) {}
 
 int mddev_init_writes_pending(struct mddev *mddev)
 {
-   if (mddev->writes_pending.percpu_count_ptr)
+   if (percpu_ref_is_initialized(&mddev->writes_pending))
return 0;
if (percpu_ref_init(&mddev->writes_pending, no_op,
PERCPU_REF_ALLOW_REINIT, GFP_KERNEL) < 0)
diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index 87d8a38bdea1..2dfdf870f2d0 100644
--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -109,6 +109,7 @@ struct percpu_ref {
 int __must_check percpu_ref_init(struct percpu_ref *ref,
 percpu_ref_func_t *release, unsigned int flags,
 gfp_t gfp);
+bool percpu_ref_is_initialized(struct percpu_ref *ref);
 void percpu_ref_exit(struct percpu_ref *ref);
 void percpu_ref_switch_to_atomic(struct percpu_ref *ref,
 percpu_ref_func_t *confirm_switch);
diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c
index 0ba686b8fe57..db2ec682e0f7 100644
--- a/lib/percpu-refcount.c
+++ b/lib/percpu-refcount.c
@@ -93,6 +93,12 @@ int percpu_ref_init(struct percpu_ref *ref, 
percpu_ref_func_t *release,
 }
 EXPORT_SYMBOL_GPL(percpu_ref_init);
 
+bool percpu_ref_is_initialized(struct percpu_ref *ref)
+{
+   return percpu_count_ptr(ref) != NULL;
+}
+EXPORT_SYMBOL_GPL(percpu_ref_is_initialized);
+
 /**
  * percpu_ref_exit - undo percpu_ref_init()
  * @ref: percpu_ref to exit
-- 
2.25.2

[PATCH V4 3/3] block: move 'q_usage_counter' into front of 'request_queue'

[Ming Lei]

The field of 'q_usage_counter' is always fetched in fast path of every
block driver, and move it into front of 'request_queue', so it can be
fetched into 1st cacheline of 'request_queue' instance.

Tested-by: Veronika Kabatova 
Reviewed-by: Christoph Hellwig 
Cc: Sagi Grimberg 
Cc: Tejun Heo 
Cc: Christoph Hellwig 
Cc: Jens Axboe 
Cc: Bart Van Assche 
Signed-off-by: Ming Lei 
---
 include/linux/blkdev.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 7d82959e7b86..7b1e53084799 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -397,6 +397,8 @@ struct request_queue {
struct request  *last_merge;
struct elevator_queue   *elevator;
 
+   struct percpu_ref   q_usage_counter;
+
struct blk_queue_stats  *stats;
struct rq_qos   *rq_qos;
 
@@ -569,7 +571,6 @@ struct request_queue {
 * percpu_ref_kill() and percpu_ref_reinit().
 */
struct mutexmq_freeze_lock;
-   struct percpu_ref   q_usage_counter;
 
struct blk_mq_tag_set   *tag_set;
struct list_headtag_set_list;
-- 
2.25.2

[PATCH] misc: rtsx: Fix memory leak in rtsx_pci_probe

[Keita Suzuki]

When mfd_add_devices() fail, pcr->slots should also be freed. However,
the current implementation does not free the member, leading to a memory
leak.

Fix this by adding a new goto label that frees pcr->slots.

Signed-off-by: Keita Suzuki 
---
 drivers/misc/cardreader/rtsx_pcr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/cardreader/rtsx_pcr.c 
b/drivers/misc/cardreader/rtsx_pcr.c
index 37ccc67f4914..f2b2805942f5 100644
--- a/drivers/misc/cardreader/rtsx_pcr.c
+++ b/drivers/misc/cardreader/rtsx_pcr.c
@@ -1562,12 +1562,14 @@ static int rtsx_pci_probe(struct pci_dev *pcidev,
ret = mfd_add_devices(&pcidev->dev, pcr->id, rtsx_pcr_cells,
ARRAY_SIZE(rtsx_pcr_cells), NULL, 0, NULL);
if (ret < 0)
-   goto disable_irq;
+   goto free_slots;
 
schedule_delayed_work(&pcr->idle_work, msecs_to_jiffies(200));
 
return 0;
 
+free_slots:
+   kfree(pcr->slots);
 disable_irq:
free_irq(pcr->irq, (void *)pcr);
 disable_msi:
-- 
2.17.1

Re: [RFC PATCH v8 0/3] Add support for AT_INTERPRETED (was O_MAYEXEC)

[Mickaël Salaün]

On 08/09/2020 20:50, Al Viro wrote:
> On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote:
>> Hi,
>>
>> This height patch series rework the previous O_MAYEXEC series by not
>> adding a new flag to openat2(2) but to faccessat2(2) instead.  As
>> suggested, this enables to perform the access check on a file descriptor
>> instead of on a file path (while opening it).  This may require two
>> checks (one on open and then with faccessat2) but it is a more generic
>> approach [8].
> 
> Again, why is that folded into lookup/open/whatnot, rather than being
> an operation applied to a file (e.g. O_PATH one)?
> 

I don't understand your question. AT_INTERPRETED can and should be used
with AT_EMPTY_PATH. The two checks I wrote about was for IMA.

Re: linux-next: build failure after merge of the driver-core tree

[Greg KH]

On Wed, Sep 09, 2020 at 03:47:09PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> lib/test_firmware.c: In function 'trigger_request_platform_store':
> lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first 
> use in this function); did you mean 'efi_embedded_fw_desc'?
>   517 |  list_add(&efi_embedded_fw.list, &efi_embedded_fw_list);
>   |   ^~~~
>   |   efi_embedded_fw_desc
> lib/test_firmware.c:517:35: note: each undeclared identifier is reported only 
> once for each function it appears in
> lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared 
> (first use in this function); did you mean 'saved_efi_embedded_fw_checked'?
>   518 |  saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
>   |  ^~~
>   |  saved_efi_embedded_fw_checked
> 
> Caused by commit
> 
>   18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI systems")

{sigh}

I'll go revert this, sorry about that.

Kees, can you fix up this whole series and resend it again?  I'm
dropping it from my trees now...

thanks,

greg k-h

[PATCH v2 1/4] dp/dp_mst: Add support for sink event notify messages

[Sam McNally]

Sink event notify messages are used for MST CEC IRQs. Add parsing
support for sink event notify messages in preparation for handling MST
CEC IRQs.

Signed-off-by: Sam McNally 
---

(no changes since v1)

 drivers/gpu/drm/drm_dp_mst_topology.c | 37 ++-
 include/drm/drm_dp_mst_helper.h   | 14 ++
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 17dbed0a9800..15b6cc39a754 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1027,6 +1027,30 @@ static bool 
drm_dp_sideband_parse_resource_status_notify(struct drm_dp_sideband_
return false;
 }
 
+static bool drm_dp_sideband_parse_sink_event_notify(
+   struct drm_dp_sideband_msg_rx *raw,
+   struct drm_dp_sideband_msg_req_body *msg)
+{
+   int idx = 1;
+
+   msg->u.sink_event.port_number = (raw->msg[idx] & 0xf0) >> 4;
+   idx++;
+   if (idx > raw->curlen)
+   goto fail_len;
+
+   memcpy(msg->u.sink_event.guid, &raw->msg[idx], 16);
+   idx += 16;
+   if (idx > raw->curlen)
+   goto fail_len;
+
+   msg->u.sink_event.event_id = (raw->msg[idx] << 8) | (raw->msg[idx + 1]);
+   idx++;
+   return true;
+fail_len:
+   DRM_DEBUG_KMS("sink event notify parse length fail %d %d\n", idx, 
raw->curlen);
+   return false;
+}
+
 static bool drm_dp_sideband_parse_req(struct drm_dp_sideband_msg_rx *raw,
  struct drm_dp_sideband_msg_req_body *msg)
 {
@@ -1038,6 +1062,8 @@ static bool drm_dp_sideband_parse_req(struct 
drm_dp_sideband_msg_rx *raw,
return drm_dp_sideband_parse_connection_status_notify(raw, msg);
case DP_RESOURCE_STATUS_NOTIFY:
return drm_dp_sideband_parse_resource_status_notify(raw, msg);
+   case DP_SINK_EVENT_NOTIFY:
+   return drm_dp_sideband_parse_sink_event_notify(raw, msg);
default:
DRM_ERROR("Got unknown request 0x%02x (%s)\n", msg->req_type,
  drm_dp_mst_req_type_str(msg->req_type));
@@ -3875,6 +3901,8 @@ drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr 
*mgr,
guid = msg->u.conn_stat.guid;
else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
guid = msg->u.resource_stat.guid;
+   else if (msg->req_type == DP_SINK_EVENT_NOTIFY)
+   guid = msg->u.sink_event.guid;
 
if (guid)
mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
@@ -3948,7 +3976,8 @@ static int drm_dp_mst_handle_up_req(struct 
drm_dp_mst_topology_mgr *mgr)
drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg);
 
if (up_req->msg.req_type != DP_CONNECTION_STATUS_NOTIFY &&
-   up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY) {
+   up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY &&
+   up_req->msg.req_type != DP_SINK_EVENT_NOTIFY) {
DRM_DEBUG_KMS("Received unknown up req type, ignoring: %x\n",
  up_req->msg.req_type);
kfree(up_req);
@@ -3976,6 +4005,12 @@ static int drm_dp_mst_handle_up_req(struct 
drm_dp_mst_topology_mgr *mgr)
DRM_DEBUG_KMS("Got RSN: pn: %d avail_pbn %d\n",
  res_stat->port_number,
  res_stat->available_pbn);
+   } else if (up_req->msg.req_type == DP_SINK_EVENT_NOTIFY) {
+   const struct drm_dp_sink_event_notify *sink_event =
+   &up_req->msg.u.sink_event;
+
+   DRM_DEBUG_KMS("Got SEN: pn: %d event_id %d\n",
+ sink_event->port_number, sink_event->event_id);
}
 
up_req->hdr = mgr->up_req_recv.initial_hdr;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 6ae5860d8644..c7c79e0ced18 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -402,6 +402,19 @@ struct drm_dp_resource_status_notify {
u16 available_pbn;
 };
 
+#define DP_SINK_EVENT_PANEL_REPLAY_ACTIVE_FRAME_CRC_ERROR  BIT(0)
+#define DP_SINK_EVENT_PANEL_REPLAY_RFB_STORAGE_ERROR   BIT(1)
+#define DP_SINK_EVENT_DSC_RC_BUFFER_UNDER_RUN  BIT(2)
+#define DP_SINK_EVENT_DSC_RC_BUFFER_OVERFLOW   BIT(3)
+#define DP_SINK_EVENT_DSC_CHUNK_LENGTH_ERROR   BIT(4)
+#define DP_SINK_EVENT_CEC_IRQ_EVENTBIT(5)
+
+struct drm_dp_sink_event_notify {
+   u8 port_number;
+   u8 guid[16];
+   u16 event_id;
+};
+
 struct drm_dp_query_payload_ack_reply {
u8 port_number;
u16 allocated_pbn;
@@ -413,6 +426,7 @@ struct drm_dp_sideband_msg_req_body {
struct drm_dp_connection_status_notify conn_stat;
struct drm_dp_port_number_req po

[PATCH v2 4/4] drm_dp_cec: add MST support

[Sam McNally]

With DP v2.0 errata E5, CEC tunneling can be supported through an MST
topology.

There are some minor differences for CEC tunneling through an MST
topology compared to CEC tunneling to an SST port:
- CEC IRQs are delivered via a sink event notify message
- CEC-related DPCD registers are accessed via remote DPCD reads and
  writes.

This results in the MST implementation diverging from the existing SST
implementation:
- sink event notify messages with CEC_IRQ ID set indicate CEC IRQ rather
  than ESI1
- setting edid and handling CEC IRQs, which can be triggered from
  contexts where locks held preclude HPD handling, are deferred to avoid
  remote DPCD access which would block until HPD handling is performed
  or a timeout

Register and unregister for all MST connectors, ensuring their
drm_dp_aux_cec struct won't be accessed uninitialized.

Signed-off-by: Sam McNally 
---

Changes in v2:
- Used aux->is_remote instead of aux->cec.is_mst, removing the need for
  the previous patch in the series
- Added a defensive check for null edid in the deferred set_edid work,
  in case the edid is no longer valid at that point

 drivers/gpu/drm/drm_dp_cec.c  | 69 +--
 drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++
 include/drm/drm_dp_helper.h   |  4 ++
 3 files changed, 92 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index 3ab2609f9ec7..d708fc1e273a 100644
--- a/drivers/gpu/drm/drm_dp_cec.c
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Unfortunately it turns out that we have a chicken-and-egg situation
@@ -248,6 +249,10 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux)
if (!aux->transfer)
return;
 
+   if (aux->is_remote) {
+   schedule_work(&aux->cec.mst_irq_work);
+   return;
+   }
mutex_lock(&aux->cec.lock);
if (!aux->cec.adap)
goto unlock;
@@ -276,6 +281,24 @@ static bool drm_dp_cec_cap(struct drm_dp_aux *aux, u8 
*cec_cap)
return true;
 }
 
+static void drm_dp_cec_mst_irq_work(struct work_struct *work)
+{
+   struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
+ cec.mst_irq_work);
+   struct drm_dp_mst_port *port =
+   container_of(aux, struct drm_dp_mst_port, aux);
+
+   port = drm_dp_mst_topology_get_port_validated(port->mgr, port);
+   if (!port)
+   return;
+   mutex_lock(&aux->cec.lock);
+   if (aux->cec.adap)
+   drm_dp_cec_handle_irq(aux);
+
+   mutex_unlock(&aux->cec.lock);
+   drm_dp_mst_topology_put_port(port);
+}
+
 /*
  * Called if the HPD was low for more than drm_dp_cec_unregister_delay
  * seconds. This unregisters the CEC adapter.
@@ -297,7 +320,8 @@ static void drm_dp_cec_unregister_work(struct work_struct 
*work)
  * were unchanged and just update the CEC physical address. Otherwise
  * unregister the old CEC adapter and create a new one.
  */
-void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
+static void drm_dp_cec_handle_set_edid(struct drm_dp_aux *aux,
+  const struct edid *edid)
 {
struct drm_connector *connector = aux->cec.connector;
u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
@@ -306,10 +330,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
struct edid *edid)
unsigned int num_las = 1;
u8 cap;
 
-   /* No transfer function was set, so not a DP connector */
-   if (!aux->transfer)
-   return;
-
 #ifndef CONFIG_MEDIA_CEC_RC
/*
 * CEC_CAP_RC is part of CEC_CAP_DEFAULTS, but it is stripped by
@@ -320,6 +340,7 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
struct edid *edid)
 */
cec_caps &= ~CEC_CAP_RC;
 #endif
+   cancel_work_sync(&aux->cec.mst_irq_work);
cancel_delayed_work_sync(&aux->cec.unregister_work);
 
mutex_lock(&aux->cec.lock);
@@ -375,6 +396,18 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
struct edid *edid)
 unlock:
mutex_unlock(&aux->cec.lock);
 }
+
+void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
+{
+   /* No transfer function was set, so not a DP connector */
+   if (!aux->transfer)
+   return;
+
+   if (aux->is_remote)
+   schedule_work(&aux->cec.mst_set_edid_work);
+   else
+   drm_dp_cec_handle_set_edid(aux, edid);
+}
 EXPORT_SYMBOL(drm_dp_cec_set_edid);
 
 /*
@@ -393,6 +426,8 @@ void drm_dp_cec_unset_edid(struct drm_dp_aux *aux)
goto unlock;
 
cec_phys_addr_invalidate(aux->cec.adap);
+   cancel_work_sync(&aux->cec.mst_irq_work);
+
/*
 * We're done if we want to keep the CEC device
 * (drm_dp_cec_unregister_delay is >= NEVER_UNREG_DELAY) or if the
@@ -414,6 +449,2

[PATCH v2 3/4] drm_dp_mst_topology: export two functions

[Sam McNally]

From: Hans Verkuil 

These are required for the CEC MST support.

Signed-off-by: Hans Verkuil 
Signed-off-by: Sam McNally 
---

(no changes since v1)

 drivers/gpu/drm/drm_dp_mst_topology.c | 6 ++
 include/drm/drm_dp_mst_helper.h   | 4 
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 0d753201adbd..c783a2a1c114 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -62,8 +62,6 @@ struct drm_dp_pending_up_req {
 static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
  char *buf);
 
-static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
-
 static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
 int id,
 struct drm_dp_payload *payload);
@@ -1864,7 +1862,7 @@ static void drm_dp_mst_topology_get_port(struct 
drm_dp_mst_port *port)
  * drm_dp_mst_topology_try_get_port()
  * drm_dp_mst_topology_get_port()
  */
-static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
+void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
 {
topology_ref_history_lock(port->mgr);
 
@@ -1935,7 +1933,7 @@ drm_dp_mst_topology_get_port_validated_locked(struct 
drm_dp_mst_branch *mstb,
return NULL;
 }
 
-static struct drm_dp_mst_port *
+struct drm_dp_mst_port *
 drm_dp_mst_topology_get_port_validated(struct drm_dp_mst_topology_mgr *mgr,
   struct drm_dp_mst_port *port)
 {
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index c7c79e0ced18..d036222e0d64 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -754,6 +754,10 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
   struct drm_dp_mst_topology_mgr *mgr,
   struct drm_dp_mst_port *port);
 
+struct drm_dp_mst_port *drm_dp_mst_topology_get_port_validated
+(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
+void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
+
 struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
 
 
-- 
2.28.0.526.ge36021eeef-goog

[PATCH v2 2/4] drm_dp_mst_topology: use correct AUX channel

[Sam McNally]

From: Hans Verkuil 

For adapters behind an MST hub use the correct AUX channel.

Signed-off-by: Hans Verkuil 
[sa...@chromium.org: rebased, removing redundant changes]
Signed-off-by: Sam McNally 
---

(no changes since v1)

 drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
 1 file changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 15b6cc39a754..0d753201adbd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct 
drm_dp_mst_topology_mgr *mgr,
drm_dp_mst_topology_put_port(port);
 }
 
+static ssize_t
+drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg);
+
 static struct drm_dp_mst_port *
 drm_dp_mst_add_port(struct drm_device *dev,
struct drm_dp_mst_topology_mgr *mgr,
@@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
port->port_num = port_number;
port->mgr = mgr;
port->aux.name = "DPMST";
+   mutex_init(&port->aux.hw_mutex);
+   mutex_init(&port->aux.cec.lock);
port->aux.dev = dev->dev;
port->aux.is_remote = true;
 
+   port->aux.transfer = drm_dp_mst_aux_transfer;
+
/* initialize the MST downstream port's AUX crc work queue */
drm_dp_remote_aux_init(&port->aux);
 
@@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct 
drm_dp_mst_topology_mgr *mgr,
return 0;
 }
 
+static ssize_t
+drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
+{
+   struct drm_dp_mst_port *port =
+   container_of(aux, struct drm_dp_mst_port, aux);
+   int ret;
+
+   switch (msg->request & ~DP_AUX_I2C_MOT) {
+   case DP_AUX_NATIVE_WRITE:
+   case DP_AUX_I2C_WRITE:
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
+   ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
+msg->size, msg->buffer);
+   break;
+
+   case DP_AUX_NATIVE_READ:
+   case DP_AUX_I2C_READ:
+   ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
+   msg->size, msg->buffer);
+   break;
+
+   default:
+   ret = -EINVAL;
+   break;
+   }
+
+   return ret;
+}
+
 static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8  dp_link_count)
 {
if (dp_link_bw == 0 || dp_link_count == 0)
-- 
2.28.0.526.ge36021eeef-goog

Re: [PATCH] block: Fix potential page reference leak in __bio_iov_append_get_pages()

[linmiaohe]

Johannes Thumshirn  wrote:
>On 05/09/2020 11:41, Miaohe Lin wrote:
>> When bio_add_hw_page() failed, we left page reference still held in pages.
>
>I'd add "from iov_iter_get_pages()" to the above sentence.
>

Sounds good. Will add it in v2.

>Otherwise
>Reviewed-by: Johannes Thumshirn 

Many Thanks for review.

Re: [PATCH] ARM: aspeed: g5: Do not set sirq polarity

[Joel Stanley]

On Thu, 27 Aug 2020 at 06:27, Jeremy Kerr  wrote:
>
> Hi Joel,
>
> > A feature was added to the aspeed vuart driver to configure the vuart
> > interrupt (sirq) polarity according to the LPC/eSPI strapping register.
> >
> > Systems that depend on a active low behaviour (sirq_polarity set to 0)
> > such as OpenPower boxes also use LPC, so this relationship does not
> > hold.
> >
> > The property was added for a Tyan S7106 system which is not supported
> > in the kernel tree. Should this or other systems wish to use this
> > feature of the driver they should add it to the machine specific device
> > tree.
> >
> > Fixes: c791fc76bc72 ("arm: dts: aspeed: Add vuart 
> > aspeed,sirq-polarity-sense...")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Joel Stanley 
>
> LGTM. I've tested this on the s2600st, which is strapped for eSPI. All
> good there too, as expected.
>
> Tested-by: Jeremy Kerr 
>
> and/or:
>
> Reviewed-by: Jeremy Kerr 

Thanks Jeremy. I have queued this for 5.10 and applied it to the openbmc tree.

We should also remove the code from the aspeed-vuart driver, as it is
not correct. Better would be a property that is set according to the
system's hardware design.

Cheers,

Joel

Re: [PATCHv3] soc: qcom: llcc: Support chipsets that can write to llcc registers

[Sai Prakash Ranjan]

On 2020-09-09 12:38, Stephen Boyd wrote:

Quoting Sai Prakash Ranjan (2020-09-09 00:04:00)

Hi,

On 2020-09-09 00:02, Stephen Boyd wrote:
> Quoting Sai Prakash Ranjan (2020-09-07 22:36:48)
>> From: "Isaac J. Manjarres" 
>>
>> Older chipsets may not be allowed to configure certain LLCC registers
>> as that is handled by the secure side software. However, this is not
>> the case for newer chipsets and they must configure these registers
>> according to the contents of the SCT table, while keeping in mind that
>> older targets may not have these capabilities. So add support to allow
>> such configuration of registers to enable capacity based allocation
>> and power collapse retention for capable chipsets.
>>
>> Reason for choosing capacity based allocation rather than the default
>> way based allocation is because capacity based allocation allows more
>> finer grain partition and provides more flexibility in configuration.
>> As for the retention through power collapse, it has an advantage where
>> the cache hits are more when we wake up from power collapse although
>> it does burn more power but the exact power numbers are not known at
>> the moment.
>>
>> Signed-off-by: Isaac J. Manjarres 
>> (sai: use existing config instead of dt property and commit msg
>> change)
>
> Should be the following format:
>
> [saiprakash.ran...@codeaurora.org: use existing...]
>

Hmm, is this documented somewhere because a quick grep shows
quite a few places where just the first name is added. Plus
there is already a signed-off-by line below this, so we know
that it is this 'sai' who made the extra changes.


See Documentation/process/submitting-patches.rst



Thanks, it says **prepending the description with your mail and/or 
name**.

So its either mail and/or name, but I didn't give my full name
and I don't have a strong opinion, so I can change it to include
my full mail address.



>> Signed-off-by: Sai Prakash Ranjan 
>> ---
>> diff --git a/drivers/soc/qcom/llcc-qcom.c
>> b/drivers/soc/qcom/llcc-qcom.c
>> index 429b5a60a1ba..b908656ce519 100644
>> --- a/drivers/soc/qcom/llcc-qcom.c
>> +++ b/drivers/soc/qcom/llcc-qcom.c
>> @@ -45,6 +45,9 @@
>>  #define LLCC_TRP_ATTR0_CFGn(n)(0x21000 + SZ_8 * n)
>>  #define LLCC_TRP_ATTR1_CFGn(n)(0x21004 + SZ_8 * n)
>>
>> +#define LLCC_TRP_SCID_DIS_CAP_ALLOC   0x21F00
>> +#define LLCC_TRP_PCB_ACT  0x21F04
>
> Use lowercase hex please. LLCC_COMMON_STATUS0 is using lowercase.
>

Ok

>> +
>>  #define BANK_OFFSET_STRIDE   0x8
>>
>>  /**
>> @@ -89,6 +92,7 @@ struct llcc_slice_config {
>>  struct qcom_llcc_config {
>> const struct llcc_slice_config *sct_data;
>> int size;
>> +   bool need_llcc_cfg;
>>  };
>>
>>  static const struct llcc_slice_config sc7180_data[] =  {
>> @@ -122,11 +126,13 @@ static const struct llcc_slice_config
>> sdm845_data[] =  {
>>  static const struct qcom_llcc_config sc7180_cfg = {
>> .sct_data   = sc7180_data,
>> .size   = ARRAY_SIZE(sc7180_data),
>> +   .need_llcc_cfg  = true,
>>  };
>>
>>  static const struct qcom_llcc_config sdm845_cfg = {
>> .sct_data   = sdm845_data,
>> .size   = ARRAY_SIZE(sdm845_data),
>> +   .need_llcc_cfg  = false,
>
> false is the default so just leave it out?
>

Done on purpose as I wanted to be explicit here so that
anyone reading it knows that it doesn't support configuring
in kernel. Yes the default is false but it won't hurt to be
explicit here to avoid confusion.


I fear that being explicit will mean that all SoCs will be explicit and
that's sort of useless. Does it need to be so explicit?



From what I know, the majority of the SoCs(upcoming) will have
it true so we don't have to fill them with false everywhere,
just have to do it for SDM845.



>>  };
>>
>>  static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;
>> @@ -327,6 +333,7 @@ static int qcom_llcc_cfg_program(struct
>> platform_device *pdev)
>> u32 attr0_val;
>> u32 max_cap_cacheline;
>> u32 sz;
>> +   u32 disable_cap_alloc, retain_pc;
>> int ret = 0;
>> const struct llcc_slice_config *llcc_table;
>> struct llcc_slice_desc desc;
>> @@ -369,6 +376,21 @@ static int qcom_llcc_cfg_program(struct
>> platform_device *pdev)
>> attr0_val);
>> if (ret)
>> return ret;
>> +
>> +   if (drv_data->need_llcc_config) {
>> +   disable_cap_alloc =
>> llcc_table[i].dis_cap_alloc << llcc_table[i].slice_id;
>
> Can we move u32 disable_cap_alloc, retain_pc here? That would keep it
> local to this if condition. Or make llc_table[i].slice_id into a local
> variable so the shift line isn't so long? Or make the body of this
> while
> loop a new function that takes an llcc_table[i] pointer so that lines
> are easier to read?
>

The whole function qcom_llcc_cfg_program() is just a loop so
adding another function 

linux-next: build warning after merge of the driver-core tree

[Stephen Rothwell]

Hi all,

After merging the driver-core tree, today's linux-next build produced
this warning:

drivers/mmc/host/davinci_mmc.c: In function 'davinci_mmcsd_probe':
drivers/mmc/host/davinci_mmc.c:1243:4: warning: ignoring return value of 
'dev_err_probe' declared with attribute 'warn_unused_result' [-Wunused-result]
 1243 |dev_err_probe(&pdev->dev, ret,
  |^~
 1244 |   "could not parse of data\n");
  |   

Introduced by commit

  e1f82a0dcf38 ("driver core: Annotate dev_err_probe() with __must_check")

interacting with commit

  3a35e7e1bd50 ("mmc: davinci: Simplify with dev_err_probe()")

from the mmc tree.

-- 
Cheers,
Stephen Rothwell


pgpxqvquHqAfE.pgp
Description: OpenPGP digital signature

Re: [PATCH 10/19] paride/pcd: use bdev_check_media_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> The pcd driver does not have a ->revalidate_disk method, so it can just
> use bdev_check_media_change without any additional changes.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/block/paride/pcd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/block/paride/pcd.c b/drivers/block/paride/pcd.c
> index 5124eca90e8337..70da8b86ce587d 100644
> --- a/drivers/block/paride/pcd.c
> +++ b/drivers/block/paride/pcd.c
> @@ -233,7 +233,7 @@ static int pcd_block_open(struct block_device *bdev, 
> fmode_t mode)
>   struct pcd_unit *cd = bdev->bd_disk->private_data;
>   int ret;
>  
> - check_disk_change(bdev);
> + bdev_check_media_change(bdev);
>  
>   mutex_lock(&pcd_mutex);
>   ret = cdrom_open(&cd->info, bdev, mode);
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

[Linux-kernel-mentees] [PATCH v2] Bluetooth: Fix memory leak in read_adv_mon_features()

[Peilin Ye]

read_adv_mon_features() is leaking memory. Free `rp` before returning.

Fixes: e5e1e7fd470c ("Bluetooth: Add handler of 
MGMT_OP_READ_ADV_MONITOR_FEATURES")
Reported-and-tested-by: syzbot+f7f6e564f4202d860...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f7f6e564f4202d8601c6
Signed-off-by: Peilin Ye 
---
I forgot the "Link:" tag yesterday. Sorry about that.

Change in v2:
- add a proper "Link:" tag.

 net/bluetooth/mgmt.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 5bbe71002fb9..f96251f818fc 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -4157,7 +4157,7 @@ static int read_adv_mon_features(struct sock *sk, struct 
hci_dev *hdev,
 {
struct adv_monitor *monitor = NULL;
struct mgmt_rp_read_adv_monitor_features *rp = NULL;
-   int handle;
+   int handle, err;
size_t rp_size = 0;
__u32 supported = 0;
__u16 num_handles = 0;
@@ -4192,9 +4192,13 @@ static int read_adv_mon_features(struct sock *sk, struct 
hci_dev *hdev,
if (num_handles)
memcpy(&rp->handles, &handles, (num_handles * sizeof(u16)));
 
-   return mgmt_cmd_complete(sk, hdev->id,
-MGMT_OP_READ_ADV_MONITOR_FEATURES,
-MGMT_STATUS_SUCCESS, rp, rp_size);
+   err = mgmt_cmd_complete(sk, hdev->id,
+   MGMT_OP_READ_ADV_MONITOR_FEATURES,
+   MGMT_STATUS_SUCCESS, rp, rp_size);
+
+   kfree(rp);
+
+   return err;
 }
 
 static int add_adv_patterns_monitor(struct sock *sk, struct hci_dev *hdev,
-- 
2.25.1

Re: [PATCH 11/19] gdrom: use bdev_check_media_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> The Sega GD-ROM driver does not have a ->revalidate_disk method, so it
> can just use bdev_check_media_change without any additional changes.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/cdrom/gdrom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
> index 09b0cd292720fa..9874fc1c815b53 100644
> --- a/drivers/cdrom/gdrom.c
> +++ b/drivers/cdrom/gdrom.c
> @@ -479,7 +479,7 @@ static int gdrom_bdops_open(struct block_device *bdev, 
> fmode_t mode)
>  {
>   int ret;
>  
> - check_disk_change(bdev);
> + bdev_check_media_change(bdev);
>  
>   mutex_lock(&gdrom_mutex);
>   ret = cdrom_open(gd.cd_info, bdev, mode);
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH 12/19] ide-cd: use bdev_check_media_changed

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Switch to use bdev_check_media_changed instead of check_disk_change and
> call idecd_revalidate_disk manually.  Given that idecd_revalidate_disk
> only re-reads the TOC, and we already do the same at probe time, the
> extra call into ->revalidate_disk from bdev_disk_changed is not required
> either, so stop wiring up the method.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/ide/ide-cd.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: linux-next: build failure after merge of the driver-core tree

[Greg KH]

On Wed, Sep 09, 2020 at 03:47:09PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> lib/test_firmware.c: In function 'trigger_request_platform_store':
> lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first 
> use in this function); did you mean 'efi_embedded_fw_desc'?
>   517 |  list_add(&efi_embedded_fw.list, &efi_embedded_fw_list);
>   |   ^~~~
>   |   efi_embedded_fw_desc
> lib/test_firmware.c:517:35: note: each undeclared identifier is reported only 
> once for each function it appears in
> lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared 
> (first use in this function); did you mean 'saved_efi_embedded_fw_checked'?
>   518 |  saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
>   |  ^~~
>   |  saved_efi_embedded_fw_checked
> 
> Caused by commit
> 
>   18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI systems")
> 
> I have reverted that commit for today.

Now reverted in my tree too, thanks.

greg k-h

Re: drivers: mfd: lm3533: Support for DT bindings

[Lee Jones]

On Thu, 03 Sep 2020, SUNGOLD wrote:

> Hi, I am a high school student and a Linux enthusiast and for my free time,
> I'm trying to mainline a spare device I had, it's a Xiaomi Mi 4i
> (xiaomi-ferrari), till now I've got some basic bringup (had to bring up
> touchscreen Atmel mXT336T using the downstream driver as the mainlined
> generic atmel_mxt_ts.c has no support, so committed a sin
> 
> ;)
> 
> I'm currently working on implementing backlight for my panel and it uses
> LM3533 for it's backlight and notification LEDS.
> 
> I tried to find any dt-bindings docs about it and I finally found a patch
> 
> that was rejected and I followed it in hopes of initialising the driver,
> and it didn't work out as it was not even initialising.
> 
> With me having almost no knowledge of C, I tried to understand the
> `lm3533-core.c` while reading some docs on building a linux driver, and my
> interpretation is that the driver was not written for devices that use DTS
> and it was actually written for devices that use a board config file such
> as imx arm based devices.
> 
> Now I request you to add support for devices that use DTS or I might have
> to commit another sin ;)
> 
> My Github repo 
> 
> Thanking you
> sungold
> p.s. just asking for advice and help, this is my first mail to a dev and a
> mailing list

Good morning,

Thanks for reaching out.

I think your best bet is to follow-up with Bjorn (now Cc'ed).

Keep up the good work.

Kind regards,
Lee

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

[David Hildenbrand]

On 09.09.20 09:16, Greg Kroah-Hartman wrote:
> On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote:
>> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
>> always set to 0 by hardware. This is far from beautiful (and confusing),
>> and the bit only applies to SYSRAM. So let's move it out of the
>> bus-specific (PnP) defined bits.
>>
>> We'll add another SYSRAM specific bit soon. If we ever need more bits for
>> other purposes, we can steal some from "desc", or reshuffle/regroup what we
>> have.
>>
>> Cc: Andrew Morton 
>> Cc: Michal Hocko 
>> Cc: Dan Williams 
>> Cc: Jason Gunthorpe 
>> Cc: Kees Cook 
>> Cc: Ard Biesheuvel 
>> Cc: Pankaj Gupta 
>> Cc: Baoquan He 
>> Cc: Wei Yang 
>> Cc: Eric Biederman 
>> Cc: Thomas Gleixner 
>> Cc: Greg Kroah-Hartman 
>> Cc: ke...@lists.infradead.org
>> Signed-off-by: David Hildenbrand 
>> ---
>>  include/linux/ioport.h | 4 +++-
>>  kernel/kexec_file.c| 2 +-
>>  mm/memory_hotplug.c| 4 ++--
>>  3 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
>> index 52a91f5fa1a36..d7620d7c941a0 100644
>> --- a/include/linux/ioport.h
>> +++ b/include/linux/ioport.h
>> @@ -58,6 +58,9 @@ struct resource {
>>  #define IORESOURCE_EXT_TYPE_BITS 0x0100 /* Resource extended types */
>>  #define IORESOURCE_SYSRAM   0x0100  /* System RAM (modifier) */
>>  
>> +/* IORESOURCE_SYSRAM specific bits. */
>> +#define IORESOURCE_SYSRAM_DRIVER_MANAGED0x0200 /* Always detected 
>> via a driver. */
>> +
> 
> Can't you use BIT() here?

I could, but this will make it look different to all other IORESOURCE_*
definitions?

If so, we should change all existing definitions - however the ones
spanning multiple bits might turn out rather ugly, like

#define IORESOURCE_TYPE_BITS0x1f00

Thoughts? Thanks

> 
> thanks,
> 
> greg k-h
> 


-- 
Thanks,

David / dhildenb

Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

[David Hildenbrand]

On 09.09.20 09:17, Greg Kroah-Hartman wrote:
> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
>> We soon want to pass flags, e.g., to mark added System RAM resources.
>> mergeable. Prepare for that.
> 
> What are these random "flags", and how do we know what should be passed
> to them?
> 
> Why not make this an enumerated type so that we know it all works
> properly, like the GPF_* flags are?  Passing around a random unsigned
> long feels very odd/broken...

Agreed, an enum (mhp_flags) seems to give a better hint what can
actually be passed. Thanks!

-- 
Thanks,

David / dhildenb

Re: [PATCH 13/19] ide-cd: remove idecd_revalidate_disk

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Just merge the trivial function into its only caller.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/ide/ide-cd.c | 17 +
>  1 file changed, 5 insertions(+), 12 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH v7 0/9] Add UEFI support for RISC-V

[Ard Biesheuvel]

On Wed, 9 Sep 2020 at 04:16, Palmer Dabbelt  wrote:
>
> On Fri, 28 Aug 2020 10:20:27 PDT (-0700), Atish Patra wrote:
> > This series adds UEFI support for RISC-V.
> >
> > Linux kernel: v5.9-rc2
> > U-Boot: v2020.07
> > OpenSBI: master
> >
> > Patch 1-3 are generic riscv feature addition required for UEFI support.
> > Patch 4-7 adds the efi stub support for RISC-V which was reviewed few 
> > months back.
> > https://www.spinics.net/lists/linux-efi/msg19144.html
> > Patch 8 just renames arm-init code so that it can be used across different
> > architectures.
> > Patch 9 adds the runtime services for RISC-V.
> >
> > The working set of patches can also be found in following git repo.
> > https://github.com/atishp04/linux/tree/uefi_riscv_5.10_v7
> >
> > The patches have been verified on following platforms:
> > 1. Qemu (both RV32 & RV64) for the following bootflow
> >OpenSBI->U-Boot->Linux
> >EDK2->Linux
> > 2. HiFive unleashed using (RV64) for the following bootflow
> >OpenSBI->U-Boot->Linux
> >EDK2->Linux
> >
> > Thanks Abner & Daniel for all work done for EDK2.
> > The EDK2 instructions are available here.
> > https://github.com/JohnAZoidberg/riscv-edk2-docker/
> >
> > Note:
> > 1. Currently, EDK2 RISC-V port doesn't support OVMF package. That's why
> > EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER should be enabled to load initrd via
> > commandline until OVMF patches are available.
> >
> > 2. For RV32, maximum allocated memory should be 1G as RISC-V kernel can not 
> > map
> > beyond 1G of physical memory for RV32.
> >
> > 3. Runtime services have been verified with fwts on EDK2.
> >
> > ***
> > [root@fedora-riscv ~]# fwts uefirtvariable
> > Running 1 tests, results appended to results.log
> > Test: UEFI Runtime service variable interface tests.
> >   Test UEFI RT service get variable interface.1 passed
> >   Test UEFI RT service get next variable name interface.  4 passed
> >   Test UEFI RT service set variable interface.7 passed, 1 
> > warning
> >   Test UEFI RT service query variable info interface. 1 passed
> >   Test UEFI RT service variable interface stress test.2 passed
> >   Test UEFI RT service set variable interface stress t..  4 passed
> >   Test UEFI RT service query variable info interface s..  1 passed
> >   Test UEFI RT service get variable interface, invalid..  5 passed
> >   Test UEFI RT variable services supported status.1 skipped
> >
> > Test   |Pass |Fail |Abort|Warn |Skip |Info |
> > uefirtvariable |   25| | |1|1| |
> > Total: |   25|0|0|1|1|0|
> >
> > ***
> >
> > Changes from v6->v7:
> > 1. Fixed build error reported on linux-next for patch2.
> >
> > Changes from v5->v6:
> > 1. Fixed the static declaration for pt_ops.
> > 2. Added Reviewed/Acked-by.
> >
> > Changes from v4->v5:
> > 1. Late mappings allocations are now done through function pointers.
> > 2. EFI run time services are verified using full linux boot and fwts using 
> > EDK2.
> >
> > Changes from v3->v4:
> > 1. Used pgd mapping to avoid copying DT to bss.
> >
> > Changes from v2->v3:
> > 1. Fixed few bugs in run time services page table mapping.
> > 2. Dropped patch 1 as it is already taken into efi-tree.
> > 3. Sent few generic mmu fixes as a separate series to ease the merge 
> > conflicts.
> >
> > Changes from v1->v2:
> > 1. Removed patch 1 as it is already taken into efi-tree.
> > 2. Fixed compilation issues with patch 9.
> > 3. Moved few function prototype declaration to header file to keep kbuild 
> > happy.
> >
> > Changes from previous version:
> > 1. Added full ioremap support.
> > 2. Added efi runtime services support.
> > 3. Fixes mm issues
> >
> > Anup Patel (1):
> > RISC-V: Move DT mapping outof fixmap
> >
> > Atish Patra (8):
> > RISC-V: Add early ioremap support
> > RISC-V: Implement late mapping page table allocation functions
> > include: pe.h: Add RISC-V related PE definition
> > RISC-V: Add PE/COFF header for EFI stub
> > RISC-V: Add EFI stub support.
> > efi: Rename arm-init to efi-init common for all arch
> > RISC-V: Add EFI runtime services
> > RISC-V: Add page table dump support for uefi
> >
> > arch/riscv/Kconfig|  25 +++
> > arch/riscv/Makefile   |   1 +
> > arch/riscv/configs/defconfig  |   1 +
> > arch/riscv/include/asm/Kbuild |   1 +
> > arch/riscv/include/asm/efi.h  |  56 +
> > arch/riscv/include/asm/fixmap.h   |  16 +-
> > arch/riscv/include/asm/io.h   |   1 +
> > arch/riscv/include/asm/mmu.h  |   2 +
> > arch/riscv/include/asm/pgtable.h  |   5 +
> > arch/riscv/include/asm/sections.h |  13 ++
> > arch/riscv/kernel/Makefile|   5 +
> > arch/riscv/kernel/efi-header.S

Re: [PATCH] rtl8xxxu: prevent potential memory leak

[Kalle Valo]

Chris Chiu  wrote:

> Free the skb if usb_submit_urb fails on rx_urb. And free the urb
> no matter usb_submit_urb succeeds or not in rtl8xxxu_submit_int_urb.
> 
> Signed-off-by: Chris Chiu 

Patch applied to wireless-drivers-next.git, thanks.

86279456a4d4 rtl8xxxu: prevent potential memory leak

-- 
https://patchwork.kernel.org/patch/11759447/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] mwifiex: remove function pointer check

[Kalle Valo]

t...@redhat.com wrote:

> From: Tom Rix 
> 
> clang static analyzer reports this problem
> 
> init.c:739:8: warning: Called function pointer
>   is null (null dereference)
> ret = adapter->if_ops.check_fw_status( ...
>   ^
> 
> In mwifiex_dnld_fw, there is an earlier check for check_fw_status(),
> The check was introduced for usb support at the same time this
> check in _mwifiex_fw_dpc() was made
> 
>   if (adapter->if_ops.dnld_fw) {
>   ret = adapter->if_ops.dnld_fw(adapter, &fw);
>   } else {
>   ret = mwifiex_dnld_fw(adapter, &fw);
>   }
> 
> And a dnld_fw function initialized as part the usb's
> mwifiex_if_ops.
> 
> The other instances of mwifiex_if_ops for pci and sdio
> both set check_fw_status.
> 
> So the first check is not needed and can be removed.
> 
> Fixes: 4daffe354366 ("mwifiex: add support for Marvell USB8797 chipset")
> Signed-off-by: Tom Rix 
> Reviewed-by: Nathan Chancellor 

Patch applied to wireless-drivers-next.git, thanks.

eb2c6ca2db8c mwifiex: remove function pointer check

-- 
https://patchwork.kernel.org/patch/11759719/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 1/3] dt-bindings: phy: amlogic,meson-axg-mipi-pcie-analog: remove reg attribute

[Neil Armstrong]

Hi,

On 08/09/2020 21:50, Rob Herring wrote:
> On Mon, Sep 07, 2020 at 09:34:00AM +0200, Neil Armstrong wrote:
>> The Amlogic AXG MIPI + PCIe Analog PHY should be a subnode of the hhi mfd
>> node like the axg-clkc node.
>>
>> Thus the reg attribute is not needed.
> 
> If the phy registers have an address then it should remain even if Linux 
> happens to not care. The exception is if the registers are all 
> interleaved with other stuff.

This is not really a question about linux using it or not.

The PHY registers happens to be at the beginning of a large zone containing
interleaved system registers (mainly clocks, power management, PHY control..).

The goal is to model it the same way as the other "features" of this zone,
like Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
and Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml
and have a coherent bindings scheme.

Neil

> 
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  .../bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml  | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
>>  
>> b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
>> index 18c1ec5e19ad..a9040aa387cf 100644
>> --- 
>> a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
>> +++ 
>> b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
>> @@ -13,15 +13,11 @@ properties:
>>compatible:
>>  const: amlogic,axg-mipi-pcie-analog-phy
>>  
>> -  reg:
>> -maxItems: 1
>> -
>>"#phy-cells":
>>  const: 1
>>  
>>  required:
>>- compatible
>> -  - reg
>>- "#phy-cells"
>>  
>>  additionalProperties: false
>> -- 
>> 2.22.0
>>

Re: [PATCH v4 2/2] mfd: intel-m10-bmc: add Max10 BMC chip support for Intel FPGA PAC

[Lee Jones]

On Wed, 09 Sep 2020, Xu Yilun wrote:

> > > > > + * m10bmc_raw_read - read m10bmc register per addr
> > > > > + * m10bmc_sys_read - read m10bmc system register per offset
> > > > > + */
> > > > > +static inline int
> > > > > +m10bmc_raw_read(struct intel_m10bmc *m10bmc, unsigned int addr,
> > > > > + unsigned int *val)
> > > > > +{
> > > > > + int ret;
> > > > > +
> > > > > + ret = regmap_read(m10bmc->regmap, addr, val);
> > > > > + if (ret)
> > > > > + dev_err(m10bmc->dev, "fail to read raw reg %x: %d\n",
> > > > > + addr, ret);
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +#define m10bmc_sys_read(m10bmc, offset, val) \
> > > > > + m10bmc_raw_read(m10bmc, M10BMC_SYS_BASE + (offset), val)
> > > > 
> > > > No unnecessary abstractions.
> > > > 
> > > > Just use the Regmap API directly please.
> > > 
> > > Could we keep the 2 definition?
> > > 
> > > For m10bmc_raw_read(), we make it to help print some error info if
> > > regmap RW fail. So we don't have to write "if (ret) dev_err" every time
> > > we use regmap.
> > 
> > How many call sites are there?
> 
> There are about 20 calls of the register read in m10bmc base driver and
> sub device drivers. Most of them calls m10bmc_sys_read().
> I prefer to keep the function for unified error log, but I'm also good
> to follow your opinion. How do you think?

Avoidable abstraction is one of my pet hates.  However,
unified/centralised error handling is a valid(ish) reason for
abstraction to exist.  Do you really need to know which read failed?
Is there a case where a read from only a particular register would
fail where others succeed?

> I also realize that it is not necessary that we define so many
> m10bmc_raw_bulk_read/bulk_write/update_bits ... which are not frequently
> used. We could change them.

Yes please.

> > > For m10bmc_sys_read(), the offset of BMC system registers could be
> > > configured by HW developers (The MAX 10 is an CPLD, it could be easily
> > > reprogrammed). And the HW SPEC will not add the offset when describing
> > > the addresses of system registers. So:
> > > 1. It makes the definition of system registers in code align with HW SPEC.
> > > 2. It makes developers easier to make changes when the offset is adjusted
> > >in HW (I've been told by HW guys, it is sometimes necessary to adjust
> > >the offset when changing RTL, required by Altera EDA tool - Quartus).
> > 
> > Make sure you justify this for the function(s) you keep.
> 
> Yes, I could add some comments.
> 
> Thanks,
> Yilun

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2] brcmsmac: fix memory leak in wlc_phy_attach_lcnphy

[Kalle Valo]

Keita Suzuki  wrote:

> When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy,
> the allocated pi->u.pi_lcnphy is leaked, since struct brcms_phy will be
> freed in the caller function.
> 
> Fix this by calling wlc_phy_detach_lcnphy in the error handler of
> wlc_phy_txpwr_srom_read_lcnphy before returning.
> 
> Signed-off-by: Keita Suzuki 

Patch applied to wireless-drivers-next.git, thanks.

f4443293d741 brcmsmac: fix memory leak in wlc_phy_attach_lcnphy

-- 
https://patchwork.kernel.org/patch/11763749/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 14/19] ide-gd: stop using the disk events mechanism

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> ide-gd is only using the disk events mechanism to be able to force an
> invalidation and partition scan on opening removable media.  Just open
> code the logic without invoving the block layer.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/ide/ide-disk.c   |  5 +
>  drivers/ide/ide-floppy.c |  2 --
>  drivers/ide/ide-gd.c | 48 +---
>  include/linux/ide.h  |  2 --
>  4 files changed, 7 insertions(+), 50 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH v2] rtlwifi: switch from 'pci_' to 'dma_' API

[Kalle Valo]

Christophe JAILLET  wrote:

> The wrappers in include/linux/pci-dma-compat.h should go away.
> 
> The patch has been generated with the coccinelle script below and has been
> hand modified to replace GFP_ with a correct flag.
> It has been compile tested.
> 
> The only file where some GFP_ flags are updated is 'pci.c'.
> 
> When memory is allocated in '_rtl_pci_init_tx_ring()' and
> '_rtl_pci_init_rx_ring()' GFP_KERNEL can be used because both functions are
> called from a probe function and no spinlock is taken.
> 
> The call chain is:
>   rtl_pci_probe
> --> rtl_pci_init
>   --> _rtl_pci_init_trx_ring
> --> _rtl_pci_init_rx_ring
> --> _rtl_pci_init_tx_ring
> 
> 
> @@
> @@
> -PCI_DMA_BIDIRECTIONAL
> +DMA_BIDIRECTIONAL
> 
> @@
> @@
> -PCI_DMA_TODEVICE
> +DMA_TO_DEVICE
> 
> @@
> @@
> -PCI_DMA_FROMDEVICE
> +DMA_FROM_DEVICE
> 
> @@
> @@
> -PCI_DMA_NONE
> +DMA_NONE
> 
> @@
> expression e1, e2, e3;
> @@
> -pci_alloc_consistent(e1, e2, e3)
> +dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
> 
> @@
> expression e1, e2, e3;
> @@
> -pci_zalloc_consistent(e1, e2, e3)
> +dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
> 
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_free_consistent(e1, e2, e3, e4)
> +dma_free_coherent(&e1->dev, e2, e3, e4)
> 
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_map_single(e1, e2, e3, e4)
> +dma_map_single(&e1->dev, e2, e3, e4)
> 
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_unmap_single(e1, e2, e3, e4)
> +dma_unmap_single(&e1->dev, e2, e3, e4)
> 
> @@
> expression e1, e2, e3, e4, e5;
> @@
> -pci_map_page(e1, e2, e3, e4, e5)
> +dma_map_page(&e1->dev, e2, e3, e4, e5)
> 
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_unmap_page(e1, e2, e3, e4)
> +dma_unmap_page(&e1->dev, e2, e3, e4)
> 
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_map_sg(e1, e2, e3, e4)
> +dma_map_sg(&e1->dev, e2, e3, e4)
> 
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_unmap_sg(e1, e2, e3, e4)
> +dma_unmap_sg(&e1->dev, e2, e3, e4)
> 
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
> +dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
> 
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_dma_sync_single_for_device(e1, e2, e3, e4)
> +dma_sync_single_for_device(&e1->dev, e2, e3, e4)
> 
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
> +dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
> 
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_dma_sync_sg_for_device(e1, e2, e3, e4)
> +dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
> 
> @@
> expression e1, e2;
> @@
> -pci_dma_mapping_error(e1, e2)
> +dma_mapping_error(&e1->dev, e2)
> 
> @@
> expression e1, e2;
> @@
> -pci_set_dma_mask(e1, e2)
> +dma_set_mask(&e1->dev, e2)
> 
> @@
> expression e1, e2;
> @@
> -pci_set_consistent_dma_mask(e1, e2)
> +dma_set_coherent_mask(&e1->dev, e2)
> 
> Signed-off-by: Christophe JAILLET 

Patch applied to wireless-drivers-next.git, thanks.

0dc0b5c29be2 rtlwifi: switch from 'pci_' to 'dma_' API

-- 
https://patchwork.kernel.org/patch/11762141/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH v3 03/11] usb: gadget: bdc: prefer pointer dereference to pointer type

[Chunfeng Yun]

Prefer kzalloc(sizeof(*bd_table)...) over
kzalloc(sizeof(struct bd_table)

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc_ep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c 
b/drivers/usb/gadget/udc/bdc/bdc_ep.c
index fafdc9f..76463de 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_ep.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_ep.c
@@ -147,7 +147,7 @@ static int ep_bd_list_alloc(struct bdc_ep *ep)
/* Allocate memory for each table */
for (index = 0; index < num_tabs; index++) {
/* Allocate memory for bd_table structure */
-   bd_table = kzalloc(sizeof(struct bd_table), GFP_ATOMIC);
+   bd_table = kzalloc(sizeof(*bd_table), GFP_ATOMIC);
if (!bd_table)
goto fail;
 
-- 
1.9.1

[PATCH v3 06/11] usb: gadget: bdc: add identifier name for function declaraion

[Chunfeng Yun]

This is used to avoid the warning of function arguments, e.g.
  WARNING:FUNCTION_ARGUMENTS: function definition argument 'u32'
  should also have an identifier name

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc.h | 28 ++--
 drivers/usb/gadget/udc/bdc/bdc_cmd.h | 18 +-
 drivers/usb/gadget/udc/bdc/bdc_dbg.h |  8 
 drivers/usb/gadget/udc/bdc/bdc_ep.h  |  8 
 4 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc.h b/drivers/usb/gadget/udc/bdc/bdc.h
index c0ee735..658abef 100644
--- a/drivers/usb/gadget/udc/bdc/bdc.h
+++ b/drivers/usb/gadget/udc/bdc/bdc.h
@@ -466,24 +466,24 @@ static inline void bdc_writel(void __iomem *base, u32 
offset, u32 value)
 }
 
 /* Buffer descriptor list operations */
-void bdc_notify_xfr(struct bdc *, u32);
-void bdc_softconn(struct bdc *);
-void bdc_softdisconn(struct bdc *);
-int bdc_run(struct bdc *);
-int bdc_stop(struct bdc *);
-int bdc_reset(struct bdc *);
-int bdc_udc_init(struct bdc *);
-void bdc_udc_exit(struct bdc *);
-int bdc_reinit(struct bdc *);
+void bdc_notify_xfr(struct bdc *bdc, u32 epnum);
+void bdc_softconn(struct bdc *bdc);
+void bdc_softdisconn(struct bdc *bdc);
+int bdc_run(struct bdc *bdc);
+int bdc_stop(struct bdc *bdc);
+int bdc_reset(struct bdc *bdc);
+int bdc_udc_init(struct bdc *bdc);
+void bdc_udc_exit(struct bdc *bdc);
+int bdc_reinit(struct bdc *bdc);
 
 /* Status report handlers */
 /* Upstream port status change sr */
-void bdc_sr_uspc(struct bdc *, struct bdc_sr *);
+void bdc_sr_uspc(struct bdc *bdc, struct bdc_sr *sreport);
 /* transfer sr */
-void bdc_sr_xsf(struct bdc *, struct bdc_sr *);
+void bdc_sr_xsf(struct bdc *bdc, struct bdc_sr *sreport);
 /* EP0 XSF handlers */
-void bdc_xsf_ep0_setup_recv(struct bdc *, struct bdc_sr *);
-void bdc_xsf_ep0_data_start(struct bdc *, struct bdc_sr *);
-void bdc_xsf_ep0_status_start(struct bdc *, struct bdc_sr *);
+void bdc_xsf_ep0_setup_recv(struct bdc *bdc, struct bdc_sr *sreport);
+void bdc_xsf_ep0_data_start(struct bdc *bdc, struct bdc_sr *sreport);
+void bdc_xsf_ep0_status_start(struct bdc *bdc, struct bdc_sr *sreport);
 
 #endif /* __LINUX_BDC_H__ */
diff --git a/drivers/usb/gadget/udc/bdc/bdc_cmd.h 
b/drivers/usb/gadget/udc/bdc/bdc_cmd.h
index a3a6dbd..533ad52 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_cmd.h
+++ b/drivers/usb/gadget/udc/bdc/bdc_cmd.h
@@ -10,14 +10,14 @@
 #define __LINUX_BDC_CMD_H__
 
 /* Command operations */
-int bdc_address_device(struct bdc *, u32);
-int bdc_config_ep(struct bdc *, struct bdc_ep *);
-int bdc_dconfig_ep(struct bdc *, struct bdc_ep *);
-int bdc_stop_ep(struct bdc *, int);
-int bdc_ep_set_stall(struct bdc *, int);
-int bdc_ep_clear_stall(struct bdc *, int);
-int bdc_ep_bla(struct bdc *, struct bdc_ep *, dma_addr_t);
-int bdc_function_wake(struct bdc*, u8);
-int bdc_function_wake_fh(struct bdc*, u8);
+int bdc_address_device(struct bdc *bdc, u32 add);
+int bdc_config_ep(struct bdc *bdc, struct bdc_ep *ep);
+int bdc_dconfig_ep(struct bdc *bdc, struct bdc_ep *ep);
+int bdc_stop_ep(struct bdc *bdc, int epnum);
+int bdc_ep_set_stall(struct bdc *bdc, int epnum);
+int bdc_ep_clear_stall(struct bdc *bdc, int epnum);
+int bdc_ep_bla(struct bdc *bdc, struct bdc_ep *ep, dma_addr_t dma_addr);
+int bdc_function_wake(struct bdc *bdc, u8 intf);
+int bdc_function_wake_fh(struct bdc *bdc, u8 intf);
 
 #endif /* __LINUX_BDC_CMD_H__ */
diff --git a/drivers/usb/gadget/udc/bdc/bdc_dbg.h 
b/drivers/usb/gadget/udc/bdc/bdc_dbg.h
index 859d588..acd8332 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_dbg.h
+++ b/drivers/usb/gadget/udc/bdc/bdc_dbg.h
@@ -12,10 +12,10 @@
 #include "bdc.h"
 
 #ifdef CONFIG_USB_GADGET_VERBOSE
-void bdc_dbg_bd_list(struct bdc *, struct bdc_ep*);
-void bdc_dbg_srr(struct bdc *, u32);
-void bdc_dbg_regs(struct bdc *);
-void bdc_dump_epsts(struct bdc *);
+void bdc_dbg_bd_list(struct bdc *bdc, struct bdc_ep *ep);
+void bdc_dbg_srr(struct bdc *bdc, u32 srr_num);
+void bdc_dbg_regs(struct bdc *bdc);
+void bdc_dump_epsts(struct bdc *bdc);
 #else
 static inline void bdc_dbg_regs(struct bdc *bdc)
 { }
diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.h 
b/drivers/usb/gadget/udc/bdc/bdc_ep.h
index 5bbd73f..4d3affd 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_ep.h
+++ b/drivers/usb/gadget/udc/bdc/bdc_ep.h
@@ -9,9 +9,9 @@
 #ifndef __LINUX_BDC_EP_H__
 #define __LINUX_BDC_EP_H__
 
-int bdc_init_ep(struct bdc *);
-int bdc_ep_disable(struct bdc_ep *);
-int bdc_ep_enable(struct bdc_ep *);
-void bdc_free_ep(struct bdc *);
+int bdc_init_ep(struct bdc *bdc);
+int bdc_ep_disable(struct bdc_ep *ep);
+int bdc_ep_enable(struct bdc_ep *ep);
+void bdc_free_ep(struct bdc *bdc);
 
 #endif /* __LINUX_BDC_EP_H__ */
-- 
1.9.1

[PATCH v3 02/11] usb: gadget: bdc: remove bdc_ep_set_halt() declaration

[Chunfeng Yun]

No definition for bdc_ep_set_halt(), so remove it.

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc_cmd.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_cmd.h 
b/drivers/usb/gadget/udc/bdc/bdc_cmd.h
index 373e674..a3a6dbd 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_cmd.h
+++ b/drivers/usb/gadget/udc/bdc/bdc_cmd.h
@@ -16,7 +16,6 @@
 int bdc_stop_ep(struct bdc *, int);
 int bdc_ep_set_stall(struct bdc *, int);
 int bdc_ep_clear_stall(struct bdc *, int);
-int bdc_ep_set_halt(struct bdc_ep *, u32 , int);
 int bdc_ep_bla(struct bdc *, struct bdc_ep *, dma_addr_t);
 int bdc_function_wake(struct bdc*, u8);
 int bdc_function_wake_fh(struct bdc*, u8);
-- 
1.9.1

[PATCH v3 05/11] usb: gadget: bdc: fix check warning of block comments alignment

[Chunfeng Yun]

fix the warning:
  WARNING:BLOCK_COMMENT_STYLE:
  Block comments should align the * on each line

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc.h | 2 +-
 drivers/usb/gadget/udc/bdc/bdc_ep.c  | 2 +-
 drivers/usb/gadget/udc/bdc/bdc_udc.c | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc.h b/drivers/usb/gadget/udc/bdc/bdc.h
index fcba77e..c0ee735 100644
--- a/drivers/usb/gadget/udc/bdc/bdc.h
+++ b/drivers/usb/gadget/udc/bdc/bdc.h
@@ -35,7 +35,7 @@
 /*
  * Maximum size of ep0 response buffer for ch9 requests,
  * the set_sel request uses 6 so far, the max.
-*/
+ */
 #define EP0_RESPONSE_BUFF  6
 /* Start with SS as default */
 #define EP0_MAX_PKT_SIZE 512
diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c 
b/drivers/usb/gadget/udc/bdc/bdc_ep.c
index 44f3a12..3fb36c8 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_ep.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_ep.c
@@ -68,7 +68,7 @@ static void ep_bd_list_free(struct bdc_ep *ep, u32 num_tabs)
 * check if the bd_table struct is allocated ?
 * if yes, then check if bd memory has been allocated, then
 * free the dma_pool and also the bd_table struct memory
-   */
+*/
bd_table = bd_list->bd_table_array[index];
dev_dbg(bdc->dev, "bd_table:%p index:%d\n", bd_table, index);
if (!bd_table) {
diff --git a/drivers/usb/gadget/udc/bdc/bdc_udc.c 
b/drivers/usb/gadget/udc/bdc/bdc_udc.c
index 248426a..0c1ab95 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_udc.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_udc.c
@@ -164,7 +164,7 @@ static void bdc_func_wake_timer(struct work_struct *work)
/*
 * Check if host has started transferring on endpoints
 * FUNC_WAKE_ISSUED is cleared when transfer has started after resume
-   */
+*/
if (bdc->devstatus & FUNC_WAKE_ISSUED) {
dev_dbg(bdc->dev, "FUNC_WAKE_ISSUED FLAG IS STILL SET\n");
/* flag is still set, so again send func wake */
@@ -205,7 +205,7 @@ static void handle_link_state_change(struct bdc *bdc, u32 
uspc)
 * if not then send function wake again every
 * TNotification secs until host initiates
 * transfer to BDC, USB3 spec Table 8.13
-   */
+*/
schedule_delayed_work(
&bdc->func_wake_notify,
msecs_to_jiffies(BDC_TNOTIFY));
@@ -379,7 +379,7 @@ static int bdc_udc_start(struct usb_gadget *gadget,
 * Run the controller from here and when BDC is connected to
 * Host then driver will receive a USPC SR with VBUS present
 * and then driver will do a softconnect.
-   */
+*/
ret = bdc_run(bdc);
if (ret) {
dev_err(bdc->dev, "%s bdc run fail\n", __func__);
-- 
1.9.1

[PATCH v3 08/11] usb: gadget: bdc: use the BIT macro to define bit filed

[Chunfeng Yun]

Prefer using the BIT macro to define bit fileds

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc.h | 84 
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc.h b/drivers/usb/gadget/udc/bdc/bdc.h
index f8d5958..8d00b12 100644
--- a/drivers/usb/gadget/udc/bdc/bdc.h
+++ b/drivers/usb/gadget/udc/bdc/bdc.h
@@ -102,7 +102,7 @@
 #define BDC_SPB(p) ((p) & 0x7)
 
 /* BDC Capability1 */
-#define BDC_P64(1 << 0)
+#define BDC_P64BIT(0)
 
 /* BDC Command register */
 #define BDC_CMD_FH 0xe
@@ -111,7 +111,7 @@
 #define BDC_CMD_BLA0x3
 #define BDC_CMD_EPC0x2
 #define BDC_CMD_DVC0x1
-#define BDC_CMD_CWS(0x1 << 5)
+#define BDC_CMD_CWSBIT(5)
 #define BDC_CMD_CST(p) (((p) & (0xf << 6))>>6)
 #define BDC_CMD_EPN(p) (((p) & 0x1f) << 10)
 #define BDC_SUB_CMD_ADD(0x1 << 17)
@@ -124,7 +124,7 @@
 #define BDC_SUB_CMD_EP_STP (0x2 << 17)
 #define BDC_SUB_CMD_EP_STL (0x4 << 17)
 #define BDC_SUB_CMD_EP_RST (0x1 << 17)
-#define BDC_CMD_SRD(1 << 27)
+#define BDC_CMD_SRDBIT(27)
 
 /* CMD completion status */
 #define BDC_CMDS_SUCC  0x1
@@ -141,19 +141,19 @@
 #define EPM_SHIFT  4
 
 /* BDC USPSC */
-#define BDC_VBC(1 << 31)
-#define BDC_PRC(1 << 30)
-#define BDC_PCE(1 << 29)
-#define BDC_CFC(1 << 28)
-#define BDC_PCC(1 << 27)
-#define BDC_PSC(1 << 26)
-#define BDC_VBS(1 << 25)
-#define BDC_PRS(1 << 24)
-#define BDC_PCS(1 << 23)
+#define BDC_VBCBIT(31)
+#define BDC_PRCBIT(30)
+#define BDC_PCEBIT(29)
+#define BDC_CFCBIT(28)
+#define BDC_PCCBIT(27)
+#define BDC_PSCBIT(26)
+#define BDC_VBSBIT(25)
+#define BDC_PRSBIT(24)
+#define BDC_PCSBIT(23)
 #define BDC_PSP(p) (((p) & (0x7 << 20))>>20)
-#define BDC_SCN(1 << 8)
-#define BDC_SDC(1 << 7)
-#define BDC_SWS(1 << 4)
+#define BDC_SCNBIT(8)
+#define BDC_SDCBIT(7)
+#define BDC_SWSBIT(4)
 
 #define BDC_USPSC_RW   (BDC_SCN|BDC_SDC|BDC_SWS|0xf)
 #define BDC_PSP(p) (((p) & (0x7 << 20))>>20)
@@ -167,17 +167,17 @@
 #define BDC_PST_MASK   0xf
 
 /* USPPMS */
-#define BDC_U2E(0x1 << 31)
-#define BDC_U1E(0x1 << 30)
-#define BDC_U2A(0x1 << 29)
-#define BDC_PORT_W1S   (0x1 << 17)
+#define BDC_U2EBIT(31)
+#define BDC_U1EBIT(30)
+#define BDC_U2ABIT(29)
+#define BDC_PORT_W1S   BIT(17)
 #define BDC_U1T(p) ((p) & 0xff)
 #define BDC_U2T(p) (((p) & 0xff) << 8)
 #define BDC_U1T_MASK   0xff
 
 /* USBPM2 */
 /* Hardware LPM Enable */
-#define BDC_HLE(1 << 16)
+#define BDC_HLEBIT(16)
 
 /* BDC Status and Control */
 #define BDC_COP_RST(1 << 29)
@@ -186,11 +186,11 @@
 
 #define BDC_COP_MASK (BDC_COP_RST|BDC_COP_RUN|BDC_COP_STP)
 
-#define BDC_COS(1 << 28)
+#define BDC_COSBIT(28)
 #define BDC_CSTS(p)(((p) & (0x7 << 20)) >> 20)
-#define BDC_MASK_MCW   (1 << 7)
-#define BDC_GIE(1 << 1)
-#define BDC_GIP(1 << 0)
+#define BDC_MASK_MCW   BIT(7)
+#define BDC_GIEBIT(1)
+#define BDC_GIPBIT(0)
 
 #define BDC_HLT1
 #define BDC_NOR2
@@ -201,19 +201,19 @@
 #define BD_CHAIN   0xf
 
 #define BD_TFS_SHIFT   4
-#define BD_SOT (1 << 26)
-#define BD_EOT (1 << 27)
-#define BD_ISP (1 << 29)
-#define BD_IOC (1 << 30)
-#define BD_SBF (1 << 31)
+#define BD_SOT BIT(26)
+#define BD_EOT BIT(27)
+#define BD_ISP BIT(29)
+#define BD_IOC BIT(30)
+#define BD_SBF BIT(31)
 
 #define BD_INTR_TARGET(p)  (((p) & 0x1f) << 27)
 
-#define BDC_SRR_RWS(1 << 4)
-#define BDC_SRR_RST(1 << 3)
-#define BDC_SRR_ISR(1 << 2)
-#define BDC_SRR_IE (1 << 1)
-#define BDC_SRR_IP (1 << 0)
+#define BDC_SRR_RWSBIT(4)
+#define BDC_SRR_RSTBIT(3)
+#define BDC_SRR_ISRBIT(2)
+#define BDC_SRR_IE BIT(1)
+#define BDC_SRR_IP BIT(0)
 #define BDC_SRR_EPI(p) (((p) & (0xff << 24)) >> 24)
 #define BDC_SRR_DPI(p) (((p) & (0xff << 16)) >> 16)
 #define BDC_SRR_DPI_MASK   0x00ff
@@ -221,7 +221,7 @@
 #define MARK_CHAIN_BD  (BD_CHAIN|BD_EOT|BD_SOT)
 
 /* Control transfer BD specific fields */
-#define BD_DIR_IN  (1 << 25)
+#define BD_DIR_IN  BIT(25)
 
 #define BDC_PTC_MASK   0xf000
 
@@ 

[PATCH v3 04/11] usb: gadget: bdc: fix warning of embedded function name

[Chunfeng Yun]

Use '"%s...", __func__' to replace embedded function name

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc_dbg.c | 2 +-
 drivers/usb/gadget/udc/bdc/bdc_ep.c  | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_dbg.c 
b/drivers/usb/gadget/udc/bdc/bdc_dbg.c
index 7ba7448..9c03e13 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_dbg.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_dbg.c
@@ -68,7 +68,7 @@ void bdc_dbg_srr(struct bdc *bdc, u32 srr_num)
 
sr = bdc->srr.sr_bds;
addr = bdc->srr.dma_addr;
-   dev_vdbg(bdc->dev, "bdc_dbg_srr sr:%p dqp_index:%d\n",
+   dev_vdbg(bdc->dev, "%s sr:%p dqp_index:%d\n", __func__,
sr, bdc->srr.dqp_index);
for (i = 0; i < NUM_SR_ENTRIES; i++) {
sr = &bdc->srr.sr_bds[i];
diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c 
b/drivers/usb/gadget/udc/bdc/bdc_ep.c
index 76463de..44f3a12 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_ep.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_ep.c
@@ -756,7 +756,7 @@ static int ep_dequeue(struct bdc_ep *ep, struct bdc_req 
*req)
 
dev_dbg(bdc->dev, "%s ep:%s start:%d end:%d\n",
__func__, ep->name, start_bdi, end_bdi);
-   dev_dbg(bdc->dev, "ep_dequeue ep=%p ep->desc=%p\n",
+   dev_dbg(bdc->dev, "%s ep=%p ep->desc=%p\n", __func__,
ep, (void *)ep->usb_ep.desc);
/* if still connected, stop the ep to see where the HW is ? */
if (!(bdc_readl(bdc->regs, BDC_USPC) & BDC_PST_MASK)) {
@@ -1858,12 +1858,12 @@ static int bdc_gadget_ep_enable(struct usb_ep *_ep,
int ret;
 
if (!_ep || !desc || desc->bDescriptorType != USB_DT_ENDPOINT) {
-   pr_debug("bdc_gadget_ep_enable invalid parameters\n");
+   pr_debug("%s invalid parameters\n", __func__);
return -EINVAL;
}
 
if (!desc->wMaxPacketSize) {
-   pr_debug("bdc_gadget_ep_enable missing wMaxPacketSize\n");
+   pr_debug("%s missing wMaxPacketSize\n", __func__);
return -EINVAL;
}
 
-- 
1.9.1

[PATCH v3 07/11] usb: gadget: bdc: avoid precedence issues

[Chunfeng Yun]

Add () around macro argument to avoid precedence issues

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc.h b/drivers/usb/gadget/udc/bdc/bdc.h
index 658abef..f8d5958 100644
--- a/drivers/usb/gadget/udc/bdc/bdc.h
+++ b/drivers/usb/gadget/udc/bdc/bdc.h
@@ -86,20 +86,20 @@
 #define BDC_EPSTS5 0x74
 #define BDC_EPSTS6 0x78
 #define BDC_EPSTS7 0x7c
-#define BDC_SRRBAL(n)  (0x200 + (n * 0x10))
-#define BDC_SRRBAH(n)  (0x204 + (n * 0x10))
-#define BDC_SRRINT(n)  (0x208 + (n * 0x10))
-#define BDC_INTCTLS(n) (0x20c + (n * 0x10))
+#define BDC_SRRBAL(n)  (0x200 + ((n) * 0x10))
+#define BDC_SRRBAH(n)  (0x204 + ((n) * 0x10))
+#define BDC_SRRINT(n)  (0x208 + ((n) * 0x10))
+#define BDC_INTCTLS(n) (0x20c + ((n) * 0x10))
 
 /* Extended capability regs */
 #define BDC_FSCNOC 0xcd4
 #define BDC_FSCNIC 0xce4
-#define NUM_NCS(p) (p >> 28)
+#define NUM_NCS(p) ((p) >> 28)
 
 /* Register bit fields and Masks */
 /* BDC Configuration 0 */
 #define BDC_PGS(p) (((p) & (0x7 << 8)) >> 8)
-#define BDC_SPB(p) (p & 0x7)
+#define BDC_SPB(p) ((p) & 0x7)
 
 /* BDC Capability1 */
 #define BDC_P64(1 << 0)
@@ -113,7 +113,7 @@
 #define BDC_CMD_DVC0x1
 #define BDC_CMD_CWS(0x1 << 5)
 #define BDC_CMD_CST(p) (((p) & (0xf << 6))>>6)
-#define BDC_CMD_EPN(p) ((p & 0x1f) << 10)
+#define BDC_CMD_EPN(p) (((p) & 0x1f) << 10)
 #define BDC_SUB_CMD_ADD(0x1 << 17)
 #define BDC_SUB_CMD_FWK(0x4 << 17)
 /* Reset sequence number */
@@ -163,7 +163,7 @@
 #define BDC_SPEED_HS   0x3
 #define BDC_SPEED_SS   0x4
 
-#define BDC_PST(p) (p & 0xf)
+#define BDC_PST(p) ((p) & 0xf)
 #define BDC_PST_MASK   0xf
 
 /* USPPMS */
@@ -228,7 +228,7 @@
 /* status report defines */
 #define SR_XSF 0
 #define SR_USPC4
-#define SR_BD_LEN(p)(p & 0xff)
+#define SR_BD_LEN(p)((p) & 0xff)
 
 #define XSF_SUCC   0x1
 #define XSF_SHORT  0x3
-- 
1.9.1

Re: [PATCH 15/19] md: use bdev_check_media_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> The md driver does not have a ->revalidate_disk method, so it can just
> use bdev_check_media_change without any additional changes.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/md/md.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 9562ef598ae1f4..27ed61197014ef 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -7848,7 +7848,7 @@ static int md_open(struct block_device *bdev, fmode_t 
> mode)
>   atomic_inc(&mddev->openers);
>   mutex_unlock(&mddev->open_mutex);
>  
> - check_disk_change(bdev);
> + bdev_check_media_change(bdev);
>   out:
>   if (err)
>   mddev_put(mddev);
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

[PATCH v3 10/11] usb: gadget: bdc: fix checkpatch.pl spacing error

[Chunfeng Yun]

fix checkpatch.pl error:
ERROR:SPACING: space prohibited before that ','

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc_udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_udc.c 
b/drivers/usb/gadget/udc/bdc/bdc_udc.c
index 0c1ab95..5ac0ef8 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_udc.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_udc.c
@@ -530,7 +530,7 @@ int bdc_udc_init(struct bdc *bdc)
 
bdc->gadget.name = BRCM_BDC_NAME;
ret = devm_request_irq(bdc->dev, bdc->irq, bdc_udc_interrupt,
-   IRQF_SHARED , BRCM_BDC_NAME, bdc);
+   IRQF_SHARED, BRCM_BDC_NAME, bdc);
if (ret) {
dev_err(bdc->dev,
"failed to request irq #%d %d\n",
-- 
1.9.1

[PATCH v3 11/11] usb: gadget: bdc: fix checkpatch.pl repeated word warning

[Chunfeng Yun]

fix the warning:
WARNING:REPEATED_WORD: Possible repeated word: 'and'

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc_ep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c 
b/drivers/usb/gadget/udc/bdc/bdc_ep.c
index d227d26..8e2f20b 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_ep.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_ep.c
@@ -1405,7 +1405,7 @@ static int ep0_set_sel(struct bdc *bdc,
 }
 
 /*
- * Queue a 0 byte bd only if wLength is more than the length and and length is
+ * Queue a 0 byte bd only if wLength is more than the length and length is
  * a multiple of MaxPacket then queue 0 byte BD
  */
 static int ep0_queue_zlp(struct bdc *bdc)
-- 
1.9.1

Re: [PATCH 16/19] sd: use bdev_check_media_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Switch to use bdev_check_media_change instead of check_disk_change and
> call sd_revalidate_disk manually.  As sd also calls sd_revalidate_disk
> manually during probe and open, , the extra call into ->revalidate_disk
> from bdev_disk_changed is not required either, so stop wiring up the
> method.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/scsi/sd.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

[PATCH v3 09/11] usb: gadget: bdc: fix checkpatch.pl tab warning

[Chunfeng Yun]

WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional statements
WARNING:TABSTOP: Statements should start on a tabstop

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc_cmd.c | 2 +-
 drivers/usb/gadget/udc/bdc/bdc_ep.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_cmd.c 
b/drivers/usb/gadget/udc/bdc/bdc_cmd.c
index 44c2a5e..995f79c 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_cmd.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_cmd.c
@@ -163,7 +163,7 @@ int bdc_config_ep(struct bdc *bdc, struct bdc_ep *ep)
usb_endpoint_xfer_isoc(desc)) {
param2 |= si;
if (usb_endpoint_xfer_isoc(desc) && comp_desc)
-   mul = comp_desc->bmAttributes;
+   mul = comp_desc->bmAttributes;
 
}
param2 |= mul << EPM_SHIFT;
diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c 
b/drivers/usb/gadget/udc/bdc/bdc_ep.c
index 3fb36c8..d227d26 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_ep.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_ep.c
@@ -275,7 +275,7 @@ static inline int find_end_bdi(struct bdc_ep *ep, int 
next_hwd_bdi)
end_bdi = next_hwd_bdi - 1;
if (end_bdi < 0)
end_bdi = ep->bd_list.max_bdi - 1;
-else if ((end_bdi % (ep->bd_list.num_bds_table-1)) == 0)
+   else if ((end_bdi % (ep->bd_list.num_bds_table-1)) == 0)
end_bdi--;
 
return end_bdi;
@@ -795,7 +795,7 @@ static int ep_dequeue(struct bdc_ep *ep, struct bdc_req 
*req)
start_pending = true;
end_pending = true;
} else if (end_bdi >= curr_hw_dqpi || end_bdi <= eqp_bdi) {
-   end_pending = true;
+   end_pending = true;
}
} else {
if (start_bdi >= curr_hw_dqpi) {
-- 
1.9.1

Re: [PATCH v1] driver core: Annotate dev_err_probe() with __must_check

[Greg Kroah-Hartman]

On Wed, Sep 09, 2020 at 09:08:14AM +0200, Krzysztof Kozlowski wrote:
> On Wed, 9 Sep 2020 at 09:02, Greg Kroah-Hartman
>  wrote:
> >
> > On Wed, Sep 09, 2020 at 08:29:25AM +0200, Krzysztof Kozlowski wrote:
> > > On Wed, 26 Aug 2020 at 18:18, Joe Perches  wrote:
> > > >
> > > > On Wed, 2020-08-26 at 18:55 +0300, Andy Shevchenko wrote:
> > > > > On Wed, Aug 26, 2020 at 08:44:30AM -0700, Joe Perches wrote:
> > > > > > On Wed, 2020-08-26 at 13:44 +0300, Andy Shevchenko wrote:
> > > > >
> > > > > ...
> > > > >
> > > > > > > -int dev_err_probe(const struct device *dev, int err, const char 
> > > > > > > *fmt, ...);
> > > > > > > +int __must_check dev_err_probe(const struct device *dev, int 
> > > > > > > err, const char *fmt, ...);
> > >
> > > +Cc Stephen and Greg,
> > >
> > > Hi Andy,
> > >
> > > Did this patch ended up in next somehow? I am surprised because now I
> > > got warnings for perfectly fine code:
> > > https://lore.kernel.org/linux-next/20200909155654.76fe3...@canb.auug.org.au/T/#u
> > >
> > > This creates simply false warnings instead of hints for "optimization".
> >
> > Yes, it got merged into m y driver core tree.
> >
> > I'll fix up the tty build warning, should be easy enough, the patch is
> > below.
> 
> Yes, this fix suppresses the warning but the question is whether we
> really want the warning?
> Such fixes mean additional code which the compiler might not optimize
> (unless it inlines the dev_err_probe()). This additional code is
> purely for suppressing the warning, without any meaning on its own.
> Actually it might be even confusing for someone to see:
> if (ret)
>   ret = dev_err_probe(ret);

Yeah, that is dumb, as the patch I made shows :(

> warn_unused_result should point errors, not "optimization
> opportunities". If you want to have opportunity, add a coccinelle
> rule. Or a checkpatch rule. Not a compiler warning.

Ok, I now agree, I'll go revert this patch and trust that driver authors
will "do the right thing" here...

thanks,

greg k-h

Re: [PATCH v4 9/9] mfd: mt6360: Merge different sub-devices I2C read/write

[Lee Jones]

On Wed, 09 Sep 2020, Gene Chen wrote:

> Lee Jones  於 2020年9月8日 週二 下午7:48寫道：
> >
> > On Tue, 01 Sep 2020, Gene Chen wrote:
> >
> > > Lee Jones  於 2020年8月28日 週五 下午6:40寫道：
> > > >
> > > > On Mon, 17 Aug 2020, Gene Chen wrote:
> > > >
> > > > > From: Gene Chen 
> > > > >
> > > > > Remove unuse register definition.
> > > >
> > > > This should be in a separate patch.
> > > >
> > > > > Merge different sub-devices I2C read/write functions into one Regmap,
> > > > > because PMIC and LDO part need CRC bits for access protection.
> > > > >
> > > > > Signed-off-by: Gene Chen 
> > > > > ---
> > > > >  drivers/mfd/Kconfig|   1 +
> > > > >  drivers/mfd/mt6360-core.c  | 260 
> > > > > +++--
> > > > >  include/linux/mfd/mt6360.h | 240 
> > > > > -
> > > > >  3 files changed, 226 insertions(+), 275 deletions(-)
> > > > >  delete mode 100644 include/linux/mfd/mt6360.h
> > > > >
> > > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > > > index a37d7d1..0684ddc 100644
> > > > > --- a/drivers/mfd/Kconfig
> > > > > +++ b/drivers/mfd/Kconfig
> > > > > @@ -913,6 +913,7 @@ config MFD_MT6360
> > > > >   select MFD_CORE
> > > > >   select REGMAP_I2C
> > > > >   select REGMAP_IRQ
> > > > > + select CRC8
> > > > >   depends on I2C
> > > > >   help
> > > > > Say Y here to enable MT6360 PMU/PMIC/LDO functional support.
> > > > > diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
> > > > > index 677c974..e995220 100644
> > > > > --- a/drivers/mfd/mt6360-core.c
> > > > > +++ b/drivers/mfd/mt6360-core.c
> > > > > @@ -14,7 +14,53 @@
> > > > >  #include 
> > > > >  #include 
> > > > >
> > > > > -#include 
> > > > > +enum {
> > > > > + MT6360_SLAVE_TCPC = 0,
> > > > > + MT6360_SLAVE_PMIC,
> > > > > + MT6360_SLAVE_LDO,
> > > > > + MT6360_SLAVE_PMU,
> > > > > + MT6360_SLAVE_MAX,
> > > > > +};
> > > > > +
> > > > > +struct mt6360_ddata {
> > > > > + struct i2c_client *i2c[MT6360_SLAVE_MAX];
> > > > > + struct device *dev;
> > > > > + struct regmap *regmap;
> > > > > + struct regmap_irq_chip_data *irq_data;
> > > > > + unsigned int chip_rev;
> > > > > + u8 crc8_tbl[CRC8_TABLE_SIZE];
> > > > > +};
> > > >
> > > > This is not a new structure, right?  Where was this before?  Surely it
> > > > should be removed from wherever it was in the same patch that places
> > > > it here?
> > > >
> > >
> > > No, it is merge from header file to source code for unuse in other 
> > > sub-module.
> >
> > So where did it come from and why don't I see the removal in this
> > patch?
> >
> 
> Change is in the bottom of this patch.
> There is a little confuse part in "[PATCH v4 5/9] mfd: mt6360: Rename
> mt6360_pmu_data by mt6360_ddata"
> The "PATCH 5/9" change mt6360_pmu_data to mt6360_ddata instead of mt6360_data.
> I will update PATCH v5 to fix it.
> 
> [PATCH v4 9/9]
> diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h
> -struct mt6360_data {
> -   struct i2c_client *i2c[MT6360_SLAVE_MAX];
> -   struct device *dev;
> -   struct regmap *regmap;
> -   struct regmap_irq_chip_data *irq_data;
> -   unsigned int chip_rev;
> -};
> 
> [PATCH v4 5/9]
> diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h
> -struct mt6360_pmu_data {
> +struct mt6360_data {
> struct i2c_client *i2c[MT6360_SLAVE_MAX];
> struct device *dev;
> struct regmap *regmap;

Oh, you've renamed it whilst moving it.  That is probably not best
practise, as it causes this kind of confusion.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 17/19] sr: use bdev_check_media_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Switch to use bdev_check_media_change instead of check_disk_change and
> call sr_block_revalidate_disk manually.  Also add an explicit call to
> sr_block_revalidate_disk just before disk_add() to ensure we always
> read check for a ready unit and read the TOC and then stop wiring up
> ->revalidate_disk.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/scsi/sr.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Re: Question: Why is there no notification when a file is opened using filp_open()?

[Amir Goldstein]

On Wed, Sep 9, 2020 at 10:00 AM Xiaoming Ni  wrote:
>
> On 2020/9/9 11:44, Amir Goldstein wrote:
> > On Tue, Sep 8, 2020 at 8:19 PM Matthew Wilcox  wrote:
> >>
> >> On Tue, Sep 08, 2020 at 04:18:29PM +0300, Amir Goldstein wrote:
> >>> On Tue, Sep 8, 2020 at 3:53 PM Xiaoming Ni  wrote:
>  For example, in fs/coredump.c, do_coredump() calls filp_open() to
>  generate core files.
>  In this scenario, the fsnotify_open() notification is missing.
> >>>
> >>> I am not convinced that we should generate an event.
> >>> You will have to explain in what is the real world use case that requires 
> >>> this
> >>> event to be generated.
> >>
> >> Take the typical usage for fsnotify of a graphical file manager.
> >> It would be nice if the file manager showed a corefile as soon as it
> >> appeared in a directory rather than waiting until some other operation
> >> in that directory caused those directory contents to be refreshed.
> >
> > fsnotify_open() is not the correct notification for file managers IMO.
> > fsnotify_create() is and it will be called in this case.
> >
> > If the reason you are interested in open events is because you want
> > to monitor the entire filesystem then welcome to the future -
> > FAN_CREATE is supported since kernel v5.1.
> >
> > Is there another real life case you have in mind where you think users
> > should be able to get an open fd for a file that the kernel has opened?
> > Because that is what FAN_OPEN will do.
> >
>
> There are also cases where file is opened in read-only mode using
> filp_open().
>
> case1: nfsd4_init_recdir() call filp_open()
> filp_open()
> nfsd4_init_recdir() fs/nfsd/nfs4recover.c#L543
>
> L70: static char user_recovery_dirname[PATH_MAX] =
> "/var/lib/nfs/v4recovery";
> L543: nn->rec_file = filp_open(user_recovery_dirname, O_RDONLY |
> O_DIRECTORY, 0);
>
>
> case2: ima_read_policy()
> filp_open()
> kernel_read_file_from_path()  fs/exec.c#L1004
> ima_read_policy()  security/integrity/ima/ima_fs.c#L286
> ima_write_policy() security/integrity/ima/ima_fs.c#L335
> ima_measure_policy_ops   security/integrity/ima/ima_fs.c#L443
> sys_write()
>
> case3: use do_file_open_root() to open file
> do_file_open_root()
> file_open_root()   fs/open.c#L1159
> kernel_read_file_from_path_initns()  fs/exec.c#L1029
> fw_get_filesystem_firmware()  drivers/base/firmware_loader/main.c#L498
>
> Do we need to add fsnotify_open() in these scenarios?

We do not *need* to add fsnotify_open() if there is no concrete use case
from real life that needs it.

Matthew gave an example of a real life use case and I explained why IMO
we don't need to add fsnotify_open() for the use case that he described.

If you want to add fsnotify_open() to any call site, please come up with
a real life use case - not a made up one, one that really exists and where
the open event is really needed.

grepping the code for callers of filp_open() is not enough.

Thanks,
Amir.

Re: [PATCH v21 4/4] arm64: dts: mt8183: add scp node

[Jon Hunter]

On 02/09/2020 17:23, Krzysztof Kozlowski wrote:
> On Wed, 2 Sep 2020 at 16:45, Naresh Kamboju  wrote:
>>
>> On Thu, 27 Aug 2020 at 15:44, Matthias Brugger  
>> wrote:
>>>
>>>
>>>
>>> On 12/11/2019 12:03, Pi-Hsun Shih wrote:
 From: Eddie Huang 

 Add scp node to mt8183 and mt8183-evb

 Signed-off-by: Erin Lo 
 Signed-off-by: Pi-Hsun Shih 
 Signed-off-by: Eddie Huang 
>>>
>>> Sorry I somehow oversaw this. Next time please don't doubt to ping me.
>>>
>>> Bjorn, do I understand correctly that you don't send emails to the list
>>> informing of the inclusion of a patch/series in your tree?
>>>
>>> Anyway applied now to v5.9-next/dts64 :)
>>
>> arm64 build dtbs failed on linux next 20200902.
> 
> I just hit it as well... I wish the kernel was built after applying
> patches... it would make the next a better place.


Any update on this? It is still broken as of next-20200908.

Jon

-- 
nvpublic

[PATCH v2] drm/dp_mst: Add ddc i2c device links for DP MST connectors

[Sam McNally]

DP MST DDC I2C devices are not parented to their connectors. This makes
it challenging to associate the ddc i2c device with its connector from
userspace. With further refactoring, this can be changed, but in the
meantime, follow the pattern of commit e1a29c6c5955 ("drm: Add ddc link
in sysfs created by drm_connector"), creating sysfs ddc links to the
associated i2c device for MST DP connectors.

If the connector is created and registered before the i2c device, create
the link when registering the i2c device; otherwise, create the link
after registering the connector.

Signed-off-by: Sam McNally 
---

Changes in v2:
- Reworded description to avoid accusing an innocent commit of
  responsibility for the problem being addressed

 drivers/gpu/drm/drm_dp_mst_topology.c | 29 +--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 17dbed0a9800..e60a6b8af3c1 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2159,11 +2159,23 @@ static void build_mst_prop_path(const struct 
drm_dp_mst_branch *mstb,
 int drm_dp_mst_connector_late_register(struct drm_connector *connector,
   struct drm_dp_mst_port *port)
 {
+   int ret;
DRM_DEBUG_KMS("registering %s remote bus for %s\n",
  port->aux.name, connector->kdev->kobj.name);
 
port->aux.dev = connector->kdev;
-   return drm_dp_aux_register_devnode(&port->aux);
+   ret = drm_dp_aux_register_devnode(&port->aux);
+   if (ret)
+   return ret;
+
+   if (port->pdt != DP_PEER_DEVICE_NONE &&
+   drm_dp_mst_is_end_device(port->pdt, port->mcs)) {
+   ret = sysfs_create_link(&port->connector->kdev->kobj,
+   &port->aux.ddc.dev.kobj, "ddc");
+   if (ret)
+   drm_dp_aux_unregister_devnode(&port->aux);
+   }
+   return ret;
 }
 EXPORT_SYMBOL(drm_dp_mst_connector_late_register);
 
@@ -5439,6 +5451,7 @@ static int drm_dp_mst_register_i2c_bus(struct 
drm_dp_mst_port *port)
 {
struct drm_dp_aux *aux = &port->aux;
struct device *parent_dev = port->mgr->dev->dev;
+   int ret;
 
aux->ddc.algo = &drm_dp_mst_i2c_algo;
aux->ddc.algo_data = aux;
@@ -5453,7 +5466,17 @@ static int drm_dp_mst_register_i2c_bus(struct 
drm_dp_mst_port *port)
strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(parent_dev),
sizeof(aux->ddc.name));
 
-   return i2c_add_adapter(&aux->ddc);
+   ret = i2c_add_adapter(&aux->ddc);
+   if (ret)
+   return ret;
+
+   if (port->connector && port->connector->kdev) {
+   ret = sysfs_create_link(&port->connector->kdev->kobj,
+   &port->aux.ddc.dev.kobj, "ddc");
+   if (ret)
+   i2c_del_adapter(&port->aux.ddc);
+   }
+   return ret;
 }
 
 /**
@@ -5462,6 +5485,8 @@ static int drm_dp_mst_register_i2c_bus(struct 
drm_dp_mst_port *port)
  */
 static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_mst_port *port)
 {
+   if (port->connector && port->connector->kdev)
+   sysfs_remove_link(&port->connector->kdev->kobj, "ddc");
i2c_del_adapter(&port->aux.ddc);
 }
 
-- 
2.28.0.526.ge36021eeef-goog

Re: [PATCH] scripts: coccicheck: Do not use shift command when rule is specified

[Sumera Priyadarsini]

On Wed, Sep 09, 2020 at 08:52:19AM +0200, Markus Elfring wrote:
> I find it helpful to avoid typos (like the following) in the change 
> description.
> 
> 
> > … Makfeile. …
> 
> … Makefile. …
> 
> 
> > … paasing …
> 
> … passing …
> 
> 
> > …, resuting …
> 
> …, resulting …
> 
> 
> > This patch modifies coccicheck …
> 

I did make those errors but I also rectified them. This is strange
because my commit message shows the rectified version.
Either way, I will send a v2. Thanks for pointing this out.

> Would an imperative wording be preferred for the commit message?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=34d4ddd359dbcdf6c5fb3f85a179243d7a1cb7f8#n151
> 
> Regards,
> Markus

[PATCH v3 01/11] usb: gadget: bdc: fix improper SPDX comment style for header file

[Chunfeng Yun]

For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used).

Cc: Florian Fainelli 
Signed-off-by: Chunfeng Yun 
Acked-by: Florian Fainelli 
---
v3: add acked-by Florian

v2: add Cc Florian
---
 drivers/usb/gadget/udc/bdc/bdc.h | 2 +-
 drivers/usb/gadget/udc/bdc/bdc_cmd.h | 2 +-
 drivers/usb/gadget/udc/bdc/bdc_dbg.h | 2 +-
 drivers/usb/gadget/udc/bdc/bdc_ep.h  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc.h b/drivers/usb/gadget/udc/bdc/bdc.h
index ac75e25..fcba77e 100644
--- a/drivers/usb/gadget/udc/bdc/bdc.h
+++ b/drivers/usb/gadget/udc/bdc/bdc.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0+
+/* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * bdc.h - header for the BRCM BDC USB3.0 device controller
  *
diff --git a/drivers/usb/gadget/udc/bdc/bdc_cmd.h 
b/drivers/usb/gadget/udc/bdc/bdc_cmd.h
index 29cc988..373e674 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_cmd.h
+++ b/drivers/usb/gadget/udc/bdc/bdc_cmd.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0+
+/* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * bdc_cmd.h - header for the BDC debug functions
  *
diff --git a/drivers/usb/gadget/udc/bdc/bdc_dbg.h 
b/drivers/usb/gadget/udc/bdc/bdc_dbg.h
index 373d5ab..859d588 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_dbg.h
+++ b/drivers/usb/gadget/udc/bdc/bdc_dbg.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0+
+/* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * bdc_dbg.h - header for the BDC debug functions
  *
diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.h 
b/drivers/usb/gadget/udc/bdc/bdc_ep.h
index a37ff803..5bbd73f 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_ep.h
+++ b/drivers/usb/gadget/udc/bdc/bdc_ep.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0+
+/* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * bdc_ep.h - header for the BDC debug functions
  *
-- 
1.9.1

Re: [PATCH 18/19] sr: simplify sr_block_revalidate_disk

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Both callers have a valid CD struture available, so rely on that instead
> of getting another reference.  Also move the function to avoid a forward
> declaration.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  drivers/scsi/sr.c | 36 +---
>  1 file changed, 13 insertions(+), 23 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH 19/19] block: remove check_disk_change

[Hannes Reinecke]

On 9/8/20 4:53 PM, Christoph Hellwig wrote:
> Remove the now unused check_disk_change helper.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 
> ---
>  fs/block_dev.c| 20 
>  include/linux/genhd.h |  1 -
>  2 files changed, 21 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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

Re: [PATCH v3 1/2] iio: adc: mt6360: Add ADC driver for MT6360

[Gene Chen]

Jonathan Cameron  於 2020年9月8日 週二 下午9:00寫道：
>
> ...
>
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +
> > > > > > +#define MT6360_REG_PMUCHGCTRL3   0x313
> > > > > > +#define MT6360_REG_PMUADCCFG 0x356
> > > > > > +#define MT6360_REG_PMUADCRPT10x35A
> > > > > > +
> > > > > > +/* PMUCHGCTRL3 0x313 */
> > > > > > +#define MT6360_AICR_MASK 0xFC
> > > > > > +#define MT6360_AICR_SHFT 2
> > > > > > +#define MT6360_AICR_400MA0x6
> > > > > > +/* PMUADCCFG 0x356 */
> > > > > > +#define MT6360_ADCEN_MASK0x8000
> > > > > > +/* PMUADCRPT1 0x35A */
> > > > > > +#define MT6360_PREFERCH_MASK 0xF0
> > > > > > +#define MT6360_PREFERCH_SHFT 4
> > > > > > +#define MT6360_RPTCH_MASK0x0F
> > > > > > +
> > > > > > +enum {
> > > > > > + MT6360_CHAN_USBID = 0,
> > > > > > + MT6360_CHAN_VBUSDIV5,
> > > > > > + MT6360_CHAN_VBUSDIV2,
> > > > > > + MT6360_CHAN_VSYS,
> > > > > > + MT6360_CHAN_VBAT,
> > > > > > + MT6360_CHAN_IBUS,
> > > > > > + MT6360_CHAN_IBAT,
> > > > > > + MT6360_CHAN_CHG_VDDP,
> > > > > > + MT6360_CHAN_TEMP_JC,
> > > > > > + MT6360_CHAN_VREF_TS,
> > > > > > + MT6360_CHAN_TS,
> > > > > > + MT6360_CHAN_MAX,
> > > > > > +};
> > > > > > +
> > > > > > +struct mt6360_adc_data {
> > > > > > + struct device *dev;
> > > > > > + struct regmap *regmap;
> > > > > > + struct completion adc_complete;
> > > > > > + struct mutex adc_lock;
> > > > > > + ktime_t last_off_timestamps[MT6360_CHAN_MAX];
> > > > > > + int irq;
> > > > > > +};
> > > > > > +
> > > > > > +static inline int mt6360_adc_val_converter(int val, int 
> > > > > > multiplier, int offset, int divisor)
> > > > > > +{
> > > > > > + return ((val * multiplier) + offset) / divisor;
> > > > >
> > > > > Why could we not report these values to userspace or consumer drivers 
> > > > > and let
> > > > > them deal with the conversion if they actually needed it?
> > > > > Mapping this to
> > > > >
> > > > > (val + new_offset) * multiplier would be a little messy, but not too 
> > > > > bad.
> > > > >
> > > > > The advantage would be that we would then be providing the data needed
> > > > > to get real units for values read from the buffers without having to
> > > > > do all the maths in kernel (without access to floating point).
> > > > >
> > > > >
> > > >
> > > > As above, if I use formula "(val + new_offset) * multiplier",
> > > > the junction temperature channel multiplier will be floating point
> > > > 1.05, i don't know how to express.
> > >
> > > As Andy mentioned, we do this all over the place.
> > > IIO_VAL_INT_PLUS_MICRO
> > >
> > > The key is that we want to push the burden of doing this maths to the user
> > > not the source.
> >
> > ACK.
> > Can I keep IIO_CHAN_INFO_PROCESSED function be reserved for user in
> > kernel space?
> >
>
> No. We have utility functions that will apply the multiplier as needed so
> there is no significant advantage in doing this and it won't be consistent
> with the majority of other drivers.
>

ACK, I will remove IIO_CHAN_INFO_PROCESSED.

> > >
> > > Often what is actually of interest is whether a temperature passed a 
> > > threshold.
> > > In that case, you can transform the threshold into the units of the ADC 
> > > (so the
> > > reverse directly to you would do with processed data) and only have to do 
> > > the
> > > maths once per change of the threshold instead of for every sample.
> > >
> > > There are helper functions to do the maths for you, should you actually
> > > need SI units.
> > >
> >
> > ACK
> >
> > > >
> > > > > > +}
> > > > > > +
> > > > > > +static int mt6360_adc_convert_processed_val(struct mt6360_adc_data 
> > > > > > *info, int chan_idx, int *val)
> > > > > > +{
> > > > > > + unsigned int regval = 0;
> > > > > > + const struct converter {
> > > > > > + int multiplier;
> > > > > > + int offset;
> > > > > > + int divisor;
> > > > > > + } adc_converter[MT6360_CHAN_MAX] = {
> > > > > > + { 1250, 0, 1}, /* USBID */
> > > > > > + { 6250, 0, 1}, /* VBUSDIV5 */
> > > > > > + { 2500, 0, 1}, /* VBUSDIV2 */
> > > > > > + { 1250, 0, 1}, /* VSYS */
> > > > > > + { 1250, 0, 1}, /* VBAT */
> > > > > > + { 2500, 0, 1}, /* IBUS */
> > > > > > + { 2500, 0, 1}, /* IBAT */
> > > > > > + { 1250, 0, 1}, /* CHG_VDDP */
> > > > > > + { 105, -8000, 100}, /* TEMP_JC */
> > > > > > + { 1250, 0, 1}, /* VREF_TS */
> > > > > > + { 1250, 0, 1}, /* TS */
> > > > > > + }, sp_ibus_adc_converter = { 1900, 0, 1 }, *sel_converter;
> > > > > > + int ret;
> > > > > > +
> > > > > > + sel_converter = a

Re: [PATCH] mm: don't rely on system state to detect hot-plug operations

[Michal Hocko]

[reposting because the malformed cc list confused my email client]

On Tue 08-09-20 19:08:35, Laurent Dufour wrote:
> In register_mem_sect_under_node() the system_state’s value is checked to
> detect whether the operation the call is made during boot time or during an
> hot-plug operation. Unfortunately, that check is wrong on some
> architecture, and may lead to sections being registered under multiple
> nodes if node's memory ranges are interleaved.

Why is this check arch specific?

> This can be seen on PowerPC LPAR after multiple memory hot-plug and
> hot-unplug operations are done. At the next reboot the node's memory ranges
> can be interleaved

What is the exact memory layout?

> and since the call to link_mem_sections() is made in
> topology_init() while the system is in the SYSTEM_SCHEDULING state, the
> node's id is not checked, and the sections registered multiple times.

So a single memory section/memblock belongs to two numa nodes?

> In
> that case, the system is able to boot but later hot-plug operation may lead
> to this panic because the node's links are correctly broken:

Correctly broken? Could you provide more details on the inconsistency
please?

Which physical memory range you are trying to add here and what is the
node affinity?

> [ cut here ]
> kernel BUG at /Users/laurent/src/linux-ppc/mm/memory_hotplug.c:1084!
> Oops: Exception in kernel mode, sig: 5 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: rpadlpar_io rpaphp pseries_rng rng_core vmx_crypto 
> gf128mul binfmt_misc ip_tables x_tables xfs libcrc32c crc32c_vpmsum autofs4
> CPU: 8 PID: 10256 Comm: drmgr Not tainted 5.9.0-rc1+ #25
> NIP:  c0403f34 LR: c0403f2c CTR: 
> REGS: c004876e3660 TRAP: 0700   Not tainted  (5.9.0-rc1+)
> MSR:  8282b033   CR: 24000448  XER: 
> 2004
> CFAR: c0846d20 IRQMASK: 0
> GPR00: c0403f2c c004876e38f0 c12f6f00 ffef
> GPR04: 0227 c004805ae680  0004886f
> GPR08: 0226 0003 0002 fffd
> GPR12: 88000484 c0001ec96280  
> GPR16:   0004 0003
> GPR20: c0047814ffe0 c0077c08 0010 c13332c8
> GPR24:  c11f6cc0  
> GPR28: ffef 0001 00015000 1000
> NIP [c0403f34] add_memory_resource+0x244/0x340
> LR [c0403f2c] add_memory_resource+0x23c/0x340
> Call Trace:
> [c004876e38f0] [c0403f2c] add_memory_resource+0x23c/0x340 
> (unreliable)
> [c004876e39c0] [c040408c] __add_memory+0x5c/0xf0
> [c004876e39f0] [c00e2b94] dlpar_add_lmb+0x1b4/0x500
> [c004876e3ad0] [c00e3888] dlpar_memory+0x1f8/0xb80
> [c004876e3b60] [c00dc0d0] handle_dlpar_errorlog+0xc0/0x190
> [c004876e3bd0] [c00dc398] dlpar_store+0x198/0x4a0
> [c004876e3c90] [c072e630] kobj_attr_store+0x30/0x50
> [c004876e3cb0] [c051f954] sysfs_kf_write+0x64/0x90
> [c004876e3cd0] [c051ee40] kernfs_fop_write+0x1b0/0x290
> [c004876e3d20] [c0438dd8] vfs_write+0xe8/0x290
> [c004876e3d70] [c04391ac] ksys_write+0xdc/0x130
> [c004876e3dc0] [c0034e40] system_call_exception+0x160/0x270
> [c004876e3e20] [c000d740] system_call_common+0xf0/0x27c
> Instruction dump:
> 48442e35 6000 0b03 3cbe0001 7fa3eb78 7bc48402 38a5fffe 7ca5fa14
> 78a58402 48442db1 6000 7c7c1b78 <0b03> 7f23cb78 4bda371d 6000
> ---[ end trace 562fd6c109cd0fb2 ]---

The BUG_ON on failure is absolutely horrendous. There must be a better
way to handle a failure like that. The failure means that
sysfs_create_link_nowarn has failed. Please describe why that is the
case.

> This patch addresses the root cause by not relying on the system_state
> value to detect whether the call is due to a hot-plug operation or not. An
> additional parameter is added to link_mem_sections() to tell the context of
> the call and this parameter is propagated to register_mem_sect_under_node()
> throuugh the walk_memory_blocks()'s call.

This looks like a hack to me and it deserves a better explanation. The
existing code is a hack on its own and it is inconsistent with other
boot time detection. We are using (system_state < SYSTEM_RUNNING) at other
places IIRC. Would it help to use the same here as well? Maybe we want to
wrap that inside a helper (early_memory_init()) and use it at all
places.

> Fixes: 4fbce633910e ("mm/memory_hotplug.c: make 
> register_mem_sect_under_node() a callback of walk_memory_range()")
> Signed-off-by: Laurent Dufour 
> Cc: sta...@vger.kernel.org
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Cc: Andrew Morton 
> ---
>  drivers/base/node.c  | 20 +++-
>  i

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

[Greg KH]

On Wed, Sep 09, 2020 at 05:23:17PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the driver-core tree, today's linux-next build produced
> this warning:
> 
> drivers/mmc/host/davinci_mmc.c: In function 'davinci_mmcsd_probe':
> drivers/mmc/host/davinci_mmc.c:1243:4: warning: ignoring return value of 
> 'dev_err_probe' declared with attribute 'warn_unused_result' [-Wunused-result]
>  1243 |dev_err_probe(&pdev->dev, ret,
>   |^~
>  1244 |   "could not parse of data\n");
>   |   
> 
> Introduced by commit
> 
>   e1f82a0dcf38 ("driver core: Annotate dev_err_probe() with __must_check")
> 
> interacting with commit
> 
>   3a35e7e1bd50 ("mmc: davinci: Simplify with dev_err_probe()")
> 
> from the mmc tree.

Offending patch now dropped from the driver-core tree, thanks.

greg k-h

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

[Greg KH]

On Wed, Sep 09, 2020 at 05:16:21PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the staging tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> drivers/iio/adc/stm32-adc-core.c: In function 'stm32_adc_core_switches_probe':
> drivers/iio/adc/stm32-adc-core.c:598:5: warning: ignoring return value of 
> 'dev_err_probe' declared with attribute 'warn_unused_result' [-Wunused-result]
>   598 | dev_err_probe(dev, ret, "can't get booster\n");
>   | ^~
> 
> Introduced by commit
> 
>   ce30eeb613cb ("iio: adc: stm32: Simplify with dev_err_probe()")

Offending patch now dropped from the driver-core tree, thanks.

greg k-h

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

[Greg KH]

On Wed, Sep 09, 2020 at 03:56:54PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tty tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> drivers/tty/serial/8250/8250_bcm2835aux.c: In function 
> 'bcm2835aux_serial_probe':
> drivers/tty/serial/8250/8250_bcm2835aux.c:154:3: warning: ignoring return 
> value of 'dev_err_probe' declared with attribute 'warn_unused_result' 
> [-Wunused-result]
>   154 |   dev_err_probe(&pdev->dev, ret, "unable to register 8250 port\n");
>   |   ^~~~
> 
> Introduced by commit
> 
>   ea43a60b1548 ("serial: 8250: Simplify with dev_err_probe()")

Offending patch now dropped from the driver-core tree, thanks.

greg k-h

Re: [PATCH v2 4/4] drm_dp_cec: add MST support

[Hans Verkuil]

On 09/09/2020 09:20, Sam McNally wrote:
> With DP v2.0 errata E5, CEC tunneling can be supported through an MST
> topology.
> 
> There are some minor differences for CEC tunneling through an MST
> topology compared to CEC tunneling to an SST port:
> - CEC IRQs are delivered via a sink event notify message
> - CEC-related DPCD registers are accessed via remote DPCD reads and
>   writes.
> 
> This results in the MST implementation diverging from the existing SST
> implementation:
> - sink event notify messages with CEC_IRQ ID set indicate CEC IRQ rather
>   than ESI1
> - setting edid and handling CEC IRQs, which can be triggered from
>   contexts where locks held preclude HPD handling, are deferred to avoid
>   remote DPCD access which would block until HPD handling is performed
>   or a timeout
> 
> Register and unregister for all MST connectors, ensuring their
> drm_dp_aux_cec struct won't be accessed uninitialized.
> 
> Signed-off-by: Sam McNally 
> ---
> 
> Changes in v2:
> - Used aux->is_remote instead of aux->cec.is_mst, removing the need for
>   the previous patch in the series
> - Added a defensive check for null edid in the deferred set_edid work,
>   in case the edid is no longer valid at that point
> 
>  drivers/gpu/drm/drm_dp_cec.c  | 69 +--
>  drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++
>  include/drm/drm_dp_helper.h   |  4 ++
>  3 files changed, 92 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index 3ab2609f9ec7..d708fc1e273a 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Unfortunately it turns out that we have a chicken-and-egg situation
> @@ -248,6 +249,10 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux)
>   if (!aux->transfer)
>   return;
>  
> + if (aux->is_remote) {
> + schedule_work(&aux->cec.mst_irq_work);
> + return;
> + }
>   mutex_lock(&aux->cec.lock);
>   if (!aux->cec.adap)
>   goto unlock;
> @@ -276,6 +281,24 @@ static bool drm_dp_cec_cap(struct drm_dp_aux *aux, u8 
> *cec_cap)
>   return true;
>  }
>  
> +static void drm_dp_cec_mst_irq_work(struct work_struct *work)
> +{
> + struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
> +   cec.mst_irq_work);
> + struct drm_dp_mst_port *port =
> + container_of(aux, struct drm_dp_mst_port, aux);
> +
> + port = drm_dp_mst_topology_get_port_validated(port->mgr, port);
> + if (!port)
> + return;
> + mutex_lock(&aux->cec.lock);
> + if (aux->cec.adap)
> + drm_dp_cec_handle_irq(aux);
> +

As mentioned in my first review: this empty line makes the code look unbalanced 
since
there is no corresponding empty line after the mutex_lock.

I think it should just be removed and optionally an empty line can be added 
before the
mutex_lock.

> + mutex_unlock(&aux->cec.lock);
> + drm_dp_mst_topology_put_port(port);
> +}
> +
>  /*
>   * Called if the HPD was low for more than drm_dp_cec_unregister_delay
>   * seconds. This unregisters the CEC adapter.
> @@ -297,7 +320,8 @@ static void drm_dp_cec_unregister_work(struct work_struct 
> *work)
>   * were unchanged and just update the CEC physical address. Otherwise
>   * unregister the old CEC adapter and create a new one.
>   */
> -void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> +static void drm_dp_cec_handle_set_edid(struct drm_dp_aux *aux,
> +const struct edid *edid)
>  {
>   struct drm_connector *connector = aux->cec.connector;
>   u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> @@ -306,10 +330,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
> struct edid *edid)
>   unsigned int num_las = 1;
>   u8 cap;
>  
> - /* No transfer function was set, so not a DP connector */
> - if (!aux->transfer)
> - return;
> -
>  #ifndef CONFIG_MEDIA_CEC_RC
>   /*
>* CEC_CAP_RC is part of CEC_CAP_DEFAULTS, but it is stripped by
> @@ -320,6 +340,7 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
> struct edid *edid)
>*/
>   cec_caps &= ~CEC_CAP_RC;
>  #endif
> + cancel_work_sync(&aux->cec.mst_irq_work);
>   cancel_delayed_work_sync(&aux->cec.unregister_work);
>  
>   mutex_lock(&aux->cec.lock);
> @@ -375,6 +396,18 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
> struct edid *edid)
>  unlock:
>   mutex_unlock(&aux->cec.lock);
>  }
> +
> +void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> +{
> + /* No transfer function was set, so not a DP connector */
> + if (!aux->transfer)
> + return;
> +
> + if (aux->is_remote)
> + schedule_work(&aux->cec.mst_set_edid_work);
> + else

Re: [PATCH] mm: don't rely on system state to detect hot-plug operations

[Laurent Dufour]

Le 09/09/2020 à 09:40, Michal Hocko a écrit :

[reposting because the malformed cc list confused my email client]

On Tue 08-09-20 19:08:35, Laurent Dufour wrote:

In register_mem_sect_under_node() the system_state’s value is checked to
detect whether the operation the call is made during boot time or during an
hot-plug operation. Unfortunately, that check is wrong on some
architecture, and may lead to sections being registered under multiple
nodes if node's memory ranges are interleaved.


Why is this check arch specific?


I was wrong the check is not arch specific.


This can be seen on PowerPC LPAR after multiple memory hot-plug and
hot-unplug operations are done. At the next reboot the node's memory ranges
can be interleaved


What is the exact memory layout?


For instance:
[0.00] Early memory node ranges
[0.00]   node   1: [mem 0x-0x00011fff]
[0.00]   node   2: [mem 0x00012000-0x00014fff]
[0.00]   node   1: [mem 0x00015000-0x0001]
[0.00]   node   0: [mem 0x0002-0x00048fff]
[0.00]   node   2: [mem 0x00049000-0x0007]




and since the call to link_mem_sections() is made in
topology_init() while the system is in the SYSTEM_SCHEDULING state, the
node's id is not checked, and the sections registered multiple times.


So a single memory section/memblock belongs to two numa nodes?


If the node id is not checked in register_mem_sect_under_node(), yes that the 
case.




In
that case, the system is able to boot but later hot-plug operation may lead
to this panic because the node's links are correctly broken:


Correctly broken? Could you provide more details on the inconsistency
please?


laurent@ltczep3-lp4:~$ ls -l /sys/devices/system/memory/memory21
total 0
lrwxrwxrwx 1 root root 0 Aug 24 05:27 node1 -> ../../node/node1
lrwxrwxrwx 1 root root 0 Aug 24 05:27 node2 -> ../../node/node2
-rw-r--r-- 1 root root 65536 Aug 24 05:27 online
-r--r--r-- 1 root root 65536 Aug 24 05:27 phys_device
-r--r--r-- 1 root root 65536 Aug 24 05:27 phys_index
drwxr-xr-x 2 root root 0 Aug 24 05:27 power
-r--r--r-- 1 root root 65536 Aug 24 05:27 removable
-rw-r--r-- 1 root root 65536 Aug 24 05:27 state
lrwxrwxrwx 1 root root 0 Aug 24 05:25 subsystem -> ../../../../bus/memory
-rw-r--r-- 1 root root 65536 Aug 24 05:25 uevent
-r--r--r-- 1 root root 65536 Aug 24 05:27 valid_zones



Which physical memory range you are trying to add here and what is the
node affinity?


None is added, the root cause of the issue is happening at boot time.




[ cut here ]
kernel BUG at /Users/laurent/src/linux-ppc/mm/memory_hotplug.c:1084!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: rpadlpar_io rpaphp pseries_rng rng_core vmx_crypto gf128mul 
binfmt_misc ip_tables x_tables xfs libcrc32c crc32c_vpmsum autofs4
CPU: 8 PID: 10256 Comm: drmgr Not tainted 5.9.0-rc1+ #25
NIP:  c0403f34 LR: c0403f2c CTR: 
REGS: c004876e3660 TRAP: 0700   Not tainted  (5.9.0-rc1+)
MSR:  8282b033   CR: 24000448  XER: 
2004
CFAR: c0846d20 IRQMASK: 0
GPR00: c0403f2c c004876e38f0 c12f6f00 ffef
GPR04: 0227 c004805ae680  0004886f
GPR08: 0226 0003 0002 fffd
GPR12: 88000484 c0001ec96280  
GPR16:   0004 0003
GPR20: c0047814ffe0 c0077c08 0010 c13332c8
GPR24:  c11f6cc0  
GPR28: ffef 0001 00015000 1000
NIP [c0403f34] add_memory_resource+0x244/0x340
LR [c0403f2c] add_memory_resource+0x23c/0x340
Call Trace:
[c004876e38f0] [c0403f2c] add_memory_resource+0x23c/0x340 
(unreliable)
[c004876e39c0] [c040408c] __add_memory+0x5c/0xf0
[c004876e39f0] [c00e2b94] dlpar_add_lmb+0x1b4/0x500
[c004876e3ad0] [c00e3888] dlpar_memory+0x1f8/0xb80
[c004876e3b60] [c00dc0d0] handle_dlpar_errorlog+0xc0/0x190
[c004876e3bd0] [c00dc398] dlpar_store+0x198/0x4a0
[c004876e3c90] [c072e630] kobj_attr_store+0x30/0x50
[c004876e3cb0] [c051f954] sysfs_kf_write+0x64/0x90
[c004876e3cd0] [c051ee40] kernfs_fop_write+0x1b0/0x290
[c004876e3d20] [c0438dd8] vfs_write+0xe8/0x290
[c004876e3d70] [c04391ac] ksys_write+0xdc/0x130
[c004876e3dc0] [c0034e40] system_call_exception+0x160/0x270
[c004876e3e20] [c000d740] system_call_common+0xf0/0x27c
Instruction dump:
48442e35 6000 0b03 3cbe0001 7fa3eb78 7bc48402 38a5fffe 7ca5fa14
78a58402 48442db1 6000 7c7c1b78 <0b03> 7f23cb78 4bda371d 6000
---[ en

Re: [PATCH] add the FPGA Device Feature List (DFL) EMIF support

[Xu Yilun]

On Tue, Sep 08, 2020 at 11:03:35AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Sep 08, 2020 at 04:27:24PM +0800, Xu Yilun wrote:
> > This patch depend on the patchsets: "Modularization of DFL private
> > feature drivers" & "add dfl bus support to MODULE_DEVICE_TABLE()"
> 
> The need for bus I understand but why it depends on the "Modularization
> of DFL private feature drivers"?

Sorry, maybe the titles of the two Patch 0 make confusion.

The patchset "Modularization of DFL private feature drivers" implements
the dfl bus.

The "add dfl bus support to MODULE_DEVICE_TABLE()" adds the support for
dfl driver module autoloading by changing script/mod. It creates the
dfl-bus.h head file that would be used in this driver.

> 
> Anyway I will need a stable tag with mentioned dependencies or this will
> wait for the next cycle.

OK. Maybe I sent it a little earlier. I could wait until the dependencies
are applied.

Thanks,
Yilun

> 
> Best regards,
> Krzysztof
> 
> 
> > 
> > https://lore.kernel.org/linux-fpga/1599488581-16386-1-git-send-email-yilun...@intel.com/
> > 
> > The driver supports the EMIF controller on Intel Programmable
> > Acceleration Card (PAC). The controller manages the on-board memory of
> > the PCIe card.
> > 
> > Xu Yilun (1):
> >   memory: dfl-emif: add the DFL EMIF private feature driver
> > 
> >  .../ABI/testing/sysfs-bus-dfl-devices-emif |  25 +++
> >  drivers/memory/Kconfig |   9 +
> >  drivers/memory/Makefile|   2 +
> >  drivers/memory/dfl-emif.c  | 211 
> > +
> >  4 files changed, 247 insertions(+)
> >  create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
> >  create mode 100644 drivers/memory/dfl-emif.c
> > 
> > -- 
> > 2.7.4
> >