* [PATCH 11/11] arm: dma-mapping: Add support to extend DMA IOMMU mappings
From: Will Deacon @ 2014-01-29 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E8DE7D.5020801@samsung.com>
Hi Marek,
On Wed, Jan 29, 2014 at 10:57:01AM +0000, Marek Szyprowski wrote:
> On 2014-01-16 13:44, Andreas Herrmann wrote:
> > Instead of using just one bitmap to keep track of IO virtual addresses
> > (handed out for IOMMU use) introduce a list of iova_ranges (each
> > having its own bitmap). This allows us to extend existing mappings
> > when running out of iova space for a mapping.
> >
> > If there is not enough space in the mapping to service an IO virtual
> > address allocation request, __alloc_iova() tries to extend the mapping
> > -- by allocating another bitmap -- and makes another allocation
> > attempt using the freshly allocated bitmap.
> >
> > This allows arm iommu drivers to start with a decent initial size when
> > an dma_iommu_mapping is created and still to avoid running out of IO
> > virtual addresses for the mapping.
> >
> > Tests were done on Calxeda ECX-2000 with smmu for sata and xgmac.
> > I've used SZ_512K both for initial mapping size and grow_size.
>
> Thanks for implementing this feature! I remember it was discussed from
> early beginning of arm dma iommu support, but I never had enough time
> to actually implement it. I briefly checked the code and it look fine,
> however I really wonder if we need separate grow_size parameter?
> Personally I would simplify it to simply grow the bitmap by initial
> size until it reaches the maximal size.
That sounds sensible, but I also think it would be worth taking into account
the page sizes supported by the IOMMU as well, since aligning to those makes
sense from a TLB utilisation perspective.
> The whole concept of the simplified bitmap (where 1 bit != 1 page) for
> iova allocation is a specific feature of this code and it has nothing
> to the hardware. After thinking a bit more on the existing
> implementation I've already observed that it is sometimes hard to
> understand the parameters for arm_iommu_create_mapping() function,
> especially the 'order' argument is ofter misunderstood. With your
> patch we got two additional parameters. Maybe it will be much better
> to use only 2 arguments: max_mapping_size and allocation_accuracy.
> The initial bitmap size can be then calculated to fit it into single
> memory page (that's quite important to avoid allocations larger that
> a single memory page). 'allocation_accuracy' will serve the same way
> as 'order' parameter now (but expressed in bytes rather than being
> the multiplier for the number of pages). This way the
> arm_iommu_create_mapping() function should be much easier to
> understand, while keeping the implementation details hidden from the
> caller.
Hmm, I wouldn't guess the SI unit of accuracy to be bytes ;)
Will
^ permalink raw reply
* [PATCH v3] ARM: hw_breakpoint: Add ARMv8 support
From: Will Deacon @ 2014-01-29 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390935112-28465-1-git-send-email-cov@codeaurora.org>
Hi Christopher,
On Tue, Jan 28, 2014 at 06:51:51PM +0000, Christopher Covington wrote:
> Add the trivial support necessary to get hardware breakpoints
> working for GDB on ARMv8 simulators running in AArch32 mode.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> ---
>
> v3: assume for now that ARMv9 and later will update FSR
Please can you stick this into the patch system? I don't have any other
hw_breakpoint changes queued, so I doubt I'll send a pull for 3.15.
Cheers,
Will
^ permalink raw reply
* [PATCH 11/11] arm: dma-mapping: Add support to extend DMA IOMMU mappings
From: Marek Szyprowski @ 2014-01-29 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389876263-25759-12-git-send-email-andreas.herrmann@calxeda.com>
Hello,
I'm sorry for so late reply, but I was quite busy with other stuff.
On 2014-01-16 13:44, Andreas Herrmann wrote:
> Instead of using just one bitmap to keep track of IO virtual addresses
> (handed out for IOMMU use) introduce a list of iova_ranges (each
> having its own bitmap). This allows us to extend existing mappings
> when running out of iova space for a mapping.
>
> If there is not enough space in the mapping to service an IO virtual
> address allocation request, __alloc_iova() tries to extend the mapping
> -- by allocating another bitmap -- and makes another allocation
> attempt using the freshly allocated bitmap.
>
> This allows arm iommu drivers to start with a decent initial size when
> an dma_iommu_mapping is created and still to avoid running out of IO
> virtual addresses for the mapping.
>
> Tests were done on Calxeda ECX-2000 with smmu for sata and xgmac.
> I've used SZ_512K both for initial mapping size and grow_size.
Thanks for implementing this feature! I remember it was discussed from
early beginning of arm dma iommu support, but I never had enough time
to actually implement it. I briefly checked the code and it look fine,
however I really wonder if we need separate grow_size parameter?
Personally I would simplify it to simply grow the bitmap by initial
size until it reaches the maximal size.
The whole concept of the simplified bitmap (where 1 bit != 1 page) for
iova allocation is a specific feature of this code and it has nothing
to the hardware. After thinking a bit more on the existing
implementation I've already observed that it is sometimes hard to
understand the parameters for arm_iommu_create_mapping() function,
especially the 'order' argument is ofter misunderstood. With your
patch we got two additional parameters. Maybe it will be much better
to use only 2 arguments: max_mapping_size and allocation_accuracy.
The initial bitmap size can be then calculated to fit it into single
memory page (that's quite important to avoid allocations larger that
a single memory page). 'allocation_accuracy' will serve the same way
as 'order' parameter now (but expressed in bytes rather than being
the multiplier for the number of pages). This way the
arm_iommu_create_mapping() function should be much easier to
understand, while keeping the implementation details hidden from the
caller.
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> Cc: Hiroshi Doyu <hdoyu@nvidia.com>
> Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
> Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
> ---
> arch/arm/include/asm/dma-iommu.h | 17 ++++-
> arch/arm/mm/dma-mapping.c | 147 ++++++++++++++++++++++++++++++++------
> 2 files changed, 139 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
> index 50edacd..987d62c 100644
> --- a/arch/arm/include/asm/dma-iommu.h
> +++ b/arch/arm/include/asm/dma-iommu.h
> @@ -8,15 +8,26 @@
> #include <linux/dma-debug.h>
> #include <linux/kmemcheck.h>
> #include <linux/kref.h>
> +#include <linux/list.h>
> +
> +struct dma_iommu_iova_range {
> + struct list_head list_head;
> + unsigned long *bitmap;
> + size_t bits;
> + dma_addr_t base;
> + dma_addr_t size;
> +};
>
> struct dma_iommu_mapping {
> /* iommu specific data */
> struct iommu_domain *domain;
>
> - void *bitmap;
> - size_t bits;
> - unsigned int order;
> + struct list_head iova_ranges;
> dma_addr_t base;
> + dma_addr_t size;
> + dma_addr_t grow_size;
> + dma_addr_t max_size;
> + unsigned int order;
>
> spinlock_t lock;
> struct kref kref;
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index ccea46a..503e8d6 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -26,6 +26,7 @@
> #include <linux/io.h>
> #include <linux/vmalloc.h>
> #include <linux/sizes.h>
> +#include <linux/list.h>
>
> #include <asm/memory.h>
> #include <asm/highmem.h>
> @@ -1069,6 +1070,8 @@ fs_initcall(dma_debug_do_init);
>
> /* IOMMU */
>
> +static int extend_iommu_mapping(struct dma_iommu_mapping *mapping);
> +
> static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
> size_t size)
> {
> @@ -1076,6 +1079,8 @@ static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
> unsigned int align = 0;
> unsigned int count, start;
> unsigned long flags;
> + struct dma_iommu_iova_range *e;
> + bool area_found;
>
> if (order > CONFIG_ARM_DMA_IOMMU_ALIGNMENT)
> order = CONFIG_ARM_DMA_IOMMU_ALIGNMENT;
> @@ -1086,32 +1091,80 @@ static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
> if (order > mapping->order)
> align = (1 << (order - mapping->order)) - 1;
>
> + area_found = false;
> spin_lock_irqsave(&mapping->lock, flags);
> - start = bitmap_find_next_zero_area(mapping->bitmap, mapping->bits, 0,
> - count, align);
> - if (start > mapping->bits) {
> - spin_unlock_irqrestore(&mapping->lock, flags);
> - return DMA_ERROR_CODE;
> + list_for_each_entry(e, &mapping->iova_ranges, list_head) {
> + start = bitmap_find_next_zero_area(e->bitmap, e->bits, 0,
> + count, align);
> + if (start > e->bits)
> + continue;
> +
> + bitmap_set(e->bitmap, start, count);
> + area_found = true;
> + break;
> }
>
> - bitmap_set(mapping->bitmap, start, count);
> + /*
> + * Try to extend the existing mapping and perform a second
> + * attempt to reserve an IO virtual address range of size
> + * bytes.
> + */
> + if (!area_found) {
> + if (extend_iommu_mapping(mapping)) {
> + spin_unlock_irqrestore(&mapping->lock, flags);
> + return DMA_ERROR_CODE;
> + }
> + e = list_entry(mapping->iova_ranges.prev,
> + struct dma_iommu_iova_range, list_head);
> + start = bitmap_find_next_zero_area(e->bitmap, e->bits, 0,
> + count, align);
> + if (start > e->bits) {
> + spin_unlock_irqrestore(&mapping->lock, flags);
> + return DMA_ERROR_CODE;
> + }
> + bitmap_set(e->bitmap, start, count);
> + }
> spin_unlock_irqrestore(&mapping->lock, flags);
>
> - return mapping->base + (start << (mapping->order + PAGE_SHIFT));
> + return e->base + (start << (mapping->order + PAGE_SHIFT));
> }
>
> static inline void __free_iova(struct dma_iommu_mapping *mapping,
> dma_addr_t addr, size_t size)
> {
> - unsigned int start = (addr - mapping->base) >>
> - (mapping->order + PAGE_SHIFT);
> - unsigned int count = ((size >> PAGE_SHIFT) +
> - (1 << mapping->order) - 1) >> mapping->order;
> + struct dma_iommu_iova_range *e;
> + unsigned int start, count, tmp;
> unsigned long flags;
>
> - spin_lock_irqsave(&mapping->lock, flags);
> - bitmap_clear(mapping->bitmap, start, count);
> - spin_unlock_irqrestore(&mapping->lock, flags);
> + list_for_each_entry(e, &mapping->iova_ranges, list_head) {
> + if (!size)
> + break;
> + if ((addr < e->base) || (addr >= e->base + e->size))
> + continue;
> +
> + start = (addr - e->base) >> (mapping->order + PAGE_SHIFT);
> + if (addr + size > e->base + e->size) {
> + /*
> + * The address range to be freed crosses an
> + * iova_range boundary.
> + * Hence calc count parameter to fit within
> + * current iova_range and prepare addr and
> + * size for next iteration.
> + */
> + tmp = (e->base + e->size) - addr;
> + count = ((tmp >> PAGE_SHIFT) +
> + (1 << mapping->order) - 1) >> mapping->order;
> + size -= tmp;
> + addr += tmp;
> + } else {
> + count = ((size >> PAGE_SHIFT) +
> + (1 << mapping->order) - 1) >> mapping->order;
> + size -= size;
> + }
> + spin_lock_irqsave(&mapping->lock, flags);
> + bitmap_clear(e->bitmap, start, count);
> + spin_unlock_irqrestore(&mapping->lock, flags);
> + }
> }
>
> static struct page **__iommu_alloc_buffer(struct device *dev, size_t size,
> @@ -1892,6 +1945,7 @@ arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
> unsigned int count = size >> (PAGE_SHIFT + order);
> unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
> struct dma_iommu_mapping *mapping;
> + struct dma_iommu_iova_range *iovar;
> int err = -ENOMEM;
>
> if (!count)
> @@ -1901,23 +1955,37 @@ arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
> if (!mapping)
> goto err;
>
> - mapping->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
> - if (!mapping->bitmap)
> + INIT_LIST_HEAD(&mapping->iova_ranges);
> + spin_lock_init(&mapping->lock);
> +
> + iovar = kzalloc(sizeof(struct dma_iommu_iova_range), GFP_KERNEL);
> + if (!iovar)
> goto err2;
>
> - mapping->base = base;
> - mapping->bits = BITS_PER_BYTE * bitmap_size;
> + iovar->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
> + if (!iovar->bitmap)
> + goto err3;
> +
> + iovar->bits = BITS_PER_BYTE * bitmap_size;
> + list_add_tail(&iovar->list_head, &mapping->iova_ranges);
> +
> + mapping->base = iovar->base = base;
> + mapping->size = iovar->size = size;
> +
> mapping->order = order;
> - spin_lock_init(&mapping->lock);
> + mapping->grow_size = grow_size;
> + mapping->max_size = max_size;
>
> mapping->domain = iommu_domain_alloc(bus);
> if (!mapping->domain)
> - goto err3;
> + goto err4;
>
> kref_init(&mapping->kref);
> return mapping;
> +err4:
> + kfree(iovar->bitmap);
> err3:
> - kfree(mapping->bitmap);
> + kfree(iovar);
> err2:
> kfree(mapping);
> err:
> @@ -1927,14 +1995,49 @@ EXPORT_SYMBOL_GPL(arm_iommu_create_mapping);
>
> static void release_iommu_mapping(struct kref *kref)
> {
> + struct dma_iommu_iova_range *e, *tmp;
> struct dma_iommu_mapping *mapping =
> container_of(kref, struct dma_iommu_mapping, kref);
>
> iommu_domain_free(mapping->domain);
> - kfree(mapping->bitmap);
> + list_for_each_entry_safe(e, tmp, &mapping->iova_ranges, list_head) {
> + list_del(&e->list_head);
> + kfree(e->bitmap);
> + kfree(e);
> + }
> kfree(mapping);
> }
>
> +static int extend_iommu_mapping(struct dma_iommu_mapping *mapping)
> +{
> + struct dma_iommu_iova_range *iovar;
> + unsigned int count = mapping->grow_size >> (PAGE_SHIFT + mapping->order);
> + unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
> +
> + if (!mapping->grow_size ||
> + (mapping->size + mapping->grow_size) >= mapping->max_size)
> + return -EINVAL;
> +
> + iovar = kzalloc(sizeof(struct dma_iommu_iova_range), GFP_ATOMIC);
> + if (!iovar)
> + return -ENOMEM;
> +
> + iovar->bitmap = kzalloc(bitmap_size, GFP_ATOMIC);
> + if (!iovar->bitmap) {
> + kfree(iovar);
> + return -ENOMEM;
> + }
> +
> + iovar->bits = BITS_PER_BYTE * bitmap_size;
> + iovar->base = mapping->base + mapping->size;
> + iovar->size = mapping->grow_size;
> +
> + mapping->size += mapping->grow_size;
> + list_add_tail(&iovar->list_head, &mapping->iova_ranges);
> +
> + return 0;
> +}
> +
> void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping)
> {
> if (mapping)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v9 1/6] arm64: Add macros to manage processor debug state
From: Will Deacon @ 2014-01-29 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390908022-10287-2-git-send-email-vijay.kilari@gmail.com>
On Tue, Jan 28, 2014 at 11:20:17AM +0000, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>
> Add macros to enable and disable to manage PSTATE.D
> for debugging. The macros local_dbg_save and local_dbg_restore
> are moved to irqflags.h file
>
> KGDB boot tests fail because of PSTATE.D is masked.
> unmask it for debugging support
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cheers,
Will
^ permalink raw reply
* [PATCH 2/9] ARM: dts: imx6sl: remove the use of pingrp macros
From: Heiko Stübner @ 2014-01-29 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128112047.GC20583@S2101-09.ap.freescale.net>
On Tuesday, 28. January 2014 19:20:49 Shawn Guo wrote:
> On Tue, Jan 28, 2014 at 11:17:22AM +0100, Heiko St?bner wrote:
> > [... and so on for the other groups ... ]
> >
> > I'm confused now :-) . Current linux-next [0] shows the pin-settings as
> > part of imx6sl.dtsi - a way a lot of other architectures organize their
> > pingroups too, with the board file only referencing the relevant
> > pingroups from the predefined ones of the soc.
> >
> > So I guess your move to the pingrp-header moved them out of the
> > imx6sl.dtsi to the .h and is not part of linux-next;
>
> Yes, my for-next branch was excluded from linux-next temporarily for
> some reason. I will ask Stephen to add it back once v3.14-rc1 is out.
> That said, you can see nothing we developed in this cycle on linux-next
> for now.
>
> > but this patch (and the others in this
> > series) now moves the definitions into the individual board files. Can't
> > you just move them back to the soc-dtsi files to prevent each board
> > duplicating them?
>
> No. That will bring back the problem we try to solve from the
> beginning [1].
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/275912/
Thanks for the pointer, I think I understand the issue now :-) .
So for the short term, I should probably also define the pingroups in my board-
dts then.
But as an insane idea that I just had, because the issue will probably affect
more architectures at some point when their pingroups or other common-nodes
grow, how about introducing something like a "/delete-if-unreferenced/" prefix
in dtc?
As I could see in [0], adding something to dtc is not as far off as I thought.
In essence one would add the pingroups to the soc dtsi, like
ecspi1 {
/delete-if-unreferenced/ pinctrl_ecspi1_1: ecspi1grp-1 {
fsl,pins = <
MX6SL_PAD_ECSPI1_MISO__ECSPI1_MISO 0x100b1
MX6SL_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x100b1
MX6SL_PAD_ECSPI1_SCLK__ECSPI1_SCLK 0x100b1
>;
};
};
and dtc would then be tasked with checking if the node gets referenced in a
phandle somewhere in the dts and if not removing it.
I don't know if this is at all sane to think about or doable in dtc.
Heiko
[0] http://www.spinics.net/lists/arm-kernel/msg300936.html
^ permalink raw reply
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Marc Zyngier @ 2014-01-29 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390944264-3435-1-git-send-email-christoffer.dall@linaro.org>
On 28/01/14 21:24, Christoffer Dall wrote:
> The stage-2 memory attributes are distinct from the Hyp memory
> attributes and the Stage-1 memory attributes. We were using the stage-1
> memory attributes for stage-2 mappings causing device mappings to be
> mapped as normal memory. Add the S2 equivalent defines for memory
> attributes and fix the comments explaining the defines while at it.
>
> Add a prot_pte_s2 field to the mem_type struct and fill out the field
> for device mappings accordingly.
>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH 1/9] mtd: nand: retrieve ECC requirements from Hynix READ ID byte 4
From: boris brezillon @ 2014-01-29 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123014906.GY8919@ld-irv-0074>
Hello Brian,
On 23/01/2014 02:49, Brian Norris wrote:
> + Huang
>
> Hi Boris,
>
> On Wed, Jan 08, 2014 at 03:21:56PM +0100, Boris BREZILLON wrote:
>> The Hynix nand flashes store their ECC requirements in byte 4 of its id
>> (returned on READ ID command).
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> I haven't verified yet (perhaps Huang can confirm?), but this may be
> similar to a patch Huang submitted recently. In his case, we found that
> this table is actually quite unreliable and is likely hard to maintain.
You mean these bytes are not reliable within the whole Hynix LP (Large Page)
NAND product line ?
>
> Why do you need this ECC information, for my reference?
Because the NAND flash available on the cubietruck board does not
support the
ONFI standard, and I thought this could be a option to retrieve the ECC
strength
requirements.
Anyway, I added a new helper function to retrieve ecc informations from
device
tree (I'll post it in the 2nd version of this series). We'll see if this
approach is
accepted...
>
> Brian
^ permalink raw reply
* [PATCH RESEND 1/4] clk: clk-s2mps11: Refactor for including support for other MFD clocks
From: Krzysztof Kozlowski @ 2014-01-29 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <mvd17-4vW-3@gated-at.bofh.it>
Hi,
>
> Quoting Mark Brown (2013-12-31 08:09:16)
> > On Mon, Dec 30, 2013 at 09:33:50AM +0530, Tushar Behera wrote:
> >
> > > Commit 1b1ccee1e821 "mfd: s2mps11: Fix build after regmap field rename
> > > in sec-core.c" is also touching this file, which is in Mark's tree
> > > right now. If I rebase
> >
> > It's been in Linus' tree for a while now.
>
> OK, so I merged the two patches into clk-next, then merged clk-next into
> next-20131224 and the merge is super trivial to resolve. So I propose
> that we just let it get resolved in linux-next the usual way.
>
> Any objections? If not I'll take these two patches into clk-next.
Did you merged these patches into clk-next? Unfortunately I couldn't
find them (clk-next, next).
I am asking because I want to send patches with support for S2MPS14
clock (based on these patches).
Best regards,
Krzysztof
^ permalink raw reply
* [RFC PATCH 0/9] mtd: nand: add sunxi NAND Flash Controller support
From: boris brezillon @ 2014-01-29 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJNd_gtn-cCLbZxT=s5NkkXp0DZkJkZrBhWiaL6Js=woQ@mail.gmail.com>
Hello Rob,
On 23/01/2014 16:22, Rob Herring wrote:
> On Sat, Jan 11, 2014 at 7:38 AM, boris brezillon
> <b.brezillon@overkiz.com> wrote:
>> On 08/01/2014 15:21, Boris BREZILLON wrote:
>>> Hello,
>>>
>>> This series add the sunxi NFC support with up to 8 NAND chip connected.
>>> I'm still in the early stages drivers development and some key features
>>> are
>>> missing, but it's usable (I tested it on the cubietruck board).
>>>
>>> Here's what's missing:
>>> - HW ECC support
>>> - DMA support
>>> - HW randomization support
>>> - many more improvements
>>>
>>> This series depends on Emilio's patch series implementing mod0 clks
>>>
>>> (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185478.html)
>>> + an other patch not yet posted
>>>
>>> (http://git.elopez.com.ar/linux/commits/5b4eb3ac406b9c98965714d40e8dd6da943d1ab0)
>>
>> During my reasearch regarding the HW ECC and HW randomizer of the Allwinner
>> NAND flash controller I found this document describing the Altera NAND flash
>> controller
>> (which is in turn based on a cadence IP):
> Which may be similar to drivers/mtd/nand/denali.c as Cadence bought Denali?
Actually I was wrong, the sunxi and the cadence IP have nothing in common.
This was pointed out by Henrik (see this thread :
https://groups.google.com/forum/#!searchin/linux-sunxi/nand/linux-sunxi/x69tFBi95Zk/bNyJlWWOV8oJ
<https://groups.google.com/forum/#%21searchin/linux-sunxi/nand/linux-sunxi/x69tFBi95Zk/bNyJlWWOV8oJ>).
Sorry for the false hopes.
Best Regards,
Boris
>
> Rob
^ permalink raw reply
* [PATCH 05/18] mfd: max14577: Use of_match_ptr() in i2c_driver
From: Krzysztof Kozlowski @ 2014-01-29 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390911522-28209-6-git-send-email-k.kozlowski@samsung.com>
I would like to drop this patch.
It does not make sense as "max14577_dt_match" is always compiled and
of_match_ptr was removed on purpose by Sachin Kamat (ae679c12e8; mfd:
max14577: Remove redundant of_match_ptr helper).
Best regards,
Krzysztof Kozlowski
On Tue, 2014-01-28 at 13:18 +0100, Krzysztof Kozlowski wrote:
> Use of_match_ptr() in assignment of i2c_driver.of_match_table.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/mfd/max14577.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
> index 2ac2f2d7cea6..75b37082a3fe 100644
> --- a/drivers/mfd/max14577.c
> +++ b/drivers/mfd/max14577.c
> @@ -224,7 +224,7 @@ static struct i2c_driver max14577_i2c_driver = {
> .name = "max14577",
> .owner = THIS_MODULE,
> .pm = &max14577_pm,
> - .of_match_table = max14577_dt_match,
> + .of_match_table = of_match_ptr(max14577_dt_match),
> },
> .probe = max14577_i2c_probe,
> .remove = max14577_i2c_remove,
^ permalink raw reply
* emmc on imx6 sabresd
From: Philippe De Muyter @ 2014-01-29 10:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shawn,
I try to use the emmc on my sabresd board and on a similar custom board
using 3.13, and I have just discovered by reading Internet that it was
not supported up to some weeks ago. Is there a git tree somewhere that
has a branch containing 3.13 or linux-next and all the fixes for emmc on
sabresd ?
TIA
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
^ permalink raw reply
* imx6dl/imx6q fec rmii mode with external ref_clk
From: Philippe De Muyter @ 2014-01-29 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115073536.GD1914@S2101-09.ap.freescale.net>
Hi Shawn,
On Wed, Jan 15, 2014 at 03:35:40PM +0800, Shawn Guo wrote:
> On Tue, Jan 14, 2014 at 04:30:12PM +0100, Philippe De Muyter wrote:
> > Hi,
> >
> > On the custom board we are developping (imx6q and imx6dl), we have connected
> > the fec to a switch chip using rmii mode, and we let the switch provide the
> > reference clock to gpio_16.
> >
> > I work currently with 3.13-rc8 and
> >
> > - I do not have ethernet access working (tx timeout)
> > - I do not find in the dtb files a description of the pad settings for the
> > RMII mode
> > - when searching about the setting for bit 21 ing GPR1, which seems to
> > be important for my setting to work, I found the following mail:
> > http://www.spinics.net/lists/devicetree/msg06450.html
>
> Just for testing your hardware, does the following change make the
> Ethernet work for you?
>
> Shawn
>
> diff --git a/arch/arm/mach-imx/mach-imx6q.c
> b/arch/arm/mach-imx/mach-imx6q.c
> index e51e3da..be8d074 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -188,7 +188,7 @@ static void __init imx6q_1588_init(void)
> if (!IS_ERR(gpr))
> regmap_update_bits(gpr, IOMUXC_GPR1,
> IMX6Q_GPR1_ENET_CLK_SEL_MASK,
> - IMX6Q_GPR1_ENET_CLK_SEL_ANATOP);
> + 0);
> else
> pr_err("failed to find fsl,imx6q-iomux-gpr regmap\n");
>
Yes, it works now. Thanks. Is that configurable from the device tree ?
Philippe
^ permalink raw reply
* [PATCH v5 00/23]
From: Jean-Francois Moine @ 2014-01-29 9:01 UTC (permalink / raw)
To: linux-arm-kernel
This patch set contains various extensions to the tda998x driver:
- simplify the i2c read/write
- code cleanup and fix some small errors
- use global constants
- don't read write-only registers
- add DT support
- use IRQ for connection status and EDID read
- v5
- remarks from Russell King
- free the IRQ on encoder destroy (patch 14)
- fix bad comment (patch 23)
- removal of 'set the video mode from the adjusted value'
which was breaking tilcdc (Darren Etheridge)
- use the IRQ trigger type from platform/DT (patch 14)
- v4
- remarks from Russell King (thank you, Russell)
- more comments about the patches
- remove 'fix a NULL pointer dereference'
- get the IRQ number from the i2c client
- remove 'get a better status of the connection'
- split the previous 'fix the ENABLE_SPACE register'
- add asounddef.h variables in 'change the frequence in the audio channel'
- add 'always enable EDID read IRQ'
- remove audio changes which will be in a next patch set about
information exchanges with the audio subsystem
- v3
- remarks from Russell King
- more comments about the patches
- change variable name instead of copy (patch 7)
- add 'fix bad value in the AIF' (patch 8)
- add 'fix a NULL pointer dereference' (patch 13)
- add 'add DT documentation' (patch 16)
- remove 'use the tda998x video format when cea mode'
- remove 'change the video quantization
- remove 'fix the value of the TBG_CNTRL_1 register'
- remove 'tda998x: move the TBG_CNTRL_0 register setting'
- change fields of the register AIP_CLKSEL (patch 19)
- remove 'adjust the audio CTS to the mode clock'
- don't put a comment between field definition (patch 23)
- some more remarks may be found in the patches 10, 14, 15
- removal of the tda codec interface which will be the subject
of an other patch series
- v2
- decompose patches with different topics
- fix some bad i2c register values
- add audio codec interface
Jean-Francois Moine (23):
drm/i2c: tda998x: simplify the i2c read/write functions
drm/i2c: tda998x: check more I/O errors
drm/i2c: tda998x: code cleanup
drm/i2c: tda998x: change probe message origin
drm/i2c: tda998x: don't freeze the system at audio startup time
drm/i2c: tda998x: force the page register at startup time
drm/i2c: tda998x: fix bad value in the AIF
drm/i2c: tda998x: use HDMI constants
drm/i2c: tda998x: don't read write-only registers
drm/i2c: tda998x: free the CEC device on encoder_destroy
drm/i2c: tda998x: check the CEC device creation
drm/i2c: tda998x: add DT support
drm/i2c: tda998x: always enable EDID read IRQ
drm/i2c: tda998x: use irq for connection status and EDID read
drm/i2c: tda998x: add DT documentation
drm/i2c: tda998x: fix the ENABLE_SPACE register
drm/i2c: tda998x: set the PLL division factor in range 0..3
drm/i2c: tda998x: make the audio code more readable
drm/i2c: tda998x: remove the unused variable ca_i2s
drm/i2c: tda998x: add the active aspect in HDMI AVI frame
drm/i2c: tda998x: change the frequence in the audio channel
drm/i2c: tda998x: code optimization
drm/i2c: tda998x: adjust the audio clock divider for S/PDIF
.../devicetree/bindings/drm/i2c/tda998x.txt | 27 +
drivers/gpu/drm/i2c/tda998x_drv.c | 609 +++++++++++++--------
2 files changed, 416 insertions(+), 220 deletions(-)
create mode 100644 Documentation/devicetree/bindings/drm/i2c/tda998x.txt
--
1.9.rc1
^ permalink raw reply
* [PATCH v3 0/2] Qualcomm Universal Peripheral (QUP) I2C controller
From: Ivan T. Ivanov @ 2014-01-29 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389999819-10648-1-git-send-email-bjorn.andersson@sonymobile.com>
Hi Bjorn,
On Fri, 2014-01-17 at 15:03 -0800, Bjorn Andersson wrote:
> Continuing on Ivans i2c-qup series.
>
Do you plan to send v4 of this driver? I would like to address
the remaining errors and suggestions and send a new version.
Regards,
Ivan
^ permalink raw reply
* [PATCH] clk: export __clk_get_hw for re-use in others
From: SeongJae Park @ 2014-01-29 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1401282328360.10321@chino.kir.corp.google.com>
Hi,
On Wed, Jan 29, 2014 at 4:29 PM, David Rientjes <rientjes@google.com> wrote:
> On Wed, 22 Jan 2014, SeongJae Park wrote:
>
>> Oops, I've forgot about the merge window. Thank you very much for your
>> kind answer.
>> Sorry if I bothered you while you're in busy time.
>> Because the build problem is not a big deal because it exists only in
>> -next tree,
>
> This problem exists in Linus's tree, not only in -next.
Yes, it looks like the problem caused commit is in Linus's tree
now(Maybe between this merge window).
But, because similar and better patch was
submitted(https://patchwork.kernel.org/patch/3507921/)
before mine by Stephen and Mike said he will merge the patch during rc1 or rc2,
looks like there is nothing we can rather than just waiting rc1 or rc2.
If there is anything I am thinking or doing wrong, please let me know.
Thanks and Regards,
SeongJae Park
^ permalink raw reply
* [PATCH] clk: nomadik: fix multiplatform problem
From: Linus Walleij @ 2014-01-29 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390291581-5858-1-git-send-email-linus.walleij@linaro.org>
On Tue, Jan 21, 2014 at 9:06 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> The Nomadik debugfs screws up multiplatform boots if debugfs
> is enabled on the multiplatform image, since it's a simple
> initcall that is unconditionally executed and reads from certain
> memory locations.
>
> Fix this by checking that the driver has been properly
> initialized, so a base offset to the Nomadik SRC controller
> exists, before proceeding to register debugfs files.
>
> Reported-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Ping Mike, pls pick this for fixes!
Yours,
Linus Walleij
^ permalink raw reply
* [BUG] reproducable ubifs reboot assert and corruption
From: Richard Weinberger @ 2014-01-29 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129053238.GA6035@gmail.com>
Am 29.01.2014 06:32, schrieb Andrew Ruder:
> Ok, I've got some more useful information. I have been adding
> a multitude of WARN_ON's and prink's all over the remount code and have
> come up with the attached log.
>
> A little bit of explanation:
>
> Line 1: sync_filesystem (from do_remount_sb)
> Line 188: sync_filesystem ends
> Line 43, 64, 81, 98, 114, 135, 156, 173: write operations that occur
> during sync_filesystem. Before each warning I print the inode pointer.
> Line 197: read-only remount has completely finished (this message is
> from userspace post remount)
> Line 199: a sync is called, there are apparently dirty inodes in our
> now-readonly ubifs filesystem
> Line 215: failed assert that occurs because the writeback triggers for
> inode 0xd75b9450 (see line 41, it got in with a sys_write while we were
> running our sync_filesystem in do_remount_sb)
>
> Does this help? It looks like there is a race condition between the
> writeback code and the remount read-only. Nothing is done to lock out
> writes during the first half of the do_remount_sb and some stuff makes
> it into the writeback worker queue while we are busy syncing the
> filesystem only to trigger later when ubifs has decided it is
> read-only...
>
> Note: I only barely know what I am talking about - filesystems still not
> my forte :)
BTW: Can you please share your .config?
Thanks,
//richard
^ permalink raw reply
* [PATCH] clk: export __clk_get_hw for re-use in others
From: David Rientjes @ 2014-01-29 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEjAshrxXLJ-zFsTO9TnewYBBEPzFR1cixbLnD6U-U1EKdByxg@mail.gmail.com>
On Wed, 22 Jan 2014, SeongJae Park wrote:
> Oops, I've forgot about the merge window. Thank you very much for your
> kind answer.
> Sorry if I bothered you while you're in busy time.
> Because the build problem is not a big deal because it exists only in
> -next tree,
This problem exists in Linus's tree, not only in -next.
^ permalink raw reply
* [BUG] reproducable ubifs reboot assert and corruption
From: Richard Weinberger @ 2014-01-29 7:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129053238.GA6035@gmail.com>
Am 29.01.2014 06:32, schrieb Andrew Ruder:
> Ok, I've got some more useful information. I have been adding
> a multitude of WARN_ON's and prink's all over the remount code and have
> come up with the attached log.
>
> A little bit of explanation:
>
> Line 1: sync_filesystem (from do_remount_sb)
> Line 188: sync_filesystem ends
> Line 43, 64, 81, 98, 114, 135, 156, 173: write operations that occur
> during sync_filesystem. Before each warning I print the inode pointer.
> Line 197: read-only remount has completely finished (this message is
> from userspace post remount)
> Line 199: a sync is called, there are apparently dirty inodes in our
> now-readonly ubifs filesystem
> Line 215: failed assert that occurs because the writeback triggers for
> inode 0xd75b9450 (see line 41, it got in with a sys_write while we were
> running our sync_filesystem in do_remount_sb)
>
> Does this help? It looks like there is a race condition between the
> writeback code and the remount read-only. Nothing is done to lock out
> writes during the first half of the do_remount_sb and some stuff makes
> it into the writeback worker queue while we are busy syncing the
> filesystem only to trigger later when ubifs has decided it is
> read-only...
So you can trigger this by running fsstress on /mnt and then call
mount -o remount,ro /mnt?
Can you also trigger it on nandsim or mtdram?
I did a quick test on my testbed using mtdram and was unable to trigger it.
But I fear my box is too fast.
Thanks,
//richard
^ permalink raw reply
* [PATCH V7 1/2] PHY: Exynos: Add Exynos5250 SATA PHY driver
From: Kishon Vijay Abraham I @ 2014-01-29 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390832366-23454-2-git-send-email-yuvaraj.cd@samsung.com>
Hi,
On Monday 27 January 2014 07:49 PM, Yuvaraj Kumar C D wrote:
> This patch adds the SATA PHY driver for Exynos5250.Exynos5250 SATA
> PHY comprises of CMU and TRSV blocks which are of I2C register Map.
> So this patch also adds a i2c client driver, which is used configure
> the CMU and TRSV block of exynos5250 SATA PHY.
>
> This patch incorporates the generic PHY framework to deal with SATA
> PHY.
>
> This patch depends on the below patches
> [1].drivers: phy: add generic PHY framework
> by Kishon Vijay Abraham I<kishon@ti.com>
It no longer should be mentioned here as it is already in mainline. Moreover
these information shouldn't be in commit log. Just move it below '---'.
> [2].ata: ahci_platform: Manage SATA PHY
> by Roger Quadros <rogerq@ti.com>
>
> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
> Signed-off-by: Girish K S <ks.giri@samsung.com>
> Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
> ---
> Changes from V6:
> 1.Removed phy-exynos5250-sata-i2c.c,as it is not required
> after moving to of_find_i2c_device_by_node().
> 2.Changed struct __iomem *pmureg tp struct regmap *pmureg.
> 3.Changed the wait_for_reg_status() to return 0 or -EFAULT.
>
> Changes from V5:
> 1.Rebased on latest generic PHY framework for-next tree.
> 2.Minor nits such as indentations.
>
> Changes from V4:
> 1.Made Exynos5250 SATA PHY driver by default selects
> CONFIG_I2C and CONFIG_I2C_S3C2410, as SATA PHY driver
> depends on I2C.
> 2.struct i2c_driver sataphy_i2c_driver made static which
> was earlier global type.
> 3.Renamed the files to phy-exynos5250-sata.c and
> phy-exynos5250-sata-i2c.c and CONFIG_EXYNOS5250_SATA_PHY
> to CONFIG_PHY_EXYNOS5250_SATA.
>
> Changes from V3:
> 1.Moved devm_phy_create before to devm_phy_provider_register.
>
> Changes from V2:
> 1.Removed of_match_table
> 2.Moved to syscon interface for PMU handling.
>
> Changes from V1:
> 1.Adapted to latest version of Generic PHY framework
> 2.Removed exynos_sata_i2c_remove function.
>
> drivers/phy/Kconfig | 13 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-exynos5250-sata.c | 244 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 258 insertions(+)
> create mode 100644 drivers/phy/phy-exynos5250-sata.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index d0611b8..df79150 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -57,4 +57,17 @@ config PHY_EXYNOS_DP_VIDEO
> help
> Support for Display Port PHY found on Samsung EXYNOS SoCs.
>
> +config PHY_EXYNOS5250_SATA
> + tristate "Exynos5250 Sata SerDes/PHY driver"
> + depends on SOC_EXYNOS5250
> + select GENERIC_PHY
> + select I2C
> + select I2C_S3C2410
depends on HAS_IOMEM and depends on OF.
> + select MFD_SYSCON
> + help
> + Enable this to support SATA SerDes/Phy found on Samsung's
> + Exynos5250 based SoCs.This SerDes/Phy supports SATA 1.5 Gb/s,
> + SATA 3.0 Gb/s, SATA 6.0 Gb/s speeds. It supports one SATA host
> + port to accept one SATA device.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 4e4adc9..5d93dc9 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
> +obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o
> diff --git a/drivers/phy/phy-exynos5250-sata.c b/drivers/phy/phy-exynos5250-sata.c
> new file mode 100644
> index 0000000..b35168d
> --- /dev/null
> +++ b/drivers/phy/phy-exynos5250-sata.c
> @@ -0,0 +1,244 @@
> +/*
> + * Samsung SATA SerDes(PHY) driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Authors: Girish K S <ks.giri@samsung.com>
> + * Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/i2c.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/spinlock.h>
> +#include <linux/mfd/syscon.h>
> +
> +#define EXYNOS5_SATA_RESET 0x4
> +#define RESET_CMN_RST_N (1 << 1)
use BIT macro here and below.
> +#define LINK_RESET 0xf0000
> +#define EXYNOS5_SATA_MODE0 0x10
> +#define EXYNOS5_SATAPHY_PMU_ENABLE (1 << 0)
> +#define SATA_SPD_GEN3 (2 << 0)
> +#define EXYNOS5_SATA_CTRL0 0x14
> +#define CTRL0_P0_PHY_CALIBRATED_SEL (1 << 9)
> +#define CTRL0_P0_PHY_CALIBRATED (1 << 8)
> +#define EXYNOS5_SATA_PHSATA_CTRLM 0xe0
> +#define PHCTRLM_REF_RATE (1 << 1)
> +#define PHCTRLM_HIGH_SPEED (1 << 0)
> +#define EXYNOS5_SATA_PHSATA_STATM 0xf0
> +#define PHSTATM_PLL_LOCKED (1 << 0)
> +#define EXYNOS_SATA_PHY_EN (1 << 0)
> +#define SATAPHY_CONTROL_OFFSET 0x0724
> +
> +#define PHY_PLL_TIMEOUT (usecs_to_jiffies(1000))
> +
> +struct exynos_sata_phy {
> + struct phy *phy;
> + struct clk *phyclk;
> + void __iomem *regs;
> + struct regmap *pmureg;
> + struct i2c_client *client;
> +};
> +
> +static int wait_for_reg_status(void __iomem *base, u32 reg, u32 checkbit,
> + u32 status)
> +{
> + unsigned long timeout = jiffies + PHY_PLL_TIMEOUT;
> +
> + while (time_before(jiffies, timeout)) {
> + if ((readl(base + reg) & checkbit) == status)
> + return 0;
> + }
> +
> + return -EFAULT;
> +}
> +
> +static int exynos_sata_phy_power_on(struct phy *phy)
> +{
> + struct exynos_sata_phy *sata_phy = phy_get_drvdata(phy);
> +
> + return regmap_update_bits(sata_phy->pmureg, SATAPHY_CONTROL_OFFSET,
> + EXYNOS5_SATAPHY_PMU_ENABLE, EXYNOS_SATA_PHY_EN);
> +
> +}
> +
> +static int exynos_sata_phy_power_off(struct phy *phy)
> +{
> + struct exynos_sata_phy *sata_phy = phy_get_drvdata(phy);
> +
> + return regmap_update_bits(sata_phy->pmureg, SATAPHY_CONTROL_OFFSET,
> + EXYNOS5_SATAPHY_PMU_ENABLE, ~EXYNOS_SATA_PHY_EN);
> +
> +}
> +
> +static int exynos_sata_phy_init(struct phy *phy)
> +{
> + u32 val = 0;
> + int ret = 0;
> + u8 buf[] = { 0x3a, 0x0b };
> + struct exynos_sata_phy *sata_phy = phy_get_drvdata(phy);
> +
> + ret = regmap_update_bits(sata_phy->pmureg, SATAPHY_CONTROL_OFFSET,
> + EXYNOS5_SATAPHY_PMU_ENABLE, EXYNOS_SATA_PHY_EN);
> + if (ret != 0)
> + dev_err(&sata_phy->phy->dev, "phy init failed\n");
> +
> + writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
> +
> + val = readl(sata_phy->regs + EXYNOS5_SATA_RESET);
> + val |= 0xff;
What does writing 0xff do? No macro for it?
> + writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
> +
> + val = readl(sata_phy->regs + EXYNOS5_SATA_RESET);
> + val |= LINK_RESET;
> + writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
> +
> + val = readl(sata_phy->regs + EXYNOS5_SATA_RESET);
> + val |= RESET_CMN_RST_N;
> + writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
> +
> + val = readl(sata_phy->regs + EXYNOS5_SATA_PHSATA_CTRLM);
> + val &= ~PHCTRLM_REF_RATE;
> + writel(val, sata_phy->regs + EXYNOS5_SATA_PHSATA_CTRLM);
> +
> + /* High speed enable for Gen3 */
> + val = readl(sata_phy->regs + EXYNOS5_SATA_PHSATA_CTRLM);
> + val |= PHCTRLM_HIGH_SPEED;
> + writel(val, sata_phy->regs + EXYNOS5_SATA_PHSATA_CTRLM);
> +
> + val = readl(sata_phy->regs + EXYNOS5_SATA_CTRL0);
> + val |= CTRL0_P0_PHY_CALIBRATED_SEL | CTRL0_P0_PHY_CALIBRATED;
> + writel(val, sata_phy->regs + EXYNOS5_SATA_CTRL0);
> +
> + val = readl(sata_phy->regs + EXYNOS5_SATA_MODE0);
> + val |= SATA_SPD_GEN3;
> + writel(val, sata_phy->regs + EXYNOS5_SATA_MODE0);
> +
> + ret = i2c_master_send(sata_phy->client, buf, sizeof(buf));
> + if (ret < 0)
> + return ret;
> +
> + /* release cmu reset */
> + val = readl(sata_phy->regs + EXYNOS5_SATA_RESET);
> + val &= ~RESET_CMN_RST_N;
> + writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
> +
> + val = readl(sata_phy->regs + EXYNOS5_SATA_RESET);
> + val |= RESET_CMN_RST_N;
> + writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
> +
> + ret = wait_for_reg_status(sata_phy->regs,
> + EXYNOS5_SATA_PHSATA_STATM,
> + PHSTATM_PLL_LOCKED, 1);
> + if (ret < 0)
> + dev_err(&sata_phy->phy->dev,
> + "PHY PLL locking failed\n");
> + return ret;
> +}
> +
> +static struct phy_ops exynos_sata_phy_ops = {
> + .init = exynos_sata_phy_init,
> + .power_on = exynos_sata_phy_power_on,
> + .power_off = exynos_sata_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int exynos_sata_phy_probe(struct platform_device *pdev)
> +{
> + struct exynos_sata_phy *sata_phy;
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + struct phy_provider *phy_provider;
> + struct device_node *node;
> + int ret = 0;
> +
> + sata_phy = devm_kzalloc(dev, sizeof(*sata_phy), GFP_KERNEL);
> + if (!sata_phy)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> + sata_phy->regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(sata_phy->regs))
> + return PTR_ERR(sata_phy->regs);
> +
> + sata_phy->pmureg = syscon_regmap_lookup_by_phandle(dev->of_node,
> + "samsung,syscon-phandle");
> + if (IS_ERR(sata_phy->pmureg)) {
> + dev_err(dev, "syscon regmap lookup failed.\n");
> + return PTR_ERR(sata_phy->pmureg);
> + }
> +
> + node = of_parse_phandle(dev->of_node,
> + "samsung,exynos-sataphy-i2c-phandle", 0);
> + if (!node)
> + return -EINVAL;
> +
> + sata_phy->client = of_find_i2c_device_by_node(node);
> + if (!sata_phy->client)
> + return -EPROBE_DEFER;
> +
> + dev_set_drvdata(dev, sata_phy);
> +
> + sata_phy->phyclk = devm_clk_get(dev, "sata_phyctrl");
> + if (IS_ERR(sata_phy->phyclk)) {
> + dev_err(dev, "failed to get clk for PHY\n");
> + return PTR_ERR(sata_phy->phyclk);
> + }
> +
> + ret = clk_prepare_enable(sata_phy->phyclk);
> + if (ret < 0) {
> + dev_err(dev, "failed to enable source clk\n");
> + return ret;
> + }
> +
> + sata_phy->phy = devm_phy_create(dev, &exynos_sata_phy_ops, NULL);
> + if (IS_ERR(sata_phy->phy)) {
> + clk_disable_unprepare(sata_phy->phyclk);
> + dev_err(dev, "failed to create PHY\n");
> + return PTR_ERR(sata_phy->phy);
> + }
> +
> + phy_set_drvdata(sata_phy->phy, sata_phy);
> +
> + phy_provider = devm_of_phy_provider_register(dev,
> + of_phy_simple_xlate);
> + if (IS_ERR(phy_provider)) {
> + clk_disable_unprepare(sata_phy->phyclk);
> + return PTR_ERR(phy_provider);
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id exynos_sata_phy_of_match[] = {
> + { .compatible = "samsung,exynos5250-sata-phy" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, exynos_sata_phy_of_match);
> +
> +static struct platform_driver exynos_sata_phy_driver = {
> + .probe = exynos_sata_phy_probe,
> + .driver = {
> + .of_match_table = exynos_sata_phy_of_match,
> + .name = "samsung,sata-phy",
> + .owner = THIS_MODULE,
> + }
> +};
> +module_platform_driver(exynos_sata_phy_driver);
> +
> +MODULE_DESCRIPTION("Samsung SerDes PHY driver");
> +MODULE_LICENSE("GPL");
The file header tells GPL v2, so change it here too.
Cheers
Kishon
^ permalink raw reply
* [PATCH v3] audit: Add generic compat syscall support
From: AKASHI Takahiro @ 2014-01-29 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127121505.GD32608@arm.com>
Catalin,
Let me correct myself,
On 01/27/2014 09:15 PM, Catalin Marinas wrote:
> On Mon, Jan 27, 2014 at 05:58:07AM +0000, AKASHI Takahiro wrote:
>> Catalin and audit maintainers,
>>
>> On 01/23/2014 11:51 PM, Catalin Marinas wrote:
>>> On Fri, Jan 17, 2014 at 08:03:15AM +0000, AKASHI Takahiro wrote:
>>>> diff --git a/lib/compat_audit.c b/lib/compat_audit.c
>>>> new file mode 100644
>>>> index 0000000..94f6480
>>>> --- /dev/null
>>>> +++ b/lib/compat_audit.c
>>>> @@ -0,0 +1,51 @@
>>>> +#include <linux/init.h>
>>>> +#include <linux/types.h>
>>>> +/* FIXME: this might be architecture dependent */
>>>> +#include <asm/unistd_32.h>
>>>
>>> It most likely is architecture dependent.
>>
>> I'm wondering what name is the most appropriate in this case.
>> Most archictures have __NR_xyz definitions in "unistd_32.h",
>> but arm64 doesn't have it, instead "unistd32." which contains
>> only __SYSCALL(xyz, NO). Confusing?
>
> I don't think we should introduce a new file (or at least it should be
> named something containing "audit" to make it clearer).
>
>>>> +int audit_classify_compat_syscall(int abi, unsigned syscall)
>>>> +{
>>>> + switch (syscall) {
>>>> +#ifdef __NR_open
>>>> + case __NR_open:
>>>> + return 2;
>>>> +#endif
>>>> +#ifdef __NR_openat
>>>> + case __NR_openat:
>>>> + return 3;
>>>> +#endif
>>>> +#ifdef __NR_socketcall
>>>> + case __NR_socketcall:
>>>> + return 4;
>>>> +#endif
>>>> + case __NR_execve:
>>>> + return 5;
>>>> + default:
>>>> + return 1;
>>>> + }
>>>> +}
>>>
>>> BTW, since they aren't many, you could get the arch code to define
>>> __NR_compat_open etc. explicitly and use these. On arm64 we have a few
>>> of these defined to avoid name collision in signal handling code.
>>
>> Again, most architecture have their own unistd32.h for compat system calls,
>> and use __NR_open-like naming.
>> It's unlikely for these archs to migrate to "generic compat" auditing,
>> but I believe that '__NR_open'-like naming is better because we may be able to avoid
>> arch-specific changes even for future(?) syscall-related enhancements in audit.
In my compat_audit.c, all the entries in audit classes are derived from asm-generic/audit_*.h,
where __NR_xyz are used to list the system calls. So it is not possible to use __NR_compat_xyz
as far as we re-use those generic files.
(Obviously we don't want to duplicate those header files, that is, audit_compat_*.h.)
I agree that we should not have similar but different files, like unist32.h and unistd_32.h,
but it seems to be inevitable for our case. (That is the reason why I dynamically generate unistd_32.h)
As for arch-specific header file name, "audit_unistd32.h" can be fine, but people on other architectures
might be unhappy with such a name since they can commonly use unistd32.h instead.
- Takahiro AKASHI
> My preference is as above, a few __NR_compat_* (just those required by
> audit) defined in unistd.h but I'm not an audit maintainer.
>
^ permalink raw reply
* [BUG] reproducable ubifs reboot assert and corruption
From: Andrew Ruder @ 2014-01-29 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127163939.GA27809@gmail.com>
Ok, I've got some more useful information. I have been adding
a multitude of WARN_ON's and prink's all over the remount code and have
come up with the attached log.
A little bit of explanation:
Line 1: sync_filesystem (from do_remount_sb)
Line 188: sync_filesystem ends
Line 43, 64, 81, 98, 114, 135, 156, 173: write operations that occur
during sync_filesystem. Before each warning I print the inode pointer.
Line 197: read-only remount has completely finished (this message is
from userspace post remount)
Line 199: a sync is called, there are apparently dirty inodes in our
now-readonly ubifs filesystem
Line 215: failed assert that occurs because the writeback triggers for
inode 0xd75b9450 (see line 41, it got in with a sys_write while we were
running our sync_filesystem in do_remount_sb)
Does this help? It looks like there is a race condition between the
writeback code and the remount read-only. Nothing is done to lock out
writes during the first half of the do_remount_sb and some stuff makes
it into the writeback worker queue while we are busy syncing the
filesystem only to trigger later when ubifs has decided it is
read-only...
Note: I only barely know what I am talking about - filesystems still not
my forte :)
Thanks,
Andy
1: pre sync_filesystem
2: ------------[ cut here ]------------
3: WARNING: CPU: 0 PID: 645 at fs/fs-writeback.c:98 bdi_queue_work+0xc8/0x130()
4: Modules linked in:
5: CPU: 0 PID: 645 Comm: mount Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
6: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
7: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
8: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
9: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
10: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f4f00>] (bdi_queue_work+0xc8/0x130)
11: [<c00f4f00>] (bdi_queue_work+0xc8/0x130) from [<c00f58cc>] (writeback_inodes_sb_nr+0xb4/0xd4)
12: [<c00f58cc>] (writeback_inodes_sb_nr+0xb4/0xd4) from [<c00f591c>] (writeback_inodes_sb+0x30/0x34)
13: [<c00f591c>] (writeback_inodes_sb+0x30/0x34) from [<c00fa3fc>] (sync_filesystem+0x50/0xbc)
14: [<c00fa3fc>] (sync_filesystem+0x50/0xbc) from [<c00d3bf4>] (do_remount_sb+0xb8/0x1fc)
15: [<c00d3bf4>] (do_remount_sb+0xb8/0x1fc) from [<c00ee3d0>] (do_mount+0x2e8/0x81c)
16: [<c00ee3d0>] (do_mount+0x2e8/0x81c) from [<c00ee998>] (SyS_mount+0x94/0xc8)
17: [<c00ee998>] (SyS_mount+0x94/0xc8) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
18: ---[ end trace c6e04f3813781dc3 ]---
19: Adding tail
20: writeback_workfn d781c110 d700fe8c
21: inode: d75a2c30
22: inode: d75b8c30
23: ------------[ cut here ]------------
24: WARNING: CPU: 0 PID: 645 at fs/fs-writeback.c:98 bdi_queue_work+0xc8/0x130()
25: Modules linked in:
26: CPU: 0 PID: 645 Comm: mount Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
27: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
28: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
29: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
30: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
31: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f4f00>] (bdi_queue_work+0xc8/0x130)
32: [<c00f4f00>] (bdi_queue_work+0xc8/0x130) from [<c00f59dc>] (sync_inodes_sb+0xbc/0x1bc)
33: [<c00f59dc>] (sync_inodes_sb+0xbc/0x1bc) from [<c00fa434>] (sync_filesystem+0x88/0xbc)
34: [<c00fa434>] (sync_filesystem+0x88/0xbc) from [<c00d3bf4>] (do_remount_sb+0xb8/0x1fc)
35: [<c00d3bf4>] (do_remount_sb+0xb8/0x1fc) from [<c00ee3d0>] (do_mount+0x2e8/0x81c)
36: [<c00ee3d0>] (do_mount+0x2e8/0x81c) from [<c00ee998>] (SyS_mount+0x94/0xc8)
37: [<c00ee998>] (SyS_mount+0x94/0xc8) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
38: ---[ end trace c6e04f3813781dc4 ]---
39: Adding tail
40: writeback_workfn d781c110 d700fe9c
41: inode: d75b9450
42: ------------[ cut here ]------------
43: WARNING: CPU: 0 PID: 651 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c()
44: Modules linked in:
45: CPU: 0 PID: 651 Comm: fsstress Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
46: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
47: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
48: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
49: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
50: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c)
51: [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c) from [<c009dc70>] (__set_page_dirty_nobuffers+0xf4/0x110)
52: [<c009dc70>] (__set_page_dirty_nobuffers+0xf4/0x110) from [<c0138a48>] (ubifs_write_end+0x1c8/0x294)
53: [<c0138a48>] (ubifs_write_end+0x1c8/0x294) from [<c009504c>] (generic_file_buffered_write+0x17c/0x260)
54: [<c009504c>] (generic_file_buffered_write+0x17c/0x260) from [<c0096ce8>] (__generic_file_aio_write+0x420/0x448)
55: [<c0096ce8>] (__generic_file_aio_write+0x420/0x448) from [<c0096d78>] (generic_file_aio_write+0x68/0xac)
56: [<c0096d78>] (generic_file_aio_write+0x68/0xac) from [<c0139880>] (ubifs_aio_write+0x17c/0x18c)
57: [<c0139880>] (ubifs_aio_write+0x17c/0x18c) from [<c00d0290>] (do_sync_write+0x7c/0xa0)
58: [<c00d0290>] (do_sync_write+0x7c/0xa0) from [<c00d09e4>] (vfs_write+0xe4/0x194)
59: [<c00d09e4>] (vfs_write+0xe4/0x194) from [<c00d0f94>] (SyS_write+0x4c/0x7c)
60: [<c00d0f94>] (SyS_write+0x4c/0x7c) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
61: ---[ end trace c6e04f3813781dc5 ]---
62: inode: d75a3248
63: ------------[ cut here ]------------
64: WARNING: CPU: 0 PID: 656 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c()
65: Modules linked in:
66: CPU: 0 PID: 656 Comm: fsstress Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
67: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
68: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
69: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
70: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
71: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c)
72: [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c) from [<c0138184>] (ubifs_setattr+0x40c/0x49c)
73: [<c0138184>] (ubifs_setattr+0x40c/0x49c) from [<c00e9634>] (notify_change+0x204/0x2e8)
74: [<c00e9634>] (notify_change+0x204/0x2e8) from [<c00ce888>] (chown_common.isra.14+0x80/0x98)
75: [<c00ce888>] (chown_common.isra.14+0x80/0x98) from [<c00cf820>] (SyS_fchownat+0x8c/0xd4)
76: [<c00cf820>] (SyS_fchownat+0x8c/0xd4) from [<c00cf8e8>] (SyS_lchown+0x3c/0x44)
77: [<c00cf8e8>] (SyS_lchown+0x3c/0x44) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
78: ---[ end trace c6e04f3813781dc6 ]---
79: inode: d75a7040
80: ------------[ cut here ]------------
81: WARNING: CPU: 0 PID: 652 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c()
82: Modules linked in:
83: CPU: 0 PID: 652 Comm: fsstress Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
84: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
85: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
86: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
87: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
88: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c)
89: [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c) from [<c0138184>] (ubifs_setattr+0x40c/0x49c)
90: [<c0138184>] (ubifs_setattr+0x40c/0x49c) from [<c00e9634>] (notify_change+0x204/0x2e8)
91: [<c00e9634>] (notify_change+0x204/0x2e8) from [<c00ce888>] (chown_common.isra.14+0x80/0x98)
92: [<c00ce888>] (chown_common.isra.14+0x80/0x98) from [<c00cf820>] (SyS_fchownat+0x8c/0xd4)
93: [<c00cf820>] (SyS_fchownat+0x8c/0xd4) from [<c00cf8e8>] (SyS_lchown+0x3c/0x44)
94: [<c00cf8e8>] (SyS_lchown+0x3c/0x44) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
95: ---[ end trace c6e04f3813781dc7 ]---
96: inode: d75b9c70
97: ------------[ cut here ]------------
98: WARNING: CPU: 0 PID: 647 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c()
99: Modules linked in:
100: CPU: 0 PID: 647 Comm: fsstress Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
101: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
102: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
103: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
104: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
105: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c)
106: [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c) from [<c013b8ac>] (ubifs_rename+0x4a4/0x600)
107: [<c013b8ac>] (ubifs_rename+0x4a4/0x600) from [<c00de80c>] (vfs_rename+0x280/0x3f4)
108: [<c00de80c>] (vfs_rename+0x280/0x3f4) from [<c00df4ac>] (SyS_renameat+0x18c/0x218)
109: [<c00df4ac>] (SyS_renameat+0x18c/0x218) from [<c00df564>] (SyS_rename+0x2c/0x30)
110: [<c00df564>] (SyS_rename+0x2c/0x30) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
111: ---[ end trace c6e04f3813781dc8 ]---
112: inode: d75a6e38
113: ------------[ cut here ]------------
114: WARNING: CPU: 0 PID: 650 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c()
115: Modules linked in:
116: CPU: 0 PID: 650 Comm: fsstress Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
117: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
118: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
119: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
120: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
121: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c)
122: [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c) from [<c009dc70>] (__set_page_dirty_nobuffers+0xf4/0x110)
123: [<c009dc70>] (__set_page_dirty_nobuffers+0xf4/0x110) from [<c0138a48>] (ubifs_write_end+0x1c8/0x294)
124: [<c0138a48>] (ubifs_write_end+0x1c8/0x294) from [<c009504c>] (generic_file_buffered_write+0x17c/0x260)
125: [<c009504c>] (generic_file_buffered_write+0x17c/0x260) from [<c0096ce8>] (__generic_file_aio_write+0x420/0x448)
126: [<c0096ce8>] (__generic_file_aio_write+0x420/0x448) from [<c0096d78>] (generic_file_aio_write+0x68/0xac)
127: [<c0096d78>] (generic_file_aio_write+0x68/0xac) from [<c0139880>] (ubifs_aio_write+0x17c/0x18c)
128: [<c0139880>] (ubifs_aio_write+0x17c/0x18c) from [<c00d0290>] (do_sync_write+0x7c/0xa0)
129: [<c00d0290>] (do_sync_write+0x7c/0xa0) from [<c00d09e4>] (vfs_write+0xe4/0x194)
130: [<c00d09e4>] (vfs_write+0xe4/0x194) from [<c00d0f94>] (SyS_write+0x4c/0x7c)
131: [<c00d0f94>] (SyS_write+0x4c/0x7c) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
132: ---[ end trace c6e04f3813781dc9 ]---
133: inode: d75a2e38
134: ------------[ cut here ]------------
135: WARNING: CPU: 0 PID: 651 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c()
136: Modules linked in:
137: CPU: 0 PID: 651 Comm: fsstress Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
138: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
139: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
140: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
141: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
142: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c)
143: [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c) from [<c009dc70>] (__set_page_dirty_nobuffers+0xf4/0x110)
144: [<c009dc70>] (__set_page_dirty_nobuffers+0xf4/0x110) from [<c0138a48>] (ubifs_write_end+0x1c8/0x294)
145: [<c0138a48>] (ubifs_write_end+0x1c8/0x294) from [<c009504c>] (generic_file_buffered_write+0x17c/0x260)
146: [<c009504c>] (generic_file_buffered_write+0x17c/0x260) from [<c0096ce8>] (__generic_file_aio_write+0x420/0x448)
147: [<c0096ce8>] (__generic_file_aio_write+0x420/0x448) from [<c0096d78>] (generic_file_aio_write+0x68/0xac)
148: [<c0096d78>] (generic_file_aio_write+0x68/0xac) from [<c0139880>] (ubifs_aio_write+0x17c/0x18c)
149: [<c0139880>] (ubifs_aio_write+0x17c/0x18c) from [<c00d0290>] (do_sync_write+0x7c/0xa0)
150: [<c00d0290>] (do_sync_write+0x7c/0xa0) from [<c00d09e4>] (vfs_write+0xe4/0x194)
151: [<c00d09e4>] (vfs_write+0xe4/0x194) from [<c00d0f94>] (SyS_write+0x4c/0x7c)
152: [<c00d0f94>] (SyS_write+0x4c/0x7c) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
153: ---[ end trace c6e04f3813781dca ]---
154: inode: d75a2410
155: ------------[ cut here ]------------
156: WARNING: CPU: 0 PID: 653 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c()
157: Modules linked in:
158: CPU: 0 PID: 653 Comm: fsstress Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
159: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
160: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
161: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
162: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
163: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c)
164: [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c) from [<c0138184>] (ubifs_setattr+0x40c/0x49c)
165: [<c0138184>] (ubifs_setattr+0x40c/0x49c) from [<c00e9634>] (notify_change+0x204/0x2e8)
166: [<c00e9634>] (notify_change+0x204/0x2e8) from [<c00ce888>] (chown_common.isra.14+0x80/0x98)
167: [<c00ce888>] (chown_common.isra.14+0x80/0x98) from [<c00cf820>] (SyS_fchownat+0x8c/0xd4)
168: [<c00cf820>] (SyS_fchownat+0x8c/0xd4) from [<c00cf8e8>] (SyS_lchown+0x3c/0x44)
169: [<c00cf8e8>] (SyS_lchown+0x3c/0x44) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
170: ---[ end trace c6e04f3813781dcb ]---
171: inode: d75a6410
172: ------------[ cut here ]------------
173: WARNING: CPU: 0 PID: 653 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c()
174: Modules linked in:
175: CPU: 0 PID: 653 Comm: fsstress Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
176: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
177: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
178: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
179: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
180: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c)
181: [<c00f57c8>] (__mark_inode_dirty+0x2dc/0x32c) from [<c0138184>] (ubifs_setattr+0x40c/0x49c)
182: [<c0138184>] (ubifs_setattr+0x40c/0x49c) from [<c00e9634>] (notify_change+0x204/0x2e8)
183: [<c00e9634>] (notify_change+0x204/0x2e8) from [<c00ce888>] (chown_common.isra.14+0x80/0x98)
184: [<c00ce888>] (chown_common.isra.14+0x80/0x98) from [<c00cf820>] (SyS_fchownat+0x8c/0xd4)
185: [<c00cf820>] (SyS_fchownat+0x8c/0xd4) from [<c00cf8e8>] (SyS_lchown+0x3c/0x44)
186: [<c00cf8e8>] (SyS_lchown+0x3c/0x44) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
187: ---[ end trace c6e04f3813781dcc ]---
188: post sync_filesystem
189: preparing
190: done preparing
191: success
192: In remount_ro
193: UBIFS: background thread "ubifs_bgt0_0" stops
194: thread stopped
195: ending 1 d781c110 d781c110
196: remount done 1
197: remount
198: ------------[ cut here ]------------
199: WARNING: CPU: 0 PID: 661 at fs/fs-writeback.c:98 bdi_queue_work+0xc8/0x130()
200: Modules linked in:
201: CPU: 0 PID: 661 Comm: fsstress Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
202: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
203: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
204: [<c0348590>] (dump_stack+0x20/0x28) from [<c0020874>] (warn_slowpath_common+0x78/0x98)
205: [<c0020874>] (warn_slowpath_common+0x78/0x98) from [<c0020950>] (warn_slowpath_null+0x2c/0x34)
206: [<c0020950>] (warn_slowpath_null+0x2c/0x34) from [<c00f4f00>] (bdi_queue_work+0xc8/0x130)
207: [<c00f4f00>] (bdi_queue_work+0xc8/0x130) from [<c00f5e48>] (__bdi_start_writeback+0x114/0x128)
208: [<c00f5e48>] (__bdi_start_writeback+0x114/0x128) from [<c00f70fc>] (wakeup_flusher_threads+0x70/0x90)
209: [<c00f70fc>] (wakeup_flusher_threads+0x70/0x90) from [<c00fa49c>] (sys_sync+0x34/0xa4)
210: [<c00fa49c>] (sys_sync+0x34/0xa4) from [<c000e820>] (ret_fast_syscall+0x0/0x2c)
211: ---[ end trace c6e04f3813781dcd ]---
212: Adding tail
213: writeback_workfn d781c110 d7b970d8
214: inode: d75b9450
215: UBIFS assert failed in reserve_space at 125 (pid 6)
216: CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W 3.12.0-00041-g7f12d39-dirty #236
217: Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
218: [<c0014fb4>] (unwind_backtrace+0x0/0x128) from [<c0012394>] (show_stack+0x20/0x24)
219: [<c0012394>] (show_stack+0x20/0x24) from [<c0348590>] (dump_stack+0x20/0x28)
220: [<c0348590>] (dump_stack+0x20/0x28) from [<c0134b84>] (make_reservation+0x8c/0x560)
221: [<c0134b84>] (make_reservation+0x8c/0x560) from [<c0135ed8>] (ubifs_jnl_write_inode+0xbc/0x214)
222: [<c0135ed8>] (ubifs_jnl_write_inode+0xbc/0x214) from [<c013d168>] (ubifs_write_inode+0xec/0x17c)
223: [<c013d168>] (ubifs_write_inode+0xec/0x17c) from [<c01391d8>] (ubifs_writepage+0x180/0x288)
224: [<c01391d8>] (ubifs_writepage+0x180/0x288) from [<c009d2dc>] (__writepage+0x24/0x6c)
225: [<c009d2dc>] (__writepage+0x24/0x6c) from [<c009d89c>] (write_cache_pages+0x2e8/0x3e8)
226: [<c009d89c>] (write_cache_pages+0x2e8/0x3e8) from [<c009d9e8>] (generic_writepages+0x4c/0x68)
227: [<c009d9e8>] (generic_writepages+0x4c/0x68) from [<c009f040>] (do_writepages+0x3c/0x48)
228: [<c009f040>] (do_writepages+0x3c/0x48) from [<c00f518c>] (__writeback_single_inode+0xf8/0x37c)
229: [<c00f518c>] (__writeback_single_inode+0xf8/0x37c) from [<c00f60f0>] (writeback_sb_inodes+0x1f8/0x3dc)
230: [<c00f60f0>] (writeback_sb_inodes+0x1f8/0x3dc) from [<c00f6354>] (__writeback_inodes_wb+0x80/0xc0)
231: [<c00f6354>] (__writeback_inodes_wb+0x80/0xc0) from [<c00f6548>] (wb_writeback+0x1b4/0x364)
232: [<c00f6548>] (wb_writeback+0x1b4/0x364) from [<c00f6c74>] (bdi_writeback_workfn+0xbc/0x4d4)
233: [<c00f6c74>] (bdi_writeback_workfn+0xbc/0x4d4) from [<c0038454>] (process_one_work+0x298/0x44c)
234: [<c0038454>] (process_one_work+0x298/0x44c) from [<c0038b04>] (worker_thread+0x240/0x380)
235: [<c0038b04>] (worker_thread+0x240/0x380) from [<c003e1a8>] (kthread+0xbc/0xc8)
236: [<c003e1a8>] (kthread+0xbc/0xc8) from [<c000e8b0>] (ret_from_fork+0x14/0x20)
^ permalink raw reply
* [PATCH 1/2] arm64: use num_possible_cpus() instead of NR_CPUS
From: Jingoo Han @ 2014-01-29 5:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E78241.4020502@arm.com>
On Tuesday, January 28, 2014 7:11 PM, Sudeep Holla wrote:
> On 28/01/14 01:35, Jingoo Han wrote:
> > Use num_possible_cpus() instead of direct use of NR_CPUS. Also,
> > it fixes the following checkpatch warning.
> >
> > WARNING: usage of NR_CPUS is often wrong - consider using cpu_possible(), num_possible_cpus(),
> for_each_possible_cpu(), etc
> >
> > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> > ---
> > arch/arm64/kernel/smp.c | 10 +++++-----
> > arch/arm64/mm/context.c | 2 +-
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index 1b7617a..09ff7d4 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -320,7 +320,7 @@ void __init smp_init_cpus(void)
> > * cpu_logical_map was initialized to INVALID_HWID to
> > * avoid matching valid MPIDR values.
> > */
> > - for (i = 1; (i < cpu) && (i < NR_CPUS); i++) {
> > + for (i = 1; (i < cpu) && (i < num_possible_cpus()); i++) {
> > if (cpu_logical_map(i) == hwid) {
> > pr_err("%s: duplicate cpu reg properties in the DT\n",
> > dn->full_name);
> > @@ -352,7 +352,7 @@ void __init smp_init_cpus(void)
> > continue;
> > }
> >
> > - if (cpu >= NR_CPUS)
> > + if (cpu >= num_possible_cpus())
>
> Have you tested this patch ? IIUC this will not work as cpu_possible mask is
> populated completely and correctly only at the end of this function.
>
> > goto next;
> >
> > if (cpu_read_ops(dn, cpu) != 0)
> > @@ -368,9 +368,9 @@ next:
> > }
> >
> > /* sanity check */
> > - if (cpu > NR_CPUS)
> > + if (cpu > num_possible_cpus())
> > pr_warning("no. of cores (%d) greater than configured maximum of %d - clipping\n",
> > - cpu, NR_CPUS);
> > + cpu, num_possible_cpus());
> >
> > if (!bootcpu_valid) {
> > pr_err("DT missing boot CPU MPIDR, not enabling secondaries\n");
> > @@ -381,7 +381,7 @@ next:
> > * All the cpus that made it to the cpu_logical_map have been
> > * validated so set them as possible cpus.
> > */
> > - for (i = 0; i < NR_CPUS; i++)
> > + for (i = 0; i < num_possible_cpus(); i++)
> > if (cpu_logical_map(i) != INVALID_HWID)
> > set_cpu_possible(i, true);
>
> This is what I am referring above, where is possible mask set before this.
> If it's already populated correctly then we can remove this completely.
OK, you're right.
Please, ignore this patch.
I really appreciate your comment. :-)
Best regards,
Jingoo Han
^ permalink raw reply
* [PATCH 2/2] arm64: kernel: use seq_puts() instead of seq_printf()
From: Joe Perches @ 2014-01-29 5:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001201cf1cae$2d60ce80$88226b80$%han@samsung.com>
On Wed, 2014-01-29 at 13:54 +0900, Jingoo Han wrote:
> On Wednesday, January 29, 2014 12:52 AM, Catalin Marinas wrote:
> > On Tue, Jan 28, 2014 at 01:36:18AM +0000, Jingoo Han wrote:
> > > For a constant format without additional arguments, use seq_puts()
> > > instead of seq_printf(). Also, it fixes the following checkpatch
> > > warning.
> > >
> > > WARNING: Prefer seq_puts to seq_printf
> > >
> > > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> > > ---
> > > arch/arm64/kernel/setup.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > index c8e9eff..4507691 100644
> > > --- a/arch/arm64/kernel/setup.c
> > > +++ b/arch/arm64/kernel/setup.c
> > > @@ -416,7 +416,7 @@ static int c_show(struct seq_file *m, void *v)
> > > seq_printf(m, "%s ", hwcap_str[i]);
> > >
> > > seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24);
> > > - seq_printf(m, "CPU architecture: AArch64\n");
> > > + seq_puts(m, "CPU architecture: AArch64\n");
> > > seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15);
> > > seq_printf(m, "CPU part\t: 0x%03x\n", (read_cpuid_id() >> 4) & 0xfff);
> > > seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15);
> >
> > Just ignore the checkpatch warning. I prefer the consistency of
> > seq_printf() in this function.
>
> (+cc Joe Perches, Dan Carpenter)
>
> Personally, I don't like the checkpatch warning.
> However, I respect your opinion on the consistency.
> Thank you for your comment.
No worries from me.
I'm happy you can ignore checkpatch bleatings
you don't agree with.
It's a stupid little checker.
People are much smarter.
cheers, Joe
^ permalink raw reply
* [PATCH 2/2] arm64: kernel: use seq_puts() instead of seq_printf()
From: Jingoo Han @ 2014-01-29 4:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128155156.GC24617@arm.com>
On Wednesday, January 29, 2014 12:52 AM, Catalin Marinas wrote:
> On Tue, Jan 28, 2014 at 01:36:18AM +0000, Jingoo Han wrote:
> > For a constant format without additional arguments, use seq_puts()
> > instead of seq_printf(). Also, it fixes the following checkpatch
> > warning.
> >
> > WARNING: Prefer seq_puts to seq_printf
> >
> > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> > ---
> > arch/arm64/kernel/setup.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index c8e9eff..4507691 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -416,7 +416,7 @@ static int c_show(struct seq_file *m, void *v)
> > seq_printf(m, "%s ", hwcap_str[i]);
> >
> > seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24);
> > - seq_printf(m, "CPU architecture: AArch64\n");
> > + seq_puts(m, "CPU architecture: AArch64\n");
> > seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15);
> > seq_printf(m, "CPU part\t: 0x%03x\n", (read_cpuid_id() >> 4) & 0xfff);
> > seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15);
>
> Just ignore the checkpatch warning. I prefer the consistency of
> seq_printf() in this function.
(+cc Joe Perches, Dan Carpenter)
Personally, I don't like the checkpatch warning.
However, I respect your opinion on the consistency.
Thank you for your comment.
Best regards,
Jingoo Han
^ 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