Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v2] power: reset: at91-poweroff: move shdwc related data to one structure
From: Sebastian Reichel @ 2018-12-06 20:59 UTC (permalink / raw)
  To: Claudiu.Beznea
  Cc: alexandre.belloni, linux-pm, linux-kernel, Ludovic.Desroches,
	linux-arm-kernel
In-Reply-To: <1544117357-24177-1-git-send-email-claudiu.beznea@microchip.com>


[-- Attachment #1.1: Type: text/plain, Size: 4731 bytes --]

Hi,

On Thu, Dec 06, 2018 at 05:29:46PM +0000, Claudiu.Beznea@microchip.com wrote:
> From: Claudiu Beznea <claudiu.beznea@microchip.com>
> 
> Move SHDWC realted data to only one structure to have them grouped.
> Inspired from commit 9be74f0d39c1 ("power: reset: at91-poweroff: make
> mpddrc_base part of struct shdwc").
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---

Thanks, queued.

-- Sebastian

> 
> Changes in v2:
> - avoid allocate at91_shdwc and keep it static instead
> - avoid registering at91_shdwc as platform data and use static variable
>   instead
> 
>  drivers/power/reset/at91-poweroff.c | 48 +++++++++++++++++++------------------
>  1 file changed, 25 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/power/reset/at91-poweroff.c b/drivers/power/reset/at91-poweroff.c
> index d3d87af24e55..9e74e131c675 100644
> --- a/drivers/power/reset/at91-poweroff.c
> +++ b/drivers/power/reset/at91-poweroff.c
> @@ -51,14 +51,16 @@ static const char *shdwc_wakeup_modes[] = {
>  	[AT91_SHDW_WKMODE0_ANYLEVEL]	= "any",
>  };
>  
> -static void __iomem *at91_shdwc_base;
> -static struct clk *sclk;
> -static void __iomem *mpddrc_base;
> +static struct shdwc {
> +	struct clk *sclk;
> +	void __iomem *shdwc_base;
> +	void __iomem *mpddrc_base;
> +} at91_shdwc;
>  
>  static void __init at91_wakeup_status(struct platform_device *pdev)
>  {
>  	const char *reason;
> -	u32 reg = readl(at91_shdwc_base + AT91_SHDW_SR);
> +	u32 reg = readl(at91_shdwc.shdwc_base + AT91_SHDW_SR);
>  
>  	/* Simple power-on, just bail out */
>  	if (!reg)
> @@ -92,9 +94,9 @@ static void at91_poweroff(void)
>  
>  		"	b	.\n\t"
>  		:
> -		: "r" (mpddrc_base),
> +		: "r" (at91_shdwc.mpddrc_base),
>  		  "r" cpu_to_le32(AT91_DDRSDRC_LPDDR2_PWOFF),
> -		  "r" (at91_shdwc_base),
> +		  "r" (at91_shdwc.shdwc_base),
>  		  "r" cpu_to_le32(AT91_SHDW_KEY | AT91_SHDW_SHDW)
>  		: "r6");
>  }
> @@ -144,7 +146,7 @@ static void at91_poweroff_dt_set_wakeup_mode(struct platform_device *pdev)
>  	if (of_property_read_bool(np, "atmel,wakeup-rtt-timer"))
>  			mode |= AT91_SHDW_RTTWKEN;
>  
> -	writel(wakeup_mode | mode, at91_shdwc_base + AT91_SHDW_MR);
> +	writel(wakeup_mode | mode, at91_shdwc.shdwc_base + AT91_SHDW_MR);
>  }
>  
>  static int __init at91_poweroff_probe(struct platform_device *pdev)
> @@ -155,15 +157,15 @@ static int __init at91_poweroff_probe(struct platform_device *pdev)
>  	int ret;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	at91_shdwc_base = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(at91_shdwc_base))
> -		return PTR_ERR(at91_shdwc_base);
> +	at91_shdwc.shdwc_base = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(at91_shdwc.shdwc_base))
> +		return PTR_ERR(at91_shdwc.shdwc_base);
>  
> -	sclk = devm_clk_get(&pdev->dev, NULL);
> -	if (IS_ERR(sclk))
> -		return PTR_ERR(sclk);
> +	at91_shdwc.sclk = devm_clk_get(&pdev->dev, NULL);
> +	if (IS_ERR(at91_shdwc.sclk))
> +		return PTR_ERR(at91_shdwc.sclk);
>  
> -	ret = clk_prepare_enable(sclk);
> +	ret = clk_prepare_enable(at91_shdwc.sclk);
>  	if (ret) {
>  		dev_err(&pdev->dev, "Could not enable slow clock\n");
>  		return ret;
> @@ -176,20 +178,20 @@ static int __init at91_poweroff_probe(struct platform_device *pdev)
>  
>  	np = of_find_compatible_node(NULL, NULL, "atmel,sama5d3-ddramc");
>  	if (np) {
> -		mpddrc_base = of_iomap(np, 0);
> +		at91_shdwc.mpddrc_base = of_iomap(np, 0);
>  		of_node_put(np);
>  
> -		if (!mpddrc_base) {
> +		if (!at91_shdwc.mpddrc_base) {
>  			ret = -ENOMEM;
>  			goto clk_disable;
>  		}
>  
> -		ddr_type = readl(mpddrc_base + AT91_DDRSDRC_MDR) &
> +		ddr_type = readl(at91_shdwc.mpddrc_base + AT91_DDRSDRC_MDR) &
>  				 AT91_DDRSDRC_MD;
>  		if (ddr_type != AT91_DDRSDRC_MD_LPDDR2 &&
>  		    ddr_type != AT91_DDRSDRC_MD_LPDDR3) {
> -			iounmap(mpddrc_base);
> -			mpddrc_base = NULL;
> +			iounmap(at91_shdwc.mpddrc_base);
> +			at91_shdwc.mpddrc_base = NULL;
>  		}
>  	}
>  
> @@ -198,7 +200,7 @@ static int __init at91_poweroff_probe(struct platform_device *pdev)
>  	return 0;
>  
>  clk_disable:
> -	clk_disable_unprepare(sclk);
> +	clk_disable_unprepare(at91_shdwc.sclk);
>  	return ret;
>  }
>  
> @@ -207,10 +209,10 @@ static int __exit at91_poweroff_remove(struct platform_device *pdev)
>  	if (pm_power_off == at91_poweroff)
>  		pm_power_off = NULL;
>  
> -	if (mpddrc_base)
> -		iounmap(mpddrc_base);
> +	if (at91_shdwc.mpddrc_base)
> +		iounmap(at91_shdwc.mpddrc_base);
>  
> -	clk_disable_unprepare(sclk);
> +	clk_disable_unprepare(at91_shdwc.sclk);
>  
>  	return 0;
>  }
> -- 
> 2.7.4
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: Moving ARM dts files
From: Olof Johansson @ 2018-12-06 20:49 UTC (permalink / raw)
  To: Mark Brown
  Cc: Andrew Lunn, Alexandre Belloni, Tony Lindgren, LinusW,
	Liviu Dudau, Michal Simek, Masahiro Yamada, Thierry Reding,
	Rob Herring, Florian Fainelli, Kevin Hilman, Gregory CLEMENT,
	Alexander Graf, Krzysztof Kozlowski, ARM-SoC Maintainers,
	Joel Stanley, Andy Gross, DTML, Boot Architecture, Jason Cooper,
	Tom Rini, Simon Horman, Linux ARM Mailing List, Grant Likely,
	Maxime Coquelin, Shawn Guo, Andreas Färber, Daniel Mack
In-Reply-To: <20181206200652.GB3084@sirena.org.uk>

On Thu, Dec 6, 2018 at 12:07 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Dec 06, 2018 at 01:06:43PM -0600, Rob Herring wrote:
> > On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber <afaerber@suse.de> wrote:
>
> > > I'd be okay with distinguishing source vs. install location. Due to the
> > > issue I mention below (and more) we can't use install_dtbs for openSUSE
> > > and had to reimplement it, which we'd need to (and can) adjust.
>
> > What would be needed for dtbs_install to work? arm64 needs to support
> > a flat install? If it doesn't work for Debian or openSUSE, I'm not
> > sure why we have it. So I'd like to make it work.
>
> Correct me if I'm wrong but as far as the flat vs directory thing goes
> isn't the issue that this winds up being a rename for an existing 32 bit
> system?  If you just install the dtbs in the default location then a
> bootloader or whatever that is hard coded to look for foo-bar.dtb won't
> see the new foo/foo-bar.dtb (or whatever) and will continue to use the
> old binary.  It's not the fact that that it's in a directory, it's the
> fact that the bootloader sees the name it needs to look for change (if
> it's looking on a filesystem at all).  This isn't a problem for arm64 as
> the location isn't changing, it's used directories from day one.

Yeah, install needs to remain flat even if the dts files move into
subdirectories. It will be painful for everybody if the install
location moves.

> The issues with the existing install_dtbs sounded unrelated to this.

Agreed.


-Olof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH V3] arm64: Don't flush tlb while clearing the accessed bit
From: Alexander Van Brunt @ 2018-12-06 20:42 UTC (permalink / raw)
  To: Will Deacon
  Cc: mark.rutland@arm.com, linux-kernel@vger.kernel.org, Sachin Nikam,
	linux-tegra@vger.kernel.org, Ashish Mhetre,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR12MB271239AAF4A0B79D756850C6CFA90@BYAPR12MB2712.namprd12.prod.outlook.com>

> > > If we roll a TLB invalidation routine without the trailing DSB, what sort of
> > > performance does that get you?
> > 
> > It is not as good. In some cases, it is really bad. Skipping the invalidate was
> > the most consistent and fast implementation.

> My problem with that is it's not really much different to just skipping the
> page table update entirely. Skipping the DSB is closer to what is done on
> x86, where we bound the stale entry time to the next context-switch.

Which of the three implementations is the "that" and "it" in the first sentence?

> Given that I already queued the version without the DSB, we have the choice
> to either continue with that or to revert it and go back to the previous
> behaviour. Which would you prefer?

To me, skipping the DSB is a win over doing the invalidate and the DSB because
it is faster on average.

DSBs have a big impact on the performance of other CPUs in the inner shareable
domain because of the ordering requirements. For example, we have observed
Cortex A57s stalling all CPUs in the cluster until Device accesses complete.

Would you be open to a patch on top of the DSB skipping patch that skips the
whole invalidate?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 00/14] rtc: sun6i: clock rework and pre-H6 SoC support
From: Alexandre Belloni @ 2018-12-06 20:34 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: linux-rtc, Alessandro Zummo, devicetree, Maxime Ripard,
	Mike Turquette, linux-kernel, Stephen Boyd, linux-sunxi,
	Rob Herring, Mark Rutland, linux-clk, linux-arm-kernel
In-Reply-To: <CAGb2v65GwzEHZnRJysp=qE4HjrTa+TzCeyQ_j_Q=RrwtnC617g@mail.gmail.com>

On 06/12/2018 13:49:10+0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Mon, Dec 3, 2018 at 10:58 PM Chen-Yu Tsai <wens@csie.org> wrote:
> >
> > Hi everyone,
> >
> > This is v2 of my rtc-sun6i clean-up series.
> >
> > Changes since v1:
> >
> >   - Collected tags
> >   - Dropped patch "clk: sunxi-ng: r40: Force LOSC parent to RTC LOSC
> >     output"; already merged
> >   - Removed H6 compatible CLK_OF_DECLARE_DRIVER entry that wasn't
> >     overlooked
> >   - Only export IOSC clock for A64/H3/H5
> >
> > Original cover letter, with patch numbers corrected, follows:
> >
> > This series was started as part of enabling Bluetooth on various
> > Allwinner SBCs. The bluetooth controller requires a precise 32.768 kHz
> > clock fed to it to correctly detect the frequency of its main oscillator.
> > This clock signal is provided by the RTC, either directly from a special
> > pin on the SoC, or some clock output function from the clock controllers.
> > I found that the clock-related properties of the RTC on later SoCs were
> > incorrect or missing.
> >
> > This series reworks the compatible strings and clock parts of the device
> > tree bindings for sun6i-rtc. Currently we assume most Allwinner SoCs use
> > the same sun6i-rtc variant, when in fact they do not. The differences
> > that matter with regards to clocks are a) the A31 does not have an extra
> > external output for the RTC 32K clock, while most of the others do;
> > b) the clock frequency of the internal RC oscillator is different on
> > some SoCs; c) on the H6 the RTC also handles the 24 MHz DCXO, which
> > feeds the system HOSC. The last difference, and by extension the H6, are
> > not covered in this series.
> >
> > Patch 1 cleans up the clock-related section of the RTC device tree
> > binding. This would make it easier to read and easier to add additional
> > clocks.
> >
> > Patch 2 adds compatible strings for all identified variants introduced
> > prior to the H6.
> >
> > Patch 3 deprecates the external clock output for the A31. The A31 does
> > not have this output, so it's introduction and usage was an error.
> >
> > Patch 4 adds a clock output for the RTC's internal oscillator to the
> > device tree binding. This feeds the PRCM in some SoCs.
> >
> > Patch 5 adds a default clock name for the LOSC to the RTC driver.
> >
> > Patch 6 adds support for different hardware variants to the RTC driver.
> >
> > Patch 7 adds support for all known pre-H6 variants.
> >
> > Patch 8 exposes the RTC's internal oscillator through the device tree.
> >
> > Patch 9 through 14 adds an RTC node or fixes up the RTC device node
> > address ranges, clock properties, names of existing clocks, and adds
> > accuracy properties for the external fixed oscillators.
> >
> > The clock names require fixing because the sunxi clock driver implicitly
> > depends on the HOSC and LOSC being named "osc24M" and "osc32k". The
> > "fixes" to the clock hierarchy introduced in this series means the names
> > must also be shuffled around or the in kernel representation would be
> > incorrect. This has been the case since the sunxi-ng drivers were
> > introduced. There are plans to address this, but the code is still in its
> > early stages.
> >
> > Please have a look.
> >
> > Thanks
> > ChenYu
> >
> > Chen-Yu Tsai (14):
> >   dt-bindings: rtc: sun6i-rtc: Rewrite clock outputs as a list
> >   dt-bindings: rtc: sun6i-rtc: Add compatible strings for pre-H6
> >     variants
> >   dt-bindings: rtc: sun6i-rtc: Deprecate external clock output for A31
> >   dt-bindings: rtc: sun6i-rtc: Export internal RC oscillator
> >   rtc: sun6i: Add default clock name for LOSC
> >   rtc: sun6i: Add support for different variants
> >   rtc: sun6i: Add support for all known pre-H6 variants
> >   rtc: sun6i: Expose internal oscillator through device tree

I've applied the above patches. However, for whatever reason, patch 3
didn't apply without some fuzz, please check.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v5 0/7] spi: add support for octal mode
From: Mark Brown @ 2018-12-06 20:29 UTC (permalink / raw)
  To: Yogesh Narayan Gaur
  Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Vignesh R,
	marek.vasut@gmail.com, linux-kernel@vger.kernel.org,
	linux-spi@vger.kernel.org, Boris Brezillon,
	frieder.schrempf@exceet.de, linux-mtd@lists.infradead.org,
	computersforpeace@gmail.com, shawnguo@kernel.org, robh@kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB572620BB57CB01A352904BB999A90@VI1PR04MB5726.eurprd04.prod.outlook.com>


[-- Attachment #1.1: Type: text/plain, Size: 481 bytes --]

On Thu, Dec 06, 2018 at 06:49:08AM +0000, Yogesh Narayan Gaur wrote:

> Sorry for ignorance. Did patches needs to be applied by Mark Brown, should I resend the patch series again?
> Also can you please review the series [1] and add your Reviewed-by tag.

As I said in my reply earlier today in the same thread:

| I don't have this any more, it looked like this was stuck behind the
| otehr MTD changes which seemed to have problems.  If someone could
| resend?

so please resend.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS
From: Trent Piepho @ 2018-12-06 20:20 UTC (permalink / raw)
  To: l.stach@pengutronix.de, andrew.smirnov@gmail.com,
	linux-pci@vger.kernel.org
  Cc: aisheng.dong@nxp.com, hongxing.zhu@nxp.com,
	linux-kernel@vger.kernel.org, cphealy@gmail.com,
	bhelgaas@google.com, leonard.crestez@nxp.com,
	linux-arm-kernel@lists.infradead.org, linux-imx@nxp.com
In-Reply-To: <1544092136.3709.57.camel@pengutronix.de>

On Thu, 2018-12-06 at 11:28 +0100, Lucas Stach wrote:
> Am Mittwoch, den 05.12.2018, 23:45 -0800 schrieb Andrey Smirnov:
> > Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
> > produces a system where built-in PCIE bridge (16c3:abcd) isn't
> > bound
> > to pcieport driver. This, in turn, results in a PCIE bus that is
> > capable of enumerating attached PCIE device, but lacks functional
> > interrupt support.
> 
> This is odd. AFAIK PCI port services are a totally optional thing and
> them being absent should not lead to a non-functional PCI bus. So I
> would really like to see some deeper analysis what is going on here.

I noticed this previously, 
https://www.spinics.net/lists/linux-pci/msg77840.html

What happened was that PCIEPORTBUS *was* selected by all the platform
dwc drivers and those selections were removed in:

commit f3fdfc4ac3a26865e84627a7fe08a906081e5abc
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Fri May 18 15:08:36 2018 -0500

    PCI: Remove host driver Kconfig selection of CONFIG_PCIEPORTBUS
    
    Host bridge drivers do not use the portdrv interfaces (struct pcie_device,
    struct pcie_port_service_driver, pcie_port_service_register(), etc), and
    they should not select CONFIG_PCIEPORTBUS.

I encountered this when a kernel defconfig that previously turned on
PCIEPORTBUS stopped turning in on, resulting in the situation that
Andrey describes:  no errors, device present, but no MSI interrupts.

The in kernel defconfigs (mine not being one of those) for all the dwc
pcie users should probably be refreshed to enable pcieportbus.

It seems appropriate that the port services are optional and it's
unfortunate that the kernel defconfig system resolves in the change in
this manner, vs keeping pcieportbus on by default.  I do know why it is
this way and I don't think there is any great solution there.

It has never been clear to me why pcieportbus was necessary for MSI.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 2/2] kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops
From: Christophe LEROY @ 2018-12-06 20:15 UTC (permalink / raw)
  To: Daniel Thompson
  Cc: Rich Felker, Gustavo A. R. Silva, Benjamin Herrenschmidt,
	Will Deacon, linux-kernel, Paul Mackerras, sparclinux,
	linux-hexagon, Yoshinori Sato, linux-sh, Michael Ellerman, x86,
	Russell King, Ingo Molnar, Catalin Marinas, James Hogan,
	linux-snps-arc, uclinux-h8-devel, linux-mips, Borislav Petkov,
	nios2-dev, Thomas Gleixner, linux-arm-kernel, Michal Simek,
	Vineet Gupta, Randy Dunlap, Douglas Anderson, Ralf Baechle,
	Richard Kuo, Paul Burton, Jason Wessel, kgdb-bugreport,
	Ley Foon Tan, linuxppc-dev, David S. Miller
In-Reply-To: <20181206140716.apapnpmdk3nrn7i3@holly.lan>



Le 06/12/2018 à 15:07, Daniel Thompson a écrit :
> On Wed, Dec 05, 2018 at 04:41:11AM +0000, Christophe Leroy wrote:
>> checkpatch.pl reports the following:
>>
>>    WARNING: struct kgdb_arch should normally be const
>>    #28: FILE: arch/mips/kernel/kgdb.c:397:
>>    +struct kgdb_arch arch_kgdb_ops = {
>>
>> This report makes sense, as all other ops struct, this
>> one should also be const. This patch does the change.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> 
> Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
> 
> Similar to https://patchwork.kernel.org/patch/10701129/ I would be more
> comfortable to see a resend with the relevant arch maintainers
> explicitly called out with a Cc: entry here.

Done in v2

And
Acked-by: Paul Burton <paul.burton@mips.com>

Thanks
Christophe

> 
> 
>> ---
>>   arch/arc/kernel/kgdb.c        | 2 +-
>>   arch/arm/kernel/kgdb.c        | 2 +-
>>   arch/arm64/kernel/kgdb.c      | 2 +-
>>   arch/h8300/kernel/kgdb.c      | 2 +-
>>   arch/hexagon/kernel/kgdb.c    | 2 +-
>>   arch/microblaze/kernel/kgdb.c | 2 +-
>>   arch/mips/kernel/kgdb.c       | 2 +-
>>   arch/nios2/kernel/kgdb.c      | 2 +-
>>   arch/powerpc/kernel/kgdb.c    | 2 +-
>>   arch/sh/kernel/kgdb.c         | 2 +-
>>   arch/sparc/kernel/kgdb_32.c   | 2 +-
>>   arch/sparc/kernel/kgdb_64.c   | 2 +-
>>   arch/x86/kernel/kgdb.c        | 2 +-
>>   include/linux/kgdb.h          | 2 +-
>>   14 files changed, 14 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
>> index 9a3c34af2ae8..bfd04b442e36 100644
>> --- a/arch/arc/kernel/kgdb.c
>> +++ b/arch/arc/kernel/kgdb.c
>> @@ -204,7 +204,7 @@ void kgdb_roundup_cpus(unsigned long flags)
>>   	local_irq_disable();
>>   }
>>   
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   	/* breakpoint instruction: TRAP_S 0x3 */
>>   #ifdef CONFIG_CPU_BIG_ENDIAN
>>   	.gdb_bpt_instr		= {0x78, 0x7e},
>> diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
>> index caa0dbe3dc61..21a6d5958955 100644
>> --- a/arch/arm/kernel/kgdb.c
>> +++ b/arch/arm/kernel/kgdb.c
>> @@ -274,7 +274,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
>>    * and we handle the normal undef case within the do_undefinstr
>>    * handler.
>>    */
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   #ifndef __ARMEB__
>>   	.gdb_bpt_instr		= {0xfe, 0xde, 0xff, 0xe7}
>>   #else /* ! __ARMEB__ */
>> diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
>> index a20de58061a8..fe1d1f935b90 100644
>> --- a/arch/arm64/kernel/kgdb.c
>> +++ b/arch/arm64/kernel/kgdb.c
>> @@ -357,7 +357,7 @@ void kgdb_arch_exit(void)
>>   	unregister_die_notifier(&kgdb_notifier);
>>   }
>>   
>> -struct kgdb_arch arch_kgdb_ops;
>> +const struct kgdb_arch arch_kgdb_ops;
>>   
>>   int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
>>   {
>> diff --git a/arch/h8300/kernel/kgdb.c b/arch/h8300/kernel/kgdb.c
>> index 1a1d30cb0609..602e478afbd5 100644
>> --- a/arch/h8300/kernel/kgdb.c
>> +++ b/arch/h8300/kernel/kgdb.c
>> @@ -129,7 +129,7 @@ void kgdb_arch_exit(void)
>>   	/* Nothing to do */
>>   }
>>   
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   	/* Breakpoint instruction: trapa #2 */
>>   	.gdb_bpt_instr = { 0x57, 0x20 },
>>   };
>> diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
>> index 16c24b22d0b2..f1924d483e78 100644
>> --- a/arch/hexagon/kernel/kgdb.c
>> +++ b/arch/hexagon/kernel/kgdb.c
>> @@ -83,7 +83,7 @@ struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
>>   	{ "syscall_nr", GDB_SIZEOF_REG, offsetof(struct pt_regs, syscall_nr)},
>>   };
>>   
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   	/* trap0(#0xDB) 0x0cdb0054 */
>>   	.gdb_bpt_instr = {0x54, 0x00, 0xdb, 0x0c},
>>   };
>> diff --git a/arch/microblaze/kernel/kgdb.c b/arch/microblaze/kernel/kgdb.c
>> index 6366f69d118e..130cd0f064ce 100644
>> --- a/arch/microblaze/kernel/kgdb.c
>> +++ b/arch/microblaze/kernel/kgdb.c
>> @@ -143,7 +143,7 @@ void kgdb_arch_exit(void)
>>   /*
>>    * Global data
>>    */
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   #ifdef __MICROBLAZEEL__
>>   	.gdb_bpt_instr = {0x18, 0x00, 0x0c, 0xba}, /* brki r16, 0x18 */
>>   #else
>> diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
>> index 31eff1bec577..edfdc2ec2d16 100644
>> --- a/arch/mips/kernel/kgdb.c
>> +++ b/arch/mips/kernel/kgdb.c
>> @@ -394,7 +394,7 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
>>   	return -1;
>>   }
>>   
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   #ifdef CONFIG_CPU_BIG_ENDIAN
>>   	.gdb_bpt_instr = { spec_op << 2, 0x00, 0x00, break_op },
>>   #else
>> diff --git a/arch/nios2/kernel/kgdb.c b/arch/nios2/kernel/kgdb.c
>> index 117859122d1c..37b25f844a2d 100644
>> --- a/arch/nios2/kernel/kgdb.c
>> +++ b/arch/nios2/kernel/kgdb.c
>> @@ -165,7 +165,7 @@ void kgdb_arch_exit(void)
>>   	/* Nothing to do */
>>   }
>>   
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   	/* Breakpoint instruction: trap 30 */
>>   	.gdb_bpt_instr = { 0xba, 0x6f, 0x3b, 0x00 },
>>   };
>> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
>> index 59c578f865aa..bdb588b1d8fb 100644
>> --- a/arch/powerpc/kernel/kgdb.c
>> +++ b/arch/powerpc/kernel/kgdb.c
>> @@ -477,7 +477,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
>>   /*
>>    * Global data
>>    */
>> -struct kgdb_arch arch_kgdb_ops;
>> +const struct kgdb_arch arch_kgdb_ops;
>>   
>>   static int kgdb_not_implemented(struct pt_regs *regs)
>>   {
>> diff --git a/arch/sh/kernel/kgdb.c b/arch/sh/kernel/kgdb.c
>> index 4f04c6638a4d..a24c48446e98 100644
>> --- a/arch/sh/kernel/kgdb.c
>> +++ b/arch/sh/kernel/kgdb.c
>> @@ -382,7 +382,7 @@ void kgdb_arch_exit(void)
>>   	unregister_die_notifier(&kgdb_notifier);
>>   }
>>   
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   	/* Breakpoint instruction: trapa #0x3c */
>>   #ifdef CONFIG_CPU_LITTLE_ENDIAN
>>   	.gdb_bpt_instr		= { 0x3c, 0xc3 },
>> diff --git a/arch/sparc/kernel/kgdb_32.c b/arch/sparc/kernel/kgdb_32.c
>> index 639c8e54530a..7580775a14b9 100644
>> --- a/arch/sparc/kernel/kgdb_32.c
>> +++ b/arch/sparc/kernel/kgdb_32.c
>> @@ -166,7 +166,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long ip)
>>   	regs->npc = regs->pc + 4;
>>   }
>>   
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   	/* Breakpoint instruction: ta 0x7d */
>>   	.gdb_bpt_instr		= { 0x91, 0xd0, 0x20, 0x7d },
>>   };
>> diff --git a/arch/sparc/kernel/kgdb_64.c b/arch/sparc/kernel/kgdb_64.c
>> index a68bbddbdba4..5d6c2d287e85 100644
>> --- a/arch/sparc/kernel/kgdb_64.c
>> +++ b/arch/sparc/kernel/kgdb_64.c
>> @@ -195,7 +195,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long ip)
>>   	regs->tnpc = regs->tpc + 4;
>>   }
>>   
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   	/* Breakpoint instruction: ta 0x72 */
>>   	.gdb_bpt_instr		= { 0x91, 0xd0, 0x20, 0x72 },
>>   };
>> diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
>> index 8e36f249646e..e7effc02f13c 100644
>> --- a/arch/x86/kernel/kgdb.c
>> +++ b/arch/x86/kernel/kgdb.c
>> @@ -804,7 +804,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
>>   				  (char *)bpt->saved_instr, BREAK_INSTR_SIZE);
>>   }
>>   
>> -struct kgdb_arch arch_kgdb_ops = {
>> +const struct kgdb_arch arch_kgdb_ops = {
>>   	/* Breakpoint instruction: */
>>   	.gdb_bpt_instr		= { 0xcc },
>>   	.flags			= KGDB_HW_BREAKPOINT,
>> diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
>> index e465bb15912d..3bf313311cca 100644
>> --- a/include/linux/kgdb.h
>> +++ b/include/linux/kgdb.h
>> @@ -281,7 +281,7 @@ struct kgdb_io {
>>   	int			is_console;
>>   };
>>   
>> -extern struct kgdb_arch		arch_kgdb_ops;
>> +extern const struct kgdb_arch		arch_kgdb_ops;
>>   
>>   extern unsigned long kgdb_arch_pc(int exception, struct pt_regs *regs);
>>   
>> -- 
>> 2.13.3
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: Moving ARM dts files
From: Tom Rini @ 2018-12-06 20:14 UTC (permalink / raw)
  To: Rob Herring
  Cc: Andrew Lunn, Alexandre Belloni, Tony Lindgren, Linus Walleij,
	Liviu Dudau, Michal Simek, Masahiro Yamada, Thierry Reding,
	Florian Fainelli, Kevin Hilman, Gregory CLEMENT, Alexander Graf,
	Krzysztof Kozlowski, ARM-SoC Maintainers, Joel Stanley,
	Andy Gross, devicetree, Architecture Mailman List, Jason Cooper,
	Simon Horman,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	Grant Likely, Maxime Coquelin, Shawn Guo, Andreas Färber,
	Daniel Mack
In-Reply-To: <CAL_JsqL4WoMqFCQ0vFd6z_i=9imnfVsQjeKOG8zxNwi5caneRQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 6547 bytes --]

On Thu, Dec 06, 2018 at 01:06:43PM -0600, Rob Herring wrote:
> On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber <afaerber@suse.de> wrote:
> >
> > Am 05.12.18 um 05:17 schrieb Rob Herring:
> > > On Tue, Dec 4, 2018 at 7:22 PM Andreas Färber <afaerber@suse.de> wrote:
> > >>
> > >> Rob,
> > >>
> > >> Am 04.12.18 um 19:36 schrieb Rob Herring:
> > >>> I've put together a script to move the dts files and update the
> > >>> makefiles. It doesn't handle files not following a common prefix which
> > >>> isn't many and some includes within the dts files will need some fixups
> > >>> by hand.
> > >>>
> > >>> MAINTAINERS will also need updating.
> > >>>
> > >>> A few questions:
> > >>>
> > >>> Do we want to move absolutely everything to subdirs?
> > >>
> > >> This refactoring is a terrible idea!
> > >
> > > How do you really feel?
> > >
> > >> While it would've been nice to have more structure from the start,
> > >> bootloaders like U-Boot expect a flat structure for arm .dtb files now.
> > >> If you start installing them into subdirs instead, they won't find the
> > >> files anymore under the hardcoded name.
> > >>
> > >> Doing this only for new platforms would be much less invasive and allow
> > >> to prepare bootloaders accordingly.
> > >
> > > That was my suggestion where this started for the new RDA platform.
> > > Olof preferred to move everything and that's my desire too.
> > >
> > >> Alternatively, white-list which ones
> > >> are safe to move around.
> > >
> > > I'd prefer to know which ones the distros don't want moved. That
> > > should be easier to figure out. We also need that anyways in context
> > > of what platforms we care about compatibility.
> > >
> > > Another option is dtbs_install target could flatten the installed
> > > dtbs. That is the only part the distros should depend on.
> >
> > I'd be okay with distinguishing source vs. install location. Due to the
> > issue I mention below (and more) we can't use install_dtbs for openSUSE
> > and had to reimplement it, which we'd need to (and can) adjust.
> 
> What would be needed for dtbs_install to work? arm64 needs to support
> a flat install? If it doesn't work for Debian or openSUSE, I'm not
> sure why we have it. So I'd like to make it work.
> 
> > >> But don't just script a refactoring because it
> > >> looks nicer in the source tree, without testing what side effects this
> > >> can have for board/distro users of the compiled files in practice.
> > >> We already had that discussion for arm64 because Debian chose to ignore
> > >> the kernel-installed subdirectories and installed .dtb files into a flat
> > >> directory, which collided with openSUSE sticking to the kernel choice.
> > >
> > > So everyone already deals with subdirs or not with arm and arm64
> > > already, seems like they can deal with this. I will raise the topic on
> > > the cross-distro list though.
> >
> > Sounds like you're twisting words... The keyword was "hardcoded" paths -
> > one way or another (not "and") depending on the kernel choices being
> > flat for arm, vendor subdir for arm64.
> >
> > >> This topic becomes even more important with EBBR: There is neither a
> > >> mechanism in place to sync .dts files into U-Boot or EDK2 source trees,
> > >> nor are capsule updates implemented in U-Boot for easily deploying such
> > >> bootloaders with new .dts sources or paths yet.
> > >
> > > EBBR actually says firmware (including dtbs) goes in directories named
> > > by vendor.
> >
> > Fine, but unrelated.
> 
> If the distros want dtbs in a flat dir and EBBR says otherwise, then
> it is related.
> 
> > >> And I can assure you
> > >> that just getting users to dd the right bootloader can be difficult...
> > >> Since DT forward and backward compatibility is often being neglected,
> > >> for example with optional properties or renamed compatibles that break
> > >> booting with previous drivers, new kernel versions often need updated
> > >> Device Trees to make use of new/enhanced drivers. Therefore it is
> > >> unfortunately often enough a necessity to load newer kernel-based .dtb
> > >> files matching the kernel (as opposed to the dream of kernel-independent
> > >> hardware descriptions) when working with the latest -rc or -next kernels
> > >> at least. For examples of DTs needing updates, look no further than
> > >> Linaro's 96boards - in case of hikey960/EDK2 GRUB is another layer where
> > >> .dtb paths may be hardcoded, ditto for arm; and Armada was an example
> > >> where the upstream bindings for the network IP changed incompatibly.
> > >
> > > Compatibility is an issue, yes, but that really has nothing to do with this.
> > >
> > >> DT overlays are another topic that is not making any progress upstream
> > >> according to the ELCE BoF, so beyond the Raspberry Pi the only known
> > >> working way to apply them is to write a U-Boot boot.scr script, which
> > >> can either reuse $fdtcontroladdr DT or use the filename $fdtfile or
> > >> hardcode one, the latter two of which would break with your renaming.
> > >
> > > DT overlays also have nothing to do with this as there aren't any in
> > > the kernel. I'm not inclined to take any either with a flat tree.
> > > We're already at 1800+ files.
> >
> > Read again: a) Breaking DT changes and b) the desire to use Overlays
> > instead of replacing the bootloaders for each change are _reasons_ why
> > people depend on .dtb filenames from the kernel source tree for their
> > boot flow today. Nothing to do with downstream .dtbo files.
> >
> > For example, remember when I reported that the kernel didn't compile DTs
> > with -@? No reaction except for Frank asking to be CC'ed - was it ever
> > fixed??? Do EDK2's or U-Boot's built-in DTs compile with -@ today?
> 
> IIRC, Frank objected to changing this globally because it will bloat
> all dtbs. And then no one did the work to make it a per dtb option.
> Maybe that was the same issue in another thread.

Being the author of one of the patches to pass in -@ so we could have
overlays work out of the box, no, there was some other problem with
making it only happen for some sub-set of DTBs.  AFAIK the current
answer is the one of a few years ago that no, if you want symbols for
overlays to work you pass in ..whatever it is.. so that -@ is passed in.
In the end it felt like there was more concern over the core concept
than anything else and I moved along due to other pressing concerns.

-- 
Tom

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 1/2] mips/kgdb: prepare arch_kgdb_ops for constness
From: Christophe LEROY @ 2018-12-06 20:14 UTC (permalink / raw)
  To: Daniel Thompson
  Cc: Rich Felker, Gustavo A. R. Silva, Benjamin Herrenschmidt,
	Will Deacon, linux-kernel, Paul Mackerras, sparclinux,
	linux-hexagon, Yoshinori Sato, linux-sh, Michael Ellerman, x86,
	Russell King, Ingo Molnar, Catalin Marinas, James Hogan,
	linux-snps-arc, uclinux-h8-devel, linux-mips, Borislav Petkov,
	nios2-dev, Thomas Gleixner, linux-arm-kernel, Michal Simek,
	Vineet Gupta, Randy Dunlap, Douglas Anderson, Ralf Baechle,
	Richard Kuo, Paul Burton, Jason Wessel, kgdb-bugreport,
	Ley Foon Tan, linuxppc-dev, David S. Miller
In-Reply-To: <20181206140902.ea6jlwqrbcwyxp5r@holly.lan>



Le 06/12/2018 à 15:09, Daniel Thompson a écrit :
> On Wed, Dec 05, 2018 at 04:41:09AM +0000, Christophe Leroy wrote:
>> MIPS is the only architecture modifying arch_kgdb_ops during init.
>> This patch makes the init static, so that it can be changed to
>> const in following patch, as recommended by checkpatch.pl
>>
>> Suggested-by: Paul Burton <paul.burton@mips.com>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> 
>  From my side this is
> Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
> 
> Since this is a dependency for the next patch I'd be happy to take via
> my tree... but would need an ack from the MIPS guys to do that.

Got an ack from MIPS:
Acked-by: Paul Burton <paul.burton@mips.com>

Included in commit text v2

Christophe

> 
> 
> Daniel.
> 
>> ---
>>   arch/mips/kernel/kgdb.c | 16 +++++++---------
>>   1 file changed, 7 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
>> index eb6c0d582626..31eff1bec577 100644
>> --- a/arch/mips/kernel/kgdb.c
>> +++ b/arch/mips/kernel/kgdb.c
>> @@ -394,18 +394,16 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
>>   	return -1;
>>   }
>>   
>> -struct kgdb_arch arch_kgdb_ops;
>> +struct kgdb_arch arch_kgdb_ops = {
>> +#ifdef CONFIG_CPU_BIG_ENDIAN
>> +	.gdb_bpt_instr = { spec_op << 2, 0x00, 0x00, break_op },
>> +#else
>> +	.gdb_bpt_instr = { break_op, 0x00, 0x00, spec_op << 2 },
>> +#endif
>> +};
>>   
>>   int kgdb_arch_init(void)
>>   {
>> -	union mips_instruction insn = {
>> -		.r_format = {
>> -			.opcode = spec_op,
>> -			.func	= break_op,
>> -		}
>> -	};
>> -	memcpy(arch_kgdb_ops.gdb_bpt_instr, insn.byte, BREAK_INSTR_SIZE);
>> -
>>   	register_die_notifier(&kgdb_notifier);
>>   
>>   	return 0;
>> -- 
>> 2.13.3
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2 2/2] kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops
From: Christophe Leroy @ 2018-12-06 20:07 UTC (permalink / raw)
  To: Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
	Yoshinori Sato, Richard Kuo, Michal Simek, Ralf Baechle,
	Paul Burton, James Hogan, Ley Foon Tan, Benjamin Herrenschmidt,
	Paul Mackerras, Michael Ellerman, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86, Jason Wessel,
	Daniel Thompson, GitAuthor: Christophe Leroy, Douglas Anderson,
	Randy Dunlap, Gustavo A. R. Silva
  Cc: uclinux-h8-devel, linux-sh, linux-hexagon, linux-kernel,
	linux-mips, kgdb-bugreport, sparclinux, nios2-dev, linux-snps-arc,
	linuxppc-dev, linux-arm-kernel
