* [PATCH] rtc: armada38x: add __ro_after_init to armada38x_rtc_ops
From: Russell King - ARM Linux @ 2017-01-04 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1701041242080.3073@hadrien>
On Wed, Jan 04, 2017 at 12:43:32PM +0100, Julia Lawall wrote:
> > The question was whether the point to the rtc_class_ops could be made
> > __ro_after_init. And Russell is right, it is pointed to by the ops
> > pointer in a struct rtc_device and that struct is dynamically allocated
> > in rtc_device_register().
>
> OK, I think it's a terminology issue. You mean the structure that
> contains the pointer, and not the pointer itself, which is already const.
That statement is really ambiguous, and really doesn't help the cause -
we have several structures here which contain pointers and it's far from
clear which you're talking about:
- The armada38x_rtc_ops and armada38x_rtc_ops_noirq structures contain
pointers to functions.
- The dynamically allocated struct rtc_device contains an ops pointer,
which will point at one or other of these two structures.
Now, as soon as we make armada38x_rtc_ops and armada38x_rtc_ops_noirq
const, if the pointer is passed through any function call where the
argument is not also marked const, or is assigned to a pointer that is
not marked const (without an explicit cast), the compiler will complain.
Remember that a const pointer (iow, const void *ptr) is just a hint to
the compiler that "ptr" _may_ point at read-only data, and dereferences
of the pointer are not allowed to write - it's just syntactic checking.
Given that this is stuff we should all know, I'm not quite sure what
people are getting in a tiz over... I'm finding it worrying that I'm
even writing this mail, reviewing this stuff! _Really_ worried that
Kees even brought it up in the first place - I suspect that came from
a misunderstanding of my suggestion which is why I later provided the
suggestion in patch form.
What I suggested, and what my patch does is:
1. It places both the armada38x_rtc_ops and armada38x_rtc_ops_noirq
structures into the .rodata section, which will be protected from
writes by hardware when appropriate kernel options are enabled.
2. The driver does _not_ store a local pointer to this memory at a
static address which could be subsequently modified (*).
3. The only pointer to this memory is during driver initialisation
(which may well reside in a CPU register only) before being passed
to the RTC subsystem.
4. The RTC subsystem dynamically allocates a struct rtc_device
structure (in rtc_device_register()) where it eventually stores
this pointer. This pointer is already marked const. This structure
contains read/write data, and can't be marked read-only, just in the
same way as "struct file" can't be.
The whole __ro_after_init thing is completely irrelevant and a total
distraction at this point - there is nothing that you could add a
__ro_after_init annotation to after my patch in regard of these ops
structures.
* - however, a compiler may decide to store the addresses of these
structures as a literal constant near the function, but with RONX
protection for the .text section, this memory is also read-only, and
so can't be modified.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [GIT PULL] DaVinci fixes for v4.10
From: Sekhar Nori @ 2017-01-04 12:13 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v4.10
for you to fetch changes up to d1df1e01af1d7c91e48204b9eb8b9f20cdb90700:
ARM: davinci: da8xx: Fix sleeping function called from invalid context (2017-01-02 16:15:07 +0530)
----------------------------------------------------------------
This pull request contains fixes for the following issues
1) Fix two instances of infinite loop occurring in
clock list for DA850. This fixes kernel hangs in some
instances and so have been marked for stable kernel.
2) Fix for sleeping function called from atomic context
with USB 2.0 clock management code introduced in v4.10
merge window.
----------------------------------------------------------------
Alexandre Bailon (2):
ARM: davinci: Make __clk_{enable,disable} functions public
ARM: davinci: da8xx: Fix sleeping function called from invalid context
Bartosz Golaszewski (2):
ARM: davinci: da850: fix infinite loop in clk_set_rate()
ARM: davinci: da850: don't add emac clock to lookup table twice
arch/arm/mach-davinci/clock.c | 12 ++++++------
arch/arm/mach-davinci/clock.h | 2 ++
arch/arm/mach-davinci/da850.c | 32 ++++++++++++++++++++++++++++++--
arch/arm/mach-davinci/usb-da8xx.c | 34 +++++++++++++++-------------------
4 files changed, 53 insertions(+), 27 deletions(-)
^ permalink raw reply
* arm64: virt_to_page() does not return right page for a kernel image address
From: Catalin Marinas @ 2017-01-04 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHB_GuqqXqVu4i4eCZ3V_d8JbdSO6rjWpA_B0NMJsNc_Zw0Niw@mail.gmail.com>
On Wed, Jan 04, 2017 at 11:19:38AM +0530, Pratyush Anand wrote:
> I noticed that on arm64 kmap_atomic() does not return correct address
> corresponding to a page located in data section. It causes crash in
> kdump kernel with v29 kdump patches. crash happens in a newly
> implemented crypto test [1], and the same test fails(even though it
> does not crash) in 1st kernel as well.
>
> Further debugging showed that the physical address returned by
> virt_to_phys(kaddr) and virt_to_phys(kmap_atomic(virt_to_page(kaddr))
> + offset_in_page(kaddr)) are not same.
>
> Mark Rutland thinks(IRC :#armlinux) that _virt_to_pgoff *only* handles
> linear addresses, and not kernel image addresses. However, we have to
> ask if it should?
It looks like we have a different behaviour for virt_to_page() depending
on whether CONFIG_SPARSEMEM_VMEMMAP is defined.
We've had some discussions about a month ago on whether we should allow
virt_to_phys() on kernel addresses and requiring that __pa_symbol() is
used instead but I forgot on what the decision was (if any). It seems
that we have other cases as well that need to be addressed, in which
case it may be better to simply allow virt_to_page/phys on kernel
symbols.
--
Catalin
^ permalink raw reply
* arm64: virt_to_page() does not return right page for a kernel image address
From: Mark Rutland @ 2017-01-04 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c23ad459-9dab-2085-2e0d-91ad4cedc987@redhat.com>
On Wed, Jan 04, 2017 at 05:28:32PM +0530, Pratyush Anand wrote:
> Hi Mark,
Hi Pratyush,
> On Wednesday 04 January 2017 04:41 PM, Mark Rutland wrote:
> >Other than the (new) crypto test and the (not yet upstream) kdump
> >patches, does any code rely on virt_to_page() working for a kernel image
> >address? If so, and if we cannot fix those in the short term, we may
> >want to temporarily revert commit 9f2875912dac35d9 until those are fixed
> >up.
> >
> >Regardless, I think that the kdump code should not rely on
> >virt_to_page() for a kernel image (or kmap) result.
>
> Its not the kdump code which is relying on virt_to_page() for a
> kernel image.
Sorry, I had misread the above. I understand now.
> Its only crypto test which does that. In the first kernel (none
> kdump case) also crypto test gets a wrong kmap_atomic() address,
> however luckily there exists an entry for that address in page table
> and so a valid corresponding physical location. Therefore, it is
> just that we do not see the crash. I see still the crypto test
> failure print in the 1st kernel.
> However, in crash kernel there was no valid physical address and so
> the kernel crashed.
So it seems we need to fix the crypto test.
Looking at crypto/testmgr.c, I can't spot the kmap_atomic() or the
page_address()/virt_to_page(). I guess that's hidden behind helpers,
which might also be used elsewhere?
Could you elaborate on where exactly the problem is in the crypto test?
Thanks,
Mark.
^ permalink raw reply
* [PATCH] mailbox: sti: Fix mbox-names copy and paste error
From: Lee Jones @ 2017-01-04 12:05 UTC (permalink / raw)
To: linux-arm-kernel
Due to an over-sight, mbox-names has become mbox-name in some instances.
Let's put it right.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
Documentation/devicetree/bindings/mailbox/sti-mailbox.txt | 4 ++--
arch/arm/boot/dts/stih407-family.dtsi | 8 ++++----
drivers/mailbox/mailbox-sti.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
index 351f612..648d176 100644
--- a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
@@ -9,7 +9,7 @@ Controller
Required properties:
- compatible : Should be "st,stih407-mailbox"
- reg : Offset and length of the device's register set
-- mbox-name : Name of the mailbox
+- mbox-names : Name of the mailbox
- #mbox-cells: : Must be 2
<&phandle instance channel direction>
phandle : Label name of controller
@@ -26,7 +26,7 @@ mailbox0: mailbox at 0 {
reg = <0x08f00000 0x1000>;
interrupts = <GIC_SPI 1 IRQ_TYPE_NONE>;
#mbox-cells = <2>;
- mbox-name = "a9";
+ mbox-names = "a9";
};
Client
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index c8b2944..00c67d4 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -787,7 +787,7 @@
reg = <0x8f00000 0x1000>;
interrupts = <GIC_SPI 1 IRQ_TYPE_NONE>;
#mbox-cells = <2>;
- mbox-name = "a9";
+ mbox-names = "a9";
status = "okay";
};
@@ -795,7 +795,7 @@
compatible = "st,stih407-mailbox";
reg = <0x8f01000 0x1000>;
#mbox-cells = <2>;
- mbox-name = "st231_gp_1";
+ mbox-names = "st231_gp_1";
status = "okay";
};
@@ -803,7 +803,7 @@
compatible = "st,stih407-mailbox";
reg = <0x8f02000 0x1000>;
#mbox-cells = <2>;
- mbox-name = "st231_gp_0";
+ mbox-names = "st231_gp_0";
status = "okay";
};
@@ -811,7 +811,7 @@
compatible = "st,stih407-mailbox";
reg = <0x8f03000 0x1000>;
#mbox-cells = <2>;
- mbox-name = "st231_audio_video";
+ mbox-names = "st231_audio_video";
status = "okay";
};
diff --git a/drivers/mailbox/mailbox-sti.c b/drivers/mailbox/mailbox-sti.c
index 41bcd33..e532a98 100644
--- a/drivers/mailbox/mailbox-sti.c
+++ b/drivers/mailbox/mailbox-sti.c
@@ -434,7 +434,7 @@ static int sti_mbox_probe(struct platform_device *pdev)
if (IS_ERR(mdev->base))
return PTR_ERR(mdev->base);
- ret = of_property_read_string(np, "mbox-name", &mdev->name);
+ ret = of_property_read_string(np, "mbox-names", &mdev->name);
if (ret)
mdev->name = np->full_name;
--
2.10.2
^ permalink raw reply related
* arm64: virt_to_page() does not return right page for a kernel image address
From: Pratyush Anand @ 2017-01-04 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104111119.GD8329@leverpostej>
Hi Mark,
On Wednesday 04 January 2017 04:41 PM, Mark Rutland wrote:
> Other than the (new) crypto test and the (not yet upstream) kdump
> patches, does any code rely on virt_to_page() working for a kernel image
> address? If so, and if we cannot fix those in the short term, we may
> want to temporarily revert commit 9f2875912dac35d9 until those are fixed
> up.
>
> Regardless, I think that the kdump code should not rely on
> virt_to_page() for a kernel image (or kmap) result.
Its not the kdump code which is relying on virt_to_page() for a kernel
image.
Its only crypto test which does that. In the first kernel (none kdump
case) also crypto test gets a wrong kmap_atomic() address, however
luckily there exists an entry for that address in page table and so a
valid corresponding physical location. Therefore, it is just that we do
not see the crash. I see still the crypto test failure print in the 1st
kernel.
However, in crash kernel there was no valid physical address and so the
kernel crashed.
~Pratyush
^ permalink raw reply
* [PATCH 18/22] mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-19-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the AXP20X/AXP22X battery driver to the MFD cells of the
> AXP209, AXP221 and AXP223 MFD.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 7f0f05f..8730fc2 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -587,6 +587,9 @@ static struct mfd_cell axp20x_cells[] = {
> .name = "axp20x-adc",
> .of_compatible = "x-powers,axp209-adc",
> }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp209-battery-power-supply",
> + }, {
> .name = "axp20x-ac-power-supply",
> .of_compatible = "x-powers,axp202-ac-power-supply",
> .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> @@ -615,6 +618,9 @@ static struct mfd_cell axp221_cells[] = {
> .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> .resources = axp20x_ac_power_supply_resources,
> }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp221-battery-power-supply",
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> @@ -631,6 +637,9 @@ static struct mfd_cell axp223_cells[] = {
> .name = "axp20x-adc",
> .of_compatible = "x-powers,axp221-adc"
> }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp221-battery-power-supply",
> + }, {
> .name = "axp20x-regulator",
> }, {
> .name = "axp20x-ac-power-supply",
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 16/22] mfd: axp20x: add V_OFF to writeable regs for AXP20X and AXP22X
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-17-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The V_OFF register has its first 3 read-write bits for the minimal
> voltage (Voff) of the battery before the system is automatically shut
> down due to the power being too low.
>
> This adds V_OFF register to the writeable registers of AXP20X and AXP22X
> PMICs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 19bdba3..7f0f05f 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -65,7 +65,7 @@ static const struct regmap_access_table axp152_volatile_table = {
>
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> - regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_V_OFF),
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> @@ -94,7 +94,7 @@ static const struct regmap_access_table axp20x_volatile_table = {
> /* AXP22x ranges are shared with the AXP809, as they cover the same range */
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> - regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_V_OFF),
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 15/22] mfd: axp20x: add CHRG_CTRL1 to writeable regs for AXP20X/AXP22X
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-16-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The CHR_CTRL1 register is made of 7 read-write bits with one being used
> to set the target voltage for battery charging.
>
> This adds the CHRG_CTRL1 register to the list of writeable registers for
> AXP20X and AXP22X PMICs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 2 ++
> 1 file changed, 2 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 65c57d0..19bdba3 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -66,6 +66,7 @@ static const struct regmap_access_table axp152_volatile_table = {
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> };
> @@ -94,6 +95,7 @@ static const struct regmap_access_table axp20x_volatile_table = {
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 09/22] mfd: axp20x: add AC power supply cells for AXP22X PMICs
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-10-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs expose the status of AC power
> supply.
>
> This adds the AC power supply driver to the MFD cells of the AXP22X
> PMICs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 31a84d81..65c57d0 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -608,6 +608,11 @@ static struct mfd_cell axp221_cells[] = {
> .name = "axp20x-adc",
> .of_compatible = "x-powers,axp221-adc"
> }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp221-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> + .resources = axp20x_ac_power_supply_resources,
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> @@ -626,6 +631,11 @@ static struct mfd_cell axp223_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp221-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> + .resources = axp20x_ac_power_supply_resources,
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp223-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 04/22] mfd: axp20x: add ADC cells for AXP20X and AXP22X PMICs
From: Lee Jones @ 2017-01-04 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104115602.GB24058@dell>
On Wed, 04 Jan 2017, Lee Jones wrote:
> On Mon, 02 Jan 2017, Quentin Schulz wrote:
>
> > This adds the AXP20X/AXP22x ADCs driver to the mfd cells of the AXP209,
> > AXP221 and AXP223 MFD.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> > ---
> > drivers/mfd/axp20x.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
>
> Applied, thanks.
Whoops, wrong key combo! Should have been:
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> > index a33db5e..31a84d81 100644
> > --- a/drivers/mfd/axp20x.c
> > +++ b/drivers/mfd/axp20x.c
> > @@ -582,6 +582,9 @@ static struct mfd_cell axp20x_cells[] = {
> > }, {
> > .name = "axp20x-regulator",
> > }, {
> > + .name = "axp20x-adc",
> > + .of_compatible = "x-powers,axp209-adc",
> > + }, {
> > .name = "axp20x-ac-power-supply",
> > .of_compatible = "x-powers,axp202-ac-power-supply",
> > .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> > @@ -602,6 +605,9 @@ static struct mfd_cell axp221_cells[] = {
> > }, {
> > .name = "axp20x-regulator",
> > }, {
> > + .name = "axp20x-adc",
> > + .of_compatible = "x-powers,axp221-adc"
> > + }, {
> > .name = "axp20x-usb-power-supply",
> > .of_compatible = "x-powers,axp221-usb-power-supply",
> > .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> > @@ -615,6 +621,9 @@ static struct mfd_cell axp223_cells[] = {
> > .num_resources = ARRAY_SIZE(axp22x_pek_resources),
> > .resources = axp22x_pek_resources,
> > }, {
> > + .name = "axp20x-adc",
> > + .of_compatible = "x-powers,axp221-adc"
> > + }, {
> > .name = "axp20x-regulator",
> > }, {
> > .name = "axp20x-usb-power-supply",
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 04/22] mfd: axp20x: add ADC cells for AXP20X and AXP22X PMICs
From: Lee Jones @ 2017-01-04 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-5-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> This adds the AXP20X/AXP22x ADCs driver to the mfd cells of the AXP209,
> AXP221 and AXP223 MFD.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
Applied, thanks.
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index a33db5e..31a84d81 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -582,6 +582,9 @@ static struct mfd_cell axp20x_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-adc",
> + .of_compatible = "x-powers,axp209-adc",
> + }, {
> .name = "axp20x-ac-power-supply",
> .of_compatible = "x-powers,axp202-ac-power-supply",
> .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> @@ -602,6 +605,9 @@ static struct mfd_cell axp221_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-adc",
> + .of_compatible = "x-powers,axp221-adc"
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> @@ -615,6 +621,9 @@ static struct mfd_cell axp223_cells[] = {
> .num_resources = ARRAY_SIZE(axp22x_pek_resources),
> .resources = axp22x_pek_resources,
> }, {
> + .name = "axp20x-adc",
> + .of_compatible = "x-powers,axp221-adc"
> + }, {
> .name = "axp20x-regulator",
> }, {
> .name = "axp20x-usb-power-supply",
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 02/22] mfd: axp20x: add ADC data regs to volatile regs for AXP22X
From: Lee Jones @ 2017-01-04 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-3-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The AXP22X PMICs have multiple ADCs, each one exposing data from the
> different power supplies connected to the PMIC.
>
> This adds the different ADC data registers to the volatile registers of
> the AXP22X PMIC.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/mfd/axp20x.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 619a83e..a33db5e 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -100,6 +100,7 @@ static const struct regmap_range axp22x_writeable_ranges[] = {
> static const struct regmap_range axp22x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP22X_TEMP_ADC_H, AXP20X_BATT_DISCHRG_I_L),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
> regmap_reg_range(AXP22X_PMIC_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
From: Will Deacon @ 2017-01-04 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4f5b650-b210-8332-e6f2-4ad9634818b9@gmail.com>
Hi Florian,
On Wed, Dec 28, 2016 at 12:17:23PM -0800, Florian Fainelli wrote:
> On 11/03/2016 10:20 AM, Florian Fainelli wrote:
> > On 11/03/2016 07:16 AM, Will Deacon wrote:
> >> If you can't change toolchain and you want this worked around, why can't you
> >> either build gold with it enabled by default, or pass the extra flag on the
> >> command line to the kernel build system?
> >
> > Because that creates a distribution problem and now we have to document
> > this for people who want to build a kernel on their own, without
> > necessarily understanding if this is something they might need, or why
> > this is needed, and why the kernel is not taking care of that on its
> > own? So yes, this comes down to who is responsible for what, in that
> > case the kernel's Makefile is the best place where to put such knowledge
> > as to which workaround needs to be enabled by the linker and it
> > simplifies things a lot for people.
>
> Was this convincing enough for Catalin to pick Markus' patch or does
> that mean this patch needs to remain out of tree for us because of using
> a slightly older toolchain?
I thought more about this last night, and there are two questions that
might sway me:
1. How prevalent is the binary toolchain with this issue? Is it, for
example, shipping as part of a publicly available LTS distribution?
I know you quoted some Linaro build, but I can't actually find those
binaries on their website.
2. Could we extend the Makefile magic to detect that, not only is
--fix-cortex-a53-843419 unsupported, but also that the linker is
in fact gold?
Will
^ permalink raw reply
* [PATCH v6 5/5] soc: zte: pm_domains: Add support for zx296718
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie@linaro.org>
This patch introduces the power domain driver of zx296718
which belongs to zte's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
---
drivers/soc/zte/Makefile | 1 +
drivers/soc/zte/zx296718_pm_domains.c | 181 ++++++++++++++++++++++++++++++++++
2 files changed, 182 insertions(+)
create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
index 8a37f2f..96b7cd4 100644
--- a/drivers/soc/zte/Makefile
+++ b/drivers/soc/zte/Makefile
@@ -2,3 +2,4 @@
# ZTE SOC drivers
#
obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx296718_pm_domains.o
diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
new file mode 100644
index 0000000..52003ee
--- /dev/null
+++ b/drivers/soc/zte/zx296718_pm_domains.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <dt-bindings/soc/zte,pm_domains.h>
+#include "zx2967_pm_domains.h"
+
+static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
+ [REG_CLKEN] = 0x18,
+ [REG_ISOEN] = 0x1c,
+ [REG_RSTEN] = 0x20,
+ [REG_PWREN] = 0x24,
+ [REG_ACK_SYNC] = 0x28,
+};
+
+enum {
+ PCU_DM_VOU = 0,
+ PCU_DM_SAPPU,
+ PCU_DM_VDE,
+ PCU_DM_VCE,
+ PCU_DM_HDE,
+ PCU_DM_VIU,
+ PCU_DM_USB20,
+ PCU_DM_USB21,
+ PCU_DM_USB30,
+ PCU_DM_HSIC,
+ PCU_DM_GMAC,
+ PCU_DM_TS,
+};
+
+static struct zx2967_pm_domain vou_domain = {
+ .dm = {
+ .name = "vou_domain",
+ },
+ .bit = PCU_DM_VOU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain sappu_domain = {
+ .dm = {
+ .name = "sappu_domain",
+ },
+ .bit = PCU_DM_SAPPU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain vde_domain = {
+ .dm = {
+ .name = "vde_domain",
+ },
+ .bit = PCU_DM_VDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain vce_domain = {
+ .dm = {
+ .name = "vce_domain",
+ },
+ .bit = PCU_DM_VCE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain hde_domain = {
+ .dm = {
+ .name = "hde_domain",
+ },
+ .bit = PCU_DM_HDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain viu_domain = {
+ .dm = {
+ .name = "viu_domain",
+ },
+ .bit = PCU_DM_VIU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb20_domain = {
+ .dm = {
+ .name = "usb20_domain",
+ },
+ .bit = PCU_DM_USB20,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb21_domain = {
+ .dm = {
+ .name = "usb21_domain",
+ },
+ .bit = PCU_DM_USB21,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb30_domain = {
+ .dm = {
+ .name = "usb30_domain",
+ },
+ .bit = PCU_DM_USB30,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain hsic_domain = {
+ .dm = {
+ .name = "hsic_domain",
+ },
+ .bit = PCU_DM_HSIC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain gmac_domain = {
+ .dm = {
+ .name = "gmac_domain",
+ },
+ .bit = PCU_DM_GMAC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain ts_domain = {
+ .dm = {
+ .name = "ts_domain",
+ },
+ .bit = PCU_DM_TS,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct generic_pm_domain *zx296718_pm_domains[] = {
+ [DM_ZX296718_SAPPU] = &sappu_domain.dm,
+ [DM_ZX296718_VDE] = &vde_domain.dm,
+ [DM_ZX296718_VCE] = &vce_domain.dm,
+ [DM_ZX296718_HDE] = &hde_domain.dm,
+ [DM_ZX296718_VIU] = &viu_domain.dm,
+ [DM_ZX296718_USB20] = &usb20_domain.dm,
+ [DM_ZX296718_USB21] = &usb21_domain.dm,
+ [DM_ZX296718_USB30] = &usb30_domain.dm,
+ [DM_ZX296718_HSIC] = &hsic_domain.dm,
+ [DM_ZX296718_GMAC] = &gmac_domain.dm,
+ [DM_ZX296718_TS] = &ts_domain.dm,
+ [DM_ZX296718_VOU] = &vou_domain.dm,
+};
+
+static int zx296718_pd_probe(struct platform_device *pdev)
+{
+ return zx2967_pd_probe(pdev,
+ zx296718_pm_domains,
+ ARRAY_SIZE(zx296718_pm_domains));
+}
+
+static const struct of_device_id zx296718_pm_domain_matches[] = {
+ { .compatible = "zte,zx296718-pcu", },
+ { },
+};
+
+static struct platform_driver zx296718_pd_driver = {
+ .driver = {
+ .name = "zx-powerdomain",
+ .owner = THIS_MODULE,
+ .of_match_table = zx296718_pm_domain_matches,
+ },
+ .probe = zx296718_pd_probe,
+};
+
+static int __init zx296718_pd_init(void)
+{
+ return platform_driver_register(&zx296718_pd_driver);
+}
+subsys_initcall(zx296718_pd_init);
--
2.7.4
^ permalink raw reply related
* [PATCH v6 4/5] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie@linaro.org>
The ARMv8 zx2967 family (296718, 296716 etc) uses different value
for controlling the power domain on/off registers, Choose the
value depending on the compatible.
Multiple domains are prepared for the family, this patch prepares
the common functions.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/zte/Kconfig | 13 ++++
drivers/soc/zte/Makefile | 4 +
drivers/soc/zte/zx2967_pm_domains.c | 142 ++++++++++++++++++++++++++++++++++++
drivers/soc/zte/zx2967_pm_domains.h | 44 +++++++++++
6 files changed, 205 insertions(+)
create mode 100644 drivers/soc/zte/Kconfig
create mode 100644 drivers/soc/zte/Makefile
create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
create mode 100644 drivers/soc/zte/zx2967_pm_domains.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f31bceb..f09023f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/ux500/Kconfig"
source "drivers/soc/versatile/Kconfig"
+source "drivers/soc/zte/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 50c23d0..05eae52 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
+obj-$(CONFIG_ARCH_ZX) += zte/
diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
new file mode 100644
index 0000000..20bde38
--- /dev/null
+++ b/drivers/soc/zte/Kconfig
@@ -0,0 +1,13 @@
+#
+# ZTE SoC drivers
+#
+menuconfig SOC_ZTE
+ bool "ZTE SoC driver support"
+
+if SOC_ZTE
+
+config ZX2967_PM_DOMAINS
+ bool "ZX2967 PM domains"
+ depends on PM_GENERIC_DOMAINS
+
+endif
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
new file mode 100644
index 0000000..8a37f2f
--- /dev/null
+++ b/drivers/soc/zte/Makefile
@@ -0,0 +1,4 @@
+#
+# ZTE SOC drivers
+#
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
diff --git a/drivers/soc/zte/zx2967_pm_domains.c b/drivers/soc/zte/zx2967_pm_domains.c
new file mode 100644
index 0000000..f190a62
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+
+#include "zx2967_pm_domains.h"
+
+#define PCU_DM_CLKEN(zpd) ((zpd)->reg_offset[REG_CLKEN])
+#define PCU_DM_ISOEN(zpd) ((zpd)->reg_offset[REG_ISOEN])
+#define PCU_DM_RSTEN(zpd) ((zpd)->reg_offset[REG_RSTEN])
+#define PCU_DM_PWREN(zpd) ((zpd)->reg_offset[REG_PWREN])
+#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
+
+static void __iomem *pcubase;
+
+int zx2967_power_on(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val |= BIT(zpd->bit);
+ else
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && !val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ pr_debug("poweron %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_power_off(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val &= ~BIT(zpd->bit);
+ else
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ pr_debug("poweroff %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num)
+{
+ struct genpd_onecell_data *genpd_data;
+ struct resource *res;
+ int i;
+
+ genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data), GFP_KERNEL);
+ if (!genpd_data)
+ return -ENOMEM;
+
+ genpd_data->domains = zx_pm_domains;
+ genpd_data->num_domains = domain_num;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pcubase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pcubase)) {
+ dev_err(&pdev->dev, "ioremap fail.\n");
+ return PTR_ERR(pcubase);
+ }
+
+ for (i = 0; i < domain_num; ++i) {
+ zx_pm_domains[i]->power_on = zx2967_power_on;
+ zx_pm_domains[i]->power_off = zx2967_power_off;
+
+ pm_genpd_init(zx_pm_domains[i], NULL, false);
+ }
+
+ of_genpd_add_provider_onecell(pdev->dev.of_node, genpd_data);
+ dev_info(&pdev->dev, "powerdomain init ok\n");
+ return 0;
+}
diff --git a/drivers/soc/zte/zx2967_pm_domains.h b/drivers/soc/zte/zx2967_pm_domains.h
new file mode 100644
index 0000000..cb46595
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.h
@@ -0,0 +1,44 @@
+/*
+ * Header for ZTE's Power Domain Driver support
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#ifndef __ZTE_ZX2967_PM_DOMAIN_H
+#define __ZTE_ZX2967_PM_DOMAIN_H
+
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+
+enum {
+ REG_CLKEN,
+ REG_ISOEN,
+ REG_RSTEN,
+ REG_PWREN,
+ REG_PWRDN,
+ REG_ACK_SYNC,
+
+ /* The size of the array - must be last */
+ REG_ARRAY_SIZE,
+};
+
+enum zx2967_power_polarity {
+ PWREN,
+ PWRDN,
+};
+
+struct zx2967_pm_domain {
+ struct generic_pm_domain dm;
+ const u16 bit;
+ const enum zx2967_power_polarity polarity;
+ const u16 *reg_offset;
+};
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num);
+
+#endif /* __ZTE_ZX2967_PM_DOMAIN_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v6 3/5] soc: zte: Add header for PM domains specifiers
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie@linaro.org>
This patch adds header with values used for ZTE 2967
SoC's power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
include/dt-bindings/soc/zte,pm_domains.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 include/dt-bindings/soc/zte,pm_domains.h
diff --git a/include/dt-bindings/soc/zte,pm_domains.h b/include/dt-bindings/soc/zte,pm_domains.h
new file mode 100644
index 0000000..01e9abc
--- /dev/null
+++ b/include/dt-bindings/soc/zte,pm_domains.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#ifndef _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+#define _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+
+#define DM_ZX296718_SAPPU 0
+#define DM_ZX296718_VDE 1 /* g1v6 */
+#define DM_ZX296718_VCE 2 /* h1v6 */
+#define DM_ZX296718_HDE 3 /* g2v2 */
+#define DM_ZX296718_VIU 4
+#define DM_ZX296718_USB20 5
+#define DM_ZX296718_USB21 6
+#define DM_ZX296718_USB30 7
+#define DM_ZX296718_HSIC 8
+#define DM_ZX296718_GMAC 9
+#define DM_ZX296718_TS 10
+#define DM_ZX296718_VOU 11
+
+#endif /* _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v6 2/5] MAINTAINERS: add zx2967 SoC drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie@linaro.org>
Add the ZTE SoC drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
By the way, this patch adds the maintainer for ARM
ZTE architecture to Baoyou Xie.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ad199da..2593296 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1975,12 +1975,17 @@ F: arch/arm/mach-pxa/include/mach/z2.h
ARM/ZTE ARCHITECTURE
M: Jun Nie <jun.nie@linaro.org>
+M: Baoyou Xie <baoyou.xie@linaro.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
+F: drivers/soc/zte/
+F: drivers/thermal/zx*
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/soc/zte/
+F: include/dt-bindings/soc/zx*.h
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@xilinx.com>
--
2.7.4
^ permalink raw reply related
* [PATCH v6 1/5] dt-bindings: zte: documents zx2967 power domain driver bindings
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: linux-arm-kernel
This patch documents devicetree tree bindings for the ZTE zx2967
power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
diff --git a/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
new file mode 100644
index 0000000..1476318
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
@@ -0,0 +1,17 @@
+* ZTE 2967 SoC Power Domains
+
+2967 processors include support for multiple power domains which are used
+to gate power to one or more peripherals on the processor.
+
+Required Properties:
+- compatible: should be one of the following.
+ * zte,zx296718-pcu - for zx296718 board's power domain.
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+Example:
+
+ pcu_domain: pcu at 0x00117000 {
+ compatible = "zte,zx296718-pcu";
+ reg = <0x00117000 0x1000>;
+ };
--
2.7.4
^ permalink raw reply related
* [QUESTION] Arm64: Query L3 cache info via DT
From: Sudeep Holla @ 2017-01-04 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58633494.9030708@huawei.com>
Hi Tan,
On 28/12/16 03:42, Tan Xiaojun wrote:
> Hi.
>
> I saw you discussed how to achieve querying cache information and
> tend to implement the external ones(like L3 cache) via DT a few
> months ago.
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405399.html
>
> Are these implementations progressing? Forgive me to take the
> liberty to ask, we care about this thing.
>
Yes the support to override the cache properties for DT was added in v4.10
However, it still depends on the the sysreg to get the total levels of
caches supported in the system. You may need to tweak a bit around that
to support what you need.
> If you've already implemented some codes, we can help with testing
> (in Hisilicon D02, D03, D05) after you send it to the mail-list.
>
Sure, that would help.
> We can try our best to help if there is any difficulty.
OK, you can start trying the patch below :). It's not even compile
tested, so you make have to make some changes necessary. I just wanted
to put my thoughts here. Make sure all the L3 cacheinfo is present in DT.
Regards,
Sudeep
--
diff --git i/arch/arm64/kernel/cacheinfo.c w/arch/arm64/kernel/cacheinfo.c
index 9617301f76b5..88fbcd368104 100644
--- i/arch/arm64/kernel/cacheinfo.c
+++ w/arch/arm64/kernel/cacheinfo.c
@@ -84,7 +84,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
static int __init_cache_level(unsigned int cpu)
{
- unsigned int ctype, level, leaves;
+ unsigned int ctype, level, leaves, of_level;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
@@ -97,6 +97,17 @@ static int __init_cache_level(unsigned int cpu)
leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
}
+ of_level = of_count_cache_levels(cpu);
+ if (level < of_level) {
+ /*
+ * some external caches not specified in CLIDR_EL1
+ * the information may be available in the device tree
+ * only unified external caches are considered here
+ */
+ level = of_level;
+ leaves += (of_level - level);
+ }
+
this_cpu_ci->num_levels = level;
this_cpu_ci->num_leaves = leaves;
return 0;
diff --git i/drivers/of/base.c w/drivers/of/base.c
index d4bea3c797d6..8007f3b06cb8 100644
--- i/drivers/of/base.c
+++ w/drivers/of/base.c
@@ -2267,6 +2267,20 @@ struct device_node *of_find_next_cache_node(const
struct device_node *np)
return NULL;
}
+int of_count_cache_levels(unsigned int cpu)
+{
+ int level = 0;
+ struct device *cpu_dev = get_cpu_device(cpu);
+ struct device_node *np = cpu_dev->of_node;
+
+ while (np) {
+ level++;
+ np = of_find_next_cache_node(np);
+ }
+
+ return level;
+}
+
/**
* of_graph_parse_endpoint() - parse common endpoint node properties
* @node: pointer to endpoint device_node
diff --git i/include/linux/of.h w/include/linux/of.h
index d72f01009297..c8597ae71ff3 100644
--- i/include/linux/of.h
+++ w/include/linux/of.h
@@ -280,6 +280,7 @@ extern struct device_node
*of_get_child_by_name(const struct device_node *node,
/* cache lookup */
extern struct device_node *of_find_next_cache_node(const struct
device_node *);
+extern int of_count_cache_levels(unsigned int cpu);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
^ permalink raw reply related
* [PATCH v2 2/2] arm: perf: Mark as non-removable
From: Mark Rutland @ 2017-01-04 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104114056.GO14217@n2100.armlinux.org.uk>
On Wed, Jan 04, 2017 at 11:40:56AM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 04, 2017 at 11:30:25AM +0000, Mark Rutland wrote:
> > On Wed, Jan 04, 2017 at 10:19:46AM +0100, Alexander Stein wrote:
> > > I'm not sure if the change above works with remove functions set in struct
> > > bus_type too.
> > > But on the other hand this would hide errors in drivers which are actually
> > > removable but do not cleanup properly which DEBUG_TEST_DRIVER_REMOVE tries to
> > > detect.
> > > By setting .suppress_bind_attrs = true explicitely you state "This
> > > driver cannot be removed!", so the remove callback is not missing by accident.
> >
> > I'm not sure I follow. If the remove callback is accidentally missing,
> > the driver is not "actually removable" today -- there's either no remove
> > code, or it's not been wired up (the latter of which will likely result
> > in a compiler warning about an unused function).
> >
> > Aborting the remove early in those cases is much safer than forcefully
> > removing a driver without a remove callback.
>
> Drivers without a remove function may be removable - there's more layers
> than just the driver - there's the bus layer as well, which may or may
> not direct to a private-bus pointer.
Sure; which is why I initially suggested doing something at the bus
layer. That way, each layer could do any necessary check, and/or
delegate to a callback for the layer below.
> There's no real way for the core driver model code to know whether the
> lack of the ->remove in the struct device_driver is something that
> prevents a driver being removed, or whether it's handled via some other
> method. Eg, platform drivers.
While true today, my suggestion is to add the infrastrucutre such that
it can. That seems nicer to me than each driver having to retain
(redundant) state.
Regardless, this patch itself is fine.
Thanks,
Mark.
^ permalink raw reply
* [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64
From: Will Deacon @ 2017-01-04 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3de65da-8a74-2510-268e-34516cc2de77@redhat.com>
On Tue, Jan 03, 2017 at 03:25:53PM -0800, Laura Abbott wrote:
> On 01/03/2017 02:56 PM, Florian Fainelli wrote:
> > On 01/03/2017 09:21 AM, Laura Abbott wrote:
> >> Happy New Year!
> >>
> >> This is a very minor rebase from v5. It only moves a few headers around.
> >> I think this series should be ready to be queued up for 4.11.
> >
> > FWIW:
> >
> > Tested-by: Florian Fainelli <f.fainelli@gmail.com>
> >
>
> Thanks!
>
> > How do we get this series included? I would like to get the ARM 32-bit
> > counterpart included as well (will resubmit rebased shortly), but I have
> > no clue which tree this should be going through.
> >
>
> I was assuming this would go through the arm64 tree unless Catalin/Will
> have an objection to that.
Yup, I was planning to pick it up for 4.11.
Florian -- does your series depend on this? If so, then I'll need to
co-ordinate with Russell (probably via a shared branch that we both pull)
if you're aiming for 4.11 too.
Will
^ permalink raw reply
* [PATCH] rtc: armada38x: add __ro_after_init to armada38x_rtc_ops
From: Julia Lawall @ 2017-01-04 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104110750.dtu54t74qkuuvkvq@piout.net>
> The question was whether the point to the rtc_class_ops could be made
> __ro_after_init. And Russell is right, it is pointed to by the ops
> pointer in a struct rtc_device and that struct is dynamically allocated
> in rtc_device_register().
OK, I think it's a terminology issue. You mean the structure that
contains the pointer, and not the pointer itself, which is already const.
thanks,
julia
^ permalink raw reply
* [PATCH v2 2/2] arm: perf: Mark as non-removable
From: Russell King - ARM Linux @ 2017-01-04 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104113025.GE8329@leverpostej>
On Wed, Jan 04, 2017 at 11:30:25AM +0000, Mark Rutland wrote:
> On Wed, Jan 04, 2017 at 10:19:46AM +0100, Alexander Stein wrote:
> > I'm not sure if the change above works with remove functions set in struct
> > bus_type too.
> > But on the other hand this would hide errors in drivers which are actually
> > removable but do not cleanup properly which DEBUG_TEST_DRIVER_REMOVE tries to
> > detect.
> > By setting .suppress_bind_attrs = true explicitely you state "This
> > driver cannot be removed!", so the remove callback is not missing by accident.
>
> I'm not sure I follow. If the remove callback is accidentally missing,
> the driver is not "actually removable" today -- there's either no remove
> code, or it's not been wired up (the latter of which will likely result
> in a compiler warning about an unused function).
>
> Aborting the remove early in those cases is much safer than forcefully
> removing a driver without a remove callback.
Drivers without a remove function may be removable - there's more layers
than just the driver - there's the bus layer as well, which may or may
not direct to a private-bus pointer.
There's no real way for the core driver model code to know whether the
lack of the ->remove in the struct device_driver is something that
prevents a driver being removed, or whether it's handled via some other
method. Eg, platform drivers.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v4 5/5] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
From: Lee Jones @ 2017-01-04 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-6-andrew@aj.id.au>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> The Aspeed SoC Display Controller is presented as a syscon device to
> arbitrate access by display and pinmux drivers. Video pinmux
> configuration on fifth generation SoCs depends on bits in both the
> System Control Unit and the Display Controller.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> new file mode 100644
> index 000000000000..aea5370efd97
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> @@ -0,0 +1,17 @@
> +* Device tree bindings for Aspeed SoC Display Controller (GFX)
> +
> +The Aspeed SoC Display Controller primarily does as its name suggests, but also
> +participates in pinmux requests on the g5 SoCs. It is therefore considered a
> +syscon device.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-gfx", "syscon"
> +- reg: contains offset/length value of the GFX memory
> + region.
> +
> +Example:
> +
> +gfx: display at 1e6e6000 {
> + compatible = "aspeed,ast2500-gfx", "syscon";
> + reg = <0x1e6e6000 0x1000>;
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox