* [PATCH] dmaengine: pl330: do not generate unaligned access
From: Robin Murphy @ 2016-12-07 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481116660-27837-1-git-send-email-vladimir.murzin@arm.com>
On 07/12/16 13:17, Vladimir Murzin wrote:
> When PL330 is used with !MMU the following fault is seen:
>
> Unhandled fault: alignment exception (0x801) at 0x8f26a002
> Internal error: : 801 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 640 Comm: dma0chan0-copy0 Not tainted 4.8.0-6a82063-clean+ #1600
> Hardware name: ARM-Versatile Express
> task: 8f1baa80 task.stack: 8e6fe000
> PC is at _setup_req+0x4c/0x350
> LR is at 0x8f2cbc00
> pc : [<801ea538>] lr : [<8f2cbc00>] psr: 60000093
> sp : 8e6ffdc0 ip : 00000000 fp : 00000000
> r10: 00000000 r9 : 8f2cba10 r8 : 8f2cbc00
> r7 : 80000013 r6 : 8f21a050 r5 : 8f21a000 r4 : 8f2ac800
> r3 : 8e6ffe18 r2 : 00944251 r1 : ffffffbc r0 : 8f26a000
> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 00c5387c
> Process dma0chan0-copy0 (pid: 640, stack limit = 0x8e6fe210)
> Stack: (0x8e6ffdc0 to 0x8e700000)
> fdc0: 00000001 60000093 00000000 8f2cba10 8f26a000 00000004 8f0ae000 8f2cbc00
> fde0: 8f0ae000 8f2ac800 8f21a000 8f21a050 80000013 8f2cbc00 8f2cba10 00000000
> fe00: 60000093 801ebca0 8e6ffe18 000013ff 40000093 00000000 00944251 8f2ac800
> fe20: a0000013 8f2b1320 00001986 00000000 00000001 000013ff 8f1e4f00 8f2cba10
> fe40: 8e6fff6c 801e9044 00000003 00000000 fef98c80 002faf07 8e6ffe7c 00000000
> fe60: 00000002 00000000 00001986 8f1f158d 8f1e4f00 80568de4 00000002 00000000
> fe80: 00001986 8f1f53ff 40000001 80580500 8f1f158d 8001e00c 00000000 cfdfdfdf
> fea0: fdae2a25 00000001 00000004 8e6fe000 00000008 00000010 00000000 00000005
> fec0: 8f2b1330 8f2b1334 8e6ffe80 8e6ffe8c 00001986 00000000 8f21a014 00000001
> fee0: 8e6ffe60 8e6ffe78 00000002 00000000 000013ff 00000001 80568de4 8f1e8018
> ff00: 0000158d 8055ec30 00000001 803f6b00 00001986 8f2cba10 fdae2a25 00000001
> ff20: 8f1baca8 8e6fff24 8e6fff24 00000000 8e6fff24 ac6f3037 00000000 00000000
> ff40: 00000000 8e6fe000 8f1e4f40 00000000 8f1e4f40 8f1e4f00 801e84ec 00000000
> ff60: 00000000 00000000 00000000 80031714 dfdfdfcf 00000000 dfdfdfcf 8f1e4f00
> ff80: 00000000 8e6fff84 8e6fff84 00000000 8e6fff90 8e6fff90 8e6fffac 8f1e4f40
> ffa0: 80031640 00000000 00000000 8000f548 00000000 00000000 00000000 00000000
> ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 dfdfdfcf cfdfdfdf
> [<801ea538>] (_setup_req) from [<801ebca0>] (pl330_tasklet+0x41c/0x490)
> [<801ebca0>] (pl330_tasklet) from [<801e9044>] (dmatest_func+0xb58/0x149c)
> [<801e9044>] (dmatest_func) from [<80031714>] (kthread+0xd4/0xec)
> [<80031714>] (kthread) from [<8000f548>] (ret_from_fork+0x14/0x2c)
> Code: e3a03001 e3e01043 e5c03001 e59d3048 (e5802002)
>
> This happens because _emit_{ADDH,MOV,GO) accessing to unaligned data
> while writing to buffer. Fix it with writing to buffer byte by byte.
>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
I don't have a NOMMU setup, but I checked arm64 (both little- and
big-endian) sees no regressions:
Tested-by: Robin Murphy <robin.murphy@arm.com>
Cheers,
Robin.
> ---
> drivers/dma/pl330.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 030fe05..e4c1ba7 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -570,7 +570,8 @@ static inline u32 _emit_ADDH(unsigned dry_run, u8 buf[],
>
> buf[0] = CMD_DMAADDH;
> buf[0] |= (da << 1);
> - *((__le16 *)&buf[1]) = cpu_to_le16(val);
> + buf[1] = val;
> + buf[2] = val >> 8;
>
> PL330_DBGCMD_DUMP(SZ_DMAADDH, "\tDMAADDH %s %u\n",
> da == 1 ? "DA" : "SA", val);
> @@ -724,7 +725,10 @@ static inline u32 _emit_MOV(unsigned dry_run, u8 buf[],
>
> buf[0] = CMD_DMAMOV;
> buf[1] = dst;
> - *((__le32 *)&buf[2]) = cpu_to_le32(val);
> + buf[2] = val;
> + buf[3] = val >> 8;
> + buf[4] = val >> 16;
> + buf[5] = val >> 24;
>
> PL330_DBGCMD_DUMP(SZ_DMAMOV, "\tDMAMOV %s 0x%x\n",
> dst == SAR ? "SAR" : (dst == DAR ? "DAR" : "CCR"), val);
> @@ -899,10 +903,11 @@ static inline u32 _emit_GO(unsigned dry_run, u8 buf[],
>
> buf[0] = CMD_DMAGO;
> buf[0] |= (ns << 1);
> -
> buf[1] = chan & 0x7;
> -
> - *((__le32 *)&buf[2]) = cpu_to_le32(addr);
> + buf[2] = addr;
> + buf[3] = addr >> 8;
> + buf[4] = addr >> 16;
> + buf[5] = addr >> 24;
>
> return SZ_DMAGO;
> }
>
^ permalink raw reply
* [RFC v3 09/10] iommu/arm-smmu: Implement reserved region get/put callbacks
From: Auger Eric @ 2016-12-07 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <02c0ce15-fa67-e65f-3a4e-f543cc9fd3b8@arm.com>
Hi Robin,
On 06/12/2016 19:55, Robin Murphy wrote:
> On 15/11/16 13:09, Eric Auger wrote:
>> The get() populates the list with the PCI host bridge windows
>> and the MSI IOVA range.
>>
>> At the moment an arbitray MSI IOVA window is set at 0x8000000
>> of size 1MB. This will allow to report those info in iommu-group
>> sysfs?
First thank you for reviewing the series. This is definitively helpful!
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> RFC v2 -> v3:
>> - use existing get/put_resv_regions
>>
>> RFC v1 -> v2:
>> - use defines for MSI IOVA base and length
>> ---
>> drivers/iommu/arm-smmu.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 52 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 8f72814..81f1a83 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>>
>> #define FSYNR0_WNR (1 << 4)
>>
>> +#define MSI_IOVA_BASE 0x8000000
>> +#define MSI_IOVA_LENGTH 0x100000
>> +
>> static int force_stage;
>> module_param(force_stage, int, S_IRUGO);
>> MODULE_PARM_DESC(force_stage,
>> @@ -1545,6 +1548,53 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
>> return iommu_fwspec_add_ids(dev, &fwid, 1);
>> }
>>
>> +static void arm_smmu_get_resv_regions(struct device *dev,
>> + struct list_head *head)
>> +{
>> + struct iommu_resv_region *region;
>> + struct pci_host_bridge *bridge;
>> + struct resource_entry *window;
>> +
>> + /* MSI region */
>> + region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
>> + IOMMU_RESV_MSI);
>> + if (!region)
>> + return;
>> +
>> + list_add_tail(®ion->list, head);
>> +
>> + if (!dev_is_pci(dev))
>> + return;
>> +
>> + bridge = pci_find_host_bridge(to_pci_dev(dev)->bus);
>> +
>> + resource_list_for_each_entry(window, &bridge->windows) {
>> + phys_addr_t start;
>> + size_t length;
>> +
>> + if (resource_type(window->res) != IORESOURCE_MEM &&
>> + resource_type(window->res) != IORESOURCE_IO)
>
> As Joerg commented elsewhere, considering anything other than memory
> resources isn't right (I appreciate you've merely copied my own mistake
> here). We need some other way to handle root complexes where the CPU
> MMIO views of PCI windows appear in PCI memory space - using the I/O
> address of I/O resources only works by chance on Juno, and it still
> doesn't account for config space. I suggest we just leave that out for
> the time being to make life easier (does it even apply to anything other
> than Juno?) and figure it out later.
OK so I understand I should remove IORESOURCE_IO check.
>
>> + continue;
>> +
>> + start = window->res->start - window->offset;
>> + length = window->res->end - window->res->start + 1;
>> + region = iommu_alloc_resv_region(start, length,
>> + IOMMU_RESV_NOMAP);
>> + if (!region)
>> + return;
>> + list_add_tail(®ion->list, head);
>> + }
>> +}
>
> Either way, there's nothing SMMU-specific about PCI windows. The fact
> that we'd have to copy-paste all of this into the SMMUv3 driver
> unchanged suggests it should go somewhere common (although I would be
> inclined to leave the insertion of the fake MSI region to driver-private
> wrappers). As I said before, the current iova_reserve_pci_windows()
> simply wants splitting into appropriate public callbacks for
> get_resv_regions and apply_resv_regions.
Do you mean somewhere common in the arm-smmu subsystem (new file) or in
another subsystem (pci?)
More generally the current implementation does not handle the case where
any of those PCIe host bridge window collide with the MSI window. To me
this is a flaw.
1) Either we take into account the PCIe windows and prevent any
collision when allocating the MSI window.
2) or we do not care about PCIe host bridge windows at kernel level.
If 1) we are back to the original issue of where do we put the MSI
window. Obviously at a place which might not be QEMU friendly anymore.
What allocation policy shall we use?
Second option - sorry I may look stubborn - which I definitively prefer
and which was also advocated by Alex, we handle PCI host bridge windows
at user level. MSI window is reported through the iommu group sysfs.
PCIe host bridge windows can be enumerated through /proc/iomem. Both x86
iommu and arm smmu would report an MSI reserved window. ARM MSI window
would become a de facto reserved window for guests.
Thoughts?
Eric
>
> Robin.
>
>> +static void arm_smmu_put_resv_regions(struct device *dev,
>> + struct list_head *head)
>> +{
>> + struct iommu_resv_region *entry, *next;
>> +
>> + list_for_each_entry_safe(entry, next, head, list)
>> + kfree(entry);
>> +}
>> +
>> static struct iommu_ops arm_smmu_ops = {
>> .capable = arm_smmu_capable,
>> .domain_alloc = arm_smmu_domain_alloc,
>> @@ -1560,6 +1610,8 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
>> .domain_get_attr = arm_smmu_domain_get_attr,
>> .domain_set_attr = arm_smmu_domain_set_attr,
>> .of_xlate = arm_smmu_of_xlate,
>> + .get_resv_regions = arm_smmu_get_resv_regions,
>> + .put_resv_regions = arm_smmu_put_resv_regions,
>> .pgsize_bitmap = -1UL, /* Restricted during device attach */
>> };
>>
>>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v3 0/4] mm: fix the "counter.sh" failure for libhugetlbfs
From: Michal Hocko @ 2016-12-07 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206100358.GA4619@sha-win-210.asiapac.arm.com>
On Tue 06-12-16 18:03:59, Huang Shijie wrote:
> On Mon, Dec 05, 2016 at 05:31:01PM +0800, Michal Hocko wrote:
> > On Mon 05-12-16 17:17:07, Huang Shijie wrote:
> > [...]
> > > The failure is caused by:
> > > 1) kernel fails to allocate a gigantic page for the surplus case.
> > > And the gather_surplus_pages() will return NULL in the end.
> > >
> > > 2) The condition checks for some functions are wrong:
> > > return_unused_surplus_pages()
> > > nr_overcommit_hugepages_store()
> > > hugetlb_overcommit_handler()
> >
> > OK, so how is this any different from gigantic (1G) hugetlb pages on
> I think there is no different from gigantic (1G) hugetlb pages on
> x86_64. Do anyone ever tested the 1G hugetlb pages in x86_64 with the "counter.sh"
> before?
I suspect nobody has because the gigantic page support is still somehow
coarse and from a quick look into the code we only support pre-allocated
giga pages. In other words surplus pages and their accounting is not
supported at all.
I haven't yet checked your patchset but I can tell you one thing.
Surplus and subpool pages code is tricky as hell. And it is not just a
matter of teaching the huge page allocation code to do the right thing.
There are subtle details all over the place. E.g. we currently
do not free giga pages AFAICS. In fact I believe that the giga pages are
kind of implanted to the existing code without any higher level
consistency. This should change long term. But I am worried it is much
more work.
Now I might be wrong because I might misremember things which might have
been changed recently but please make sure you describe the current
state and changes of giga pages when touching this area much better if
you want to pursue this route...
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel
From: Daniel Vetter @ 2016-12-07 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2C9FE0C5-F521-48CD-B274-66128312CA75@soulik.info>
On Wed, Dec 07, 2016 at 08:57:23AM +0800, Ayaka wrote:
>
>
> ??? iPad ??
>
> > Thierry Reding <thierry.reding@gmail.com> ? 2016?12?6? ??11:46 ???
> >
> >> On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
> >> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
> >> supported by the simple panel driver.
> >>
> >> Signed-off-by: Randy Li <ayaka@soulik.info>
> >> ---
> >> .../display/panel/chunghwa,claa070wp03xg.txt | 7 ++++++
> >> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> >> 2 files changed, 34 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
> >
> > Applied, thanks.
> Wait, it is RFC, not pass the test.
Well 2 months of silence, it's reasonable to assume that this works for
you ... I guess you need to supply a fixup patch asap ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v5 3/5] [media] davinci: vpif_capture: fix start/stop streaming locking
From: Laurent Pinchart @ 2016-12-07 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-4-khilman@baylibre.com>
Hi Kevin,
Thank you for the patch.
On Tuesday 06 Dec 2016 21:08:24 Kevin Hilman wrote:
> Video capture subdevs may be over I2C and may sleep during xfer, so we
> cannot do IRQ-disabled locking when calling the subdev.
>
> The IRQ-disabled locking is meant to protect the DMA queue list
> throughout the rest of the driver, so update the locking in
> [start|stop]_streaming to protect just this list.
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
I would also add a comment to document the irqlock field as protecting the
dma_queue list only. Something like
- /* Used in video-buf */
+ /* Protects the dma_queue field */
spinlock_t irqlock;
With that,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/media/platform/davinci/vpif_capture.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c index
> c24049acd40a..f72a719efb3d 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -179,8 +179,6 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count) unsigned long addr, flags;
> int ret;
>
> - spin_lock_irqsave(&common->irqlock, flags);
> -
> /* Initialize field_id */
> ch->field_id = 0;
>
> @@ -211,6 +209,7 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count) vpif_config_addr(ch, ret);
>
> /* Get the next frame from the buffer queue */
> + spin_lock_irqsave(&common->irqlock, flags);
> common->cur_frm = common->next_frm = list_entry(common-
>dma_queue.next,
> struct vpif_cap_buffer, list);
> /* Remove buffer from the buffer queue */
> @@ -244,6 +243,7 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count) return 0;
>
> err:
> + spin_lock_irqsave(&common->irqlock, flags);
> list_for_each_entry_safe(buf, tmp, &common->dma_queue, list) {
> list_del(&buf->list);
> vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_QUEUED);
> @@ -287,7 +287,6 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
> vpif_dbg(1, debug, "stream off failed in subdev\n");
>
> /* release all active buffers */
> - spin_lock_irqsave(&common->irqlock, flags);
> if (common->cur_frm == common->next_frm) {
> vb2_buffer_done(&common->cur_frm->vb.vb2_buf,
> VB2_BUF_STATE_ERROR);
> @@ -300,6 +299,7 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
> VB2_BUF_STATE_ERROR);
> }
>
> + spin_lock_irqsave(&common->irqlock, flags);
> while (!list_empty(&common->dma_queue)) {
> common->next_frm = list_entry(common->dma_queue.next,
> struct vpif_cap_buffer, list);
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v3] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Alexandre Belloni @ 2016-12-07 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121140248.utlir6krokjeeobi@piout.net>
Hi,
On 21/11/2016 at 15:02:48 +0100, Alexandre Belloni wrote :
> > Changes in v3:
> > - Use a dual license scheme for DT files.
> > - Use the proper model name and the compatible string to reflect
> > the nature of this new "CMP" board.
> > - Change name of wakeup property to "wakeup-source".
> > - Remove unnecessary comments.
> > - Remove bootargs.
> >
> > Changes in v2:
> > - Add the pinctrl sleep state for adc0 node to fix the over
> > consumption on VDDANA.
> > - Improve the commit log.
> >
> > arch/arm/boot/dts/sama5d36ek_cmp.dts | 87 ++++++++++
> > arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 201 +++++++++++++++++++++++
> > arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 301 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 589 insertions(+)
> > create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> > create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> > create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> >
> Applied, thanks.
>
Actually, I have to postpone this one for 4.12 because it depends on
https://patchwork.ozlabs.org/patch/688265/
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Greg Ungerer @ 2016-12-07 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58481C3C.9090006@arm.com>
Hi Vladimir,
On 08/12/16 00:27, Vladimir Murzin wrote:
> Hi Greg,
>
> On 07/12/16 14:21, Greg Ungerer wrote:
>> Hi Vladimir,
>>
>> On 07/12/16 23:57, Greg Ungerer wrote:
>>> On 07/12/16 19:23, Vladimir Murzin wrote:
>>>> On 07/12/16 06:08, Greg Ungerer wrote:
>>>>> Does the ARM Versatile machine have a maintainer?
>>>>> I have CC'ed this patch set to those names reported by get_maintainer.
>>>>> I had no feedback on the first posting of this series back in August.
>>>>>
>>>>> The following patches support configuring and building the versatile
>>>>> machine with a no-MMU kernel.
>>>>>
>>>>> There is only a few minor changes required. It was previously possible
>>>>> in older kernels to build for versatile with CONFIG_MMU disabled, but
>>>>> the change to devicetree lost that capability. These changes make it
>>>>> possible again.
>>>>>
>>>>> One patch is a fix for address translation (broken in older kernels
>>>>> too),
>>>>> two are build problems when CONFIG_MMU is disabled, and the last is the
>>>>> actuall configuration changes needed.
>>>>>
>>>>> The motivation for this is that the versatile machine is well supported
>>>>> in qemu. And this provides an excellent platform for development and
>>>>> testing no-MMU support on ARM in general. With these patches applied
>>>>> it is possible to build and run a kernel with MMU disabled on qemu.
>>>>
>>>> I'm wondering if my "Allow NOMMU for MULTIPLATFORM" series [1] work
>>>> for you?
>>>>
>>>> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
>>>
>>> Sorry I hadn't seen these patches before.
>>>
>>> Just tried them out. With CONFIG_EXPERT set I can select and
>>> build for the Versatile machine with CONFIG_MMU not set. The
>>> build is successful, but the resulting kernel doesn't boot.
>>>
>>> I see that the resulting .config has CONFIG_PLAT_VERSATILE set
>>> but not CONFIG_ARCH_VERSATILE. Is this intentional?
>>
>> Let me revise that. By setting the "Multiple platform selection"
>> selection correctly to v5 platforms I did get CONFIG_ARCH_VERSATILE
>> set, and could still successfully build the kernel.
>>
>> A couple of other config options I had to readjust and I can
>> boot up this kernel under qemu. So success!
>>
>
> Congrats!!!
>
> Thanks for trying these patches! It is really nice to see someone else shows
> interest on NOMMU! If you don't mind I'll keep you in Cc when/if I re-spin my
> patches ;)
Yes, please do.
Regards
Greg
> Cheers
> Vladimir
>
>>
>>> With CONFIG_ARCH_VERSATILE missing the build doesn't traverse
>>> into arch/arm/mach-versatile, and you don't get any device tree
>>> built.
>>>
>>> Ultimately to produce a working kernel we will still need my
>>> patch 01/04 ("ARM: versatile: support no-MMU mode addressing").
>>> No surprise here, this was missing in older kernels too.
>>
>> So in the end this is the only extra change I needed as well
>> to get the running kernel.
>>
>> Regards
>> Greg
>>
>>
>>
>
>
^ permalink raw reply
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Greg Ungerer @ 2016-12-07 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZywn46QbnvKcN-jkt43Vf+GBSNQkLgnnNg-DC-8aSO5w@mail.gmail.com>
Hi Linus,
On 08/12/16 00:11, Linus Walleij wrote:
> On Wed, Dec 7, 2016 at 7:59 AM, Greg Ungerer <gerg@uclinux.org> wrote:
>
>> The motivation for this is that the versatile machine is well supported
>> in qemu. And this provides an excellent platform for development and
>> testing no-MMU support on ARM in general.
>>
>> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
>
> Pretty cool eh?
Yep :-)
> Have you tested it on real hardware?
No, I don't have a Versatile board, or access to one...
> Otherwise I can test it if I have a git branch
> I can pull in and compile.
I have been stashing the changes here for now:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
in the armnommu branch.
> Another target I had in mind was the Integrator which
> incidentally supports a bunch of the old noMMU core
> tiles where we can swap in an ARM946, which I guess
> could work with this?
It should do, or at least should be able to be made to work with it.
>> --- a/arch/arm/mach-versatile/Kconfig
>> +++ b/arch/arm/mach-versatile/Kconfig
>> @@ -1,12 +1,13 @@
>> config ARCH_VERSATILE
>> bool "ARM Ltd. Versatile family"
>> - depends on ARCH_MULTI_V5
>> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
>> select ARM_AMBA
>> select ARM_TIMER_SP804
>> select ARM_VIC
>> select CLKSRC_VERSATILE
>> select COMMON_CLK_VERSATILE
>> select CPU_ARM926T
>> + select GPIOLIB
>
> Not really related but I don't mind.
No, probably strictly not. But without this here we lose CONFIG_GPIO
for the no-MMU case. When CONFIG_MMU was enabled it was being selected
via some other path through arch/arm/Kconfig - I don't recall at the
moment where exactly.
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Thanks
Greg
^ permalink raw reply
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Vladimir Murzin @ 2016-12-07 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZywn46QbnvKcN-jkt43Vf+GBSNQkLgnnNg-DC-8aSO5w@mail.gmail.com>
Hi Linus,
On 07/12/16 14:11, Linus Walleij wrote:
> Another target I had in mind was the Integrator which
> incidentally supports a bunch of the old noMMU core
> tiles where we can swap in an ARM946, which I guess
> could work with this?
Do you mind trying my "Allow NOMMU for MULTIPLATFORM" series [1]? Greg just
reported it did a trick for Versatile, there is a good chance it would work
for Integrator too ;)
[1] https://www.spinics.net/lists/arm-kernel/msg546823.html
Thanks
Vladimir
^ permalink raw reply
* [PATCH 0/2] Hibernate fixes for 'Fix memmap to be initialized for the entire section'
From: Will Deacon @ 2016-12-07 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207090638.GI10776@rric.localdomain>
On Wed, Dec 07, 2016 at 10:06:38AM +0100, Robert Richter wrote:
> On 06.12.16 17:38:11, Will Deacon wrote:
> > On Mon, Dec 05, 2016 at 03:42:14PM +0000, Ard Biesheuvel wrote:
> > > On 2 December 2016 at 14:49, James Morse <james.morse@arm.com> wrote:
> > > > Patch "arm64: mm: Fix memmap to be initialized for the entire section"
> > > > changes pfn_valid() in a way that breaks hibernate. These patches fix
> > > > hibernate, and provided struct page's are allocated for nomap pages,
> > > > can be applied before [0].
> > > >
> > > > Hibernate core code belives 'valid' to mean "I can access this". It
> > > > uses pfn_valid() to test the page if the page is 'valid'.
> > > >
> > > > pfn_valid() needs to be changed so that all struct pages in a numa
> > > > node have the same node-id. Currently 'nomap' pages are skipped, and
> > > > retain their pre-numa node-ids, which leads to a later BUG_ON().
> > > >
> > > > These patches make hibernate's savable_page() take its escape route
> > > > via 'if (PageReserved(page) && pfn_is_nosave(pfn))'.
> > > >
> > >
> > > This makes me feel slightly uneasy. Robert makes a convincing point,
> > > but I wonder if we can expect more fallout from the ambiguity of
> > > pfn_valid(). Now we are not only forced to assign non-existing (as far
> > > as the OS is concerned) pages to the correct NUMA node, we also need
> > > to set certain page flags.
> >
> > Yes, I really don't know how to proceed here. Playing whack-a-mole with
> > pfn_valid() users doesn't sounds like an improvement on the current
> > situation to me.
> >
> > Robert -- if we leave pfn_valid() as it is, would a point-hack to
> > memmap_init_zone help, or do you anticipate other problems?
>
> I would suggest to fix the hibernation code as I commented on before
> to use pfn_is_nosave() that defaults to pfn_valid() but uses memblock_
> is_nomap() for arm64. Let's just fix it and see if no other issues
> arise. I am trying to send a patch for this until tomorrow.
I'd rather not use mainline as a guinea pig like this, since I'd be very
surprised if other places don't break given the scope for different
interpretations of pfn_valid.
> I am also going to see how early_pfn_valid() could be redirected to
> use memblock_is_nomap() on arm64. That would "quick fix" the problem,
> though I rather prefer to go further with the current solution.
I don't like either of them, but early_pfn_valid is easier to revert so
let's go with that.
Will
^ permalink raw reply
* [PATCH v5 3/4] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-07 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1620991.lLXgDihv8c@avalon>
2016-12-07 15:25 GMT+01:00 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Bartosz,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:42:44 Bartosz Golaszewski wrote:
>> Add the vga-bridge node to the board DT together with corresponding
>> ports and vga connector. This allows to retrieve the edid info from
>> the display automatically.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> arch/arm/boot/dts/da850-lcdk.dts | 67 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 67 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
>> b/arch/arm/boot/dts/da850-lcdk.dts index afcb482..39602eb 100644
>> --- a/arch/arm/boot/dts/da850-lcdk.dts
>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
>> @@ -51,6 +51,51 @@
>> system-clock-frequency = <24576000>;
>> };
>> };
>> +
>> + vga-bridge {
>> + compatible = "ti,ths8135";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port at 0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + vga_bridge_in: endpoint at 0 {
>> + reg = <0>;
>> + remote-endpoint = <&lcdc_out_vga>;
>> + };
>> + };
>> +
>> + port at 1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + vga_bridge_out: endpoint at 0 {
>> + reg = <0>;
>> + remote-endpoint = <&vga_con_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + vga {
>> + compatible = "vga-connector";
>> +
>> + ddc-i2c-bus = <&i2c0>;
>> +
>> + port {
>> + vga_con_in: endpoint {
>> + remote-endpoint = <&vga_bridge_out>;
>> + };
>> + };
>> + };
>> };
>>
>> &pmx_core {
>> @@ -236,3 +281,25 @@
>> &memctrl {
>> status = "okay";
>> };
>> +
>> +&lcdc {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&lcd_pins>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + lcdc_out: port at 1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + lcdc_out_vga: endpoint at 0 {
>> + reg = <0>;
>> + remote-endpoint = <&vga_bridge_in>;
>> + };
>> + };
>
> Just to make sure you're aware, when there's a single endpoint you can
> simplify the DT by omitting the endpoint number. This would become
>
> lcdc_out: port at 1 {
> reg = <1>;
>
> lcdc_out_vga: endpoint {
> remote-endpoint = <&vga_bridge_in>;
> };
> };
>
> It's entirely up to you, both get my
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
>> + };
>> +};
>
> --
> Regards,
>
> Laurent Pinchart
>
Hi Laurent,
thanks for the hint, I'll change it if there's going to be a new
version of the series.
Best regards,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Vladimir Murzin @ 2016-12-07 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22e20a24-5f1e-a23d-0d18-31dc14179cf5@westnet.com.au>
Hi Greg,
On 07/12/16 14:21, Greg Ungerer wrote:
> Hi Vladimir,
>
> On 07/12/16 23:57, Greg Ungerer wrote:
>> On 07/12/16 19:23, Vladimir Murzin wrote:
>>> On 07/12/16 06:08, Greg Ungerer wrote:
>>>> Does the ARM Versatile machine have a maintainer?
>>>> I have CC'ed this patch set to those names reported by get_maintainer.
>>>> I had no feedback on the first posting of this series back in August.
>>>>
>>>> The following patches support configuring and building the versatile
>>>> machine with a no-MMU kernel.
>>>>
>>>> There is only a few minor changes required. It was previously possible
>>>> in older kernels to build for versatile with CONFIG_MMU disabled, but
>>>> the change to devicetree lost that capability. These changes make it
>>>> possible again.
>>>>
>>>> One patch is a fix for address translation (broken in older kernels
>>>> too),
>>>> two are build problems when CONFIG_MMU is disabled, and the last is the
>>>> actuall configuration changes needed.
>>>>
>>>> The motivation for this is that the versatile machine is well supported
>>>> in qemu. And this provides an excellent platform for development and
>>>> testing no-MMU support on ARM in general. With these patches applied
>>>> it is possible to build and run a kernel with MMU disabled on qemu.
>>>
>>> I'm wondering if my "Allow NOMMU for MULTIPLATFORM" series [1] work
>>> for you?
>>>
>>> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
>>
>> Sorry I hadn't seen these patches before.
>>
>> Just tried them out. With CONFIG_EXPERT set I can select and
>> build for the Versatile machine with CONFIG_MMU not set. The
>> build is successful, but the resulting kernel doesn't boot.
>>
>> I see that the resulting .config has CONFIG_PLAT_VERSATILE set
>> but not CONFIG_ARCH_VERSATILE. Is this intentional?
>
> Let me revise that. By setting the "Multiple platform selection"
> selection correctly to v5 platforms I did get CONFIG_ARCH_VERSATILE
> set, and could still successfully build the kernel.
>
> A couple of other config options I had to readjust and I can
> boot up this kernel under qemu. So success!
>
Congrats!!!
Thanks for trying these patches! It is really nice to see someone else shows
interest on NOMMU! If you don't mind I'll keep you in Cc when/if I re-spin my
patches ;)
Cheers
Vladimir
>
>> With CONFIG_ARCH_VERSATILE missing the build doesn't traverse
>> into arch/arm/mach-versatile, and you don't get any device tree
>> built.
>>
>> Ultimately to produce a working kernel we will still need my
>> patch 01/04 ("ARM: versatile: support no-MMU mode addressing").
>> No surprise here, this was missing in older kernels too.
>
> So in the end this is the only extra change I needed as well
> to get the running kernel.
>
> Regards
> Greg
>
>
>
^ permalink raw reply
* [PATCH v5 3/4] ARM: dts: da850-lcdk: add the vga-bridge node
From: Laurent Pinchart @ 2016-12-07 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481107365-24839-4-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:42:44 Bartosz Golaszewski wrote:
> Add the vga-bridge node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 67 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
> b/arch/arm/boot/dts/da850-lcdk.dts index afcb482..39602eb 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -51,6 +51,51 @@
> system-clock-frequency = <24576000>;
> };
> };
> +
> + vga-bridge {
> + compatible = "ti,ths8135";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&lcdc_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> + };
> +
> + vga {
> + compatible = "vga-connector";
> +
> + ddc-i2c-bus = <&i2c0>;
> +
> + port {
> + vga_con_in: endpoint {
> + remote-endpoint = <&vga_bridge_out>;
> + };
> + };
> + };
> };
>
> &pmx_core {
> @@ -236,3 +281,25 @@
> &memctrl {
> status = "okay";
> };
> +
> +&lcdc {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + lcdc_out: port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + lcdc_out_vga: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_bridge_in>;
> + };
> + };
Just to make sure you're aware, when there's a single endpoint you can
simplify the DT by omitting the endpoint number. This would become
lcdc_out: port at 1 {
reg = <1>;
lcdc_out_vga: endpoint {
remote-endpoint = <&vga_bridge_in>;
};
};
It's entirely up to you, both get my
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v5 2/4] drm: bridge: add support for TI ths8135
From: Laurent Pinchart @ 2016-12-07 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJX9b3UqNz_nERH-N58Yw3jkSZ1P+PjjA51x3wTC0So7mQ@mail.gmail.com>
Hi Bartosz,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:45:11 Bartosz Golaszewski wrote:
> 2016-12-07 11:42 GMT+01:00 Bartosz Golaszewski <bgolaszewski@baylibre.com>:
> > THS8135 is a configurable video DAC. Add DT bindings for this chip and
> > use the dumb-vga-dac driver for now as no configuration is required to
> > make it work.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > ---
> >
> > .../bindings/display/bridge/ti,ths8135.txt | 52 +++++++++++++++++
> > drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
You might be asked by DT maintainers to split this in two, but regardless of
whether it's one patch or two, you can add my
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > 2 files changed, 53 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt>
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> > b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt new
> > file mode 100644
> > index 0000000..23cd8ee
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> > @@ -0,0 +1,52 @@
> > +THS8135 Video DAC
> > +-----------------
> > +
> > +This is the binding for Texas Instruments THS8135 Video DAC bridge.
> > +
> > +Required properties:
> > +
> > +- compatible: Must be "ti,ths8135"
> > +
> > +Required nodes:
> > +
> > +This device has two video ports. Their connections are modelled using the
> > OF +graph bindings specified in
> > Documentation/devicetree/bindings/graph.txt. +
> > +- Video port 0 for RGB input
> > +- Video port 1 for VGA output
> > +
> > +Example
> > +-------
> > +
> > +vga-bridge {
> > + compatible = "ti,ths8135";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + vga_bridge_in: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint = <&lcdc_out_vga>;
> > + };
> > + };
> > +
> > + port at 1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <1>;
> > +
> > + vga_bridge_out: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint = <&vga_con_in>;
> > + };
> > + };
> > + };
> > +};
> > diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > b/drivers/gpu/drm/bridge/dumb-vga-dac.c index afec232..498fa75 100644
> > --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > @@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device
> > *pdev)>
> > static const struct of_device_id dumb_vga_match[] = {
> >
> > { .compatible = "dumb-vga-dac" },
> >
> > + { .compatible = "ti,ths8135" },
> >
> > {},
> >
> > };
> > MODULE_DEVICE_TABLE(of, dumb_vga_match);
> >
> > --
> > 2.9.3
>
> + Maxime
>
> Sorry, I forgot to include your e-mail.
>
> Bartosz
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Greg Ungerer @ 2016-12-07 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a2ab1e0c-d24b-ac8d-fb9a-4ae7271455b9@uclinux.org>
Hi Vladimir,
On 07/12/16 23:57, Greg Ungerer wrote:
> On 07/12/16 19:23, Vladimir Murzin wrote:
>> On 07/12/16 06:08, Greg Ungerer wrote:
>>> Does the ARM Versatile machine have a maintainer?
>>> I have CC'ed this patch set to those names reported by get_maintainer.
>>> I had no feedback on the first posting of this series back in August.
>>>
>>> The following patches support configuring and building the versatile
>>> machine with a no-MMU kernel.
>>>
>>> There is only a few minor changes required. It was previously possible
>>> in older kernels to build for versatile with CONFIG_MMU disabled, but
>>> the change to devicetree lost that capability. These changes make it
>>> possible again.
>>>
>>> One patch is a fix for address translation (broken in older kernels
>>> too),
>>> two are build problems when CONFIG_MMU is disabled, and the last is the
>>> actuall configuration changes needed.
>>>
>>> The motivation for this is that the versatile machine is well supported
>>> in qemu. And this provides an excellent platform for development and
>>> testing no-MMU support on ARM in general. With these patches applied
>>> it is possible to build and run a kernel with MMU disabled on qemu.
>>
>> I'm wondering if my "Allow NOMMU for MULTIPLATFORM" series [1] work
>> for you?
>>
>> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
>
> Sorry I hadn't seen these patches before.
>
> Just tried them out. With CONFIG_EXPERT set I can select and
> build for the Versatile machine with CONFIG_MMU not set. The
> build is successful, but the resulting kernel doesn't boot.
>
> I see that the resulting .config has CONFIG_PLAT_VERSATILE set
> but not CONFIG_ARCH_VERSATILE. Is this intentional?
Let me revise that. By setting the "Multiple platform selection"
selection correctly to v5 platforms I did get CONFIG_ARCH_VERSATILE
set, and could still successfully build the kernel.
A couple of other config options I had to readjust and I can
boot up this kernel under qemu. So success!
> With CONFIG_ARCH_VERSATILE missing the build doesn't traverse
> into arch/arm/mach-versatile, and you don't get any device tree
> built.
>
> Ultimately to produce a working kernel we will still need my
> patch 01/04 ("ARM: versatile: support no-MMU mode addressing").
> No surprise here, this was missing in older kernels too.
So in the end this is the only extra change I needed as well
to get the running kernel.
Regards
Greg
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Linus Walleij @ 2016-12-07 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481090912-29835-1-git-send-email-gerg@uclinux.org>
On Wed, Dec 7, 2016 at 7:08 AM, Greg Ungerer <gerg@uclinux.org> wrote:
> Does the ARM Versatile machine have a maintainer?
Russell did the original port so he tends to look after it a bit.
Rob Herring and myself tend to maintain it a bit too.
> I have CC'ed this patch set to those names reported by get_maintainer.
> I had no feedback on the first posting of this series back in August.
Sorry.
> The following patches support configuring and building the versatile
> machine with a no-MMU kernel.
Which I think is pretty nice.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Vladimir Murzin @ 2016-12-07 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a2ab1e0c-d24b-ac8d-fb9a-4ae7271455b9@uclinux.org>
On 07/12/16 13:57, Greg Ungerer wrote:
> Hi Vladimir,
>
> On 07/12/16 19:23, Vladimir Murzin wrote:
>> Hi Greg,
>>
>> On 07/12/16 06:08, Greg Ungerer wrote:
>>> Does the ARM Versatile machine have a maintainer?
>>> I have CC'ed this patch set to those names reported by get_maintainer.
>>> I had no feedback on the first posting of this series back in August.
>>>
>>> The following patches support configuring and building the versatile
>>> machine with a no-MMU kernel.
>>>
>>> There is only a few minor changes required. It was previously possible
>>> in older kernels to build for versatile with CONFIG_MMU disabled, but
>>> the change to devicetree lost that capability. These changes make it
>>> possible again.
>>>
>>> One patch is a fix for address translation (broken in older kernels too),
>>> two are build problems when CONFIG_MMU is disabled, and the last is the
>>> actuall configuration changes needed.
>>>
>>> The motivation for this is that the versatile machine is well supported
>>> in qemu. And this provides an excellent platform for development and
>>> testing no-MMU support on ARM in general. With these patches applied
>>> it is possible to build and run a kernel with MMU disabled on qemu.
>>
>> I'm wondering if my "Allow NOMMU for MULTIPLATFORM" series [1] work for you?
>>
>> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
>
> Sorry I hadn't seen these patches before.
>
> Just tried them out. With CONFIG_EXPERT set I can select and
> build for the Versatile machine with CONFIG_MMU not set. The
> build is successful, but the resulting kernel doesn't boot.
It is why "no guarantee" there ;)
>
> I see that the resulting .config has CONFIG_PLAT_VERSATILE set
> but not CONFIG_ARCH_VERSATILE. Is this intentional?
No.
>
> With CONFIG_ARCH_VERSATILE missing the build doesn't traverse
> into arch/arm/mach-versatile, and you don't get any device tree
> built.
>
I've just done:
$ make ARCH=arm versatile_defconfig nommu.config
...
$ grep VERSATILE .config 1 CONFIG_ARCH_VERSATILE=y
CONFIG_PLAT_VERSATILE=y
CONFIG_I2C_VERSATILE=y
CONFIG_POWER_RESET_VERSATILE=y
CONFIG_PLAT_VERSATILE_CLCD=y
# CONFIG_LEDS_VERSATILE is not set
CONFIG_COMMON_CLK_VERSATILE=y
CONFIG_CLKSRC_VERSATILE=y
CONFIG_VERSATILE_FPGA_IRQ=y
CONFIG_VERSATILE_FPGA_IRQ_NR=4
CONFIG_DEBUG_VERSATILE=y
$ cat arch/arm/configs/nommu.config
CONFIG_EXPERT=y
# CONFIG_MMU is not set
I didn't submit nommu config fragment, but it is is what I've been using to
simplify defconfigs and randconfig builds.
> Ultimately to produce a working kernel we will still need my
> patch 01/04 ("ARM: versatile: support no-MMU mode addressing").
> No surprise here, this was missing in older kernels too.
Agreed.
Cheers
Vladimir
>
> Regards
> Greg
>
>
>>>
>>> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
>>> ---
>>> arch/arm/Kconfig | 10 ++++++++++
>>> arch/arm/Kconfig.debug | 3 ++-
>>> arch/arm/include/asm/mach/map.h | 1 +
>>> arch/arm/mach-versatile/Kconfig | 3 ++-
>>> arch/arm/mach-versatile/Makefile.boot | 3 +++
>>> arch/arm/mach-versatile/versatile_dt.c | 4 ++++
>>> 6 files changed, 22 insertions(+), 2 deletions(-)
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
>>
>
^ permalink raw reply
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Linus Walleij @ 2016-12-07 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481093992-30520-2-git-send-email-gerg@uclinux.org>
On Wed, Dec 7, 2016 at 7:59 AM, Greg Ungerer <gerg@uclinux.org> wrote:
> The motivation for this is that the versatile machine is well supported
> in qemu. And this provides an excellent platform for development and
> testing no-MMU support on ARM in general.
>
> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Pretty cool eh?
Have you tested it on real hardware?
Otherwise I can test it if I have a git branch
I can pull in and compile.
Another target I had in mind was the Integrator which
incidentally supports a bunch of the old noMMU core
tiles where we can swap in an ARM946, which I guess
could work with this?
> --- a/arch/arm/mach-versatile/Kconfig
> +++ b/arch/arm/mach-versatile/Kconfig
> @@ -1,12 +1,13 @@
> config ARCH_VERSATILE
> bool "ARM Ltd. Versatile family"
> - depends on ARCH_MULTI_V5
> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
> select ARM_AMBA
> select ARM_TIMER_SP804
> select ARM_VIC
> select CLKSRC_VERSATILE
> select COMMON_CLK_VERSATILE
> select CPU_ARM926T
> + select GPIOLIB
Not really related but I don't mind.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 2/3] soc: zte: pm_domains: Add support for zx296718 board
From: Shawn Guo @ 2016-12-07 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481091204-6559-2-git-send-email-baoyou.xie@linaro.org>
On Wed, Dec 07, 2016 at 02:13:23PM +0800, Baoyou Xie wrote:
> This patch introduces the power domain driver of zx296718
> which belongs to zte's 2967 family.
The 'board' in subject is not appropriate, as zx296718 is a SoC, not
board.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
When you repost, tags like Reviewed-by, Acked-by, and Tested-by provided
by people on your patches should be added after your Signed-off-by line.
Specifically, the Reviewed-by from Jun Nie on v2 of the patch should be
added here.
> ---
> drivers/soc/zte/Makefile | 2 +-
> drivers/soc/zte/zx296718_pm_domains.c | 194 ++++++++++++++++++++++++++++++++++
> 2 files changed, 195 insertions(+), 1 deletion(-)
> create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
>
> diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
> index 97ac8ea..2d2a2cc 100644
> --- a/drivers/soc/zte/Makefile
> +++ b/drivers/soc/zte/Makefile
> @@ -1,4 +1,4 @@
> #
> # zx SOC drivers
> #
> -obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o zx296718_pm_domains.o
I would suggest to name it pm_domains_zx296718.o, so that power domain
files can alphabetically grouped. Also, we may want to write the
Makefile like below, so that a target can be added or removed easily.
obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o
obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains_zx296718.o
> diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
> new file mode 100644
> index 0000000..5355b94
> --- /dev/null
> +++ b/drivers/soc/zte/zx296718_pm_domains.c
> @@ -0,0 +1,194 @@
> +/*
> + * Copyright (C) 2015 ZTE Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +#include <dt-bindings/arm/zte_pm_domains.h>
The header is added by another patch. You should include that patch
into the series, as there is dependency between patches.
> +#include "pm_domains.h"
> +
> +static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
> + [REG_CLKEN] = 0x18,
> + [REG_ISOEN] = 0x1c,
> + [REG_RSTEN] = 0x20,
> + [REG_PWREN] = 0x24,
> + [REG_ACK_SYNC] = 0x28,
> +};
> +
> +enum {
> + PCU_DM_VOU = 0,
> + PCU_DM_SAPPU,
> + PCU_DM_VDE,
> + PCU_DM_VCE,
> + PCU_DM_HDE,
> + PCU_DM_VIU,
> + PCU_DM_USB20,
> + PCU_DM_USB21,
> + PCU_DM_USB30,
> + PCU_DM_HSIC,
> + PCU_DM_GMAC,
> + PCU_DM_TS,
> +};
> +
> +static struct 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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
Please have a newline between struct variables.
> +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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +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,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +static struct zx_pm_domain ts_domain = {
> + .dm = {
> + .name = "ts_domain",
> + .power_off = zx_normal_power_off,
> + .power_on = zx_normal_power_on,
Can we assign these two function hooks in zx_pd_probe()? If so, both
functions can be static ones in pm_domains.c.
> + },
> + .bit = PCU_DM_TS,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +struct generic_pm_domain *zx296718_pm_domains[] = {
static?
> + [DM_ZX296718_SAPPU] = &sappu_domain.dm,
> + [DM_ZX296718_VDE] = &vde_domain.dm,
> + [DM_ZX296718_VCE] = &vce_domain.dm,
> + [DM_ZX296718_HDE] = &hde_domain.dm,
> + [DM_ZX296718_VIU] = &viu_domain.dm,
> + [DM_ZX296718_USB20] = &usb20_domain.dm,
> + [DM_ZX296718_USB21] = &usb21_domain.dm,
> + [DM_ZX296718_USB30] = &usb30_domain.dm,
> + [DM_ZX296718_HSIC] = &hsic_domain.dm,
> + [DM_ZX296718_GMAC] = &gmac_domain.dm,
> + [DM_ZX296718_TS] = &ts_domain.dm,
> + [DM_ZX296718_VOU] = &vou_domain.dm,
> +};
> +
> +static int zx296718_pd_probe(struct platform_device *pdev)
> +{
> + return 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", },
Where is the patch documents the bindings?
Shawn
> + { },
> +};
> +
> +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
* [PATCH 0/4] arm/versatile: no-MMU support
From: Greg Ungerer @ 2016-12-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5847D4F8.1080108@arm.com>
Hi Vladimir,
On 07/12/16 19:23, Vladimir Murzin wrote:
> Hi Greg,
>
> On 07/12/16 06:08, Greg Ungerer wrote:
>> Does the ARM Versatile machine have a maintainer?
>> I have CC'ed this patch set to those names reported by get_maintainer.
>> I had no feedback on the first posting of this series back in August.
>>
>> The following patches support configuring and building the versatile
>> machine with a no-MMU kernel.
>>
>> There is only a few minor changes required. It was previously possible
>> in older kernels to build for versatile with CONFIG_MMU disabled, but
>> the change to devicetree lost that capability. These changes make it
>> possible again.
>>
>> One patch is a fix for address translation (broken in older kernels too),
>> two are build problems when CONFIG_MMU is disabled, and the last is the
>> actuall configuration changes needed.
>>
>> The motivation for this is that the versatile machine is well supported
>> in qemu. And this provides an excellent platform for development and
>> testing no-MMU support on ARM in general. With these patches applied
>> it is possible to build and run a kernel with MMU disabled on qemu.
>
> I'm wondering if my "Allow NOMMU for MULTIPLATFORM" series [1] work for you?
>
> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
Sorry I hadn't seen these patches before.
Just tried them out. With CONFIG_EXPERT set I can select and
build for the Versatile machine with CONFIG_MMU not set. The
build is successful, but the resulting kernel doesn't boot.
I see that the resulting .config has CONFIG_PLAT_VERSATILE set
but not CONFIG_ARCH_VERSATILE. Is this intentional?
With CONFIG_ARCH_VERSATILE missing the build doesn't traverse
into arch/arm/mach-versatile, and you don't get any device tree
built.
Ultimately to produce a working kernel we will still need my
patch 01/04 ("ARM: versatile: support no-MMU mode addressing").
No surprise here, this was missing in older kernels too.
Regards
Greg
>>
>> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
>> ---
>> arch/arm/Kconfig | 10 ++++++++++
>> arch/arm/Kconfig.debug | 3 ++-
>> arch/arm/include/asm/mach/map.h | 1 +
>> arch/arm/mach-versatile/Kconfig | 3 ++-
>> arch/arm/mach-versatile/Makefile.boot | 3 +++
>> arch/arm/mach-versatile/versatile_dt.c | 4 ++++
>> 6 files changed, 22 insertions(+), 2 deletions(-)
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
>
^ permalink raw reply
* [PATCHv4 09/10] mm/usercopy: Switch to using lm_alias
From: Mark Rutland @ 2016-12-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jKTdZUbbHU91mbN+Qy80AGXRhpzdLNXr3oxxZyxAzmjmQ@mail.gmail.com>
On Tue, Dec 06, 2016 at 12:10:50PM -0800, Kees Cook wrote:
> On Tue, Dec 6, 2016 at 10:18 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Nov 29, 2016 at 11:39:44AM -0800, Kees Cook wrote:
> >> On Tue, Nov 29, 2016 at 10:55 AM, Laura Abbott <labbott@redhat.com> wrote:
> >> >
> >> > The usercopy checking code currently calls __va(__pa(...)) to check for
> >> > aliases on symbols. Switch to using lm_alias instead.
> >> >
> >> > Signed-off-by: Laura Abbott <labbott@redhat.com>
> >>
> >> Acked-by: Kees Cook <keescook@chromium.org>
> >>
> >> I should probably add a corresponding alias test to lkdtm...
> >>
> >> -Kees
> >
> > Something like the below?
> >
> > It uses lm_alias(), so it depends on Laura's patches. We seem to do the
> > right thing, anyhow:
>
> Cool, this looks good. What happens on systems without an alias?
In that case, lm_alias() should be an identity function, and we'll just
hit the usual kernel address (i.e. it should be identical to
USERCOPY_KERNEL).
> Laura, feel free to add this to your series:
>
> Acked-by: Kees Cook <keescook@chromium.org>
I'm happy with that, or I can resend this as a proper patch once the
rest is in.
Thanks,
Mark.
^ permalink raw reply
* [Question] New mmap64 syscall?
From: Florian Weimer @ 2016-12-07 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206185440.GA4654@yury-N73SV>
On 12/06/2016 07:54 PM, Yury Norov wrote:
> 3. Introduce new mmap64() syscall like this:
> sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair *off);
> (The pointer here because otherwise we have 7 args, if simply pass off_hi and
> off_lo in registers.)
I would prefer a batched mmap/munmap/mremap/mprotect/madvise interface,
so that VM changes can be coalesced and the output reduced. This
interface could then be used to implement mmap on 32-bit architectures
as well because the offset restrictions would not apply there.
Thanks,
Florian
^ permalink raw reply
* [PATCH 8/8] efi: Handle secure boot from UEFI-2.6 [ver #5]
From: David Howells @ 2016-12-07 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
UEFI-2.6 adds a new variable, DeployedMode. If it exists, this must be 1
if we're to engage lockdown mode.
Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/firmware/efi/libstub/secureboot.c | 16 +++++++++++++++-
include/linux/efi.h | 4 ++++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/secureboot.c b/drivers/firmware/efi/libstub/secureboot.c
index ba6ef717c66f..333b1594cce4 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -22,6 +22,9 @@ static const efi_char16_t const efi_SecureBoot_name[] = {
static const efi_char16_t const efi_SetupMode_name[] = {
'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
};
+static const efi_char16_t const efi_DeployedMode_name[] = {
+ 'D', 'e', 'p', 'l', 'o', 'y', 'e', 'd', 'M', 'o', 'd', 'e', 0
+};
/* SHIM variables */
static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
@@ -40,7 +43,7 @@ static efi_char16_t const shim_MokSBState_name[] = {
enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
{
u32 attr;
- u8 secboot, setupmode, moksbstate;
+ u8 secboot, setupmode, deployedmode, moksbstate;
unsigned long size;
efi_status_t status;
@@ -59,6 +62,17 @@ enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
if (secboot == 0 || setupmode == 1)
goto secure_boot_disabled;
+ /* UEFI-2.6 requires DeployedMode to be 1. */
+ if (sys_table_arg->hdr.revision >= EFI_2_60_SYSTEM_TABLE_REVISION) {
+ size = sizeof(deployedmode);
+ status = get_efi_var(efi_DeployedMode_name, &efi_variable_guid,
+ NULL, &size, &deployedmode);
+ if (status != EFI_SUCCESS)
+ goto out_efi_err;
+ if (deployedmode == 0)
+ goto secure_boot_disabled;
+ }
+
/* See if a user has put shim into insecure mode. If so, and if the
* variable doesn't have the runtime attribute set, we might as well
* honor that.
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 135ca9c0c0b5..e1893f5002c3 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -645,6 +645,10 @@ typedef struct {
#define EFI_SYSTEM_TABLE_SIGNATURE ((u64)0x5453595320494249ULL)
+#define EFI_2_60_SYSTEM_TABLE_REVISION ((2 << 16) | (60))
+#define EFI_2_50_SYSTEM_TABLE_REVISION ((2 << 16) | (50))
+#define EFI_2_40_SYSTEM_TABLE_REVISION ((2 << 16) | (40))
+#define EFI_2_31_SYSTEM_TABLE_REVISION ((2 << 16) | (31))
#define EFI_2_30_SYSTEM_TABLE_REVISION ((2 << 16) | (30))
#define EFI_2_20_SYSTEM_TABLE_REVISION ((2 << 16) | (20))
#define EFI_2_10_SYSTEM_TABLE_REVISION ((2 << 16) | (10))
^ permalink raw reply related
* [PATCH 7/8] efi: Add EFI_SECURE_BOOT bit [ver #5]
From: David Howells @ 2016-12-07 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
From: Josh Boyer <jwboyer@fedoraproject.org>
UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit
that can be passed to efi_enabled() to find out whether secure boot is
enabled.
This will be used by the SysRq+x handler, registered by the x86 arch, to find
out whether secure boot mode is enabled so that it can be disabled.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---
arch/x86/kernel/setup.c | 15 +++++++++++++++
include/linux/efi.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 9c337b0e8ba7..d8972ec6257d 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1152,6 +1152,21 @@ void __init setup_arch(char **cmdline_p)
/* Allocate bigger log buffer */
setup_log_buf(1);
+ if (IS_ENABLED(CONFIG_EFI)) {
+ switch (boot_params.secure_boot) {
+ case efi_secureboot_mode_disabled:
+ pr_info("Secure boot disabled\n");
+ break;
+ case efi_secureboot_mode_enabled:
+ set_bit(EFI_SECURE_BOOT, &efi.flags);
+ pr_info("Secure boot enabled\n");
+ break;
+ default:
+ pr_info("Secure boot could not be determined\n");
+ break;
+ }
+ }
+
reserve_initrd();
acpi_table_upgrade();
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 92e23f03045e..135ca9c0c0b5 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1066,6 +1066,7 @@ extern int __init efi_setup_pcdp_console(char *);
#define EFI_ARCH_1 7 /* First arch-specific bit */
#define EFI_DBG 8 /* Print additional debug info at runtime */
#define EFI_NX_PE_DATA 9 /* Can runtime data regions be mapped non-executable? */
+#define EFI_SECURE_BOOT 10 /* Are we in Secure Boot mode? */
#ifdef CONFIG_EFI
/*
^ permalink raw reply related
* [PATCH 6/8] efi: Disable secure boot if shim is in insecure mode [ver #5]
From: David Howells @ 2016-12-07 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148111668193.23390.6340512985876251017.stgit@warthog.procyon.org.uk>
From: Josh Boyer <jwboyer@fedoraproject.org>
A user can manually tell the shim boot loader to disable validation of
images it loads. When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set. Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/firmware/efi/libstub/secureboot.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/secureboot.c b/drivers/firmware/efi/libstub/secureboot.c
index 70e2a36577d4..ba6ef717c66f 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -23,6 +23,12 @@ static const efi_char16_t const efi_SetupMode_name[] = {
'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
};
+/* SHIM variables */
+static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
+static efi_char16_t const shim_MokSBState_name[] = {
+ 'M', 'o', 'k', 'S', 'B', 'S', 't', 'a', 't', 'e', 0
+};
+
#define get_efi_var(name, vendor, ...) \
efi_call_runtime(get_variable, \
(efi_char16_t *)(name), (efi_guid_t *)(vendor), \
@@ -33,7 +39,8 @@ static const efi_char16_t const efi_SetupMode_name[] = {
*/
enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
{
- u8 secboot, setupmode;
+ u32 attr;
+ u8 secboot, setupmode, moksbstate;
unsigned long size;
efi_status_t status;
@@ -52,6 +59,21 @@ enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
if (secboot == 0 || setupmode == 1)
goto secure_boot_disabled;
+ /* See if a user has put shim into insecure mode. If so, and if the
+ * variable doesn't have the runtime attribute set, we might as well
+ * honor that.
+ */
+ size = sizeof(moksbstate);
+ status = get_efi_var(shim_MokSBState_name, &shim_guid,
+ &attr, &size, &moksbstate);
+
+ /* If it fails, we don't care why. Default to secure */
+ if (status != EFI_SUCCESS)
+ goto secure_boot_enabled;
+ if (!(attr & EFI_VARIABLE_RUNTIME_ACCESS) && moksbstate == 1)
+ goto secure_boot_disabled;
+
+secure_boot_enabled:
pr_efi(sys_table_arg, "UEFI Secure Boot is enabled.\n");
return efi_secureboot_mode_enabled;
^ permalink raw reply related
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