Re: [RFC PATCH 4/9] cpufreq: qcom: support qcs404 on nvmem driver

[Viresh Kumar]

On 04-04-19, 07:09, Niklas Cassel wrote:
> From: Jorge Ramirez-Ortiz 
> 

Always have something here, even for the simplest of the patches.

> Signed-off-by: Jorge Ramirez-Ortiz 
> Co-developed-by: Niklas Cassel 
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/cpufreq/qcom-cpufreq-nvmem.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c 
> b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> index 366c65a7132a..7fdc38218390 100644
> --- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
> +++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -79,6 +80,13 @@ static enum _msm8996_version qcom_cpufreq_get_msm_id(void)
>   return version;
>  }
>  
> +static int qcom_cpufreq_qcs404_name_version(struct device *cpu_dev,
> + struct nvmem_cell *speedbin_nvmem,
> + struct qcom_cpufreq_drv *drv)
> +{
> + return 0;
> +}
> +

Why provide empty stubs? Rather check for get_version() in probe and call only
if it is supported.

>  static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,
> struct nvmem_cell *speedbin_nvmem,
> struct qcom_cpufreq_drv *drv)
> @@ -191,6 +199,14 @@ static int qcom_cpufreq_probe(struct platform_device 
> *pdev)
>   dev_err(cpu_dev, "Failed to set supported hardware\n");
>   goto free_opp;
>   }
> +
> + ret = dev_pm_domain_attach(cpu_dev, false);

Why is it required specially for this platform and not earlier ?

And I was hoping for the attach-by-name thing to be present here instead because
of multiple domain thing.

> + if (ret) {
> + if (ret == -EPROBE_DEFER)
> + goto free_opp;
> + dev_err(cpu_dev, "Could not attach to pm_domain: %d\n",
> + ret);

And it is okay if we couldn't attach the domain ?

> + }
>   }
>  
>   cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", -1,
> @@ -247,6 +263,8 @@ static const struct of_device_id 
> qcom_cpufreq_match_list[] __initconst = {
> .data = qcom_cpufreq_kryo_name_version },
>   { .compatible = "qcom,msm8996",
> .data = qcom_cpufreq_kryo_name_version },
> + { .compatible = "qcom,qcs404",
> +   .data = qcom_cpufreq_qcs404_name_version },
>   {},
>  };
>  
> -- 
> 2.20.1

-- 
viresh

[PATCH 1/2] net: xilinx: add a helper function for axienet_probe

[Wen Yang]

The "Find DMA Node, Map DMA Register, and Decode DMA IRQ" code snippets
in Axienet_Probe are independent. Tidy up axienet_probe a little by
factoring these out into a helper function.

Signed-off-by: Wen Yang 
Reported-by: Markus Elfring 
Cc: Anirudha Sarangi 
Cc: John Linn 
Cc: "David S. Miller" 
Cc: Michal Simek 
Cc: Markus Elfring 
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 69 +++
 1 file changed, 45 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c 
b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 4041c75..2d15897 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1434,6 +1434,48 @@ static void axienet_dma_err_handler(unsigned long data)
 }
 
 /**
+ * axienet_dma_res_init - Initialize the DMA related resources of
+ *the axienet local structure.
+ * @lp: Pointer to axienet local structure
+ *
+ * Return: 0, on success
+ * Non-zero error value on failure.
+ *
+ * This function find the DMA node via pdev, map the DMA registers,
+ * and decode the DMA IRQs.
+ */
+static int axienet_dma_res_init(struct axienet_local *lp)
+{
+   struct resource dmares;
+   struct device_node *np;
+   int ret;
+
+   np = of_parse_phandle(lp->dev->of_node, "axistream-connected", 0);
+   if (!np) {
+   dev_err(lp->dev, "could not find DMA node\n");
+   ret = -ENODEV;
+   return ret;
+   }
+   ret = of_address_to_resource(np, 0, );
+   if (ret) {
+   dev_err(lp->dev, "unable to get DMA resource\n");
+   goto put_node;
+   }
+   lp->dma_regs = devm_ioremap_resource(lp->dev, );
+   if (IS_ERR(lp->dma_regs)) {
+   dev_err(lp->dev, "could not map DMA regs\n");
+   ret = PTR_ERR(lp->dma_regs);
+   goto put_node;
+   }
+   lp->rx_irq = irq_of_parse_and_map(np, 1);
+   lp->tx_irq = irq_of_parse_and_map(np, 0);
+
+put_node:
+   of_node_put(np);
+   return ret;
+}
+
+/**
  * axienet_probe - Axi Ethernet probe function.
  * @pdev:  Pointer to platform device structure.
  *
@@ -1448,11 +1490,10 @@ static void axienet_dma_err_handler(unsigned long data)
 static int axienet_probe(struct platform_device *pdev)
 {
int ret;
-   struct device_node *np;
struct axienet_local *lp;
struct net_device *ndev;
const void *mac_addr;
-   struct resource *ethres, dmares;
+   struct resource *ethres;
u32 value;
 
ndev = alloc_etherdev(sizeof(*lp));
@@ -1565,29 +1606,9 @@ static int axienet_probe(struct platform_device *pdev)
}
}
 
-   /* Find the DMA node, map the DMA registers, and decode the DMA IRQs */
-   np = of_parse_phandle(pdev->dev.of_node, "axistream-connected", 0);
-   if (!np) {
-   dev_err(>dev, "could not find DMA node\n");
-   ret = -ENODEV;
-   goto free_netdev;
-   }
-   ret = of_address_to_resource(np, 0, );
-   if (ret) {
-   dev_err(>dev, "unable to get DMA resource\n");
-   of_node_put(np);
-   goto free_netdev;
-   }
-   lp->dma_regs = devm_ioremap_resource(>dev, );
-   if (IS_ERR(lp->dma_regs)) {
-   dev_err(>dev, "could not map DMA regs\n");
-   ret = PTR_ERR(lp->dma_regs);
-   of_node_put(np);
+   ret = axienet_dma_res_init(lp);
+   if (ret)
goto free_netdev;
-   }
-   lp->rx_irq = irq_of_parse_and_map(np, 1);
-   lp->tx_irq = irq_of_parse_and_map(np, 0);
-   of_node_put(np);
if ((lp->rx_irq <= 0) || (lp->tx_irq <= 0)) {
dev_err(>dev, "could not determine irqs\n");
ret = -ENOMEM;
-- 
2.9.5

[PATCH 2/2] net: ethernet: ti: eliminated some duplicate code.

[Wen Yang]

Put the code that obtains device_node and the code that
uses it tightly together to remove duplicate resource
cleanup statements between them.

Signed-off-by: Wen Yang 
Reported-by: Markus Elfring 
Cc: Markus Elfring 
Cc: Wingman Kwok  (maintainer:TI NETCP ETHERNET DRIVER)
Cc: Murali Karicheri  (maintainer:TI NETCP ETHERNET DRIVER)
Cc: "David S. Miller"  (odd fixer:NETWORKING DRIVERS)
Cc: net...@vger.kernel.org (open list:TI NETCP ETHERNET DRIVER)
Cc: linux-kernel@vger.kernel.org (open list)
---
 drivers/net/ethernet/ti/netcp_ethss.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/ti/netcp_ethss.c 
b/drivers/net/ethernet/ti/netcp_ethss.c
index 0a920c5..748116a 100644
--- a/drivers/net/ethernet/ti/netcp_ethss.c
+++ b/drivers/net/ethernet/ti/netcp_ethss.c
@@ -3651,22 +3651,18 @@ static int gbe_probe(struct netcp_device *netcp_device, 
struct device *dev,
if (ret)
return ret;
 
-   interfaces = of_get_child_by_name(node, "interfaces");
-   if (!interfaces)
-   dev_err(dev, "could not find interfaces\n");
-
ret = netcp_txpipe_init(_dev->tx_pipe, netcp_device,
gbe_dev->dma_chan_name, gbe_dev->tx_queue_id);
-   if (ret) {
-   of_node_put(interfaces);
+   if (ret)
return ret;
-   }
 
ret = netcp_txpipe_open(_dev->tx_pipe);
-   if (ret) {
-   of_node_put(interfaces);
+   if (ret)
return ret;
-   }
+
+   interfaces = of_get_child_by_name(node, "interfaces");
+   if (!interfaces)
+   dev_err(dev, "could not find interfaces\n");
 
/* Create network interfaces */
INIT_LIST_HEAD(_dev->gbe_intf_head);
-- 
2.9.5

Re: No 8254 PIT & no HPET on new Intel N3350 platforms causes kernel panic during early boot

[Daniel Drake]

On Wed, Apr 3, 2019 at 7:21 PM Thomas Gleixner  wrote:
> Btw, one of those links you provided
>
>   https://www.manualslib.com/manual/1316475/Ecs-Ed20pa2.html?page=23
>
> claims that you have to disable MWAIT as well. No idea why. Is MWAIT
> disabled on your platform?

I don't have that option in the BIOS. However there's no mention of
"mwait" nor "mwaitx" in /proc/cpuinfo. Checking our more general
database of 202 x86_64 consumer products released over the last few
years, only 19 of them have mwait/mwaitx listed there and they tend to
be older platforms.

> We have early-quirks.c in arch/x86/kernel/ for that.

Nice, we should be able to work around the issue there, but I hope we
can find something better...

> For newer CPUs we might assume that:
>
>  1) The TSC and APIC timer are actually usable
>
>  2) The frequencies can be retrieved from CPUID or MSRs
>
> If #1 and #2 are reliable we can avoid the whole calibration and interrupt
> delivery mess.