In-Reply-To: <030d63848e4b0ef4d76ca24597ab8302a393d692.1544083483.git.christophe.leroy@c-s.fr>

checkpatch.pl reports the following:

  WARNING: struct kgdb_arch should normally be const
  #28: FILE: arch/mips/kernel/kgdb.c:397:
  +struct kgdb_arch arch_kgdb_ops = {

This report makes sense, as all other ops struct, this
one should also be const. This patch does the change.

Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Rich Felker <dalias@libc.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Paul Burton <paul.burton@mips.com>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
 v2: Added CCs to all maintainers/supporters identified by get_maintainer.pl and Acks from Daniel and Paul.

 arch/arc/kernel/kgdb.c        | 2 +-
 arch/arm/kernel/kgdb.c        | 2 +-
 arch/arm64/kernel/kgdb.c      | 2 +-
 arch/h8300/kernel/kgdb.c      | 2 +-
 arch/hexagon/kernel/kgdb.c    | 2 +-
 arch/microblaze/kernel/kgdb.c | 2 +-
 arch/mips/kernel/kgdb.c       | 2 +-
 arch/nios2/kernel/kgdb.c      | 2 +-
 arch/powerpc/kernel/kgdb.c    | 2 +-
 arch/sh/kernel/kgdb.c         | 2 +-
 arch/sparc/kernel/kgdb_32.c   | 2 +-
 arch/sparc/kernel/kgdb_64.c   | 2 +-
 arch/x86/kernel/kgdb.c        | 2 +-
 include/linux/kgdb.h          | 2 +-
 14 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 9a3c34af2ae8..bfd04b442e36 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -204,7 +204,7 @@ void kgdb_roundup_cpus(unsigned long flags)
 	local_irq_disable();
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 	/* breakpoint instruction: TRAP_S 0x3 */
 #ifdef CONFIG_CPU_BIG_ENDIAN
 	.gdb_bpt_instr		= {0x78, 0x7e},
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index caa0dbe3dc61..21a6d5958955 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -274,7 +274,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
  * and we handle the normal undef case within the do_undefinstr
  * handler.
  */
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 #ifndef __ARMEB__
 	.gdb_bpt_instr		= {0xfe, 0xde, 0xff, 0xe7}
 #else /* ! __ARMEB__ */
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index a20de58061a8..fe1d1f935b90 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -357,7 +357,7 @@ void kgdb_arch_exit(void)
 	unregister_die_notifier(&kgdb_notifier);
 }
 
-struct kgdb_arch arch_kgdb_ops;
+const struct kgdb_arch arch_kgdb_ops;
 
 int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
 {
diff --git a/arch/h8300/kernel/kgdb.c b/arch/h8300/kernel/kgdb.c
index 1a1d30cb0609..602e478afbd5 100644
--- a/arch/h8300/kernel/kgdb.c
+++ b/arch/h8300/kernel/kgdb.c
@@ -129,7 +129,7 @@ void kgdb_arch_exit(void)
 	/* Nothing to do */
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 	/* Breakpoint instruction: trapa #2 */
 	.gdb_bpt_instr = { 0x57, 0x20 },
 };
diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
index 16c24b22d0b2..f1924d483e78 100644
--- a/arch/hexagon/kernel/kgdb.c
+++ b/arch/hexagon/kernel/kgdb.c
@@ -83,7 +83,7 @@ struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
 	{ "syscall_nr", GDB_SIZEOF_REG, offsetof(struct pt_regs, syscall_nr)},
 };
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 	/* trap0(#0xDB) 0x0cdb0054 */
 	.gdb_bpt_instr = {0x54, 0x00, 0xdb, 0x0c},
 };
diff --git a/arch/microblaze/kernel/kgdb.c b/arch/microblaze/kernel/kgdb.c
index 6366f69d118e..130cd0f064ce 100644
--- a/arch/microblaze/kernel/kgdb.c
+++ b/arch/microblaze/kernel/kgdb.c
@@ -143,7 +143,7 @@ void kgdb_arch_exit(void)
 /*
  * Global data
  */
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 #ifdef __MICROBLAZEEL__
 	.gdb_bpt_instr = {0x18, 0x00, 0x0c, 0xba}, /* brki r16, 0x18 */
 #else
diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index 31eff1bec577..edfdc2ec2d16 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -394,7 +394,7 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
 	return -1;
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 #ifdef CONFIG_CPU_BIG_ENDIAN
 	.gdb_bpt_instr = { spec_op << 2, 0x00, 0x00, break_op },
 #else
diff --git a/arch/nios2/kernel/kgdb.c b/arch/nios2/kernel/kgdb.c
index 117859122d1c..37b25f844a2d 100644
--- a/arch/nios2/kernel/kgdb.c
+++ b/arch/nios2/kernel/kgdb.c
@@ -165,7 +165,7 @@ void kgdb_arch_exit(void)
 	/* Nothing to do */
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 	/* Breakpoint instruction: trap 30 */
 	.gdb_bpt_instr = { 0xba, 0x6f, 0x3b, 0x00 },
 };
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 59c578f865aa..bdb588b1d8fb 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -477,7 +477,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
 /*
  * Global data
  */
-struct kgdb_arch arch_kgdb_ops;
+const struct kgdb_arch arch_kgdb_ops;
 
 static int kgdb_not_implemented(struct pt_regs *regs)
 {
diff --git a/arch/sh/kernel/kgdb.c b/arch/sh/kernel/kgdb.c
index 4f04c6638a4d..a24c48446e98 100644
--- a/arch/sh/kernel/kgdb.c
+++ b/arch/sh/kernel/kgdb.c
@@ -382,7 +382,7 @@ void kgdb_arch_exit(void)
 	unregister_die_notifier(&kgdb_notifier);
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 	/* Breakpoint instruction: trapa #0x3c */
 #ifdef CONFIG_CPU_LITTLE_ENDIAN
 	.gdb_bpt_instr		= { 0x3c, 0xc3 },
diff --git a/arch/sparc/kernel/kgdb_32.c b/arch/sparc/kernel/kgdb_32.c
index 639c8e54530a..7580775a14b9 100644
--- a/arch/sparc/kernel/kgdb_32.c
+++ b/arch/sparc/kernel/kgdb_32.c
@@ -166,7 +166,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long ip)
 	regs->npc = regs->pc + 4;
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 	/* Breakpoint instruction: ta 0x7d */
 	.gdb_bpt_instr		= { 0x91, 0xd0, 0x20, 0x7d },
 };
diff --git a/arch/sparc/kernel/kgdb_64.c b/arch/sparc/kernel/kgdb_64.c
index a68bbddbdba4..5d6c2d287e85 100644
--- a/arch/sparc/kernel/kgdb_64.c
+++ b/arch/sparc/kernel/kgdb_64.c
@@ -195,7 +195,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long ip)
 	regs->tnpc = regs->tpc + 4;
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 	/* Breakpoint instruction: ta 0x72 */
 	.gdb_bpt_instr		= { 0x91, 0xd0, 0x20, 0x72 },
 };
diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index 8e36f249646e..e7effc02f13c 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -804,7 +804,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
 				  (char *)bpt->saved_instr, BREAK_INSTR_SIZE);
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 	/* Breakpoint instruction: */
 	.gdb_bpt_instr		= { 0xcc },
 	.flags			= KGDB_HW_BREAKPOINT,
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index e465bb15912d..3bf313311cca 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -281,7 +281,7 @@ struct kgdb_io {
 	int			is_console;
 };
 
-extern struct kgdb_arch		arch_kgdb_ops;
+extern const struct kgdb_arch		arch_kgdb_ops;
 
 extern unsigned long kgdb_arch_pc(int exception, struct pt_regs *regs);
 
-- 
2.13.3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 1/2] mips/kgdb: prepare arch_kgdb_ops for constness
From: Christophe Leroy @ 2018-12-06 20:07 UTC (permalink / raw)
  To: Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
	Yoshinori Sato, Richard Kuo, Michal Simek, Ralf Baechle,
	Paul Burton, James Hogan, Ley Foon Tan, Benjamin Herrenschmidt,
	Paul Mackerras, Michael Ellerman, Rich Felker, David S. Miller,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86, Jason Wessel,
	Daniel Thompson, GitAuthor: Christophe Leroy, Douglas Anderson,
	Randy Dunlap, Gustavo A. R. Silva
  Cc: uclinux-h8-devel, linux-sh, linux-hexagon, linux-kernel,
	linux-mips, kgdb-bugreport, sparclinux, nios2-dev, linux-snps-arc,
	linuxppc-dev, linux-arm-kernel

MIPS is the only architecture modifying arch_kgdb_ops during init.
This patch makes the init static, so that it can be changed to
const in following patch, as recommended by checkpatch.pl

Suggested-by: Paul Burton <paul.burton@mips.com>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Paul Burton <paul.burton@mips.com>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
 v2: Added acks from Daniel and Paul.

 arch/mips/kernel/kgdb.c | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index eb6c0d582626..31eff1bec577 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -394,18 +394,16 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
 	return -1;
 }
 
-struct kgdb_arch arch_kgdb_ops;
+struct kgdb_arch arch_kgdb_ops = {
+#ifdef CONFIG_CPU_BIG_ENDIAN
+	.gdb_bpt_instr = { spec_op << 2, 0x00, 0x00, break_op },
+#else
+	.gdb_bpt_instr = { break_op, 0x00, 0x00, spec_op << 2 },
+#endif
+};
 
 int kgdb_arch_init(void)
 {
-	union mips_instruction insn = {
-		.r_format = {
-			.opcode = spec_op,
-			.func	= break_op,
-		}
-	};
-	memcpy(arch_kgdb_ops.gdb_bpt_instr, insn.byte, BREAK_INSTR_SIZE);
-
 	register_die_notifier(&kgdb_notifier);
 
 	return 0;
-- 
2.13.3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: Moving ARM dts files
From: Mark Brown @ 2018-12-06 20:06 UTC (permalink / raw)
  To: Rob Herring
  Cc: Andrew Lunn, Alexandre Belloni, Tony Lindgren, Linus Walleij,
	Liviu Dudau, Michal Simek, Masahiro Yamada, Thierry Reding,
	Tom Rini, Florian Fainelli, Kevin Hilman, Gregory CLEMENT,
	Alexander Graf, Krzysztof Kozlowski, ARM-SoC Maintainers,
	Joel Stanley, Andy Gross, devicetree, Architecture Mailman List,
	Jason Cooper, Simon Horman,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	Grant Likely, Maxime Coquelin, Shawn Guo, Andreas Färber,
	Daniel Mack
In-Reply-To: <CAL_JsqL4WoMqFCQ0vFd6z_i=9imnfVsQjeKOG8zxNwi5caneRQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1279 bytes --]

On Thu, Dec 06, 2018 at 01:06:43PM -0600, Rob Herring wrote:
> On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber <afaerber@suse.de> wrote:

> > I'd be okay with distinguishing source vs. install location. Due to the
> > issue I mention below (and more) we can't use install_dtbs for openSUSE
> > and had to reimplement it, which we'd need to (and can) adjust.

> What would be needed for dtbs_install to work? arm64 needs to support
> a flat install? If it doesn't work for Debian or openSUSE, I'm not
> sure why we have it. So I'd like to make it work.

Correct me if I'm wrong but as far as the flat vs directory thing goes
isn't the issue that this winds up being a rename for an existing 32 bit
system?  If you just install the dtbs in the default location then a
bootloader or whatever that is hard coded to look for foo-bar.dtb won't
see the new foo/foo-bar.dtb (or whatever) and will continue to use the
old binary.  It's not the fact that that it's in a directory, it's the
fact that the bootloader sees the name it needs to look for change (if
it's looking on a filesystem at all).  This isn't a problem for arm64 as
the location isn't changing, it's used directories from day one.

The issues with the existing install_dtbs sounded unrelated to this.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 02/11] thermal: add irq-mode configuration for trip point
From: Lukasz Luba @ 2018-12-06 19:55 UTC (permalink / raw)
  To: Zhang Rui, devicetree, linux-arm-kernel, linux-doc, linux-kernel,
	linux-pm
  Cc: mark.rutland, corbet, b.zolnierkie, daniel.lezcano, krzk,
	edubezval, robh+dt
In-Reply-To: <2ac425fc-7c32-6e2f-7086-c14f85b0bbfd@partner.samsung.com>



On 12/6/18 8:18 PM, Lukasz Luba wrote:
> Hi Rui,
> 
> On 12/5/18 4:09 PM, Zhang Rui wrote:
>> On 三, 2018-11-07 at 18:09 +0100, Lukasz Luba wrote:
>>> This patch adds support irq mode in trip point.
>>> When that flag is set in DT, there is no need for polling
>>> in thermal framework. Crossing the trip point will rise an IRQ.
>>> The naming convention for tip point 'type' can be confussing
>>> and 'passive' (whic is passive cooling) might be interpretted
>>> wrongly.
>>>
>>> This mechanism prevents from missue and adds explicit setting
>>> for hardware which support interrupts for pre-configured temperature
>>> threshold.
>>>
>>> Cc: Zhang Rui <rui.zhang@intel.com>
>>> Cc: Eduardo Valentin <edubezval@gmail.com>
>>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>>> ---
>>>   drivers/thermal/of-thermal.c   | 17 +++++++++++++++++
>>>   drivers/thermal/thermal_core.c | 10 ++++++++--
>>>   include/linux/thermal.h        |  5 +++++
>>>   3 files changed, 30 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-
>>> thermal.c
>>> index 4bfdb4a..1a75946a 100644
>>> --- a/drivers/thermal/of-thermal.c
>>> +++ b/drivers/thermal/of-thermal.c
>>> @@ -312,6 +312,20 @@ static int of_thermal_get_trip_type(struct
>>> thermal_zone_device *tz, int trip,
>>>       return 0;
>>>   }
>>> +static int
>>> +of_thermal_get_trip_irq_mode(struct thermal_zone_device *tz, int
>>> trip,
>>> +                 bool *mode)
>>> +{
>>> +    struct __thermal_zone *data = tz->devdata;
>>> +
>>> +    if (trip >= data->ntrips || trip < 0)
>>> +        return -EDOM;
>>> +
>>> +    *mode = data->trips[trip].irq_mode;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>   static int of_thermal_get_trip_temp(struct thermal_zone_device *tz,
>>> int trip,
>>>                       int *temp)
>>>   {
>>> @@ -394,6 +408,7 @@ static struct thermal_zone_device_ops
>>> of_thermal_ops = {
>>>       .set_mode = of_thermal_set_mode,
>>>       .get_trip_type = of_thermal_get_trip_type,
>>> +    .get_trip_irq_mode = of_thermal_get_trip_irq_mode,
>>>       .get_trip_temp = of_thermal_get_trip_temp,
>>>       .set_trip_temp = of_thermal_set_trip_temp,
>>>       .get_trip_hyst = of_thermal_get_trip_hyst,
>>> @@ -827,6 +842,8 @@ static int thermal_of_populate_trip(struct
>>> device_node *np,
>>>           return ret;
>>>       }
>>> +    trip->irq_mode = of_property_read_bool(np, "irq-mode");
>>> +
>>>       /* Required for cooling map matching */
>>>       trip->np = np;
>>>       of_node_get(np);
>>> diff --git a/drivers/thermal/thermal_core.c
>>> b/drivers/thermal/thermal_core.c
>>> index 39fc812..6d41e08 100644
>>> --- a/drivers/thermal/thermal_core.c
>>> +++ b/drivers/thermal/thermal_core.c
>>> @@ -406,6 +406,7 @@ static void handle_critical_trips(struct
>>> thermal_zone_device *tz,
>>>   static void handle_thermal_trip(struct thermal_zone_device *tz, int
>>> trip)
>>>   {
>>>       enum thermal_trip_type type;
>>> +    bool irq_mode = false;
>>>       /* Ignore disabled trip points */
>>>       if (test_bit(trip, &tz->trips_disabled))
>>> @@ -419,9 +420,14 @@ static void handle_thermal_trip(struct
>>> thermal_zone_device *tz, int trip)
>>>           handle_non_critical_trips(tz, trip);
>>>       /*
>>>        * Alright, we handled this trip successfully.
>>> -     * So, start monitoring again.
>>> +     * So, start monitoring in polling mode if
>>> +     * trip is not using irq HW support.
>>>        */
>>> -    monitor_thermal_zone(tz);
>>> +    if (tz->ops->get_trip_irq_mode)
>>> +        tz->ops->get_trip_irq_mode(tz, trip, &irq_mode);
>>> +
>>> +    if (!irq_mode)
>>> +        monitor_thermal_zone(tz);
>>>   }
>> handle_thermal_trip() is called from thermal_zone_device_update(), and
>> it is invoked for every trip points.
>> say, you have a passive trip point 1 that supports irq_mode, and
>> another passive trip point 2 that does not support irq_mode,
>> monitor_thermal_zone() is still called in handle_thermal_trip(tz, 2),
>> and the passive timer will be activated anyway, do I miss something?
> Yes, the passive timer will be activated in your example. It is correct
> behavior and does not break anything.
> case 1: there is 'k' passive trip points which have irq_mode and 1
> additional which does not have 'irq_mode', the framework will start
> polling but skip check for those 'k' trip points.
> case 2: all of the passive trip points have irq_mode set, the framework
> will not register 'scheduled_work' because it will not call 
> 'monitor_thermal_zone()'.
> This is the case of most Exynos platforms, but there is one exception 
> which has 'case 1' with 2 trip points not supporting irq_mode.
Do you suggest to cover the 'case 1'?
It would be possible after adding a new enum THERMAL_FRAMEWORK_POLL, 
then function:
thermal_zone_device_check() will call
thermal_zone_device_update(tz, THERMAL_FRAMEWORK_POLL)
and in handle_thermal_trip() implement something like:
--------------8<----------------
static void handle_thermal_trip(struct thermal_zone_device *tz, int trip)
{
	enum thermal_trip_type type;
	bool irq_mode = false;

	/* Ignore disabled trip points */
	if (test_bit(trip, &tz->trips_disabled))
		return;

	if (tz->ops->get_trip_irq_mode)
		tz->ops->get_trip_irq_mode(tz, trip, &irq_mode)

	if (tz->notify_event == THERMAL_FRAMEWORK_POLL && irq_mode)
		return;
...

	if (!irq_mode)
		monitor_thermal_zone(tz);
}

---------->8-----------------------

I could implement it in v3 if you don't see that it add too much of mess 
and agree for this approach.

Regards,
Lukasz

> 
> Regards,
> Lukasz
> 
>>
>> thanks,
>> rui
>>
>>>   static void update_temperature(struct thermal_zone_device *tz)
>>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>>> index 5f4705f..b064565 100644
>>> --- a/include/linux/thermal.h
>>> +++ b/include/linux/thermal.h
>>> @@ -103,6 +103,7 @@ struct thermal_zone_device_ops {
>>>           enum thermal_device_mode);
>>>       int (*get_trip_type) (struct thermal_zone_device *, int,
>>>           enum thermal_trip_type *);
>>> +    int (*get_trip_irq_mode) (struct thermal_zone_device *, int,
>>> bool *);
>>>       int (*get_trip_temp) (struct thermal_zone_device *, int, int
>>> *);
>>>       int (*set_trip_temp) (struct thermal_zone_device *, int,
>>> int);
>>>       int (*get_trip_hyst) (struct thermal_zone_device *, int, int
>>> *);
>>> @@ -196,6 +197,7 @@ struct thermal_zone_device {
>>>       struct thermal_attr *trip_temp_attrs;
>>>       struct thermal_attr *trip_type_attrs;
>>>       struct thermal_attr *trip_hyst_attrs;
>>> +    struct thermal_attr *trip_irq_mode_attrs;
>>>       void *devdata;
>>>       int trips;
>>>       unsigned long trips_disabled;    /* bitmap for disabled
>>> trips */
>>> @@ -364,6 +366,8 @@ struct thermal_zone_of_device_ops {
>>>    * @temperature: temperature value in miliCelsius
>>>    * @hysteresis: relative hysteresis in miliCelsius
>>>    * @type: trip point type
>>> + * @irq_mode: to not use polling in framework set support of HW irq
>>> (which will
>>> + *          be triggered when temperature reaches this level).
>>>    */
>>>   struct thermal_trip {
>>> @@ -371,6 +375,7 @@ struct thermal_trip {
>>>       int temperature;
>>>       int hysteresis;
>>>       enum thermal_trip_type type;
>>> +    bool irq_mode;
>>>   };
>>>   /* Function declarations */
>>
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 26/34] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema
From: Rob Herring @ 2018-12-06 19:38 UTC (permalink / raw)
  To: Simon Horman
  Cc: Mark Rutland, devicetree, Kumar Gala, Grant Likely, Sean Hudson,
	linuxppc-dev, Magnus Damm, linux-kernel@vger.kernel.org,
	open list:MEDIA DRIVERS FOR RENESAS - FCP, ARM-SoC Maintainers,
	Geert Uytterhoeven, Frank Rowand,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20181205194419.p6u56h57yk63xshj@verge.net.au>

On Wed, Dec 5, 2018 at 1:44 PM Simon Horman <horms@verge.net.au> wrote:
>
> On Tue, Dec 04, 2018 at 09:08:57AM -0600, Rob Herring wrote:
> > On Tue, Dec 4, 2018 at 8:57 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Tue, Dec 4, 2018 at 3:48 PM Simon Horman <horms@verge.net.au> wrote:
> > > > On Mon, Dec 03, 2018 at 03:32:15PM -0600, Rob Herring wrote:
> > > > > Convert Renesas SoC bindings to DT schema format using json-schema.
> > > > >
> > > > > Cc: Simon Horman <horms@verge.net.au>
> > > > > Cc: Magnus Damm <magnus.damm@gmail.com>
> > > > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > > > Cc: linux-renesas-soc@vger.kernel.org
> > > > > Cc: devicetree@vger.kernel.org
> > > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > > > ---
> > > > >  .../devicetree/bindings/arm/shmobile.txt      | 151 ------------
> > > > >  .../devicetree/bindings/arm/shmobile.yaml     | 218 ++++++++++++++++++
> > > > >  2 files changed, 218 insertions(+), 151 deletions(-)
> > > > >  delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt
> > > > >  create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml
> > > >
> > > > Hi Rob,
> > > >
> > > > what is this based on? I get a conflict when applying the .txt change
> > > > and if I knew the base for this patch it would be rather easy to work
> > > > out what has changed.
> >
> > 4.20-rc2
> >
> > > >
> > > > Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS?
> >
> > Yes. Though it was pointed out that get_maintainers.pl can pull emails
> > out of this file. We'd need to get that to work by default though.
> >
> > > Probably even s/shmobile.yaml/renesas.yaml/, while at it?
> >
> > Sure, if that's what you all want.
>
> How about this?

LGTM

> From: Rob Herring <robh@kernel.org>
> Subject: [PATCH v2.1] dt-bindings: arm: Convert Renesas board/soc bindings to
>  json-schema
>
> Convert Renesas SoC bindings to DT schema format using json-schema.
>
> v2.1 [Simon Horman]
> - rebased on renesas-devel-20181204-v4.20-rc5
>   + Added r8a7744 development platform and SoM
>   + Correct RZ/G2E part number
> - Update MAINTAINERS
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  Documentation/devicetree/bindings/arm/renesas.yaml | 228 +++++++++++++++++++++
>  Documentation/devicetree/bindings/arm/shmobile.txt | 155 --------------
>  MAINTAINERS                                        |   4 +-
>  3 files changed, 230 insertions(+), 157 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/renesas.yaml
>  delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2] media: Use of_node_name_eq for node name comparisons
From: Rob Herring @ 2018-12-06 19:35 UTC (permalink / raw)
  To: devicetree, linux-kernel
  Cc: linux-samsung-soc, Hyun Kwon, Michal Simek, Krzysztof Kozlowski,
	Benoit Parrot, Kyungmin Park, Kukjin Kim, Laurent Pinchart,
	Sylwester Nawrocki, Mauro Carvalho Chehab, linux-arm-kernel,
	linux-media

Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.

Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Hyun Kwon <hyun.kwon@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: linux-media@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
v2:
- Also convert tabs to spaces between the 'if' and '('

 drivers/media/platform/exynos4-is/media-dev.c | 12 ++++++------
 drivers/media/platform/ti-vpe/cal.c           |  4 ++--
 drivers/media/platform/xilinx/xilinx-tpg.c    |  2 +-
 drivers/media/v4l2-core/v4l2-fwnode.c         |  6 ++----
 4 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
index 870501b0f351..463f2d84553e 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -445,7 +445,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
 	 */
 	np = of_get_parent(rem);
 
-	if (np && !of_node_cmp(np->name, "i2c-isp"))
+	if (of_node_name_eq(np, "i2c-isp"))
 		pd->fimc_bus_type = FIMC_BUS_TYPE_ISP_WRITEBACK;
 	else
 		pd->fimc_bus_type = pd->sensor_bus_type;
@@ -495,7 +495,7 @@ static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
 	for_each_available_child_of_node(parent, node) {
 		struct device_node *port;
 
-		if (of_node_cmp(node->name, "csis"))
+		if (!of_node_name_eq(node, "csis"))
 			continue;
 		/* The csis node can have only port subnode. */
 		port = of_get_next_child(node, NULL);
@@ -720,13 +720,13 @@ static int fimc_md_register_platform_entities(struct fimc_md *fmd,
 			continue;
 
 		/* If driver of any entity isn't ready try all again later. */
-		if (!strcmp(node->name, CSIS_OF_NODE_NAME))
+		if (of_node_name_eq(node, CSIS_OF_NODE_NAME))
 			plat_entity = IDX_CSIS;
-		else if	(!strcmp(node->name, FIMC_IS_OF_NODE_NAME))
+		else if (of_node_name_eq(node, FIMC_IS_OF_NODE_NAME))
 			plat_entity = IDX_IS_ISP;
-		else if (!strcmp(node->name, FIMC_LITE_OF_NODE_NAME))
+		else if (of_node_name_eq(node, FIMC_LITE_OF_NODE_NAME))
 			plat_entity = IDX_FLITE;
-		else if	(!strcmp(node->name, FIMC_OF_NODE_NAME) &&
+		else if (of_node_name_eq(node, FIMC_OF_NODE_NAME) &&
 			 !of_property_read_bool(node, "samsung,lcd-wb"))
 			plat_entity = IDX_FIMC;
 
diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c
index 95a093f41905..fc3c212b96e1 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -1615,7 +1615,7 @@ of_get_next_port(const struct device_node *parent,
 				return NULL;
 			}
 			prev = port;
-		} while (of_node_cmp(port->name, "port") != 0);
+		} while (!of_node_name_eq(port, "port"));
 	}
 
 	return port;
@@ -1635,7 +1635,7 @@ of_get_next_endpoint(const struct device_node *parent,
 		if (!ep)
 			return NULL;
 		prev = ep;
-	} while (of_node_cmp(ep->name, "endpoint") != 0);
+	} while (!of_node_name_eq(ep, "endpoint"));
 
 	return ep;
 }
diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c b/drivers/media/platform/xilinx/xilinx-tpg.c
index 851d20dcd550..ce686b8d6cff 100644
--- a/drivers/media/platform/xilinx/xilinx-tpg.c
+++ b/drivers/media/platform/xilinx/xilinx-tpg.c
@@ -725,7 +725,7 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
 		const struct xvip_video_format *format;
 		struct device_node *endpoint;
 
-		if (!port->name || of_node_cmp(port->name, "port"))
+		if (!of_node_name_eq(port, "port"))
 			continue;
 
 		format = xvip_of_get_format(port);
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c
index 218f0da0ce76..849326241b17 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -564,8 +564,7 @@ int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,
 	fwnode = fwnode_get_parent(__fwnode);
 	fwnode_property_read_u32(fwnode, port_prop, &link->local_port);
 	fwnode = fwnode_get_next_parent(fwnode);
-	if (is_of_node(fwnode) &&
-	    of_node_cmp(to_of_node(fwnode)->name, "ports") == 0)
+	if (is_of_node(fwnode) && of_node_name_eq(to_of_node(fwnode), "ports"))
 		fwnode = fwnode_get_next_parent(fwnode);
 	link->local_node = fwnode;
 
@@ -578,8 +577,7 @@ int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,
 	fwnode = fwnode_get_parent(fwnode);
 	fwnode_property_read_u32(fwnode, port_prop, &link->remote_port);
 	fwnode = fwnode_get_next_parent(fwnode);
-	if (is_of_node(fwnode) &&
-	    of_node_cmp(to_of_node(fwnode)->name, "ports") == 0)
+	if (is_of_node(fwnode) && of_node_name_eq(to_of_node(fwnode), "ports"))
 		fwnode = fwnode_get_next_parent(fwnode);
 	link->remote_node = fwnode;
 
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH] ARM: dts: imx6ul: Remove extra space between node name and {
From: Leonard Crestez @ 2018-12-06 19:22 UTC (permalink / raw)
  To: Shawn Guo, Fabio Estevam, Lothar Waßmann
  Cc: Aisheng Dong, kernel@pengutronix.de, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, dl-linux-imx

Fixes: 7d1cd2978664 ("ARM: dts: imx6ul: add gpmi support")

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm/boot/dts/imx6ul.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 083d3446c41d..93ca2405ac8c 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -183,11 +183,11 @@
 			#dma-cells = <1>;
 			dma-channels = <4>;
 			clocks = <&clks IMX6UL_CLK_APBHDMA>;
 		};
 
-		gpmi: gpmi-nand@1806000         {
+		gpmi: gpmi-nand@1806000 {
 			compatible = "fsl,imx6q-gpmi-nand";
 			#address-cells = <1>;
 			#size-cells = <1>;
 			reg = <0x01806000 0x2000>, <0x01808000 0x2000>;
 			reg-names = "gpmi-nand", "bch";
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH v5 2/4] arm64: KVM: add accessors to track guest/host only counters
From: Andrew Murray @ 2018-12-06 19:21 UTC (permalink / raw)
  To: Suzuki K Poulose
  Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Catalin Marinas,
	Will Deacon, Christoffer Dall, kvmarm, linux-arm-kernel
In-Reply-To: <fefadc01-05dd-f714-667e-71c3589083e7@arm.com>

On Thu, Dec 06, 2018 at 06:51:37PM +0000, Suzuki K Poulose wrote:
> 
> 
> On 06/12/2018 17:21, Suzuki K Poulose wrote:
> > Hi Andrew,
> > 
> > On 05/12/2018 15:30, Andrew Murray wrote:
> > > In order to effeciently enable/disable guest/host only perf counters
> > > at guest entry/exit we add bitfields to kvm_cpu_context for guest and
> > > host events as well as accessors for updating them.
> > > 
> > > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> > > ---
> > >    arch/arm64/include/asm/kvm_host.h | 24 ++++++++++++++++++++++++
> > >    1 file changed, 24 insertions(+)
> > > 
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index 1550192..800c87b 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -203,6 +203,8 @@ struct kvm_cpu_context {
> > >    	};
> > >    	struct kvm_vcpu *__hyp_running_vcpu;
> > > +	u32 events_host;
> > > +	u32 events_guest;
> > >    };
> > >    typedef struct kvm_cpu_context kvm_cpu_context_t;
> > > @@ -467,11 +469,33 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu);
> > >    void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu);
> > >    void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu);
> > > +#define KVM_PMU_EVENTS_HOST	1
> > > +#define KVM_PMU_EVENTS_GUEST	2
> > > +
> > >    #ifdef CONFIG_KVM /* Avoid conflicts with core headers if CONFIG_KVM=n */
> > >    static inline int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> > >    {
> > >    	return kvm_arch_vcpu_run_map_fp(vcpu);
> > >    }
> > > +static inline void kvm_set_pmu_events(u32 set, int flags)
> > > +{
> > > +	kvm_cpu_context_t *ctx = this_cpu_ptr(&kvm_host_cpu_state);
> > > +
> > > +	if (flags & KVM_PMU_EVENTS_HOST)
> > > +		ctx->events_host |= set;
> > > +	if (flags & KVM_PMU_EVENTS_GUEST)
> > > +		ctx->events_guest |= set;
> > 
> > You seem to be passing a single flag at a time ever, in the next patch.
> > Either we can batch the calls in the next patch, or make this a real number and
> > not a flag. g.g, enum { HOST,  GUEST } or even a bool.
> > 
> > I think the former sounds better.
> 
> Having another look at patch-3, we can never club set() calls for host &
> guest events, we should go for the latter.

Well we could always do this..

        u32 flags = 0;
        if (!attr->exclude_host)
                flags |= KVM_PMU_EVENTS_HOST;
        if (!attr->exclude_guest)
                flags |= KVM_PMU_EVENTS_GUEST;

        kvm_set_pmu_events(counter_bits, flags);

Thanks,

Andrew Murray

> 
> Suzuki
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 02/11] thermal: add irq-mode configuration for trip point
From: Lukasz Luba @ 2018-12-06 19:18 UTC (permalink / raw)
  To: Zhang Rui, devicetree, linux-arm-kernel, linux-doc, linux-kernel,
	linux-pm
  Cc: mark.rutland, corbet, b.zolnierkie, daniel.lezcano, krzk,
	edubezval, robh+dt
In-Reply-To: <1544022595.2841.45.camel@intel.com>

Hi Rui,

On 12/5/18 4:09 PM, Zhang Rui wrote:
> On 三, 2018-11-07 at 18:09 +0100, Lukasz Luba wrote:
>> This patch adds support irq mode in trip point.
>> When that flag is set in DT, there is no need for polling
>> in thermal framework. Crossing the trip point will rise an IRQ.
>> The naming convention for tip point 'type' can be confussing
>> and 'passive' (whic is passive cooling) might be interpretted
>> wrongly.
>>
>> This mechanism prevents from missue and adds explicit setting
>> for hardware which support interrupts for pre-configured temperature
>> threshold.
>>
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: Eduardo Valentin <edubezval@gmail.com>
>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>> ---
>>   drivers/thermal/of-thermal.c   | 17 +++++++++++++++++
>>   drivers/thermal/thermal_core.c | 10 ++++++++--
>>   include/linux/thermal.h        |  5 +++++
>>   3 files changed, 30 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-
>> thermal.c
>> index 4bfdb4a..1a75946a 100644
>> --- a/drivers/thermal/of-thermal.c
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -312,6 +312,20 @@ static int of_thermal_get_trip_type(struct
>> thermal_zone_device *tz, int trip,
>>   	return 0;
>>   }
>>   
>> +static int
>> +of_thermal_get_trip_irq_mode(struct thermal_zone_device *tz, int
>> trip,
>> +			     bool *mode)
>> +{
>> +	struct __thermal_zone *data = tz->devdata;
>> +
>> +	if (trip >= data->ntrips || trip < 0)
>> +		return -EDOM;
>> +
>> +	*mode = data->trips[trip].irq_mode;
>> +
>> +	return 0;
>> +}
>> +
>>   static int of_thermal_get_trip_temp(struct thermal_zone_device *tz,
>> int trip,
>>   				    int *temp)
>>   {
>> @@ -394,6 +408,7 @@ static struct thermal_zone_device_ops
>> of_thermal_ops = {
>>   	.set_mode = of_thermal_set_mode,
>>   
>>   	.get_trip_type = of_thermal_get_trip_type,
>> +	.get_trip_irq_mode = of_thermal_get_trip_irq_mode,
>>   	.get_trip_temp = of_thermal_get_trip_temp,
>>   	.set_trip_temp = of_thermal_set_trip_temp,
>>   	.get_trip_hyst = of_thermal_get_trip_hyst,
>> @@ -827,6 +842,8 @@ static int thermal_of_populate_trip(struct
>> device_node *np,
>>   		return ret;
>>   	}
>>   
>> +	trip->irq_mode = of_property_read_bool(np, "irq-mode");
>> +
>>   	/* Required for cooling map matching */
>>   	trip->np = np;
>>   	of_node_get(np);
>> diff --git a/drivers/thermal/thermal_core.c
>> b/drivers/thermal/thermal_core.c
>> index 39fc812..6d41e08 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -406,6 +406,7 @@ static void handle_critical_trips(struct
>> thermal_zone_device *tz,
>>   static void handle_thermal_trip(struct thermal_zone_device *tz, int
>> trip)
>>   {
>>   	enum thermal_trip_type type;
>> +	bool irq_mode = false;
>>   
>>   	/* Ignore disabled trip points */
>>   	if (test_bit(trip, &tz->trips_disabled))
>> @@ -419,9 +420,14 @@ static void handle_thermal_trip(struct
>> thermal_zone_device *tz, int trip)
>>   		handle_non_critical_trips(tz, trip);
>>   	/*
>>   	 * Alright, we handled this trip successfully.
>> -	 * So, start monitoring again.
>> +	 * So, start monitoring in polling mode if
>> +	 * trip is not using irq HW support.
>>   	 */
>> -	monitor_thermal_zone(tz);
>> +	if (tz->ops->get_trip_irq_mode)
>> +		tz->ops->get_trip_irq_mode(tz, trip, &irq_mode);
>> +
>> +	if (!irq_mode)
>> +		monitor_thermal_zone(tz);
>>   }
>>   
> handle_thermal_trip() is called from thermal_zone_device_update(), and
> it is invoked for every trip points.
> say, you have a passive trip point 1 that supports irq_mode, and
> another passive trip point 2 that does not support irq_mode,
> monitor_thermal_zone() is still called in handle_thermal_trip(tz, 2),
> and the passive timer will be activated anyway, do I miss something?
Yes, the passive timer will be activated in your example. It is correct
behavior and does not break anything.
case 1: there is 'k' passive trip points which have irq_mode and 1
additional which does not have 'irq_mode', the framework will start
polling but skip check for those 'k' trip points.
case 2: all of the passive trip points have irq_mode set, the framework
will not register 'scheduled_work' because it will not call 
'monitor_thermal_zone()'.
This is the case of most Exynos platforms, but there is one exception 
which has 'case 1' with 2 trip points not supporting irq_mode.

Regards,
Lukasz

> 
> thanks,
> rui
> 
>>   static void update_temperature(struct thermal_zone_device *tz)
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index 5f4705f..b064565 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -103,6 +103,7 @@ struct thermal_zone_device_ops {
>>   		enum thermal_device_mode);
>>   	int (*get_trip_type) (struct thermal_zone_device *, int,
>>   		enum thermal_trip_type *);
>> +	int (*get_trip_irq_mode) (struct thermal_zone_device *, int,
>> bool *);
>>   	int (*get_trip_temp) (struct thermal_zone_device *, int, int
>> *);
>>   	int (*set_trip_temp) (struct thermal_zone_device *, int,
>> int);
>>   	int (*get_trip_hyst) (struct thermal_zone_device *, int, int
>> *);
>> @@ -196,6 +197,7 @@ struct thermal_zone_device {
>>   	struct thermal_attr *trip_temp_attrs;
>>   	struct thermal_attr *trip_type_attrs;
>>   	struct thermal_attr *trip_hyst_attrs;
>> +	struct thermal_attr *trip_irq_mode_attrs;
>>   	void *devdata;
>>   	int trips;
>>   	unsigned long trips_disabled;	/* bitmap for disabled
>> trips */
>> @@ -364,6 +366,8 @@ struct thermal_zone_of_device_ops {
>>    * @temperature: temperature value in miliCelsius
>>    * @hysteresis: relative hysteresis in miliCelsius
>>    * @type: trip point type
>> + * @irq_mode: to not use polling in framework set support of HW irq
>> (which will
>> + *	      be triggered when temperature reaches this level).
>>    */
>>   
>>   struct thermal_trip {
>> @@ -371,6 +375,7 @@ struct thermal_trip {
>>   	int temperature;
>>   	int hysteresis;
>>   	enum thermal_trip_type type;
>> +	bool irq_mode;
>>   };
>>   
>>   /* Function declarations */
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 0/2] arm64: Only call into preempt_schedule() if need_resched()
From: Will Deacon @ 2018-12-06 19:18 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: ard.biesheuvel, catalin.marinas, rml, linux-kernel, schwidefsky,
	tglx, linux-arm-kernel
In-Reply-To: <20181206150850.GI13538@hirez.programming.kicks-ass.net>

Hi Peter,

On Thu, Dec 06, 2018 at 04:08:50PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 30, 2018 at 05:34:29PM +0000, Will Deacon wrote:
> > This is version two of the patches I originally posted here:
> > 
> >   http://lkml.kernel.org/r/1543347902-21170-1-git-send-email-will.deacon@arm.com
> > 
> > The only change since v1 is that  __preempt_count_dec_and_test() now
> > reloads the need_resched flag if it initially saw that it was set. This
> > resolves the issue spotted by Peter, where an IRQ coming in during the
> > decrement can cause a reschedule to be missed.
> 
> Yes, I think this one will work, so:
> 
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Thanks!

> However, this leaves me wondering if the sequence is actually much
> better than what you had?
> 
> I suppose there's a win due to cache locality -- you only have to load a
> single line -- but I'm thinking that on pure instruction count, you're
> not actually winning much.

The fast path is still slightly shorter in terms of executed instructions,
but you're right that the win is likely to be because everything hits in the
cache or the store buffer when we're not preempting, so we should run
through the code reasonably quickly and avoid the unconditional call to
preempt_schedule().

Will

--->8

// Before
  20:   a9bf7bfd        stp     x29, x30, [sp, #-16]!
  24:   910003fd        mov     x29, sp
  28:   d5384101        mrs     x1, sp_el0
  2c:   b9401020        ldr     w0, [x1, #16]
  30:   51000400        sub     w0, w0, #0x1
  34:   b9001020        str     w0, [x1, #16]
  38:   350000a0        cbnz    w0, 4c <preempt_enable+0x2c>
  3c:   f9400020        ldr     x0, [x1]
  40:   721f001f        tst     w0, #0x2
  44:   54000040        b.eq    4c <preempt_enable+0x2c>  // b.none
  48:   94000000        bl      0 <preempt_schedule>
  4c:   a8c17bfd        ldp     x29, x30, [sp], #16
  50:   d65f03c0        ret

// After
  20:   a9bf7bfd        stp     x29, x30, [sp, #-16]!
  24:   910003fd        mov     x29, sp
  28:   d5384101        mrs     x1, sp_el0
  2c:   f9400820        ldr     x0, [x1, #16]
  30:   d1000400        sub     x0, x0, #0x1
  34:   b9001020        str     w0, [x1, #16]
  38:   b5000080        cbnz    x0, 48 <preempt_enable+0x28>
  3c:   94000000        bl      0 <preempt_schedule>
  40:   a8c17bfd        ldp     x29, x30, [sp], #16
  44:   d65f03c0        ret
  48:   f9400820        ldr     x0, [x1, #16]
  4c:   b5ffffa0        cbnz    x0, 40 <preempt_enable+0x20>
  50:   94000000        bl      0 <preempt_schedule>
  54:   17fffffb        b       40 <will_preempt_enable+0x20>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH V3] arm64: Don't flush tlb while clearing the accessed bit
From: Will Deacon @ 2018-12-06 19:18 UTC (permalink / raw)
  To: Alexander Van Brunt
  Cc: mark.rutland@arm.com, linux-kernel@vger.kernel.org, Sachin Nikam,
	linux-tegra@vger.kernel.org, Ashish Mhetre,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR12MB27129A4EE7BBF57B1CAB5094CFAE0@BYAPR12MB2712.namprd12.prod.outlook.com>

Hi Alex,

Thanks for running these tests and providing the in-depth analysis.

On Mon, Dec 03, 2018 at 09:20:25PM +0000, Alexander Van Brunt wrote:
> > If we roll a TLB invalidation routine without the trailing DSB, what sort of
> > performance does that get you?
> 
> It is not as good. In some cases, it is really bad. Skipping the invalidate was
> the most consistent and fast implementation.

My problem with that is it's not really much different to just skipping the
page table update entirely. Skipping the DSB is closer to what is done on
x86, where we bound the stale entry time to the next context-switch.

Given that I already queued the version without the DSB, we have the choice
to either continue with that or to revert it and go back to the previous
behaviour. Which would you prefer?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] ARM: dts: sunxi: Fix PMU compatible strings
From: Will Deacon @ 2018-12-06 19:13 UTC (permalink / raw)
  To: Rob Herring
  Cc: Maxime Ripard, devicetree, Chen-Yu Tsai, linux-kernel,
	linux-arm-kernel
In-Reply-To: <20181206191142.14118-1-robh@kernel.org>

On Thu, Dec 06, 2018 at 01:11:42PM -0600, Rob Herring wrote:
> "arm,cortex-a15-pmu" is not a valid fallback compatible string for an
> Cortex-A7 PMU, so drop it.
> 
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
>  arch/arm/boot/dts/sun6i-a31.dtsi | 2 +-
>  arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> index a960b8ef7822..9e7931d5e42a 100644
> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> @@ -202,7 +202,7 @@
>  	};
>  
>  	pmu {
> -		compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
> +		compatible = "arm,cortex-a7-pmu";
>  		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
>  			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
>  			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 3c571dc599c3..5e413a5d9f6d 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -199,7 +199,7 @@
>  	};
>  
>  	pmu {
> -		compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
> +		compatible = "arm,cortex-a7-pmu";
>  		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
>  			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;

Acked-by: Will Deacon <will.deacon@arm.com>

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] ARM: dts: sunxi: Fix PMU compatible strings
From: Rob Herring @ 2018-12-06 19:11 UTC (permalink / raw)
  To: devicetree, linux-kernel, linux-arm-kernel
  Cc: Maxime Ripard, Chen-Yu Tsai, Will Deacon

"arm,cortex-a15-pmu" is not a valid fallback compatible string for an
Cortex-A7 PMU, so drop it.

Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 2 +-
 arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index a960b8ef7822..9e7931d5e42a 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -202,7 +202,7 @@
 	};
 
 	pmu {
-		compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
+		compatible = "arm,cortex-a7-pmu";
 		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 3c571dc599c3..5e413a5d9f6d 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -199,7 +199,7 @@
 	};
 
 	pmu {
-		compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
+		compatible = "arm,cortex-a7-pmu";
 		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
 	};
-- 
2.19.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: Moving ARM dts files
From: Rob Herring @ 2018-12-06 19:06 UTC (permalink / raw)
  To: Andreas Färber
  Cc: Andrew Lunn, Alexandre Belloni, Tony Lindgren, Linus Walleij,
	Liviu Dudau, Alexander Graf, Masahiro Yamada, Thierry Reding,
	Tom Rini, Florian Fainelli, Kevin Hilman, Gregory CLEMENT,
	Michal Simek, Krzysztof Kozlowski, ARM-SoC Maintainers,
	Joel Stanley, Andy Gross, devicetree, Architecture Mailman List,
	Jason Cooper, Simon Horman,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	Grant Likely, Maxime Coquelin, Shawn Guo, Daniel Mack
In-Reply-To: <2474284e-8a55-639f-2cfa-f811741099f3@suse.de>

On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber <afaerber@suse.de> wrote:
>
> Am 05.12.18 um 05:17 schrieb Rob Herring:
> > On Tue, Dec 4, 2018 at 7:22 PM Andreas Färber <afaerber@suse.de> wrote:
> >>
> >> Rob,
> >>
> >> Am 04.12.18 um 19:36 schrieb Rob Herring:
> >>> I've put together a script to move the dts files and update the
> >>> makefiles. It doesn't handle files not following a common prefix which
> >>> isn't many and some includes within the dts files will need some fixups
> >>> by hand.
> >>>
> >>> MAINTAINERS will also need updating.
> >>>
> >>> A few questions:
> >>>
> >>> Do we want to move absolutely everything to subdirs?
> >>
> >> This refactoring is a terrible idea!
> >
> > How do you really feel?
> >
> >> While it would've been nice to have more structure from the start,
> >> bootloaders like U-Boot expect a flat structure for arm .dtb files now.
> >> If you start installing them into subdirs instead, they won't find the
> >> files anymore under the hardcoded name.
> >>
> >> Doing this only for new platforms would be much less invasive and allow
> >> to prepare bootloaders accordingly.
> >
> > That was my suggestion where this started for the new RDA platform.
> > Olof preferred to move everything and that's my desire too.
> >
> >> Alternatively, white-list which ones
> >> are safe to move around.
> >
> > I'd prefer to know which ones the distros don't want moved. That
> > should be easier to figure out. We also need that anyways in context
> > of what platforms we care about compatibility.
> >
> > Another option is dtbs_install target could flatten the installed
> > dtbs. That is the only part the distros should depend on.
>
> I'd be okay with distinguishing source vs. install location. Due to the
> issue I mention below (and more) we can't use install_dtbs for openSUSE
> and had to reimplement it, which we'd need to (and can) adjust.

What would be needed for dtbs_install to work? arm64 needs to support
a flat install? If it doesn't work for Debian or openSUSE, I'm not
sure why we have it. So I'd like to make it work.

> >> But don't just script a refactoring because it
> >> looks nicer in the source tree, without testing what side effects this
> >> can have for board/distro users of the compiled files in practice.
> >> We already had that discussion for arm64 because Debian chose to ignore
> >> the kernel-installed subdirectories and installed .dtb files into a flat
> >> directory, which collided with openSUSE sticking to the kernel choice.
> >
> > So everyone already deals with subdirs or not with arm and arm64
> > already, seems like they can deal with this. I will raise the topic on
> > the cross-distro list though.
>
> Sounds like you're twisting words... The keyword was "hardcoded" paths -
> one way or another (not "and") depending on the kernel choices being
> flat for arm, vendor subdir for arm64.
>
> >> This topic becomes even more important with EBBR: There is neither a
> >> mechanism in place to sync .dts files into U-Boot or EDK2 source trees,
> >> nor are capsule updates implemented in U-Boot for easily deploying such
> >> bootloaders with new .dts sources or paths yet.
> >
> > EBBR actually says firmware (including dtbs) goes in directories named
> > by vendor.
>
> Fine, but unrelated.

If the distros want dtbs in a flat dir and EBBR says otherwise, then
it is related.

> >> And I can assure you
> >> that just getting users to dd the right bootloader can be difficult...
> >> Since DT forward and backward compatibility is often being neglected,
> >> for example with optional properties or renamed compatibles that break
> >> booting with previous drivers, new kernel versions often need updated
> >> Device Trees to make use of new/enhanced drivers. Therefore it is
> >> unfortunately often enough a necessity to load newer kernel-based .dtb
> >> files matching the kernel (as opposed to the dream of kernel-independent
> >> hardware descriptions) when working with the latest -rc or -next kernels
> >> at least. For examples of DTs needing updates, look no further than
> >> Linaro's 96boards - in case of hikey960/EDK2 GRUB is another layer where
> >> .dtb paths may be hardcoded, ditto for arm; and Armada was an example
> >> where the upstream bindings for the network IP changed incompatibly.
> >
> > Compatibility is an issue, yes, but that really has nothing to do with this.
> >
> >> DT overlays are another topic that is not making any progress upstream
> >> according to the ELCE BoF, so beyond the Raspberry Pi the only known
> >> working way to apply them is to write a U-Boot boot.scr script, which
> >> can either reuse $fdtcontroladdr DT or use the filename $fdtfile or
> >> hardcode one, the latter two of which would break with your renaming.
> >
> > DT overlays also have nothing to do with this as there aren't any in
> > the kernel. I'm not inclined to take any either with a flat tree.
> > We're already at 1800+ files.
>
> Read again: a) Breaking DT changes and b) the desire to use Overlays
> instead of replacing the bootloaders for each change are _reasons_ why
> people depend on .dtb filenames from the kernel source tree for their
> boot flow today. Nothing to do with downstream .dtbo files.
>
> For example, remember when I reported that the kernel didn't compile DTs
> with -@? No reaction except for Frank asking to be CC'ed - was it ever
> fixed??? Do EDK2's or U-Boot's built-in DTs compile with -@ today?

IIRC, Frank objected to changing this globally because it will bloat
all dtbs. And then no one did the work to make it a per dtb option.
Maybe that was the same issue in another thread.

> Raspberry Pi overlays in U-Boot work because it switched to passing the
> DT through from the proprietary firmware.
> Point being that while it would be nice to get a current, compatible DT
> via UEFI tables and ignore .dtb filenames outside of a few bootloaders,
> in reality we're not quite there yet for all platforms.
>
> I see no problem (except for naming choices) moving new targets like RDA
> to subfolders because we can then hardcode it the new way; I also assume
> deeply embedded targets like stm32f4 or targets with no mainline
> bootloaders yet like owl-s500 could be refactored.
> I do see problems refactoring widely used SBC targets like sunXi though.
>
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 0/2] meson: Fix IRQ trigger type
From: Emiliano Ingrassia @ 2018-12-06 18:51 UTC (permalink / raw)
  To: Carlo Caione, Martin Blumenstingl
  Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
	linux-arm-kernel
In-Reply-To: <20181206155228.GA15225@ingrassia.epigenesys.com>

Hi Carlo,

I keep running tests with packet generator,
using nload to show bandwidth usage.

Here is my test results with packet generators
both running on laptop and board with rate 1 Gbps.

TEST 0: no patch applied.

1) Start packet generator on laptop:

              | incoming traffic | outgoing traffic
=====================================================
nload (board) |     ~940 Mbps    |       0 Mbps
-----------------------------------------------------
nload (laptop)|       0 Mbps     |     ~940 Mbps
=====================================================

2) Start packet generator on board:

              | incoming traffic  | outgoing traffic
==============+===================+==================
nload (board) |     ~460 Mbps     |     ~256 Mbps
--------------+-------------------+------------------
nload (laptop)|     ~256 Mbps     |     ~940 Mbps
=====================================================

3) Stop packet generator on laptop:

              | incoming traffic | outgoing traffic
=====================================================
nload (board) |       0 Mbps     |    ~940 Mbps
-----------------------------------------------------
nload (laptop)|       ~940 Mbps  |      0 Mbps
=====================================================

4) Restart packet generator on laptop:

              | incoming traffic | outgoing traffic
=====================================================
nload (board) |     ~0 Mbps      |     ~940 Mbps
-----------------------------------------------------
nload (laptop)|     ~940 Mbps    |     ~940 Mbps
=====================================================

In the last case the "ifconfig" statistics about RX packets
remain fixed which probably indicates that the incoming traffic
to the board is effectively being dropped.

The eth0 interrupt counter keeps incrementing.
Simple ping test works correctly.


TEST 1: IRQ type patch applied

Same results as TEST 0.


TEST 2: eee-broken-1000t flag removed

1) Start packet generator on laptop:

              | incoming traffic | outgoing traffic
=====================================================
nload (board) |      ~3Mbps      |       0 Mbps
-----------------------------------------------------
nload (laptop)|       0 Mbps     |     ~940 Mbps
=====================================================

2) Start packet generator on board:

              | incoming traffic  | outgoing traffic
==============+===================+==================
nload (board) |     ~0 Mbps       |     ~940 Mbps
--------------+-------------------+------------------
nload (laptop)|     ~940 Mbps     |     ~940 Mbps
=====================================================

3) Stop packet generator on laptop:

              | incoming traffic | outgoing traffic
=====================================================
nload (board) |       0 Mbps     |    ~940 Mbps
-----------------------------------------------------
nload (laptop)|       ~940 Mbps  |      0 Mbps
=====================================================

4) Restart packet generator on laptop:

              | incoming traffic | outgoing traffic
=====================================================
nload (board) |     ~0 Mbps      |     ~940 Mbps
-----------------------------------------------------
nload (laptop)|     ~940 Mbps    |     ~940 Mbps
=====================================================

In the first case the "ifconfig" statistics about RX packets
are incremented consistently with the incoming traffic value
showed by the nload (board side).

In the last case the "ifconfig" statistics about RX packets
remain fixed which probably indicates that the incoming traffic
to the board is effectively being dropped.

The eth0 interrupt counter keeps incrementing.
Simple ping test from laptop to board shows a packet loss
of 90% and more while no packet loss achieved pinging
the laptop from the board.


