* [PATCH] arm64: kgdb: handle read-only text / modules
From: AKASHI Takahiro @ 2016-09-21 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920103333.GB1045@leverpostej>
On Tue, Sep 20, 2016 at 11:33:34AM +0100, Mark Rutland wrote:
> On Tue, Sep 20, 2016 at 07:03:21PM +0900, AKASHI Takahiro wrote:
> > Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
> > by using aarch64_insn_write() instead of probe_kernel_write().
> > See how this works:
> > commit 2f896d586610 ("arm64: use fixmap for text patching")
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Jason Wessel <jason.wessel@windriver.com>
> > Cc: <stable@vger.kernel.org> # 4.0-
>
> We had SET_MODULE_RONX in v3.17, and we had KGDB before that, so we need
> something for v3.17+.
Right, but 3.18+ :)
Unfortunately, the patch ("arm64: use fixmap for text patching")
is merged only in v4.0 or later. So it is also a pre-requisite.
> > ---
> > arch/arm64/kernel/kgdb.c | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> > index 6732a27..133cfe3 100644
> > --- a/arch/arm64/kernel/kgdb.c
> > +++ b/arch/arm64/kernel/kgdb.c
> > @@ -382,3 +382,23 @@ struct kgdb_arch arch_kgdb_ops = {
> > KGDB_DYN_BRK_INS_BYTE(3),
> > }
> > };
> > +int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> > +{
> > + int err;
> > +
> > + BUILD_BUG_ON(AARCH64_INSN_SIZE != BREAK_INSTR_SIZE);
> > +
> > + err = aarch64_insn_read((void *)bpt->bpt_addr, (u32 *)bpt->saved_instr);
> > + if (err)
> > + return err;
> > +
> > + return aarch64_insn_write((void *)bpt->bpt_addr,
> > + (u32)AARCH64_BREAK_KGDB_DYN_DBG);
> > +}
>
> This changes the endianness of saved_instr (on BE), but it looks like
> that's handed as an opaque token by the core code anyway, so that should
> be fine.
>
> This also renders arch_kgdb_ops.gdb_bpt_instr unused. Can/should we get
> rid of that?
Yes, we can. But arch_kgdb_ops is still needed for compiling anyway.
> > +int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> > +{
> > + return aarch64_insn_write((void *)bpt->bpt_addr,
> > + *(u32 *)bpt->saved_instr);
> > +}
>
> We also need a few additional includes:
>
> <asm/debug-monitors.h> # for BREAK_INSTR_SIZE, AARCH64_BREAK_KGDB_DYN_DBG
> <asm/insn.h> # for AARCH64_INSN_SIZE, insn_{read,write}
> <linux/bug.h> # for BUILD_BUG_ON()
Added.
> I take it that we're protected against nesting within
> aarch64_insn_write(), so that we can't deadlock on patch_lock?
>
> Other than that, this looks good to me.
Thanks,
-Takahiro AKASHI
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH v2] arm64: kgdb: handle read-only text / modules
From: AKASHI Takahiro @ 2016-09-21 7:19 UTC (permalink / raw)
To: linux-arm-kernel
Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
by using aarch64_insn_write() instead of probe_kernel_write().
See how this works:
commit 2f896d586610 ("arm64: use fixmap for text patching")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: <stable@vger.kernel.org> # 3.18-3.19: 2f896d5: arm64: use fixmap
Cc: <stable@vger.kernel.org> # 4.0-
---
arch/arm64/include/asm/debug-monitors.h | 2 --
arch/arm64/kernel/kgdb.c | 36 ++++++++++++++++++++++-----------
2 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index 4b6b3f7..b71420a 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -61,8 +61,6 @@
#define AARCH64_BREAK_KGDB_DYN_DBG \
(AARCH64_BREAK_MON | (KGDB_DYN_DBG_BRK_IMM << 5))
-#define KGDB_DYN_BRK_INS_BYTE(x) \
- ((AARCH64_BREAK_KGDB_DYN_DBG >> (8 * (x))) & 0xff)
#define CACHE_FLUSH_IS_SAFE 1
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index 6732a27..b06a7a2 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -19,6 +19,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/bug.h>
#include <linux/cpumask.h>
#include <linux/irq.h>
#include <linux/irq_work.h>
@@ -26,6 +27,8 @@
#include <linux/kgdb.h>
#include <linux/kprobes.h>
#include <linux/percpu.h>
+#include <asm/debug-monitors.h>
+#include <asm/insn.h>
#include <asm/ptrace.h>
#include <asm/traps.h>
@@ -370,15 +373,24 @@ void kgdb_arch_exit(void)
unregister_die_notifier(&kgdb_notifier);
}
-/*
- * ARM instructions are always in LE.
- * Break instruction is encoded in LE format
- */
-struct kgdb_arch arch_kgdb_ops = {
- .gdb_bpt_instr = {
- KGDB_DYN_BRK_INS_BYTE(0),
- KGDB_DYN_BRK_INS_BYTE(1),
- KGDB_DYN_BRK_INS_BYTE(2),
- KGDB_DYN_BRK_INS_BYTE(3),
- }
-};
+struct kgdb_arch arch_kgdb_ops;
+
+int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
+{
+ int err;
+
+ BUILD_BUG_ON(AARCH64_INSN_SIZE != BREAK_INSTR_SIZE);
+
+ err = aarch64_insn_read((void *)bpt->bpt_addr, (u32 *)bpt->saved_instr);
+ if (err)
+ return err;
+
+ return aarch64_insn_write((void *)bpt->bpt_addr,
+ (u32)AARCH64_BREAK_KGDB_DYN_DBG);
+}
+
+int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
+{
+ return aarch64_insn_write((void *)bpt->bpt_addr,
+ *(u32 *)bpt->saved_instr);
+}
--
2.10.0
^ permalink raw reply related
* [PATCH 1/2] dt: bindings: add allwinner, otg-routed property for phy-sun4i-usb
From: Icenowy Zheng @ 2016-09-21 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a1ab62a-4091-fd75-d753-fb30585dffa5@redhat.com>
21.09.2016, 15:10, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 09/21/2016 10:04 AM, Icenowy Zheng wrote:
>> ?On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
>> ?the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
>> ?(which is a Host-only controller, but more stable and easy to implement).
>>
>> ?This property marks whether on a certain board which controller should be
>> ?attached to the PHY.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> Erm, I think that the idea here is to dynamically switch the routing
> based on the id-pin of the otg connector. IOW use the musb controller
> for device mode, and the ehci/ohci proper for proper host support
> when in host mode.
At least on some boards this implementation works...
(I mean Pine64, which has two USB-A connectors)
>
> Regards,
>
> Hans
>
>> ?---
>> ??Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 7 +++++++
>> ??1 file changed, 7 insertions(+)
>>
>> ?diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?index 287150d..5c11d57 100644
>> ?--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?@@ -36,6 +36,13 @@ Optional properties:
>> ??- usb1_vbus-supply : regulator phandle for controller usb1 vbus
>> ??- usb2_vbus-supply : regulator phandle for controller usb2 vbus
>>
>> ?+Optional properties for H3 or A64 SoCs:
>> ?+- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
>> ?+ MUSB. (boolean, if this property is set, the OHCI/EHCI
>> ?+ controllers at PHY0 should be enabled and the MUSB
>> ?+ controller must *NOT* be enabled, and thus the PHY can
>> ?+ only work in host mode)
>> ?+
>> ??Example:
>> ??????????usbphy: phy at 0x01c13400 {
>> ??????????????????#phy-cells = <1>;
^ permalink raw reply
* [PATCH] gpio: Added zynq specific check for special pins on bank zero
From: Michal Simek @ 2016-09-21 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920140633.GD16583@xsjsorenbubuntu>
On 20.9.2016 16:06, S?ren Brinkmann wrote:
> On Tue, 2016-09-20 at 14:02:04 +0530, Nava kishore Manne wrote:
>> From: Nava kishore Manne <nava.manne@xilinx.com>
>>
>> This patch adds zynq specific check for bank 0 pins 7 and 8
>> are special and cannot be used as inputs
>>
>> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
>> ---
>> drivers/gpio/gpio-zynq.c | 17 +++++++++++++++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
>> index e72794e..eae9d24 100644
>> --- a/drivers/gpio/gpio-zynq.c
>> +++ b/drivers/gpio/gpio-zynq.c
>> @@ -96,6 +96,10 @@
>> /* GPIO upper 16 bit mask */
>> #define ZYNQ_GPIO_UPPER_MASK 0xFFFF0000
>>
>> +/* For GPIO quirks */
>> +#define ZYNQ_GPIO BIT(0)
>> +#define ZYNQMP_GPIO BIT(1)
>
> I'd make sure all quirks are easily identifiable and call them something
> like 'ZYNQ_GPIO_QUIRK_FOO'
>
> Apart from that:
> Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
>
This issue was:
Reported-by: Jonas Karlsson <Jonas.d.karlsson@gmail.com>
And here is also my:
Acked-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160921/7059a368/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb
From: Hans de Goede @ 2016-09-21 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6718551474442396@web16h.yandex.ru>
Hi,
On 09/21/2016 10:19 AM, Icenowy Zheng wrote:
>
>
> 21.09.2016, 15:10, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 09/21/2016 10:04 AM, Icenowy Zheng wrote:
>>> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
>>> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
>>> (which is a Host-only controller, but more stable and easy to implement).
>>>
>>> This property marks whether on a certain board which controller should be
>>> attached to the PHY.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>
>> Erm, I think that the idea here is to dynamically switch the routing
>> based on the id-pin of the otg connector. IOW use the musb controller
>> for device mode, and the ehci/ohci proper for proper host support
>> when in host mode.
>
> At least on some boards this implementation works...
>
> (I mean Pine64, which has two USB-A connectors)
Right and I think it is great that you're working on this.
But even with an A connector on the board, we can still use the device
mode (e.g. the SoC's native FEL mode will be used this way).
Notice that you can fake id-pin changes by echoing a mode to:
/sys/devices/platform/soc at 01c00000/1c13000.usb/musb-hdrc.1.auto/mode
Valid values to echo are: host, peripheral and otg.
If you combine this with using either an USB A<->A cable, or using
the port normally as a host you should be able to develop and test
full otg support.
Eventually we will need a full otg support rather then your current solution
and I'm afraid that your solution may get in the way of full otg support.
Regards,
Hans
^ permalink raw reply
* [PATCH 2/4] ARM: tegra: nyan: Use external control for bq24735 charger
From: Jon Hunter @ 2016-09-21 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474394567.1215.14.camel@paulk.fr>
On 20/09/16 19:02, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 ? 18:40 +0100, Jon Hunter a ?crit :
>> On 28/08/16 18:32, Paul Kocialkowski wrote:
>>>
>>> Nyan boards come with an embedded controller that controls when to
>>> enable and disable the charge. Thus, it should not be left up to the
>>> kernel to handle that.
>>>
>>> Using the ti,external-control property allows specifying this use-case.
>>
>> So the bq24735 is populated under the EC's 'i2c-tunnel' property which
>> is there to specifically interface it's child devices to the host. So I
>> am a bit confused why this is expose to the host if it should not be used?
>
> Well, it needs to access the information in the read-only registers provided by
> the chip, which is allowed by the setup in place that you described.
Is this to expose the current state to the kernel so we can monitor the
battery state?
> However, the EC has its internal state machine that decides when to start
> charging, etc and so should be the only one to write registers, to avoid
> conflicts.
>
>> Again you may right and I did find the original series [0] for this
>> which specifically references the Acer Chromebook that needs this.
>> However, I am not sure why this was never populated? Is there any other
>> history here?
>
> I am also confused about why it wasn't applied earlier. However, the cros kernel
> is using the very same scheme.
Do you have a reference?
>> What is the actual problem you see without making this change?
>
> There is a risk of conflict (even though it's probably not that significant),
> given the low variety of possible cases here. The idea is simply to say that the
> EC is in charge and to let it do its job without interfering.
>
>> The original series states ...
>>
>> "On Acer Chromebook 13 (CB5-311) this module fails to load if the
>> charger is not inserted, and will error when it is removed."
>
> I'm confused about that comment. At this point (and with this patch), it works
> normally.
Ok, I think Thierry prefers to only apply fixes for problems that can be
reproduced. Is there a simple way to check the battery status and
charging status via say the sysfs? If I can test that this has no
negative impact may be it is ok.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH 8/9] dmaengine: ti-dma-crossbar: Use enum for crossbar type
From: Peter Ujfalusi @ 2016-09-21 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921035226.GE2609@localhost>
On 09/21/16 06:52, Vinod Koul wrote:
> On Fri, Sep 16, 2016 at 11:33:23AM +0300, Peter Ujfalusi wrote:
>> Fixes compiler warning on 64bit architectures.
>
> Would be good to give the warning message here
Let me revert this patch and patch #2 for the eDMA to get the warnings.
I will repost v2 with the updated commit messages.
>
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>> drivers/dma/ti-dma-crossbar.c | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
>> index e4f3bd1ae264..876e4ccaf033 100644
>> --- a/drivers/dma/ti-dma-crossbar.c
>> +++ b/drivers/dma/ti-dma-crossbar.c
>> @@ -16,8 +16,10 @@
>> #include <linux/of_device.h>
>> #include <linux/of_dma.h>
>>
>> -#define TI_XBAR_DRA7 0
>> -#define TI_XBAR_AM335X 1
>> +enum ti_xbar_type {
>> + TI_XBAR_DRA7 = 0,
>> + TI_XBAR_AM335X,
>> +};
>>
>> static const struct of_device_id ti_dma_xbar_match[] = {
>> {
>> @@ -395,7 +397,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
>>
>> xbar->dmarouter.dev = &pdev->dev;
>> xbar->dmarouter.route_free = ti_dra7_xbar_free;
>> - xbar->dma_offset = (u32)match->data;
>> + xbar->dma_offset = (enum ti_xbar_type)match->data;
>>
>> mutex_init(&xbar->mutex);
>> platform_set_drvdata(pdev, xbar);
>> @@ -428,7 +430,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
>> if (unlikely(!match))
>> return -EINVAL;
>>
>> - switch ((u32)match->data) {
>> + switch ((enum ti_xbar_type)match->data) {
>> case TI_XBAR_DRA7:
>> ret = ti_dra7_xbar_probe(pdev);
>> break;
>> --
>> 2.10.0
>>
>
--
P?ter
^ permalink raw reply
* [PATCH v26 0/7] arm64: add kdump support
From: AKASHI Takahiro @ 2016-09-21 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC1812.6040906@arm.com>
James,
On Fri, Sep 16, 2016 at 05:04:34PM +0100, James Morse wrote:
> (Cc: Ard),
>
> Mark, Ard, how does/will reserved-memory work on an APCI only system?
>
>
> On 07/09/16 05:29, AKASHI Takahiro wrote:
> > v26-specific note: After a comment from Rob[0], an idea of adding
> > "linux,usable-memory-range" was dropped. Instead, an existing
> > "reserved-memory" node will be used to limit usable memory ranges
> > on crash dump kernel.
> > This works not only on UEFI/ACPI systems but also on DT-only systems,
> > but if he really insists on using DT-specific "usable-memory" property,
> > I will post additional patches for kexec-tools. Those would be
> > redundant, though.
> > Even in that case, the kernel will not have to be changed.
>
> Some narrative on how the old memory ranges get reserved, as there is no longer
> any code in the series doing this, (which is pretty neat!):
Thank you for detailed explanation :)
I was wondering whether I should have added such kind of description,
but it was nothing but, I believed, a "normal" DT behavior.
> kexec-tools parses the list of memory ranges in /proc/iomem, and adds a node to
> the /reserved-memory for System RAM ranges that don't cover the crash kernel.
> Decompiling the crash-kernel DT from Seattle, it looks roughly like this:
>
> reserved-memory {
> ranges;
> #size-cells = <0x2>;
> #address-cells = <0x2>;
>
> crash_dump at 83ffe50000 {
> no-map;
> reg = <0x83 0xffe50000 0x0 0x1b0000>;
> };
>
> [ ... ]
> };
>
>
> 'no-map' means its doing the same thing to memblock as
> 'linux,usable-memory-range' did in earlier versions,
> early_init_dt_reserve_memory_arch() takes no-map to mean memblock_remove().
> We trigger the removing via early_init_fdt_scan_reserved_mem() in
> arch/arm64/mm/init.c. This happens later than before, but its before the
> crashkernel and cma ranges get reserved.
>
> One difference I can see is that before we avoided memblock_remove()ing ranges
> that were also in memblock.nomap. This was to avoid the ACPI tables getting
> mapped as device memory by mistake, this is fixed by [1]. Now these ranges are
> published in /proc/iomem as 'reserved' and won't get covered by a
> reserved-memory node, and so we don't need to check memblock.nomap when
> memblock_remove()ing.
>
>
> The only odd thing I can see is for a (mythical?) pure-ACPI system. The EFI stub
> will create a DT with a chosen node containing pointers to the memory map and
> the efi command line. Now such as system may also grow a /reserved-memory node
> after kdump. I don't think this is a problem, but it may not match how an
> acpi-only system reserves memory. (how does that work?)
I didn't get what you mean by "may grow a /reserved-memory after kdump."
>
> > [1] "arm64: mark reserved memblock regions explicitly in iomem"
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/450433.html
>
> This is queued in Will's arm64/for-next/core,
>
> > [2] "efi: arm64: treat regions with WT/WC set but WB cleared as memory"
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/451491.html
>
> This is queued in tip, but I can't see why kdump depends on it. It only has an
> effect if the uefi memory map has !WB regions that linux needs to use.
Just because you said that the patch had fixed your problem on Seattle.
If I misunderstood, it will be fine to remove this reference from
my commit message.
Thanks,
-Takahiro AKASHI
>
> Thanks,
>
> James
>
^ permalink raw reply
* [PATCH 3/4] ARM: tegra: nyan-big: Include compatible revisions for proper detection
From: Jon Hunter @ 2016-09-21 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474394544.1215.13.camel@paulk.fr>
On 20/09/16 19:02, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 ? 18:56 +0100, Jon Hunter a ?crit :
>> On 20/09/16 18:53, Paul Kocialkowski wrote:
>>>
>>>> Old Signed by an unknown key
>>>
>>> Le mardi 20 septembre 2016 ? 18:41 +0100, Jon Hunter a ?crit :
>>>>
>>>> On 28/08/16 18:32, Paul Kocialkowski wrote:
>>>>>
>>>>>
>>>>> Depthcharge (the payload used with cros devices) will attempt to detect
>>>>> boards using their revision. This includes all the known revisions for
>>>>> the nyan-big board so that the dtb can be selected preferably.
>>>>
>>>> May be I am missing something here, but for the mainline there is only
>>>> one dtb available and so why is this needed for the mainline?
>>>
>>> There is indeed a single dts in mainline, but depthcharge will use the
>>> revision
>>> to match the compatible string (e.g. it will look for google,nyan-big-rev5,
>>> not
>>> google,nyan-big), so we need to list them all in that single dts. Otherwise,
>>> depthcharge will fall back to the default config, which may or may not be
>>> suitable for nyan.
>>
>> Is tegra124-nyan-big.dtb not the default?
>
> You can't expect that to always be the case. The image format allows many
> different dts to be provided, so I could easily build with multi_v7_defconfig
> and have various dts for various devices in the same image, and just select a
> random one as default.
Really? Sounds odd. I was hoping that tegra124-nyan-big.dtb would be a
catch all.
> Here, default is really a fallback, the right one is expected to be detected by
> this mechanism. And it really doesn't hurt to provide that information for
> proper detection.
>
> Note that this is done with many other cros devices in mainline (such as rk3288
> veyrons).
Yes, I guess the same is true for the tegra210-smaug and we do define
all the revs for that one. May be extend the changelog comment to say
what may happen without this change and the problem that this is fixing.
Jon
--
nvpublic
^ permalink raw reply
* [PATCH 5/9] dmaengine/ARM: omap-dma: Fix the DMAengine compile test on non OMAP configs
From: Peter Ujfalusi @ 2016-09-21 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921035326.GF2609@localhost>
On 09/21/16 06:53, Vinod Koul wrote:
> On Wed, Sep 21, 2016 at 09:21:32AM +0530, Vinod Koul wrote:
>> On Fri, Sep 16, 2016 at 11:33:20AM +0300, Peter Ujfalusi wrote:
>>> The DMAengine driver for omap-dma use three function calls from the
>>> plat-omap legacy driver. When the DMAengine driver is built when ARCH_OMAP
>>> is not set, the compilation will fail due to missing symbols.
>>> Add empty inline functions to allow the DMAengine driver to be compiled
>>> with COMPILE_TEST.
>>
>> Peter,
>>
>> This should be before you enable COMPILE_TEST otherwise build will break!
>
> Ah never mind, you have three drivers in this series so I think this is fine
> before the omap one :)
Yep, patch 1-4 is for eDMA, patch 5-6 is for omap-dma and the remaining is for
ti-dma-crossbar.
I wanted to have them separate (including when I enable the COMPILE_TEST) so
we can revert easily if needed.
If I move the 'enable COMPILE_TEST' patches at the end of the series, I think
I will still have them as separate as they are enabling the test for three
different driver.
--
P?ter
^ permalink raw reply
* [PATCH v26 0/7] arm64: add kdump support
From: AKASHI Takahiro @ 2016-09-21 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E00CDC.70403@arm.com>
On Mon, Sep 19, 2016 at 05:05:48PM +0100, James Morse wrote:
> On 16/09/16 21:17, Ard Biesheuvel wrote:
> > On 16 September 2016 at 17:04, James Morse <james.morse@arm.com> wrote:
> >> Mark, Ard, how does/will reserved-memory work on an APCI only system?
> >
> > It works by accident, at the moment. We used to ignore both
> > /memreserve/s and the /reserved-memory node, but due to some unrelated
> > refactoring, we ended up honouring the reserved-memory node when
> > booting via UEFI
>
> Okay, so kdump probably shouldn't rely on this behaviour...
>
> For an acpi-only system, we could get reserve_crashkernel() to copy the uefi
> memory map into the reserved region, changing the region types for existing
> kernel memory to EfiReservedMemoryType (for example) and fixing up the reserved
> region boundaries.
>
> This second memory map could then be added alongside the real one in the
> DT/chosen, and used in preference the second time we go through uefi_init() in
> the crash kernel.
Do we need add this map as the second one?
Why not replace "linux,uefi-mmap-start" in a new blob?
> kexec-tools would still need to keep the '/reserved-memory' node for non-uefi
> systems.
Yeah, but if we go in our own way on UEFI/ACPI systems, we may want to
go in a DT-specific way, like PPC does, on DT systems.
(That is, "linux,usable-memory" in memory nodes.)
Thanks,
-Takahiro AKASHI
> Doing this doesn't depend on userspace, and means the uefi memory map is still
> the one and only true source of memory layout information. If fixing it like
> this is valid I don't think it should block kdump.
>
> ... I will think about this some more before trying to put it together.
>
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH 3/4] ARM: tegra: nyan-big: Include compatible revisions for proper detection
From: Paul Kocialkowski @ 2016-09-21 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6501341f-e14c-4876-dcb7-60a33b7621c4@nvidia.com>
Le mercredi 21 septembre 2016 ? 08:34 +0100, Jon Hunter a ?crit?:
> On 20/09/16 19:02, Paul Kocialkowski wrote:
> >
> > * PGP Signed by an unknown key
> >
> > Le mardi 20 septembre 2016 ? 18:56 +0100, Jon Hunter a ?crit :
> > >
> > > On 20/09/16 18:53, Paul Kocialkowski wrote:
> > > >
> > > >
> > > > >
> > > > > Old Signed by an unknown key
> > > >
> > > > Le mardi 20 septembre 2016 ? 18:41 +0100, Jon Hunter a ?crit :
> > > > >
> > > > >
> > > > > On 28/08/16 18:32, Paul Kocialkowski wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Depthcharge (the payload used with cros devices) will attempt to
> > > > > > detect
> > > > > > boards using their revision. This includes all the known revisions
> > > > > > for
> > > > > > the nyan-big board so that the dtb can be selected preferably.
> > > > >
> > > > > May be I am missing something here, but for the mainline there is only
> > > > > one dtb available and so why is this needed for the mainline?
> > > >
> > > > There is indeed a single dts in mainline, but depthcharge will use the
> > > > revision
> > > > to match the compatible string (e.g. it will look for google,nyan-big-
> > > > rev5,
> > > > not
> > > > google,nyan-big), so we need to list them all in that single dts.
> > > > Otherwise,
> > > > depthcharge will fall back to the default config, which may or may not
> > > > be
> > > > suitable for nyan.
> > >
> > > Is tegra124-nyan-big.dtb not the default?
> >
> > You can't expect that to always be the case. The image format allows many
> > different dts to be provided, so I could easily build with
> > multi_v7_defconfig
> > and have various dts for various devices in the same image, and just select
> > a
> > random one as default.
>
> Really? Sounds odd. I was hoping that tegra124-nyan-big.dtb would be a
> catch all.
Yes, the image format (FIT) allows specifying multiple dtb and zImage
combinations in the same image[0].
See depthcharge[|1] for how the "compatible" property is being matched against.
> > Here, default is really a fallback, the right one is expected to be detected
> > by
> > this mechanism. And it really doesn't hurt to provide that information for
> > proper detection.
> >
> > Note that this is done with many other cros devices in mainline (such as
> > rk3288
> > veyrons).
>
> Yes, I guess the same is true for the tegra210-smaug and we do define
> all the revs for that one. May be extend the changelog comment to say
> what may happen without this change and the problem that this is fixing.
Allright, will do!
Thanks
[0]:?http://www.denx.de/wiki/pub/U-Boot/Documentation/multi_image_booting_scenarios.pdf
[1]:?https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/master/src/boot/fit.c#39
--
Paul Kocialkowski, developer of low-level free software for embedded devices
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160921/d16c5577/attachment.sig>
^ permalink raw reply
* [PATCH v6 2/4] drivers: irqchip: Add STM32 external interrupts support
From: Alexandre Torgue @ 2016-09-21 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1609202214460.5476@nanos>
Hi Thomas,
On 09/20/2016 10:16 PM, Thomas Gleixner wrote:
> Alexandre,
>
> On Tue, 20 Sep 2016, Alexandre TORGUE wrote:
>
>> The STM32 external interrupt controller consists of edge detectors that
>> generate interrupts requests or wake-up events.
>>
>> Each line can be independently configured as interrupt or wake-up source,
>> and triggers either on rising, falling or both edges. Each line can also
>> be masked independently.
>>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>
> That all looks very reasonable now. The only remaining question is your SOB
> chain. Who is the author of these patches? You or Maxime? If it's Maxime,
> then the changelog misses a From: tag. If it's you then Maximes SOB is
> bogus.
Actually Maxime wrote the main part of this driver and sent version 1
and 2 of the series. After Linus W. reviews, rework was required to use
hierarchical domain. According to Maxime, I coded the rework (adaptation
to hierarchical domain) and sent other version of the series.
Regards
Alex
>
> Thanks,
>
> tglx
>
>
^ permalink raw reply
* [PATCH v6 2/4] drivers: irqchip: Add STM32 external interrupts support
From: Thomas Gleixner @ 2016-09-21 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f7875786-9b5e-075a-59c8-cd32fb1c4583@st.com>
On Wed, 21 Sep 2016, Alexandre Torgue wrote:
> Hi Thomas,
>
> On 09/20/2016 10:16 PM, Thomas Gleixner wrote:
> > Alexandre,
> >
> > On Tue, 20 Sep 2016, Alexandre TORGUE wrote:
> >
> > > The STM32 external interrupt controller consists of edge detectors that
> > > generate interrupts requests or wake-up events.
> > >
> > > Each line can be independently configured as interrupt or wake-up source,
> > > and triggers either on rising, falling or both edges. Each line can also
> > > be masked independently.
> > >
> > > Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> > > Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
> >
> > That all looks very reasonable now. The only remaining question is your SOB
> > chain. Who is the author of these patches? You or Maxime? If it's Maxime,
> > then the changelog misses a From: tag. If it's you then Maximes SOB is
> > bogus.
>
> Actually Maxime wrote the main part of this driver and sent version 1 and 2 of
> the series. After Linus W. reviews, rework was required to use hierarchical
> domain. According to Maxime, I coded the rework (adaptation to hierarchical
> domain) and sent other version of the series.
So I replace Maximes SOB with Originally-by: Does that apply to all four
patches?
Thanks,
tglx
^ permalink raw reply
* ftrace function_graph causes system crash
From: Bean Huo (beanhuo) @ 2016-09-21 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920100716.131d3647@gandalf.local.home>
> From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org]
> On Behalf Of Steven Rostedt
> Sent: Dienstag, 20. September 2016 16:07
> To: Bean Huo (beanhuo) <beanhuo@micron.com>
> Cc: Zoltan Szubbocsev (zszubbocsev) <zszubbocsev@micron.com>;
> catalin.marinas at arm.com; will.deacon at arm.com; rfi at lists.rocketboards.org;
> linux-kernel at vger.kernel.org; mingo at redhat.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: ftrace function_graph causes system crash
>
> On Tue, 20 Sep 2016 13:10:39 +0000
> "Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
>
> > Hi, all
> > I just use ftrace to do some latency study, found that function_graph
> > can not Work, as long as enable it, will cause kernel panic. I searched this
> online.
> > Found that there are also some cause the same as mine. I am a newer of
> ftrace.
> > I want to know who know what root cause? Here is some partial log:
> >
> >
>
> Can you do a function bisect to find what function this is.
>
> This script is used to help find functions that are being traced by function tracer
> or function graph tracing that causes the machine to reboot, hang, or crash.
> Here's the steps to take.
>
> First, determine if function graph is working with a single function:
>
> # cd /sys/kernel/debug/tracing
> # echo schedule > set_ftrace_filter
> # echo function_graph > current_tracer
>
> If this works, then we know that something is being traced that shouldn't be.
>
> # echo nop > current_tracer
>
> # cat available_filter_functions > ~/full-file # ftrace-bisect ~/full-file ~/test-file
> ~/non-test-file # cat ~/test-file > set_ftrace_filter
>
> *** Note *** this will take several minutes. Setting multiple functions is an
> O(n^2) operation, and we are dealing with thousands of functions.
> So go have coffee, talk with your coworkers, read facebook. And eventually,
> this operation will end.
>
> # echo function_graph > current_tracer
>
> If it crashes, we know that ~/test-file has a bad function.
>
> Reboot back to test kernel.
>
> # cd /sys/kernel/debug/tracing
> # mv ~/test-file ~/full-file
>
> If it didn't crash.
>
> # echo nop > current_tracer
> # mv ~/non-test-file ~/full-file
>
> Get rid of the other test file from previous run (or save them off somewhere.
> # rm -f ~/test-file ~/non-test-file
>
> And start again:
>
> # ftrace-bisect ~/full-file ~/test-file ~/non-test-file
>
> The good thing is, because this cuts the number of functions in ~/test-file by half,
> the cat of it into set_ftrace_filter takes half as long each iteration, so don't talk
> so much at the water cooler the second time.
>
> Eventually, if you did this correctly, you will get down to the problem function,
> and all we need to do is to notrace it.
>
> The way to figure out if the problem function is bad, just do:
>
> # echo <problem-function> > set_ftrace_notrace # echo > set_ftrace_filter #
> echo function_graph > current_tracer
>
> And if it doesn't crash, we are done.
>
> -- Steve
Hi, Steve
Thanks very much! This is a very useful trace tool, I now know the problem function,
It is gt_counter_read, if not trace this function, ftrace function_graph work well.
Do you know now how to deeply debug and trace which line is wrong through Ftrace?
--Bean
^ permalink raw reply
* [PATCH 1/4] ARM: tegra: nyan: Use proper IRQ type definitions
From: Jon Hunter @ 2016-09-21 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474395289.1215.20.camel@paulk.fr>
On 20/09/16 19:14, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 ? 18:15 +0100, Jon Hunter a ?crit :
>> On 28/08/16 18:32, Paul Kocialkowski wrote:
>>>
>>> This switches a few interrupt definitions that were using
>>> GPIO_ACTIVE_HIGH as IRQ type, which is invalid.
>>
>> May be you are right, but this does not describe why this is invalid.
>> Can you elaborate?
>
> GPIO_ACTIVE_HIGH is simply not the right kind of define to use in the
> "interrupts" devicetree property. Values provided there are understood as
> IRQ_TYPE_ defines.
Right, but you are changing the type as GPIO_ACTIVE_HIGH = 0 and
IRQ_TYPE_EDGE_FALLING = 2 and there is no comment about why this has
been changed. It might be correct, but you need to explain it.
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v6 2/4] drivers: irqchip: Add STM32 external interrupts support
From: Maxime Coquelin @ 2016-09-21 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1609210949150.5573@nanos>
2016-09-21 9:50 GMT+02:00 Thomas Gleixner <tglx@linutronix.de>:
> On Wed, 21 Sep 2016, Alexandre Torgue wrote:
>
>> Hi Thomas,
>>
>> On 09/20/2016 10:16 PM, Thomas Gleixner wrote:
>> > Alexandre,
>> >
>> > On Tue, 20 Sep 2016, Alexandre TORGUE wrote:
>> >
>> > > The STM32 external interrupt controller consists of edge detectors that
>> > > generate interrupts requests or wake-up events.
>> > >
>> > > Each line can be independently configured as interrupt or wake-up source,
>> > > and triggers either on rising, falling or both edges. Each line can also
>> > > be masked independently.
>> > >
>> > > Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> > > Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>> >
>> > That all looks very reasonable now. The only remaining question is your SOB
>> > chain. Who is the author of these patches? You or Maxime? If it's Maxime,
>> > then the changelog misses a From: tag. If it's you then Maximes SOB is
>> > bogus.
>>
>> Actually Maxime wrote the main part of this driver and sent version 1 and 2 of
>> the series. After Linus W. reviews, rework was required to use hierarchical
>> domain. According to Maxime, I coded the rework (adaptation to hierarchical
>> domain) and sent other version of the series.
>
> So I replace Maximes SOB with Originally-by: Does that apply to all four
> patches?
Yes, that's fine.
Alex did a lot of rework on this series, he deserves the SoB.
Thanks,
Maxime
^ permalink raw reply
* [PATCH] spi: atmel: use managed resource for gpio chip select
From: Nicolas Ferre @ 2016-09-21 7:55 UTC (permalink / raw)
To: linux-arm-kernel
Use the managed gpio CS pin request so that we avoid having trouble
in the cleanup code.
In fact, if module was configured with DT, cleanup code released
invalid pin. Since resource wasn't freed, module cannot be reinserted.
Reported-by: Alexander Morozov <linux@meltdown.ru>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/spi/spi-atmel.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 8feac599e9ab..4e3f2345844a 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1248,7 +1248,8 @@ static int atmel_spi_setup(struct spi_device *spi)
return -ENOMEM;
if (as->use_cs_gpios) {
- ret = gpio_request(npcs_pin, dev_name(&spi->dev));
+ ret = devm_gpio_request(&spi->dev,
+ npcs_pin, dev_name(&spi->dev));
if (ret) {
kfree(asd);
return ret;
@@ -1471,13 +1472,11 @@ static int atmel_spi_transfer_one_message(struct spi_master *master,
static void atmel_spi_cleanup(struct spi_device *spi)
{
struct atmel_spi_device *asd = spi->controller_state;
- unsigned gpio = (unsigned long) spi->controller_data;
if (!asd)
return;
spi->controller_state = NULL;
- gpio_free(gpio);
kfree(asd);
}
--
2.9.0
^ permalink raw reply related
* Re: [v12, 7/8] base: soc: introduce soc_device_match() interface
From: Alexander Shiyan @ 2016-09-21 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474441040-11946-8-git-send-email-yangbo.lu@nxp.com>
>?????, 21 ???????? 2016, 9:57 +03:00 ?? Yangbo Lu <yangbo.lu@nxp.com>:
>
>From: Arnd Bergmann < arnd@arndb.de >
>
>We keep running into cases where device drivers want to know the exact
>version of the a SoC they are currently running on. In the past, this has
>usually been done through a vendor specific API that can be called by a
>driver, or by directly accessing some kind of version register that is
>not part of the device itself but that belongs to a global register area
>of the chip.
...
>+const struct soc_device_attribute *soc_device_match(
>+const struct soc_device_attribute *matches)
>+{
>+int ret = 0;
>+
>+if (!matches)
>+return NULL;
>+
>+while (!ret) {
>+if (!(matches->machine || matches->family ||
>+ matches->revision || matches->soc_id))
>+break;
>+ret = bus_for_each_dev(&soc_bus_type, NULL, (void *)matches,
>+ soc_device_match_one);
>+if (!ret)
>+matches++;
So, what happen if next "matches" (after increment) will be NULL?
I think you should use while(matches) at the start of this procedure.
---
^ permalink raw reply
* [PATCH 2/4] ARM: tegra: nyan: Use external control for bq24735 charger
From: Paul Kocialkowski @ 2016-09-21 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <90828c8d-e46d-0956-d6b3-e88fc90f3049@nvidia.com>
Le mercredi 21 septembre 2016 ? 08:30 +0100, Jon Hunter a ?crit?:
> On 20/09/16 19:02, Paul Kocialkowski wrote:
> >
> > * PGP Signed by an unknown key
> >
> > Le mardi 20 septembre 2016 ? 18:40 +0100, Jon Hunter a ?crit :
> > >
> > > On 28/08/16 18:32, Paul Kocialkowski wrote:
> > > >
> > > > ?
> > > > Nyan boards come with an embedded controller that controls when to
> > > > enable and disable the charge. Thus, it should not be left up to the
> > > > kernel to handle that.
> > > > ?
> > > > Using the ti,external-control property allows specifying this use-case.
> > > ?
> > > So the bq24735 is populated under the EC's 'i2c-tunnel' property which
> > > is there to specifically interface it's child devices to the host. So I
> > > am a bit confused why this is expose to the host if it should not be used?
> >
> > Well, it needs to access the information in the read-only registers provided
> > by
> > the chip, which is allowed by the setup in place that you described.
>
> Is this to expose the current state to the kernel so we can monitor the
> battery state?
Yes, that is correct.
> > However, the EC has its internal state machine that decides when to start
> > charging, etc and so should be the only one to write registers, to avoid
> > conflicts.
> >
> > >
> > > Again you may right and I did find the original series [0] for this
> > > which specifically references the Acer Chromebook that needs this.
> > > However, I am not sure why this was never populated? Is there any other
> > > history here?
> >
> > I am also confused about why it wasn't applied earlier. However, the cros
> > kernel
> > is using the very same scheme.
>
> Do you have a reference?
Sure thing, there's a similar commit for the dts[0] and one for the driver[1]
(which was already merged in mainline).
> > > What is the actual problem you see without making this change?
> >
> > There is a risk of conflict (even though it's probably not that
> > significant),
> > given the low variety of possible cases here. The idea is simply to say that
> > the
> > EC is in charge and to let it do its job without interfering.
> >
> > >
> > > The original series states ...
> > > ?
> > > "On Acer Chromebook 13 (CB5-311) this module fails to load if the
> > > charger is not inserted, and will error when it is removed."
> >
> > I'm confused about that comment. At this point (and with this patch), it
> > works
> > normally.
>
> Ok, I think Thierry prefers to only apply fixes for problems that can be
> reproduced. Is there a simple way to check the battery status and
> charging status via say the sysfs? If I can test that this has no
> negative impact may be it is ok.
Sure, this is exported at: /sys/class/power_supply/bq24735 at 5-0009
Also, note that the power-supply next branch[2] has some more fixes for the
bq24735 driver.
Cheers,
[0]:?https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e25a91f87af41e29012a4e2dd7a9ab725efd308e
[1]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6b34e53d506b44f911d0fd246ccdc8b4e942e4ae
[2]: https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/log/?h=for-next
--
Paul Kocialkowski, developer of low-level free software for embedded devices
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160921/be9788f1/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Enable GPU node and related supply
From: Jon Hunter @ 2016-09-21 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474395433.1215.23.camel@paulk.fr>
On 20/09/16 19:17, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 ? 13:24 +0100, Jon Hunter a ?crit :
>> On 18/09/16 15:13, Paul Kocialkowski wrote:
>>>
>>> This enables the GPU node for tegra124 nyan boards, which is required to
>>> get graphics acceleration with nouveau on these devices.
>>>
>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>>> ---
>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 8 +++++++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi
>>> b/arch/arm/boot/dts/tegra124-nyan.dtsi
>>> index dab9509..225ca77 100644
>>> --- a/arch/arm/boot/dts/tegra124-nyan.dtsi
>>> +++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
>>> @@ -42,6 +42,12 @@
>>> };
>>> };
>>>
>>> + gpu at 0,57000000 {
>>> + status = "okay";
>>> +
>>> + vdd-supply = <&vdd_gpu>;
>>> + };
>>> +
>>> serial at 70006000 {
>>> /* Debug connector on the bottom of the board near SD card.
>>> */
>>> status = "okay";
>>> @@ -214,7 +220,7 @@
>>> regulator-always-on;
>>> };
>>>
>>> - sd6 {
>>> + vdd_gpu: sd6 {
>>> regulator-name = "+VDD_GPU_AP";
>>> regulator-min-microvolt = <650000>;
>>> regulator-max-microvolt =
>>> <1200000>;
>>>
>>
>> Looks good to me. I see the following error when booting but looking at the
>> code appears to be benign. Thierry, Alex, is this normal/okay?
>
> I have the same messages and asked Alexandre about them the other day. He told
> me that it looks normal.
Ok great. Hopefully, Alex can ACK then.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v3 1/5] clk: at91: move slow clock controller clocks to sckc.c
From: Alexandre Belloni @ 2016-09-21 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921000211.GH8319@codeaurora.org>
On 20/09/2016 at 17:02:11 -0700, Stephen Boyd wrote :
> On 09/20, Alexandre Belloni wrote:
> > Move all clocks related to the slow clock controller to sckc.c. This avoids
> > extern definitions and allows to remove sckc.h
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > ---
>
> Applied to clk-next
>
Thanks for the fix!
> drivers/clk/at91/sckc.c:146:13:
> warning: symbol 'of_at91sam9x5_clk_slow_osc_setup' was not
> declared. Should it be static?
> drivers/clk/at91/sckc.c:260:13:
> warning: symbol 'of_at91sam9x5_clk_slow_rc_osc_setup' was not
> declared. Should it be static?
> drivers/clk/at91/sckc.c:359:13:
> warning: symbol 'of_at91sam9x5_clk_slow_setup' was not declared.
> Should it be static?
>
> ----8<----
> diff --git a/drivers/clk/at91/sckc.c b/drivers/clk/at91/sckc.c
> index f6ed711af738..311956abf4aa 100644
> --- a/drivers/clk/at91/sckc.c
> +++ b/drivers/clk/at91/sckc.c
> @@ -143,8 +143,8 @@ at91_clk_register_slow_osc(void __iomem *sckcr,
> return hw;
> }
>
> -void __init of_at91sam9x5_clk_slow_osc_setup(struct device_node *np,
> - void __iomem *sckcr)
> +static void __init
> +of_at91sam9x5_clk_slow_osc_setup(struct device_node *np, void __iomem *sckcr)
> {
> struct clk_hw *hw;
> const char *parent_name;
> @@ -257,8 +257,8 @@ at91_clk_register_slow_rc_osc(void __iomem *sckcr,
> return hw;
> }
>
> -void __init of_at91sam9x5_clk_slow_rc_osc_setup(struct device_node *np,
> - void __iomem *sckcr)
> +static void __init
> +of_at91sam9x5_clk_slow_rc_osc_setup(struct device_node *np, void __iomem *sckcr)
> {
> struct clk_hw *hw;
> u32 frequency = 0;
> @@ -356,8 +356,8 @@ at91_clk_register_sam9x5_slow(void __iomem *sckcr,
> return hw;
> }
>
> -void __init of_at91sam9x5_clk_slow_setup(struct device_node *np,
> - void __iomem *sckcr)
> +static void __init
> +of_at91sam9x5_clk_slow_setup(struct device_node *np, void __iomem *sckcr)
> {
> struct clk_hw *hw;
> const char *parent_names[2];
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] phy-sun4i-usb: Add sun4i_usb_phy_force_session_end() function
From: Hans de Goede @ 2016-09-21 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E0BEDF.2020603@ti.com>
Hi,
On 09/20/2016 07:45 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Sunday 18 September 2016 10:20 PM, Hans de Goede wrote:
>> The sunxi musb has a bug where sometimes it will generate a babble
>> error on device disconnect instead of a disconnect irq. When this
>> happens the musb-controller switches from host mode to device mode
>> (it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
>> gets stuck in this state.
>>
>> Clearing this requires reporting Vbus low for 200 or more ms, but
>> on some devices Vbus is simply always high (host-only mode, no Vbus
>> control). The phy-sun4i-usb code already has code to force a session
>> end for devices without Vbus control.
>>
>> This commit adds a sun4i_usb_phy_force_session_end() function exporting
>> this functionality to the sunxi-musb glue, so that it can force a session
>> end to fixup the stuck state after a babble error.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/phy/phy-sun4i-usb.c | 11 +++++++++++
>> include/linux/phy/phy-sun4i-usb.h | 7 +++++++
>> 2 files changed, 18 insertions(+)
>>
>> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
>> index 43c0d98..06f4e11a 100644
>> --- a/drivers/phy/phy-sun4i-usb.c
>> +++ b/drivers/phy/phy-sun4i-usb.c
>> @@ -470,6 +470,17 @@ void sun4i_usb_phy_set_squelch_detect(struct phy *_phy, bool enabled)
>> }
>> EXPORT_SYMBOL_GPL(sun4i_usb_phy_set_squelch_detect);
>>
>> +void sun4i_usb_phy_force_session_end(struct phy *_phy)
>> +{
>> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>> + struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
>> +
>> + data->id_det = -1;
>> + data->force_session_end = true;
>> + queue_delayed_work(system_wq, &data->detect, 0);
>> +}
>> +EXPORT_SYMBOL_GPL(sun4i_usb_phy_force_session_end);
>
> Er.. one more export symbol :-(
Yes unfortunately we need one more to work around sunxi musb / phy bugs.
>> +
>> static const struct phy_ops sun4i_usb_phy_ops = {
>> .init = sun4i_usb_phy_init,
>> .exit = sun4i_usb_phy_exit,
>> diff --git a/include/linux/phy/phy-sun4i-usb.h b/include/linux/phy/phy-sun4i-usb.h
>> index 50aed92..3bb773f 100644
>> --- a/include/linux/phy/phy-sun4i-usb.h
>> +++ b/include/linux/phy/phy-sun4i-usb.h
>> @@ -23,4 +23,11 @@
>> */
>> void sun4i_usb_phy_set_squelch_detect(struct phy *phy, bool enabled);
>>
>> +/**
>> + * sun4i_usb_force_session_end() - Force the current session to end
>> + * by reporting VBus low for 200+ ms
>> + * @phy: reference to a sun4i usb phy
>> + */
>> +void sun4i_usb_phy_force_session_end(struct phy *phy);
>
> Should we include a static inline function if sun4i phy is not defined?
No, we're also not doing that for the already exported
sun4i_usb_phy_set_squelch_detect()
And it is not necessary since the only caller is drivers/usb/musb/sunxi.c,
and drivers/usb/musb/Kconfig has:
config USB_MUSB_SUNXI
tristate "Allwinner (sunxi)"
depends on PHY_SUN4I_USB
Regards,
Hans
^ permalink raw reply
* [PATCH V6 4/5] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Tomasz Nowicki @ 2016-09-21 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920130839.GA13855@localhost>
On 20.09.2016 15:08, Bjorn Helgaas wrote:
> On Tue, Sep 20, 2016 at 09:06:23AM +0200, Tomasz Nowicki wrote:
>> On 19.09.2016 17:45, Bjorn Helgaas wrote:
>>> On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
>>>> ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
>>>> compliant with ECAM standard. It uses non-standard configuration space
>>>> accessors (see pci_thunder_pem_ops) and custom configuration space granulation
>>>> (see bus_shift = 24). In order to access configuration space and
>>>> probe PEM as ACPI based PCI host controller we need to add MCFG quirk
>>>> infrastructure. This involves:
>>>> 1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
>>>> code.
>>>> 2. New quirk entries for each PEM segment. Each contains platform IDs,
>>>> mentioned pci_thunder_pem_ops and CFG resources.
>>>>
>>>> Quirk is considered for ThunderX silicon pass2.x only which is identified
>>>> via MCFG revision 1.
>>>
>>> Is it really the case that silicon pass2.x has MCFG revision 1, and
>>> silicon pass1.x has MCFG revision 2? That just seems backwards.
>>
>> It is weird but silicon pass2.x is more common and it had MCFG
>> revision 1 from the beginning. Unless it is allowed to use MCFG
>> revision 0 ? Then we could use MCFG revision 0 for pass1.x
>
> There's no reason to avoid revision 0. The question is really what
> firmware is already in the field. We need to accommodate that. We don't
> want a situation where kernel version X only works with firmware version Y,
> but kernel version X+1 only works with firmware version Y+1.
Yes I agree. We have already deployed the firmware where:
pass2.x has MCFG revision 1
pass1.x has MCFG revision 2
so we need to stick to this.
Thanks,
Tomasz
^ permalink raw reply
* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-21 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87eg4e5xop.fsf@free-electrons.com>
On Tuesday, September 20, 2016 6:43:34 PM CEST Gregory CLEMENT wrote:
>
> Do you mean board-wnr854t.c?
Yes.
> If it is the case then I can just drop the patch adding this file because
> the only things done in this file are about the PCI.
Ah, that's perfect. Just for more background, I think it shouldn't be too
hard to convert the existing orion5x PCI support into a proper host driver,
and I can assist anyone willing to work on this and test it.
I think the steps here would roughly be:
- change PCI (not PCIe) host initialization to call
pci_scan_root_bus() directly, bypassing the pci_common_init
logic
- move PCI code into a separate file
- change PCI code into a driver by adding platform_device based
probing
- add DT support for that driver.
For the PCIe code, the obvious strategy is to replace it with
the existing pcie-mvebu driver, adding any missing parts
in the process.
Arnd
^ 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