Let's take a step back and re-examine the wider sequence of events
here (which I've now done thanks to your pointers).

1. In very early boot, we face the TSC calibration challenge, arriving
at determine_cpu_tsc_frequencies(). This function calculates CPU
frequency and TSC frequency separately.

For the CPU frequency, native_calibrate_cpu_early() tries to do it via
cpu_khz_from_cpuid() with CPUID leaf 0x16, but this is not available
on the platforms in question, which have max cpuid level 0x15.
cpu_khz_from_msr() is then tried, but that doesn't support this
platform either (looks like it only supports older SoC generations).
So now we arrive in quick_pit_calibrate(), which directly programs the
PIT and measures the TSC rate against the PIT ticks.

When the 8254 is ungated in the BIOS, this function fails early because:
if (pit_expect_msb(0xff, , )) {
/* returned at count=13, d1 is now 32118 */
for (i = 1; i <= MAX_QUICK_PIT_ITERATIONS; i++) {
if (!pit_expect_msb(0xff-i, , ))
/* returned at count=13, d2 is now 48595 */
break;

delta -= tsc;
/* delta is now 246741 */

/*
 * Extrapolate the error and fail fast if the error will
 * never be below 500 ppm.
 */
if (i == 1 &&
d1 + d2 >= (delta * MAX_QUICK_PIT_ITERATIONS) >> 11)
return 0;
/* this return statement is hit, the calculation is:
32118 + 48595 >= (246741 * 233) >> 11
*/

so the error was too high (I'm not sure why) and
determine_cpu_tsc_frequencies() records the CPU frequency as 0.

Then, comparing to when the 8254 is gated via the BIOS option, the
behaviour is surprising too.
In that case, the quick_calibrate_pit() loop runs through up to i=128,
at which point the error level is low enough to be accepted,
calculating the CPU frequency as 4448MHz (4x higher than reality).
During each loop iteration, pit_expect_msb() returns when the value
changes at count=63 (compared to 13 in the PIT-ungated case). Does
this suggest the PIT is not actually fully gated, it's just ticking a
lot slower than otherwise?

Anyway, back in determine_cpu_tsc_frequencies() with the CPU frequency
calibration done, we now do TSC calibration. This one succeeds in all
cases via native_calibrate_tsc()  using CPUID leaf 0x15 to read the
correct value. The TSC is 1094MHz.

Then, in both cases (8254 gated or not), the CPU frequency calculation
is discarded here, because it's wildly different from the TSC rate:
else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz)
cpu_khz = tsc_khz;

So it seems that this code already behaves along the lines you
describe: it gives more trust to the TSC value read in the modern way,
and does not get upset if the CPU frequency calibration against the
PIT didn't produce a meaningful result.


2. Significantly later during boot, x86_late_time_init() calls
hpet_time_init() which sets up either the PIT or HPET. However, as far
as I can see, there is no checking that the selected clock is actually
ticking. In the case of these affected platforms with the 8254 gated,
we sail right pass this point without a working clock source.

3. x86_late_time_init() then calls apic_intr_mode_init() ->
apic_bsp_setup() -> setup_IO_APIC() and at this point we reach
check_timer(), which attempts to verify/fixup IRQ0 delivery via the
IO-APIC. At this point we check that jiffies increments, and if not,
panic.

4. Some time later, naive_smp_prepare_cpus() calls
setup_boot_APIC_clock() -> setup_APIC_timer() which registers the
local APIC clocksource, replacing the previous PIT/HPET clocksource.
There's no check to make sure that the new clocksource is ticking, as
far as I can see.

5. Some time later, start_secondary() calls
start_secondary_APIC_clock() -> setup_APIC_timer() registering the
APIC clocksource (again? or just for another CPU core?).


Hopefully that analysis helps refine/elaborate the plan a bit more...

> That means we need the following decision logic:
>
>   1) If HPET is 

Re: [RFC PATCH 3/9] cpufreq: qcom: create a driver struct

[Viresh Kumar]

On 04-04-19, 07:09, Niklas Cassel wrote:
> create a driver struct to make it easier to free up all common
> resources, and only call dev_pm_opp_set_supported_hw() if the
> implementation has dynamically allocated versions.
> 
> Co-developed-by: Jorge Ramirez-Ortiz 
> Signed-off-by: Jorge Ramirez-Ortiz 
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/cpufreq/qcom-cpufreq-nvmem.c | 69 ++--
>  1 file changed, 46 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c 
> b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> index 652a1de2a5d4..366c65a7132a 100644
> --- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
> +++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
> @@ -43,6 +43,11 @@ enum _msm8996_version {
>   NUM_OF_MSM8996_VERSIONS,
>  };
>  
> +struct qcom_cpufreq_drv {

I would suggest renaming it a bit, around the purpose of this thing. Maybe like
struct supported_hw {} ? Or something else that you would like.

> + struct opp_table **opp_tables;
> + u32 *versions;

Maybe this can be just "u32 versions" instead and you won't need a separate
kzalloc.

> +};
> +
>  static struct platform_device *cpufreq_dt_pdev, *cpufreq_pdev;
>  
>  static enum _msm8996_version qcom_cpufreq_get_msm_id(void)
> @@ -76,12 +81,16 @@ static enum _msm8996_version qcom_cpufreq_get_msm_id(void)
>  
>  static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,
> struct nvmem_cell *speedbin_nvmem,
> -   u32 *versions)
> +   struct qcom_cpufreq_drv *drv)
>  {
>   size_t len;
>   u8 *speedbin;
>   enum _msm8996_version msm8996_version;
>  
> + drv->versions = kzalloc(sizeof(*drv->versions), GFP_KERNEL);
> + if (!drv->versions)
> + return -ENOMEM;
> +
>   msm8996_version = qcom_cpufreq_get_msm_id();
>   if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
>   dev_err(cpu_dev, "Not Snapdragon 820/821!");
> @@ -94,10 +103,10 @@ static int qcom_cpufreq_kryo_name_version(struct device 
> *cpu_dev,
>  
>   switch (msm8996_version) {
>   case MSM8996_V3:
> - *versions = 1 << (unsigned int)(*speedbin);
> + *drv->versions = 1 << (unsigned int)(*speedbin);
>   break;
>   case MSM8996_SG:
> - *versions = 1 << ((unsigned int)(*speedbin) + 4);
> + *drv->versions = 1 << ((unsigned int)(*speedbin) + 4);
>   break;

I see that versions will surely have a non-zero value here ? In that case you
can use it ... (see later)

>   default:
>   BUG();
> @@ -110,15 +119,14 @@ static int qcom_cpufreq_kryo_name_version(struct device 
> *cpu_dev,
>  
>  static int qcom_cpufreq_probe(struct platform_device *pdev)
>  {
> - struct opp_table **opp_tables;
> + struct qcom_cpufreq_drv *drv;
>   int (*get_version)(struct device *cpu_dev,
>  struct nvmem_cell *speedbin_nvmem,
> -u32 *versions);
> +struct qcom_cpufreq_drv *drv);
>   struct nvmem_cell *speedbin_nvmem;
>   struct device_node *np;
>   struct device *cpu_dev;
>   unsigned cpu;
> - u32 versions;
>   const struct of_device_id *match;
>   int ret;
>  
> @@ -141,23 +149,31 @@ static int qcom_cpufreq_probe(struct platform_device 
> *pdev)
>   return -ENOENT;
>   }
>  
> + drv = kzalloc(sizeof(*drv), GFP_KERNEL);
> + if (!drv)
> + return -ENOMEM;
> +
>   speedbin_nvmem = of_nvmem_cell_get(np, NULL);
>   of_node_put(np);
>   if (IS_ERR(speedbin_nvmem)) {
>   if (PTR_ERR(speedbin_nvmem) != -EPROBE_DEFER)
>   dev_err(cpu_dev, "Could not get nvmem cell: %ld\n",
>   PTR_ERR(speedbin_nvmem));
> - return PTR_ERR(speedbin_nvmem);
> + ret = PTR_ERR(speedbin_nvmem);
> + goto free_drv;
>   }
>  
> - ret = get_version(cpu_dev, speedbin_nvmem, );
> + ret = get_version(cpu_dev, speedbin_nvmem, drv);
>   nvmem_cell_put(speedbin_nvmem);
>   if (ret)
> - return ret;
> + goto free_drv;
>  
> - opp_tables = kcalloc(num_possible_cpus(), sizeof(*opp_tables), 
> GFP_KERNEL);
> - if (!opp_tables)
> - return -ENOMEM;
> + drv->opp_tables = kcalloc(num_possible_cpus(), sizeof(*drv->opp_tables),
> +   GFP_KERNEL);
> + if (!drv->opp_tables) {
> + ret = -ENOMEM;
> + goto free_drv;
> + }
>  
>   for_each_possible_cpu(cpu) {
>   cpu_dev = get_cpu_device(cpu);
> @@ -166,10 +182,12 @@ static int qcom_cpufreq_probe(struct platform_device 
> *pdev)
>   goto free_opp;
>   }
>  
> - opp_tables[cpu] = dev_pm_opp_set_supported_hw(cpu_dev,
> -   , 1);
> -

Re: [PATCH v3 1/7] clkdev: Hold clocks_mutex while iterating clocks list

[Vaittinen, Matti]

On Mon, 2019-04-08 at 23:21 +0100, Russell King - ARM Linux admin
wrote:
> On Mon, Apr 08, 2019 at 10:00:02AM -0700, Stephen Boyd wrote:
> > Quoting Matti Vaittinen (2019-04-08 03:49:41)
> > > On Fri, Apr 05, 2019 at 01:37:24PM -0700, Stephen Boyd wrote:
> > > > Quoting Vaittinen, Matti (2019-04-04 23:51:43)
> > > > > On Thu, 2019-04-04 at 14:53 -0700, Stephen Boyd wrote:
> > > > > > We recently introduced a change to support devm clk
> > > > > > lookups. That
> > > > > > change
> > > > > > introduced a code-path that used clk_find() without holding
> > > > > > the
> > > > > > 'clocks_mutex'. Unfortunately, clk_find() iterates over the
> > > > > > 'clocks'
> > > > > > list and so we need to prevent the list from being modified
> > > > > > while
> > > > > > iterating over it by holding the mutex. Similarly, we don't
> > > > > > need to
> > > > > > hold
> > > > > > the 'clocks_mutex' besides when we're dereferencing the
> > > > > > clk_lookup
> > > > > > pointer
> > > > > 
> > > > > /// Snip
> > > > > 
> > > > > > -out:
> > > > > > +static struct clk_lookup *clk_find(const char *dev_id,
> > > > > > const char
> > > > > > *con_id)
> > > > > > +{
> > > > > > + struct clk_lookup *cl;
> > > > > > +
> > > > > > + mutex_lock(_mutex);
> > > > > > + cl = __clk_find(dev_id, con_id);
> > > > > >   mutex_unlock(_mutex);
> > > > > >  
> > > > > > - return cl ? clk : ERR_PTR(-ENOENT);
> > > > > > + return cl;
> > > > > > +}
> > > > > 
> > > > > I am not an expert on this but reading commit message abowe
> > > > > and seeing
> > > > > the code for clk_find() looks a bit scary. If I understand it
> > > > > correctly, the clocks_mutex should be held when dereferencing
> > > > > the
> > > > > clk_lookup returned by clk_find. The clk_find implementation
> > > > > drops the
> > > > > lock before returning - which makes me think I miss something
> > > > > here. How
> > > > > can the caller ever safely dereference returned clk_lookup
> > > > > pointer?
> > > > > Just reading abowe makes me think that lock should be taken
> > > > > by whoever
> > > > > is calling the clk_find, and dropped only after caller has
> > > > > used the
> > > > > found clk_lookup for whatever caller intends to use it. Maybe
> > > > > I am
> > > > > missing something?
> > > > > 
> > > > 
> > > > The only user after this patch (devm) is doing a pointer
> > > > comparison so
> > > > it looks OK. But yes, in general there shouldn't be users of
> > > > clk_find()
> > > > that dereference the pointer because there isn't any protection
> > > > besides
> > > > the mutex.
> > > 
> > > If the only (intended) user for clk_find is
> > > devm_clk_release_clkdev,
> > > then we might want to write it in devm_clk_release_clkdev - just
> > > to
> > > avoid similar errors (as I did with devm) in the future? I might
> > > even
> > > consider renaming __clk_find to clk_find or to clk_find_unsafe -
> > > but
> > > that's all just nitpicking :) Go with what you like to maintain
> > > :D
> > > 
> > 
> > Sure. I was thinking along the same lines after you asked.
> 
> This is rubbish.  The reason clk_find() doesn't take the lock is that
> you _need_ to hold the lock while you dereference the clk_lookup
> data.

I think we all agreed on this already. Stephen pointed out that the
current user(s) of clk_find() do _not_ dereference the pointer.

> The lock isn't protecting just the lookup, it protects what you do
> with
> the result of the lookup as well.

And we agreed on this too.

Br,
Matti Vaittinen

RE: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal binding

[Anson Huang]

Ping...
Can anyone provide some suggestion about how to proceed next?

Best Regards!
Anson Huang

> -Original Message-
> From: Anson Huang
> Sent: 2019年3月26日 10:45
> To: 'Rob Herring' ; 'edubez...@gmail.com'
> 
> Cc: 'mark.rutl...@arm.com' ;
> 'shawn...@kernel.org' ; 's.ha...@pengutronix.de'
> ; 'ker...@pengutronix.de'
> ; 'feste...@gmail.com' ;
> 'catalin.mari...@arm.com' ;
> 'will.dea...@arm.com' ; 'rui.zh...@intel.com'
> ; 'edubez...@gmail.com' ;
> 'daniel.lezc...@linaro.org' ; Aisheng Dong
> ; 'ulf.hans...@linaro.org'
> ; 'sb...@kernel.org' ; Daniel
> Baluta ; Andy Gross ;
> 'horms+rene...@verge.net.au' ;
> 'he...@sntech.de' ; 'a...@arndb.de' ;
> 'maxime.rip...@bootlin.com' ;
> 'bjorn.anders...@linaro.org' ;
> 'ja...@amarulasolutions.com' ;
> 'enric.balle...@collabora.com' ;
> 'marc.w.gonza...@free.fr' ; 'o...@lixom.net'
> ; 'devicet...@vger.kernel.org'
> ; 'linux-kernel@vger.kernel.org'  ker...@vger.kernel.org>; 'linux-arm-ker...@lists.infradead.org'  ker...@lists.infradead.org>; 'linux...@vger.kernel.org'  p...@vger.kernel.org>; dl-linux-imx 
> Subject: RE: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal binding
> 
> Ping...
> 
> Hi, Eduardo
>   What is your opinion about where to put the HW resource ID in DT?
> 
> Best Regards!
> Anson Huang
> 
> > -Original Message-
> > From: Anson Huang
> > Sent: 2019年3月13日 16:12
> > To: 'Rob Herring' ; 'edubez...@gmail.com'
> > 
> > Cc: 'mark.rutl...@arm.com' ;
> > 'shawn...@kernel.org' ;
> 's.ha...@pengutronix.de'
> > ; 'ker...@pengutronix.de'
> > ; 'feste...@gmail.com' ;
> > 'catalin.mari...@arm.com' ;
> > 'will.dea...@arm.com' ; 'rui.zh...@intel.com'
> > ; 'edubez...@gmail.com' ;
> > 'daniel.lezc...@linaro.org' ; Aisheng Dong
> > ; 'ulf.hans...@linaro.org'
> > ; 'sb...@kernel.org' ;
> > Daniel Baluta ; Andy Gross
> > ; 'horms+rene...@verge.net.au'
> > ; 'he...@sntech.de' ;
> > 'a...@arndb.de' ; 'maxime.rip...@bootlin.com'
> > ; 'bjorn.anders...@linaro.org'
> > ; 'ja...@amarulasolutions.com'
> > ; 'enric.balle...@collabora.com'
> > ; 'marc.w.gonza...@free.fr'
> ; 'o...@lixom.net'
> > ; 'devicet...@vger.kernel.org'
> > ; 'linux-kernel@vger.kernel.org'  > ker...@vger.kernel.org>; 'linux-arm-ker...@lists.infradead.org'
> > ; 'linux...@vger.kernel.org'
> > ; dl-linux-imx 
> > Subject: RE: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal
> > binding
> >
> > Ping...
> > Hi, Eduardo
> > Can you take a look at this thread? Thanks.
> >
> >
> > Best Regards!
> > Anson Huang
> >
> > > -Original Message-
> > > From: Anson Huang
> > > Sent: 2019年3月6日 13:27
> > > To: 'Rob Herring' ; 'edubez...@gmail.com'
> > > 
> > > Cc: 'mark.rutl...@arm.com' ;
> > > 'shawn...@kernel.org' ;
> > 's.ha...@pengutronix.de'
> > > ; 'ker...@pengutronix.de'
> > > ; 'feste...@gmail.com'
> ;
> > > 'catalin.mari...@arm.com' ;
> > > 'will.dea...@arm.com' ; 'rui.zh...@intel.com'
> > > ; 'edubez...@gmail.com'
> ;
> > > 'daniel.lezc...@linaro.org' ; Aisheng
> > > Dong ; 'ulf.hans...@linaro.org'
> > > ; 'sb...@kernel.org' ;
> > > Daniel Baluta ; Andy Gross
> > > ; 'horms+rene...@verge.net.au'
> > > ; 'he...@sntech.de' ;
> > > 'a...@arndb.de' ; 'maxime.rip...@bootlin.com'
> > > ; 'bjorn.anders...@linaro.org'
> > > ; 'ja...@amarulasolutions.com'
> > > ; 'enric.balle...@collabora.com'
> > > ; 'marc.w.gonza...@free.fr'
> > ; 'o...@lixom.net'
> > > ; 'devicet...@vger.kernel.org'
> > > ; 'linux-kernel@vger.kernel.org'  > > ker...@vger.kernel.org>; 'linux-arm-ker...@lists.infradead.org'
> > > ; 'linux...@vger.kernel.org'
> > > ; dl-linux-imx 
> > > Subject: RE: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal
> > > binding
> > >
> > > Ping...
> > >
> > > Hi, Eduardo
> > >   Looks like we are going around in circle, can we make decision of
> > > which direction to go?
> > >
> > > Best Regards!
> > > Anson Huang
> > >
> > > > -Original Message-
> > > > From: Anson Huang
> > > > Sent: 2019年3月1日 9:41
> > > > To: 'Rob Herring' ; edubez...@gmail.com
> > > > Cc: mark.rutl...@arm.com; shawn...@kernel.org;
> > > s.ha...@pengutronix.de;
> > > > ker...@pengutronix.de; feste...@gmail.com;
> > catalin.mari...@arm.com;
> > > > will.dea...@arm.com; rui.zh...@intel.com; edubez...@gmail.com;
> > > > daniel.lezc...@linaro.org; Aisheng Dong ;
> > > > ulf.hans...@linaro.org; sb...@kernel.org; Daniel Baluta
> > > > ; Andy Gross ;
> > > > horms+rene...@verge.net.au; he...@sntech.de; a...@arndb.de;
> > > > maxime.rip...@bootlin.com; bjorn.anders...@linaro.org;
> > > > ja...@amarulasolutions.com; enric.balle...@collabora.com;
> > > > marc.w.gonza...@free.fr; o...@lixom.net;
> > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > linux-arm-ker...@lists.infradead.org;
> > > > linux- p...@vger.kernel.org; dl-linux-imx 
> > > > Subject: RE: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal
> > > > binding
> > > >
> > > > Hi, Rob/Eduardo
> > > >
> > > > Best Regards!
> > > > Anson Huang
> > > >
> > > > > -Original Message-
> > > > > From: Rob Herring 

Re: [PATCH] fat: issue flush after the writeback of FAT

[OGAWA Hirofumi]

Hou Tao  writes:

> fsync() needs to make sure the data & meta-data of file are persistent
> after the return of fsync(), even when a power-failure occurs later.
> In the case of fat-fs, the FAT belongs to the meta-data of file,
> so we need to issue a flush after the writeback of FAT instead before.
>
> Also bail out early when any stage of fsync fails.
>
> Signed-off-by: Hou Tao 

Looks good.

Acked-by: OGAWA Hirofumi 

> ---
>  fs/fat/file.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/fs/fat/file.c b/fs/fat/file.c
> index b3bed32946b1..0e3ed79fcc3f 100644
> --- a/fs/fat/file.c
> +++ b/fs/fat/file.c
> @@ -193,12 +193,17 @@ static int fat_file_release(struct inode *inode, struct 
> file *filp)
>  int fat_file_fsync(struct file *filp, loff_t start, loff_t end, int datasync)
>  {
>   struct inode *inode = filp->f_mapping->host;
> - int res, err;
> + int err;
> +
> + err = __generic_file_fsync(filp, start, end, datasync);
> + if (err)
> + return err;
>  
> - res = generic_file_fsync(filp, start, end, datasync);
>   err = sync_mapping_buffers(MSDOS_SB(inode->i_sb)->fat_inode->i_mapping);
> + if (err)
> + return err;
>  
> - return res ? res : err;
> + return blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL);
>  }

-- 
OGAWA Hirofumi 

RE: [PATCH] net: lan78xx: fix "enabled interrupts" warninig

[RaghuramChary.Jallipalli]

> > Correct, IRQ domain is generally used in chained irq controllers.
> > Yes, We need to check why irq domain is used in the current driver.
> >
> 
> It's introduced in the commit cc89c323a30e
> 
Thanks Jisheng, Will check and get back ASAP.

Thanks

Re: [PATCH] fat: issue flush after the writeback of FAT

[OGAWA Hirofumi]

"Darrick J. Wong"  writes:

>> +err = __generic_file_fsync(filp, start, end, datasync);
>> +if (err)
>> +return err;
>>  
>> -res = generic_file_fsync(filp, start, end, datasync);
>>  err = sync_mapping_buffers(MSDOS_SB(inode->i_sb)->fat_inode->i_mapping);
>
> Huh.  I would've thought that flushing the FAT would also be required
> at the end of a WB_SYNC_ALL (aka data integrity) writepages call?

In fatfs implement, FAT area is flushed by sync_mapping_buffers(fat_inode). 
(FAT buffer is dirtied only by using bh->b_assoc_map to fat_inode)

Thanks.
-- 
OGAWA Hirofumi 

linux-next: manual merge of the rtc tree with the omap tree

[Stephen Rothwell]

Hi all,

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

  drivers/rtc/rtc-omap.c

between commit:

  6256f7f7f217 ("rtc: OMAP: Add support for rtc-only mode")

from the omap tree and commit:

  35118b7a4ea0 ("rtc: omap: let the core handle range")

from the rtc tree.

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

-- 
Cheers,
Stephen Rothwell


pgpZHofh1m4iv.pgp
Description: OpenPGP digital signature

mmotm 2019-04-08-22-14 uploaded

[akpm]

The mm-of-the-moment snapshot 2019-04-08-22-14 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/



The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 5.1-rc4:
(patches marked "*" will be included in linux-next)

  origin.patch
* checkpatch-dont-interpret-stack-dumps-as-commit-ids.patch
* mm-add-sys-kernel-slab-cache-cache_dma32.patch
* 
coredump-fix-race-condition-between-mmget_not_zero-get_task_mm-and-core-dumping.patch
* userfaultfd-use-rcu-to-free-the-task-struct-when-fork-fails.patch
* slab-store-tagged-freelist-for-off-slab-slabmgmt.patch
* mm-swapoff-shmem_find_swap_entries-filter-out-other-types.patch
* mm-swapoff-remove-too-limiting-swap_unuse_max_tries.patch
* mm-swapoff-take-notice-of-completion-sooner.patch
* mm-swapoff-shmem_unuse-stop-eviction-without-igrab.patch
* 
mm-memory_hotplug-do-not-unlock-when-fails-to-take-the-device_hotplug_lock.patch
* prctl-fix-false-positive-in-validate_prctl_map.patch
* scripts-spellingtxt-add-more-typos-to-spellingtxt-and-sort.patch
* arch-sh-boards-mach-dreamcast-irqc-remove-duplicate-header.patch
* debugobjects-move-printk-out-of-db-lock-critical-sections.patch
* ocfs2-use-common-file-type-conversion.patch
* ocfs2-fix-ocfs2-read-inode-data-panic-in-ocfs2_iget.patch
* ocfs2-clear-zero-in-unaligned-direct-io.patch
* ocfs2-clear-zero-in-unaligned-direct-io-checkpatch-fixes.patch
* ocfs2-wait-for-recovering-done-after-direct-unlock-request.patch
* ocfs2-checkpoint-appending-truncate-log-transaction-before-flushing.patch
* ramfs-support-o_tmpfile.patch
  mm.patch
* list-add-function-list_rotate_to_front.patch
* slob-respect-list_head-abstraction-layer.patch
* slob-use-slab_list-instead-of-lru.patch
* slub-add-comments-to-endif-pre-processor-macros.patch
* slub-use-slab_list-instead-of-lru.patch
* slab-use-slab_list-instead-of-lru.patch
* mm-remove-stale-comment-from-page-struct.patch
* slub-remove-useless-kmem_cache_debug-before-remove_full.patch
* mm-slab-remove-unneed-check-in-cpuup_canceled.patch
* slub-update-the-comment-about-slab-frozen.patch
* mm-vmscan-drop-zone-id-from-kswapd-tracepoints.patch
* mm-cma_debugc-fix-the-break-condition-in-cma_maxchunk_get.patch
* userfaultfd-sysctl-add-vmunprivileged_userfaultfd.patch
* userfaultfd-sysctl-add-vmunprivileged_userfaultfd-fix.patch
* page-cache-store-only-head-pages-in-i_pages.patch
* page-cache-store-only-head-pages-in-i_pages-fix.patch
* page-cache-store-only-head-pages-in-i_pages-fix-fix.patch
* mm-page_alloc-disallow-__gfp_comp-in-alloc_pages_exact.patch
* mm-move-recent_rotated-pages-calculation-to-shrink_inactive_list.patch
* mm-move-nr_deactivate-accounting-to-shrink_active_list.patch
* mm-move-nr_deactivate-accounting-to-shrink_active_list-fix.patch
* mm-remove-pages_to_free-argument-of-move_active_pages_to_lru.patch
* mm-generalize-putback-scan-functions.patch
* mm-gup-replace-get_user_pages_longterm-with-foll_longterm.patch
* mm-gup-replace-get_user_pages_longterm-with-foll_longterm-v3.patch
* mm-gup-change-write-parameter-to-flags-in-fast-walk.patch
* mm-gup-change-gup-fast-to-use-flags-rather-than-a-write-bool.patch
* mm-gup-add-foll_longterm-capability-to-gup-fast.patch
* mm-gup-add-foll_longterm-capability-to-gup-fast-v3.patch
* ib-hfi1-use-the-new-foll_longterm-flag-to-get_user_pages_fast.patch
* ib-hfi1-use-the-new-foll_longterm-flag-to-get_user_pages_fast-v3.patch
* ib-qib-use-the-new-foll_longterm-flag-to-get_user_pages_fast.patch
* 

Re: [PATCH 3/3] ARM: omap2: move platform-specific asm-offset.h to arch/arm/mach-omap2

[Keerthy]

On 09/04/19 10:37 AM, Masahiro Yamada wrote:

On Tue, Apr 9, 2019 at 2:00 PM Keerthy  wrote:




On 08/04/19 9:48 PM, Tony Lindgren wrote:

Hi,

* Masahiro Yamada  [190408 07:56]:

 is only generated and included
by arch/arm/mach-omap2/, so it does not need to reside in the
globally visible include/generated/.

I moved and renamed it to arch/arm/mach-omap2/pm-asm-offsets.h
since the prefix 'omap2-' is just redundant in mach-omap2/.

Signed-off-by: Masahiro Yamada 
---

Can this be applied to ARM-SOC tree in a series?
(with Ack from the platform sub-maintainer.)

ti-pm-asm-offsets.h does not need to reside in include/generated/,
but you may ask "Why must it get out of include/generated/?"

My main motivation is to avoid a race condition in the currently
proposed patch:

https://lore.kernel.org/patchwork/patch/1052763/

This patch tries to embed some build artifacts into the kernel.

If arch/arm/mach-omap2/ and kernel/ are built at the same time,
it may embed a truncated file.


Looks like a nice improvment to me, adding Keerthy and Dave to Cc.

Keerthy and Dave, can you please test this series with am3 and am4
PM code?


Tested for Deep Sleep0 on AM33xx Beaglebone-black.
Tested for Deep Sleep0 on AM437x-gp-evm.

Applied this on top of Tony's for-next with the gpio patch
required for RTC+DDR mode on am437x-gp-evm.


Was it applied to TI tree?

If so ...

Arnd, Olof,
Please just ignore this patch
since it looks it was already applied to TI tree.


Masahiro Yamada,

No i manually applied this on top.

Regards,
Keerthy



Thanks.
Masahiro Yamada





Tested-by: Keerthy 



Regards,

Tony


   arch/arm/mach-omap2/.gitignore  | 1 +
   arch/arm/mach-omap2/Makefile| 5 +++--
   arch/arm/mach-omap2/sleep33xx.S | 2 +-
   arch/arm/mach-omap2/sleep43xx.S | 2 +-
   4 files changed, 6 insertions(+), 4 deletions(-)
   create mode 100644 arch/arm/mach-omap2/.gitignore

diff --git a/arch/arm/mach-omap2/.gitignore b/arch/arm/mach-omap2/.gitignore
new file mode 100644
index ..79a8d6ea7152
--- /dev/null
+++ b/arch/arm/mach-omap2/.gitignore
@@ -0,0 +1 @@
+pm-asm-offsets.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 85d1b13c9215..26baeb6477af 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -236,9 +236,10 @@ obj-y   += 
omap_phy_internal.o

   obj-$(CONFIG_MACH_OMAP2_TUSB6010)  += usb-tusb6010.o

-include/generated/ti-pm-asm-offsets.h: arch/arm/mach-omap2/pm-asm-offsets.s 
FORCE
+$(obj)/pm-asm-offsets.h: $(obj)/pm-asm-offsets.s FORCE
  $(call filechk,offsets,__TI_PM_ASM_OFFSETS_H__)

-$(obj)/sleep33xx.o $(obj)/sleep43xx.o: include/generated/ti-pm-asm-offsets.h
+$(obj)/sleep33xx.o $(obj)/sleep43xx.o: $(obj)/pm-asm-offsets.h

   targets += pm-asm-offsets.s
+clean-files += pm-asm-offsets.h
diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S
index 47a816468cdb..a003769121aa 100644
--- a/arch/arm/mach-omap2/sleep33xx.S
+++ b/arch/arm/mach-omap2/sleep33xx.S
@@ -6,7 +6,6 @@
* Dave Gerlach, Vaibhav Bedia
*/

-#include 
   #include 
   #include 
   #include 
@@ -15,6 +14,7 @@

   #include "iomap.h"
   #include "cm33xx.h"
+#include "pm-asm-offsets.h"

   #define AM33XX_CM_CLKCTRL_MODULESTATE_DISABLED 0x0003
   #define AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE   0x0003
diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S
index 5b9343b58fc7..aa288f361c5e 100644
--- a/arch/arm/mach-omap2/sleep43xx.S
+++ b/arch/arm/mach-omap2/sleep43xx.S
@@ -6,7 +6,6 @@
* Dave Gerlach, Vaibhav Bedia
*/

-#include 
   #include 
   #include 
   #include 
@@ -19,6 +18,7 @@
   #include "iomap.h"
   #include "omap-secure.h"
   #include "omap44xx.h"
+#include "pm-asm-offsets.h"
   #include "prm33xx.h"
   #include "prcm43xx.h"

--
2.17.1





--
Best Regards
Masahiro Yamada

Re: [PATCH 3/3] ARM: omap2: move platform-specific asm-offset.h to arch/arm/mach-omap2

[Masahiro Yamada]

On Tue, Apr 9, 2019 at 2:00 PM Keerthy  wrote:
>
>
>
> On 08/04/19 9:48 PM, Tony Lindgren wrote:
> > Hi,
> >
> > * Masahiro Yamada  [190408 07:56]:
> >>  is only generated and included
> >> by arch/arm/mach-omap2/, so it does not need to reside in the
> >> globally visible include/generated/.
> >>
> >> I moved and renamed it to arch/arm/mach-omap2/pm-asm-offsets.h
> >> since the prefix 'omap2-' is just redundant in mach-omap2/.
> >>
> >> Signed-off-by: Masahiro Yamada 
> >> ---
> >>
> >> Can this be applied to ARM-SOC tree in a series?
> >> (with Ack from the platform sub-maintainer.)
> >>
> >> ti-pm-asm-offsets.h does not need to reside in include/generated/,
> >> but you may ask "Why must it get out of include/generated/?"
> >>
> >> My main motivation is to avoid a race condition in the currently
> >> proposed patch:
> >>
> >> https://lore.kernel.org/patchwork/patch/1052763/
> >>
> >> This patch tries to embed some build artifacts into the kernel.
> >>
> >> If arch/arm/mach-omap2/ and kernel/ are built at the same time,
> >> it may embed a truncated file.
> >
> > Looks like a nice improvment to me, adding Keerthy and Dave to Cc.
> >
> > Keerthy and Dave, can you please test this series with am3 and am4
> > PM code?
>
> Tested for Deep Sleep0 on AM33xx Beaglebone-black.
> Tested for Deep Sleep0 on AM437x-gp-evm.
>
> Applied this on top of Tony's for-next with the gpio patch
> required for RTC+DDR mode on am437x-gp-evm.

Was it applied to TI tree?

If so ...

Arnd, Olof,
Please just ignore this patch
since it looks it was already applied to TI tree.

Thanks.
Masahiro Yamada




> Tested-by: Keerthy 
>
> >
> > Regards,
> >
> > Tony
> >
> >>   arch/arm/mach-omap2/.gitignore  | 1 +
> >>   arch/arm/mach-omap2/Makefile| 5 +++--
> >>   arch/arm/mach-omap2/sleep33xx.S | 2 +-
> >>   arch/arm/mach-omap2/sleep43xx.S | 2 +-
> >>   4 files changed, 6 insertions(+), 4 deletions(-)
> >>   create mode 100644 arch/arm/mach-omap2/.gitignore
> >>
> >> diff --git a/arch/arm/mach-omap2/.gitignore 
> >> b/arch/arm/mach-omap2/.gitignore
> >> new file mode 100644
> >> index ..79a8d6ea7152
> >> --- /dev/null
> >> +++ b/arch/arm/mach-omap2/.gitignore
> >> @@ -0,0 +1 @@
> >> +pm-asm-offsets.h
> >> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> >> index 85d1b13c9215..26baeb6477af 100644
> >> --- a/arch/arm/mach-omap2/Makefile
> >> +++ b/arch/arm/mach-omap2/Makefile
> >> @@ -236,9 +236,10 @@ obj-y   += 
> >> omap_phy_internal.o
> >>
> >>   obj-$(CONFIG_MACH_OMAP2_TUSB6010)  += usb-tusb6010.o
> >>
> >> -include/generated/ti-pm-asm-offsets.h: 
> >> arch/arm/mach-omap2/pm-asm-offsets.s FORCE
> >> +$(obj)/pm-asm-offsets.h: $(obj)/pm-asm-offsets.s FORCE
> >>  $(call filechk,offsets,__TI_PM_ASM_OFFSETS_H__)
> >>
> >> -$(obj)/sleep33xx.o $(obj)/sleep43xx.o: 
> >> include/generated/ti-pm-asm-offsets.h
> >> +$(obj)/sleep33xx.o $(obj)/sleep43xx.o: $(obj)/pm-asm-offsets.h
> >>
> >>   targets += pm-asm-offsets.s
> >> +clean-files += pm-asm-offsets.h
> >> diff --git a/arch/arm/mach-omap2/sleep33xx.S 
> >> b/arch/arm/mach-omap2/sleep33xx.S
> >> index 47a816468cdb..a003769121aa 100644
> >> --- a/arch/arm/mach-omap2/sleep33xx.S
> >> +++ b/arch/arm/mach-omap2/sleep33xx.S
> >> @@ -6,7 +6,6 @@
> >>* Dave Gerlach, Vaibhav Bedia
> >>*/
> >>
> >> -#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -15,6 +14,7 @@
> >>
> >>   #include "iomap.h"
> >>   #include "cm33xx.h"
> >> +#include "pm-asm-offsets.h"
> >>
> >>   #define AM33XX_CM_CLKCTRL_MODULESTATE_DISABLED 
> >> 0x0003
> >>   #define AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE   0x0003
> >> diff --git a/arch/arm/mach-omap2/sleep43xx.S 
> >> b/arch/arm/mach-omap2/sleep43xx.S
> >> index 5b9343b58fc7..aa288f361c5e 100644
> >> --- a/arch/arm/mach-omap2/sleep43xx.S
> >> +++ b/arch/arm/mach-omap2/sleep43xx.S
> >> @@ -6,7 +6,6 @@
> >>* Dave Gerlach, Vaibhav Bedia
> >>*/
> >>
> >> -#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -19,6 +18,7 @@
> >>   #include "iomap.h"
> >>   #include "omap-secure.h"
> >>   #include "omap44xx.h"
> >> +#include "pm-asm-offsets.h"
> >>   #include "prm33xx.h"
> >>   #include "prcm43xx.h"
> >>
> >> --
> >> 2.17.1
> >>



--
Best Regards
Masahiro Yamada

[PATCH V7 3/4] arm64: dts: freescale: imx8qxp: enable scu general irq channel

[Anson Huang]

On i.MX8QXP, SCU uses MU1 general interrupt channel #3 to notify
user for IRQs of RTC alarm, thermal alarm and WDOG etc., mailbox
RX doorbell mode is used for this function, this patch adds
support for it.

Signed-off-by: Anson Huang 
Reviewed-by: Dong Aisheng 
---
No changes.
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 0cb9398..70ef3db 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -21,6 +21,7 @@
mmc1 = 
mmc2 = 
serial0 = _lpuart0;
+   mu1 = _mu1;
};
 
cpus {
@@ -117,7 +118,8 @@
scu {
compatible = "fsl,imx-scu";
mbox-names = "tx0", "tx1", "tx2", "tx3",
-"rx0", "rx1", "rx2", "rx3";
+"rx0", "rx1", "rx2", "rx3",
+"gip3";
mboxes = <_mu1 0 0
  _mu1 0 1
  _mu1 0 2
@@ -125,7 +127,8 @@
  _mu1 1 0
  _mu1 1 1
  _mu1 1 2
- _mu1 1 3>;
+ _mu1 1 3
+ _mu1 3 3>;
 
clk: clock-controller {
compatible = "fsl,imx8qxp-clk";
-- 
2.7.4

[PATCH V7 2/4] firmware: imx: enable imx scu general irq function

[Anson Huang]

The System Controller Firmware (SCFW) controls RTC, thermal
and WDOG etc., these resources' interrupt function are managed
by SCU. When any IRQ pending, SCU will notify Linux via MU general
interrupt channel #3, and Linux kernel needs to call SCU APIs
to get IRQ status and notify each module to handle the interrupt.

Since there is no data transmission for SCU IRQ notification, so
doorbell mode is used for this MU channel, and SCU driver will
use notifier mechanism to broadcast to every module which registers
the SCU block notifier.

Signed-off-by: Anson Huang 
Reviewed-by: Dong Aisheng 
---
Changes since V6:
- improve imx_scu_irq_enable() function name to 
imx_scu_irq_group_enable();
- make imx_scu_irq_group_enable() function return int;
---
 drivers/firmware/imx/Makefile  |   2 +-
 drivers/firmware/imx/imx-scu-irq.c | 168 +
 drivers/firmware/imx/imx-scu.c |   6 ++
 include/linux/firmware/imx/sci.h   |   5 ++
 4 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/imx/imx-scu-irq.c

diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 1b2e15b..802c4ad 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o
+obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o imx-scu-irq.o
 obj-$(CONFIG_IMX_SCU_PD)   += scu-pd.o
diff --git a/drivers/firmware/imx/imx-scu-irq.c 
b/drivers/firmware/imx/imx-scu-irq.c
new file mode 100644
index 000..043833a
--- /dev/null
+++ b/drivers/firmware/imx/imx-scu-irq.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ *
+ * Implementation of the SCU IRQ functions using MU.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#define IMX_SC_IRQ_FUNC_ENABLE 1
+#define IMX_SC_IRQ_FUNC_STATUS 2
+#define IMX_SC_IRQ_NUM_GROUP   4
+
+static u32 mu_resource_id;
+
+struct imx_sc_msg_irq_get_status {
+   struct imx_sc_rpc_msg hdr;
+   union {
+   struct {
+   u16 resource;
+   u8 group;
+   u8 reserved;
+   } __packed req;
+   struct {
+   u32 status;
+   } resp;
+   } data;
+};
+
+struct imx_sc_msg_irq_enable {
+   struct imx_sc_rpc_msg hdr;
+   u32 mask;
+   u16 resource;
+   u8 group;
+   u8 enable;
+} __packed;
+
+static struct imx_sc_ipc *imx_sc_irq_ipc_handle;
+static struct work_struct imx_sc_irq_work;
+static ATOMIC_NOTIFIER_HEAD(imx_scu_irq_notifier_chain);
+
+int imx_scu_irq_register_notifier(struct notifier_block *nb)
+{
+   return atomic_notifier_chain_register(
+   _scu_irq_notifier_chain, nb);
+}
+EXPORT_SYMBOL(imx_scu_irq_register_notifier);
+
+int imx_scu_irq_unregister_notifier(struct notifier_block *nb)
+{
+   return atomic_notifier_chain_unregister(
+   _scu_irq_notifier_chain, nb);
+}
+EXPORT_SYMBOL(imx_scu_irq_unregister_notifier);
+
+static int imx_scu_irq_notifier_call_chain(unsigned long status, u8 *group)
+{
+   return atomic_notifier_call_chain(_scu_irq_notifier_chain,
+   status, (void *)group);
+}
+
+static void imx_scu_irq_work_handler(struct work_struct *work)
+{
+   struct imx_sc_msg_irq_get_status msg;
+   struct imx_sc_rpc_msg *hdr = 
+   u32 irq_status;
+   int ret;
+   u8 i;
+
+   for (i = 0; i < IMX_SC_IRQ_NUM_GROUP; i++) {
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_IRQ;
+   hdr->func = IMX_SC_IRQ_FUNC_STATUS;
+   hdr->size = 2;
+
+   msg.data.req.resource = mu_resource_id;
+   msg.data.req.group = i;
+
+   ret = imx_scu_call_rpc(imx_sc_irq_ipc_handle, , true);
+   if (ret) {
+   pr_err("get irq group %d status failed, ret %d\n",
+  i, ret);
+   return;
+   }
+
+   irq_status = msg.data.resp.status;
+   if (!irq_status)
+   continue;
+
+   imx_scu_irq_notifier_call_chain(irq_status, );
+   }
+}
+
+int imx_scu_irq_group_enable(u8 group, u32 mask, u8 enable)
+{
+   struct imx_sc_msg_irq_enable msg;
+   struct imx_sc_rpc_msg *hdr = 
+   int ret;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_IRQ;
+   hdr->func = IMX_SC_IRQ_FUNC_ENABLE;
+   hdr->size = 3;
+
+   msg.resource = mu_resource_id;
+   msg.group = group;
+   msg.mask = mask;
+   msg.enable = enable;
+
+   ret = imx_scu_call_rpc(imx_sc_irq_ipc_handle, , true);
+   if (ret)
+   pr_err("enable irq failed, group %d, mask %d, ret %d\n",
+   group, mask, ret);
+
+   return ret;
+}
+EXPORT_SYMBOL(imx_scu_irq_group_enable);
+
+static void 

[PATCH V7 4/4] rtc: imx-sc: add rtc alarm support

[Anson Huang]

Add i.MX system controller RTC alarm support, the RTC alarm
is implemented via SIP(silicon provider) runtime service call
and ARM-Trusted-Firmware will communicate with system controller
via MU(message unit) IPC to set RTC alarm. When RTC alarm fires,
system controller will generate a common MU irq event and notify
system controller RTC driver to handle the irq event.

Signed-off-by: Anson Huang 
Reviewed-by: Dong Aisheng 
---
Changes since V6:
- add comments to .read_alarm callback function to explain why it is an 
empty function;
- improve irq notify callback function name.
--
 drivers/rtc/rtc-imx-sc.c | 87 
 1 file changed, 87 insertions(+)

diff --git a/drivers/rtc/rtc-imx-sc.c b/drivers/rtc/rtc-imx-sc.c
index 19642bf..c933045 100644
--- a/drivers/rtc/rtc-imx-sc.c
+++ b/drivers/rtc/rtc-imx-sc.c
@@ -3,6 +3,7 @@
  * Copyright 2018 NXP.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -11,11 +12,15 @@
 #include 
 
 #define IMX_SC_TIMER_FUNC_GET_RTC_SEC1970  9
+#define IMX_SC_TIMER_FUNC_SET_RTC_ALARM8
 #define IMX_SC_TIMER_FUNC_SET_RTC_TIME 6
 
 #define IMX_SIP_SRTC   0xC202
 #define IMX_SIP_SRTC_SET_TIME  0x0
 
+#define SC_IRQ_GROUP_RTC2
+#define SC_IRQ_RTC  1
+
 static struct imx_sc_ipc *rtc_ipc_handle;
 static struct rtc_device *imx_sc_rtc;
 
@@ -24,6 +29,16 @@ struct imx_sc_msg_timer_get_rtc_time {
u32 time;
 } __packed;
 
+struct imx_sc_msg_timer_rtc_set_alarm {
+   struct imx_sc_rpc_msg hdr;
+   u16 year;
+   u8 mon;
+   u8 day;
+   u8 hour;
+   u8 min;
+   u8 sec;
+} __packed;
+
 static int imx_sc_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
struct imx_sc_msg_timer_get_rtc_time msg;
@@ -60,9 +75,77 @@ static int imx_sc_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
return res.a0;
 }
 
+static int imx_sc_rtc_alarm_irq_enable(struct device *dev, unsigned int enable)
+{
+   return imx_scu_irq_group_enable(SC_IRQ_GROUP_RTC, SC_IRQ_RTC, enable);
+}
+
+static int imx_sc_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+   /*
+* SCU firmware does NOT provide read alarm API, but .read_alarm
+* callback is required by RTC framework to support alarm function,
+* so just return here.
+*/
+   return 0;
+}
+
+static int imx_sc_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+   struct imx_sc_msg_timer_rtc_set_alarm msg;
+   struct imx_sc_rpc_msg *hdr = 
+   int ret;
+   struct rtc_time *alrm_tm = >time;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_TIMER;
+   hdr->func = IMX_SC_TIMER_FUNC_SET_RTC_ALARM;
+   hdr->size = 3;
+
+   msg.year = alrm_tm->tm_year + 1900;
+   msg.mon = alrm_tm->tm_mon + 1;
+   msg.day = alrm_tm->tm_mday;
+   msg.hour = alrm_tm->tm_hour;
+   msg.min = alrm_tm->tm_min;
+   msg.sec = alrm_tm->tm_sec;
+
+   ret = imx_scu_call_rpc(rtc_ipc_handle, , true);
+   if (ret) {
+   dev_err(dev, "set rtc alarm failed, ret %d\n", ret);
+   return ret;
+   }
+
+   ret = imx_sc_rtc_alarm_irq_enable(dev, alrm->enabled);
+   if (ret) {
+   dev_err(dev, "enable rtc alarm failed, ret %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct rtc_class_ops imx_sc_rtc_ops = {
.read_time = imx_sc_rtc_read_time,
.set_time = imx_sc_rtc_set_time,
+   .read_alarm = imx_sc_rtc_read_alarm,
+   .set_alarm = imx_sc_rtc_set_alarm,
+   .alarm_irq_enable = imx_sc_rtc_alarm_irq_enable,
+};
+
+static int imx_sc_rtc_alarm_notify(struct notifier_block *nb,
+   unsigned long event, void *group)
+{
+   /* ignore non-rtc irq */
+   if (!((event & SC_IRQ_RTC) && (*(u8 *)group == SC_IRQ_GROUP_RTC)))
+   return 0;
+
+   rtc_update_irq(imx_sc_rtc, 1, RTC_IRQF | RTC_AF);
+
+   return 0;
+}
+
+static struct notifier_block imx_sc_rtc_alarm_sc_notifier = {
+   .notifier_call = imx_sc_rtc_alarm_notify,
 };
 
 static int imx_sc_rtc_probe(struct platform_device *pdev)
@@ -73,6 +156,8 @@ static int imx_sc_rtc_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   device_init_wakeup(>dev, true);
+
imx_sc_rtc = devm_rtc_allocate_device(>dev);
if (IS_ERR(imx_sc_rtc))
return PTR_ERR(imx_sc_rtc);
@@ -87,6 +172,8 @@ static int imx_sc_rtc_probe(struct platform_device *pdev)
return ret;
}
 
+   imx_scu_irq_register_notifier(_sc_rtc_alarm_sc_notifier);
+
return 0;
 }
 
-- 
2.7.4

[PATCH V7 1/4] dt-bindings: fsl: scu: add general interrupt support

[Anson Huang]

Add scu general interrupt function support.

Signed-off-by: Anson Huang 
Reviewed-by: Rob Herring 
Reviewed-by: Dong Aisheng 
---
No changes.
---
 .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 29 +-
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 72d481c..5d7dbab 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -22,9 +22,11 @@ Required properties:
 ---
 - compatible:  should be "fsl,imx-scu".
 - mbox-names:  should include "tx0", "tx1", "tx2", "tx3",
-  "rx0", "rx1", "rx2", "rx3".
-- mboxes:  List of phandle of 4 MU channels for tx and 4 MU channels
-   for rx. All 8 MU channels must be in the same MU instance.
+  "rx0", "rx1", "rx2", "rx3";
+   include "gip3" if want to support general MU interrupt.
+- mboxes:  List of phandle of 4 MU channels for tx, 4 MU channels for
+   rx, and 1 optional MU channel for general interrupt.
+   All MU channels must be in the same MU instance.
Cross instances are not allowed. The MU instance can only
be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
to make sure use the one which is not conflict with other
@@ -34,6 +36,7 @@ Required properties:
Channel 1 must be "tx1" or "rx1".
Channel 2 must be "tx2" or "rx2".
Channel 3 must be "tx3" or "rx3".
+   General interrupt rx channel must be "gip3".
e.g.
mboxes = <_mu1 0 0
  _mu1 0 1
@@ -42,10 +45,18 @@ Required properties:
  _mu1 1 0
  _mu1 1 1
  _mu1 1 2
- _mu1 1 3>;
+ _mu1 1 3
+ _mu1 3 3>;
See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
for detailed mailbox binding.
 
+Note: Each mu which supports general interrupt should have an alias correctly
+numbered in "aliases" node.
+e.g.
+aliases {
+   mu1 = _mu1;
+};
+
 i.MX SCU Client Device Node:
 
 
@@ -124,6 +135,10 @@ Required properties:
 
 Example (imx8qxp):
 -
+aliases {
+   mu1 = _mu1;
+};
+
 lsio_mu1: mailbox@5d1c {
...
#mbox-cells = <2>;
@@ -133,7 +148,8 @@ firmware {
scu {
compatible = "fsl,imx-scu";
mbox-names = "tx0", "tx1", "tx2", "tx3",
-"rx0", "rx1", "rx2", "rx3";
+"rx0", "rx1", "rx2", "rx3",
+"gip3";
mboxes = <_mu1 0 0
  _mu1 0 1
  _mu1 0 2
@@ -141,7 +157,8 @@ firmware {
  _mu1 1 0
  _mu1 1 1
  _mu1 1 2
- _mu1 1 3>;
+ _mu1 1 3
+ _mu1 3 3>;
 
clk: clk {
compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
-- 
2.7.4

Re: [PATCH 3/3] ARM: omap2: move platform-specific asm-offset.h to arch/arm/mach-omap2

[Keerthy]

On 08/04/19 9:48 PM, Tony Lindgren wrote:

Hi,

* Masahiro Yamada  [190408 07:56]:

 is only generated and included
by arch/arm/mach-omap2/, so it does not need to reside in the
globally visible include/generated/.

I moved and renamed it to arch/arm/mach-omap2/pm-asm-offsets.h
since the prefix 'omap2-' is just redundant in mach-omap2/.

Signed-off-by: Masahiro Yamada 
---

Can this be applied to ARM-SOC tree in a series?
(with Ack from the platform sub-maintainer.)

ti-pm-asm-offsets.h does not need to reside in include/generated/,
but you may ask "Why must it get out of include/generated/?"

My main motivation is to avoid a race condition in the currently
proposed patch:

https://lore.kernel.org/patchwork/patch/1052763/

This patch tries to embed some build artifacts into the kernel.

If arch/arm/mach-omap2/ and kernel/ are built at the same time,
it may embed a truncated file.


Looks like a nice improvment to me, adding Keerthy and Dave to Cc.

Keerthy and Dave, can you please test this series with am3 and am4
PM code?


Tested for Deep Sleep0 on AM33xx Beaglebone-black.
Tested for Deep Sleep0 on AM437x-gp-evm.

Applied this on top of Tony's for-next with the gpio patch
required for RTC+DDR mode on am437x-gp-evm.

Tested-by: Keerthy 



Regards,

Tony


  arch/arm/mach-omap2/.gitignore  | 1 +
  arch/arm/mach-omap2/Makefile| 5 +++--
  arch/arm/mach-omap2/sleep33xx.S | 2 +-
  arch/arm/mach-omap2/sleep43xx.S | 2 +-
  4 files changed, 6 insertions(+), 4 deletions(-)
  create mode 100644 arch/arm/mach-omap2/.gitignore

diff --git a/arch/arm/mach-omap2/.gitignore b/arch/arm/mach-omap2/.gitignore
new file mode 100644
index ..79a8d6ea7152
--- /dev/null
+++ b/arch/arm/mach-omap2/.gitignore
@@ -0,0 +1 @@
+pm-asm-offsets.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 85d1b13c9215..26baeb6477af 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -236,9 +236,10 @@ obj-y  += 
omap_phy_internal.o
  
  obj-$(CONFIG_MACH_OMAP2_TUSB6010)	+= usb-tusb6010.o
  
-include/generated/ti-pm-asm-offsets.h: arch/arm/mach-omap2/pm-asm-offsets.s FORCE

+$(obj)/pm-asm-offsets.h: $(obj)/pm-asm-offsets.s FORCE
$(call filechk,offsets,__TI_PM_ASM_OFFSETS_H__)
  
-$(obj)/sleep33xx.o $(obj)/sleep43xx.o: include/generated/ti-pm-asm-offsets.h

+$(obj)/sleep33xx.o $(obj)/sleep43xx.o: $(obj)/pm-asm-offsets.h
  
  targets += pm-asm-offsets.s

+clean-files += pm-asm-offsets.h
diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S
index 47a816468cdb..a003769121aa 100644
--- a/arch/arm/mach-omap2/sleep33xx.S
+++ b/arch/arm/mach-omap2/sleep33xx.S
@@ -6,7 +6,6 @@
   *Dave Gerlach, Vaibhav Bedia
   */
  
-#include 

  #include 
  #include 
  #include 
@@ -15,6 +14,7 @@
  
  #include "iomap.h"

  #include "cm33xx.h"
+#include "pm-asm-offsets.h"
  
  #define AM33XX_CM_CLKCTRL_MODULESTATE_DISABLED			0x0003

  #define AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE  0x0003
diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S
index 5b9343b58fc7..aa288f361c5e 100644
--- a/arch/arm/mach-omap2/sleep43xx.S
+++ b/arch/arm/mach-omap2/sleep43xx.S
@@ -6,7 +6,6 @@
   *Dave Gerlach, Vaibhav Bedia
   */
  
-#include 

  #include 
  #include 
  #include 
@@ -19,6 +18,7 @@
  #include "iomap.h"
  #include "omap-secure.h"
  #include "omap44xx.h"
+#include "pm-asm-offsets.h"
  #include "prm33xx.h"
  #include "prcm43xx.h"
  
--

2.17.1

[PATCH] mtd: rawnand: constify elements of NAND_OP_PARSER(_PATTERN)

[Masahiro Yamada]

Currently, drivers are able to constify a nand_op_parser array,
but not nand_op_parser_pattern and nand_op_parser_pattern_elem
since they are instantiated by using the NAND_OP_PARSER(_PATTERN).

Add 'const' to them in order to move more driver data from .data to
.rodata section.

Signed-off-by: Masahiro Yamada 
---

 include/linux/mtd/rawnand.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index b7445a44a814..ebde52088e4d 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -805,7 +805,7 @@ struct nand_op_parser_pattern {
 #define NAND_OP_PARSER_PATTERN(_exec, ...) 
\
{   
\
.exec = _exec,  
\
-   .elems = (struct nand_op_parser_pattern_elem[]) { __VA_ARGS__ 
},\
+   .elems = (const struct nand_op_parser_pattern_elem[]) { 
__VA_ARGS__ },  \
.nelems = sizeof((struct nand_op_parser_pattern_elem[]) { 
__VA_ARGS__ }) /  \
  sizeof(struct nand_op_parser_pattern_elem),   
\
}
@@ -831,7 +831,7 @@ struct nand_op_parser {
 
 #define NAND_OP_PARSER(...)
\
{   
\
-   .patterns = (struct nand_op_parser_pattern[]) { __VA_ARGS__ },  
\
+   .patterns = (const struct nand_op_parser_pattern[]) { 
__VA_ARGS__ },\
.npatterns = sizeof((struct nand_op_parser_pattern[]) { 
__VA_ARGS__ }) /\
 sizeof(struct nand_op_parser_pattern), 
\
}
-- 
2.17.1

RE: [RESEND] arm64: defconfig: Enable RTC_DRV_SNVS

[Aisheng Dong]

> From: Abel Vesa
> Sent: Tuesday, April 9, 2019 2:53 AM
> 
> i.MX8MQ needs it for RTC support.
> 
> Signed-off-by: Abel Vesa 

Reviewed-by: Dong Aisheng 

Regards
Dong Aisheng

Re: [PATCH v2 2/2] mm, memory_hotplug: provide a more generic restrictions for memory hotplug

[Andrew Morton]

On Mon,  8 Apr 2019 10:26:33 +0200 Oscar Salvador  wrote:

> arch_add_memory, __add_pages take a want_memblock which controls whether
> the newly added memory should get the sysfs memblock user API (e.g.
> ZONE_DEVICE users do not want/need this interface). Some callers even
> want to control where do we allocate the memmap from by configuring
> altmap.
> 
> Add a more generic hotplug context for arch_add_memory and __add_pages.
> struct mhp_restrictions contains flags which contains additional
> features to be enabled by the memory hotplug (MHP_MEMBLOCK_API
> currently) and altmap for alternative memmap allocator.
> 
> This patch shouldn't introduce any functional change.

From: Andrew Morton 
Subject: 
mm-memory_hotplug-provide-a-more-generic-restrictions-for-memory-hotplug-fix

x86_64 allnoconfig:

In file included from ./include/linux/mmzone.h:744:0,
 from ./include/linux/gfp.h:6,
 from ./include/linux/umh.h:4,
 from ./include/linux/kmod.h:22,
 from ./include/linux/module.h:13,
 from init/do_mounts.c:1:
./include/linux/memory_hotplug.h:353:11: warning: ‘struct mhp_restrictions’ 
declared inside parameter list will not be visible outside of this definition 
or declaration
struct mhp_restrictions *restrictions);
   ^~~~

Fix this by moving the arch_add_memory() definition inside
CONFIG_MEMORY_HOTPLUG and moving the mhp_restrictions definition to a more
appropriate place.

Cc: Dan Williams 
Cc: David Hildenbrand 
Cc: Michal Hocko 
Cc: Oscar Salvador 
Signed-off-by: Andrew Morton 
---

 include/linux/memory_hotplug.h |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

--- 
a/include/linux/memory_hotplug.h~mm-memory_hotplug-provide-a-more-generic-restrictions-for-memory-hotplug-fix
+++ a/include/linux/memory_hotplug.h
@@ -54,6 +54,16 @@ enum {
 };
 
 /*
+ * Restrictions for the memory hotplug:
+ * flags:  MHP_ flags
+ * altmap: alternative allocator for memmap array
+ */
+struct mhp_restrictions {
+   unsigned long flags;
+   struct vmem_altmap *altmap;
+};
+
+/*
  * Zone resizing functions
  *
  * Note: any attempt to resize a zone should has pgdat_resize_lock()
@@ -101,6 +111,8 @@ extern void __online_page_free(struct pa
 
 extern int try_online_node(int nid);
 
+extern int arch_add_memory(int nid, u64 start, u64 size,
+   struct mhp_restrictions *restrictions);
 extern u64 max_mem_size;
 
 extern bool memhp_auto_online;
@@ -126,16 +138,6 @@ extern int __remove_pages(struct zone *z
 
 #define MHP_MEMBLOCK_API   (1<<0)
 
-/*
- * Restrictions for the memory hotplug:
- * flags:  MHP_ flags
- * altmap: alternative allocator for memmap array
- */
-struct mhp_restrictions {
-   unsigned long flags;
-   struct vmem_altmap *altmap;
-};
-
 /* reasonably generic interface to expand the physical pages */
 extern int __add_pages(int nid, unsigned long start_pfn, unsigned long 
nr_pages,
   struct mhp_restrictions *restrictions);
@@ -349,8 +351,6 @@ extern int walk_memory_range(unsigned lo
 extern int __add_memory(int nid, u64 start, u64 size);
 extern int add_memory(int nid, u64 start, u64 size);
 extern int add_memory_resource(int nid, struct resource *resource);
-extern int arch_add_memory(int nid, u64 start, u64 size,
-   struct mhp_restrictions *restrictions);
 extern void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,
unsigned long nr_pages, struct vmem_altmap *altmap);
 extern bool is_memblock_offlined(struct memory_block *mem);
_

Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)

[Michael Ellerman]

Carlos O'Donell  writes:
> On 4/8/19 3:20 PM, Tulio Magno Quites Machado Filho wrote:
>> Carlos O'Donell  writes:
>> 
>>> On 4/5/19 5:16 AM, Florian Weimer wrote:
 * Carlos O'Donell:
> It is valuable that it be a trap, particularly for constant pools because
> it means that a jump into the constant pool will trap.

 Sorry, I don't understand why this matters in this context.  Would you
 please elaborate?
>>>
>>> Sorry, I wasn't very clear.
>>>
>>> My point is only that any accidental jumps, either with off-by-one (like you
>>> fixed in gcc/glibc's signal unwinding most recently), result in a process 
>>> fault
>>> rather than executing RSEQ_SIG as a valid instruction *and then* continuing
>>> onwards to the handler.
>>>
>>> A process fault is achieved either by a trap, or an invalid instruction, or
>>> a privileged insn (like suggested for MIPS in this thread).
>> 
>> In that case, mtmsr (Move to Machine State Register) seems a good candidate.
>> 
>> mtmsr is available both on 32 and 64 bits since their first implementations.
>> 
>> It's a privileged instruction and should never appear in userspace
>> code (causes SIGILL).

I'd much rather we use a trap with a specific immediate value. Otherwise
someone's going to waste time one day puzzling over why userspace is
doing mtmsr.

It would also complicate things if we ever wanted to emulate mtmsr.

If we want something that is a trap rather than a nop then use 0x0fe50553.

That's "compare the value in r5 with 0x553 and then trap unconditionally".

It shows up in objdump as:

1000:   53 05 e5 0f twuir5,1363


The immediate can be anything, I chose that value to mimic the x86 value
Mathieu mentioned.

There's no reason that instruction would ever be generated because the
immediate value serves no purpose. So it satisfies the "very unlikely
to appear" criteria AFAICS.

cheers

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

[Annaliese McDermond]

Stephen --

I’m testing a potential solution now and I’ll be submitting something in the 
next couple of days.  Thanks for the heads up.

--
Annaliese McDermond
n...@nh6z.net

> On Apr 8, 2019, at 4:12 PM, Stephen Rothwell  wrote:
> 
> Hi all,
> 
> On Tue, 26 Mar 2019 10:01:45 +1100 Stephen Rothwell  
> wrote:
>> 
>> After merging the sound-asoc tree, today's linux-next build (x86_64
>> allmodconfig) produced this warning:
>> 
>> sound/soc/codecs/tlv320aic32x4-clk.c: In function 
>> 'clk_aic32x4_pll_recalc_rate':
>> sound/soc/codecs/tlv320aic32x4-clk.c:149:38: warning: 'settings.d' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
>> ((settings->j * 1) + settings->d);
>>  ^~~
>> sound/soc/codecs/tlv320aic32x4-clk.c:197:32: note: 'settings.d' was declared 
>> here
>>  struct clk_aic32x4_pll_muldiv settings;
>>^~~~
>> sound/soc/codecs/tlv320aic32x4-clk.c:149:15: warning: 'settings.j' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
>> ((settings->j * 1) + settings->d);
>>   ^~~
>> sound/soc/codecs/tlv320aic32x4-clk.c:197:32: note: 'settings.j' was declared 
>> here
>>  struct clk_aic32x4_pll_muldiv settings;
>>^~~~
>> sound/soc/codecs/tlv320aic32x4-clk.c:148:37: warning: 'settings.r' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
>>  rate = (u64) parent_rate * settings->r *
>> ^~~
>> sound/soc/codecs/tlv320aic32x4-clk.c:197:32: note: 'settings.r' was declared 
>> here
>>  struct clk_aic32x4_pll_muldiv settings;
>>^~~~
>> sound/soc/codecs/tlv320aic32x4-clk.c:151:56: warning: 'settings.p' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
>>  return (unsigned long) DIV_ROUND_UP_ULL(rate, settings->p * 1);
>>^~
>> sound/soc/codecs/tlv320aic32x4-clk.c:197:32: note: 'settings.p' was declared 
>> here
>>  struct clk_aic32x4_pll_muldiv settings;
>>^~~~
>> 
>> Introduced by commit
>> 
>>  514b044cba66 ("ASoC: tlv320aic32x4: Model PLL in CCF")
> 
> I am still getting these warnings.
> 
> -- 
> Cheers,
> Stephen Rothwell

[PATCH] x86/mm/mem_encrypt: fix a crash with kmemleak_scan

[Qian Cai]

The first kmemleak_scan() after boot would trigger a crash below because

kernel_init
  free_initmem
mem_encrypt_free_decrypted_mem
  free_init_pages

unmapped some memory inside the .bss.

BUG: unable to handle kernel paging request at bd402000
CPU: 12 PID: 325 Comm: kmemleak Not tainted 5.1.0-rc4+ #4
RIP: 0010:scan_block+0x58/0x160
Call Trace:
 scan_gray_list+0x1d9/0x280
 kmemleak_scan+0x485/0xad0
 kmemleak_scan_thread+0x9f/0xc4
 kthread+0x1d2/0x1f0
 ret_from_fork+0x35/0x40

Signed-off-by: Qian Cai 
---
 arch/x86/mm/mem_encrypt.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 385afa2b9e17..614ab156024f 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -369,6 +370,11 @@ void __init mem_encrypt_free_decrypted_mem(void)
}
}
 
+   /*
+* Inform kmemleak about the hole in the .bss section since the
+* corresponding pages will be unmapped with DEBUG_PAGEALLOC=y.
+*/
+   kmemleak_free_part((void *)vaddr, vaddr_end - vaddr);
free_init_pages("unused decrypted", vaddr, vaddr_end);
 }
 
-- 
2.17.2 (Apple Git-113)

Re: [PATCH] fat: issue flush after the writeback of FAT

[Darrick J. Wong]

On Tue, Apr 09, 2019 at 11:01:58AM +0800, Hou Tao wrote:
> fsync() needs to make sure the data & meta-data of file are persistent
> after the return of fsync(), even when a power-failure occurs later.
> In the case of fat-fs, the FAT belongs to the meta-data of file,
> so we need to issue a flush after the writeback of FAT instead before.
> 
> Also bail out early when any stage of fsync fails.
> 
> Signed-off-by: Hou Tao 
> ---
>  fs/fat/file.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/fat/file.c b/fs/fat/file.c
> index b3bed32946b1..0e3ed79fcc3f 100644
> --- a/fs/fat/file.c
> +++ b/fs/fat/file.c
> @@ -193,12 +193,17 @@ static int fat_file_release(struct inode *inode, struct 
> file *filp)
>  int fat_file_fsync(struct file *filp, loff_t start, loff_t end, int datasync)
>  {
>   struct inode *inode = filp->f_mapping->host;
> - int res, err;
> + int err;
> +
> + err = __generic_file_fsync(filp, start, end, datasync);
> + if (err)
> + return err;
>  
> - res = generic_file_fsync(filp, start, end, datasync);
>   err = sync_mapping_buffers(MSDOS_SB(inode->i_sb)->fat_inode->i_mapping);

Huh.  I would've thought that flushing the FAT would also be required
at the end of a WB_SYNC_ALL (aka data integrity) writepages call?

The patch itself seems good, though.

--D

> + if (err)
> + return err;
>  
> - return res ? res : err;
> + return blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL);
>  }
>  
>  
> -- 
> 2.16.2.dirty
> 

[PATCH ghak90 V6 10/10] audit: NETFILTER_PKT: record each container ID associated with a netNS

[Richard Guy Briggs]

Add audit container identifier auxiliary record(s) to NETFILTER_PKT
event standalone records.  Iterate through all potential audit container
identifiers associated with a network namespace.

Signed-off-by: Richard Guy Briggs 
Acked-by: Neil Horman 
Reviewed-by: Ondrej Mosnacek 
---
 include/linux/audit.h|  5 +
 kernel/audit.c   | 39 +++
 net/netfilter/nft_log.c  | 11 +--
 net/netfilter/xt_AUDIT.c | 11 +--
 4 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 4b2503927c37..d43db4491dd1 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -220,6 +220,8 @@ static inline u64 audit_get_contid(struct task_struct *tsk)
 extern void audit_netns_contid_del(struct net *net, u64 contid);
 extern void audit_switch_task_namespaces(struct nsproxy *ns,
 struct task_struct *p);
+extern void audit_log_netns_contid_list(struct net *net,
+   struct audit_context *context);
 
 extern u32 audit_enabled;
 #else /* CONFIG_AUDIT */
@@ -296,6 +298,9 @@ static inline void audit_netns_contid_del(struct net *net, 
u64 contid)
 static inline void audit_switch_task_namespaces(struct nsproxy *ns,
struct task_struct *p)
 { }
+static inline void audit_log_netns_contid_list(struct net *net,
+  struct audit_context *context)
+{ }
 
 #define audit_enabled AUDIT_OFF
 #endif /* CONFIG_AUDIT */
diff --git a/kernel/audit.c b/kernel/audit.c
index 996213591617..512464a626d1 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -453,6 +453,45 @@ void audit_switch_task_namespaces(struct nsproxy *ns, 
struct task_struct *p)
audit_netns_contid_add(new->net_ns, contid);
 }
 
+/**
+ * audit_log_netns_contid_list - List contids for the given network namespace
+ * @net: the network namespace of interest
+ * @context: the audit context to use
+ *
+ * Description:
+ * Issues a CONTAINER_ID record with a CSV list of contids associated
+ * with a network namespace to accompany a NETFILTER_PKT record.
+ */
+void audit_log_netns_contid_list(struct net *net, struct audit_context 
*context)
+{
+   struct audit_buffer *ab = NULL;
+   struct audit_contid *cont;
+   struct audit_net *aunet;
+
+   /* Generate AUDIT_CONTAINER_ID record with container ID CSV list */
+   rcu_read_lock();
+   aunet = net_generic(net, audit_net_id);
+   if (!aunet)
+   goto out;
+   list_for_each_entry_rcu(cont, >contid_list, list) {
+   if (!ab) {
+   ab = audit_log_start(context, GFP_ATOMIC,
+AUDIT_CONTAINER_ID);
+   if (!ab) {
+   audit_log_lost("out of memory in 
audit_log_netns_contid_list");
+   goto out;
+   }
+   audit_log_format(ab, "contid=");
+   } else
+   audit_log_format(ab, ",");
+   audit_log_format(ab, "%llu", (unsigned long long)cont->id);
+   }
+   audit_log_end(ab);
+out:
+   rcu_read_unlock();
+}
+EXPORT_SYMBOL(audit_log_netns_contid_list);
+
 void audit_panic(const char *message)
 {
switch (audit_failure) {
diff --git a/net/netfilter/nft_log.c b/net/netfilter/nft_log.c
index 655187bed5d8..bdb1ec2368a7 100644
--- a/net/netfilter/nft_log.c
+++ b/net/netfilter/nft_log.c
@@ -69,13 +69,16 @@ static void nft_log_eval_audit(const struct nft_pktinfo 
*pkt)
struct sk_buff *skb = pkt->skb;
struct audit_buffer *ab;
int fam = -1;
+   struct audit_context *context;
+   struct net *net;
 
if (!audit_enabled)
return;
 
-   ab = audit_log_start(NULL, GFP_ATOMIC, AUDIT_NETFILTER_PKT);
+   context = audit_alloc_local(GFP_ATOMIC);
+   ab = audit_log_start(context, GFP_ATOMIC, AUDIT_NETFILTER_PKT);
if (!ab)
-   return;
+   goto errout;
 
audit_log_format(ab, "mark=%#x", skb->mark);
 
@@ -102,6 +105,10 @@ static void nft_log_eval_audit(const struct nft_pktinfo 
*pkt)
audit_log_format(ab, " saddr=? daddr=? proto=-1");
 
audit_log_end(ab);
+   net = xt_net(>xt);
+   audit_log_netns_contid_list(net, context);
+errout:
+   audit_free_context(context);
 }
 
 static void nft_log_eval(const struct nft_expr *expr,
diff --git a/net/netfilter/xt_AUDIT.c b/net/netfilter/xt_AUDIT.c
index af883f1b64f9..a3e547435f13 100644
--- a/net/netfilter/xt_AUDIT.c
+++ b/net/netfilter/xt_AUDIT.c
@@ -71,10 +71,13 @@ static bool audit_ip6(struct audit_buffer *ab, struct 
sk_buff *skb)
 {
struct audit_buffer *ab;
int fam = -1;
+   struct audit_context *context;
+   struct net *net;
 
if (audit_enabled == AUDIT_OFF)
- 

RE: [PATCH V6 4/4] rtc: imx-sc: add rtc alarm support

[Aisheng Dong]

[...]

> > > +static int imx_sc_rtc_alarm_irq_enable(struct device *dev, unsigned
> > > +int
> > > +enable) {
> > > + imx_scu_irq_enable(SC_IRQ_GROUP_RTC, SC_IRQ_RTC, enable);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int imx_sc_rtc_read_alarm(struct device *dev, struct
> > > +rtc_wkalrm
> > > +*alrm) {
> >
> > I still think here needs a doc explain why needs this and why it's
> > safe to do that.
> 
> I will add a comment here, for the doc, it should be another topic of RTC
> framework, we can do it later.

I'm fine with it.
BTW, don't miss the next minor comments when you resend.

Regards
Dong Aisheng

> > > + .set_alarm = imx_sc_rtc_set_alarm,
> > > + .alarm_irq_enable = imx_sc_rtc_alarm_irq_enable, };
> > > +
> > > +static int imx_sc_rtc_alarm_sc_notify(struct notifier_block *nb,
> > > + unsigned long event, void *group)
> >
> > Not necessary to have such a long function name.
> > Imx_sc_rtc_alarm_notify() should be ok
> >

RE: [PATCH v2] RISC-V: Implement ASID allocator

[Anup Patel]

> -Original Message-
> From: Guo Ren 
> Sent: Tuesday, April 9, 2019 8:33 AM
> To: Anup Patel 
> Cc: Palmer Dabbelt ; Albert Ou
> ; linux-kernel@vger.kernel.org; Mike Rapoport
> ; Christoph Hellwig ; Atish Patra
> ; Gary Guo ; Paul Walmsley
> ; linux-ri...@lists.infradead.org
> Subject: Re: [PATCH v2] RISC-V: Implement ASID allocator
> 
> Hi Anup,
> 
> On Thu, Mar 28, 2019 at 06:32:36AM +, Anup Patel wrote:
> > This patch is tested on QEMU/virt machine and SiFive Unleashed board.
> > On QEMU/virt machine, we see 10% (approx) performance improvement
> with
> > SW emulated TLBs provided by QEMU. Unfortunately, ASID bits of SATP
> > CSR are not implemented on SiFive Unleashed board so we don't see any
> > change in performance.
> Can you tell me what is the test case ?

I am testing this using hackbench.

Regards,
Anup

RE: [PATCH V6 2/4] firmware: imx: enable imx scu general irq function

[Anson Huang]

Best Regards!
Anson Huang

> -Original Message-
> From: Aisheng Dong
> Sent: 2019年4月9日 11:21
> To: Anson Huang ; robh...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de;
> ker...@pengutronix.de; feste...@gmail.com; a.zu...@towertech.it;
> alexandre.bell...@bootlin.com; ulf.hans...@linaro.org; sb...@kernel.org;
> Peng Fan ; Daniel Baluta ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Cc: dl-linux-imx 
> Subject: RE: [PATCH V6 2/4] firmware: imx: enable imx scu general irq
> function
> 
> > From: Anson Huang
> > Sent: Tuesday, April 9, 2019 10:43 AM
> > Subject: [PATCH V6 2/4] firmware: imx: enable imx scu general irq
> > function
> >
> > The System Controller Firmware (SCFW) controls RTC, thermal and WDOG
> > etc., these resources' interrupt function are managed by SCU. When any
> > IRQ pending, SCU will notify Linux via MU general interrupt channel
> > #3, and Linux kernel needs to call SCU APIs to get IRQ status and
> > notify each module to handle the interrupt.
> >
> > Since there is no data transmission for SCU IRQ notification, so
> > doorbell mode is used for this MU channel, and SCU driver will use
> > notifier mechanism to broadcast to every module which registers the SCU
> block notifier.
> >
> > Signed-off-by: Anson Huang 
> > ---
> > Changes since V5:
> > - use ATOMIC_NOTIFIER instead of BLOCKING_NOTIFIER for irq
> > notification;
> > - add memory free for failed case to avoid memory leak;
> > - add new API imx_scu_irq_enable() for modules to enable/disable
> > their own irqs.
> > ---
> >  drivers/firmware/imx/Makefile  |   2 +-
> >  drivers/firmware/imx/imx-scu-irq.c | 166
> > +
> >  drivers/firmware/imx/imx-scu.c |   6 ++
> >  include/linux/firmware/imx/sci.h   |   5 ++
> >  4 files changed, 178 insertions(+), 1 deletion(-)  create mode 100644
> > drivers/firmware/imx/imx-scu-irq.c
> >
> > diff --git a/drivers/firmware/imx/Makefile
> > b/drivers/firmware/imx/Makefile index 1b2e15b..802c4ad 100644
> > --- a/drivers/firmware/imx/Makefile
> > +++ b/drivers/firmware/imx/Makefile
> > @@ -1,3 +1,3 @@
> >  # SPDX-License-Identifier: GPL-2.0
> > -obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o
> > +obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o imx-scu-irq.o
> >  obj-$(CONFIG_IMX_SCU_PD)   += scu-pd.o
> > diff --git a/drivers/firmware/imx/imx-scu-irq.c
> > b/drivers/firmware/imx/imx-scu-irq.c
> > new file mode 100644
> > index 000..4000c63
> > --- /dev/null
> > +++ b/drivers/firmware/imx/imx-scu-irq.c
> > @@ -0,0 +1,166 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2019 NXP
> > + *
> > + * Implementation of the SCU IRQ functions using MU.
> > + *
> > + */
> > +
> > +#include  #include
> > + #include 
> > +
> > +#define IMX_SC_IRQ_FUNC_ENABLE 1
> > +#define IMX_SC_IRQ_FUNC_STATUS 2
> > +#define IMX_SC_IRQ_NUM_GROUP   4
> > +
> > +static u32 mu_resource_id;
> > +
> > +struct imx_sc_msg_irq_get_status {
> > +   struct imx_sc_rpc_msg hdr;
> > +   union {
> > +   struct {
> > +   u16 resource;
> > +   u8 group;
> > +   u8 reserved;
> > +   } __packed req;
> > +   struct {
> > +   u32 status;
> > +   } resp;
> > +   } data;
> > +};
> > +
> > +struct imx_sc_msg_irq_enable {
> > +   struct imx_sc_rpc_msg hdr;
> > +   u32 mask;
> > +   u16 resource;
> > +   u8 group;
> > +   u8 enable;
> > +} __packed;
> > +
> > +static struct imx_sc_ipc *imx_sc_irq_ipc_handle; static struct
> > +work_struct imx_sc_irq_work; static
> > +ATOMIC_NOTIFIER_HEAD(imx_scu_irq_notifier_chain);
> > +
> > +int imx_scu_irq_register_notifier(struct notifier_block *nb) {
> > +   return atomic_notifier_chain_register(
> > +   _scu_irq_notifier_chain, nb);
> > +}
> > +EXPORT_SYMBOL(imx_scu_irq_register_notifier);
> > +
> > +int imx_scu_irq_unregister_notifier(struct notifier_block *nb) {
> > +   return atomic_notifier_chain_unregister(
> > +   _scu_irq_notifier_chain, nb);
> > +}
> > +EXPORT_SYMBOL(imx_scu_irq_unregister_notifier);
> > +
> > +static int imx_scu_irq_notifier_call_chain(unsigned long status, u8
> > +*group) {
> > +   return atomic_notifier_call_chain(_scu_irq_notifier_chain,
> > +   status, (void *)group);
> > +}
> > +
> > +static void imx_scu_irq_work_handler(struct work_struct *work) {
> > +   struct imx_sc_msg_irq_get_status msg;
> > +   struct imx_sc_rpc_msg *hdr = 
> > +   u32 irq_status;
> > +   int ret;
> > +   u8 i;
> > +
> > +   for (i = 0; i < IMX_SC_IRQ_NUM_GROUP; i++) {
> > +   hdr->ver = IMX_SC_RPC_VERSION;
> > +   hdr->svc = IMX_SC_RPC_SVC_IRQ;
> > +   hdr->func = IMX_SC_IRQ_FUNC_STATUS;
> > +   hdr->size = 2;
> > +
> > +   msg.data.req.resource = mu_resource_id;
> > +   msg.data.req.group = i;
> > +
> > + 

RE: [PATCH V6 4/4] rtc: imx-sc: add rtc alarm support

[Anson Huang]

Best Regards!
Anson Huang

> -Original Message-
> From: Aisheng Dong
> Sent: 2019年4月9日 11:25
> To: Anson Huang ; robh...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de;
> ker...@pengutronix.de; feste...@gmail.com; a.zu...@towertech.it;
> alexandre.bell...@bootlin.com; ulf.hans...@linaro.org; sb...@kernel.org;
> Peng Fan ; Daniel Baluta ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Cc: dl-linux-imx 
> Subject: RE: [PATCH V6 4/4] rtc: imx-sc: add rtc alarm support
> 
> > From: Anson Huang
> > Sent: Tuesday, April 9, 2019 10:44 AM
> > Subject: [PATCH V6 4/4] rtc: imx-sc: add rtc alarm support
> >
> > Add i.MX system controller RTC alarm support, the RTC alarm is
> > implemented via SIP(silicon provider) runtime service call and
> > ARM-Trusted-Firmware will communicate with system controller via
> > MU(message unit) IPC to set RTC alarm. When RTC alarm fires, system
> > controller will generate a common MU irq event and notify system
> controller RTC driver to handle the irq event.
> >
> > Signed-off-by: Anson Huang 
> > ---
> > Changes since V5:
> > - move the irq alarm enable RPC to imx-scu-irq driver, and rtc driver
> > just call the
> >   API to enable/disable alarm.
> > ---
> >  drivers/rtc/rtc-imx-sc.c | 84
> > 
> >  1 file changed, 84 insertions(+)
> >
> > diff --git a/drivers/rtc/rtc-imx-sc.c b/drivers/rtc/rtc-imx-sc.c index
> > 19642bf..3eb4db0 100644
> > --- a/drivers/rtc/rtc-imx-sc.c
> > +++ b/drivers/rtc/rtc-imx-sc.c
> > @@ -3,6 +3,7 @@
> >   * Copyright 2018 NXP.
> >   */
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -11,11 +12,15 @@
> >  #include 
> >
> >  #define IMX_SC_TIMER_FUNC_GET_RTC_SEC1970  9
> > +#define IMX_SC_TIMER_FUNC_SET_RTC_ALARM8
> >  #define IMX_SC_TIMER_FUNC_SET_RTC_TIME 6
> >
> >  #define IMX_SIP_SRTC   0xC202
> >  #define IMX_SIP_SRTC_SET_TIME  0x0
> >
> > +#define SC_IRQ_GROUP_RTC2
> > +#define SC_IRQ_RTC  1
> > +
> >  static struct imx_sc_ipc *rtc_ipc_handle;  static struct rtc_device
> > *imx_sc_rtc;
> >
> > @@ -24,6 +29,16 @@ struct imx_sc_msg_timer_get_rtc_time {
> > u32 time;
> >  } __packed;
> >
> > +struct imx_sc_msg_timer_rtc_set_alarm {
> > +   struct imx_sc_rpc_msg hdr;
> > +   u16 year;
> > +   u8 mon;
> > +   u8 day;
> > +   u8 hour;
> > +   u8 min;
> > +   u8 sec;
> > +} __packed;
> > +
> >  static int imx_sc_rtc_read_time(struct device *dev, struct rtc_time *tm)  {
> > struct imx_sc_msg_timer_get_rtc_time msg; @@ -60,9 +75,74 @@
> static
> > int imx_sc_rtc_set_time(struct device *dev, struct rtc_time *tm)
> > return res.a0;
> >  }
> >
> > +static int imx_sc_rtc_alarm_irq_enable(struct device *dev, unsigned
> > +int
> > +enable) {
> > +   imx_scu_irq_enable(SC_IRQ_GROUP_RTC, SC_IRQ_RTC, enable);
> > +
> > +   return 0;
> > +}
> > +
> > +static int imx_sc_rtc_read_alarm(struct device *dev, struct
> > +rtc_wkalrm
> > +*alrm) {
> 
> I still think here needs a doc explain why needs this and why it's safe to do
> that.

I will add a comment here, for the doc, it should be another topic of RTC 
framework,
we can do it later.

Anson.

> Otherwise:
> Reviewed-by: Dong Aisheng 
> 
> > +   return 0;
> > +}
> > +
> > +static int imx_sc_rtc_set_alarm(struct device *dev, struct rtc_wkalrm
> > +*alrm) {
> > +   struct imx_sc_msg_timer_rtc_set_alarm msg;
> > +   struct imx_sc_rpc_msg *hdr = 
> > +   int ret;
> > +   struct rtc_time *alrm_tm = >time;
> > +
> > +   hdr->ver = IMX_SC_RPC_VERSION;
> > +   hdr->svc = IMX_SC_RPC_SVC_TIMER;
> > +   hdr->func = IMX_SC_TIMER_FUNC_SET_RTC_ALARM;
> > +   hdr->size = 3;
> > +
> > +   msg.year = alrm_tm->tm_year + 1900;
> > +   msg.mon = alrm_tm->tm_mon + 1;
> > +   msg.day = alrm_tm->tm_mday;
> > +   msg.hour = alrm_tm->tm_hour;
> > +   msg.min = alrm_tm->tm_min;
> > +   msg.sec = alrm_tm->tm_sec;
> > +
> > +   ret = imx_scu_call_rpc(rtc_ipc_handle, , true);
> > +   if (ret) {
> > +   dev_err(dev, "set rtc alarm failed, ret %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   ret = imx_sc_rtc_alarm_irq_enable(dev, alrm->enabled);
> > +   if (ret) {
> > +   dev_err(dev, "enable rtc alarm failed, ret %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> >  static const struct rtc_class_ops imx_sc_rtc_ops = {
> > .read_time = imx_sc_rtc_read_time,
> > .set_time = imx_sc_rtc_set_time,
> > +   .read_alarm = imx_sc_rtc_read_alarm,
> > +   .set_alarm = imx_sc_rtc_set_alarm,
> > +   .alarm_irq_enable = imx_sc_rtc_alarm_irq_enable, };
> > +
> > +static int imx_sc_rtc_alarm_sc_notify(struct notifier_block *nb,
> > +   unsigned long event, void *group)
> 
> Not necessary to have such a long function name.
> Imx_sc_rtc_alarm_notify() should be ok
> 
> Regards

Re: [PATCH v2 0/2] A couple hugetlbfs fixes

[Mike Kravetz]

On 4/8/19 12:48 PM, Davidlohr Bueso wrote:
> On Thu, 28 Mar 2019, Mike Kravetz wrote:
> 
>> - A BUG can be triggered (not easily) due to temporarily mapping a
>>  page before doing a COW.
> 
> But you actually _have_ seen it? Do you have the traces? I ask
> not because of the patches perse, but because it would be nice
> to have a real snipplet in the Changelog for patch 2.

Yes, I actually saw this problem.  It happened while I was debugging and
testing some patches for hugetlb migration.  The BUG I hit was in
unaccount_page_cache_page(): VM_BUG_ON_PAGE(page_mapped(page), page).

Stack trace was something like:
unaccount_page_cache_page
  __delete_from_page_cache
delete_from_page_cache
  remove_huge_page
remove_inode_hugepages
  hugetlbfs_punch_hole
hugetlbfs_fallocate

When I hit that, it took me a while to figure out how it could happen.
i.e. How could a page be mapped at that point in remove_inode_hugepages?
It checks page_mapped and we are holding the fault mutex.  With some
additional debug code (strategic udelays) I could hit the issue on a
somewhat regular basis and verified another thread was in the
hugetlb_no_page/hugetlb_cow path for the same page at the same time.

Unfortunately, I did not save the traces.  I am trying to recreate now.
However, my test system was recently updated and it might take a little
time to recreate.
-- 
Mike Kravetz

RE: [PATCH v3] pinctrl: imx8mq: Add suspend/resume ops

[Aisheng Dong]

> From: Abel Vesa
> Sent: Tuesday, April 9, 2019 2:39 AM
> 
> To support pinctl hog restore after LPSR resume back, add the generic
> suspend/resume in pinctrl-imx along with the generic pm ops to be used by
> platform specific drivers. Then make use of the newly added ops in i.MX8MQ
> platform specific driver.
> 
> Signed-off-by: Robin Gong 
> Signed-off-by: Abel Vesa 

Acked-by: Dong Aisheng 

Regards
Dong Aisheng

Re: [PATCH][next] acpi/hmat: fix uninitialized pointer dereference on pointer 'target'

[Nathan Chancellor]

On Fri, Apr 05, 2019 at 03:12:15PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The pointer 'target' is not initialized and is only assigned when the
> ACPI_HMAT_MEMORY_PD_VALID bit in p->flags is set.  There is a later null
> check on target that leads to an uninitialized pointer read and
> dereference when assigning target->processor_pxm when target contains a
> non-null garbage value.  Fix this by initializing targer to null.
> 
> Fixes: 665ac7e92757 ("acpi/hmat: Register processor domain to its memory")
> Addresses-Coverity: ("Uninitialized pointer read")
> Signed-off-by: Colin Ian King 

Reviewed-by: Nathan Chancellor 

> ---
>  drivers/acpi/hmat/hmat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/hmat/hmat.c b/drivers/acpi/hmat/hmat.c
> index b7824a0309f7..b275016ff648 100644
> --- a/drivers/acpi/hmat/hmat.c
> +++ b/drivers/acpi/hmat/hmat.c
> @@ -366,7 +366,7 @@ static int __init hmat_parse_proximity_domain(union 
> acpi_subtable_headers *heade
> const unsigned long end)
>  {
>   struct acpi_hmat_proximity_domain *p = (void *)header;
> - struct memory_target *target;
> + struct memory_target *target = NULL;
>  
>   if (p->header.length != sizeof(*p)) {
>   pr_notice("HMAT: Unexpected address range header length: %d\n",
> -- 
> 2.20.1
> 

Re: [PATCH 2/3] interconnect: qcom: Add QCS404 interconnect provider driver

[Bjorn Andersson]

On Mon 08 Apr 07:33 PDT 2019, Georgi Djakov wrote:
> On 4/5/19 17:57, Bjorn Andersson wrote:
> > On Fri 05 Apr 10:54 +07 2019, Georgi Djakov wrote:
> > [..]
[..]
> >> diff --git a/drivers/interconnect/qcom/qcs404_ids.h 
> >> b/drivers/interconnect/qcom/qcs404_ids.h
> > 
> > You use these defines in the driver, so I think this file should be the
> > one in include/dt-bindings...
> 
> The ids in this header are in a single global namespace in order to
> build the internal topology and could be used for drivers that support
> only platform data (although not sure if there would be any).
> 

As you say these numbers could be used by drivers on non-DT enabled
platforms, but for that this include file should be in
include/linux/interconnect. That said, there are no such Qualcomm
platforms, so these numbers will only ever be used internally in the
qcs404.c provider, so it would be better to just define them in that
file - to remove the risk of confusion.

> > 
> > [..]
> >> diff --git a/include/dt-bindings/interconnect/qcom,qcs404.h 
> >> b/include/dt-bindings/interconnect/qcom,qcs404.h
> > 
> 
> These header is using per NoC local ids and should be used on DT enabled
> platforms.
> 

I had missed that you implemented support for xlating NoC-specific ids,
so this makes sense now, nice. I presume we won't ever include files in
a way where these defines collide - so this looks good.

Regards,
Bjorn

RE: Issues with i.MX SPI DMA transfers

[Robin Gong]

Hi Igor,
Please have a try with the attached patches, and revert 25aaa75df1e6, 
ad0d92d7ba6a
, dd4b487b32a3, df07101e1c4a before apply. Besides XCH, tx thresh should be set 
to 0 ,
now no failure caught on ecspi5.

> -Original Message-
> From: Robin Gong
> Sent: 2019年4月2日 16:33
> To: 'Igor Plyatov' ; Uwe Kleine-König
> 
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam
> ; Pengutronix Kernel Team ;
> Sascha Hauer ; Shawn Guo
> ; Mark Brown ;
> dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams
> ; Andy Duan ; Han Xu
> ; Clark Wang 
> Subject: RE: Issues with i.MX SPI DMA transfers
> 
> > -Original Message-
> > From: Igor Plyatov 
> > Sent: 2019年4月2日 15:20
> > To: Robin Gong ; Uwe Kleine-König
> > 
> > Cc: linux-kernel@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org;
> > linux-...@vger.kernel.org; dl-linux-imx ; Fabio
> > Estevam ; Pengutronix Kernel Team
> > ; Sascha Hauer ; Shawn
> > Guo ; Mark Brown ;
> > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams
> > ; Andy Duan ; Han Xu
> > ; Clark Wang 
> > Subject: Re: Issues with i.MX SPI DMA transfers
> >
> > Dear Robin Gong,
> >
> >
> > >> Sorry...below another sdma patch(ad0d92d7ba6a) need to be reverted,
> > >> because spi driver may dynamically change burst length.
> >
> >
> > now I have reverted patch ad0d92d7ba6a.
> >
> > Patches 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch and
> > 0002-spi-spi-imx-fix-ERR009165.patch are applied.
> >
> >
> > Kernel log show messages
> >
> > [   29.202639] imx-sdma 20ec000.sdma: loaded firmware 3.3 [
> > 29.238595] spi_imx 2008000.spi: probed [   29.242802] spi_imx
> > 200c000.spi: probed [   29.245217] spi_imx 2018000.spi: probed
> >
> > SPI DMA transfers still not work.
> >
> > If I test 32 byte transfers, then they work fine. But 64 byte
> > transfers fails always and I see error messages
> >
> > root@cr7:~# spidev_test -D /dev/spidev4.1 -s 120 -b 8 -S 64 -I 1
> > -l spi mode: 0x20 bits per word: 8 max speed: 120 Hz (1200 KHz) [
> > 423.686736] spi_master spi4: I/O Error in DMA RX [  423.691392] spidev
> > spi4.1: SPI transfer failed: -110 [  423.696382] spi_master spi4:
> > failed to transfer one message from queue can't send spi message:
> > Connection timed out Aborted (core dumped)
> >
> > I suppose, transfers shorter then 64 bytes made with help of PIO.
> >
> > Robin, is there any chance for you to find some time and look at this
> > issue again?
> I have quick test with spidev_test loopback, but didn't meet your error, Is 
> your
> code the almost latest code in linux-next as mine?
> 
> root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
>  48: 37   GPC   2 Level sdma
>  -lt@imx6qpdlsolox:~# ./spidev_test -D /dev/spidev0.0 -s 120 -b 8 -S 64 -I
> 1 -l spi mode: 0x20 bits per word: 8 max speed: 120 Hz (1200 KHz)
> root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
>  48: 43   GPC   2 Level sdma
> ./spidev_test -D /dev/spidev0.0 -s 120 -b 8 -S 512 -I 1 -l spi mode: 0x20 
> bits
> per word: 8 max speed: 120 Hz (1200 KHz)
> total: tx 0.5KB, rx 0.5KB
> >
> > Best wishes.
> > --
> > Igor Plyatov


0005-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch
Description: 0005-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch


0006-spi-spi-imx-fix-ERR009165.patch
Description: 0006-spi-spi-imx-fix-ERR009165.patch

RE: [PATCH V6 4/4] rtc: imx-sc: add rtc alarm support

[Aisheng Dong]

> From: Anson Huang
> Sent: Tuesday, April 9, 2019 10:44 AM
> Subject: [PATCH V6 4/4] rtc: imx-sc: add rtc alarm support
> 
> Add i.MX system controller RTC alarm support, the RTC alarm is implemented
> via SIP(silicon provider) runtime service call and ARM-Trusted-Firmware will
> communicate with system controller via MU(message unit) IPC to set RTC
> alarm. When RTC alarm fires, system controller will generate a common MU
> irq event and notify system controller RTC driver to handle the irq event.
> 
> Signed-off-by: Anson Huang 
> ---
> Changes since V5:
>   - move the irq alarm enable RPC to imx-scu-irq driver, and rtc driver 
> just
> call the
> API to enable/disable alarm.
> ---
>  drivers/rtc/rtc-imx-sc.c | 84
> 
>  1 file changed, 84 insertions(+)
> 
> diff --git a/drivers/rtc/rtc-imx-sc.c b/drivers/rtc/rtc-imx-sc.c index
> 19642bf..3eb4db0 100644
> --- a/drivers/rtc/rtc-imx-sc.c
> +++ b/drivers/rtc/rtc-imx-sc.c
> @@ -3,6 +3,7 @@
>   * Copyright 2018 NXP.
>   */
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -11,11 +12,15 @@
>  #include 
> 
>  #define IMX_SC_TIMER_FUNC_GET_RTC_SEC19709
> +#define IMX_SC_TIMER_FUNC_SET_RTC_ALARM  8
>  #define IMX_SC_TIMER_FUNC_SET_RTC_TIME   6
> 
>  #define IMX_SIP_SRTC 0xC202
>  #define IMX_SIP_SRTC_SET_TIME0x0
> 
> +#define SC_IRQ_GROUP_RTC2
> +#define SC_IRQ_RTC  1
> +
>  static struct imx_sc_ipc *rtc_ipc_handle;  static struct rtc_device
> *imx_sc_rtc;
> 
> @@ -24,6 +29,16 @@ struct imx_sc_msg_timer_get_rtc_time {
>   u32 time;
>  } __packed;
> 
> +struct imx_sc_msg_timer_rtc_set_alarm {
> + struct imx_sc_rpc_msg hdr;
> + u16 year;
> + u8 mon;
> + u8 day;
> + u8 hour;
> + u8 min;
> + u8 sec;
> +} __packed;
> +
>  static int imx_sc_rtc_read_time(struct device *dev, struct rtc_time *tm)  {
>   struct imx_sc_msg_timer_get_rtc_time msg; @@ -60,9 +75,74 @@ static
> int imx_sc_rtc_set_time(struct device *dev, struct rtc_time *tm)
>   return res.a0;
>  }
> 
> +static int imx_sc_rtc_alarm_irq_enable(struct device *dev, unsigned int
> +enable) {
> + imx_scu_irq_enable(SC_IRQ_GROUP_RTC, SC_IRQ_RTC, enable);
> +
> + return 0;
> +}
> +
> +static int imx_sc_rtc_read_alarm(struct device *dev, struct rtc_wkalrm
> +*alrm) {

I still think here needs a doc explain why needs this and why it's safe to do 
that.
Otherwise:
Reviewed-by: Dong Aisheng 

> + return 0;
> +}
> +
> +static int imx_sc_rtc_set_alarm(struct device *dev, struct rtc_wkalrm
> +*alrm) {
> + struct imx_sc_msg_timer_rtc_set_alarm msg;
> + struct imx_sc_rpc_msg *hdr = 
> + int ret;
> + struct rtc_time *alrm_tm = >time;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_TIMER;
> + hdr->func = IMX_SC_TIMER_FUNC_SET_RTC_ALARM;
> + hdr->size = 3;
> +
> + msg.year = alrm_tm->tm_year + 1900;
> + msg.mon = alrm_tm->tm_mon + 1;
> + msg.day = alrm_tm->tm_mday;
> + msg.hour = alrm_tm->tm_hour;
> + msg.min = alrm_tm->tm_min;
> + msg.sec = alrm_tm->tm_sec;
> +
> + ret = imx_scu_call_rpc(rtc_ipc_handle, , true);
> + if (ret) {
> + dev_err(dev, "set rtc alarm failed, ret %d\n", ret);
> + return ret;
> + }
> +
> + ret = imx_sc_rtc_alarm_irq_enable(dev, alrm->enabled);
> + if (ret) {
> + dev_err(dev, "enable rtc alarm failed, ret %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static const struct rtc_class_ops imx_sc_rtc_ops = {
>   .read_time = imx_sc_rtc_read_time,
>   .set_time = imx_sc_rtc_set_time,
> + .read_alarm = imx_sc_rtc_read_alarm,
> + .set_alarm = imx_sc_rtc_set_alarm,
> + .alarm_irq_enable = imx_sc_rtc_alarm_irq_enable, };
> +
> +static int imx_sc_rtc_alarm_sc_notify(struct notifier_block *nb,
> + unsigned long event, void *group)

Not necessary to have such a long function name.
Imx_sc_rtc_alarm_notify() should be ok

Regards
Dong Aisheng

> +{
> + /* ignore non-rtc irq */
> + if (!((event & SC_IRQ_RTC) && (*(u8 *)group == SC_IRQ_GROUP_RTC)))
> + return 0;
> +
> + rtc_update_irq(imx_sc_rtc, 1, RTC_IRQF | RTC_AF);
> +
> + return 0;
> +}
> +
> +static struct notifier_block imx_sc_rtc_alarm_sc_notifier = {
> + .notifier_call = imx_sc_rtc_alarm_sc_notify,
>  };
> 
>  static int imx_sc_rtc_probe(struct platform_device *pdev) @@ -73,6 +153,8
> @@ static int imx_sc_rtc_probe(struct platform_device *pdev)
>   if (ret)
>   return ret;
> 
> + device_init_wakeup(>dev, true);
> +
>   imx_sc_rtc = devm_rtc_allocate_device(>dev);
>   if (IS_ERR(imx_sc_rtc))
>   return PTR_ERR(imx_sc_rtc);
> @@ -87,6 +169,8 @@ static int imx_sc_rtc_probe(struct platform_device
> *pdev)
>   return ret;
>   }
> 
> + 

Re: [PATCH v4 2/2] Input: add Apple SPI keyboard and trackpad driver.

[Life is hard, and then you die]

On Mon, Apr 08, 2019 at 03:33:43PM +0300, Andy Shevchenko wrote:
> On Sat, Apr 06, 2019 at 10:03:58PM -0700, Ronald Tschalär wrote:
> > The keyboard and trackpad on recent MacBook's (since 8,1) and
> > MacBookPro's (13,* and 14,*) are attached to an SPI controller instead
> > of USB, as previously. The higher level protocol is not publicly
> > documented and hence has been reverse engineered. As a consequence there
> > are still a number of unknown fields and commands. However, the known
> > parts have been working well and received extensive testing and use.
> > 
> > In order for this driver to work, the proper SPI drivers need to be
> > loaded too; for MB8,1 these are spi_pxa2xx_platform and spi_pxa2xx_pci;
> > for all others they are spi_pxa2xx_platform and intel_lpss_pci. For this
> > reason enabling this driver in the config implies enabling the above
> > drivers.
> 
> Thank you for an update, my comments below.

Thank you again for your review.

[snip]
> > +   } else {
> > +   struct dentry *ret;
> > +
> > +   ret = debugfs_create_bool("enable_tp_dim", 0600,
> > + applespi->debugfs_root,
> > + >debug_tp_dim);
> > +   if (IS_ERR(ret))
> > +   dev_warn(&(applespi)->spi->dev,
> > +"Error creating debugfs entry enable_tp_dim 
> > (%ld)\n",
> > +PTR_ERR(ret));
> 
> Can ret be NULL?

No, it actually can't (I manually traced all code paths to be sure):
the documentation for these helper functions is wrong in this respect.
However, I note that a lot of existing kernel code also has this wrong
(i.e. it's checking for NULL). Digging a bit further and looking at
the history, it appears this was changed just recently (commit
ff9fb72b "debugfs: return error values, not NULL"), which would
explain the existing code and documentation. I'll submit a patch to
update the docs.

> dev_dbg() looks more appropriate.

Hmm, ok, I guess I find this a bit odd, though: true, this only
affects code used for debugging, but it's nevertheless an error that
shouldn't normally occur.


  Cheers,

  Ronald

RE: [PATCH V6 2/4] firmware: imx: enable imx scu general irq function

[Aisheng Dong]

> From: Anson Huang
> Sent: Tuesday, April 9, 2019 10:43 AM
> Subject: [PATCH V6 2/4] firmware: imx: enable imx scu general irq function
> 
> The System Controller Firmware (SCFW) controls RTC, thermal and WDOG etc.,
> these resources' interrupt function are managed by SCU. When any IRQ
> pending, SCU will notify Linux via MU general interrupt channel #3, and Linux
> kernel needs to call SCU APIs to get IRQ status and notify each module to
> handle the interrupt.
> 
> Since there is no data transmission for SCU IRQ notification, so doorbell mode
> is used for this MU channel, and SCU driver will use notifier mechanism to
> broadcast to every module which registers the SCU block notifier.
> 
> Signed-off-by: Anson Huang 
> ---
> Changes since V5:
>   - use ATOMIC_NOTIFIER instead of BLOCKING_NOTIFIER for irq
> notification;
>   - add memory free for failed case to avoid memory leak;
>   - add new API imx_scu_irq_enable() for modules to enable/disable their
> own irqs.
> ---
>  drivers/firmware/imx/Makefile  |   2 +-
>  drivers/firmware/imx/imx-scu-irq.c | 166
> +
>  drivers/firmware/imx/imx-scu.c |   6 ++
>  include/linux/firmware/imx/sci.h   |   5 ++
>  4 files changed, 178 insertions(+), 1 deletion(-)  create mode 100644
> drivers/firmware/imx/imx-scu-irq.c
> 
> diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
> index 1b2e15b..802c4ad 100644
> --- a/drivers/firmware/imx/Makefile
> +++ b/drivers/firmware/imx/Makefile
> @@ -1,3 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o
> +obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o
>  obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> diff --git a/drivers/firmware/imx/imx-scu-irq.c
> b/drivers/firmware/imx/imx-scu-irq.c
> new file mode 100644
> index 000..4000c63
> --- /dev/null
> +++ b/drivers/firmware/imx/imx-scu-irq.c
> @@ -0,0 +1,166 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 NXP
> + *
> + * Implementation of the SCU IRQ functions using MU.
> + *
> + */
> +
> +#include  #include
> + #include 
> +
> +#define IMX_SC_IRQ_FUNC_ENABLE   1
> +#define IMX_SC_IRQ_FUNC_STATUS   2
> +#define IMX_SC_IRQ_NUM_GROUP 4
> +
> +static u32 mu_resource_id;
> +
> +struct imx_sc_msg_irq_get_status {
> + struct imx_sc_rpc_msg hdr;
> + union {
> + struct {
> + u16 resource;
> + u8 group;
> + u8 reserved;
> + } __packed req;
> + struct {
> + u32 status;
> + } resp;
> + } data;
> +};
> +
> +struct imx_sc_msg_irq_enable {
> + struct imx_sc_rpc_msg hdr;
> + u32 mask;
> + u16 resource;
> + u8 group;
> + u8 enable;
> +} __packed;
> +
> +static struct imx_sc_ipc *imx_sc_irq_ipc_handle; static struct
> +work_struct imx_sc_irq_work; static
> +ATOMIC_NOTIFIER_HEAD(imx_scu_irq_notifier_chain);
> +
> +int imx_scu_irq_register_notifier(struct notifier_block *nb) {
> + return atomic_notifier_chain_register(
> + _scu_irq_notifier_chain, nb);
> +}
> +EXPORT_SYMBOL(imx_scu_irq_register_notifier);
> +
> +int imx_scu_irq_unregister_notifier(struct notifier_block *nb) {
> + return atomic_notifier_chain_unregister(
> + _scu_irq_notifier_chain, nb);
> +}
> +EXPORT_SYMBOL(imx_scu_irq_unregister_notifier);
> +
> +static int imx_scu_irq_notifier_call_chain(unsigned long status, u8
> +*group) {
> + return atomic_notifier_call_chain(_scu_irq_notifier_chain,
> + status, (void *)group);
> +}
> +
> +static void imx_scu_irq_work_handler(struct work_struct *work) {
> + struct imx_sc_msg_irq_get_status msg;
> + struct imx_sc_rpc_msg *hdr = 
> + u32 irq_status;
> + int ret;
> + u8 i;
> +
> + for (i = 0; i < IMX_SC_IRQ_NUM_GROUP; i++) {
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_IRQ;
> + hdr->func = IMX_SC_IRQ_FUNC_STATUS;
> + hdr->size = 2;
> +
> + msg.data.req.resource = mu_resource_id;
> + msg.data.req.group = i;
> +
> + ret = imx_scu_call_rpc(imx_sc_irq_ipc_handle, , true);
> + if (ret) {
> + pr_err("get irq group %d status failed, ret %d\n",
> +i, ret);
> + return;
> + }
> +
> + irq_status = msg.data.resp.status;
> + if (!irq_status)
> + continue;
> +
> + imx_scu_irq_notifier_call_chain(irq_status, );
> + }
> +}
> +
> +void imx_scu_irq_enable(u8 group, u32 mask, u8 enable) {

Why should this be a void return?

Besides that, a nitpick better rename to imx_scu_irq_group_enable
to distinguish with the exist general irq enable.

Regards
Dong Aisheng

> + struct imx_sc_msg_irq_enable msg;
> + struct imx_sc_rpc_msg *hdr = 
> + int 

Re: [PULL 0/4] xtensa fixes for v5.1-rc5

[pr-tracker-bot]

The pull request you sent on Mon,  8 Apr 2019 11:01:46 -0700:

> git://github.com/jcmvbkbc/linux-xtensa.git tags/xtensa-20190408

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/10d433979f2eb78fa6ef042bf0d7e1c1f3199d4c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] TPM fixes for v5.1

[pr-tracker-bot]

The pull request you sent on Tue, 9 Apr 2019 09:07:10 +1000 (AEST):

> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
> fixes-v5.1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a556810d8e06aa2da8bbe22da3d105eb5a0d0c7d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Networking

[pr-tracker-bot]

The pull request you sent on Mon, 08 Apr 2019 19:21:27 -0700 (PDT):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/869e3305f23dfeacdaa234717c92ccb237815d90

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

RE: [PATCH V5 4/4] rtc: imx-sc: add rtc alarm support

[Aisheng Dong]

[...]

> so I will add another API in imx-scu-irq
> driver to provide function of enabling/disabling irq, each driver can just 
> call the
> API to enable/disable its own IRQ, ONLY need to pass the corresponding
> arguments:
> 

That's exactly what I mean.

> >
> > > + msg.group = SC_IRQ_GROUP_RTC;
> > > + msg.mask = SC_IRQ_RTC;
> > > + msg.enable = enable;
> > > +
> > > + ret = imx_scu_call_rpc(rtc_ipc_handle, , true);
> > > + if (ret) {
> > > + dev_err(dev, "enable rtc irq failed, ret %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int imx_sc_rtc_read_alarm(struct device *dev, struct
> > > +rtc_wkalrm
> > > +*alrm) {
> > > + return 0;
> > > +}
> >
> > Can't avoid define NULL function?
> 
> We have to implement it as NULL function, as SCFW does NOT provide such
> feature, But rtc alarm ONLY available when .read_alarm ops is implemented:
> 

If the framework mandantorily requires it, then we'd probably better to add
doc before this function and explain why it's safe to be NULL.

> 147 static ssize_t
> 148 wakealarm_store(struct device *dev, struct device_attribute *attr,
> 149 const char *buf, size_t n)
> 150 {
> 
> ...
> 
> 187 retval = rtc_read_alarm(rtc, );
> 188 if (retval < 0)
> 189 return retval;
> 
> 
> >
> > > +
> > > +static int imx_sc_rtc_set_alarm(struct device *dev, struct
> > > +rtc_wkalrm
> > > +*alrm) {
> > > + struct imx_sc_msg_timer_rtc_set_alarm msg;
> > > + struct imx_sc_rpc_msg *hdr = 
> > > + int ret;
> > > + struct rtc_time *alrm_tm = >time;
> > > +
> > > + hdr->ver = IMX_SC_RPC_VERSION;
> > > + hdr->svc = IMX_SC_RPC_SVC_TIMER;
> > > + hdr->func = IMX_SC_TIMER_FUNC_SET_RTC_ALARM;
> > > + hdr->size = 3;
> > > +
> > > + msg.year = alrm_tm->tm_year + 1900;
> > > + msg.mon = alrm_tm->tm_mon + 1;
> > > + msg.day = alrm_tm->tm_mday;
> > > + msg.hour = alrm_tm->tm_hour;
> > > + msg.min = alrm_tm->tm_min;
> > > + msg.sec = alrm_tm->tm_sec;
> > > +
> > > + ret = imx_scu_call_rpc(rtc_ipc_handle, , true);
> > > + if (ret) {
> > > + dev_err(dev, "set rtc alarm failed, ret %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + ret = imx_sc_rtc_alarm_irq_enable(dev, alrm->enabled);
> >
> > Just curious we already have .alarm_irq_enable().
> > Why do we need call it again here?
> 
> That is because the  set_alarm function  pass alarm time and alarm->enabled
> argument, it could be to enable alarm or to disable alarm, so we have to
> control the alarm function here, all other rtc drivers also do it this way.
> The .alarm_irq_enable() callback is for just enable or disable alarm.
> 

Got it, thanks for the explanation.

Regards
Dong Aisheng

> Thanks,
> Anson
> 
> 
> >
> > Regards
> > Dong Aisheng
> >
> > > + if (ret) {
> > > + dev_err(dev, "enable rtc alarm failed, ret %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > >  static const struct rtc_class_ops imx_sc_rtc_ops = {
> > >   .read_time = imx_sc_rtc_read_time,
> > >   .set_time = imx_sc_rtc_set_time,
> > > + .read_alarm = imx_sc_rtc_read_alarm,
> > > + .set_alarm = imx_sc_rtc_set_alarm,
> > > + .alarm_irq_enable = imx_sc_rtc_alarm_irq_enable, };
> > > +
> > > +static int imx_sc_rtc_alarm_sc_notify(struct notifier_block *nb,
> > > + unsigned long event, void *group) {
> > > + /* ignore non-rtc irq */
> > > + if (!((event & SC_IRQ_RTC) && (*(u8 *)group ==
> > SC_IRQ_GROUP_RTC)))
> > > + return 0;
> > > +
> > > + rtc_update_irq(imx_sc_rtc, 1, RTC_IRQF | RTC_AF);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static struct notifier_block imx_sc_rtc_alarm_sc_notifier = {
> > > + .notifier_call = imx_sc_rtc_alarm_sc_notify,
> > >  };
> > >
> > >  static int imx_sc_rtc_probe(struct platform_device *pdev) @@ -73,6
> > > +181,8 @@ static int imx_sc_rtc_probe(struct platform_device *pdev)
> > >   if (ret)
> > >   return ret;
> > >
> > > + device_init_wakeup(>dev, true);
> > > +
> > >   imx_sc_rtc = devm_rtc_allocate_device(>dev);
> > >   if (IS_ERR(imx_sc_rtc))
> > >   return PTR_ERR(imx_sc_rtc);
> > > @@ -87,6 +197,8 @@ static int imx_sc_rtc_probe(struct
> > > platform_device
> > > *pdev)
> > >   return ret;
> > >   }
> > >
> > > + imx_scu_irq_register_notifier(_sc_rtc_alarm_sc_notifier);
> > > +
> > >   return 0;
> > >  }
> > >
> > > --
> > > 2.7.4

[PATCH V9 5/5] drm/mediatek: no change parent rate in round_rate() for mt2701 hdmi phy

[wangyan wang]

From: Wangyan Wang 

This is the third step to make MT2701 HDMI stable.
We should not change the rate of parent for hdmi phy when
doing round_rate for this clock. The parent clock of hdmi
phy must be the same as it. We change it when doing set_rate
only.

Signed-off-by: Wangyan Wang 
---
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h|  2 --
 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c |  6 ++
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
 4 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 9e153e080739..e3a6b50e0cf2 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
.owner = THIS_MODULE,
 };
 
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate)
-{
-   struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
-   hdmi_phy->pll_rate = rate;
-   if (rate <= 7425)
-   *parent_rate = rate;
-   else
-   *parent_rate = rate / 2;
-
-   return rate;
-}
-
 void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
 u32 bits)
 {
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h 
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index d28b8d5ed2b4..2d8b3182470d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -49,8 +49,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32 
offset,
 void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
   u32 val, u32 mask);
 struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate);
 
 extern struct platform_driver mtk_hdmi_phy_driver;
 extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index b24ea6651db4..e3f05ad89b1e 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -106,6 +106,12 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
usleep_range(80, 100);
 }
 
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *parent_rate)
+
+{
+   return rate;
+}
+
 static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 unsigned long parent_rate)
 {
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 625739b4e938..78c638c29102 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -199,6 +199,20 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
usleep_range(100, 150);
 }
 
+long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *parent_rate)
+
+{
+   struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+   hdmi_phy->pll_rate = rate;
+   if (rate <= 7425)
+   *parent_rate = rate;
+   else
+   *parent_rate = rate / 2;
+
+   return rate;
+}
+
 static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 unsigned long parent_rate)
 {
-- 
2.14.1

Re: [PATCH 1/2] mm/gup.c: fix the wrong comments

[Huang Shijie]

On Mon, Apr 08, 2019 at 07:49:29PM -0700, Matthew Wilcox wrote:
> On Tue, Apr 09, 2019 at 09:08:33AM +0800, Huang Shijie wrote:
> > On Mon, Apr 08, 2019 at 07:13:13AM -0700, Matthew Wilcox wrote:
> > > On Mon, Apr 08, 2019 at 10:37:45AM +0800, Huang Shijie wrote:
> > > > The root cause is that sg_alloc_table_from_pages() requires the
> > > > page order to keep the same as it used in the user space, but
> > > > get_user_pages_fast() will mess it up.
> > > 
> > > I don't understand how get_user_pages_fast() can return the pages in a
> > > different order in the array from the order they appear in userspace.
> > > Can you explain?
> > Please see the code in gup.c:
> > 
> > int get_user_pages_fast(unsigned long start, int nr_pages,
> > unsigned int gup_flags, struct page **pages)
> > {
> > ...
> > if (gup_fast_permitted(start, nr_pages)) {
> > local_irq_disable();
> > gup_pgd_range(addr, end, gup_flags, pages, );
> >// The @pages array maybe filled at the first time.
> 
> Right ... but if it's not filled entirely, it will be filled part-way,
> and then we stop.
> 
> > local_irq_enable();
> > ret = nr;
> > }
> > ...
> > if (nr < nr_pages) {
> > /* Try to get the remaining pages with get_user_pages */
> > start += nr << PAGE_SHIFT;
> > pages += nr;
> >   // The @pages is moved forward.
> 
> Yes, to the point where gup_pgd_range() stopped.
> 
> > if (gup_flags & FOLL_LONGTERM) {
> > down_read(>mm->mmap_sem);
> > ret = __gup_longterm_locked(current, 
> > current->mm,  // The @pages maybe filled at the second time
> 
> Right.
> 
> > /*
> >  * retain FAULT_FOLL_ALLOW_RETRY optimization if
> >  * possible
> >  */
> > ret = get_user_pages_unlocked(start, nr_pages - 
> > nr,// The @pages maybe filled at the second time.
> >   pages, gup_flags);
> 
> Yes.  But they'll be in the same order.
> 
> > BTW, I do not know why we mess up the page order. It maybe used in some 
> > special case.
> 
> I'm not discounting the possibility that you've found a bug.
> But documenting that a bug exists is not the solution; the solution is
> fixing the bug.
I do not think it is a bug :)

If we use the get_user_pages_unlocked(), DMA is okay, such as:
 
 get_user_pages_unlocked()
 sg_alloc_table_from_pages()
 .

I think the comment is not accurate enough. So just add more comments, and tell 
the driver
users how to use the GUPs.

Thanks
Huang Shijie

Re: [PATCH v2] RISC-V: Implement ASID allocator

[Guo Ren]

Hi Anup,

On Thu, Mar 28, 2019 at 06:32:36AM +, Anup Patel wrote:
> This patch is tested on QEMU/virt machine and SiFive Unleashed board.
> On QEMU/virt machine, we see 10% (approx) performance improvement with
> SW emulated TLBs provided by QEMU. Unfortunately, ASID bits of SATP CSR
> are not implemented on SiFive Unleashed board so we don't see any change
> in performance.
Can you tell me what is the test case ?

Best Regards
 Guo Ren

[PATCH] mtd: rawnand: Add Macronix NAND read retry and randomizer support

[Mason Yang]

Add a driver for Macronix NAND read retry and randomizer.

Signed-off-by: Mason Yang 
---
 drivers/mtd/nand/raw/nand_macronix.c | 169 +++
 1 file changed, 169 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_macronix.c 
b/drivers/mtd/nand/raw/nand_macronix.c
index 47d8cda..a19caa4 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -17,6 +17,174 @@
 
 #include "internals.h"
 
+#define MACRONIX_READ_RETRY_BIT BIT(0)
+#define MACRONIX_RANDOMIZER_BIT BIT(1)
+#define MACRONIX_READ_RETRY_MODE 5
+
+#define ONFI_FEATURE_ADDR_MXIC_RANDOMIZER 0xB0
+
+struct nand_onfi_vendor_macronix {
+   u8 reserved[1];
+   u8 reliability_func;
+} __packed;
+
+struct nand_chip *mxic_sysfs;
+
+static int macronix_nand_setup_read_retry(struct nand_chip *chip, int mode)
+{
+   u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = {0};
+   int ret;
+
+   if (mode > MACRONIX_READ_RETRY_MODE)
+   mode = MACRONIX_READ_RETRY_MODE;
+
+   feature[0] = mode;
+   ret =  nand_set_features(chip, ONFI_FEATURE_ADDR_READ_RETRY, feature);
+   if (ret)
+   pr_err("failed to enter read retry moded:%d\n", mode);
+
+   if (mode == 0)
+   ret =  nand_get_features(chip, ONFI_FEATURE_ADDR_READ_RETRY,
+feature);
+   if (ret)
+   pr_err("failed to exits read retry moded:%d\n", mode);
+
+   return ret;
+}
+
+static ssize_t mxic_nand_rand_type_show(struct kobject *kobj,
+   struct kobj_attribute *attr, char *buf)
+{
+   struct nand_chip *chip = mxic_sysfs;
+   u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = {0};
+   int ret;
+
+   nand_select_target(chip, 0);
+   ret = nand_get_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+   feature);
+   nand_deselect_target(chip);
+   if (ret)
+   pr_err("failed to check mxic nand device randomizer\n");
+
+   return sprintf(buf, "MXIC NAND device randomizer %s(0x%x)\n",
+  feature[0] & MACRONIX_RANDOMIZER_BIT ?
+  "enable" : "disable", feature[0]);
+}
+
+static ssize_t mxic_nand_rand_type_store(struct kobject *kobj,
+struct kobj_attribute *attr,
+const char *buf, size_t count)
+{
+   struct nand_chip *chip = mxic_sysfs;
+   u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = {0};
+   unsigned int rand_layout;
+   int ret;
+
+   nand_select_target(chip, 0);
+   ret = nand_get_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+   feature);
+   nand_deselect_target(chip);
+
+   if (feature[0]) {
+   pr_err("Randomizer is enabled 0x%x\n", feature[0]);
+   goto err_out;
+   }
+
+   ret = kstrtouint(buf, 0, _layout);
+   if (ret)
+   goto err_out;
+
+   if (rand_layout > 7) {
+   pr_err("Error parameter value:0x%x\n", rand_layout);
+   goto err_out;
+   }
+
+   feature[0] = rand_layout & 0x07;
+   nand_select_target(chip, 0);
+   ret = nand_set_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+   feature);
+   nand_deselect_target(chip);
+   if (ret) {
+   pr_err("device randomizer set feature failed\n");
+   goto err_out;
+   }
+
+   feature[0] = 0x0;
+   nand_select_target(chip, 0);
+   ret = nand_prog_page_op(chip, 0, 0, feature, 1);
+   nand_deselect_target(chip);
+   if (ret) {
+   pr_err("Prog device randomizer failed\n");
+   goto err_out;
+   }
+
+   feature[0] = 0x0;
+   nand_select_target(chip, 0);
+   ret = nand_set_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+   feature);
+   nand_deselect_target(chip);
+   if (ret)
+   pr_err("failed to exits prog device randomizer\n");
+
+err_out:
+   return count;
+}
+
+static const struct kobj_attribute sysfs_mxic_nand =
+   __ATTR(nand_random, S_IRUGO | S_IWUSR,
+  mxic_nand_rand_type_show,
+  mxic_nand_rand_type_store);
+
+static void macronix_nand_onfi_init(struct nand_chip *chip)
+{
+   struct nand_parameters *p = >parameters;
+   struct kobject *kobj;
+   int ret;
+
+   mxic_sysfs = chip;
+   if (p->onfi) {
+   struct nand_onfi_vendor_macronix *mxic =
+   (void *)p->onfi->vendor;
+
+   if (mxic->reliability_func & MACRONIX_READ_RETRY_BIT) {
+   chip->read_retries = MACRONIX_READ_RETRY_MODE + 1;
+   chip->setup_read_retry =
+macronix_nand_setup_read_retry;
+   if (p->supports_set_get_features) {
+   

[PATCH] fat: issue flush after the writeback of FAT

[Hou Tao]

fsync() needs to make sure the data & meta-data of file are persistent
after the return of fsync(), even when a power-failure occurs later.
In the case of fat-fs, the FAT belongs to the meta-data of file,
so we need to issue a flush after the writeback of FAT instead before.

Also bail out early when any stage of fsync fails.

Signed-off-by: Hou Tao 
---
 fs/fat/file.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/fs/fat/file.c b/fs/fat/file.c
index b3bed32946b1..0e3ed79fcc3f 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -193,12 +193,17 @@ static int fat_file_release(struct inode *inode, struct 
file *filp)
 int fat_file_fsync(struct file *filp, loff_t start, loff_t end, int datasync)
 {
struct inode *inode = filp->f_mapping->host;
-   int res, err;
+   int err;
+
+   err = __generic_file_fsync(filp, start, end, datasync);
+   if (err)
+   return err;
 
-   res = generic_file_fsync(filp, start, end, datasync);
err = sync_mapping_buffers(MSDOS_SB(inode->i_sb)->fat_inode->i_mapping);
+   if (err)
+   return err;
 
-   return res ? res : err;
+   return blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL);
 }
 
 
-- 
2.16.2.dirty

Re: [PATCH 1/2] mm/gup.c: fix the wrong comments

[Matthew Wilcox]

On Tue, Apr 09, 2019 at 09:08:33AM +0800, Huang Shijie wrote:
> On Mon, Apr 08, 2019 at 07:13:13AM -0700, Matthew Wilcox wrote:
> > On Mon, Apr 08, 2019 at 10:37:45AM +0800, Huang Shijie wrote:
> > > The root cause is that sg_alloc_table_from_pages() requires the
> > > page order to keep the same as it used in the user space, but
> > > get_user_pages_fast() will mess it up.
> > 
> > I don't understand how get_user_pages_fast() can return the pages in a
> > different order in the array from the order they appear in userspace.
> > Can you explain?
> Please see the code in gup.c:
> 
>   int get_user_pages_fast(unsigned long start, int nr_pages,
>   unsigned int gup_flags, struct page **pages)
>   {
>   ...
>   if (gup_fast_permitted(start, nr_pages)) {
>   local_irq_disable();
>   gup_pgd_range(addr, end, gup_flags, pages, );
>// The @pages array maybe filled at the first time.

Right ... but if it's not filled entirely, it will be filled part-way,
and then we stop.

>   local_irq_enable();
>   ret = nr;
>   }
>   ...
>   if (nr < nr_pages) {
>   /* Try to get the remaining pages with get_user_pages */
>   start += nr << PAGE_SHIFT;
>   pages += nr;
>   // The @pages is moved forward.

Yes, to the point where gup_pgd_range() stopped.

>   if (gup_flags & FOLL_LONGTERM) {
>   down_read(>mm->mmap_sem);
>   ret = __gup_longterm_locked(current, 
> current->mm,  // The @pages maybe filled at the second time

Right.

>   /*
>* retain FAULT_FOLL_ALLOW_RETRY optimization if
>* possible
>*/
>   ret = get_user_pages_unlocked(start, nr_pages - 
> nr,// The @pages maybe filled at the second time.
> pages, gup_flags);

Yes.  But they'll be in the same order.

> BTW, I do not know why we mess up the page order. It maybe used in some 
> special case.

I'm not discounting the possibility that you've found a bug.
But documenting that a bug exists is not the solution; the solution is
fixing the bug.

Re: Thoughts on simple scanner approach for free page hinting

[Michael S. Tsirkin]

On Fri, Apr 05, 2019 at 05:09:45PM -0700, Alexander Duyck wrote:
> In addition we will need some way to identify which pages have been
> hinted on and which have not. The way I believe easiest to do this
> would be to overload the PageType value so that we could essentially
> have two values for "Buddy" pages. We would have our standard "Buddy"
> pages, and "Buddy" pages that also have the "Offline" value set in the
> PageType field. Tracking the Online vs Offline pages this way would
> actually allow us to do this with almost no overhead as the mapcount
> value is already being reset to clear the "Buddy" flag so adding a
> "Offline" flag to this clearing should come at no additional cost.

It bothers me a bit that this doesn't scale to multiple hint types
if we ever need them. Would it be better to have two
free lists: hinted and non-hinted one?


-- 
MST

[PATCH V6 4/4] rtc: imx-sc: add rtc alarm support

[Anson Huang]

Add i.MX system controller RTC alarm support, the RTC alarm
is implemented via SIP(silicon provider) runtime service call
and ARM-Trusted-Firmware will communicate with system controller
via MU(message unit) IPC to set RTC alarm. When RTC alarm fires,
system controller will generate a common MU irq event and notify
system controller RTC driver to handle the irq event.

Signed-off-by: Anson Huang 
---
Changes since V5:
- move the irq alarm enable RPC to imx-scu-irq driver, and rtc driver 
just call the
  API to enable/disable alarm.
---
 drivers/rtc/rtc-imx-sc.c | 84 
 1 file changed, 84 insertions(+)

diff --git a/drivers/rtc/rtc-imx-sc.c b/drivers/rtc/rtc-imx-sc.c
index 19642bf..3eb4db0 100644
--- a/drivers/rtc/rtc-imx-sc.c
+++ b/drivers/rtc/rtc-imx-sc.c
@@ -3,6 +3,7 @@
  * Copyright 2018 NXP.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -11,11 +12,15 @@
 #include 
 
 #define IMX_SC_TIMER_FUNC_GET_RTC_SEC1970  9
+#define IMX_SC_TIMER_FUNC_SET_RTC_ALARM8
 #define IMX_SC_TIMER_FUNC_SET_RTC_TIME 6
 
 #define IMX_SIP_SRTC   0xC202
 #define IMX_SIP_SRTC_SET_TIME  0x0
 
+#define SC_IRQ_GROUP_RTC2
+#define SC_IRQ_RTC  1
+
 static struct imx_sc_ipc *rtc_ipc_handle;
 static struct rtc_device *imx_sc_rtc;
 
@@ -24,6 +29,16 @@ struct imx_sc_msg_timer_get_rtc_time {
u32 time;
 } __packed;
 
+struct imx_sc_msg_timer_rtc_set_alarm {
+   struct imx_sc_rpc_msg hdr;
+   u16 year;
+   u8 mon;
+   u8 day;
+   u8 hour;
+   u8 min;
+   u8 sec;
+} __packed;
+
 static int imx_sc_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
struct imx_sc_msg_timer_get_rtc_time msg;
@@ -60,9 +75,74 @@ static int imx_sc_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
return res.a0;
 }
 
+static int imx_sc_rtc_alarm_irq_enable(struct device *dev, unsigned int enable)
+{
+   imx_scu_irq_enable(SC_IRQ_GROUP_RTC, SC_IRQ_RTC, enable);
+
+   return 0;
+}
+
+static int imx_sc_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+   return 0;
+}
+
+static int imx_sc_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+   struct imx_sc_msg_timer_rtc_set_alarm msg;
+   struct imx_sc_rpc_msg *hdr = 
+   int ret;
+   struct rtc_time *alrm_tm = >time;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_TIMER;
+   hdr->func = IMX_SC_TIMER_FUNC_SET_RTC_ALARM;
+   hdr->size = 3;
+
+   msg.year = alrm_tm->tm_year + 1900;
+   msg.mon = alrm_tm->tm_mon + 1;
+   msg.day = alrm_tm->tm_mday;
+   msg.hour = alrm_tm->tm_hour;
+   msg.min = alrm_tm->tm_min;
+   msg.sec = alrm_tm->tm_sec;
+
+   ret = imx_scu_call_rpc(rtc_ipc_handle, , true);
+   if (ret) {
+   dev_err(dev, "set rtc alarm failed, ret %d\n", ret);
+   return ret;
+   }
+
+   ret = imx_sc_rtc_alarm_irq_enable(dev, alrm->enabled);
+   if (ret) {
+   dev_err(dev, "enable rtc alarm failed, ret %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct rtc_class_ops imx_sc_rtc_ops = {
.read_time = imx_sc_rtc_read_time,
.set_time = imx_sc_rtc_set_time,
+   .read_alarm = imx_sc_rtc_read_alarm,
+   .set_alarm = imx_sc_rtc_set_alarm,
+   .alarm_irq_enable = imx_sc_rtc_alarm_irq_enable,
+};
+
+static int imx_sc_rtc_alarm_sc_notify(struct notifier_block *nb,
+   unsigned long event, void *group)
+{
+   /* ignore non-rtc irq */
+   if (!((event & SC_IRQ_RTC) && (*(u8 *)group == SC_IRQ_GROUP_RTC)))
+   return 0;
+
+   rtc_update_irq(imx_sc_rtc, 1, RTC_IRQF | RTC_AF);
+
+   return 0;
+}
+
+static struct notifier_block imx_sc_rtc_alarm_sc_notifier = {
+   .notifier_call = imx_sc_rtc_alarm_sc_notify,
 };
 
 static int imx_sc_rtc_probe(struct platform_device *pdev)
@@ -73,6 +153,8 @@ static int imx_sc_rtc_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   device_init_wakeup(>dev, true);
+
imx_sc_rtc = devm_rtc_allocate_device(>dev);
if (IS_ERR(imx_sc_rtc))
return PTR_ERR(imx_sc_rtc);
@@ -87,6 +169,8 @@ static int imx_sc_rtc_probe(struct platform_device *pdev)
return ret;
}
 
+   imx_scu_irq_register_notifier(_sc_rtc_alarm_sc_notifier);
+
return 0;
 }
 
-- 
2.7.4

[PATCH V6 3/4] arm64: dts: freescale: imx8qxp: enable scu general irq channel

[Anson Huang]

On i.MX8QXP, SCU uses MU1 general interrupt channel #3 to notify
user for IRQs of RTC alarm, thermal alarm and WDOG etc., mailbox
RX doorbell mode is used for this function, this patch adds
support for it.

Signed-off-by: Anson Huang 
Reviewed-by: Dong Aisheng 
---
No changes.
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 0cb9398..70ef3db 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -21,6 +21,7 @@
mmc1 = 
mmc2 = 
serial0 = _lpuart0;
+   mu1 = _mu1;
};
 
cpus {
@@ -117,7 +118,8 @@
scu {
compatible = "fsl,imx-scu";
mbox-names = "tx0", "tx1", "tx2", "tx3",
-"rx0", "rx1", "rx2", "rx3";
+"rx0", "rx1", "rx2", "rx3",
+"gip3";
mboxes = <_mu1 0 0
  _mu1 0 1
  _mu1 0 2
@@ -125,7 +127,8 @@
  _mu1 1 0
  _mu1 1 1
  _mu1 1 2
- _mu1 1 3>;
+ _mu1 1 3
+ _mu1 3 3>;
 
clk: clock-controller {
compatible = "fsl,imx8qxp-clk";
-- 
2.7.4

[PATCH V6 1/4] dt-bindings: fsl: scu: add general interrupt support

[Anson Huang]

Add scu general interrupt function support.

Signed-off-by: Anson Huang 
Reviewed-by: Rob Herring 
Reviewed-by: Dong Aisheng 
---
No changes.
---
 .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 29 +-
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 72d481c..5d7dbab 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -22,9 +22,11 @@ Required properties:
 ---
 - compatible:  should be "fsl,imx-scu".
 - mbox-names:  should include "tx0", "tx1", "tx2", "tx3",
-  "rx0", "rx1", "rx2", "rx3".
-- mboxes:  List of phandle of 4 MU channels for tx and 4 MU channels
-   for rx. All 8 MU channels must be in the same MU instance.
+  "rx0", "rx1", "rx2", "rx3";
+   include "gip3" if want to support general MU interrupt.
+- mboxes:  List of phandle of 4 MU channels for tx, 4 MU channels for
+   rx, and 1 optional MU channel for general interrupt.
+   All MU channels must be in the same MU instance.
Cross instances are not allowed. The MU instance can only
be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
to make sure use the one which is not conflict with other
@@ -34,6 +36,7 @@ Required properties:
Channel 1 must be "tx1" or "rx1".
Channel 2 must be "tx2" or "rx2".
Channel 3 must be "tx3" or "rx3".
+   General interrupt rx channel must be "gip3".
e.g.
mboxes = <_mu1 0 0
  _mu1 0 1
@@ -42,10 +45,18 @@ Required properties:
  _mu1 1 0
  _mu1 1 1
  _mu1 1 2
- _mu1 1 3>;
+ _mu1 1 3
+ _mu1 3 3>;
See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
for detailed mailbox binding.
 
+Note: Each mu which supports general interrupt should have an alias correctly
+numbered in "aliases" node.
+e.g.
+aliases {
+   mu1 = _mu1;
+};
+
 i.MX SCU Client Device Node:
 
 
@@ -124,6 +135,10 @@ Required properties:
 
 Example (imx8qxp):
 -
+aliases {
+   mu1 = _mu1;
+};
+
 lsio_mu1: mailbox@5d1c {
...
#mbox-cells = <2>;
@@ -133,7 +148,8 @@ firmware {
scu {
compatible = "fsl,imx-scu";
mbox-names = "tx0", "tx1", "tx2", "tx3",
-"rx0", "rx1", "rx2", "rx3";
+"rx0", "rx1", "rx2", "rx3",
+"gip3";
mboxes = <_mu1 0 0
  _mu1 0 1
  _mu1 0 2
@@ -141,7 +157,8 @@ firmware {
  _mu1 1 0
  _mu1 1 1
  _mu1 1 2
- _mu1 1 3>;
+ _mu1 1 3
+ _mu1 3 3>;
 
clk: clk {
compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
-- 
2.7.4

[PATCH V6 2/4] firmware: imx: enable imx scu general irq function

[Anson Huang]

The System Controller Firmware (SCFW) controls RTC, thermal
and WDOG etc., these resources' interrupt function are managed
by SCU. When any IRQ pending, SCU will notify Linux via MU general
interrupt channel #3, and Linux kernel needs to call SCU APIs
to get IRQ status and notify each module to handle the interrupt.

Since there is no data transmission for SCU IRQ notification, so
doorbell mode is used for this MU channel, and SCU driver will
use notifier mechanism to broadcast to every module which registers
the SCU block notifier.

Signed-off-by: Anson Huang 
---
Changes since V5:
- use ATOMIC_NOTIFIER instead of BLOCKING_NOTIFIER for irq notification;
- add memory free for failed case to avoid memory leak;
- add new API imx_scu_irq_enable() for modules to enable/disable their 
own irqs.
---
 drivers/firmware/imx/Makefile  |   2 +-
 drivers/firmware/imx/imx-scu-irq.c | 166 +
 drivers/firmware/imx/imx-scu.c |   6 ++
 include/linux/firmware/imx/sci.h   |   5 ++
 4 files changed, 178 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/imx/imx-scu-irq.c

diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 1b2e15b..802c4ad 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o
+obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o imx-scu-irq.o
 obj-$(CONFIG_IMX_SCU_PD)   += scu-pd.o
diff --git a/drivers/firmware/imx/imx-scu-irq.c 
b/drivers/firmware/imx/imx-scu-irq.c
new file mode 100644
index 000..4000c63
--- /dev/null
+++ b/drivers/firmware/imx/imx-scu-irq.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ *
+ * Implementation of the SCU IRQ functions using MU.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#define IMX_SC_IRQ_FUNC_ENABLE 1
+#define IMX_SC_IRQ_FUNC_STATUS 2
+#define IMX_SC_IRQ_NUM_GROUP   4
+
+static u32 mu_resource_id;
+
+struct imx_sc_msg_irq_get_status {
+   struct imx_sc_rpc_msg hdr;
+   union {
+   struct {
+   u16 resource;
+   u8 group;
+   u8 reserved;
+   } __packed req;
+   struct {
+   u32 status;
+   } resp;
+   } data;
+};
+
+struct imx_sc_msg_irq_enable {
+   struct imx_sc_rpc_msg hdr;
+   u32 mask;
+   u16 resource;
+   u8 group;
+   u8 enable;
+} __packed;
+
+static struct imx_sc_ipc *imx_sc_irq_ipc_handle;
+static struct work_struct imx_sc_irq_work;
+static ATOMIC_NOTIFIER_HEAD(imx_scu_irq_notifier_chain);
+
+int imx_scu_irq_register_notifier(struct notifier_block *nb)
+{
+   return atomic_notifier_chain_register(
+   _scu_irq_notifier_chain, nb);
+}
+EXPORT_SYMBOL(imx_scu_irq_register_notifier);
+
+int imx_scu_irq_unregister_notifier(struct notifier_block *nb)
+{
+   return atomic_notifier_chain_unregister(
+   _scu_irq_notifier_chain, nb);
+}
+EXPORT_SYMBOL(imx_scu_irq_unregister_notifier);
+
+static int imx_scu_irq_notifier_call_chain(unsigned long status, u8 *group)
+{
+   return atomic_notifier_call_chain(_scu_irq_notifier_chain,
+   status, (void *)group);
+}
+
+static void imx_scu_irq_work_handler(struct work_struct *work)
+{
+   struct imx_sc_msg_irq_get_status msg;
+   struct imx_sc_rpc_msg *hdr = 
+   u32 irq_status;
+   int ret;
+   u8 i;
+
+   for (i = 0; i < IMX_SC_IRQ_NUM_GROUP; i++) {
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_IRQ;
+   hdr->func = IMX_SC_IRQ_FUNC_STATUS;
+   hdr->size = 2;
+
+   msg.data.req.resource = mu_resource_id;
+   msg.data.req.group = i;
+
+   ret = imx_scu_call_rpc(imx_sc_irq_ipc_handle, , true);
+   if (ret) {
+   pr_err("get irq group %d status failed, ret %d\n",
+  i, ret);
+   return;
+   }
+
+   irq_status = msg.data.resp.status;
+   if (!irq_status)
+   continue;
+
+   imx_scu_irq_notifier_call_chain(irq_status, );
+   }
+}
+
+void imx_scu_irq_enable(u8 group, u32 mask, u8 enable)
+{
+   struct imx_sc_msg_irq_enable msg;
+   struct imx_sc_rpc_msg *hdr = 
+   int ret;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_IRQ;
+   hdr->func = IMX_SC_IRQ_FUNC_ENABLE;
+   hdr->size = 3;
+
+   msg.resource = mu_resource_id;
+   msg.group = group;
+   msg.mask = mask;
+   msg.enable = enable;
+
+   ret = imx_scu_call_rpc(imx_sc_irq_ipc_handle, , true);
+   if (ret)
+   pr_err("enable irq failed, group %d, mask %d, ret %d\n",
+   group, mask, ret);
+}

Re: [RFC PATCH v2 11/14] x86/watchdog/hardlockup: Add an HPET-based hardlockup detector

[Ricardo Neri]

On Fri, Apr 05, 2019 at 04:12:56PM +, Suthikulpanit, Suravee wrote:
> Hi Neri,

Hi Suravee,

Many thanks for testing the patches!
> 
> While trying out this patch series, I found that it does not work when the 
> HPET timer
> is in periodic mode.

I should have tested this better. I'll double check my setup.
> 
> On 2/27/19 11:05 PM, Ricardo Neri wrote:
> > ..
> > diff --git a/arch/x86/kernel/watchdog_hld_hpet.c 
> > b/arch/x86/kernel/watchdog_hld_hpet.c
> > new file mode 100644
> > index ..cfa284da4bf6
> > --- /dev/null
> > +++ b/arch/x86/kernel/watchdog_hld_hpet.c
> > @@ -0,0 +1,405 @@
> > .
> > +
> > +/**
> > + * set_comparator() - Update the comparator in an HPET timer instance
> > + * @hdata: A data structure with the timer instance to update
> > + * @cmp:   The value to write in the in the comparator registere
> > + *
> > + * Returns:
> > + *
> > + * None
> > + */
> > +static inline void set_comparator(struct hpet_hld_data *hdata,
> > + unsigned long cmp)
> > +{
> > +   hpet_writeq(cmp, HPET_Tn_CMP(hdata->num));
> > +}
> > +
> > +/**
> > + * kick_timer() - Reprogram timer to expire in the future
> > + * @hdata: A data structure with the timer instance to update
> > + * @force: Force reprogram. Useful enabling or re-enabling detector.
> > + *
> > + * Reprogram the timer to expire within watchdog_thresh seconds in the 
> > future.
> > + *
> > + * Returns:
> > + *
> > + * None
> > + */
> > +static void kick_timer(struct hpet_hld_data *hdata, bool force)
> > +{
> > +   bool kick_needed = force || !(hdata->flags & HPET_DEV_PERI_CAP);
> > +   unsigned long new_compare, count;
> > +
> > +   /*
> > +* Update the comparator in increments of watch_thresh seconds relative
> > +* to the current count. Since watch_thresh is given in seconds, we
> > +* are able to update the comparator before the counter reaches such new
> > +* value.
> > +*
> > +* Let it wrap around if needed.
> > +*/
> > +
> > +   if (kick_needed) {
> > +   count = get_count();
> > +
> > +   new_compare = count + watchdog_thresh * hdata->ticks_per_second;
> > +
> > +   set_comparator(hdata, new_compare);
> > +   }
> > +}
> 
> It turns out that the set_comparator() does not seem to support periodic mode,
> in which it should have been setting the accumulator/period via the 
> comparator register.
> 
> Instead, what if we re-factor the code in the 
> arch/x86/kernel/hpet.c:hpet_set_periodic()
> to hpet_set_comparator(). Then we can also reuse it in the 
> arch/x86/kernel/watchdog_hld_pet.c:
> kick_timer() as shown below.
> 
> With these changes, I can test the series on AMD systems, and see all cores
> in /proc/interrupts are receiving NMI interrupts.

These changes look OK to me. Thanks! I'll incorporate them in my next version.

> 
> Regards,
> Suravee
> 
> 
> diff --git a/arch/x86/include/asm/hpet.h b/arch/x86/include/asm/hpet.h
> index 0976334..f30957f 100644
> --- a/arch/x86/include/asm/hpet.h
> +++ b/arch/x86/include/asm/hpet.h
> @@ -115,6 +115,7 @@ extern int hpet_rtc_timer_init(void);
>   extern irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id);
>   extern int hpet_register_irq_handler(rtc_irq_handler handler);
>   extern void hpet_unregister_irq_handler(rtc_irq_handler handler);
> +extern void hpet_set_comparator(int num, unsigned int cmp, unsigned int 
> period);
> 
>   #endif /* CONFIG_HPET_EMULATE_RTC */
> 
> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index 03b05dae..f3b2351 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -328,6 +328,41 @@ static void hpet_legacy_clockevent_register(void)
>   printk(KERN_DEBUG "hpet clockevent registered\n");
>   }
> 
> +/*
> + * hpet_set_comparator() - Helper function for setting comparator register
> + * @num: The timer ID
> + * @cmp: The value to be written to the comparator/accumulator
> + * @period:  The value to be written to the period (0 = oneshot mode)
> + *
> + * Helper function for updating comparator, accumulator and period values.
> + *
> + * In periodic mode, HPET needs HPET_TN_SETVAL to be set before writing
> + * to the Tn_CMP to update the accumulator. Then, HPET needs a second
> + * write (with HPET_TN_SETVAL cleared) to Tn_CMP to set the period.
> + * The HPET_TN_SETVAL bit is automatically cleared after the first write.
> + *
> + * For one-shot mode, HPET_TN_SETVAL does not need to be set.
> + *
> + * See the following documents:
> + *   - Intel IA-PC HPET (High Precision Event Timers) Specification
> + *   - AMD-8111 HyperTransport I/O Hub Data Sheet, Publication # 24674
> + */
> +void hpet_set_comparator(int num, unsigned int cmp, unsigned int period)
> +{
> + if (period) {
> + unsigned int v = hpet_readl(HPET_Tn_CFG(num));
> + hpet_writel(v | HPET_TN_SETVAL, HPET_Tn_CFG(num));
> + }
> +
> + hpet_writel(cmp, HPET_Tn_CMP(num));
> + if (!period)
> + return;
> +
> +

Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak

[pierre kuo]

hi Rob, Marek and Frank:

> >
> > In this patch, we un-reserving memory ONLY if explicit compatible matching 
> > fail.
> > That mean driver found something wrong while matching and let OS know.
> > (But reserved-memory without compatible property will not be affected.)
> >
> > So per ur explaination, there would be cases that driver reported
> > matching memory fail,
> > but the memory is still needed by another processor?
>

Would you mind to give some comment and suggestion for this patch?

Sincerely appreciate ur kind help.

[PATCH v2 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller driver

[Mason Yang]

Add a driver for Macronix MX25F0A NAND controller.

Signed-off-by: Mason Yang 
---
 drivers/mtd/nand/raw/Kconfig |   6 +
 drivers/mtd/nand/raw/Makefile|   1 +
 drivers/mtd/nand/raw/mxic_nand.c | 294 +++
 3 files changed, 301 insertions(+)
 create mode 100644 drivers/mtd/nand/raw/mxic_nand.c

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index e604625..e0329cc 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -522,6 +522,12 @@ config MTD_NAND_QCOM
  Enables support for NAND flash chips on SoCs containing the EBI2 NAND
  controller. This controller is found on IPQ806x SoC.
 
+config MTD_NAND_MXIC
+   tristate "Macronix MX25F0A NAND controller"
+   depends on HAS_IOMEM
+   help
+ This selects the Macronix MX25F0A NAND controller driver.
+
 config MTD_NAND_MTK
tristate "Support for NAND controller on MTK SoCs"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 5a5a72f..c8a6790 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_MTD_NAND_SUNXI)  += sunxi_nand.o
 obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/
 obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o
+obj-$(CONFIG_MTD_NAND_MXIC)+= mxic_nand.o
 obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o
 obj-$(CONFIG_MTD_NAND_TEGRA)   += tegra_nand.o
 obj-$(CONFIG_MTD_NAND_STM32_FMC2)  += stm32_fmc2_nand.o
diff --git a/drivers/mtd/nand/raw/mxic_nand.c b/drivers/mtd/nand/raw/mxic_nand.c
new file mode 100644
index 000..689fae2
--- /dev/null
+++ b/drivers/mtd/nand/raw/mxic_nand.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2019 Macronix International Co., Ltd.
+//
+// Authors:
+// Mason Yang 
+// zhengxunli 
+//
+
+#include 
+#include 
+#include 
+
+#include "internals.h"
+
+struct mxic_nand_ctlr {
+   struct mx25f0a_mfd *mfd;
+   struct nand_controller base;
+   struct nand_chip nand;
+};
+
+static void mxic_host_init(struct mxic_nand_ctlr *mxic)
+{
+   writel(DATA_STROB_EDO_EN, mxic->mfd->regs + DATA_STROB);
+   writel(INT_STS_ALL, mxic->mfd->regs + INT_STS_EN);
+   writel(0x0, mxic->mfd->regs + ONFI_DIN_CNT(0));
+   writel(HC_CFG_NIO(8) | HC_CFG_SLV_ACT(0) | HC_CFG_IDLE_SIO_LVL(1) |
+  HC_CFG_TYPE(1, HC_CFG_TYPE_RAW_NAND) | HC_CFG_MAN_CS_EN,
+  mxic->mfd->regs + HC_CFG);
+   writel(0x0, mxic->mfd->regs + HC_EN);
+}
+
+static int  mxic_nand_wait_ready(struct nand_chip *chip)
+{
+   struct mxic_nand_ctlr *mxic = nand_get_controller_data(chip);
+   u32 sts;
+
+   return readl_poll_timeout(mxic->mfd->regs + INT_STS, sts,
+ sts & INT_RDY_PIN, 0, USEC_PER_SEC);
+}
+
+static void mxic_nand_select_chip(struct nand_chip *chip, int chipnr)
+{
+   struct mxic_nand_ctlr *mxic = nand_get_controller_data(chip);
+
+   switch (chipnr) {
+   case 0:
+   case 1:
+   writel(HC_EN_BIT, mxic->mfd->regs + HC_EN);
+   writel(HC_CFG_MAN_CS_ASSERT | readl(mxic->mfd->regs + HC_CFG),
+  mxic->mfd->regs + HC_CFG);
+   break;
+
+   case -1:
+   writel(~HC_CFG_MAN_CS_ASSERT & readl(mxic->mfd->regs + HC_CFG),
+  mxic->mfd->regs + HC_CFG);
+   writel(0, mxic->mfd->regs + HC_EN);
+   break;
+
+   default:
+   break;
+   }
+}
+
+static int mxic_nand_data_xfer(struct mxic_nand_ctlr *mxic, const void *txbuf,
+  void *rxbuf, unsigned int len)
+{
+   unsigned int pos = 0;
+
+   while (pos < len) {
+   unsigned int nbytes = len - pos;
+   u32 data = 0x;
+   u32 sts;
+   int ret;
+
+   if (nbytes > 4)
+   nbytes = 4;
+
+   if (txbuf)
+   memcpy(, txbuf + pos, nbytes);
+
+   ret = readl_poll_timeout(mxic->mfd->regs + INT_STS, sts,
+sts & INT_TX_EMPTY, 0, USEC_PER_SEC);
+   if (ret)
+   return ret;
+
+   writel(data, mxic->mfd->regs + TXD(nbytes % 4));
+
+   if (rxbuf) {
+   ret = readl_poll_timeout(mxic->mfd->regs + INT_STS, sts,
+sts & INT_TX_EMPTY, 0,
+USEC_PER_SEC);
+   if (ret)
+   return ret;
+
+   ret = readl_poll_timeout(mxic->mfd->regs + INT_STS, sts,
+sts & INT_RX_NOT_EMPTY, 0,
+

[PATCH v2 3/4] spi: Add MFD for Macronix MX25F0A SPI controller driver

[Mason Yang]

Add a MFD driver for Macronix MX25F0A SPI controller.

Signed-off-by: Mason Yang 
---
 drivers/spi/spi-mxic.c | 275 +
 1 file changed, 49 insertions(+), 226 deletions(-)

diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index e41ae6e..f98f8e0 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -9,168 +9,13 @@
 //
 
 #include 
-#include 
-#include 
-#include 
-#include 
+#include 
 #include 
 #include 
 #include 
 
-#define HC_CFG 0x0
-#define HC_CFG_IF_CFG(x)   ((x) << 27)
-#define HC_CFG_DUAL_SLAVE  BIT(31)
-#define HC_CFG_INDIVIDUAL  BIT(30)
-#define HC_CFG_NIO(x)  (((x) / 4) << 27)
-#define HC_CFG_TYPE(s, t)  ((t) << (23 + ((s) * 2)))
-#define HC_CFG_TYPE_SPI_NOR0
-#define HC_CFG_TYPE_SPI_NAND   1
-#define HC_CFG_TYPE_SPI_RAM2
-#define HC_CFG_TYPE_RAW_NAND   3
-#define HC_CFG_SLV_ACT(x)  ((x) << 21)
-#define HC_CFG_CLK_PH_EN   BIT(20)
-#define HC_CFG_CLK_POL_INV BIT(19)
-#define HC_CFG_BIG_ENDIAN  BIT(18)
-#define HC_CFG_DATA_PASS   BIT(17)
-#define HC_CFG_IDLE_SIO_LVL(x) ((x) << 16)
-#define HC_CFG_MAN_START_ENBIT(3)
-#define HC_CFG_MAN_START   BIT(2)
-#define HC_CFG_MAN_CS_EN   BIT(1)
-#define HC_CFG_MAN_CS_ASSERT   BIT(0)
-
-#define INT_STS0x4
-#define INT_STS_EN 0x8
-#define INT_SIG_EN 0xc
-#define INT_STS_ALLGENMASK(31, 0)
-#define INT_RDY_PINBIT(26)
-#define INT_RDY_SR BIT(25)
-#define INT_LNR_SUSP   BIT(24)
-#define INT_ECC_ERRBIT(17)
-#define INT_CRC_ERRBIT(16)
-#define INT_LWR_DISBIT(12)
-#define INT_LRD_DISBIT(11)
-#define INT_SDMA_INT   BIT(10)
-#define INT_DMA_FINISH BIT(9)
-#define INT_RX_NOT_FULLBIT(3)
-#define INT_RX_NOT_EMPTY   BIT(2)
-#define INT_TX_NOT_FULLBIT(1)
-#define INT_TX_EMPTY   BIT(0)
-
-#define HC_EN  0x10
-#define HC_EN_BIT  BIT(0)
-
-#define TXD(x) (0x14 + ((x) * 4))
-#define RXD0x24
-
-#define SS_CTRL(s) (0x30 + ((s) * 4))
-#define LRD_CFG0x44
-#define LWR_CFG0x80
-#define RWW_CFG0x70
-#define OP_READBIT(23)
-#define OP_DUMMY_CYC(x)((x) << 17)
-#define OP_ADDR_BYTES(x)   ((x) << 14)
-#define OP_CMD_BYTES(x)(((x) - 1) << 13)
-#define OP_OCTA_CRC_EN BIT(12)
-#define OP_DQS_EN  BIT(11)
-#define OP_ENHC_EN BIT(10)
-#define OP_PREAMBLE_EN BIT(9)
-#define OP_DATA_DDRBIT(8)
-#define OP_DATA_BUSW(x)((x) << 6)
-#define OP_ADDR_DDRBIT(5)
-#define OP_ADDR_BUSW(x)((x) << 3)
-#define OP_CMD_DDR BIT(2)
-#define OP_CMD_BUSW(x) (x)
-#define OP_BUSW_1  0
-#define OP_BUSW_2  1
-#define OP_BUSW_4  2
-#define OP_BUSW_8  3
-
-#define OCTA_CRC   0x38
-#define OCTA_CRC_IN_EN(s)  BIT(3 + ((s) * 16))
-#define OCTA_CRC_CHUNK(s, x)   ((fls((x) / 32)) << (1 + ((s) * 16)))
-#define OCTA_CRC_OUT_EN(s) BIT(0 + ((s) * 16))
-
-#define ONFI_DIN_CNT(s)(0x3c + (s))
-
-#define LRD_CTRL   0x48
-#define RWW_CTRL   0x74
-#define LWR_CTRL   0x84
-#define LMODE_EN   BIT(31)
-#define LMODE_SLV_ACT(x)   ((x) << 21)
-#define LMODE_CMD1(x)  ((x) << 8)
-#define LMODE_CMD0(x)  (x)
-
-#define LRD_ADDR   0x4c
-#define LWR_ADDR   0x88
-#define LRD_RANGE  0x50
-#define LWR_RANGE  0x8c
-
-#define AXI_SLV_ADDR   0x54
-
-#define DMAC_RD_CFG0x58
-#define DMAC_WR_CFG0x94
-#define DMAC_CFG_PERIPH_EN BIT(31)
-#define DMAC_CFG_ALLFLUSH_EN   BIT(30)
-#define DMAC_CFG_LASTFLUSH_EN  BIT(29)
-#define DMAC_CFG_QE(x) (((x) + 1) << 16)
-#define DMAC_CFG_BURST_LEN(x)  (((x) + 1) << 12)
-#define DMAC_CFG_BURST_SZ(x)   ((x) << 8)
-#define DMAC_CFG_DIR_READ  BIT(1)
-#define DMAC_CFG_START BIT(0)
-
-#define DMAC_RD_CNT0x5c
-#define DMAC_WR_CNT0x98
-
-#define SDMA_ADDR  0x60
-
-#define DMAM_CFG   0x64
-#define DMAM_CFG_START BIT(31)
-#define DMAM_CFG_CONT  BIT(30)
-#define DMAM_CFG_SDMA_GAP(x)   (fls((x) / 8192) << 2)
-#define DMAM_CFG_DIR_READ  BIT(1)
-#define DMAM_CFG_ENBIT(0)
-
-#define DMAM_CNT   0x68
-
-#define LNR_TIMER_TH   0x6c
-
-#define RDM_CFG0   0x78
-#define RDM_CFG0_POLY(x)   (x)
-
-#define RDM_CFG1   0x7c
-#define RDM_CFG1_RDM_ENBIT(31)
-#define RDM_CFG1_SEED(x)   (x)
-
-#define LWR_SUSP_CTRL  0x90
-#define LWR_SUSP_CTRL_EN   BIT(31)
-
-#define DMAS_CTRL 

[PATCH v2 0/4] Add Macronix MX25F0A MFD driver for raw nand and spi

[Mason Yang]

Hi,

This patches support Macronix MX25F0A MFD driver for raw nand and spi
controller which is separated form previous patchset:

https://patchwork.kernel.org/patch/10874679/

thanks for your review.

best regards,
Mason

Mason Yang (4):
  mfd: Add Macronix MX25F0A MFD controller driver
  mtd: rawnand: Add Macronix MX25F0A NAND controller driver
  spi: Add MFD for Macronix MX25F0A SPI controller driver
  dt-bindings: mfd: Document Macronix MX25F0A controller bindings

 .../devicetree/bindings/mfd/mxic-mx25f0a.txt   |  51 
 drivers/mfd/Kconfig|   9 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/mxic-mx25f0a.c |  84 ++
 drivers/mtd/nand/raw/Kconfig   |   6 +
 drivers/mtd/nand/raw/Makefile  |   1 +
 drivers/mtd/nand/raw/mxic_nand.c   | 294 +
 drivers/spi/spi-mxic.c | 275 ---
 include/linux/mfd/mxic-mx25f0a.h   | 175 
 9 files changed, 670 insertions(+), 226 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/mxic-mx25f0a.txt
 create mode 100644 drivers/mfd/mxic-mx25f0a.c
 create mode 100644 drivers/mtd/nand/raw/mxic_nand.c
 create mode 100644 include/linux/mfd/mxic-mx25f0a.h

-- 
1.9.1

Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak

[pierre kuo]

hi Rob, Marek and Frank:

> > In this patch, we un-reserving memory ONLY if explicit compatible matching 
> > fail.
> > That mean driver found something wrong while matching and let OS know.
> > (But reserved-memory without compatible property will not be affected.)
> >
> > So per ur explaination, there would be cases that driver reported
> > matching memory fail,
> > but the memory is still needed by another processor?

Would you mind to give some comment and suggestion for this patch?

Sincerely appreciate ur kind help,

[PATCH v2 4/4] dt-bindings: mfd: Document Macronix MX25F0A controller bindings

[Mason Yang]

Document the bindings used by the Macronix MX25F0A MFD controller.

Signed-off-by: Mason Yang 
---
 .../devicetree/bindings/mfd/mxic-mx25f0a.txt   | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/mxic-mx25f0a.txt

diff --git a/Documentation/devicetree/bindings/mfd/mxic-mx25f0a.txt 
b/Documentation/devicetree/bindings/mfd/mxic-mx25f0a.txt
new file mode 100644
index 000..7f3e0f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mxic-mx25f0a.txt
@@ -0,0 +1,51 @@
+Macronix MX25F0A MultiFunction Device Tree Bindings
+
+
+MX25F0A is a MultiFunction Device with SPI and raw NAND, which
+supports either spi host controller or raw nand controller.
+
+Required properties:
+- compatible: should be "mxic,mx25f0a"
+- #address-cells: should be 1
+- #size-cells: should be 0
+- reg: should contain 2 entries, one for the registers and one for the direct
+   mapping area in SPI mode.
+- reg-names: should contain "regs" and "dirmap"
+- interrupts: interrupt line connected to this MFD controller
+- SPI controller driver:
+   - clock-names: should contain "ps_clk", "send_clk" and
+  "send_dly_clk"
+   - clocks: should contain 3 entries for the "ps_clk", "send_clk"
+ and "send_dly_clk" clocks
+
+- Raw nand controller driver.
+   - nand-ecc-mode = "soft";
+   - nand-ecc-algo = "bch";
+
+Example:
+
+   mxic: mx25f0a@43c3 {
+   compatible = "mxic,mx25f0a";
+   reg = <0x43c3 0x1>, <0xa000 0x400>;
+   reg-names = "regs", "dirmap";
+
+   /* spi */
+   clocks = < 0>, < 1>, < 15>;
+   clock-names = "send_clk", "send_dly_clk", "ps_clk";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2500>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   };
+
+   /* nand */
+   nand-ecc-mode = "soft";
+   nand-ecc-algo = "bch";
+   nand-ecc-step-size = <512>;
+   nand-ecc-strength = <8>;
+   };
-- 
1.9.1

[PATCH v2 1/4] mfd: Add Macronix MX25F0A MFD controller driver

[Mason Yang]

Add a driver for Macronix MX25F0A multifunction device controller.

Signed-off-by: Mason Yang 
---
 drivers/mfd/Kconfig  |   9 ++
 drivers/mfd/Makefile |   1 +
 drivers/mfd/mxic-mx25f0a.c   |  84 +++
 include/linux/mfd/mxic-mx25f0a.h | 175 +++
 4 files changed, 269 insertions(+)
 create mode 100644 drivers/mfd/mxic-mx25f0a.c
 create mode 100644 include/linux/mfd/mxic-mx25f0a.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 26ad646..7e99e93 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -823,6 +823,15 @@ config MFD_MAX8998
  additional drivers must be enabled in order to use the functionality
  of the device.
 
+config MFD_MXIC_MX25F0A
+   tristate "Macronix mx25f0a multifunction device support"
+   select MFD_CORE
+   help
+ This supports for Macronix mx25f0a multifunction device controller
+ for raw nand or spi. You have to select individual components like
+ raw nand controller or spi host controller under the corresponding
+ menus.
+
 config MFD_MT6397
tristate "MediaTek MT6397 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b4569ed7..dcfe8fd 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -163,6 +163,7 @@ max8925-objs:= max8925-core.o 
max8925-i2c.o
 obj-$(CONFIG_MFD_MAX8925)  += max8925.o
 obj-$(CONFIG_MFD_MAX8997)  += max8997.o max8997-irq.o
 obj-$(CONFIG_MFD_MAX8998)  += max8998.o max8998-irq.o
+obj-$(CONFIG_MFD_MXIC_MX25F0A) += mxic-mx25f0a.o
 
 pcf50633-objs  := pcf50633-core.o pcf50633-irq.o
 obj-$(CONFIG_MFD_PCF50633) += pcf50633.o
diff --git a/drivers/mfd/mxic-mx25f0a.c b/drivers/mfd/mxic-mx25f0a.c
new file mode 100644
index 000..a884d97
--- /dev/null
+++ b/drivers/mfd/mxic-mx25f0a.c
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2019 Macronix International Co., Ltd.
+//
+// Author:
+// Mason Yang 
+//
+
+#include 
+#include 
+#include 
+
+static const struct mfd_cell mx25f0a_nand_ctlr = {
+   .name = "mxic-nand-ctlr",
+   .of_compatible = "mxicy,mx25f0a-nand-ctlr",
+};
+
+static const struct mfd_cell mx25f0a_spi_ctlr = {
+   .name = "mxic-spi",
+   .of_compatible = "mxicy,mx25f0a-spi",
+};
+
+static int mx25f0a_mfd_probe(struct platform_device *pdev)
+{
+   const struct mfd_cell *cell;
+   struct mx25f0a_mfd *mxic;
+   struct resource *res;
+   int ret;
+
+   ret = of_device_is_compatible(pdev->dev.of_node->child,
+ "jedec,spi-nor");
+   if (ret)
+   cell = _spi_ctlr;
+   else
+   cell = _nand_ctlr;
+
+   mxic = devm_kzalloc(>dev, sizeof(*mxic), GFP_KERNEL);
+   if (!mxic)
+   return -ENOMEM;
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
+   mxic->regs = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(mxic->regs))
+   return PTR_ERR(mxic->regs);
+
+   if (cell == _spi_ctlr) {
+   mxic->ps_clk = devm_clk_get(>dev, "ps_clk");
+   if (IS_ERR(mxic->ps_clk))
+   return PTR_ERR(mxic->ps_clk);
+
+   mxic->send_clk = devm_clk_get(>dev, "send_clk");
+   if (IS_ERR(mxic->send_clk))
+   return PTR_ERR(mxic->send_clk);
+
+   mxic->send_dly_clk = devm_clk_get(>dev, "send_dly_clk");
+   if (IS_ERR(mxic->send_dly_clk))
+   return PTR_ERR(mxic->send_dly_clk);
+   }
+
+   platform_set_drvdata(pdev, mxic);
+
+   ret = devm_mfd_add_devices(>dev, -1, cell, 1, NULL, 0, NULL);
+
+   return ret;
+}
+
+static const struct of_device_id mx25f0a_mfd_of_match[] = {
+   { .compatible = "mxic,mx25f0a", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, mx25f0a_mfd_of_match);
+
+static struct platform_driver mx25f0a_mfd_driver = {
+   .probe  = mx25f0a_mfd_probe,
+   .driver = {
+   .name = "mx25f0a-mfd",
+   .of_match_table = mx25f0a_mfd_of_match,
+   },
+};
+module_platform_driver(mx25f0a_mfd_driver);
+
+MODULE_AUTHOR("Mason Yang ");
+MODULE_DESCRIPTION("MX25F0A controller MFD driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/mxic-mx25f0a.h b/include/linux/mfd/mxic-mx25f0a.h
new file mode 100644
index 000..cb7bf19
--- /dev/null
+++ b/include/linux/mfd/mxic-mx25f0a.h
@@ -0,0 +1,175 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+//
+// Copyright (C) 2019 Macronix International Co., Ltd.
+//
+// Author:
+// Mason Yang 
+//
+
+#ifndef __MFD_MXIC_MX25F0A_H
+#define __MFD_MXIC_MX25F0A_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HC_CFG 0x0
+#define HC_CFG_IF_CFG(x)   ((x) << 27)
+#define HC_CFG_DUAL_SLAVE  BIT(31)
+#define HC_CFG_INDIVIDUAL  

Re: [RFC PATCH v2 13/14] watchdog/hardlockup/hpet: Only enable the HPET watchdog via a boot parameter

[Ricardo Neri]

On Tue, Mar 26, 2019 at 10:29:52PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Feb 2019, Ricardo Neri wrote:
> > +   When hpet is specified, the NMI watchdog will be driven
> > +   by an HPET timer, if available in the system. Otherwise,
> > +   the perf-based implementation will be used. Specifying
> > +   hpet implies that nmi_watchdog is on.
> 
> How so?
> 
I meant to say that the user does not need to provide nmi_watchdog=1 and
nmi_watchdog=hpet separately.

I think this is true because watchdog_user_enabled in kernel/watchdog.c is set
to 1 when CONFIG_HARDLOCKUP_DETECTOR is selected. Also, if 
nmi_watchdog_available
is set to true if watchdog_nmi_probe() is successful.

Perhaps I can add a warning in case nmi_watchdog=hpet and either
CONFIG_HARDLOCKUP_DETECTOR or CONFIG_HARDLOCKUP_DETECTOR_HPET are not
selected?

> > +static int __init hardlockup_detector_hpet_setup(char *str)
> > +{
> > +   if (strstr(str, "hpet"))
> > +   hardlockup_use_hpet = true;
> 
> strstr()? Not really.

Is strncmp(str, "hpet", 5) more acceptable?

> 
> > +
> > +   return 0;
> > +}
> > +__setup("nmi_watchdog=", hardlockup_detector_hpet_setup);
> > +
> >  /**
> >   * hardlockup_detector_hpet_init() - Initialize the hardlockup detector
> >   *
> > @@ -405,6 +422,9 @@ int __init hardlockup_detector_hpet_init(void)
> >  {
> > int ret;
> >  
> > +   if (!hardlockup_use_hpet)
> > +   return -ENODEV;
> 
> This should have been there in the patch which introduces
> hardlockup_detector_hpet_init(). And this patch merily adds the command
> line magic which sets that flag.

Sure, I will move this check into the patch that introduces
hardlockup_detector_hpet_init().

> 
> > +
> > if (!is_hpet_enabled())
> > return -ENODEV;
> >  
> > diff --git a/kernel/watchdog.c b/kernel/watchdog.c
> > index 367aa81294ef..28cad7310378 100644
> > --- a/kernel/watchdog.c
> > +++ b/kernel/watchdog.c
> > @@ -78,7 +78,7 @@ static int __init hardlockup_panic_setup(char *str)
> > nmi_watchdog_user_enabled = 0;
> > else if (!strncmp(str, "1", 1))
> > nmi_watchdog_user_enabled = 1;
> > -   return 1;
> > +   return 0;
> 
> Why?

My understanding is that this is needed so that other __setup functions that 
also
want to check "nmi_watchdog" are able to do it. Is this understanding
not correct?

Thanks and BR,
Ricardo

Re: [RFC PATCH v2 08/14] watchdog/hardlockup: Decouple the hardlockup detector from perf

[Ricardo Neri]

On Tue, Mar 26, 2019 at 10:18:32PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Feb 2019, Ricardo Neri wrote:
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Detect hard lockups on a system
> > + *
> > + * Copyright (C) Intel Corporation 2019
> > + *
> > + * Note: All of this code comes from the original perf-specific hardlockup
> > + * detector.
> 
> And because you copied it from there without modification this becomes
> automatically Copyrighted by Intel?

Yes, it does not look correct.

> 
> May I recommend that you talk to your legal departement about this.
> 
> Aside of that there is really no value in creating yet another file. The
> code in question can simply wrapped into a large #ifdef PERF in the old
> file.

Sure, I'll implement the change in this manner.

Thanks and BR,
Ricardo

Re: [RFC PATCH v2 06/14] x86/hpet: Configure the timer used by the hardlockup detector

[Ricardo Neri]

On Tue, Mar 26, 2019 at 10:13:06PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Feb 2019, Ricardo Neri wrote:
> > +#ifdef CONFIG_X86_HARDLOCKUP_DETECTOR_HPET
> > +struct hpet_hld_data *hpet_hardlockup_detector_assign_timer(void)
> > +{
> > +   struct hpet_hld_data *hdata;
> > +   unsigned int cfg;
> > +
> > +   cfg = hpet_readl(HPET_Tn_CFG(HPET_WD_TIMER_NR));
> > +
> > +   if (!(cfg & HPET_TN_FSB_CAP))
> > +   return NULL;
> > +
> > +   hdata = kzalloc(sizeof(*hdata), GFP_KERNEL);
> > +   if (!hdata)
> > +   return NULL;
> > +
> > +   hdata->flags = HPET_DEV_FSB_CAP;
> 
> Pointless.

Agreed. Only if the timer is FSB-capable is hdata is initialized.
> 
> > +
> > +   if (cfg & HPET_TN_PERIODIC_CAP)
> > +   hdata->flags |= HPET_DEV_PERI_CAP;
> 
> This can be expressed by a simple:
> 
>  hdata->has_periodic = 1;
> 
> And no flag shuffling required at all.

Sure. I'll implement this change.

Thanks and BR,
Ricardo

Re: [RFC PATCH v2 03/14] x86/hpet: Calculate ticks-per-second in a separate function

[Ricardo Neri]

On Tue, Mar 26, 2019 at 10:03:02PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Feb 2019, Ricardo Neri wrote:
> >  int hpet_alloc(struct hpet_data *hdp)
> >  {
> > u64 cap, mcfg;
> > @@ -845,7 +868,6 @@ int hpet_alloc(struct hpet_data *hdp)
> > size_t siz;
> > struct hpet __iomem *hpet;
> > static struct hpets *last;
> > -   unsigned long period;
> > unsigned long long temp;
> > u32 remainder;
> >  
> > @@ -881,6 +903,8 @@ int hpet_alloc(struct hpet_data *hdp)
> >  
> > cap = readq(>hpet_cap);
> >  
> > +   temp = hpet_get_ticks_per_sec(cap);
> 
> Just putting stuff to random places does not make the code any better.

This seems to not be needed. I'll remove it and directly save the result
in hpetp->hp_tick_freq;

> 
> > ntimer = ((cap & HPET_NUM_TIM_CAP_MASK) >> HPET_NUM_TIM_CAP_SHIFT) + 1;
> >  
> > if (hpetp->hp_ntimer != ntimer) {
> > @@ -897,11 +921,6 @@ int hpet_alloc(struct hpet_data *hdp)
> >  
> > last = hpetp;
> >  
> > -   period = (cap & HPET_COUNTER_CLK_PERIOD_MASK) >>
> > -   HPET_COUNTER_CLK_PERIOD_SHIFT; /* fs, 10^-15 */
> > -   temp = 1000uLL; /* 10^15 femtoseconds per second */
> > -   temp += period >> 1; /* round */
> > -   do_div(temp, period);
> > hpetp->hp_tick_freq = temp; /* ticks per second */
> 
> What's wrong with the obvious:
> 
>hpetp->hp_tick_freq = hpet_get_ticks_per_sec(cap);
> 
> Hmm?

Nothing wrong. I'll implement this change.

Thanks and BR,
Ricardo

Re: [RFC PATCH v2 05/14] x86/hpet: Relocate flag definitions to a header file

[Ricardo Neri]

On Tue, Mar 26, 2019 at 10:11:16PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Feb 2019, Ricardo Neri wrote:
> 
> > Users of HPET timers (such as the hardlockup detector) need the definitions
> > of these flags to interpret the configuration of a timer as passed by
> > platform code.
> 
> Which platform code?

Sorry, it is not platform code. Shall I call it the HPET-enabling code?
> 
> > +#define HPET_DEV_USED_BIT  2
> > +#define HPET_DEV_USED  (1 << HPET_DEV_USED_BIT)
> > +#define HPET_DEV_VALID 0x8
> > +#define HPET_DEV_FSB_CAP   0x1000
> > +#define HPET_DEV_PERI_CAP  0x2000
> 
> I'm not seing why you would need any of those in the watchdog code.
> 
> The only function related to the watchdog which needs these is
> hpet_hardlockup_detector_assign_timer() and that is located in hpet.c
> itself.

Yes, I see now that it is not needed. This patch can be removed.

Thanks and BR,
Ricardo

Re: [RFC PATCH v2 12/14] x86/watchdog/hardlockup/hpet: Determine if HPET timer caused NMI

[Ricardo Neri]

On Tue, Mar 26, 2019 at 09:55:35PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Feb 2019, Ricardo Neri wrote:
> > @@ -62,7 +67,18 @@ static inline void set_comparator(struct hpet_hld_data 
> > *hdata,
> >  static void kick_timer(struct hpet_hld_data *hdata, bool force)
> >  {
> > bool kick_needed = force || !(hdata->flags & HPET_DEV_PERI_CAP);
> > -   unsigned long new_compare, count;
> > +   unsigned long tsc_curr, tsc_delta, new_compare, count;
> > +
> > +   /* Start obtaining the current TSC and HPET counts. */
> > +   tsc_curr = rdtsc();
> > +
> > +   if (kick_needed)
> > +   count = get_count();
> 
> Can you please keep the TSC code in one block and the HPET block in the
> next one? Having this inbetween is really bad to follow.
> 
> It really does not matter whether you read the HPET counter before or after
> the calculation. This is a crystal ball estimation anyway so a few cyles
> more or less are completely irrelevant.

Sure! I will implement this change.

Thanks and BR,
Ricardo

> 
> > +   tsc_delta = (unsigned long)watchdog_thresh * (unsigned long)tsc_khz
> > +   * 1000L;
> > +   hdata->tsc_next = tsc_curr + tsc_delta;
> > +   hdata->tsc_next_error = tsc_delta >> 6;
> 
> Thanks,
> 
>   tglx

Re: [RFC PATCH v2 02/14] x86/hpet: Expose more functions to read and write registers

[Ricardo Neri]

On Tue, Mar 26, 2019 at 10:00:24PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Feb 2019, Ricardo Neri wrote:
> >  struct irq_data;
> > @@ -109,6 +114,11 @@ extern void 
> > hpet_unregister_irq_handler(rtc_irq_handler handler);
> >  static inline int hpet_enable(void) { return 0; }
> >  static inline int is_hpet_enabled(void) { return 0; }
> >  #define hpet_readl(a) 0
> > +#define hpet_writel(d, a)
> 
> What for?
> 
> > +#ifdef CONFIG_X86_64
> > +#define hpet_readq(a) 0
> > +#define hpet_writeq(d, a)
> > +#endif
> 
> Ditto.
> 
> There are no users outside of HPET and your new HPET watchdog code for
> those. And both are not compiled when CONFIG_HPET=n.

I'll remove these unneeded defintions.
> 
> The only reason to have the hpet_readl() define, which btw. should be an
> inline, is to avoid massive ifdeffery in the TSC calibration code.

May I ask what is the problem with the #define hpet_readl()? Commit
bfc0f5947afa("x86: merge tsc calibration") changed it from inline to
#define. Should I change it back?

Thanks and BR,
Ricardo

Re: [RFC PATCH v2 11/14] x86/watchdog/hardlockup: Add an HPET-based hardlockup detector

[Ricardo Neri]

On Tue, Mar 26, 2019 at 09:49:13PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Feb 2019, Ricardo Neri wrote:
> > +/**
> > + * get_count() - Get the current count of the HPET timer
> > + *
> > + * Returns:
> > + *
> > + * Value of the main counter of the HPET timer
> 
> The extra newline is not required IIRC.
> 
> Returns: Value ..
> 
> shoud be sufficient and spares a lot of lines all over the place.
> 

Many thanks for your review!

I checked the documentation again and the extra line is not needed. I'll
remove it.

> > + */
> > +static inline unsigned long get_count(void)
> > +{
> > +   return hpet_readq(HPET_COUNTER);
> > +}
> > +
> > +/**
> > + * set_comparator() - Update the comparator in an HPET timer instance
> > + * @hdata: A data structure with the timer instance to update
> > + * @cmp:   The value to write in the in the comparator registere
> > + *
> > + * Returns:
> > + *
> > + * None
> 
> Returns: None is not required and provides no additional value.
> 
> I appreciate that you try to document your functions extensively, but please
> apply common sense whether it really provides value. Documenting the
> obvious is not necessarily an improvement.

Sure, I'll limit function documentation to places where it makes sense.

> 
> > + */
> > +static inline void set_comparator(struct hpet_hld_data *hdata,
> > + unsigned long cmp)
> > +{
> > +   hpet_writeq(cmp, HPET_Tn_CMP(hdata->num));
> > +}
> 
> Also do we really need wrappers plus N lines documentation for
> hpet_readq/writeq()?
> 
> I fail to see the benefit. It's just increasing the line count for no
> reason and requires the reader to lookup functions which are just cosmetic
> wrappers.

I'll remove the wrapper for set_comparator() and get_count() as well as
their documentation. These are the simplest wrappers. Is this
acceptable?

> 
> > +/**
> > + * hardlockup_detector_nmi_handler() - NMI Interrupt handler
> > + * @val:   Attribute associated with the NMI. Not used.
> > + * @regs:  Register values as seen when the NMI was asserted
> > + *
> > + * When in NMI context, check if it was caused by the expiration of the
> 
> When in NMI context? This function _IS_ called in NMI context, right?
> 

Yes, this wording is incorrect. I'll remove the "When in NMI context"
part.

> > + * HPET timer. If yes, create a CPU mask to issue an IPI to the rest
> > + * of monitored CPUs. Upon receiving their own NMI, the other CPUs will
> > + * check such mask to determine if they need to also look for lockups.
> > + *
> > + * Returns:
> > + *
> > + * NMI_DONE if the HPET timer did not cause the interrupt. NMI_HANDLED
> > + * otherwise.
> > + */
> > +static int hardlockup_detector_nmi_handler(unsigned int val,
> > +  struct pt_regs *regs)
> > +{
> > +   struct hpet_hld_data *hdata = hld_data;
> > +   unsigned int cpu = smp_processor_id();
> > +
> > +   if (is_hpet_wdt_interrupt(hdata)) {
> > +   /* Get ready to check other CPUs for hardlockups. */
> > +   cpumask_copy(>cpu_monitored_mask,
> > +watchdog_get_allowed_cpumask());
> > +   cpumask_clear_cpu(smp_processor_id(),
> > + >cpu_monitored_mask);
> 
> Why are you copying the mask in NMI context and not updating it when the
> watchdog enable/disable functions are called?

I think I need two CPU masks for this implementation. A mask is used to
track what CPUs need to be monitored at any given time; I use
watchdog_allowed_mask from kernel/watchdog.c for that.

Separately, I need to prepare a CPU mask to determine which CPUs should be
targeted in the IPI; I use hdata->cpu_monitored_mask for this. This mask will
remain clear most of the time. As soon as CPUs receive their own IPI,
they must clear themselves from this mask. This to prevent them from
incorrectly handling unrelated NMIs; as would be the case if it relied on
watchdog_allowed_mask.

> 
> Also the mask can contain offline CPUs, which is bad because the send IPI
> function expects offline CPUs to be cleared.
> 
> Clearing the CPU in the mask is not required because the function you
> invoke:
> 
> > +   apic->send_IPI_mask_allbutself(>cpu_monitored_mask,
> > +  NMI_VECTOR);
> 
> has it's name for a reason.
> 

I think it still needs to be cleared. While it may not receive an IPI
from this call, an unrelated NMI may happen and it will incorrectly invoke
inspection as it found its bit in the CPU mask set.

> > +
> > +   kick_timer(hdata, !(hdata->flags & HPET_DEV_PERI_CAP));
> > +
> > +   inspect_for_hardlockups(regs);
> > +
> > +   return NMI_HANDLED;
> > +   }
> > +
> > +   if (cpumask_test_and_clear_cpu(cpu, >cpu_monitored_mask)) {
> > +   inspect_for_hardlockups(regs);
> > +   return NMI_HANDLED;
> > +   }
> 
> So if the function above returns false, then why would you try to check
> that CPU mask and invoke the inspection? 

RE: [PATCH V5 4/4] rtc: imx-sc: add rtc alarm support

[Anson Huang]

Hi, Aisheng

Best Regards!
Anson Huang

> -Original Message-
> From: Aisheng Dong
> Sent: 2019年4月8日 19:09
> To: Anson Huang ; robh...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de;
> ker...@pengutronix.de; feste...@gmail.com; a.zu...@towertech.it;
> alexandre.bell...@bootlin.com; ulf.hans...@linaro.org; Daniel Baluta
> ; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> r...@vger.kernel.org
> Cc: dl-linux-imx 
> Subject: RE: [PATCH V5 4/4] rtc: imx-sc: add rtc alarm support
> 
> > From: Anson Huang
> > Sent: Monday, March 18, 2019 11:10 AM
> >
> > Add i.MX system controller RTC alarm support, the RTC alarm is
> > implemented via SIP(silicon provider) runtime service call and
> > ARM-Trusted-Firmware will communicate with system controller via
> > MU(message unit) IPC to set RTC alarm. When RTC alarm fires, system
> > controller will generate a common MU irq event and notify system
> controller RTC driver to handle the irq event.
> >
> > Signed-off-by: Anson Huang 
> > ---
> > No function changes, just update imx_scu_irq_register_notifier()
> > function name according to SCU IRQ function name change.
> > ---
> >  drivers/rtc/rtc-imx-sc.c | 112
> > +++
> >  1 file changed, 112 insertions(+)
> >
> > diff --git a/drivers/rtc/rtc-imx-sc.c b/drivers/rtc/rtc-imx-sc.c index
> > 19642bf..9df4990 100644
> > --- a/drivers/rtc/rtc-imx-sc.c
> > +++ b/drivers/rtc/rtc-imx-sc.c
> > @@ -3,6 +3,7 @@
> >   * Copyright 2018 NXP.
> >   */
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -11,11 +12,17 @@
> >  #include 
> >
> >  #define IMX_SC_TIMER_FUNC_GET_RTC_SEC1970  9
> > +#define IMX_SC_TIMER_FUNC_SET_RTC_ALARM8
> >  #define IMX_SC_TIMER_FUNC_SET_RTC_TIME 6
> >
> > +#define IMX_SC_IRQ_FUNC_ENABLE 1
> > +
> >  #define IMX_SIP_SRTC   0xC202
> >  #define IMX_SIP_SRTC_SET_TIME  0x0
> >
> > +#define SC_IRQ_GROUP_RTC2
> > +#define SC_IRQ_RTC  1
> > +
> >  static struct imx_sc_ipc *rtc_ipc_handle;  static struct rtc_device
> > *imx_sc_rtc;
> >
> > @@ -24,6 +31,24 @@ struct imx_sc_msg_timer_get_rtc_time {
> > u32 time;
> >  } __packed;
> >
> > +struct imx_sc_msg_timer_enable_irq {
> > +   struct imx_sc_rpc_msg hdr;
> > +   u32 mask;
> > +   u16 resource;
> > +   u8 group;
> > +   u8 enable;
> > +} __packed;
> > +
> > +struct imx_sc_msg_timer_rtc_set_alarm {
> > +   struct imx_sc_rpc_msg hdr;
> > +   u16 year;
> > +   u8 mon;
> > +   u8 day;
> > +   u8 hour;
> > +   u8 min;
> > +   u8 sec;
> > +} __packed;
> > +
> >  static int imx_sc_rtc_read_time(struct device *dev, struct rtc_time *tm)  {
> > struct imx_sc_msg_timer_get_rtc_time msg; @@ -60,9 +85,92 @@
> static
> > int imx_sc_rtc_set_time(struct device *dev, struct rtc_time *tm)
> > return res.a0;
> >  }
> >
> > +static int imx_sc_rtc_alarm_irq_enable(struct device *dev, unsigned
> > +int
> > +enable) {
> 
> I think you shouldn't implement this generic function in rtc driver instead of
> Imx-scu-irq driver.

RTC driver has capability to enable/disable IRQ, so we have to implement this
callback, and considering the MU resource ID has to be parsed from DT, it does
NOT make sense to do it for all driver, so I will add another API in 
imx-scu-irq driver
to provide function of enabling/disabling irq, each driver can just call the 
API to
enable/disable its own IRQ, ONLY need to pass the corresponding arguments:

+void imx_scu_irq_enable(u8 group, u32 mask, u8 enable)
+{
+   struct imx_sc_msg_irq_enable msg;
+   struct imx_sc_rpc_msg *hdr = 
+   int ret;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_IRQ;
+   hdr->func = IMX_SC_IRQ_FUNC_ENABLE;
+   hdr->size = 3;
+
+   msg.resource = mu_resource_id;
+   msg.group = group;
+   msg.mask = mask;
+   msg.enable = enable;
+
+   ret = imx_scu_call_rpc(rtc_ipc_handle, , true);
+   if (ret)
+   dev_err(dev, "enable irq failed, group %d, mask %d, ret %d\n",
+   group, mask, ret);
+}

> 
> > +   struct imx_sc_msg_timer_enable_irq msg;
> > +   struct imx_sc_rpc_msg *hdr = 
> > +   int ret;
> > +
> > +   hdr->ver = IMX_SC_RPC_VERSION;
> > +   hdr->svc = IMX_SC_RPC_SVC_IRQ;
> > +   hdr->func = IMX_SC_IRQ_FUNC_ENABLE;
> > +   hdr->size = 3;
> > +
> > +   msg.resource = IMX_SC_R_MU_1A;
> 
> Here may be wrong as it is not align with what you did in Patch 2 that MU
> resource is dynamically detected.

Fixed by upper comment using new API inside imx-scu-irq driver.

> 
> > +   msg.group = SC_IRQ_GROUP_RTC;
> > +   msg.mask = SC_IRQ_RTC;
> > +   msg.enable = enable;
> > +
> > +   ret = imx_scu_call_rpc(rtc_ipc_handle, , true);
> > +   if (ret) {
> > +   dev_err(dev, "enable rtc irq failed, ret %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   return 0;
> > +}
> > 

linux-next: build warning after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

sound/soc/intel/boards/bytcht_es8316.c: In function 
'snd_byt_cht_es8316_mc_probe':
sound/soc/intel/boards/bytcht_es8316.c:508:11: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
   quirk = (int)dmi_id->driver_data;
   ^

Introduced by commit

  a8d218f4fe81 ("ASoC: Intel: bytcht_es8316: Add quirk for the Teclast X98+ II")

-- 
Cheers,
Stephen Rothwell


pgpI8IpkgCN0z.pgp
Description: OpenPGP digital signature

Re: [PATCH][next] scsi: qla2xxx: fix spelling mistake "alredy" -> "already"

[Martin K. Petersen]

Colin,

> There is a spelling mistake in a ql_log message. Fix it.

Applied to 5.2/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: Adding plain accesses and detecting data races in the LKMM

[Andrea Parri]

> > The formula was more along the line of "do not assume either of these
> > cases to hold; use barrier() is you need an unconditional barrier..."
> > AFAICT, all current implementations of smp_mb__{before,after}_atomic()
> > provides a compiler barrier with either barrier() or "memory" clobber.
> 
> Well, we have two reasonable choices: Say that 
> smp_mb__{before,after}_atomic will always provide a compiler barrier, 
> or don't say this.  I see no point in saying that the combination of 
> Before-atomic followed by RMW provides a barrier.

;-/ I'm fine with the first choice. I don't see how the second choice
(this proposal/patch) would be consistent with some documentation and
with the current implementations; for example,

1) Documentation/atomic_t.txt says:

Thus:

  atomic_fetch_add();

is equivalent to:

  smp_mb__before_atomic();
  atomic_fetch_add_relaxed();
  smp_mb__after_atomic();

[...]

2) Some implementations of the _relaxed() variants do not provide any
compiler barrier currently.

  Andrea

Re: [PATCH -next] pinctrl: artpec6: Make two functions static

[YueHaibing]

On 2019/4/9 2:01, Nathan Chancellor wrote:
> On Thu, Mar 21, 2019 at 11:09:09PM +0800, Yue Haibing wrote:
>> From: YueHaibing 
>>
>> Fix sparse warnings:
>>
>> drivers/pinctrl/pinctrl-artpec6.c:691:5: warning:
>>  symbol 'artpec6_pmx_enable' was not declared. Should it be static?
>> drivers/pinctrl/pinctrl-artpec6.c:705:6: warning:
>>  symbol 'artpec6_pmx_disable' was not declared. Should it be static?
>>
>> Signed-off-by: YueHaibing 
>> ---
>>  drivers/pinctrl/pinctrl-artpec6.c | 10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pinctrl/pinctrl-artpec6.c 
>> b/drivers/pinctrl/pinctrl-artpec6.c
>> index d89dc43..e836850 100644
>> --- a/drivers/pinctrl/pinctrl-artpec6.c
>> +++ b/drivers/pinctrl/pinctrl-artpec6.c
>> @@ -688,8 +688,9 @@ static void artpec6_pmx_select_func(struct pinctrl_dev 
>> *pctldev,
>>  }
>>  }
>>  
>> -int artpec6_pmx_enable(struct pinctrl_dev *pctldev, unsigned int function,
>> -   unsigned int group)
>> +static int artpec6_pmx_enable(struct pinctrl_dev *pctldev,
>> +  unsigned int function,
>> +  unsigned int group)
>>  {
>>  struct artpec6_pmx *pmx = pinctrl_dev_get_drvdata(pctldev);
>>  
>> @@ -702,8 +703,9 @@ int artpec6_pmx_enable(struct pinctrl_dev *pctldev, 
>> unsigned int function,
>>  return 0;
>>  }
>>  
>> -void artpec6_pmx_disable(struct pinctrl_dev *pctldev, unsigned int function,
>> - unsigned int group)
>> +static void artpec6_pmx_disable(struct pinctrl_dev *pctldev,
>> +unsigned int function,
>> +unsigned int group)
> 
> On arm32 allyesconfig:
> 
> drivers/pinctrl/pinctrl-artpec6.c:706:13: error: unused function
> 'artpec6_pmx_disable' [-Werror,-Wunused-function]
> 
> This is the second time you've introduced an unused function warning by
> making a function static[1], could you please be a little more vigilant
> in your clean ups in the future?

Sorry for this.

> 
> [1]: 
> https://lore.kernel.org/lkml/20190327050126.12064-1-natechancel...@gmail.com/
> 
> Linus/Jesper/Lars, should this function just be deleted? I'd be happy to
> send a patch doing so if that's the right course of action.
> 
> Thanks,
> Nathan
> 
>>  {
>>  struct artpec6_pmx *pmx = pinctrl_dev_get_drvdata(pctldev);
>>  
>> -- 
>> 2.7.0
>>
>>
> 
> .
> 

Re: [PATCH 1/2] dt-bindings: rtc: add battery-low-hw-alarm property

[Rob Herring]

On Mon, Apr 8, 2019 at 2:22 AM Flavio Suligoi  wrote:
>
> HI,
>
> > On 06/04/2019 01:07:13-0500, Rob Herring wrote:
> > > On Wed, Apr 03, 2019 at 04:52:44PM +0200, Flavio Suligoi wrote:
> > > > Some RTC devices have a battery-low automatic detection circuit.
> > > > The battery-low event is usually reported with:
> > > >
> > > > - a bit change in a RTC status register
> > > > - a hw signaling (generally using an interrupt generation), changing
> > > >   the hw level of a specific pin;
> > > >
> > > > The new property "battery-low-hw-alarm" enable the RTC to generate the
> > > > hw signaling in case of battery-low event.
> > > >
> > > > Signed-off-by: Flavio Suligoi 
> > > > ---
> > > >  Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt
> > b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > index a97fc6a..f93a44d 100644
> > > > --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > @@ -31,6 +31,9 @@ below.
> > > >  expressed in femto Farad (fF).
> > > >  The default value shall be listed (if
> > optional),
> > > >  and likewise all valid values.
> > > > +- battery-low-hw-alarm :Enable the "battery-low" output pin. This
> > function
> > > > +is available on the following devices:
> > > > +- pcf2127 - pin used for alarm: INTn
> > >
> > > Boolean? If there's cases where which pin is selectable, then we'd need
> > > this to take a value. Not sure how likely that is?
> > >
> >
> > Indeed, there is at least the pcf85363 that has two possible pins for
> > that interrupt. How would you select the pin then? a zero based index? a
> > string?

I prefer an index.

> I think the string could be clearer for the final user and would give
> more freedom for future changes.
> For example, we can call this property, instead of "battery-low-alarm" or
> "low-voltage-alarm", simply: "alarm-pin_1" and then the string argument
> can describe the function used; for example:
>
> alarm-pin_1 = "backup-supply-low-voltage-alarm";
> alarm-pin_2 = "..";

How many pins and functions then? And how does this relate to any interrupts?

Rob

Re: [PATCH v8 02/11] dt-bindings: power: supply: add DT bindings for max77650

[Rob Herring]

On Mon, Apr 8, 2019 at 7:25 AM Bartosz Golaszewski  wrote:
>
> sob., 6 kwi 2019 o 09:07 Rob Herring  napisał(a):
> >
> > On Wed, Apr 03, 2019 at 11:00:59AM +0200, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski 
> > >
> > > Add the DT binding document for the battery charger module of max77650.
> > >
> > > Signed-off-by: Bartosz Golaszewski 
> > > ---
> > >  .../power/supply/max77650-charger.txt | 27 +++
> > >  1 file changed, 27 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/power/supply/max77650-charger.txt
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/power/supply/max77650-charger.txt 
> > > b/Documentation/devicetree/bindings/power/supply/max77650-charger.txt
> > > new file mode 100644
> > > index ..fef188144386
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/power/supply/max77650-charger.txt
> > > @@ -0,0 +1,27 @@
> > > +Battery charger driver for MAX77650 PMIC from Maxim Integrated.
> > > +
> > > +This module is part of the MAX77650 MFD device. For more details
> > > +see Documentation/devicetree/bindings/mfd/max77650.txt.
> > > +
> > > +The charger is represented as a sub-node of the PMIC node on the device 
> > > tree.
> > > +
> > > +Required properties:
> > > +
> > > +- compatible:Must be "maxim,max77650-charger"
> > > +
> > > +Optional properties:
> > > +
> > > +- min-microvolt: Minimum CHGIN regulation voltage (in microvolts). 
> > > Must be
> > > + one of: 400, 410, 420, 430, 440,
> > > + 450, 460, 470.
> > > +- current-limit-microamp:CHGIN input current limit (in microamps). 
> > > Must
> > > + be one of: 95000, 19, 285000, 38, 
> > > 475000.
> >
> > To repeat what I said on v6, these should be common properties IMO (and
> > therefore documented as such).
> >
>
> Do you mean a separate "charger.txt" document in
> Documentation/devicetree/bindings/power/supply/?

Yes, though I thought we had something already.

Rob

Re: [PATCH 1/2] mm/gup.c: fix the wrong comments

[Huang Shijie]

On Mon, Apr 08, 2019 at 07:13:13AM -0700, Matthew Wilcox wrote:
> On Mon, Apr 08, 2019 at 10:37:45AM +0800, Huang Shijie wrote:
> > When CONFIG_HAVE_GENERIC_GUP is defined, the kernel will use its own
> > get_user_pages_fast().
> > 
> > In the following scenario, we will may meet the bug in the DMA case:
> > .
> > get_user_pages_fast(start,,, pages);
> > ..
> > sg_alloc_table_from_pages(, pages, ...);
> > .
> > 
> > The root cause is that sg_alloc_table_from_pages() requires the
> > page order to keep the same as it used in the user space, but
> > get_user_pages_fast() will mess it up.
> 
> I don't understand how get_user_pages_fast() can return the pages in a
> different order in the array from the order they appear in userspace.
> Can you explain?
Please see the code in gup.c:

int get_user_pages_fast(unsigned long start, int nr_pages,
unsigned int gup_flags, struct page **pages)
{
...
if (gup_fast_permitted(start, nr_pages)) {
local_irq_disable();
gup_pgd_range(addr, end, gup_flags, pages, );
   // The @pages array maybe filled at the first time.
local_irq_enable();
ret = nr;
}
...
if (nr < nr_pages) {
/* Try to get the remaining pages with get_user_pages */
start += nr << PAGE_SHIFT;
pages += nr;
  // The @pages is moved forward.

if (gup_flags & FOLL_LONGTERM) {
down_read(>mm->mmap_sem);
ret = __gup_longterm_locked(current, 
current->mm,  // The @pages maybe filled at the second time
start, nr_pages - 
nr,
pages, NULL, 
gup_flags);
up_read(>mm->mmap_sem);
} else {
/*
 * retain FAULT_FOLL_ALLOW_RETRY optimization if
 * possible
 */
ret = get_user_pages_unlocked(start, nr_pages - 
nr,// The @pages maybe filled at the second time.
  pages, gup_flags);
}
}


.

BTW, I do not know why we mess up the page order. It maybe used in some special 
case.

Thanks
Huang Shijie

Re: [PATCH 03/22] watchdog: aspeed_wdt: Use 'dev' instead of dereferencing it repeatedly

[Andrew Jeffery]

On Tue, 9 Apr 2019, at 10:33, Guenter Roeck wrote:
> Hi Andrew,
> 
> On 4/8/19 5:37 PM, Andrew Jeffery wrote:
> > 
> > 
> > On Tue, 9 Apr 2019, at 05:09, Guenter Roeck wrote:
> >> Introduce local variable 'struct device *dev' and use it instead of
> >> dereferencing it repeatedly.
> >>
> >> The conversion was done automatically with coccinelle using the
> >> following semantic patches. The semantic patches and the scripts
> >> used to generate this commit log are available at
> >> https://github.com/groeck/coccinelle-patches
> >>
> >> Cc: Joel Stanley 
> >> Cc: Andrew Jeffery 
> >> Signed-off-by: Guenter Roeck 
> >> ---
> >>   drivers/watchdog/aspeed_wdt.c | 21 +++--
> >>   1 file changed, 11 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> >> index f09333fd54b4..34117745c65f 100644
> >> --- a/drivers/watchdog/aspeed_wdt.c
> >> +++ b/drivers/watchdog/aspeed_wdt.c
> >> @@ -187,6 +187,7 @@ static const struct watchdog_info aspeed_wdt_info = {
> >>   
> >>   static int aspeed_wdt_probe(struct platform_device *pdev)
> >>   {
> >> +  struct device *dev = >dev;
> >>const struct aspeed_wdt_config *config;
> >>const struct of_device_id *ofdid;
> >>struct aspeed_wdt *wdt;
> >> @@ -196,7 +197,7 @@ static int aspeed_wdt_probe(struct platform_device 
> >> *pdev)
> >>u32 status;
> >>int ret;
> >>   
> >> -  wdt = devm_kzalloc(>dev, sizeof(*wdt), GFP_KERNEL);
> >> +  wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL);
> >>if (!wdt)
> >>return -ENOMEM;
> > 
> > Looks like it's missed this one somehow?
> > 
> > wdt->base = devm_ioremap_resource(>dev, res);
> > 
> > Otherwise,
> > 
> > Reviewed-by: Andrew Jeffery 
> > 
> 
> Assuming you mean the conversion to use devm_platform_ioremap_resource(),
> I had this already addressed with a single patch for all watchdog drivers.
> 
> https://patchwork.kernel.org/patch/10882207/
> 
> Sorry, I didn't Cc: you on that one - I limited the number of Cc:s to 
> avoid being
> tagged as spammer.

That's the piece I was missing.

Thanks!

Andrew

Re: [PATCH 03/22] watchdog: aspeed_wdt: Use 'dev' instead of dereferencing it repeatedly

[Guenter Roeck]

Hi Andrew,

On 4/8/19 5:37 PM, Andrew Jeffery wrote:



On Tue, 9 Apr 2019, at 05:09, Guenter Roeck wrote:

Introduce local variable 'struct device *dev' and use it instead of
dereferencing it repeatedly.

The conversion was done automatically with coccinelle using the
following semantic patches. The semantic patches and the scripts
used to generate this commit log are available at
https://github.com/groeck/coccinelle-patches

Cc: Joel Stanley 
Cc: Andrew Jeffery 
Signed-off-by: Guenter Roeck 
---
  drivers/watchdog/aspeed_wdt.c | 21 +++--
  1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
index f09333fd54b4..34117745c65f 100644
--- a/drivers/watchdog/aspeed_wdt.c
+++ b/drivers/watchdog/aspeed_wdt.c
@@ -187,6 +187,7 @@ static const struct watchdog_info aspeed_wdt_info = {
  
  static int aspeed_wdt_probe(struct platform_device *pdev)

  {
+   struct device *dev = >dev;
const struct aspeed_wdt_config *config;
const struct of_device_id *ofdid;
struct aspeed_wdt *wdt;
@@ -196,7 +197,7 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
u32 status;
int ret;
  
-	wdt = devm_kzalloc(>dev, sizeof(*wdt), GFP_KERNEL);

+   wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL);
if (!wdt)
return -ENOMEM;


Looks like it's missed this one somehow?

wdt->base = devm_ioremap_resource(>dev, res);

Otherwise,

Reviewed-by: Andrew Jeffery 



Assuming you mean the conversion to use devm_platform_ioremap_resource(),
I had this already addressed with a single patch for all watchdog drivers.

https://patchwork.kernel.org/patch/10882207/

Sorry, I didn't Cc: you on that one - I limited the number of Cc:s to avoid 
being
tagged as spammer.

Guenter

Re: linux-next: manual merge of the kspp-gustavo tree with Linus' tree

[Stephen Rothwell]

Hi Gustavo,

On Mon, 8 Apr 2019 18:53:16 -0500 "Gustavo A. R. Silva" 
 wrote:
>
> I just removed the above commit from my tree.

OK, thanks.

-- 
Cheers,
Stephen Rothwell


pgpFH68Tq494p.pgp
Description: OpenPGP digital signature

Re: [PATCH v10 1/2] dt-bindings: misc: aspeed-p2a-ctrl: add support

[Andrew Jeffery]

On Tue, 9 Apr 2019, at 00:12, Patrick Venture wrote:
> Document the ast2400, ast2500 PCI-to-AHB bridge control driver bindings.
> 
> Signed-off-by: Patrick Venture 
> Reviewed-by: Rob Herring 

Reviewed-by: Andrew Jeffery 

> ---
> Changes for v10:
>  - Chopped out nearly identical information.
> Changes for v9:
>  - Added missing details about syscon parent
> Changes for v8:
> - None
> Changes for v7:
> - Moved node under the syscon node it requires
> Changes for v6:
> - None
> Changes for v5:
> - None
> Changes for v4:
> - None
> Changes for v3:
> - None
> Changes for v2:
> - Added comment about syscon required parameter.
> ---
>  .../bindings/misc/aspeed-p2a-ctrl.txt | 47 +++
>  1 file changed, 47 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt 
> b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> new file mode 100644
> index 0..854bd67ffec68
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> @@ -0,0 +1,47 @@
> +==
> +Device tree bindings for Aspeed AST2400/AST2500 PCI-to-AHB Bridge 
> Control Driver
> +==
> +
> +The bridge is available on platforms with the VGA enabled on the 
> Aspeed device.
> +In this case, the host has access to a 64KiB window into all of the 
> BMC's
> +memory.  The BMC can disable this bridge.  If the bridge is enabled, 
> the host
> +has read access to all the regions of memory, however the host only 
> has read
> +and write access depending on a register controlled by the BMC.
> +
> +Required properties:
> +===
> +
> + - compatible: must be one of:
> + - "aspeed,ast2400-p2a-ctrl"
> + - "aspeed,ast2500-p2a-ctrl"
> +
> +Optional properties:
> +===
> +
> +- memory-region: A phandle to a reserved_memory region to be used for 
> the PCI
> + to AHB mapping
> +
> +The p2a-control node should be the child of a syscon node with the 
> required
> +property:
> +
> +- compatible : Should be one of the following:
> + "aspeed,ast2400-scu", "syscon", "simple-mfd"
> + "aspeed,g4-scu", "syscon", "simple-mfd"
> + "aspeed,ast2500-scu", "syscon", "simple-mfd"
> + "aspeed,g5-scu", "syscon", "simple-mfd"
> +
> +Example
> +===
> +
> +g4 Example
> +--
> +
> +syscon: scu@1e6e2000 {
> + compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
> + reg = <0x1e6e2000 0x1a8>;
> +
> + p2a: p2a-control {
> + compatible = "aspeed,ast2400-p2a-ctrl";
> + memory-region = <_memory>;
> + };
> +};
> -- 
> 2.21.0.392.gf8f6787159e-goog
> 
>

Re: [PATCH 03/22] watchdog: aspeed_wdt: Use 'dev' instead of dereferencing it repeatedly

[Andrew Jeffery]

On Tue, 9 Apr 2019, at 05:09, Guenter Roeck wrote:
> Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatedly.
> 
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
> 
> Cc: Joel Stanley 
> Cc: Andrew Jeffery 
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/watchdog/aspeed_wdt.c | 21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> index f09333fd54b4..34117745c65f 100644
> --- a/drivers/watchdog/aspeed_wdt.c
> +++ b/drivers/watchdog/aspeed_wdt.c
> @@ -187,6 +187,7 @@ static const struct watchdog_info aspeed_wdt_info = {
>  
>  static int aspeed_wdt_probe(struct platform_device *pdev)
>  {
> + struct device *dev = >dev;
>   const struct aspeed_wdt_config *config;
>   const struct of_device_id *ofdid;
>   struct aspeed_wdt *wdt;
> @@ -196,7 +197,7 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
>   u32 status;
>   int ret;
>  
> - wdt = devm_kzalloc(>dev, sizeof(*wdt), GFP_KERNEL);
> + wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL);
>   if (!wdt)
>   return -ENOMEM;

Looks like it's missed this one somehow?

wdt->base = devm_ioremap_resource(>dev, res); 

Otherwise,

Reviewed-by: Andrew Jeffery 

>  
> @@ -212,12 +213,12 @@ static int aspeed_wdt_probe(struct platform_device 
> *pdev)
>   wdt->wdd.info = _wdt_info;
>   wdt->wdd.ops = _wdt_ops;
>   wdt->wdd.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT_MS;
> - wdt->wdd.parent = >dev;
> + wdt->wdd.parent = dev;
>  
>   wdt->wdd.timeout = WDT_DEFAULT_TIMEOUT;
> - watchdog_init_timeout(>wdd, 0, >dev);
> + watchdog_init_timeout(>wdd, 0, dev);
>  
> - np = pdev->dev.of_node;
> + np = dev->of_node;
>  
>   ofdid = of_match_node(aspeed_wdt_of_table, np);
>   if (!ofdid)
> @@ -286,11 +287,11 @@ static int aspeed_wdt_probe(struct platform_device 
> *pdev)
>   u32 max_duration = config->ext_pulse_width_mask + 1;
>  
>   if (duration == 0 || duration > max_duration) {
> - dev_err(>dev, "Invalid pulse duration: %uus\n",
> - duration);
> + dev_err(dev, "Invalid pulse duration: %uus\n",
> + duration);
>   duration = max(1U, min(max_duration, duration));
> - dev_info(>dev, "Pulse duration set to %uus\n",
> - duration);
> + dev_info(dev, "Pulse duration set to %uus\n",
> +  duration);
>   }
>  
>   /*
> @@ -312,9 +313,9 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
>   if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY)
>   wdt->wdd.bootstatus = WDIOF_CARDRESET;
>  
> - ret = devm_watchdog_register_device(>dev, >wdd);
> + ret = devm_watchdog_register_device(dev, >wdd);
>   if (ret) {
> - dev_err(>dev, "failed to register\n");
> + dev_err(dev, "failed to register\n");
>   return ret;
>   }
>  
> -- 
> 2.7.4
> 
>

[PATCH v6] platform/chrome: Add Wilco EC keyboard backlight LEDs support

[Nick Crews]

The EC is in charge of controlling the keyboard backlight on
the Wilco platform. We expose a standard LED class device at
/sys/class/leds/chromeos::kbd_backlight. This driver is modeled
after the standard Chrome OS keyboard backlight driver at
drivers/platform/chrome/cros_kbd_led_backlight.c

Some Wilco devices do not support a keyboard backlight. This
is checked via wilco_ec_keyboard_leds_exist() in the core driver,
and a platform_device will only be registered by the core if
a backlight is supported.

After an EC reset the backlight could be in a non-PWM mode.
Earlier in the boot sequence the BIOS should send a command to
the EC to set the brightness, so things **should** be set up,
but we double check in probe() as we query the initial brightness.
If not set up, then set the brightness to 0.

Since the EC will never change the backlight level of its own accord,
we don't need to implement a brightness_get() method.

v6 changes:
-Remove bogus extra de-referencing in send_kbbl_msg()
-Actually return error if mailbox() fails in send_kbbl_msg()
-Use SET_STATE, not GET_STATE sub-command in set_brightness()

v4 changes:
-Call keyboard_led_set_brightness() directly within
 initialize_brightness(), instead of calling the library function.

v3 changes:
-Since this behaves the same as the standard Chrome OS keyboard
 backlight, rename the led device to "chromeos::kbd_backlight"
-Move wilco_ec_keyboard_backlight_exists() into core module, so
 that the core does not depend upon the keyboard backlight driver.
-This required moving some code into wilco-ec.h
-Refactor out some common code in set_brightness() and
 initialize_brightness()

v2 changes:
-Remove and fix uses of led vs LED in kconfig
-Assume BIOS initializes brightness, but double check in probe()
-Remove get_brightness() callback, as EC never changes brightness
 by itself.
-Use a __packed struct as message instead of opaque array
-Add exported wilco_ec_keyboard_leds_exist() so the core driver
 now only creates a platform _device if relevant
-Fix use of keyboard_led_set_brightness() since it can sleep

Signed-off-by: Nick Crews 
---
 drivers/platform/chrome/wilco_ec/Kconfig  |   9 +
 drivers/platform/chrome/wilco_ec/Makefile |   2 +
 drivers/platform/chrome/wilco_ec/core.c   |  58 ++
 .../chrome/wilco_ec/kbd_led_backlight.c   | 166 ++
 include/linux/platform_data/wilco-ec.h|  38 
 5 files changed, 273 insertions(+)
 create mode 100644 drivers/platform/chrome/wilco_ec/kbd_led_backlight.c

diff --git a/drivers/platform/chrome/wilco_ec/Kconfig 
b/drivers/platform/chrome/wilco_ec/Kconfig
index e09e4cebe9b4..d8cf4a60d1b5 100644
--- a/drivers/platform/chrome/wilco_ec/Kconfig
+++ b/drivers/platform/chrome/wilco_ec/Kconfig
@@ -18,3 +18,12 @@ config WILCO_EC_DEBUGFS
  manipulation and allow for testing arbitrary commands.  This
  interface is intended for debug only and will not be present
  on production devices.
+
+config WILCO_EC_KBD_BACKLIGHT
+   tristate "Enable keyboard backlight control"
+   depends on WILCO_EC
+   help
+ If you say Y here, you get support to set the keyboard backlight
+ brightness. This happens via a standard LED driver that uses the
+ Wilco EC mailbox interface. A standard LED class device will
+ appear under /sys/class/leds/chromeos::kbd_backlight
diff --git a/drivers/platform/chrome/wilco_ec/Makefile 
b/drivers/platform/chrome/wilco_ec/Makefile
index 063e7fb4ea17..8436539813cd 100644
--- a/drivers/platform/chrome/wilco_ec/Makefile
+++ b/drivers/platform/chrome/wilco_ec/Makefile
@@ -4,3 +4,5 @@ wilco_ec-objs   := core.o mailbox.o
 obj-$(CONFIG_WILCO_EC) += wilco_ec.o
 wilco_ec_debugfs-objs  := debugfs.o
 obj-$(CONFIG_WILCO_EC_DEBUGFS) += wilco_ec_debugfs.o
+wilco_kbd_backlight-objs   := kbd_led_backlight.o
+obj-$(CONFIG_WILCO_EC_KBD_BACKLIGHT)   += wilco_kbd_backlight.o
diff --git a/drivers/platform/chrome/wilco_ec/core.c 
b/drivers/platform/chrome/wilco_ec/core.c
index 05e1e2be1c91..3c45c157b7da 100644
--- a/drivers/platform/chrome/wilco_ec/core.c
+++ b/drivers/platform/chrome/wilco_ec/core.c
@@ -38,11 +38,47 @@ static struct resource *wilco_get_resource(struct 
platform_device *pdev,
   dev_name(dev));
 }
 
+/**
+ * wilco_ec_keyboard_backlight_exists() - Is the keyboad backlight supported?
+ * @ec: EC device to query.
+ * @exists: Return value to fill in.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+static int wilco_ec_keyboard_backlight_exists(struct wilco_ec_device *ec,
+ bool *exists)
+{
+   struct wilco_ec_kbbl_msg request;
+   struct wilco_ec_kbbl_msg response;
+   struct wilco_ec_message msg;
+   int ret;
+
+   memset(, 0, sizeof(request));
+   request.command = WILCO_EC_COMMAND_KBBL;
+   request.subcmd = 

Re: [PATCH] adfs: mark expected switch fall-throughs

[Kees Cook]

On Mon, Jan 14, 2019 at 12:35 PM Gustavo A. R. Silva
 wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
>
> Signed-off-by: Gustavo A. R. Silva 

Please consider this reviewed! :)

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH] afs: Mark expected switch fall-throughs

[Kees Cook]

On Thu, Jan 10, 2019 at 2:02 PM Gustavo A. R. Silva
 wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that in many cases I placed a /* Fall through */ comment
> at the bottom of the case, which what GCC is expecting to find.
>
> In other cases I had to tweak a bit the format of the comments.
>
> This patch suppresses ALL missing-break-in-switch false positives
> in fs/afs
>
> Addresses-Coverity-ID: 115042 ("Missing break in switch")
> Addresses-Coverity-ID: 115043 ("Missing break in switch")
> Addresses-Coverity-ID: 115045 ("Missing break in switch")
> Addresses-Coverity-ID: 1357430 ("Missing break in switch")
> Addresses-Coverity-ID: 115047 ("Missing break in switch")
> Addresses-Coverity-ID: 115050 ("Missing break in switch")
> Addresses-Coverity-ID: 115051 ("Missing break in switch")
> Addresses-Coverity-ID: 1467806 ("Missing break in switch")
> Addresses-Coverity-ID: 1467807 ("Missing break in switch")
> Addresses-Coverity-ID: 1467811 ("Missing break in switch")
> Addresses-Coverity-ID: 115041 ("Missing break in switch")
> Signed-off-by: Gustavo A. R. Silva 

These look good to me. Gets us another step to finishing this. :)

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH] ARM: dts: imx6qdl-nitrogen6_max: Disable LVDS channels

[Robert Foss]

Hey Fabio,

On 4/8/19 10:37 PM, Fabio Estevam wrote:

Hi Robert,

[Adding Gary]

On Mon, Apr 8, 2019 at 2:54 PM Robert Foss  wrote:


If a LVDS device is not connected, having the LVDS channels
enabled will prevent imx-ldb from probing correctly even
if other CRTCs are connected.

Signed-off-by: Robert Foss 
---
  arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi 
b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
index 39200e5dc896..5b413cf4c250 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
@@ -703,7 +703,7 @@
 status = "okay";

 lvds-channel@0 {
-   status = "okay";
+   status = "disabled";

 port@4 {
 reg = <4>;
@@ -715,7 +715,7 @@
 };

 lvds-channel@1 {
-   status = "okay";
+   status = "disabled";


I am not sure I understood what you are trying to fix.


If CONFIG_DRM_IMX_LDB is enabled, LVDS DT channels are enabled
and no LVDS-panels are connected the imx-ldb driver will
fail to bind.

This is a problem, since it will prevent other actually connected
display output from being used, even if they bind properly.



Could you please share some logs when imx-ldb fails to probe correctly?



[2.119563] component_bind_all() trying to bind: ldb
[2.124600] imx-drm display-subsystem: binding ldb (ops imx_ldb_ops)
[2.146169] drm_of_find_panel_or_bridge() np->name=lvds-channel  
np->type=
[2.153709] drm_of_find_panel_or_bridge() no panel found for remote
[2.160081] drm_of_find_panel_or_bridge() bridge needed
[2.162043] drm_of_find_panel_or_bridge() bridge not found
[2.165331] drm_of_find_panel_or_bridge() failed
[2.170023] imx-drm display-subsystem: failed to bind ldb (ops imx_ldb_ops): 
-517

This at the same time as HDMI binds properly:

[4.458954] dwhdmi-imx 12.hdmi: Detected HDMI TX controller v1.30a with 
HDCP (DWC HDMI 3D TX PHY)

[4.469633] imx-drm display-subsystem: bound 12.hdmi (ops 
dw_hdmi_imx_ops)

Which in the end causes the IMX driver to not initialize properly
and ignore the HDMI connection that bound properly.
This in turn prevents us from having any graphical output while there
is no LVDS panel connected.




Is this a regression?



Not as far as I know.

How a Nitrogen6-Max board without a LVDS panel, but using the
imx_v6_v7_defconfig ever started and had displayed graphical
output on other connected displays I don't know though.


Rob.

Re: [PATCH v5 3/3] platform/chrome: Standardize Chrome OS keyboard backlight name

[Nick Crews]

I've just found a few [embarrassing :)] bugs in this version,
so after we figure out the naming, please wait for me to send
out another patch that fixes these.

Thanks, Nick

On Thu, Apr 4, 2019 at 11:10 AM Nick Crews  wrote:
>
> We want all backlights for the system keyboard to
> use a common name, so the name "platform::kbd_backlight"
> would be better than the current "chromeos::kbd_backlight"
> name. Normally this wouldn't be worth changing, but the new
> Wilco keyboard backlight driver uses the "platform" name.
> We want to make it so all Chrome OS devices are consistent,
> so we'll change the name here too.
>
> The Power Manager daemon only looks for LEDs that match the
> pattern "*:kbd_backlight", so this change won't affect that.
>
> Signed-off-by: Nick Crews 
> ---
>  drivers/platform/chrome/cros_kbd_led_backlight.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/chrome/cros_kbd_led_backlight.c 
> b/drivers/platform/chrome/cros_kbd_led_backlight.c
> index aa409f0201fb..c56c8405f39c 100644
> --- a/drivers/platform/chrome/cros_kbd_led_backlight.c
> +++ b/drivers/platform/chrome/cros_kbd_led_backlight.c
> @@ -77,7 +77,7 @@ static int keyboard_led_probe(struct platform_device *pdev)
> if (!cdev)
> return -ENOMEM;
>
> -   cdev->name = "chromeos::kbd_backlight";
> +   cdev->name = "platform::kbd_backlight";
> cdev->max_brightness = ACPI_KEYBOARD_BACKLIGHT_MAX;
> cdev->flags |= LED_CORE_SUSPENDRESUME;
> cdev->brightness_set = keyboard_led_set_brightness;
> --
> 2.20.1
>

[PATCH 14/18] iommu/vt-d: Add nested translation support

[Jacob Pan]

Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
With PASID granular translation type set to 0x11b, translation
result from the first level(FL) also subject to a second level(SL)
page table translation. This mode is used for SVA virtualization,
where FL performs guest virtual to guest physical translation and
SL performs guest physical to host physical translation.

Signed-off-by: Jacob Pan 
Signed-off-by: Liu, Yi L 
---
 drivers/iommu/intel-pasid.c | 101 
 drivers/iommu/intel-pasid.h |  11 +
 2 files changed, 112 insertions(+)

diff --git a/drivers/iommu/intel-pasid.c b/drivers/iommu/intel-pasid.c
index 0fda626..123e035 100644
--- a/drivers/iommu/intel-pasid.c
+++ b/drivers/iommu/intel-pasid.c
@@ -690,3 +690,104 @@ int intel_pasid_setup_pass_through(struct intel_iommu 
*iommu,
 
return 0;
 }
+
+/**
+ * intel_pasid_setup_nested() - Set up PASID entry for nested translation
+ * which is used for vSVA. The first level page tables are used for
+ * GVA-GPA translation in the guest, second level page tables are used
+ * for GPA to HPA translation.
+ *
+ * @iommu:  Iommu which the device belong to
+ * @dev:Device to be set up for translation
+ * @pgd:First level PGD, treated as GPA
+ * @pasid:  PASID to be programmed in the device PASID table
+ * @flags:  Additional info such as supervisor PASID
+ * @domain: Domain info for setting up second level page tables
+ * @addr_width: Address width of the first level (guest)
+ */
+int intel_pasid_setup_nested(struct intel_iommu *iommu,
+   struct device *dev, pgd_t *gpgd,
+   int pasid, int flags,
+   struct dmar_domain *domain,
+   int addr_width)
+{
+   struct pasid_entry *pte;
+   struct dma_pte *pgd;
+   u64 pgd_val;
+   int agaw;
+   u16 did;
+
+   if (!ecap_nest(iommu->ecap)) {
+   pr_err("No nested translation support on %s\n",
+  iommu->name);
+   return -EINVAL;
+   }
+
+   pte = intel_pasid_get_entry(dev, pasid);
+   if (WARN_ON(!pte))
+   return -EINVAL;
+
+   pasid_clear_entry(pte);
+
+   /* Sanity checking performed by caller to make sure address
+* width matching in two dimensions:
+* 1. CPU vs. IOMMU
+* 2. Guest vs. Host.
+*/
+   switch (addr_width) {
+   case 57:
+   pasid_set_flpm(pte, 1);
+   break;
+   case 48:
+   pasid_set_flpm(pte, 0);
+   break;
+   default:
+   dev_err(dev, "Invalid paging mode %d\n", addr_width);
+   return -EINVAL;
+   }
+
+   /* Setup the first level page table pointer in GPA */
+   pasid_set_flptr(pte, (u64)gpgd);
+   if (flags & PASID_FLAG_SUPERVISOR_MODE) {
+   if (!ecap_srs(iommu->ecap)) {
+   pr_err("No supervisor request support on %s\n",
+  iommu->name);
+   return -EINVAL;
+   }
+   pasid_set_sre(pte);
+   }
+
+   /* Setup the second level based on the given domain */
+   pgd = domain->pgd;
+
+   for (agaw = domain->agaw; agaw != iommu->agaw; agaw--) {
+   pgd = phys_to_virt(dma_pte_addr(pgd));
+   if (!dma_pte_present(pgd)) {
+   dev_err(dev, "Invalid domain page table\n");
+   return -EINVAL;
+   }
+   }
+   pgd_val = virt_to_phys(pgd);
+   pasid_set_slptr(pte, pgd_val);
+   pasid_set_fault_enable(pte);
+
+   did = domain->iommu_did[iommu->seq_id];
+   pasid_set_domain_id(pte, did);
+
+   pasid_set_address_width(pte, agaw);
+   pasid_set_page_snoop(pte, !!ecap_smpwc(iommu->ecap));
+
+   pasid_set_translation_type(pte, PASID_ENTRY_PGTT_NESTED);
+   pasid_set_present(pte);
+
+   if (!ecap_coherent(iommu->ecap))
+   clflush_cache_range(pte, sizeof(*pte));
+
+   if (cap_caching_mode(iommu->cap)) {
+   pasid_cache_invalidation_with_pasid(iommu, did, pasid);
+   iotlb_invalidation_with_pasid(iommu, did, pasid);
+   } else
+   iommu_flush_write_buffer(iommu);
+
+   return 0;
+}
diff --git a/drivers/iommu/intel-pasid.h b/drivers/iommu/intel-pasid.h
index 0999dfe..c4fc1af 100644
--- a/drivers/iommu/intel-pasid.h
+++ b/drivers/iommu/intel-pasid.h
@@ -42,6 +42,7 @@
  * to vmalloc or even module mappings.
  */
 #define PASID_FLAG_SUPERVISOR_MODE BIT(0)
+#define PASID_FLAG_NESTED  BIT(1)
 
 struct pasid_dir_entry {
u64 val;
@@ -51,6 +52,11 @@ struct pasid_entry {
u64 val[8];
 };
 
+#define PASID_ENTRY_PGTT_FL_ONLY   (1)
+#define PASID_ENTRY_PGTT_SL_ONLY   (2)
+#define PASID_ENTRY_PGTT_NESTED(3)
+#define PASID_ENTRY_PGTT_PT(4)
+
 /* The representative of a 

[PATCH 07/18] iommu: Introduce attach/detach_pasid_table API

[Jacob Pan]

In virtualization use case, when a guest is assigned
a PCI host device, protected by a virtual IOMMU on the guest,
the physical IOMMU must be programmed to be consistent with
the guest mappings. If the physical IOMMU supports two
translation stages it makes sense to program guest mappings
onto the first stage/level (ARM/Intel terminology) while the host
owns the stage/level 2.

In that case, it is mandated to trap on guest configuration
settings and pass those to the physical iommu driver.

This patch adds a new API to the iommu subsystem that allows
to set/unset the pasid table information.

A generic iommu_pasid_table_config struct is introduced in
a new iommu.h uapi header. This is going to be used by the VFIO
user API.

Signed-off-by: Jean-Philippe Brucker 
Signed-off-by: Liu, Yi L 
Signed-off-by: Ashok Raj 
Signed-off-by: Jacob Pan 
Signed-off-by: Eric Auger 

---

This patch generalizes the API introduced by Jacob & co-authors in
https://lwn.net/Articles/754331/

v3 -> v4:
- s/set_pasid_table/attach_pasid_table
- restore detach_pasid_table. Detach can be used on unwind path.
- add padding
- remove @abort
- signature used for config and format
- add comments for fields in the SMMU struct

v2 -> v3:
- replace unbind/bind by set_pasid_table
- move table pointer and pasid bits in the generic part of the struct

v1 -> v2:
- restore the original pasid table name
- remove the struct device * parameter in the API
- reworked iommu_pasid_smmuv3
---
 drivers/iommu/iommu.c  | 19 +++
 include/linux/iommu.h  | 22 ++
 include/uapi/linux/iommu.h | 47 ++
 3 files changed, 88 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ac7e6b3..242f702 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1547,6 +1547,25 @@ int iommu_attach_device(struct iommu_domain *domain, 
struct device *dev)
 }
 EXPORT_SYMBOL_GPL(iommu_attach_device);
 
+int iommu_attach_pasid_table(struct iommu_domain *domain,
+struct iommu_pasid_table_config *cfg)
+{
+   if (unlikely(!domain->ops->attach_pasid_table))
+   return -ENODEV;
+
+   return domain->ops->attach_pasid_table(domain, cfg);
+}
+EXPORT_SYMBOL_GPL(iommu_attach_pasid_table);
+
+void iommu_detach_pasid_table(struct iommu_domain *domain)
+{
+   if (unlikely(!domain->ops->detach_pasid_table))
+   return;
+
+   domain->ops->detach_pasid_table(domain);
+}
+EXPORT_SYMBOL_GPL(iommu_detach_pasid_table);
+
 static void __iommu_detach_device(struct iommu_domain *domain,
  struct device *dev)
 {
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f12f251..9f870ae 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -190,6 +190,8 @@ struct iommu_resv_region {
  * @is_attach_deferred: Check if domain attach should be deferred from iommu
  *  driver init to device driver init (default no)
  * @pgsize_bitmap: bitmap of all possible supported page sizes
+ * @attach_pasid_table: attach a pasid table
+ * @detach_pasid_table: detach the pasid table
  */
 struct iommu_ops {
bool (*capable)(enum iommu_cap);
@@ -233,6 +235,10 @@ struct iommu_ops {
int (*of_xlate)(struct device *dev, struct of_phandle_args *args);
bool (*is_attach_deferred)(struct iommu_domain *domain, struct device 
*dev);
 
+   int (*attach_pasid_table)(struct iommu_domain *domain,
+ struct iommu_pasid_table_config *cfg);
+   void (*detach_pasid_table)(struct iommu_domain *domain);
+
unsigned long pgsize_bitmap;
 };
 
@@ -343,6 +349,9 @@ extern int iommu_attach_device(struct iommu_domain *domain,
   struct device *dev);
 extern void iommu_detach_device(struct iommu_domain *domain,
struct device *dev);
+extern int iommu_attach_pasid_table(struct iommu_domain *domain,
+   struct iommu_pasid_table_config *cfg);
+extern void iommu_detach_pasid_table(struct iommu_domain *domain);
 extern struct iommu_domain *iommu_get_domain_for_dev(struct device *dev);
 extern struct iommu_domain *iommu_get_dma_domain(struct device *dev);
 extern int iommu_map(struct iommu_domain *domain, unsigned long iova,
@@ -781,6 +790,19 @@ const struct iommu_ops *iommu_ops_from_fwnode(struct 
fwnode_handle *fwnode)
return NULL;
 }
 
+static inline
+int iommu_attach_pasid_table(struct iommu_domain *domain,
+struct iommu_pasid_table_config *cfg)
+{
+   return -ENODEV;
+}
+
+static inline
+void iommu_detach_pasid_table(struct iommu_domain *domain)
+{
+   return -ENODEV;
+}
+
 #endif /* CONFIG_IOMMU_API */
 
 #ifdef CONFIG_IOMMU_DEBUGFS
diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
index 7ebf23e..e9065bf 100644
--- a/include/uapi/linux/iommu.h
+++ b/include/uapi/linux/iommu.h

Re: linux-next: Fixes tags need some work in the cifs tree

[Stephen Rothwell]

Hi Steve,

On Mon, 8 Apr 2019 17:30:20 -0500 Steve French  wrote:
>
> I just fixed these up manually and repushed to cifs-2.6.git for-next

Thanks.

> I was curious if checkpatch should have flagged this - I reran
> checkpatch on the original version of Zhang's patches and it didn't
> complain about the spacing (and probably should have).

Yeah, I use the attached script to check for these.  I was hoping that
someone might hack at least some of theses tests into checkpatch, but
that hasn't happened yet :-(  But, then again, I don't run checkpatch :-)
-- 
Cheers,
Stephen Rothwell


check_fixes
Description: application/shellscript


pgp_HoAFhNX2v.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the kspp-gustavo tree with Linus' tree

[Gustavo A. R. Silva]

On 4/7/19 4:17 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kspp-gustavo tree got a conflict in:
> 
>   arch/x86/include/asm/syscall.h
> 
> between commits:
> 
>   b35f549df1d7 ("syscalls: Remove start and number from 
> syscall_get_arguments() args")
>   32d92586629a ("syscalls: Remove start and number from 
> syscall_set_arguments() args")
> 
> from Linus' tree and commit:
> 
>   1f7ae812f87e ("x86/syscalls: Mark expected switch fall-throughs")
> 

I just removed the above commit from my tree.

Thanks for the report, Stephen.
--
Gustavo

Re: [PATCH] slab: fix a crash by reading /proc/slab_allocators

[Tobin C. Harding]

On Sun, Apr 07, 2019 at 07:35:34PM -1000, Linus Torvalds wrote:
> On Sat, Apr 6, 2019 at 12:59 PM Qian Cai  wrote:
> >
> > The commit 510ded33e075 ("slab: implement slab_root_caches list")
> > changes the name of the list node within "struct kmem_cache" from
> > "list" to "root_caches_node", but leaks_show() still use the "list"
> > which causes a crash when reading /proc/slab_allocators.
> 
> The patch does seem to be correct, and I have applied it.
> 
> However, it does strike me that apparently this wasn't caught for two
> years. Which makes me wonder whether we should (once again) discuss
> just removing SLAB entirely, or at least removing the
> /proc/slab_allocators file. Apparently it has never been used in the
> last two years. At some point a "this can't have worked if  anybody
> ever tried to use it" situation means that the code should likely be
> excised.

The bug doesn't trigger on every read of /proc/slab_allocators (as noted
later in this thread by Qian).  I tried to repro it with a bunch of
different configs and often `cat /proc/slab_allocators` just returns
empty.

I've got a patchset ready to go sitting in my tree that removes SLAB, I
could just send it to start the conversation :)


Tobin

RE: [PATCH RESEND 4/5] x86/MCE: Make number of MCA banks per_cpu

[Ghannam, Yazen]

> -Original Message-
> From: linux-edac-ow...@vger.kernel.org  On 
> Behalf Of Luck, Tony
> Sent: Monday, April 8, 2019 6:23 PM
> To: Ghannam, Yazen 
> Cc: Borislav Petkov ; linux-e...@vger.kernel.org; 
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re: [PATCH RESEND 4/5] x86/MCE: Make number of MCA banks per_cpu
> 
> On Mon, Apr 08, 2019 at 10:48:34PM +, Ghannam, Yazen wrote:
> > Okay, so drop the export and leave the injector code as-is (it's
> > already doing a rdmsrl_on_cpu()).
> 
> It's still a globally visible symbol (shared by core.c and amd.c).
> So I think it needs a "mce_" prefix.
> 
> While it doesn't collide now, there are a bunch of other
> subsystems that have "banks" and a variable to count them.
> 
> Look at output from "git grep -w num_banks".
> 

Okay, I'll add the prefix.

And thanks for the tip. I'll try to keep this in mind.

Thanks,
Yazen 

Re: [PATCH RESEND 4/5] x86/MCE: Make number of MCA banks per_cpu

[Luck, Tony]

On Mon, Apr 08, 2019 at 10:48:34PM +, Ghannam, Yazen wrote:
> Okay, so drop the export and leave the injector code as-is (it's
> already doing a rdmsrl_on_cpu()).

It's still a globally visible symbol (shared by core.c and amd.c).
So I think it needs a "mce_" prefix.

While it doesn't collide now, there are a bunch of other
subsystems that have "banks" and a variable to count them.

Look at output from "git grep -w num_banks".

-Tony

Re: [PATCH v4 1/3] mm/vmap: keep track of free blocks for vmap allocation

[Roman Gushchin]

On Sat, Apr 06, 2019 at 08:35:06PM +0200, Uladzislau Rezki (Sony) wrote:
> Currently an allocation of the new vmap area is done over busy
> list iteration(complexity O(n)) until a suitable hole is found
> between two busy areas. Therefore each new allocation causes
> the list being grown. Due to over fragmented list and different
> permissive parameters an allocation can take a long time. For
> example on embedded devices it is milliseconds.
> 
> This patch organizes the KVA memory layout into free areas of the
> 1-ULONG_MAX range. It uses an augment red-black tree that keeps
> blocks sorted by their offsets in pair with linked list keeping
> the free space in order of increasing addresses.
> 
> Nodes are augmented with the size of the maximum available free
> block in its left or right sub-tree. Thus, that allows to take a
> decision and traversal toward the block that will fit and will
> have the lowest start address, i.e. it is sequential allocation.
> 
> Allocation: to allocate a new block a search is done over the
> tree until a suitable lowest(left most) block is large enough
> to encompass: the requested size, alignment and vstart point.
> If the block is bigger than requested size - it is split.
> 
> De-allocation: when a busy vmap area is freed it can either be
> merged or inserted to the tree. Red-black tree allows efficiently
> find a spot whereas a linked list provides a constant-time access
> to previous and next blocks to check if merging can be done. In case
> of merging of de-allocated memory chunk a large coalesced area is
> created.
> 
> Complexity: ~O(log(N))
> 
> Signed-off-by: Uladzislau Rezki (Sony) 

Reviewed-by: Roman Gushchin 

Thanks!

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

[Stephen Rothwell]

Hi all,

On Tue, 26 Mar 2019 10:01:45 +1100 Stephen Rothwell  
wrote:
>
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> sound/soc/codecs/tlv320aic32x4-clk.c: In function 
> 'clk_aic32x4_pll_recalc_rate':
> sound/soc/codecs/tlv320aic32x4-clk.c:149:38: warning: 'settings.d' may be 
> used uninitialized in this function [-Wmaybe-uninitialized]
>  ((settings->j * 1) + settings->d);
>   ^~~
> sound/soc/codecs/tlv320aic32x4-clk.c:197:32: note: 'settings.d' was declared 
> here
>   struct clk_aic32x4_pll_muldiv settings;
> ^~~~
> sound/soc/codecs/tlv320aic32x4-clk.c:149:15: warning: 'settings.j' may be 
> used uninitialized in this function [-Wmaybe-uninitialized]
>  ((settings->j * 1) + settings->d);
>^~~
> sound/soc/codecs/tlv320aic32x4-clk.c:197:32: note: 'settings.j' was declared 
> here
>   struct clk_aic32x4_pll_muldiv settings;
> ^~~~
> sound/soc/codecs/tlv320aic32x4-clk.c:148:37: warning: 'settings.r' may be 
> used uninitialized in this function [-Wmaybe-uninitialized]
>   rate = (u64) parent_rate * settings->r *
>  ^~~
> sound/soc/codecs/tlv320aic32x4-clk.c:197:32: note: 'settings.r' was declared 
> here
>   struct clk_aic32x4_pll_muldiv settings;
> ^~~~
> sound/soc/codecs/tlv320aic32x4-clk.c:151:56: warning: 'settings.p' may be 
> used uninitialized in this function [-Wmaybe-uninitialized]
>   return (unsigned long) DIV_ROUND_UP_ULL(rate, settings->p * 1);
> ^~
> sound/soc/codecs/tlv320aic32x4-clk.c:197:32: note: 'settings.p' was declared 
> here
>   struct clk_aic32x4_pll_muldiv settings;
> ^~~~
> 
> Introduced by commit
> 
>   514b044cba66 ("ASoC: tlv320aic32x4: Model PLL in CCF")

I am still getting these warnings.

-- 
Cheers,
Stephen Rothwell


pgpBw3IqPaxZF.pgp
Description: OpenPGP digital signature

[GIT PULL] TPM fixes for v5.1

[James Morris]

Please pull these TPM fixes, from Jarkko:

"These are critical fixes for v5.1. Contains also couple of new selftests 
for v5.1 features (partial reads in /dev/tpm0)."

---

The following changes since commit fd008d1a7a204695f0e5e003af16448bb9c34b7b:

  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2019-04-07 
19:51:09 -1000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
fixes-v5.1

for you to fetch changes up to 6da70580af9612accf042b37564d73e787af39b4:

  selftests/tpm2: Open tpm dev in unbuffered mode (2019-04-08 15:58:55 -0700)


Jarkko Sakkinen (2):
  tpm: turn on TPM on suspend for TPM 1.x
  KEYS: trusted: allow trusted.ko to initialize w/o a TPM

Tadeusz Struk (3):
  tpm: fix an invalid condition in tpm_common_poll
  selftests/tpm2: Extend tests to cover partial reads
  selftests/tpm2: Open tpm dev in unbuffered mode

Yue Haibing (1):
  tpm: Fix the type of the return value in calc_tpm2_event_size()

ndesaulni...@google.com (1):
  KEYS: trusted: fix -Wvarags warning

 drivers/char/tpm/eventlog/tpm2.c   |  4 +-
 drivers/char/tpm/tpm-dev-common.c  |  9 -
 drivers/char/tpm/tpm-interface.c   | 14 +++
 include/keys/trusted.h |  2 +-
 security/keys/trusted.c| 32 +++
 tools/testing/selftests/tpm2/tpm2.py   |  5 ++-
 tools/testing/selftests/tpm2/tpm2_tests.py | 63 ++
 7 files changed, 108 insertions(+), 21 deletions(-)

Re: [PATCH v3] PCI: al: Add Amazon Annapurna Labs PCIe host controller driver

[Benjamin Herrenschmidt]

On Thu, 2019-03-28 at 13:57 +0200, Jonathan Chocron wrote:
> Add support for Amazon's Annapurna Labs PCIe driver. The HW
> controller
> is based on DesignWare's IP.
> 
> The HW doesn't support accessing the Root Port's config space via
> ECAM,
> so we obtain its base address via an AMZN0001 device.
> 
> Furthermore, the DesignWare PCIe controller doesn't filter out config
> transactions sent to devices 1 and up on its bus, so they are
> filtered
> by the driver.
> 
> All subordinate buses do support ECAM access.
> 
> Implementing specific PCI config access functions involves:
>  - Adding an init function to obtain the Root Port's base address
> from
>an AMZN0001 device.
>  - Adding a new entry in the MCFG quirk array
> 
> Co-developed-by: Vladimir Aerov 
> Signed-off-by: Jonathan Chocron 
> Signed-off-by: Vladimir Aerov 
> Reviewed-by: David Woodhouse 

Late to the party, sorry :-) That kernel.crashing.org email is on its
last legs...

Reviewed-by: Benjamin Herrenschmidt 

> ---
> 
> --v2:
>   - Fix commit message comments (incl. using AMZN0001 instead of
> PNP0C02)
>   - Use the usual multi-line comment style
> 
> --v3:
>   - Fix additional commit message comments
> 
>  MAINTAINERS  |  6 +++
>  drivers/acpi/pci_mcfg.c  | 12 +
>  drivers/pci/controller/dwc/Makefile  |  1 +
>  drivers/pci/controller/dwc/pcie-al.c | 93
> 
>  include/linux/pci-ecam.h |  1 +
>  5 files changed, 113 insertions(+)
>  create mode 100644 drivers/pci/controller/dwc/pcie-al.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 32d76a90..7a17017f9f82 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11769,6 +11769,12 @@ T:   git
> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git/
>  S:   Supported
>  F:   drivers/pci/controller/
>  
> +PCIE DRIVER FOR ANNAPURNA LABS
> +M:   Jonathan Chocron 
> +L:   linux-...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/pci/controller/dwc/pcie-al.c
> +
>  PCIE DRIVER FOR AMLOGIC MESON
>  M:   Yue Wang 
>  L:   linux-...@vger.kernel.org
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index a4e8432fc2fb..b42be067fb83 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -52,6 +52,18 @@ struct mcfg_fixup {
>  static struct mcfg_fixup mcfg_quirks[] = {
>  /*   { OEM_ID, OEM_TABLE_ID, REV, SEGMENT, BUS_RANGE, ops, cfgres },
> */
>  
> +#define AL_ECAM(table_id, rev, seg, ops) \
> + { "AMAZON", table_id, rev, seg, MCFG_BUS_ANY, ops }
> +
> + AL_ECAM("GRAVITON", 0, 0, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 1, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 2, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 3, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 4, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 5, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 6, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 7, _pcie_ops),
> +
>  #define QCOM_ECAM32(seg) \
>   { "QCOM  ", "QDF2432 ", 1, seg, MCFG_BUS_ANY, _32b_ops }
>  
> diff --git a/drivers/pci/controller/dwc/Makefile
> b/drivers/pci/controller/dwc/Makefile
> index 7bcdcdf5024e..1ea773c0070d 100644
> --- a/drivers/pci/controller/dwc/Makefile
> +++ b/drivers/pci/controller/dwc/Makefile
> @@ -28,5 +28,6 @@ obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
>  # depending on whether ACPI, the DT driver, or both are enabled.
>  
>  ifdef CONFIG_PCI
> +obj-$(CONFIG_ARM64) += pcie-al.o
>  obj-$(CONFIG_ARM64) += pcie-hisi.o
>  endif
> diff --git a/drivers/pci/controller/dwc/pcie-al.c
> b/drivers/pci/controller/dwc/pcie-al.c
> new file mode 100644
> index ..65a9776c12be
> --- /dev/null
> +++ b/drivers/pci/controller/dwc/pcie-al.c
> @@ -0,0 +1,93 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PCIe host controller driver for Amazon's Annapurna Labs IP (used
> in chips
> + * such as Graviton and Alpine)
> + *
> + * Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights
> Reserved.
> + *
> + * Author: Jonathan Chocron 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include "../../pci.h"
> +
> +#if defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS)
> +
> +struct al_pcie_acpi  {
> + void __iomem *dbi_base;
> +};
> +
> +static void __iomem *al_pcie_map_bus(struct pci_bus *bus, unsigned
> int devfn,
> +  int where)
> +{
> + struct pci_config_window *cfg = bus->sysdata;
> + struct al_pcie_acpi *pcie = cfg->priv;
> + void __iomem *dbi_base = pcie->dbi_base;
> +
> + if (bus->number == cfg->busr.start) {
> + /*
> +  * The DW PCIe core doesn't filter out transactions to
> other
> +  * devices/functions on the primary bus num, so we do
> this here.
> +  */
> + if (PCI_SLOT(devfn) > 0)
> + return NULL;
> + else
> + return dbi_base + where;
> + }
> +
> + return pci_ecam_map_bus(bus, devfn, where);
> +}
> +
> +static int 

Re: [PATCH v1 bitops] bitops: Fix UBSAN undefined behavior warning for rotation right

[Andrew Morton]

(resend, cc Andrey)

On Sun,  7 Apr 2019 12:53:25 + Vadim Pasternak  wrote:

> The warning is caused by call to rorXX(), if the second parameters of
> this function "shift" is zero. In such case UBSAN reports the warning
> for the next expression: (word << (XX - shift), where XX is
> 64, 32, 16, 8 for respectively ror64, ror32, ror16, ror8.
> Fix adds validation of this parameter - in case it's equal zero, no
> need to rotate, just original "word" is to be returned to caller.
> 
> The UBSAN undefined behavior warning has been reported for call to
> ror32():
> [   11.426543] UBSAN: Undefined behaviour in ./include/linux/bitops.h:93:33
> [   11.434045] shift exponent 32 is too large for 32-bit type 'unsigned int'

hm, do we care?

> ...
>

> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -70,6 +70,9 @@ static inline __u64 rol64(__u64 word, unsigned int shift)
>   */
>  static inline __u64 ror64(__u64 word, unsigned int shift)
>  {
> + if (!shift)
> + return word;
> +
>   return (word >> shift) | (word << (64 - shift));
>  }

Is there any known architecture or compiler for which UL<<64 doesn't
reliably produce zero?  Is there any prospect that this will become a
problem in the future?