TEST 3: both patches applied.

Same results as TEST 2.


From the results obtained from these tests,
which are more accurate than the previous one,
I can say that the second patch (remove eee-broken-1000t flag)
should NOT be applied.

About the first one (change MAC IRQ type), I would like
to do other tests with other tools like iperf3.
With these results only, I would say to not apply it
because nothing changed but if your stress test failed on
long running and this patch fix it I would like to test it more deeply.

As final thought, the conducted tests clearly show that if the board
transmits at full rate, all the incoming traffic is dropped.
I think that this behaviour should be fixed but don't know if
it depends on the driver or device tree description.
I'll keep investigating.

Regards,

Emiliano

On Thu, Dec 06, 2018 at 04:52:28PM +0100, Emiliano Ingrassia wrote:
> Hi Carlo,
>
> thanks for the answer.
>
> On Thu, Dec 06, 2018 at 01:17:58PM +0000, Carlo Caione wrote:
> > On Thu, 2018-12-06 at 13:43 +0100, Emiliano Ingrassia wrote:
> > > Hi all,
> >
> > Hi Emiliano,
> >
> > > thank you for involving me.
> > >
> > > I applied Carlo's patches[0] on a kernel vanilla 4.19.6
> > > and tested it with kernel packet generator, monitoring
> > > bandwidth usage with "nload".
> > >
> > > All tests were conducted on an Odroid-C1+ Rev. 0.4-20150930 board
> > > with a short ethernet cable directly attached to a laptop with
> > > 1G ethernet interface, with "nload" running on the board.
> > >
> > > The tests I performed are composed by the following steps:
> > >
> > > 1) Start packet generator with "rate 1000M" on laptop;
> > >
> > > 2) Keep packet generator active on the laptop and
> > >    start the packet generator on the board with "rate 1000M";
> > >
> > > 3) Stop both packet generators;
> > >
> > > 4) Start packet generator on the board;
> > >
> > > 5) Keep packet generator active on the board and
> > >    start the packet generator on the laptop.
> >
> > out of curiosity: why do you expect to see something different from
> > point (2)?
> >
>
> I did not expect it indeed, I tried and got different results.
>
> > > Test results without Carlo's patches applied:
> > >
> > > 1) "nload" shows an incoming traffic of ~950Mbps;
> > >
> > > 2) "nload" shows an incoming traffic of ~400Mbps
> > >    and an outgoing traffic of ~250Mbps;
> > >
> > > 3) "nload" shows 0Mbps both for incoming and outgoing traffic;
> > >
> > > 4) "nload" shows an outgoing traffic of ~950Mbps from the board;
> > >
> > > 5) "nload" shows incoming traffic of 0Mbps
> > >    and an outgoing traffic of ~950Mbps.
> > >
> > > Applying only the first patch (change mac IRQ type) I got the same
> > > results.
> >
> > This is expected. The change in the IRQ type is solving an issue that
> > you can see if the run a stress test involving multiple components for
> > several hours.
> >
>
> OK, did you use "stress-ng" tool for tests?
>
> > > Applying only the second patch (drop eee-broken-1000t) I got the same
> > > results!
> >
> > I am a bit confused here. Wasn't the eee-broken-1000t added to fix a
> > problem with the ethernet? Are you suggesting that for some reason you
> > cannot reproduce anymore the problem for which the quirk was
> > introduced?
> >
>
> Problems without the "eee-broken-1000t" flags were experimented
> one and a half years ago on a Amlogic development kernel from [0],
> probably a 4.14 version.
> Many patches about Meson8b SoC, dwmac-meson8b and dwmac driver
> were introduced so yes, the "eee-broken-1000t" was added
> to fix a problem with the ethernet (one and a half years ago),
> but new tests are needed to say if it still necessary.
>
> > > With both patches applied I got the same results but with an incoming
> > > traffic
> > > of ~3Mbps on the board.
> >
> > On all the tests and immediately from the start of the tests?
> >
>
> Yes, in all the 5 steps immediately from the start.
>
> I also tried to execute "nload" on both sides to see the bandwidth
> usage.
>
> With bot patches applied, after starting kernel packet generator
> on my laptop with 1Gbps rate, "nload" on the laptop side shows me
> an outgoing traffic of ~940Mbps while "nload" on the board side shows
> me an incoming traffic of ~3Mbps.
>
> Also consider that a pinging test from my laptop to the board shows
> a packet loss of about 90%.
>
> > When you hit the problem con you check in /proc/interrupts if you see
> > the IRQ counter for the eth0 incrementing or not?
> >
>
> The eth0 IRQ counter is incremented during the test.
>
> > Cheers,
> >
> > --
> > Carlo Caione
> >
> >
>
> I would like to conduct other tests with iperf3 to be sure about
> the obtained results. What do you think?
> Should I apply your patches on the latest Amlogic development kernel?
>
> Regards,
>
> Emiliano
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/

Cheers,

Emiliano

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v5 2/4] arm64: KVM: add accessors to track guest/host only counters
From: Suzuki K Poulose @ 2018-12-06 18:51 UTC (permalink / raw)
  To: Andrew Murray, Christoffer Dall, Marc Zyngier, Catalin Marinas,
	Will Deacon, Mark Rutland
  Cc: kvmarm, linux-arm-kernel, Julien Thierry
In-Reply-To: <97301473-69d0-9a0b-b957-5568a43a6551@arm.com>



On 06/12/2018 17:21, Suzuki K Poulose wrote:
> Hi Andrew,
> 
> On 05/12/2018 15:30, Andrew Murray wrote:
>> In order to effeciently enable/disable guest/host only perf counters
>> at guest entry/exit we add bitfields to kvm_cpu_context for guest and
>> host events as well as accessors for updating them.
>>
>> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
>> ---
>>    arch/arm64/include/asm/kvm_host.h | 24 ++++++++++++++++++++++++
>>    1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 1550192..800c87b 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -203,6 +203,8 @@ struct kvm_cpu_context {
>>    	};
>>    
>>    	struct kvm_vcpu *__hyp_running_vcpu;
>> +	u32 events_host;
>> +	u32 events_guest;
>>    };
>>    
>>    typedef struct kvm_cpu_context kvm_cpu_context_t;
>> @@ -467,11 +469,33 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu);
>>    void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu);
>>    void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu);
>>    
>> +#define KVM_PMU_EVENTS_HOST	1
>> +#define KVM_PMU_EVENTS_GUEST	2
>> +
>>    #ifdef CONFIG_KVM /* Avoid conflicts with core headers if CONFIG_KVM=n */
>>    static inline int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
>>    {
>>    	return kvm_arch_vcpu_run_map_fp(vcpu);
>>    }
>> +static inline void kvm_set_pmu_events(u32 set, int flags)
>> +{
>> +	kvm_cpu_context_t *ctx = this_cpu_ptr(&kvm_host_cpu_state);
>> +
>> +	if (flags & KVM_PMU_EVENTS_HOST)
>> +		ctx->events_host |= set;
>> +	if (flags & KVM_PMU_EVENTS_GUEST)
>> +		ctx->events_guest |= set;
> 
> You seem to be passing a single flag at a time ever, in the next patch.
> Either we can batch the calls in the next patch, or make this a real number and
> not a flag. g.g, enum { HOST,  GUEST } or even a bool.
> 
> I think the former sounds better.

Having another look at patch-3, we can never club set() calls for host & guest 
events, we should go for the latter.

Suzuki


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox