* [PATCH 1/3][v2] dt-bindings: Add compatible for LS2088A QDS and RDB boards
From: Rob Herring @ 2016-12-03 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480325824-14649-2-git-send-email-abhimanyu.saini@nxp.com>
On Mon, Nov 28, 2016 at 03:07:02PM +0530, Abhimanyu Saini wrote:
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 11 +++++++++++
> 1 file changed, 11 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: PRM: Delete an error message for a failed memory allocation
From: SF Markus Elfring @ 2016-12-03 20:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 3 Dec 2016 21:46:02 +0100
Omit an extra message for a memory allocation failure in this function.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/arm/mach-omap2/prm_common.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 5b2f5138d938..2b138b65129a 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -295,10 +295,8 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
GFP_KERNEL);
if (!prcm_irq_chips || !prcm_irq_setup->saved_mask ||
- !prcm_irq_setup->priority_mask) {
- pr_err("PRCM: kzalloc failed\n");
+ !prcm_irq_setup->priority_mask)
goto err;
- }
memset(mask, 0, sizeof(mask));
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 0/8] drivers: net: xgene: Add Jumbo and Pause frame support
From: David Miller @ 2016-12-03 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480639304-18757-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Thu, 1 Dec 2016 16:41:36 -0800
> This patch set adds,
>
> 1. Jumbo frame support
> 2. Pause frame based flow control
>
> and fixes RSS for non-TCP/UDP packets.
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Series applied, thanks.
^ permalink raw reply
* [SPCR] mmio32 iotype access requirements for X-Gene 8250(_dw) UART
From: Jon Masters @ 2016-12-03 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480785308.4751.41.camel@redhat.com>
Hi Mark,
On 12/03/2016 12:15 PM, Mark Salter wrote:
> On Sat, 2016-12-03 at 05:06 -0500, Jon Masters wrote:
>> There is a broader problem with X-Gene SPCR support. The problem is
>> that the 16550 UART in X-Gene requires the 32-bit access quirk (the
>> iotype is set to UPIO_MEM32 for the APMC0D08 device). This means
>> that when univ8250_console_match runs later, it will compare the
>> iotype (MEM32) with the type previously registered with the
>> kernel when the earlycon setup the preferred console.
>
> Linaro has a kernel patch which looks at the bit_width field of the
> port address:
>
> Author: Aleksey Makarov <aleksey.makarov@linaro.org>
> Date: Thu Apr 28 19:52:38 2016 +0300
>
> serial: SPCR: check bit width for the 16550 UART
>
> The SPCR in 3.06.25 firmware has a bit_width field set to 32 and with the
> above patch, I don't need to use console=. But HP firmware on m400 sets
> bit width to 8 so that needs a firmware fix to work with above.
Indeed, thanks. Graeme also mentioned that last night. I think this
a good solution for the moment, but still that it makes sense to
have a new 16650 UART type defined in the DBG2 spec for those
requiring 32-bit access (to mirror the type D for pl011). I
heard back from Microsoft this morning that they're looking.
Jon.
--
Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
* [PATCH v5] PM/devfreq: add suspend frequency support
From: Pavel Machek @ 2016-12-03 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478599598-26015-1-git-send-email-hl@rock-chips.com>
Hi!
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 98c6993..8567153 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -172,6 +172,7 @@ struct devfreq {
> struct delayed_work work;
>
> unsigned long previous_freq;
> + unsigned long suspend_freq;
> struct devfreq_dev_status last_status;
>
> void *data; /* private data for governors */
> @@ -179,6 +180,7 @@ struct devfreq {
> unsigned long min_freq;
> unsigned long max_freq;
> bool stop_polling;
> + bool suspend_flag;
>
> /* information for device frequency transition */
> unsigned int total_trans;
It would be nice to comment what "suspend_flag" is... plus... Would it
be possible to rename suspend_freq or suspend_flag? They are really
really similar visually...
Thanks.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161203/6d21481d/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Stefan Schmidt @ 2016-12-03 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161203175513.499a3affbb3e4a0640997f82@ao2.it>
Hello.
On 03.12.2016 17:55, Antonio Ospite wrote:
> On Sat, 26 Nov 2016 00:30:52 +0100
> Stefan Schmidt <stefan@datenfreihafen.org> wrote:
>
>> Hello.
>>
>
> Hi everyone,
>
>> On 25.11.2016 20:53, Robert Jarzmik wrote:
>>> Stefan Schmidt <stefan@datenfreihafen.org> writes:
>>>
>>>> Hello.
>>>>
>>>> On 24.11.2016 17:29, Arnd Bergmann wrote:
>>>>> The camera_supply_dummy_device definition is shared between a780 and a910,
>>>>> but only provided when the first is enabled and fails to build for a
>>>>> configuration with only a910:
>>>>>
>>>>> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
>>>>>
>>>>> This moves the definition into its own section.
>>>>>
>>>>> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
>>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>>>> ---
>>>>> arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
>>>>
>>>> I wonder what we should do with ezx.c.
>>>>
>>>> As far as I know neither Daniel nor Harald or myself are doing anything
>>>> with this devices anymore. Besides a basic compile test having an ack or
>>>> reviewed by from our side is a bit worthless. :/
>>>>
>>>> I should still have some of these phones around in a box somewhere. If
>>>> there is someone with a good motivation and time to take over on this
>>>> platform we will find a way to get the person this devices.
>>>>
>>>> Any takers? Robert? I guess you are already overloaded but you might
>>>> also have an interest. Worth asking :)
>>> Oh yes, I'm very interested in your box. Besides I really like old platforms
>>> :)
>>
>>
>> Great! I should have at least 3 or 4 different devices from the EZX
>> platform around. I will go and search for the box over the weekend :)
>>
>>>> In the case nobody wants to pick up here what would you consider the
>>>> bets way forward? I could send a patch removing ezx platform support
>>>> from the kernel (basically ezx.c plus build support) or I can send a
>>>> patch marking it at least orphan in MAINTAINERS. Let me know what you think.
>>>>
>>>> Daniel, Harald, if one of you is still interested in these and what to
>>>> pick up the work again, please speak up now. :)
>>> Unless another maintainer steps in, you can submit a patch to transfer the
>>> maintainance onto me, and we'll see off mailing lists how we could arange the
>>> boards transfer.
>>
>> I cc'ed another developer who did a lot of work regarding EZX.
>>
>> Antonio, as you can see from the mail above we are pondering what who
>> will maintain the ezx platform in the kernel going forward. Neither
>> Daniel, Harald or me is going to do so. If you have time, interest and
>> motivation to do so please speak up. I know life moved on and you ahve
>> other projects and interests so do not feel pressured here. Just say no
>> if you have no interest. Robert already agreed to act as a fallback so
>> we would still be safe. :)
>>
>
> I still use a Motorola A1200 with the original EZX stack as my main
> phone (and that tells something about how much I use a phone...)
hehe :)
> however I haven't touched any OpenEZX stuff in a while.
>
> I don't think I am going to play with these devices anytime soon, but I
> can provide Robert any info he may need about OpenEZX, the development
> tools and the out-of-tree patches required to make the phones somewhat
> usable.
Great. I think this will be a great help for Robert when he tries to get
things going. Thanks a lot!
Robert, please send me your address details off list so we can arrange
for the device shipping. I will send a patch transferring the
maintainership for the EZX platform over to you in the next days.
regards
Stefan Schmidt
^ permalink raw reply
* [SPCR] mmio32 iotype access requirements for X-Gene 8250(_dw) UART
From: Mark Salter @ 2016-12-03 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7fa523de-3fbb-1566-f521-927143f73d1e@redhat.com>
On Sat, 2016-12-03 at 05:06 -0500, Jon Masters wrote:
> Hi Duc, all,
>
> (and changing the subject and trimming/adjusting the CC)
>
> On 12/02/2016 02:39 PM, Duc Dang wrote:
> >
> > On Fri, Dec 2, 2016 at 12:11 AM, Jon Masters <jcm@redhat.com> wrote:
> > >
> > > You're welcome.
> > >
> > > (Unrelated) Note that I added a console= and earlycon in my test (and
> > > got the baud rate wrong for the console but nevermind...was ssh'd in
> > > after the earlycon output I cared about anyway) because of some other
> > > cleanup work for the SPCR parsing that apparently is still not quite
> > > fixed for upstream, or rather, there is a need to match on the 32-bit
> > > access required for the UART and that isn't happening so it's not
> > > getting setup. Folks are tracking that one and fixing it though.
> >
> > I don't see this console issue on X-Gene1 (Mustang board). I tried
> > with X-Gene 2 as well. I used both console=ttyS0,115200 and
> > earlycon=uart8250,mmio32,0x1c020000. Are you setting baudrate to
> > 115200 or something else?
> Let me clarify. What I meant above is that when I generated the boot
> log, I had specified earlycon and console parameters, but had fat
> fingered the baud rate (m400 uses 9600, mustang uses 115200 baud).
> That's what I was referring to in the original text above.
>
> HOWEVER...
>
> There is a broader problem with X-Gene SPCR support. The problem is
> that the 16550 UART in X-Gene requires the 32-bit access quirk (the
> iotype is set to UPIO_MEM32 for the APMC0D08 device). This means
> that when univ8250_console_match runs later, it will compare the
> iotype (MEM32) with the type previously registered with the
> kernel when the earlycon setup the preferred console.
Linaro has a kernel patch which looks at the bit_width field of the
port address:
Author: Aleksey Makarov <aleksey.makarov@linaro.org>
Date:???Thu Apr 28 19:52:38 2016 +0300
????serial: SPCR: check bit width for the 16550 UART
The SPCR in 3.06.25 firmware has a bit_width field set to 32 and with the
above patch, I don't need to use console=. But HP firmware on m400 sets
bit width to 8 so that needs a firmware fix to work with above.
>
> The earlycon preferred console will parse the SPCR and find:
>
> ????????iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ?
> ????????????????????????"mmio" : "io";
>
> Which sets it to "mmio" (not "mmio32"). There is a DBG2 (the table
> referenced by the SPCR that provides the actual port types for all
> modern revisions of the SPCR with revision2+, as required by Linux)
> port subtype for non-compliant SBSA ARM Generic UARTs that require
> 32-bit accesses, and this is ACPI_DBG2_ARM_SBSA_32BIT (type 0xd).
>
> However that only applies for "pl011" devices, and doesn't provide
> for 16550 UARTs that require 32-bit accessors.
>
> So you'll end up with Linux thinking it's registering a non-32-bit
> mmio preferred console during earlycon setup and then never match
> against that later in the 8250_core/8250_dw match function by
> virtue of the fact that these differ.
>
> There are a couple of possibilities:
>
> 1). Perhaps (for some reason) the IP actually does support sub-32-bit
> ????access and the iotype simply needs to be changed to reflect this.
> ????That would be the easiest option. But it's been this way for a
> ????long time in various codebases, so I would be pleasantly
> ????surprised if this were the case. Let me/us know :)
>
> 2). We find some way during SPCR setup to quirk for X-Gene as a non
> ????standard 16550 and set it up as an mmio32 iotype.
>
> 3). We get the DBG2 table updated to add a subtype of the 16650
> ????called something like "(deprecated) 16550 subset supporting
> ????only 32-bit accesses". Then we add this to Linux and get
> ????the firmware updated on systems to switch to this type. We
> ????would probably still want to quirk for existing machines.
>
> Perhaps I'm missing something. I would love for that to be true,
> but I don't think it is. I think we need a subtype of the 16550
> defined that encapsulates this mmio32 requirement properly. To
> that end, I've preemptively asked some friends at MS for a
> favor to look into adding a new subtype for this.
>
> Let me know what you think is the best path... :)
>
> Thanks,
>
> Jon.
>
^ permalink raw reply
* [GIT PULL 1/3] ARM: exynos: Soc/mach for v4.10
From: Krzysztof Kozlowski @ 2016-12-03 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57568492.9hbg5JCdec@wuerfel>
On Fri, Dec 02, 2016 at 10:52:57PM +0100, Arnd Bergmann wrote:
> On Thursday, December 1, 2016 8:34:04 PM CET Krzysztof Kozlowski wrote:
> > On Thu, Nov 24, 2016 at 08:08:27AM +0200, Krzysztof Kozlowski wrote:
> > > Hi,
> > >
> > > This contains previous dts branch because SCU node in dts is needed
> > > prior to removing it from mach code.
> > >
> > > Below you will find full pull request and one stripped from dependency.
> > >
> >
> > Hi Arnd, Kevin and Olof,
> >
> > What about this pull from the set?
> >
>
> Sorry, I initially deferred it and then didn't get back to it.
>
> The dependency on the .dts changes made me a bit nervous about
> taking it, mostly because the changelog fails to explain the
> exact dependencies.
>
> This breaks compatibility with existing .dtb files, right?
No, strictly speaking not. There was no dt-bindings change here, no DT
properties for SCU before. We are converting our drivers to DTB so this
is the same as before when switching for pinctrl, clocks or all other
drivers to DT.
We are not braking DTB ABI because there was no ABI around it before.
Otherwise, one would say that lack of SCU DT node was an ABI. That is
wrong, because DT should describe the hardware and SCU is in hardware.
> What I'd like to see here is an explanation about:
>
> - what the upside of breaking compatibility is
DTBs which do not have SCU are not proper because they skip that part of
hardware. However we are breaking them in the way the SMP won't work
there. It is not an ABI break, as I mentioned above.
> - what exactly stops working with an old dtb
> - why we don't keep a fallback for handling old dtb files
What is the point for it? This is not an ABI break. Even if it was,
Samsung guys don't care for ABI breaks at all (and in fact we wanted to
mark the platform experimental...).
> It would also be helpful to have a separate pull request for
> the commits require the new dtb, and the stuff that is unrelated.
I can do that but the pull will be small.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] ARM: mmp: Delete an unnecessary variable initialisation in sram_probe()
From: SF Markus Elfring @ 2016-12-03 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b687577b-e664-6aa1-a85c-438e96216171@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 3 Dec 2016 17:38:21 +0100
The local variable "ret" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/arm/mach-mmp/sram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
index 0fbfc2a42ab3..260e8309dfd3 100644
--- a/arch/arm/mach-mmp/sram.c
+++ b/arch/arm/mach-mmp/sram.c
@@ -66,7 +66,7 @@ static int sram_probe(struct platform_device *pdev)
struct sram_platdata *pdata = pdev->dev.platform_data;
struct sram_bank_info *info;
struct resource *res;
- int ret = 0;
+ int ret;
if (!pdata || !pdata->pool_name)
return -ENODEV;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] ARM: mmp: Check return values from ioremap() and kstrdup() in sram_probe()
From: SF Markus Elfring @ 2016-12-03 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b687577b-e664-6aa1-a85c-438e96216171@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 3 Dec 2016 17:26:32 +0100
Two return values were not checked before their further use so far.
This issue was detected by using the Coccinelle software.
* Add a bit of exception handling.
* Adjust tump targets.
Fixes: 3c7241bd36e2a618fe20c91f6c69cc20f2d981f2 ("ARM: mmp: add sram allocator")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/arm/mach-mmp/sram.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
index bf5e64906e65..0fbfc2a42ab3 100644
--- a/arch/arm/mach-mmp/sram.c
+++ b/arch/arm/mach-mmp/sram.c
@@ -88,14 +88,24 @@ static int sram_probe(struct platform_device *pdev)
info->sram_phys = (phys_addr_t)res->start;
info->sram_size = resource_size(res);
info->sram_virt = ioremap(info->sram_phys, info->sram_size);
+ if (!info->sram_virt) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
info->pool_name = kstrdup(pdata->pool_name, GFP_KERNEL);
+ if (!info->pool_name) {
+ ret = -ENOMEM;
+ goto unmap_io;
+ }
+
info->granularity = pdata->granularity;
info->gpool = gen_pool_create(ilog2(info->granularity), -1);
if (!info->gpool) {
dev_err(&pdev->dev, "create pool failed\n");
ret = -ENOMEM;
- goto create_pool_err;
+ goto free_name;
}
ret = gen_pool_add_virt(info->gpool, (unsigned long)info->sram_virt,
@@ -117,9 +127,10 @@ static int sram_probe(struct platform_device *pdev)
add_chunk_err:
gen_pool_destroy(info->gpool);
-create_pool_err:
- iounmap(info->sram_virt);
+free_name:
kfree(info->pool_name);
+unmap_io:
+ iounmap(info->sram_virt);
out:
kfree(info);
return ret;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/2] ARM: mmp: Fine-tuning for sram_probe()
From: SF Markus Elfring @ 2016-12-03 16:57 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 3 Dec 2016 17:50:23 +0100
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Check return values from ioremap() and kstrdup()
Delete an unnecessary variable initialisation
arch/arm/mach-mmp/sram.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Antonio Ospite @ 2016-12-03 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <df32cbf6-e897-56d9-89d8-c65af06323a8@datenfreihafen.org>
On Sat, 26 Nov 2016 00:30:52 +0100
Stefan Schmidt <stefan@datenfreihafen.org> wrote:
> Hello.
>
Hi everyone,
> On 25.11.2016 20:53, Robert Jarzmik wrote:
> > Stefan Schmidt <stefan@datenfreihafen.org> writes:
> >
> >> Hello.
> >>
> >> On 24.11.2016 17:29, Arnd Bergmann wrote:
> >>> The camera_supply_dummy_device definition is shared between a780 and a910,
> >>> but only provided when the first is enabled and fails to build for a
> >>> configuration with only a910:
> >>>
> >>> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
> >>>
> >>> This moves the definition into its own section.
> >>>
> >>> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
> >>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >>> ---
> >>> arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
> >>
> >> I wonder what we should do with ezx.c.
> >>
> >> As far as I know neither Daniel nor Harald or myself are doing anything
> >> with this devices anymore. Besides a basic compile test having an ack or
> >> reviewed by from our side is a bit worthless. :/
> >>
> >> I should still have some of these phones around in a box somewhere. If
> >> there is someone with a good motivation and time to take over on this
> >> platform we will find a way to get the person this devices.
> >>
> >> Any takers? Robert? I guess you are already overloaded but you might
> >> also have an interest. Worth asking :)
> > Oh yes, I'm very interested in your box. Besides I really like old platforms
> > :)
>
>
> Great! I should have at least 3 or 4 different devices from the EZX
> platform around. I will go and search for the box over the weekend :)
>
> >> In the case nobody wants to pick up here what would you consider the
> >> bets way forward? I could send a patch removing ezx platform support
> >> from the kernel (basically ezx.c plus build support) or I can send a
> >> patch marking it at least orphan in MAINTAINERS. Let me know what you think.
> >>
> >> Daniel, Harald, if one of you is still interested in these and what to
> >> pick up the work again, please speak up now. :)
> > Unless another maintainer steps in, you can submit a patch to transfer the
> > maintainance onto me, and we'll see off mailing lists how we could arange the
> > boards transfer.
>
> I cc'ed another developer who did a lot of work regarding EZX.
>
> Antonio, as you can see from the mail above we are pondering what who
> will maintain the ezx platform in the kernel going forward. Neither
> Daniel, Harald or me is going to do so. If you have time, interest and
> motivation to do so please speak up. I know life moved on and you ahve
> other projects and interests so do not feel pressured here. Just say no
> if you have no interest. Robert already agreed to act as a fallback so
> we would still be safe. :)
>
I still use a Motorola A1200 with the original EZX stack as my main
phone (and that tells something about how much I use a phone...)
however I haven't touched any OpenEZX stuff in a while.
I don't think I am going to play with these devices anytime soon, but I
can provide Robert any info he may need about OpenEZX, the development
tools and the out-of-tree patches required to make the phones somewhat
usable.
I have an off-line backup of the OpenEZX wiki as well if that should be
needed.
Robert, feel free to contact me off-list any time.
I also still hang out in the #openezx IRC channel on Freenode.
Ciao ciao,
Antonio
--
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
^ permalink raw reply
* [PATCH 2/2] soc: zte: pm_domains: Add support for zx296718 driver
From: Baoyou Xie @ 2016-12-03 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480774291-6211-1-git-send-email-baoyou.xie@linaro.org>
This patch introduces the power domain driver of zx296718
which belongs to zte's 2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/soc/zte/Makefile | 3 +
drivers/soc/zte/zx296718_pm_domains.c | 162 ++++++++++++++++++++++++++++++++++
2 files changed, 165 insertions(+)
create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
index 97ac8ea..a6e7bfe 100644
--- a/drivers/soc/zte/Makefile
+++ b/drivers/soc/zte/Makefile
@@ -2,3 +2,6 @@
# zx SOC drivers
#
obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o
+ifeq ($(CONFIG_ZX_PM_DOMAINS), y)
+ obj-y += zx296718_pm_domains.o
+endif
diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
new file mode 100644
index 0000000..fc16dfd
--- /dev/null
+++ b/drivers/soc/zte/zx296718_pm_domains.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright (C) 2015 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include "pm_domains.h"
+
+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 zx_pm_domain vou_domain = {
+ .dm = {
+ .name = "vou_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VOU,
+};
+static struct zx_pm_domain sappu_domain = {
+ .dm = {
+ .name = "sappu_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_SAPPU,
+};
+static struct zx_pm_domain vde_domain = {
+ .dm = {
+ .name = "vde_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VDE,
+};
+static struct zx_pm_domain vce_domain = {
+ .dm = {
+ .name = "vce_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VCE,
+};
+static struct zx_pm_domain hde_domain = {
+ .dm = {
+ .name = "hde_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_HDE,
+};
+
+static struct zx_pm_domain viu_domain = {
+ .dm = {
+ .name = "viu_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VIU,
+};
+static struct zx_pm_domain usb20_domain = {
+ .dm = {
+ .name = "usb20_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_USB20,
+};
+static struct zx_pm_domain usb21_domain = {
+ .dm = {
+ .name = "usb21_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_USB21,
+};
+static struct zx_pm_domain usb30_domain = {
+ .dm = {
+ .name = "usb30_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_USB30,
+};
+static struct zx_pm_domain hsic_domain = {
+ .dm = {
+ .name = "hsic_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_HSIC,
+};
+static struct zx_pm_domain gmac_domain = {
+ .dm = {
+ .name = "gmac_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_GMAC,
+};
+static struct zx_pm_domain ts_domain = {
+ .dm = {
+ .name = "ts_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_TS,
+};
+struct generic_pm_domain *zx296718_pm_domains[] = {
+ //&vou_domain.dm,
+ &sappu_domain.dm,
+ &vde_domain.dm,
+ &vce_domain.dm,
+ &hde_domain.dm,
+ &viu_domain.dm,
+ &usb20_domain.dm,
+ &usb21_domain.dm,
+ &usb30_domain.dm,
+ &hsic_domain.dm,
+ &gmac_domain.dm,
+ &ts_domain.dm,
+ &vou_domain.dm,
+};
+
+static int zx296718_pd_probe(struct platform_device *pdev)
+{
+ return zx_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 1/2] soc: zte: pm_domains: Prepare for supporting ARMv8 2967 family
From: Baoyou Xie @ 2016-12-03 14:11 UTC (permalink / raw)
To: linux-arm-kernel
The ARMv8 2967 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, it's privated by
the drivers of boards.
This patch prepares the common functions.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 1 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/zte/Kconfig | 13 ++++
drivers/soc/zte/Makefile | 4 ++
drivers/soc/zte/pm_domains.c | 138 +++++++++++++++++++++++++++++++++++++++++++
drivers/soc/zte/pm_domains.h | 29 +++++++++
7 files changed, 187 insertions(+)
create mode 100644 drivers/soc/zte/Kconfig
create mode 100644 drivers/soc/zte/Makefile
create mode 100644 drivers/soc/zte/pm_domains.c
create mode 100644 drivers/soc/zte/pm_domains.h
diff --git a/MAINTAINERS b/MAINTAINERS
index ad199da..8198389 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1979,6 +1979,7 @@ 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: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
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..4953c3fa
--- /dev/null
+++ b/drivers/soc/zte/Kconfig
@@ -0,0 +1,13 @@
+#
+# zx SoC drivers
+#
+menuconfig SOC_ZX
+ bool "zx SoC driver support"
+
+if SOC_ZX
+
+config ZX_PM_DOMAINS
+ bool "zx 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..97ac8ea
--- /dev/null
+++ b/drivers/soc/zte/Makefile
@@ -0,0 +1,4 @@
+#
+# zx SOC drivers
+#
+obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o
diff --git a/drivers/soc/zte/pm_domains.c b/drivers/soc/zte/pm_domains.c
new file mode 100644
index 0000000..5792f21
--- /dev/null
+++ b/drivers/soc/zte/pm_domains.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2015 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 "pm_domains.h"
+
+#define PCU_DM_CLKEN 0x18
+#define PCU_DM_RSTEN 0x20
+#define PCU_DM_ISOEN 0x1c
+#define PCU_DM_PWREN 0x24
+#define PCU_DM_ACK_SYNC 0x28
+
+static void __iomem *pcubase;
+
+int zx_normal_power_on(struct generic_pm_domain *domain)
+{
+ struct zx_pm_domain *zpd = (struct zx_pm_domain *)domain;
+ unsigned long loop = 20000;
+ u32 val;
+
+ loop = 1000;
+ do {
+ val = readl_relaxed(pcubase + PCU_DM_PWREN);
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN);
+
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC) & 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);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val | BIT(zpd->bit), pcubase + PCU_DM_RSTEN);
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN);
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val | BIT(zpd->bit), pcubase + PCU_DM_CLKEN);
+ udelay(5);
+
+ pr_info("normal poweron %s\n", domain->name);
+
+ return 0;
+}
+
+int zx_normal_power_off(struct generic_pm_domain *domain)
+{
+ struct zx_pm_domain *zpd = (struct zx_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN);
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val | BIT(zpd->bit), pcubase + PCU_DM_ISOEN);
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN);
+ udelay(5);
+
+ loop = 1000;
+ do {
+ val = readl_relaxed(pcubase + PCU_DM_PWREN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN);
+
+ udelay(1);
+
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC) & BIT(zpd->bit);
+ } while (--loop && val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ pr_info("normal poweroff %s\n", domain->name);
+
+ return 0;
+}
+
+int
+zx_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);
+ if (!res) {
+ dev_err(&pdev->dev, "no memory resource defined\n");
+ return -ENODEV;
+ }
+
+ pcubase = devm_ioremap_resource(&pdev->dev, res);
+ if (!pcubase) {
+ dev_err(&pdev->dev, "ioremap fail.\n");
+ return -EIO;
+ }
+
+ for (i = 0; i < domain_num; ++i)
+ 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/pm_domains.h b/drivers/soc/zte/pm_domains.h
new file mode 100644
index 0000000..613e0be
--- /dev/null
+++ b/drivers/soc/zte/pm_domains.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2015 ZTE Co., Ltd.
+ * http://www.zte.com.cn
+ *
+ * Header for ZTE's Power Domain Driver support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ZTE_PM_DOMAIN_H
+#define __ZTE_PM_DOMAIN_H
+
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+
+struct zx_pm_domain {
+ struct generic_pm_domain dm;
+ unsigned int bit;
+};
+
+extern int zx_normal_power_on(struct generic_pm_domain *domain);
+extern int zx_normal_power_off(struct generic_pm_domain *domain);
+extern int
+zx_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num);
+#endif /* __ZTE_PM_DOMAIN_H */
--
2.7.4
^ permalink raw reply related
* [arm64:for-next/core 52/52] arch/arm64/include/asm/probes.h:18:25: fatal error: asm/opcodes.h: No such file or directory
From: Marc Zyngier @ 2016-12-03 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86h96lmh5p.fsf@arm.com>
On Sat, 03 Dec 2016 10:38:26 +0000
Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Fri, Dec 02 2016 at 10:05:27 PM, kbuild test robot <fengguang.wu@intel.com> wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
> > head: bca8f17f57bd76ddf2bbd2527eb890d6f588853e
> > commit: bca8f17f57bd76ddf2bbd2527eb890d6f588853e [52/52] arm64: Get rid of asm/opcodes.h
> > config: arm64-allmodconfig (attached as .config)
> > compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> > reproduce:
> > wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout bca8f17f57bd76ddf2bbd2527eb890d6f588853e
> > # save the attached .config to linux build tree
> > make.cross ARCH=arm64
> >
> > All errors (new ones prefixed by >>):
> >
> > In file included from arch/arm64/include/asm/uprobes.h:14:0,
> > from include/linux/uprobes.h:61,
> > from include/linux/mm_types.h:13,
> > from include/linux/sched.h:27,
> > from arch/arm64/kernel/asm-offsets.c:21:
> >>> arch/arm64/include/asm/probes.h:18:25: fatal error: asm/opcodes.h: No such file or directory
> > #include <asm/opcodes.h>
> > ^
> > compilation terminated.
> > make[2]: *** [arch/arm64/kernel/asm-offsets.s] Error 1
> > make[2]: Target '__build' not remade because of errors.
> > make[1]: *** [prepare0] Error 2
> > make[1]: Target 'prepare' not remade because of errors.
> > make: *** [sub-make] Error 2
>
> Blah. Bloody uprobes. Just deleting this line should be enough, as I
> can't see anything that actually depends on what is in the 32bit
> asm/opcodes.h.
>
> I can submit a patch if needed.
Well, another (slightly more serious) bug has cropped up, so I just sent
a small patch series that addresses both.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH 2/2] arm64: alternatives: Work around NOP generation with broken assembler
From: Marc Zyngier @ 2016-12-03 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161203140538.23525-1-marc.zyngier@arm.com>
When compiling a .inst directive in an alternative clause with
a rather old version of gas (circa 2.24), and when used with
the alternative_else_nop_endif feature, the compilation fails
with a rather cryptic message such as:
arch/arm64/lib/clear_user.S:33: Error: bad or irreducible absolute expression
which is caused by the bug described in eb7c11ee3c5c ("arm64:
alternative: Work around .inst assembler bugs").
This effectively prevents the use of the "nops" macro, which
requires the number of instruction as a parameter (the assembler
is confused and unable to compute the difference between two labels).
As an alternative(!), use the .fill directive to output the number
of required NOPs (.fill has the good idea to output the fill pattern
in the endianness of the instruction stream).
Fixes: 792d47379f4d ("arm64: alternative: add auto-nop infrastructure")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/alternative.h | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index 39feb85..39f8c98 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -159,9 +159,19 @@ void apply_alternatives(void *start, size_t length);
* of NOPs. The number of NOPs is chosen automatically to match the
* previous case.
*/
+
+#define NOP_INST 0xd503201f
+
.macro alternative_else_nop_endif
alternative_else
- nops (662b-661b) / AARCH64_INSN_SIZE
+ /*
+ * The same assembler bug strikes again here if the first half
+ * of the alternative sequence contains a .inst, leading to a
+ * bizarre error message. Fortulately, .fill replaces the
+ * "nops" macro by inserting padding with the target machine
+ * endianness.
+ */
+ .fill (662b-661b) / AARCH64_INSN_SIZE, AARCH64_INSN_SIZE, NOP_INST
alternative_endif
.endm
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] arm64: Remove reference to asm/opcodes.h
From: Marc Zyngier @ 2016-12-03 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161203140538.23525-1-marc.zyngier@arm.com>
The asm/opcodes.h file is now gone, but probes.h still references it
for not obvious reason. Removing the #include directive fixes
the compilation.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/probes.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
index e175a82..6a5b289 100644
--- a/arch/arm64/include/asm/probes.h
+++ b/arch/arm64/include/asm/probes.h
@@ -15,8 +15,6 @@
#ifndef _ARM_PROBES_H
#define _ARM_PROBES_H
-#include <asm/opcodes.h>
-
typedef u32 probe_opcode_t;
typedef void (probes_handler_t) (u32 opcode, long addr, struct pt_regs *);
--
2.10.2
^ permalink raw reply related
* [PATCH 0/2] Fix fallouts from asm/opcodes.h removal
From: Marc Zyngier @ 2016-12-03 14:05 UTC (permalink / raw)
To: linux-arm-kernel
Since the asm/opcodes.h file was removed, two bugs have cropped up:
- probes.h contains a reference to asm/opcodes.h that was missed
- An ugly (and alas familiar) bug has reappeared, leading to obscure
compilation errors when a .inst is part of an alternative and that
the "auto nop" feature is used to pad the alternative sequence (and
the whole thing is assembled with an old version of gas). This is
triggered again now that we generate SET_PSTATE_PAN/UAO using .inst.
The first bug is easy to fix, while the second requires some really
ugly (if limited) surgery using the .fill directive to replace the
"nops" macro.
Marc Zyngier (2):
arm64: Remove reference to asm/opcodes.h
arm64: alternatives: Work around NOP generation with broken assembler
arch/arm64/include/asm/alternative.h | 12 +++++++++++-
arch/arm64/include/asm/probes.h | 2 --
2 files changed, 11 insertions(+), 3 deletions(-)
--
2.10.2
^ permalink raw reply
* ARM: topology: Checking for a failed kcalloc() in parse_dt_topology()?
From: SF Markus Elfring @ 2016-12-03 14:00 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Another run of a small script for the semantic patch language (Coccinelle)
pointed the implementation of the function ?parse_dt_topology? out for
further considerations.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm/kernel/topology.c?id=e05f574a0bb1f4502a4b2264fdb0ef6419cf3772#n285
Would it be useful to check the return value from a call of the
function ?kcalloc? also there?
Regards,
Markus
^ permalink raw reply
* [PATCH] arm64: dts: zte: clean up gic-v3 redistributor properties
From: Marc Zyngier @ 2016-12-03 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480768600-20827-1-git-send-email-shawnguo@kernel.org>
On Sat, 3 Dec 2016 20:36:40 +0800
Shawn Guo <shawnguo@kernel.org> wrote:
> The gic-v3 property redistributor-stride is only meant as a workaround
> for broken platforms that have a redistributor stride deviating what the
> architecture defines, i.e. 128KiB for GICv3, 256KiB for GICv4. This is
> not the case for ZX296718, and redistributor-stride is not really
> necessary. Let's drop it.
>
> Also, #redistributor-regions is only required when there is more than
> one such region is present. Let's remove it as well.
>
> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH] arm64: dts: zte: clean up gic-v3 redistributor properties
From: Shawn Guo @ 2016-12-03 12:36 UTC (permalink / raw)
To: linux-arm-kernel
The gic-v3 property redistributor-stride is only meant as a workaround
for broken platforms that have a redistributor stride deviating what the
architecture defines, i.e. 128KiB for GICv3, 256KiB for GICv4. This is
not the case for ZX296718, and redistributor-stride is not really
necessary. Let's drop it.
Also, #redistributor-regions is only required when there is more than
one such region is present. Let's remove it as well.
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 6b239a365f01..dd2cd73c774c 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -239,8 +239,6 @@
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <0>;
- #redistributor-regions = <1>;
- redistributor-stride = <0x20000>;
interrupt-controller;
reg = <0x02a00000 0x10000>,
<0x02b00000 0xc0000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v3 11/14] ACPI: irq: introduce interrupt producer
From: G Gregory @ 2016-12-03 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477408169-22217-12-git-send-email-guohanjun@huawei.com>
On Tue, Oct 25, 2016 at 11:09:26PM +0800, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> In ACPI 6.1 spec, section 19.6.62, Interrupt Resource Descriptor Macro,
>
> Interrupt (ResourceUsage, EdgeLevel, ActiveLevel, Shared,
> ResourceSourceIndex, ResourceSource, DescriptorName)
> { InterruptList } => Buffer
>
> For the arguement ResourceUsage and DescriptorName, which means:
>
> ResourceUsage describes whether the device consumes the specified
> interrupt ( ResourceConsumer ) or produces it for use by a child
> device ( ResourceProducer ).
> If nothing is specified, then ResourceConsumer is assumed.
>
> DescriptorName evaluates to a name string which refers to the
> entire resource descriptor.
>
> So it can be used for devices connecting to a specific interrupt
> prodcucer instead of the main interrupt controller in MADT. In the
> real world, we have irqchip such as mbi-gen which connecting to
> a group of wired interrupts and then issue msi to the ITS, devices
> connecting to such interrupt controller fit this scope.
>
> For now the irq for ACPI only pointer to the main interrupt
> controller's irqdomain, for devices not connecting to those
> irqdomains, which need to present its irq parent, we can use
> following ASL code to represent it:
>
> Interrupt(ResourceConsumer,..., "\_SB.IRQP") {12,14,....}
>
> then we can parse the interrupt producer with the full
> path name "\_SB.IRQP".
>
> In order to do that, we introduce a pointer interrupt_producer
> in struct acpi_device, and fill it when scanning irq resources
> for acpi device if it specifies the interrupt producer.
>
> But for now when parsing the resources for acpi devices, we don't
> pass the acpi device for acpi_walk_resoures() in drivers/acpi/resource.c,
> so introduce a adev in struct res_proc_context to pass it as a context
> to scan the interrupt resources, then finally pass to acpi_register_gsi()
> to find its interrupt producer to get the virq from diffrent domains.
>
> With steps above ready, rework acpi_register_gsi() to get other
> interrupt producer if devices not connecting to main interrupt
> controller.
>
> Since we often pass NULL to acpi_register_gsi() and there is no interrupt
> producer for devices connect to gicd on ARM or io-apic on X86, so it will
> use the default irqdomain for those deivces and no functional changes to
> those devices.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Agustin Vega-Frias <agustinv@codeaurora.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> drivers/acpi/gsi.c | 10 ++++--
> drivers/acpi/resource.c | 85 ++++++++++++++++++++++++++++++++++---------------
> include/acpi/acpi_bus.h | 1 +
> 3 files changed, 68 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
> index ee9e0f2..29ee547 100644
> --- a/drivers/acpi/gsi.c
> +++ b/drivers/acpi/gsi.c
> @@ -55,13 +55,19 @@ int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
> int polarity)
> {
> struct irq_fwspec fwspec;
> + struct acpi_device *adev = dev ? to_acpi_device(dev) : NULL;
>
> - if (WARN_ON(!acpi_gsi_domain_id)) {
> + if (adev && &adev->fwnode && adev->interrupt_producer)
> + /* devices in DSDT connecting to spefic interrupt producer */
> + fwspec.fwnode = adev->interrupt_producer;
> + else if (acpi_gsi_domain_id)
> + /* devices connecting to gicd in default */
> + fwspec.fwnode = acpi_gsi_domain_id;
> + else {
> pr_warn("GSI: No registered irqchip, giving up\n");
> return -EINVAL;
> }
>
> - fwspec.fwnode = acpi_gsi_domain_id;
> fwspec.param[0] = gsi;
> fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
> fwspec.param_count = 2;
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..f1371cf 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -381,7 +381,7 @@ static void acpi_dev_irqresource_disabled(struct resource *res, u32 gsi)
> res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> }
>
> -static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> +static void acpi_dev_get_irqresource(struct acpi_device *adev, struct resource *res, u32 gsi,
> u8 triggering, u8 polarity, u8 shareable,
> bool legacy)
> {
> @@ -415,7 +415,7 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> }
>
> res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> - irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
> + irq = acpi_register_gsi(&adev->dev, gsi, triggering, polarity);
> if (irq >= 0) {
> res->start = irq;
> res->end = irq;
> @@ -424,27 +424,9 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> }
> }
>
> -/**
> - * acpi_dev_resource_interrupt - Extract ACPI interrupt resource information.
> - * @ares: Input ACPI resource object.
> - * @index: Index into the array of GSIs represented by the resource.
> - * @res: Output generic resource object.
> - *
> - * Check if the given ACPI resource object represents an interrupt resource
> - * and @index does not exceed the resource's interrupt count (true is returned
> - * in that case regardless of the results of the other checks)). If that's the
> - * case, register the GSI corresponding to @index from the array of interrupts
> - * represented by the resource and populate the generic resource object pointed
> - * to by @res accordingly. If the registration of the GSI is not successful,
> - * IORESOURCE_DISABLED will be set it that object's flags.
> - *
> - * Return:
> - * 1) false with res->flags setting to zero: not the expected resource type
> - * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned resource
> - * 3) true: valid assigned resource
> - */
> -bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> - struct resource *res)
> +static bool __acpi_dev_resource_interrupt(struct acpi_device *adev,
> + struct acpi_resource *ares, int index,
> + struct resource *res)
> {
> struct acpi_resource_irq *irq;
> struct acpi_resource_extended_irq *ext_irq;
> @@ -460,7 +442,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> acpi_dev_irqresource_disabled(res, 0);
> return false;
> }
> - acpi_dev_get_irqresource(res, irq->interrupts[index],
> + acpi_dev_get_irqresource(adev, res, irq->interrupts[index],
> irq->triggering, irq->polarity,
> irq->sharable, true);
> break;
> @@ -470,7 +452,31 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> acpi_dev_irqresource_disabled(res, 0);
> return false;
> }
> - acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
> +
> + /*
> + * It's a interrupt consumer device and connecting to specfic
> + * interrupt controller. For now, we only support connecting
> + * interrupts to one irq controller for a single device
> + */
> + if (ext_irq->producer_consumer == ACPI_CONSUMER
> + && ext_irq->resource_source.string_length != 0
> + && !adev->interrupt_producer) {
> + acpi_status status;
> + acpi_handle handle;
> + struct acpi_device *device;
> +
> + status = acpi_get_handle(NULL, ext_irq->resource_source.string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return false;
> +
> + adev->interrupt_producer = &device->fwnode;
> + }
> +
> + acpi_dev_get_irqresource(adev, res, ext_irq->interrupts[index],
> ext_irq->triggering, ext_irq->polarity,
> ext_irq->sharable, false);
> break;
> @@ -481,6 +487,31 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>
> return true;
> }
> +
> +/**
> + * acpi_dev_resource_interrupt - Extract ACPI interrupt resource information.
> + * @ares: Input ACPI resource object.
> + * @index: Index into the array of GSIs represented by the resource.
> + * @res: Output generic resource object.
> + *
> + * Check if the given ACPI resource object represents an interrupt resource
> + * and @index does not exceed the resource's interrupt count (true is returned
> + * in that case regardless of the results of the other checks)). If that's the
> + * case, register the GSI corresponding to @index from the array of interrupts
> + * represented by the resource and populate the generic resource object pointed
> + * to by @res accordingly. If the registration of the GSI is not successful,
> + * IORESOURCE_DISABLED will be set it that object's flags.
> + *
> + * Return:
> + * 1) false with res->flags setting to zero: not the expected resource type
> + * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned resource
> + * 3) true: valid assigned resource
> + */
> +bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> + struct resource *res)
> +{
> + return __acpi_dev_resource_interrupt(NULL, ares, index, res);
> +}
> EXPORT_SYMBOL_GPL(acpi_dev_resource_interrupt);
You cannot do this as &adev->dev is deferenced in acpi_dev_get_irqresource
without a check that adev is NULL, and so passes an offset from NULL to
acpi_register_gsi() which breaks everything.
Graeme
>
> /**
> @@ -499,6 +530,7 @@ struct res_proc_context {
> void *preproc_data;
> int count;
> int error;
> + struct acpi_device *adev;
> };
>
> static acpi_status acpi_dev_new_resource_entry(struct resource_win *win,
> @@ -546,7 +578,7 @@ static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
> || acpi_dev_resource_ext_address_space(ares, &win))
> return acpi_dev_new_resource_entry(&win, c);
>
> - for (i = 0; acpi_dev_resource_interrupt(ares, i, res); i++) {
> + for (i = 0; __acpi_dev_resource_interrupt(c->adev, ares, i, res); i++) {
> acpi_status status;
>
> status = acpi_dev_new_resource_entry(&win, c);
> @@ -599,6 +631,7 @@ int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
> c.preproc_data = preproc_data;
> c.count = 0;
> c.error = 0;
> + c.adev = adev;
> status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
> acpi_dev_process_resource, &c);
> if (ACPI_FAILURE(status)) {
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 4242c31..5410d3b 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -355,6 +355,7 @@ struct acpi_device {
> int device_type;
> acpi_handle handle; /* no handle for fixed hardware */
> struct fwnode_handle fwnode;
> + struct fwnode_handle *interrupt_producer;
> struct acpi_device *parent;
> struct list_head children;
> struct list_head node;
> --
> 1.7.12.4
>
^ permalink raw reply
* [PATCH] arm64: dts: zx: add pcu_domain node for zx296718
From: Baoyou Xie @ 2016-12-03 11:59 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds the pcu_domain node, so it can be used
by zte-soc's power domain driver.
Furthermore, it adds the document of the node.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
Documentation/devicetree/bindings/arm/zte.txt | 11 +++++++++++
arch/arm64/boot/dts/zte/zx296718.dtsi | 7 +++++++
2 files changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/zte.txt b/Documentation/devicetree/bindings/arm/zte.txt
index 83369785..19a7e1b 100644
--- a/Documentation/devicetree/bindings/arm/zte.txt
+++ b/Documentation/devicetree/bindings/arm/zte.txt
@@ -27,6 +27,9 @@ System management required properties:
- compatible = "zte,zx296718-aon-sysctrl"
- compatible = "zte,zx296718-sysctrl"
+Low power management required properties:
+ - compatible = "zte,zx296718-pcu"
+
Example:
aon_sysctrl: aon-sysctrl at 116000 {
compatible = "zte,zx296718-aon-sysctrl", "syscon";
@@ -37,3 +40,11 @@ sysctrl: sysctrl at 1463000 {
compatible = "zte,zx296718-sysctrl", "syscon";
reg = <0x1463000 0x1000>;
};
+
+pcu_domain: pcu at 0x00117000 {
+ compatible = "zte,zx296718-pcu";
+ reg = <0x00117000 0x1000>;
+ #power-domain-cells = <1>;
+ status = "ok";
+};
+
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index b44d1d1..39e70c7 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -351,5 +351,12 @@
reg = <0x01480000 0x1000>;
#clock-cells = <1>;
};
+
+ pcu_domain: pcu at 0x00117000 {
+ compatible = "zte,zx296718-pcu";
+ reg = <0x00117000 0x1000>;
+ #power-domain-cells = <1>;
+ status = "ok";
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Shawn Guo @ 2016-12-03 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6379358.TRgYEOKGM8@wuerfel>
On Fri, Dec 02, 2016 at 05:38:01PM +0100, Arnd Bergmann wrote:
> On Monday, November 28, 2016 10:08:18 PM CET Shawn Guo wrote:
> > On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:
> > >> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
> > >> > GICR for multiple CPU can be described with start address and stride,
> > >> > or with multiple address. Current multiple address and stride are
> > >> > both used. Fix it.
> > >> >
> > >> > vmalloc patch 727a7f5a9 triggered this bug:
> > >> > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> > >> > [ 0.097150] pgd = ffff000008602000
> > >> > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> > >> > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> > >> > [ 0.097170] Modules linked in:
> > >> > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> > >> > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> > >> > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> > >> > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c
> > >> > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20
> > >> > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> > >> >
> > >> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > >>
> > >> A Fixes: tag would be useful on a patch like this, to tell what patch
> > >> introduced the problem. Please consider using them in the future.
> > >>
> > >> I've applied this one to fixes now.
> > >
> > > Hi Olof,
> > >
> > > I happened to still have this one in my todo folder as I must have
> > > missed your reply, and I stumbled over it while looking for things
> > > that may have gone missing.
> > >
> > > I don't see it in v4.9-rc6, did it get dropped accidentally?
> >
> > Please help get this into v4.9 if possible, as it is required to get
> > v4.9 kernel boot up on ZTE ZX296718 SoC. Thanks.
> >
> > Shawn
> >
>
> Ok, applied both. Thanks,
Patch 2/2 already went to you in the pull request[1]:
[GIT PULL] ZTE arm64 device tree updates for 4.10
Shawn
[1] http://www.spinics.net/lists/arm-kernel/msg545640.html
^ permalink raw reply
* [PATCH v9 07/16] drivers: acpi: implement acpi_dma_configure
From: Lorenzo Pieralisi @ 2016-12-03 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0jfwGBaHepToB9U3qQZ3KTB6XzoRDwEskV0B9fK7+OoDg@mail.gmail.com>
On Sat, Dec 03, 2016 at 03:11:09AM +0100, Rafael J. Wysocki wrote:
> On Fri, Dec 2, 2016 at 4:38 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > Rafael, Mark, Suravee,
> >
> > On Mon, Nov 21, 2016 at 10:01:39AM +0000, Lorenzo Pieralisi wrote:
> >> On DT based systems, the of_dma_configure() API implements DMA
> >> configuration for a given device. On ACPI systems an API equivalent to
> >> of_dma_configure() is missing which implies that it is currently not
> >> possible to set-up DMA operations for devices through the ACPI generic
> >> kernel layer.
> >>
> >> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
> >> calls that for now are just wrappers around arch_setup_dma_ops() and
> >> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
> >> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
> >>
> >> Since acpi_dma_configure() is used to configure DMA operations, the
> >> function initializes the dma/coherent_dma masks to sane default values
> >> if the current masks are uninitialized (also to keep the default values
> >> consistent with DT systems) to make sure the device has a complete
> >> default DMA set-up.
> >
> > I spotted a niggle that unfortunately was hard to spot (and should not
> > be a problem per se but better safe than sorry) and I am not comfortable
> > with it.
> >
> > Following commit d0562674838c ("ACPI / scan: Parse _CCA and setup
> > device coherency") in acpi_bind_one() we check if the acpi_device
> > associated with a device just added supports DMA, first it was
> > done with acpi_check_dma() and then commit 1831eff876bd ("device
> > property: ACPI: Make use of the new DMA Attribute APIs") changed
> > it to acpi_get_dma_attr().
> >
> > The subsequent check (attr != DEV_DMA_NOT_SUPPORTED) is always true
> > on _any_ acpi device we pass to acpi_bind_one() on x86, which was
> > fine because we used it to call arch_setup_dma_ops(), which is a nop
> > on x86. On ARM64 a _CCA method is required to define if a device
> > supports DMA so (attr != DEV_DMA_NOT_SUPPORTED) may well be false.
> >
> > Now, acpi_bind_one() is used to bind an acpi_device to its physical
> > node also for pseudo-devices like cpus and memory nodes. For those
> > objects, on x86, attr will always be != DEV_DMA_NOT_SUPPORTED.
> >
> > So far so good, because on x86 arch_setup_dma_ops() is empty code.
> >
> > With this patch, I use the (attr != DEV_DMA_NOT_SUPPORTED) check
> > to call acpi_dma_configure() which is basically a nop on x86 except
> > that it sets up the dma_mask/coherent_dma_mask to a sane default value
> > (after all we are setting up DMA for the device so it makes sense to
> > initialize the masks there if they were unset since we are configuring
> > DMA for the device in question) for the given device.
> >
> > Problem is, as per the explanation above, we are also setting the
> > default dma masks for pseudo-devices (eg CPUs) that were previously
> > untouched, it should not be a problem per-se but I am not comfortable
> > with that, honestly it does not make much sense.
> >
> > An easy "fix" would be to move the default dma masks initialization out
> > of acpi_dma_configure() (as it was in previous patch versions of this
> > series - I moved it to acpi_dma_configure() just a consolidation point
> > for initializing the masks instead of scattering them in every
> > acpi_dma_configure caller) I can send this as a fix-up patch to Joerg if
> > we think that's the right thing to do (or I can send it to Rafael later
> > when the code is in the merged depending on the timing) just let me
> > know please.
>
> Why can't arch_setup_dma_ops() set those masks too?
Because the dma masks set-up is done by the caller (see
of_dma_configure()) according to firmware configuration or
platform data knowledge. I wanted to replicate the of_dma_configure()
interface on ACPI for obvious reasons (on ARM systems), I stopped
short of adding ACPI code to mirror of_dma_get_range() equivalent
(through the _DMA object) but I am really really nervous about changing
the code path on x86 because in theory all is fine, in practice even
just setting the masks to sane values can have unexpected consequences,
I just can't know (that's why I wasn't doing it in the first iterations
of this series).
Side note: DT with of_dma_configure() and ACPI with
acpi_create_platform_device() set the default dma mask for all
platform devices already _regardless_ of what they really are, though
arguably acpi_bind_one() touches ways more devices.
I really think that removing the default dma masks settings from
acpi_dma_configure() is the safer thing to do for the time being (or
moving acpi_dma_configure() to acpi_create_platform_device(), where the
DMA masks are set-up by default by core ACPI. Mark, Suravee, what was
the rationale behind calling arch_setup_dma_ops() in acpi_bind_one() ?)
Please let me know, fix-up is trivial however we decide to proceed.
Thank you !
Lorenzo
^ 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