[PATCH 1/2] net: macb: Include multi queue support for xilinx ZynqMP ethernet version
From: Punnaiah Choudary Kalluri Include multi queue support for the ethernet IP version in xilinx ZynqMP SoC. Signed-off-by: Punnaiah Choudary Kalluri Signed-off-by: Michal Simek --- drivers/net/ethernet/cadence/macb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c index ad76b8e35a00..24b1eb466e52 100644 --- a/drivers/net/ethernet/cadence/macb.c +++ b/drivers/net/ethernet/cadence/macb.c @@ -2192,7 +2192,7 @@ static void macb_probe_queues(void __iomem *mem, /* is it macb or gem ? */ mid = __raw_readl(mem + MACB_MID); - if (MACB_BFEXT(IDNUM, mid) != 0x2) + if (MACB_BFEXT(IDNUM, mid) < 0x2) return; /* bit 0 is never set but queue 0 always exists */ -- 1.8.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] net: macb: Fix multi queue support for xilinx ZynqMP soc
From: Punnaiah Choudary Kalluri
ZynqMP soc has single interrupt for all the queue events. So,
passing the IRQF_SHARED flag for interrupt registration call.
Signed-off-by: Punnaiah Choudary Kalluri
Signed-off-by: Michal Simek
---
drivers/net/ethernet/cadence/macb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 24b1eb466e52..0493c3e6bbbe 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2319,7 +2319,7 @@ static int macb_probe(struct platform_device *pdev)
*/
queue->irq = platform_get_irq(pdev, q);
err = devm_request_irq(>dev, queue->irq, macb_interrupt,
- 0, dev->name, queue);
+ IRQF_SHARED, dev->name, queue);
if (err) {
dev_err(>dev,
"Unable to request IRQ %d (error %d)\n",
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] dmaengine: bam-dma: fix a warning about missing capabilities
Avoid the warning below triggered during dmaengine async device registration. WARNING: CPU: 1 PID: 1 at linux/drivers/dma/dmaengine.c:863 dma_async_device_register+0x2a8/0x4b8() this driver doesn't support generic slave capabilities reporting To do that fill mandatory .directions bit mask, .src/dst_addr_widths and .residue_granularity dma_device fields with appropriate values. Signed-off-by: Stanimir Varbanov --- v1 -> v2 - the patch subject has been changed - now fill also .residue_granularity and src/dts_addr_widths - added the warning in patch description v1 can be found at https://lkml.org/lkml/2015/3/4/896 drivers/dma/qcom_bam_dma.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c index c3113e3..9c914d6 100644 --- a/drivers/dma/qcom_bam_dma.c +++ b/drivers/dma/qcom_bam_dma.c @@ -1143,6 +1143,10 @@ static int bam_dma_probe(struct platform_device *pdev) dma_cap_set(DMA_SLAVE, bdev->common.cap_mask); /* initialize dmaengine apis */ + bdev->common.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV); + bdev->common.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT; + bdev->common.src_addr_widths = DMA_SLAVE_BUSWIDTH_4_BYTES; + bdev->common.dst_addr_widths = DMA_SLAVE_BUSWIDTH_4_BYTES; bdev->common.device_alloc_chan_resources = bam_alloc_chan; bdev->common.device_free_chan_resources = bam_free_chan; bdev->common.device_prep_slave_sg = bam_prep_slave_sg; -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Remove deprecated IRQF_DISABLED flag entirely
The IRQF_DISABLED is a NOOP and has been scheduled for removal since
Linux v2.6.36 by commit 6932bf37bed4 ("genirq: Remove IRQF_DISABLED from
core code").
According to commit e58aa3d2d0cc ("genirq: Run irq handlers with
interrupts disabled") running IRQ handlers with interrupts enabled can
cause stack overflows when the interrupt line of the issuing device is
still active.
This patch ends the grace period for IRQF_DISABLED (i.e., SA_INTERRUPT
in older versions of Linux) and removes the definition and all remaining
usages of this flag.
Signed-off-by: Valentin Rothberg
---
The bigger hunk in Documentation/scsi/ncr53c8xx.txt is removed entirely
as IRQF_DISABLED is gone now; the usage in older kernel versions
(including the old SA_INTERRUPT flag) should be discouraged. The
trouble of using IRQF_SHARED is a general problem and not specific to
any driver.
I left the reference in Documentation/PCI/MSI-HOWTO.txt untouched since
it has already been removed in linux-next by commit b0e1ee8e1405
("MSI-HOWTO.txt: remove reference on IRQF_DISABLED").
All remaining references are changelogs that I suggest to keep.
---
Documentation/scsi/ncr53c8xx.txt | 25 -
Documentation/scsi/tmscsim.txt | 4
arch/mips/loongson/loongson-3/hpet.c | 2 +-
drivers/block/cpqarray.c | 4 ++--
drivers/bus/omap_l3_noc.c| 4 ++--
drivers/bus/omap_l3_smx.c| 10 --
drivers/mtd/nand/hisi504_nand.c | 3 +--
drivers/usb/isp1760/isp1760-core.c | 3 +--
drivers/usb/isp1760/isp1760-udc.c| 4 ++--
include/linux/interrupt.h| 3 ---
10 files changed, 13 insertions(+), 49 deletions(-)
diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt
index 1d508dcbf859..8586efff1e99 100644
--- a/Documentation/scsi/ncr53c8xx.txt
+++ b/Documentation/scsi/ncr53c8xx.txt
@@ -786,7 +786,6 @@ port address 0x1400.
irqm:1 same as initial settings (assumed BIOS settings)
irqm:2 always totem pole
irqm:0x10 driver will not use IRQF_SHARED flag when requesting irq
-irqm:0x20 driver will not use IRQF_DISABLED flag when requesting irq
(Bits 0x10 and 0x20 can be combined with hardware irq mode option)
@@ -1231,30 +1230,6 @@ they only refer to system buffers that are well aligned.
So, a work around
may only be needed under Linux when a scatter/gather list is not used and
when the SCSI DATA IN phase is reentered after a phase mismatch.
-14.5 IRQ sharing problems
-
-When an IRQ is shared by devices that are handled by different drivers, it
-may happen that one driver complains about the request of the IRQ having
-failed. Inder Linux-2.0, this may be due to one driver having requested the
-IRQ using the IRQF_DISABLED flag but some other having requested the same IRQ
-without this flag. Under both Linux-2.0 and linux-2.2, this may be caused by
-one driver not having requested the IRQ with the IRQF_SHARED flag.
-
-By default, the ncr53c8xx and sym53c8xx drivers request IRQs with both the
-IRQF_DISABLED and the IRQF_SHARED flag under Linux-2.0 and with only the
IRQF_SHARED
-flag under Linux-2.2.
-
-Under Linux-2.0, you can disable use of IRQF_DISABLED flag from the boot
-command line by using the following option:
-
- ncr53c8xx=irqm:0x20 (for the generic ncr53c8xx driver)
- sym53c8xx=irqm:0x20 (for the sym53c8xx driver)
-
-If this does not fix the problem, then you may want to check how all other
-drivers are requesting the IRQ and report the problem. Note that if at least
-a single driver does not request the IRQ with the IRQF_SHARED flag (share IRQ),
-then the request of the IRQ obviously will not succeed for all the drivers.
-
15. SCSI problem troubleshooting
15.1 Problem tracking
diff --git a/Documentation/scsi/tmscsim.txt b/Documentation/scsi/tmscsim.txt
index 0810132772a8..0e0322bf0020 100644
--- a/Documentation/scsi/tmscsim.txt
+++ b/Documentation/scsi/tmscsim.txt
@@ -107,10 +107,6 @@ produced errors and started to corrupt my disks. So don't
do that! A 37.50
MHz PCI bus works for me, though, but I don't recommend using higher clocks
than the 33.33 MHz being in the PCI spec.
-If you want to share the IRQ with another device and the driver refuses to
-do so, you might succeed with changing the DC390_IRQ type in tmscsim.c to
-IRQF_SHARED | IRQF_DISABLED.
-
3.Features
--
diff --git a/arch/mips/loongson/loongson-3/hpet.c
b/arch/mips/loongson/loongson-3/hpet.c
index e898d68668a9..5c21cd3bd339 100644
--- a/arch/mips/loongson/loongson-3/hpet.c
+++ b/arch/mips/loongson/loongson-3/hpet.c
@@ -162,7 +162,7 @@ static irqreturn_t hpet_irq_handler(int irq, void *data)
static struct irqaction hpet_irq = {
.handler = hpet_irq_handler,
- .flags = IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TIMER,
+ .flags = IRQF_NOBALANCING | IRQF_TIMER,
.name = "hpet",
};
diff --git a/drivers/block/cpqarray.c b/drivers/block/cpqarray.c
Re: [PATCH v3 5/9] mtd: pxa3xx_nand: add support for the Marvell Berlin nand controller
Dear Antoine Tenart,
On Thu, 5 Mar 2015 12:31:21 +0100, Antoine Tenart wrote:
> struct pxa3xx_nand_host {
> @@ -253,6 +258,12 @@ static struct pxa3xx_nand_flash builtin_flash_types[] = {
> { "512MiB 8-bit", 0xdc2c, 64, 2048, 8, 8, 4096 },
> { "512MiB 16-bit", 0xcc2c, 64, 2048, 16, 16, 4096 },
> { "256MiB 16-bit", 0xba20, 64, 2048, 16, 16, 2048 },
> +{ }
> +};
> +
> +static struct pxa3xx_nand_flash berlin_builtin_flash_types[] = {
> +{ "4GiB 8-bit",0xd7ec, 128, 8192, 8, 8, 4096 },
> +{ },
This looks fishy. You know have two different definitions for the exact
same chip_id. In the builtin_flash_types[] array:
{ "4GiB 8-bit",0xd7ec, 128, 4096, 8, 8, 8192 },
and in your new berlin_builtin_flash_types[] array:
{ "4GiB 8-bit",0xd7ec, 128, 8192, 8, 8, 4096 },
So you have twice a big pages, and twice as less blocks. Are you sure
about your definition of the 0xd7ec NAND chip_id ?
Why cannot you use the same data for both the Berlin platform and the
platforms already supported by the driver? Are you sure your NAND isn't
using 4k pages ? Or maybe the 0xd7ec entry in builtin_flash_types[] is
incorrect?
Or maybe like
http://lists.infradead.org/pipermail/linux-mtd/2010-June/031159.html,
the NAND chip_id is the same, but the NAND ext id is different.
Is there no common NAND mechanism to handle this, rather than having
this specifically in the driver?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] toshiba_acpi: Add Satellite P50W-B to alternative keymap and create new mappings.
On 03/04/2015 07:05 PM, Azael Avalos wrote:
> Hi there,
>
> 2015-03-04 14:52 GMT-07:00 Joseph Salisbury :
> ...
>> + { KE_KEY, 0x140, { KEY_BRIGHTNESSDOWN } },
>> + { KE_KEY, 0x141, { KEY_BRIGHTNESSUP } },
> ...
>
> These two are not neccesary, as they may collide with "previous song"
> and "playpause" in case Toshiba (or its manufacturers) decide to use
> those keys.
>
> If you can, please test the first two patches from the gmane archive [1],
> they eliminate the need of the DMI matching list. And it would be great
> to have more laptops tested.
>
> [1] http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/6602
>
>
> Cheers
> Azael
>
>
Thanks for the feedback, Azael. I'll spin up a kernel with the first
two patches in that archive, and have them testing. I'll reply with the
results.
Thanks again,
Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memcg: make CONFIG_MEMCG depend on CONFIG_MMU
On Wed 04-03-15 13:21:26, Andrew Morton wrote: > On Wed, 4 Mar 2015 16:13:01 -0500 Johannes Weiner wrote: > > > I don't even care about NOMMU, this is just wrong on principle. > > Agree. And I do care about nommu ;) > > If some nommu person wants to start using memcg and manages to get it > doing something useful then good for them - we end up with a better > kernel. We shouldn't go and rule this out without having even tried it. Fair enough, but shouldn't we be explicit (and honest) that the configuration is currently broken and hardly usable? Would it make sense to make MEMCG depend on BROKEN for !MMU? If somebody really has an usecase then dependency on BROKEN would suggest there is a work to be done before it is enabled for his/her configuration. I would expect such a user would send us an email when noticing this and submit a bug report so that we can help making it work. --- >From 3707f445ebd21d10c076f0cb2446a0732cf6c3bb Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Wed, 4 Mar 2015 10:48:47 +0100 Subject: [PATCH] memcg: mark CONFIG_MEMCG broken for !CONFIG_MMU CONFIG_MEMCG might be currently enabled also for !MMU architectures which was probably an omission because Balbir had this on the TODO list section (https://lkml.org/lkml/2008/3/16/59) " Only when CONFIG_MMU is enabled, is the virtual address space control enabled. Should we do this for nommu cases as well? My suspicion is that we don't have to. " I do not see any traces for !MMU requests after then. The code compiles with !MMU but I haven't heard about anybody using it in the real life so it is not clear to me whether it works and it is usable at all. At least anonymous mmaps do not try to charge the memory and who knows what else is broken. Let's make CONFIG_MEMCG depend on BROKEN for !CONFIG_MMU to make the current status explicit for somebody who might be interested in using MEMCG and report it to us so that we can help with fixing it up. Signed-off-by: Michal Hocko --- init/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/init/Kconfig b/init/Kconfig index 9afb971497f4..f5373c4188c0 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -979,6 +979,7 @@ config MEMCG bool "Memory Resource Controller for Control Groups" select PAGE_COUNTER select EVENTFD + depends on MMU || BROKEN help Provides a memory resource controller that manages both anonymous memory and page cache. (See Documentation/cgroups/memory.txt) -- 2.1.4 -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: STi: Add STiH410 SoC support
Hi Fabrice,
On 03/05/2015 01:47 PM, Fabrice GASNIER wrote:
This patch adds support to STiH410 SoC.
Actually, the STiH410 support is already here in v4.0-rc1.
The problem is that it is missing the entry in the match table,
and so the L2 cache and other cpus than 0 don't get initialized.
Once fixed, you can add my:
Acked-by: Maxime Coquelin
Thanks,
Maxime
Signed-off-by: Fabrice Gasnier
---
Documentation/devicetree/bindings/arm/sti.txt | 4
arch/arm/mach-sti/board-dt.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sti.txt
b/Documentation/devicetree/bindings/arm/sti.txt
index d70ec35..8d27f6b 100644
--- a/Documentation/devicetree/bindings/arm/sti.txt
+++ b/Documentation/devicetree/bindings/arm/sti.txt
@@ -13,6 +13,10 @@ Boards with the ST STiH407 SoC shall have the following
properties:
Required root node property:
compatible = "st,stih407";
+Boards with the ST STiH410 SoC shall have the following properties:
+Required root node property:
+compatible = "st,stih410";
+
Boards with the ST STiH418 SoC shall have the following properties:
Required root node property:
compatible = "st,stih418";
diff --git a/arch/arm/mach-sti/board-dt.c b/arch/arm/mach-sti/board-dt.c
index b067390..b373aca 100644
--- a/arch/arm/mach-sti/board-dt.c
+++ b/arch/arm/mach-sti/board-dt.c
@@ -18,6 +18,7 @@ static const char *stih41x_dt_match[] __initdata = {
"st,stih415",
"st,stih416",
"st,stih407",
+ "st,stih410",
"st,stih418",
NULL
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 8/9] ACPI: arm64: use an arch-specific ACPI _OSI method and ACPI blacklist
On Thu, Mar 5, 2015 at 11:17 AM, Will Deacon wrote:
> On Wed, Mar 04, 2015 at 11:14:50PM +, Rafael J. Wysocki wrote:
>> On Monday, March 02, 2015 12:00:21 PM Al Stone wrote:
>> > On 03/02/2015 10:29 AM, Will Deacon wrote:
>> > > On Wed, Feb 25, 2015 at 12:36:24AM +, al.st...@linaro.org wrote:
>> > >> diff --git a/arch/arm64/kernel/acpi-blacklist.c
>> > >> b/arch/arm64/kernel/acpi-blacklist.c
>> > >> new file mode 100644
>> > >> index 000..1be6a56
>> > >> --- /dev/null
>> > >> +++ b/arch/arm64/kernel/acpi-blacklist.c
>> > >> @@ -0,0 +1,20 @@
>> > >> +/*
>> > >> + * ARM64 Specific ACPI Blacklist Support
>> > >> + *
>> > >> + * Copyright (C) 2015, Linaro Ltd.
>> > >> + * Author: Al Stone
>> > >> + *
>> > >> + * 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.
>> > >> + */
>> > >> +
>> > >> +#define pr_fmt(fmt) "ACPI: " fmt
>> > >> +
>> > >> +#include
>> > >> +
>> > >> +/* The arm64 ACPI blacklist is currently empty. */
>> > >> +int __init acpi_blacklisted(void)
>> > >> +{
>> > >> +return 0;
>> > >> +}
>> > >> diff --git a/arch/arm64/kernel/acpi-osi.c b/arch/arm64/kernel/acpi-osi.c
>> > >> new file mode 100644
>> > >> index 000..bb351f4
>> > >> --- /dev/null
>> > >> +++ b/arch/arm64/kernel/acpi-osi.c
>> > >> @@ -0,0 +1,25 @@
>> > >> +/*
>> > >> + * ARM64 Specific ACPI _OSI Support
>> > >> + *
>> > >> + * Copyright (C) 2015, Linaro Ltd.
>> > >> + * Author: Al Stone
>> > >> + *
>> > >> + * 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.
>> > >> + */
>> > >> +
>> > >> +#define pr_fmt(fmt) "ACPI: " fmt
>> > >> +
>> > >> +#include
>> > >> +
>> > >> +/*
>> > >> + * Consensus is to deprecate _OSI for all new ACPI-supported
>> > >> architectures.
>> > >> + * So, for arm64, reduce _OSI to a warning message, and tell the
>> > >> firmware
>> > >> + * nothing of value.
>> > >> + */
>> > >> +u32 acpi_osi_handler(acpi_string interface, u32 supported)
>> > >> +{
>> > >> +pr_warn("_OSI was called, but is deprecated for this
>> > >> architecture.\n");
>> > >> +return false;
>> > >> +}
>> > >
>> > > This kinda feels backwards to me. If _OSI is going away, then the default
>> > > should be "the architecture doesn't need to do anything", rather than
>> > > have
>> > > new architectures defining a bunch of empty, useless stub code.
>> > >
>> > > Anyway we could make this the default in core code and have architectures
>> > > that *do* want _OSI override that behaviour, instead of the other way
>> > > around?
>> > >
>> > We could do that; I personally don't have a strong preference either way,
>> > so I'm inclined to make it whatever structure Rafael thinks is proper since
>> > it affects ACPI code most. That being said, the current patch structure
>> > made sense to me since it wasn't distorting existing code much -- and given
>> > the pure number of x86/ia64 machines vs ARM machines using ACPI, that
>> > seemed
>> > the more cautious approach.
>> >
>> > @Rafael: do you have an opinion/preference?
>>
>> My preference is to avoid changes in the existing code at least for the time
>> being. Especially if the changes in question are going to affect ia64,
>> unless
>> you have an Itanium machine where you can readily test those, that is. :-)
>
> Well, this code doesn't even need to compiled for ia64 if we have those
> architectures that want to use _OSI select a Kconfig symbol for it, so I
> don't think the testing argument is really that valid. I appreciate that you
> want to avoid changing the existing code, but I also don't want to add this
> sort of stuff to the architecture code, when it really has nothing to do
> with the architecture.
OK, so consider this.
_OSI may be deprecated in the spec for *new* implementations.
However, there still are many systems out there that use _OSI and
we'll need to support
them going forward. So while the spec people may think that they have
deprecated
_OSI, the reality is that in the kernel it is not going to be
deprecated as long as there
are systems using it that we need to support.
So the whole "_OSI is going away" argument is simply bogus and useless.
That aside, yes, we can use a Kconfig symbol to select from x86 and ia64
and compile the generic code conditional on that. That would be fine by me.
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 00/24] THP refcounting redesign
On 03/04/2015 05:32 PM, Kirill A. Shutemov wrote: > Hello everybody, > > It's bug-fix update of my thp refcounting work. > > The goal of patchset is to make refcounting on THP pages cheaper with > simpler semantics and allow the same THP compound page to be mapped with > PMD and PTEs. This is required to get reasonable THP-pagecache > implementation. > > With the new refcounting design it's much easier to protect against > split_huge_page(): simple reference on a page will make you the deal. > It makes gup_fast() implementation simpler and doesn't require > special-case in futex code to handle tail THP pages. > > It should improve THP utilization over the system since splitting THP in > one process doesn't necessary lead to splitting the page in all other > processes have the page mapped. > [...] > I believe all known bugs have been fixed, but I'm sure Sasha will bring more > reports. > > The patchset also available on git: > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git thp/refcounting/v4 > Hi Kirill, I ran some ltp tests and it triggered two bugs: [ 318.526528] [ cut here ] [ 318.527031] kernel BUG at mm/filemap.c:203! [ 318.527031] invalid opcode: [#1] SMP [ 318.527031] Modules linked in: loop ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_security iptable_raw crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev microcode joydev virtio_console pcspkr serio_raw virtio_balloon parport_pc parport nfsd pvpanic i2c_piix4 acpi_cpufreq auth_rpcgss nfs_acl lockd grace sunrpc qxl virtio_blk virtio_net drm_kms_helper ttm drm virtio_pci virtio_ring virtio ata_generic pata_acpi floppy [ 318.527031] CPU: 0 PID: 8929 Comm: hugemmap01 Not tainted 4.0.0-rc1-next-20150227+ #213 [ 318.527031] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 318.527031] task: 8800783d9200 ti: 880078bc task.ti: 880078bc [ 318.527031] RIP: 0010:[] [] __delete_from_page_cache+0x2ec/0x350 [ 318.527031] RSP: 0018:880078bc3c58 EFLAGS: 00010002 [ 318.527031] RAX: 0001 RBX: ea0001338000 RCX: ffec [ 318.527031] RDX: 003ffc01 RSI: 000a RDI: 88007ffe97c0 [ 318.527031] RBP: 880078bc3ca8 R08: 82660f14 R09: [ 318.527031] R10: 8800783d9200 R11: 0001 R12: 880077824980 [ 318.527031] R13: 880077824968 R14: R15: 880077824970 [ 318.527031] FS: 7fe5cff0b700() GS:88007fc0() knlGS: [ 318.527031] CS: 0010 DS: ES: CR0: 80050033 [ 318.527031] CR2: 7fe5cff17000 CR3: 778fb000 CR4: 001407f0 [ 318.527031] Stack: [ 318.527031] 880077824980 880077824980 880077824978 [ 318.527031] 880078bc3ca8 ea0001338000 880077824980 [ 318.527031] 0001 880078bc3cd8 811a758c [ 318.527031] Call Trace: [ 318.527031] [] delete_from_page_cache+0x4c/0x80 [ 318.527031] [] truncate_hugepages+0xfb/0x1d0 [ 318.527031] [] ? inode_wait_for_writeback+0x1e/0x40 [ 318.527031] [] ? __inode_wait_for_writeback+0x6d/0xc0 [ 318.527031] [] hugetlbfs_evict_inode+0x18/0x40 [ 318.527031] [] evict+0xab/0x180 [ 318.527031] [] iput+0x19b/0x200 [ 318.527031] [] do_unlinkat+0x1e9/0x310 [ 318.527031] [] ? ret_from_sys_call+0x24/0x63 [ 318.527031] [] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 318.527031] [] ? trace_hardirqs_on_thunk+0x17/0x19 [ 318.527031] [] SyS_unlink+0x16/0x20 [ 318.527031] [] system_call_fastpath+0x12/0x17 [ 318.527031] Code: 00 00 48 83 f8 01 19 c0 25 01 fe ff ff 05 00 02 00 00 39 d0 0f 8e 92 fe ff ff 48 63 c2 48 c1 e0 06 48 01 d8 8b 40 18 85 c0 78 c4 <0f> 0b 48 8b 43 30 e9 7b fd ff ff e8 aa e6 5f 00 80 3d c0 d8 b5 [ 318.527031] RIP [] __delete_from_page_cache+0x2ec/0x350 [ 318.527031] RSP [ 318.527031] ---[ end trace 4595a8f53048ea33 ]--- [ 320.670687] [ cut here ] And: [ 4309.839683] page:ea000640 count:0 mapcount:0 mapping: index:0x0 compound_mapcount: 0 [ 4309.842296] flags: 0x1ffc008000(tail) [ 4309.843253] page dumped because: VM_BUG_ON_PAGE(PageTail(page)) [ 4309.845357] [ cut here ] [ 4309.846306] kernel BUG at include/linux/page-flags.h:438! [ 4309.846306] invalid opcode: [#3] SMP [ 4309.846306] Modules linked in: binfmt_misc loop ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security ip6table_raw
Re: [PATCH v3 4/9] mtd: pxa3xx_nand: rework timings setup
Thomas, On Thu, Mar 05, 2015 at 01:50:23PM +0100, Thomas Petazzoni wrote: > On Thu, 5 Mar 2015 12:31:20 +0100, Antoine Tenart wrote: > > Use the nand framework helpers: onfi_get_async_timing_mode() and > > onfi_async_timing_mode_to_sdr_timings() to retrieve the timing > > configuration. Then update the pxa3xx timing setup function to use the > > timing configuration retrieved. > > > > Signed-off-by: Antoine Tenart > > --- > > drivers/mtd/nand/pxa3xx_nand.c| 101 > > ++ > > include/linux/platform_data/mtd-nand-pxa3xx.h | 2 - > > 2 files changed, 69 insertions(+), 34 deletions(-) > > After this commit, the pxa3xx_nand_timing structure type is no longer > used as far as I understand. So maybe it can be removed from > include/linux/platform_data/mtd-nand-pxa3xx.h ? Right, I'll remove it. Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/9] mtd: pxa3xx_nand: rework timings setup
Dear Antoine Tenart, On Thu, 5 Mar 2015 12:31:20 +0100, Antoine Tenart wrote: > Use the nand framework helpers: onfi_get_async_timing_mode() and > onfi_async_timing_mode_to_sdr_timings() to retrieve the timing > configuration. Then update the pxa3xx timing setup function to use the > timing configuration retrieved. > > Signed-off-by: Antoine Tenart > --- > drivers/mtd/nand/pxa3xx_nand.c| 101 > ++ > include/linux/platform_data/mtd-nand-pxa3xx.h | 2 - > 2 files changed, 69 insertions(+), 34 deletions(-) After this commit, the pxa3xx_nand_timing structure type is no longer used as far as I understand. So maybe it can be removed from include/linux/platform_data/mtd-nand-pxa3xx.h ? Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: STi: Add STiH410 SoC support
This patch adds support to STiH410 SoC.
Signed-off-by: Fabrice Gasnier
---
Documentation/devicetree/bindings/arm/sti.txt | 4
arch/arm/mach-sti/board-dt.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sti.txt
b/Documentation/devicetree/bindings/arm/sti.txt
index d70ec35..8d27f6b 100644
--- a/Documentation/devicetree/bindings/arm/sti.txt
+++ b/Documentation/devicetree/bindings/arm/sti.txt
@@ -13,6 +13,10 @@ Boards with the ST STiH407 SoC shall have the following
properties:
Required root node property:
compatible = "st,stih407";
+Boards with the ST STiH410 SoC shall have the following properties:
+Required root node property:
+compatible = "st,stih410";
+
Boards with the ST STiH418 SoC shall have the following properties:
Required root node property:
compatible = "st,stih418";
diff --git a/arch/arm/mach-sti/board-dt.c b/arch/arm/mach-sti/board-dt.c
index b067390..b373aca 100644
--- a/arch/arm/mach-sti/board-dt.c
+++ b/arch/arm/mach-sti/board-dt.c
@@ -18,6 +18,7 @@ static const char *stih41x_dt_match[] __initdata = {
"st,stih415",
"st,stih416",
"st,stih407",
+ "st,stih410",
"st,stih418",
NULL
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Bypass legacy PIC and PIT on ACPI hardware reduced platform
On 2015/3/5 19:36, Ingo Molnar wrote:
>
> * Li, Aubrey wrote:
>
>> On 2015/3/5 4:11, Ingo Molnar wrote:
>>>
>>> * Arjan van de Ven wrote:
>>>
On 3/4/2015 1:50 AM, Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
>>>
>>> Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
>>> is a mistake.
>>
>> ideally, the presence of that flag in the firmware table will clear/set
>> more global settings,
>> for example, having that flag should cause the 8042 input code to not
>> probe for the 8042.
>>
>> for interrupts, there really ought to be a "apic first/only" mode, which
>> is then used on
>> all modern systems (not just hw reduced).
>
> Do we need some sort of platform-specific querying interfaces now too,
> similar to cpu_has()? I.e., platform_has()...
>
> if (platform_has(X86_PLATFORM_REDUCED_HW))
> do stuff..
more like
platform_has(X86_PLATFORM_PIT)
etc, one for each legacy io item
>>>
>>> Precisely. The main problem is the generic, 'lumps everything
>>> together' nature of the acpi_gbl_reduced_hardware flag.
>>>
>>> (Like the big kernel lock lumped together all sorts of locking rules
>>> and semantics.)
>>>
>>> Properly split out, feature-ish or driver-ish interfaces for PIT and
>>> other legacy details are the proper approach to 'turn them off'.
>>>
>>> - x86_platform is a function pointer driven, driver-ish interface.
>>>
>>> - platform_has(X86_PLATFORM_IT) is a flag driven, feature-flag-ish
>>>interface.
>>>
>>> Both are fine - for something as separate as the PIT (or the PIC)
>>> it might make more sense to go towards a 'driver' interface
>>> though, as modern drivers are (and will be) much different from
>>> the legacy PIT.
>>>
>>> Whichever method is used, low level platforms can just switch them
>>> on/off in their enumeration/detection routines, while the generic
>>> code will have them enabled by default.
>>
>> Whichever method is used, we will face a problem how to determine
>> PIT exists or not.
>>
>> When we enabled Bay Trail-T platform at the beginning, we were
>> trying to make the code as generic as possible, and it works
>> properly up to now. So we don't have a SUBARCH like
>> X86_SUBARCH_INTEL_MID to use the platform specific functions. And
>> for now I'm not quite sure it's a good idea to create one.
>>
>> If we make it as a flag driven, I don't know there is a flag in
>> firmware better than ACPI HW reduced flag(Of course it's not good
>> enough to cover all the cases). Or if we want to use platform info
>> to turn on/off this flag, we'll have to maintain a platform list,
>> which may be longer and more complicated than worth doing that.
>
> Well, it's not nearly so difficult, because you already have a
> platform flag: acpi_gbl_reduced_hardware.
>
> What I object against is to infest generic codepaths with unreadable,
> unrobust crap like:
>
> + if (acpi_gbl_reduced_hardware) {
> + pr_info("Using NULL legacy PIC\n");
> + legacy_pic = _legacy_pic;
> + } else
> + legacy_pic->init(0);
>
> To solve that, add a small (early) init function (say
> 'x86_reduced_hw_init()') that sets up the right driver
> selections if acpi_gbl_reduced_hardware is set:
>
> - in x86_reduced_hw_init() set 'legacy_pic' to 'null_legacy_pic'
>
> - clean up 'global_clock_event' handling: instead of a global
>variable, move its management into x86_platform_ops::get_clockevent()
>and set the method to hpet/pit/abp/etc. specific handlers that
>return the right clockevent device.
>
> - in your x86_reduced_hw_init() function add the hpet clockevent
>device to x86_platform_ops::get_clockevent, overriding the default
>PIT.
>
> - in x86_reduced_hw_init() set pm_power_off.
>
> - set 'reboot_type' and remove the acpi_gbl_reduced_hardware hack
>from efi_reboot_required().
>
I'll do more investigation above items but I want to leave at least
these two as the quirk today unless I am convinced I can do that because
from my understanding, UEFI runtime services should not be supported in
reduced hw mode.
> etc.
>
> Just keep the generic init codepaths free of those random selections
> based on global flags, okay?
>
Agree.
Thanks,
-Aubrey
> Thanks,
>
> Ingo
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH mmotm] x86, mm: ioremap_pud_capable can be static
Signed-off-by: Fengguang Wu
---
ioremap.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/ioremap.c b/lib/ioremap.c
index 3055ada..1634c53 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -14,9 +14,9 @@
#include
#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
-int __read_mostly ioremap_pud_capable;
-int __read_mostly ioremap_pmd_capable;
-int __read_mostly ioremap_huge_disabled;
+static int __read_mostly ioremap_pud_capable;
+static int __read_mostly ioremap_pmd_capable;
+static int __read_mostly ioremap_huge_disabled;
static int __init set_nohugeiomap(char *str)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[mmotm:master 126/298] lib/ioremap.c:17:19: sparse: symbol 'ioremap_pud_capable' was not declared. Should it be static?
tree: git://git.cmpxchg.org/linux-mmotm.git master head: fe8eec967fb5db169b876720a6e0cced026173b6 commit: e4dc2631d6de08fe1ee5421944a71c7c89ed1d90 [126/298] x86, mm: support huge KVA mappings on x86 reproduce: # apt-get install sparse git checkout e4dc2631d6de08fe1ee5421944a71c7c89ed1d90 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> lib/ioremap.c:17:19: sparse: symbol 'ioremap_pud_capable' was not declared. >> Should it be static? >> lib/ioremap.c:18:19: sparse: symbol 'ioremap_pmd_capable' was not declared. >> Should it be static? >> lib/ioremap.c:19:19: sparse: symbol 'ioremap_huge_disabled' was not >> declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] Freescale DPAA FMan FLIB(s)
On 03/05/15 00:45, Emil Medve wrote: From: Igal Liberman The Freescale Data Path Acceleration Architecture (DPAA) is a set of hardware components on specific QorIQ P and T series multicore processors. This architecture provides the infrastructure to support simplified sharing of networking interfaces and accelerators by multiple CPU cores, and the accelerators themselves. One of the DPAA accelerators is the Frame Manager (FMan), which combines the Ethernet network interfaces with packet distribution logic to provide intelligent distribution and queuing decisions for incoming traffic at line rate. This patch presents the FMan Foundation Libraries (FLIB) headers. The FMan FLIB suite adds basic support for the DPAA FMan hardware register access. The FMan FLIB suite is used in Freescale's SDK Releases. Is this intended to merely enable your sdk? How are you planning to add support for your classifiers, queue schedulers etc? Is that a patch on top of this or it is something that sits on user space? cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] make automatic device_id generation possible
On (03/05/15 13:10), Karel Zak wrote: > > > we upgraded our scripts but landed some bugs there? it's up to particular > > > implementation. in your example, I assume, someone used zram with > > > num_devices >= 1000? > > > that's impossible. current num_devices limitation is 32. and uid-s start > > > from 1000. [..] > Why 1000? > > The UID_MIN and UID_MAX is nothing strictly defined, it's just option > in /etc/login.defs. I guess it's nothing unusually to have system > where UID_MIN is 500 :-) > I meant on my system min is 1000 (don't know if anyone change min value for any reason of his own), and current num_devices limit is 32, anyway. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: rt5033: MFD_RT5033 needs to select REGMAP_IRQ
On Thu, 05 Mar 2015, Artem Savkov wrote: > Since commit 0b2712585(linux-next.git) this driver uses regmap_irq and so > needs > to select REGMAP_IRQ. > > This fixes the following compilation errors: > ERROR: "regmap_irq_get_domain" [drivers/mfd/rt5033.ko] undefined! > ERROR: "regmap_add_irq_chip" [drivers/mfd/rt5033.ko] undefined! > > Signed-off-by: Artem Savkov > --- > drivers/mfd/Kconfig | 1 + > 1 file changed, 1 insertion(+) Applied, thanks. > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index f8ef77d9a..f49f404 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -680,6 +680,7 @@ config MFD_RT5033 > depends on I2C=y > select MFD_CORE > select REGMAP_I2C > + select REGMAP_IRQ > help > This driver provides for the Richtek RT5033 Power Management IC, > which includes the I2C driver and the Core APIs. This driver provides -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0-rc1 v17 5/6] x86/nmi: Use common printk functions
On Thu, 2015-03-05 at 01:54 +0100, Ingo Molnar wrote: > * Daniel Thompson wrote: > > > Much of the code sitting in arch/x86/kernel/apic/hw_nmi.c to support > > safe all-cpu backtracing from NMI has been copied to printk.c to > > make it accessible to other architectures. > > > > Port the x86 NMI backtrace to the generic code. > > Is there any difference between the generic and the x86 code as they > stand today? Shouldn't be any user observable change but there are some changes, mostly due to review comments. 1. The seq_buf structures are initialized at boot and *after* they are consumed (originally they were initialized just before use). 2. The generic code doesn't maintain an equivalent of backtrace_mask (which was essentially a copy of cpus_online made when backtracing was requested) and instead iterates using for_each_possible_cpu() to initialize and dump the seq_buf:s. Daniel. PS The main piece that git code motion tracking should follow if I squashed the generic and x86 patches together would be nmi_vprintk(). I suspect most of the rest would be missed as the code copies is in pretty small fragments. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fixed Microblaze syscall error recovery for invalid syscall IDs.
On 02/23/2015 04:35 PM, jamie.gars...@york.ac.uk wrote: > From: Jamie Garside > > This patch fixes two bugs in the Microblaze syscall trap handler when an > invalid > syscall ID is used. > > First, the range check on line 351 only checks for syscall IDs greater than > __NR_syscalls. A negative syscall ID (either passed to `syscall()` or as > returned > by `do_syscall_trace_enter()` on error) will still satisfy this test and cause > the Linux kernel to access an invalid memory location and cause a kernel oops. > This has been fixed by also checking for r12 < 0. > > Secondly, the current error recovery at line 378 returns using the wrong > register > (r15 instead of r14) and does not restore the previous stack state. This has > been > fixed by invoking `ret_from_trap` on error, setting r3 to `-ENOSYS`, similar > to > what would happen when calling a valid syscall. > > Signed-off-by: Jamie Garside > --- > arch/microblaze/kernel/entry.S | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/microblaze/kernel/entry.S b/arch/microblaze/kernel/entry.S > index 0536bc0..101f13c 100644 > --- a/arch/microblaze/kernel/entry.S > +++ b/arch/microblaze/kernel/entry.S > @@ -348,8 +348,9 @@ C_ENTRY(_user_exception): > * The LP register should point to the location where the called function > * should return. [note that MAKE_SYS_CALL uses label 1] */ > /* See if the system call number is valid */ > +bltir12, 5f > addir11, r12, -__NR_syscalls; > - bgeir11,5f; > + bgeir11, 5f; > /* Figure out which function to use for this system call. */ > /* Note Microblaze barrel shift is optional, so don't rely on it */ > add r12, r12, r12; /* convert num -> ptr */ > @@ -375,7 +376,7 @@ C_ENTRY(_user_exception): > > /* The syscall number is invalid, return an error. */ > 5: > - rtsdr15, 8; /* looks like a normal subroutine return */ > +braid ret_from_trap > addir3, r0, -ENOSYS; > > /* Entry point used to return from a syscall/trap */ > Looks reasonable and I have also tested it. I have fixed subject, coding style and I have create one more patch to fix that coding style issue. The patches should be in linux-next. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
[PATCH v3 3/9] mtd: pxa3xx_nand: add a default chunk size
When keeping the configuration set by the bootloader (by using
the marvell,nand-keep-config property), the pxa3xx_nand_detect_config()
function is called and set the chunk size to 512 as a default value if
NDCR_PAGE_SZ is not set.
In the other case, when not keeping the bootloader configuration, no
chunk size is set. Fix this by adding a default chunk size of 512.
Signed-off-by: Antoine Tenart
---
drivers/mtd/nand/pxa3xx_nand.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 55fce9527c2e..dc0edbc406bb 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -1429,6 +1429,9 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
if (pdata->keep_config && !pxa3xx_nand_detect_config(info))
goto KEEP_CONFIG;
+ /* Set a default chunk size */
+ info->chunk_size = 512;
+
ret = pxa3xx_nand_sensing(info);
if (ret) {
dev_info(>pdev->dev, "There is no chip on cs %d!\n",
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/9] ARM: berlin: add nand support
Hi all, This series introduces the support for the Marvell Berlin nand controller. It is based on top of v4.0-rc1 and was tested on the Marvell Berlin BG2Q DMP board. The support is added into the existing pxa3xx nand controller. Some additions were done in order to get this controller working: - Support for a non mandatory ECC clock has been added. - The Berlin nand controller needs to poll the status register. - Sequences of commands are quite different in order to perform write operation. Thanks! Antoine Changes since v2: - Reworked the timings setup - Added a explanation in the default chunk size commit - Ensured commit 4/10 was useless and removed it - Fixed typos, cosmetic Changes since v1: - Added a fallback to NULL when looking for the 'nfc' clock - Added the clocks in the bindings documentation - Reworked the DT - Removed non needed RNDOUT command - Used the standard RESET command - Fixed the flash type matching order - Remove all non tested flash types (only one left) - Added a check to explicitly not support nand chips with small pages - Remove useless checks for clocks in the probing function - Various clean up Antoine Tenart (9): mtd: pxa3xx_nand: add a non mandatory ECC clock Documentation: bindings: document the clocks for pxa3xx-nand mtd: pxa3xx_nand: add a default chunk size mtd: pxa3xx_nand: rework timings setup mtd: pxa3xx_nand: add support for the Marvell Berlin nand controller Documentation: bindings: add the Berlin nand controller compatible mtd: nand: let Marvell Berlin SoCs select the pxa3xx driver ARM: berlin: add BG2Q node for the nand ARM: berlin: enable flash on the BG2Q DMP .../devicetree/bindings/mtd/pxa3xx-nand.txt| 5 + arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 25 ++ arch/arm/boot/dts/berlin2q.dtsi| 13 + drivers/mtd/nand/Kconfig | 2 +- drivers/mtd/nand/pxa3xx_nand.c | 349 + include/linux/platform_data/mtd-nand-pxa3xx.h | 2 - 6 files changed, 332 insertions(+), 64 deletions(-) -- 2.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/9] mtd: pxa3xx_nand: add a non mandatory ECC clock
Some controllers (as the coming Berlin nand controller) need to enable
an ECC clock. Add support for this clock in the pxa3xx nand driver, and
leave it as non mandatory.
Signed-off-by: Antoine Tenart
---
drivers/mtd/nand/pxa3xx_nand.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index d00ac392d1c4..55fce9527c2e 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -180,7 +180,7 @@ struct pxa3xx_nand_info {
struct nand_hw_control controller;
struct platform_device *pdev;
- struct clk *clk;
+ struct clk *clk, *ecc_clk;
void __iomem*mmio_base;
unsigned long mmio_phys;
struct completion cmd_complete, dev_ready;
@@ -1608,15 +1608,26 @@ static int alloc_nand_resource(struct platform_device
*pdev)
spin_lock_init(>controller->lock);
init_waitqueue_head(>controller->wq);
- info->clk = devm_clk_get(>dev, NULL);
+ info->clk = devm_clk_get(>dev, "nfc");
if (IS_ERR(info->clk)) {
- dev_err(>dev, "failed to get nand clock\n");
- return PTR_ERR(info->clk);
+ info->clk = devm_clk_get(>dev, NULL);
+
+ if (IS_ERR(info->clk)) {
+ dev_err(>dev, "failed to get nand clock\n");
+ return PTR_ERR(info->clk);
+ }
}
ret = clk_prepare_enable(info->clk);
if (ret < 0)
return ret;
+ info->ecc_clk = devm_clk_get(>dev, "ecc");
+ if (!IS_ERR(info->ecc_clk)) {
+ ret = clk_prepare_enable(info->ecc_clk);
+ if (ret < 0)
+ goto fail_disable_clk;
+ }
+
if (use_dma) {
/*
* This is a dirty hack to make this driver work from
@@ -1633,7 +1644,7 @@ static int alloc_nand_resource(struct platform_device
*pdev)
dev_err(>dev,
"no resource defined for data DMA\n");
ret = -ENXIO;
- goto fail_disable_clk;
+ goto fail_disable_ecc_clk;
}
info->drcmr_dat = r->start;
@@ -1642,7 +1653,7 @@ static int alloc_nand_resource(struct platform_device
*pdev)
dev_err(>dev,
"no resource defined for cmd DMA\n");
ret = -ENXIO;
- goto fail_disable_clk;
+ goto fail_disable_ecc_clk;
}
info->drcmr_cmd = r->start;
}
@@ -1652,14 +1663,14 @@ static int alloc_nand_resource(struct platform_device
*pdev)
if (irq < 0) {
dev_err(>dev, "no IRQ resource defined\n");
ret = -ENXIO;
- goto fail_disable_clk;
+ goto fail_disable_ecc_clk;
}
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
info->mmio_base = devm_ioremap_resource(>dev, r);
if (IS_ERR(info->mmio_base)) {
ret = PTR_ERR(info->mmio_base);
- goto fail_disable_clk;
+ goto fail_disable_ecc_clk;
}
info->mmio_phys = r->start;
@@ -1668,7 +1679,7 @@ static int alloc_nand_resource(struct platform_device
*pdev)
info->data_buff = kmalloc(info->buf_size, GFP_KERNEL);
if (info->data_buff == NULL) {
ret = -ENOMEM;
- goto fail_disable_clk;
+ goto fail_disable_ecc_clk;
}
/* initialize all interrupts to be disabled */
@@ -1687,6 +1698,8 @@ static int alloc_nand_resource(struct platform_device
*pdev)
fail_free_buf:
free_irq(irq, info);
kfree(info->data_buff);
+fail_disable_ecc_clk:
+ clk_disable_unprepare(info->ecc_clk);
fail_disable_clk:
clk_disable_unprepare(info->clk);
return ret;
@@ -1709,6 +1722,7 @@ static int pxa3xx_nand_remove(struct platform_device
*pdev)
pxa3xx_nand_free_buff(info);
clk_disable_unprepare(info->clk);
+ clk_disable_unprepare(info->ecc_clk);
for (cs = 0; cs < pdata->num_cs; cs++)
nand_release(info->host[cs]->mtd);
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"
On Wed, Mar 04, 2015 at 05:29:14PM +0100, Lino Sanfilippo wrote: > On 04.03.2015 15:35, Dave Martin wrote: > > > > >Try > > > >rm drivers/clk/mvebu/kirkwood.o > >make ARCH=arm KBUILD_CFLAGS_KERNEL=-save-temps drivers/clk/mvebu/kirkwood.o > > > >(abuse of KBUILD_CFLAGS_KERNEL here, but it's empty by default, and > >I'm too lazy to copy-paste command lines...) > > > > > >The compiler will split out the compiled assembly code in kirkwood.s: > > > >Look for ".align" directives between the start of the affected section > >and the start of the next section (next .section directive). > > > >Here, we just have .align 2, which is the expected correct value > >(i.e., align __of_table_mv88f6180_clk on a 2^2 = 4 byte boundary). > > > >A different value here may indicate a bug in the compiler, because > >you observed that gcc _thinks_ that __alignof__ is 4 for the struct > >in this section even in the failing case. > > Ok, this is the result for the assembly: > > .section__clk_of_table,"a",%progbits > .align 3 > .type __of_table_mv88f6180_clk, %object > .size __of_table_mv88f6180_clk, 196 > __of_table_mv88f6180_clk: > .space 64 [...] > Very interesting. It shows an .align 3 which explains alignment on > 8 byte boundaries: > > > c07630f8 T __clk_of_table > c07630f8 t __of_table_fixed_factor_clk > c07630f8 T __stop_kprobe_blacklist > c07631c0 t __of_table_fixed_clk > c0763288 t __of_table_gpio_gate_clk > c0763350 t __of_table_mv88f6180_clk > > So this is indeed a compiler bug, right? It certainly looks like the compiler is causing the issue somehow. Whether this is a bug, a bug-like feature, a configuration issue, or a combination of these is not clear. If you know where to find the toolchain source, it might be worth taking a look. Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] make automatic device_id generation possible
On (03/05/15 13:02), Karel Zak wrote: > > hm, you never know what people can come up with. that's probably the > > strongest support argument I can provide. I wish there was something > > like - my friend Mike has a "device /dev/zram1 is always swap device, > > device /dev/zram$(id -u) is a per-user zram device (he finds it useful, > > I have doubts that promise stable device names is good idea. The usual > way is to care about FS/SWAP identifiers (LABEL=, or UUID=), and for > example udevd should be able to create a stable /dev/disk/by-* > symlinks. > > So for your friend Mike is better to have UUID= in /etc/fstab and > force mkswap or mkfs to use still the same UUID. +1 for removal from Karel. thanks. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/9] Documentation: bindings: document the clocks for pxa3xx-nand
The pxa3xx nand driver requires at least one clock to probe correctly. A second one, named 'ecc' can be specified if needed. Add the corresponding documentation. Signed-off-by: Antoine Tenart --- Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt index de8b517a5521..ecd1fc071f81 100644 --- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt +++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt @@ -8,6 +8,8 @@ Required properties: - reg:The register base for the controller - interrupts: The interrupt to map - #address-cells: Set to <1> if the node includes partitions + - clocks: A phandle to the clocks + - clock-names:'nfc' and 'ecc'. The 'nfc' clock is mandatory. Optional properties: @@ -32,6 +34,8 @@ Example: compatible = "marvell,pxa3xx-nand"; reg = <0x4310 90>; interrupts = <45>; + clocks = < 11>; + clock-names = "nfc"; #address-cells = <1>; marvell,nand-enable-arbiter; -- 2.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 9/9] ARM: berlin: enable flash on the BG2Q DMP
The BG2Q DMP has a nand controller. Add the corresponding node, but do
not enable it by default because the nand is only available on some BG2Q
DMP.
Signed-off-by: Antoine Tenart
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index a98ac1bd8f65..4157258a6fb0 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -112,3 +112,28 @@
_phy {
status = "okay";
};
+
+ {
+ nand_pmux: nand-pmux {
+ groups = "G0", "G1";
+ function = "nand";
+ };
+};
+
+ {
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
+
+ marvell,nand-enable-arbiter;
+ nand-ecc-strength = <48>;
+ nand-ecc-step-size = <1024>;
+
+ num-cs = <1>;
+
+ /*
+* Two kinds of BG2Q DMP are available: one with emmc and
+* one with a nand. The latter is not widespread. Because
+* of this, disable the nand by default.
+*/
+ status = "disabled";
+};
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/9] mtd: pxa3xx_nand: rework timings setup
Use the nand framework helpers: onfi_get_async_timing_mode() and
onfi_async_timing_mode_to_sdr_timings() to retrieve the timing
configuration. Then update the pxa3xx timing setup function to use the
timing configuration retrieved.
Signed-off-by: Antoine Tenart
---
drivers/mtd/nand/pxa3xx_nand.c| 101 ++
include/linux/platform_data/mtd-nand-pxa3xx.h | 2 -
2 files changed, 69 insertions(+), 34 deletions(-)
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index dc0edbc406bb..4bcfb4cf6fee 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -243,23 +243,16 @@ static bool use_dma = 1;
module_param(use_dma, bool, 0444);
MODULE_PARM_DESC(use_dma, "enable DMA for data transferring to/from NAND HW");
-static struct pxa3xx_nand_timing timing[] = {
- { 40, 80, 60, 100, 80, 100, 9, 400, 40, },
- { 10, 0, 20, 40, 30, 40, 11123, 110, 10, },
- { 10, 25, 15, 25, 15, 30, 25000, 60, 10, },
- { 10, 35, 15, 25, 15, 25, 25000, 60, 10, },
-};
-
static struct pxa3xx_nand_flash builtin_flash_types[] = {
-{ "DEFAULT FLASH", 0, 0, 2048, 8, 8,0, [0] },
-{ "64MiB 16-bit", 0x46ec, 32, 512, 16, 16, 4096, [1] },
-{ "256MiB 8-bit", 0xdaec, 64, 2048, 8, 8, 2048, [1] },
-{ "4GiB 8-bit",0xd7ec, 128, 4096, 8, 8, 8192, [1] },
-{ "128MiB 8-bit", 0xa12c, 64, 2048, 8, 8, 1024, [2] },
-{ "128MiB 16-bit", 0xb12c, 64, 2048, 16, 16, 1024, [2] },
-{ "512MiB 8-bit", 0xdc2c, 64, 2048, 8, 8, 4096, [2] },
-{ "512MiB 16-bit", 0xcc2c, 64, 2048, 16, 16, 4096, [2] },
-{ "256MiB 16-bit", 0xba20, 64, 2048, 16, 16, 2048, [3] },
+{ "DEFAULT FLASH", 0, 0, 2048, 8, 8,0 },
+{ "64MiB 16-bit", 0x46ec, 32, 512, 16, 16, 4096 },
+{ "256MiB 8-bit", 0xdaec, 64, 2048, 8, 8, 2048 },
+{ "4GiB 8-bit",0xd7ec, 128, 4096, 8, 8, 8192 },
+{ "128MiB 8-bit", 0xa12c, 64, 2048, 8, 8, 1024 },
+{ "128MiB 16-bit", 0xb12c, 64, 2048, 16, 16, 1024 },
+{ "512MiB 8-bit", 0xdc2c, 64, 2048, 8, 8, 4096 },
+{ "512MiB 16-bit", 0xcc2c, 64, 2048, 16, 16, 4096 },
+{ "256MiB 16-bit", 0xba20, 64, 2048, 16, 16, 2048 },
};
static u8 bbt_pattern[] = {'M', 'V', 'B', 'b', 't', '0' };
@@ -361,22 +354,31 @@ pxa3xx_nand_get_variant(struct platform_device *pdev)
}
static void pxa3xx_nand_set_timing(struct pxa3xx_nand_host *host,
- const struct pxa3xx_nand_timing *t)
+ const struct nand_sdr_timings *t)
{
struct pxa3xx_nand_info *info = host->info_data;
unsigned long nand_clk = clk_get_rate(info->clk);
uint32_t ndtr0, ndtr1;
-
- ndtr0 = NDTR0_tCH(ns2cycle(t->tCH, nand_clk)) |
- NDTR0_tCS(ns2cycle(t->tCS, nand_clk)) |
- NDTR0_tWH(ns2cycle(t->tWH, nand_clk)) |
- NDTR0_tWP(ns2cycle(t->tWP, nand_clk)) |
- NDTR0_tRH(ns2cycle(t->tRH, nand_clk)) |
- NDTR0_tRP(ns2cycle(t->tRP, nand_clk));
-
- ndtr1 = NDTR1_tR(ns2cycle(t->tR, nand_clk)) |
- NDTR1_tWHR(ns2cycle(t->tWHR, nand_clk)) |
- NDTR1_tAR(ns2cycle(t->tAR, nand_clk));
+ u32 tCH_min = DIV_ROUND_UP(t->tCH_min, 1000);
+ u32 tCS_min = DIV_ROUND_UP(t->tCS_min, 1000);
+ u32 tWH_min = DIV_ROUND_UP(t->tWH_min, 1000);
+ u32 tWP_min = DIV_ROUND_UP(t->tWP_min, 1000);
+ u32 tREH_min = DIV_ROUND_UP(t->tREH_min, 1000);
+ u32 tRP_min = DIV_ROUND_UP(t->tRP_min, 1000);
+ u32 tRST_max = DIV_ROUND_UP_ULL(t->tRST_max, 1000);
+ u32 tWHR_min = DIV_ROUND_UP(t->tWHR_min, 1000);
+ u32 tAR_min = DIV_ROUND_UP(t->tAR_min, 1000);
+
+ ndtr0 = NDTR0_tCH(ns2cycle(tCH_min, nand_clk)) |
+ NDTR0_tCS(ns2cycle(tCS_min, nand_clk)) |
+ NDTR0_tWH(ns2cycle(tWH_min, nand_clk)) |
+ NDTR0_tWP(ns2cycle(tWP_min, nand_clk)) |
+ NDTR0_tRH(ns2cycle(tREH_min, nand_clk)) |
+ NDTR0_tRP(ns2cycle(tRP_min, nand_clk));
+
+ ndtr1 = NDTR1_tR(ns2cycle(tRST_max, nand_clk)) |
+ NDTR1_tWHR(ns2cycle(tWHR_min, nand_clk)) |
+ NDTR1_tAR(ns2cycle(tAR_min, nand_clk));
info->ndtr0cs0 = ndtr0;
info->ndtr1cs0 = ndtr1;
@@ -384,6 +386,29 @@ static void pxa3xx_nand_set_timing(struct pxa3xx_nand_host
*host,
nand_writel(info, NDTR1CS0, ndtr1);
}
+static int pxa3xx_nand_init_timings(struct pxa3xx_nand_host *host)
+{
+ const struct nand_sdr_timings *timings;
+ int mode;
+
+ mode = onfi_get_async_timing_mode(>chip);
+ if (mode == ONFI_TIMING_MODE_UNKNOWN) {
+ mode = host->chip.onfi_timing_mode_default;
+ } else {
+ mode = fls(mode) - 1;
+ if (mode < 0)
+ mode = 0;
+ }
+
+ timings = onfi_async_timing_mode_to_sdr_timings(mode);
+ if (IS_ERR(timings))
+ return PTR_ERR(timings);
+
+
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
On Thu, Mar 05, 2015 at 05:38:23AM +, Chanwoo Choi wrote:
> This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
> Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
> PSCI (Power State Coordination Interface) v0.1.
>
> This patch includes following dt node to support Exynos5433 SoC:
> 1. Octa core for big.LITTLE architecture
> - Cortex-A53 LITTLE Quad-core
> - Cortex-A57 big Quad-core
> - Support PSCI v0.1
[...]
> + psci {
> + compatible = "arm,psci";
> + method = "smc";
> + cpu_off = <0x8402>;
> + cpu_on = <0xC403>;
> + };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
I take it CPUs boot at EL2?
[...]
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <1 13 0xff04>,
> +<1 14 0xff04>,
> +<1 11 0xff04>,
> +<1 10 0xff04>;
> + };
The timer node should be moved under the root node. It doesn't live on
the bus; it's a component of the CPU.
Thanks,
Mark.
[1] https://lkml.org/lkml/2014/12/2/413
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 7/9] mtd: nand: let Marvell Berlin SoCs select the pxa3xx driver
Marvell Berlin nand controller support has been added in the pxa3xx nand driver. Let these SoCs select the driver. Signed-off-by: Antoine Tenart --- drivers/mtd/nand/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 5b76a173cd95..cfe7f223f48f 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -332,7 +332,7 @@ config MTD_NAND_ATMEL config MTD_NAND_PXA3xx tristate "NAND support on PXA3xx and Armada 370/XP" - depends on PXA3xx || ARCH_MMP || PLAT_ORION + depends on PXA3xx || ARCH_MMP || PLAT_ORION || ARCH_BERLIN help This enables the driver for the NAND flash device found on PXA3xx processors (NFCv1) and also on Armada 370/XP (NFCv2). -- 2.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/9] Documentation: bindings: add the Berlin nand controller compatible
The Berlin nand controller support was introduced using the existing pxa3xx nand driver. Add the Berlin specific compatible into the documentation. Signed-off-by: Antoine Tenart --- Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt index ecd1fc071f81..f33ee0aa0a2e 100644 --- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt +++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt @@ -5,6 +5,7 @@ Required properties: - compatible: Should be set to one of the following: marvell,pxa3xx-nand marvell,armada370-nand + marvell,berlin2-nand - reg:The register base for the controller - interrupts: The interrupt to map - #address-cells: Set to <1> if the node includes partitions -- 2.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/9] mtd: pxa3xx_nand: add support for the Marvell Berlin nand controller
The nand controller on Marvell Berlin SoC reuse the pxa3xx nand driver
as it quite close. The process of sending commands can be compared to
the one of the Marvell armada 370: read and write commands are done in
chunks.
But the Berlin nand controller has some other specificities which
require some modifications of the pxa3xx nand driver:
- there are no IRQ available so we need to poll the status register: we
have to use our own cmdfunc Berlin function, and early on the probing
function.
- PAGEPROG are very different from the one used in the pxa3xx driver,
so we're using a specific process for this one
- the SEQIN command is equivalent to a READ0 command
Signed-off-by: Antoine Tenart
---
drivers/mtd/nand/pxa3xx_nand.c | 215 +
1 file changed, 194 insertions(+), 21 deletions(-)
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 4bcfb4cf6fee..983c13c80c55 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -109,6 +109,8 @@
#define NDCB0_EXT_CMD_TYPE(x) (((x) << 29) & NDCB0_EXT_CMD_TYPE_MASK)
#define NDCB0_CMD_TYPE_MASK(0x7 << 21)
#define NDCB0_CMD_TYPE(x) (((x) << 21) & NDCB0_CMD_TYPE_MASK)
+#define NDCB0_CMD_XTYPE_MASK (0x7 << 29)
+#define NDCB0_CMD_XTYPE(x) (((x) << 29) & NDCB0_CMD_XTYPE_MASK)
#define NDCB0_NC (0x1 << 20)
#define NDCB0_DBC (0x1 << 19)
#define NDCB0_ADDR_CYC_MASK(0x7 << 16)
@@ -117,13 +119,15 @@
#define NDCB0_CMD1_MASK(0xff)
#define NDCB0_ADDR_CYC_SHIFT (16)
-#define EXT_CMD_TYPE_DISPATCH 6 /* Command dispatch */
-#define EXT_CMD_TYPE_NAKED_RW 5 /* Naked read or Naked write */
-#define EXT_CMD_TYPE_READ 4 /* Read */
-#define EXT_CMD_TYPE_DISP_WR 4 /* Command dispatch with write */
-#define EXT_CMD_TYPE_FINAL 3 /* Final command */
-#define EXT_CMD_TYPE_LAST_RW 1 /* Last naked read/write */
-#define EXT_CMD_TYPE_MONO 0 /* Monolithic read/write */
+#define EXT_CMD_TYPE_LAST_PAGEPROG 8
+#define EXT_CMD_TYPE_CHUNK_PAGEPROG7
+#define EXT_CMD_TYPE_DISPATCH 6 /* Command dispatch */
+#define EXT_CMD_TYPE_NAKED_RW 5 /* Naked read or Naked write */
+#define EXT_CMD_TYPE_READ 4 /* Read */
+#define EXT_CMD_TYPE_DISP_WR 4 /* Command dispatch with write */
+#define EXT_CMD_TYPE_FINAL 3 /* Final command */
+#define EXT_CMD_TYPE_LAST_RW 1 /* Last naked read/write */
+#define EXT_CMD_TYPE_MONO 0 /* Monolithic read/write */
/* macros for registers read/write */
#define nand_writel(info, off, val)\
@@ -158,6 +162,7 @@ enum {
enum pxa3xx_nand_variant {
PXA3XX_NAND_VARIANT_PXA,
PXA3XX_NAND_VARIANT_ARMADA370,
+ PXA3XX_NAND_VARIANT_BERLIN2,
};
struct pxa3xx_nand_host {
@@ -253,6 +258,12 @@ static struct pxa3xx_nand_flash builtin_flash_types[] = {
{ "512MiB 8-bit", 0xdc2c, 64, 2048, 8, 8, 4096 },
{ "512MiB 16-bit", 0xcc2c, 64, 2048, 16, 16, 4096 },
{ "256MiB 16-bit", 0xba20, 64, 2048, 16, 16, 2048 },
+{ }
+};
+
+static struct pxa3xx_nand_flash berlin_builtin_flash_types[] = {
+{ "4GiB 8-bit",0xd7ec, 128, 8192, 8, 8, 4096 },
+{ },
};
static u8 bbt_pattern[] = {'M', 'V', 'B', 'b', 't', '0' };
@@ -313,6 +324,18 @@ static struct nand_ecclayout ecc_layout_4KB_bch8bit = {
.oobfree = { }
};
+static struct nand_ecclayout ecc_layout_oob_128 = {
+ .eccbytes = 48,
+ .eccpos = {
+ 80, 81, 82, 83, 84, 85, 86, 87,
+ 88, 89, 90, 91, 92, 93, 94, 95,
+ 96, 97, 98, 99, 100, 101, 102, 103,
+ 104, 105, 106, 107, 108, 109, 110, 111,
+ 112, 113, 114, 115, 116, 117, 118, 119,
+ 120, 121, 122, 123, 124, 125, 126, 127},
+ .oobfree = { {.offset = 2, .length = 78} }
+};
+
/* Define a default flash type setting serve as flash detecting only */
#define DEFAULT_FLASH_TYPE (_flash_types[0])
@@ -339,6 +362,10 @@ static const struct of_device_id pxa3xx_nand_dt_ids[] = {
.compatible = "marvell,armada370-nand",
.data = (void *)PXA3XX_NAND_VARIANT_ARMADA370,
},
+ {
+ .compatible = "marvell,berlin2-nand",
+ .data = (void *)PXA3XX_NAND_VARIANT_BERLIN2,
+ },
{}
};
MODULE_DEVICE_TABLE(of, pxa3xx_nand_dt_ids);
@@ -670,7 +697,8 @@ static irqreturn_t pxa3xx_nand_irq(int irq, void *devid)
nand_writel(info, NDCB0, info->ndcb2);
/* NDCB3 register is available in NFCv2 (Armada 370/XP SoC) */
- if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
+ if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
+ info->variant == PXA3XX_NAND_VARIANT_BERLIN2)
nand_writel(info, NDCB0, info->ndcb3);
}
@@ -780,6 +808,16 @@ static int prepare_set_command(struct pxa3xx_nand_info
*info, int command,
Re: [PATCH -next 07/12] serial: earlycon: Common log banner for command line and DT
Hi Geert,
On 03/05/2015 07:02 AM, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Wed, Mar 4, 2015 at 6:24 PM, Peter Hurley wrote:
>> --- a/drivers/tty/serial/earlycon.c
>> +++ b/drivers/tty/serial/earlycon.c
>> @@ -69,6 +69,7 @@ static void __init earlycon_init(struct earlycon_device
>> *device,
>> const char *name)
>> {
>> struct console *earlycon = device->con;
>> + struct uart_port *port = >port;
>> const char *s;
>> size_t len;
>>
>> @@ -82,6 +83,16 @@ static void __init earlycon_init(struct earlycon_device
>> *device,
>> len = s - name;
>> strlcpy(earlycon->name, name, min(len + 1, sizeof(earlycon->name)));
>> earlycon->data = _console_dev;
>> +
>> + if (port->iotype == UPIO_MEM || port->iotype == UPIO_MEM32)
>> + pr_info("Early serial console at MMIO%s 0x%llx (options
>> '%s')\n",
>> + (port->iotype == UPIO_MEM32) ? "32" : "",
>> + (unsigned long long)port->mapbase,
>
> I know you're just moving this piece of code around, but mapbase is a
> resource_size_t (it should actually be phys_addr_t, which probably didn't
> exist in 2007), so it should be printed using %pa and passing a reference,
> instead of %llx and using a cast.
Good point.
I could add that fix to the 8/12 patch which adds the earlycon name to the
banner.
I have to respin anyway because of a rebase error that breaks x86 build.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: fsl_ssi: Don't try to round-up for PM divisor calculation
On Wed, Mar 04, 2015 at 09:05:04PM -0800, Nicolin Chen wrote: > According to i.MX6 Series Reference Manual, the formula to calculate > the sys clock is Applied, thanks. signature.asc Description: Digital signature
[PATCH v3 8/9] ARM: berlin: add BG2Q node for the nand
Add a node describing the nand controller of the Marvell Berlin BG2Q
SoC. It uses the pxa3xx nand driver, with a dedicated compatible.
Also add the corresponding pinmuxing configuration.
Signed-off-by: Antoine Tenart
---
arch/arm/boot/dts/berlin2q.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index be5397288d24..aeb3a0ea0540 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -437,6 +437,19 @@
status = "disabled";
};
+ nand0: nand@f0 {
+ compatible = "marvell,berlin2-nand";
+ reg = <0xf0 0x1>;
+ interrupts = ;
+ clocks = < CLKID_NFC>,
+< CLKID_NFC_ECC>;
+ clock-names = "nfc", "ecc";
+
+ #address-cells = <1>;
+
+ status = "disabled";
+ };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: parent/child hierarchy for regulator
On Thu, Mar 05, 2015 at 06:35:36PM +0800, Peter Chen wrote: > Any good ways at code/dts to show parent/child hierarchy for regulator? There's plenty of examples in mainline... > The related regulators at my platforms like below: > PMIC (SWB 5v) --> Switch Chip (GPIO Regulator) --> USB VBUS > PMIC has one 5V regulator (eg, swbst at pfuse), and it is the input > for USB power switch chip, and there are two gpios at this switch > chip to control if 5V is output or not, we register these two gpios as > fixed regulators, currently, if regulator swbst is disabled, the > gpio regulator has no way to know, and cause the vbus voltage is wrong. Can you please clarify why you're registering two fixed voltage regulators for the switch chip and how you're doing that? The picture above looks like you should just have a single regulator there and nothing should care if the either regulator is enabled when querying the parent for its voltage. signature.asc Description: Digital signature
Re: parent/child hierarchy for regulator
Hi Peter, Am 05.03.2015 um 11:35 schrieb Peter Chen: > Hi lists, > > Any good ways at code/dts to show parent/child hierarchy for regulator? > > The related regulators at my platforms like below: > PMIC (SWB 5v) --> Switch Chip (GPIO Regulator) --> USB VBUS > > PMIC has one 5V regulator (eg, swbst at pfuse), and it is the input > for USB power switch chip, and there are two gpios at this switch > chip to control if 5V is output or not, we register these two gpios as > fixed regulators, currently, if regulator swbst is disabled, the > gpio regulator has no way to know, and cause the vbus voltage is wrong. > > Thanks in advance. > i don't have an answer to your question, but do you think of i.MX28 platform? Regards Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/9] ARM: at91: remove unused _matrix.h headers
The matrix headers are not used anymore, remove them. Signed-off-by: Alexandre Belloni --- .../mach-at91/include/mach/at91sam9260_matrix.h| 80 --- .../mach-at91/include/mach/at91sam9261_matrix.h| 64 - .../mach-at91/include/mach/at91sam9263_matrix.h| 129 - .../mach-at91/include/mach/at91sam9g45_matrix.h| 153 - .../mach-at91/include/mach/at91sam9n12_matrix.h| 53 --- .../arm/mach-at91/include/mach/at91sam9rl_matrix.h | 96 - .../arm/mach-at91/include/mach/at91sam9x5_matrix.h | 53 --- 7 files changed, 628 deletions(-) delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9260_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9261_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9263_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9g45_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9n12_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9rl_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9x5_matrix.h diff --git a/arch/arm/mach-at91/include/mach/at91sam9260_matrix.h b/arch/arm/mach-at91/include/mach/at91sam9260_matrix.h deleted file mode 100644 index f459df420629.. --- a/arch/arm/mach-at91/include/mach/at91sam9260_matrix.h +++ /dev/null @@ -1,80 +0,0 @@ -/* - * arch/arm/mach-at91/include/mach/at91sam9260_matrix.h - * - * Copyright (C) 2007 Atmel Corporation. - * - * Memory Controllers (MATRIX, EBI) - System peripherals registers. - * Based on AT91SAM9260 datasheet revision B. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - */ - -#ifndef AT91SAM9260_MATRIX_H -#define AT91SAM9260_MATRIX_H - -#define AT91_MATRIX_MCFG0 0x00/* Master Configuration Register 0 */ -#define AT91_MATRIX_MCFG1 0x04/* Master Configuration Register 1 */ -#define AT91_MATRIX_MCFG2 0x08/* Master Configuration Register 2 */ -#define AT91_MATRIX_MCFG3 0x0C/* Master Configuration Register 3 */ -#define AT91_MATRIX_MCFG4 0x10/* Master Configuration Register 4 */ -#define AT91_MATRIX_MCFG5 0x14/* Master Configuration Register 5 */ -#defineAT91_MATRIX_ULBT(7 << 0)/* Undefined Length Burst Type */ -#defineAT91_MATRIX_ULBT_INFINITE (0 << 0) -#defineAT91_MATRIX_ULBT_SINGLE (1 << 0) -#defineAT91_MATRIX_ULBT_FOUR (2 << 0) -#defineAT91_MATRIX_ULBT_EIGHT (3 << 0) -#defineAT91_MATRIX_ULBT_SIXTEEN(4 << 0) - -#define AT91_MATRIX_SCFG0 0x40/* Slave Configuration Register 0 */ -#define AT91_MATRIX_SCFG1 0x44/* Slave Configuration Register 1 */ -#define AT91_MATRIX_SCFG2 0x48/* Slave Configuration Register 2 */ -#define AT91_MATRIX_SCFG3 0x4C/* Slave Configuration Register 3 */ -#define AT91_MATRIX_SCFG4 0x50/* Slave Configuration Register 4 */ -#defineAT91_MATRIX_SLOT_CYCLE (0xff << 0)/* Maximum Number of Allowed Cycles for a Burst */ -#defineAT91_MATRIX_DEFMSTR_TYPE(3<< 16)/* Default Master Type */ -#defineAT91_MATRIX_DEFMSTR_TYPE_NONE (0 << 16) -#defineAT91_MATRIX_DEFMSTR_TYPE_LAST (1 << 16) -#defineAT91_MATRIX_DEFMSTR_TYPE_FIXED (2 << 16) -#defineAT91_MATRIX_FIXED_DEFMSTR (7<< 18)/* Fixed Index of Default Master */ -#defineAT91_MATRIX_ARBT(3<< 24)/* Arbitration Type */ -#defineAT91_MATRIX_ARBT_ROUND_ROBIN(0 << 24) -#defineAT91_MATRIX_ARBT_FIXED_PRIORITY (1 << 24) - -#define AT91_MATRIX_PRAS0 0x80/* Priority Register A for Slave 0 */ -#define AT91_MATRIX_PRAS1 0x88/* Priority Register A for Slave 1 */ -#define AT91_MATRIX_PRAS2 0x90/* Priority Register A for Slave 2 */ -#define AT91_MATRIX_PRAS3 0x98/* Priority Register A for Slave 3 */ -#define AT91_MATRIX_PRAS4 0xA0/* Priority Register A for Slave 4 */ -#defineAT91_MATRIX_M0PR(3 << 0)/* Master 0 Priority */ -#defineAT91_MATRIX_M1PR(3 << 4)/* Master 1 Priority */ -#defineAT91_MATRIX_M2PR
[PATCH v2 0/9] ARM: at91 cleanups for 4.1 #1
Hi, This series removes more mach/headers. Then it introduces a more scalable SoC detection infrastructure which allows to remove the at91_map_io/at91_alt_map_io and iotable_init ugliness. Changes in v2: - All the SoC names are lowercased - Removed the unused compatible string - Use name/subname to display the type and subtype Alexandre Belloni (7): ARM: at91: remove unused at91_ioremap_matrix and header ARM: at91: remove unused _matrix.h headers ARM: at91/dt: introduce atmel,-dbgu ARM: at91: at91rm9200 use SoC detection infrastructure ARM: at91: at91sam9: use SoC detection infrastructure ARM: at91: sama5 use SoC detection infrastructure ARM: at91: remove old setup Arnd Bergmann (1): ARM: at91: remove NEED_MACH_IO_H Boris BREZILLON (1): ARM: at91: add soc detection infrastructure .../devicetree/bindings/serial/atmel-usart.txt | 3 +- arch/arm/Kconfig | 2 +- arch/arm/boot/dts/at91rm9200.dtsi | 2 +- arch/arm/boot/dts/at91sam9260.dtsi | 2 +- arch/arm/boot/dts/at91sam9261.dtsi | 2 +- arch/arm/boot/dts/at91sam9263.dtsi | 2 +- arch/arm/boot/dts/at91sam9g45.dtsi | 2 +- arch/arm/boot/dts/at91sam9n12.dtsi | 2 +- arch/arm/boot/dts/at91sam9rl.dtsi | 2 +- arch/arm/boot/dts/at91sam9x5.dtsi | 2 +- arch/arm/boot/dts/sama5d3.dtsi | 2 +- arch/arm/boot/dts/sama5d4.dtsi | 2 +- arch/arm/mach-at91/Kconfig | 1 + arch/arm/mach-at91/Makefile| 2 +- arch/arm/mach-at91/at91rm9200.c| 34 ++- arch/arm/mach-at91/at91sam9.c | 86 -- arch/arm/mach-at91/generic.h | 4 - arch/arm/mach-at91/include/mach/at91_matrix.h | 23 -- .../mach-at91/include/mach/at91sam9260_matrix.h| 80 - .../mach-at91/include/mach/at91sam9261_matrix.h| 64 .../mach-at91/include/mach/at91sam9263_matrix.h| 129 .../mach-at91/include/mach/at91sam9g45_matrix.h| 153 -- .../mach-at91/include/mach/at91sam9n12_matrix.h| 53 .../arm/mach-at91/include/mach/at91sam9rl_matrix.h | 96 -- .../arm/mach-at91/include/mach/at91sam9x5_matrix.h | 53 arch/arm/mach-at91/include/mach/io.h | 27 -- arch/arm/mach-at91/sama5.c | 54 +++- arch/arm/mach-at91/setup.c | 330 - arch/arm/mach-at91/soc.c | 111 +++ arch/arm/mach-at91/soc.h | 95 ++ drivers/pcmcia/Kconfig | 1 + drivers/pcmcia/at91_cf.c | 13 +- 32 files changed, 352 insertions(+), 1082 deletions(-) delete mode 100644 arch/arm/mach-at91/include/mach/at91_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9260_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9261_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9263_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9g45_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9n12_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9rl_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9x5_matrix.h delete mode 100644 arch/arm/mach-at91/include/mach/io.h delete mode 100644 arch/arm/mach-at91/setup.c create mode 100644 arch/arm/mach-at91/soc.c create mode 100644 arch/arm/mach-at91/soc.h -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/9] ARM: at91: add soc detection infrastructure
From: Boris BREZILLON
Add new structures and functions to handle AT91 SoC detection.
[alexandre.bell...@free-electrons.com: reworked DBGU detection]
Signed-off-by: Alexandre Belloni
Signed-off-by: Boris BREZILLON
---
arch/arm/Kconfig| 1 +
arch/arm/mach-at91/Makefile | 2 +-
arch/arm/mach-at91/soc.c| 111
arch/arm/mach-at91/soc.h| 48 +++
4 files changed, 161 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-at91/soc.c
create mode 100644 arch/arm/mach-at91/soc.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e7ce6612bc42..f6c5b05e8de8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -363,6 +363,7 @@ config ARCH_AT91
select IRQ_DOMAIN
select PINCTRL
select PINCTRL_AT91
+ select SOC_BUS
select USE_OF
help
This enables support for systems based on Atmel
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index 827fdbcce1c7..44a5c1a92b39 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -2,7 +2,7 @@
# Makefile for the linux kernel.
#
-obj-y := setup.o
+obj-y := setup.o soc.o
obj-$(CONFIG_SOC_AT91SAM9) += sam9_smc.o
diff --git a/arch/arm/mach-at91/soc.c b/arch/arm/mach-at91/soc.c
new file mode 100644
index ..227872246fd9
--- /dev/null
+++ b/arch/arm/mach-at91/soc.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (C) 2015 Atmel
+ *
+ * Alexandre Belloni
+#include
+#include
+#include
+#include
+#include
+
+#include "soc.h"
+
+#define AT91_DBGU_CIDR 0x40
+#define AT91_DBGU_CIDR_ARCH(x) (((x) >> 20) & 0xff)
+#define AT91_DBGU_CIDR_VERSION(x) ((x) & 0x1f)
+#define AT91_DBGU_CIDR_EXT BIT(31)
+#define AT91_DBGU_CIDR_MATCH_MASK 0x7fe0
+#define AT91_DBGU_EXID 0x44
+
+struct soc_device * __init at91_soc_init(const struct at91_soc_family
*families)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ const struct at91_soc_family *family;
+ const struct at91_soc *soc;
+ struct soc_device *soc_dev;
+ struct device_node *np;
+ void __iomem *regs;
+ u32 cidr, exid;
+
+
+ np = of_find_compatible_node(NULL, NULL, "atmel,at91rm9200-dbgu");
+ if (!np)
+ np = of_find_compatible_node(NULL, NULL,
+"atmel,at91sam9260-dbgu");
+
+ if (!np) {
+ pr_warn("Could not find DBGU node");
+ return NULL;
+ }
+
+ regs = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!regs) {
+ pr_warn("Could not map DBGU iomem range");
+ iounmap(regs);
+ return NULL;
+ }
+
+ cidr = readl(regs + AT91_DBGU_CIDR);
+ exid = readl(regs + AT91_DBGU_EXID);
+
+ iounmap(regs);
+
+ for (family = families; family->name; family++) {
+ if (family->id == AT91_DBGU_CIDR_ARCH(cidr))
+ break;
+ }
+
+ if (!family->name) {
+ pr_warn("Could not find matching SoC family\n");
+ return NULL;
+ }
+
+ for (soc = family->socs; soc->name; soc++) {
+ if (soc->cidr_match != (cidr & AT91_DBGU_CIDR_MATCH_MASK))
+ continue;
+
+ if (!(cidr & AT91_DBGU_CIDR_EXT) || soc->exid_match == exid)
+ break;
+ }
+
+ if (!soc->name) {
+ pr_warn("Could not find matching SoC description\n");
+ return NULL;
+ }
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return NULL;
+
+ soc_dev_attr->family = family->name;
+ soc_dev_attr->soc_id = soc->subname ? soc->subname : soc->name;
+ soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%X",
+ AT91_DBGU_CIDR_VERSION(cidr));
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ kfree(soc_dev_attr->revision);
+ kfree(soc_dev_attr);
+ pr_warn("Could not register SoC device\n");
+ return NULL;
+ }
+
+ pr_info("Detected soc type: %s, revision %X\n", soc->name,
+ AT91_DBGU_CIDR_VERSION(cidr));
+ if (soc->subname)
+ pr_info("Detected soc subtype: %s\n", soc->subname);
+
+ return soc_dev;
+}
diff --git a/arch/arm/mach-at91/soc.h b/arch/arm/mach-at91/soc.h
new file mode 100644
index ..66dcd146601a
--- /dev/null
+++ b/arch/arm/mach-at91/soc.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2015 Atmel
+ *
+ * Boris Brezillon
+
+struct at91_soc {
+ u32 cidr_match;
+ u32 exid_match;
+ const char *name;
+ const char *subname;
+};
+
+struct at91_soc_family {
+ int id;
+ const char *name;
+ const struct at91_soc *socs;
+};
+
[PATCH v2 7/9] ARM: at91: at91sam9: use SoC detection infrastructure
Use the soc detection infrastructure for at91sam9 initialization.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/at91sam9.c | 86 ---
arch/arm/mach-at91/soc.h | 30 +++
2 files changed, 94 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9.c b/arch/arm/mach-at91/at91sam9.c
index 56e3ba73ec40..6aa0a5461be9 100644
--- a/arch/arm/mach-at91/at91sam9.c
+++ b/arch/arm/mach-at91/at91sam9.c
@@ -7,29 +7,78 @@
* Licensed under GPLv2 or later.
*/
-#include
-#include
-#include
-#include
#include
-#include
#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
+#include
#include "generic.h"
+#include "soc.h"
-static void __init at91sam9_dt_device_init(void)
+static const struct at91_soc at91sam9_socs[] = {
+ AT91_SOC(AT91SAM9260_CIDR_MATCH, 0, "at91sam9260", NULL),
+ AT91_SOC(AT91SAM9261_CIDR_MATCH, 0, "at91sam9261", NULL),
+ AT91_SOC(AT91SAM9263_CIDR_MATCH, 0, "at91sam9263", NULL),
+ AT91_SOC(AT91SAM9G20_CIDR_MATCH, 0, "at91sam9g20", NULL),
+ AT91_SOC(AT91SAM9RL64_CIDR_MATCH, 0, "at91sam9rl64", NULL),
+ AT91_SOC(AT91SAM9G45_CIDR_MATCH, AT91SAM9M11_EXID_MATCH,
+"at91sam9g45", "at91sam9m11"),
+ AT91_SOC(AT91SAM9G45_CIDR_MATCH, AT91SAM9M10_EXID_MATCH,
+"at91sam9g45", "at91sam9m10"),
+ AT91_SOC(AT91SAM9G45_CIDR_MATCH, AT91SAM9G46_EXID_MATCH,
+"at91sam9g45", "at91sam9g46"),
+ AT91_SOC(AT91SAM9G45_CIDR_MATCH, AT91SAM9G45_EXID_MATCH,
+"at91sam9g45", "at91sam9g45"),
+ AT91_SOC(AT91SAM9X5_CIDR_MATCH, AT91SAM9G15_EXID_MATCH,
+"at91sam9x5", "at91sam9g15"),
+ AT91_SOC(AT91SAM9X5_CIDR_MATCH, AT91SAM9G35_EXID_MATCH,
+"at91sam9x5", "at91sam9g35"),
+ AT91_SOC(AT91SAM9X5_CIDR_MATCH, AT91SAM9X35_EXID_MATCH,
+"at91sam9x5", "at91sam9x35"),
+ AT91_SOC(AT91SAM9X5_CIDR_MATCH, AT91SAM9G25_EXID_MATCH,
+"at91sam9x5", "at91sam9g25"),
+ AT91_SOC(AT91SAM9X5_CIDR_MATCH, AT91SAM9X25_EXID_MATCH,
+"at91sam9x5", "at91sam9x25"),
+ AT91_SOC(AT91SAM9N12_CIDR_MATCH, AT91SAM9CN12_EXID_MATCH,
+"at91sam9n12", "at91sam9cn12"),
+ AT91_SOC(AT91SAM9N12_CIDR_MATCH, AT91SAM9N12_EXID_MATCH,
+"at91sam9n12", "at91sam9n12"),
+ AT91_SOC(AT91SAM9N12_CIDR_MATCH, AT91SAM9CN11_EXID_MATCH,
+"at91sam9n12", "at91sam9cn11"),
+ { /* sentinel */ },
+};
+
+static const struct at91_soc at91sam9xe_socs[] = {
+ AT91_SOC(AT91SAM9XE128_CIDR_MATCH, 0, "at91sam9xe", "at91sam9xe128"),
+ AT91_SOC(AT91SAM9XE256_CIDR_MATCH, 0, "at91sam9xe", "at91sam9xe256"),
+ AT91_SOC(AT91SAM9XE512_CIDR_MATCH, 0, "at91sam9xe", "at91sam9xe512"),
+ { /* sentinel */ },
+};
+
+static const struct at91_soc_family at91sam9_families[] = {
+ AT91_SOC_FAMILY(ARCH_ID_AT91SAM9, "AT91SAM9", at91sam9_socs),
+ AT91_SOC_FAMILY(ARCH_ID_AT91SAM9XE, "AT91SAM9XE", at91sam9xe_socs),
+ { /* sentinel */ },
+};
+
+static void __init at91sam9_common_init(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ struct soc_device *soc;
+ struct device *soc_dev = NULL;
+
+ soc = at91_soc_init(at91sam9_families);
+ if (soc != NULL)
+ soc_dev = soc_device_to_device(soc);
+
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
arm_pm_idle = at91sam9_idle;
+}
+
+static void __init at91sam9_dt_device_init(void)
+{
+ at91sam9_common_init();
at91sam9260_pm_init();
}
@@ -40,16 +89,13 @@ static const char *at91_dt_board_compat[] __initconst = {
DT_MACHINE_START(at91sam_dt, "Atmel AT91SAM9")
/* Maintainer: Atmel */
- .map_io = at91_map_io,
.init_machine = at91sam9_dt_device_init,
.dt_compat = at91_dt_board_compat,
MACHINE_END
static void __init at91sam9g45_dt_device_init(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-
- arm_pm_idle = at91sam9_idle;
+ at91sam9_common_init();
at91sam9g45_pm_init();
}
@@ -60,16 +106,13 @@ static const char *at91sam9g45_board_compat[] __initconst
= {
DT_MACHINE_START(at91sam9g45_dt, "Atmel AT91SAM9G45")
/* Maintainer: Atmel */
- .map_io = at91_map_io,
.init_machine = at91sam9g45_dt_device_init,
.dt_compat = at91sam9g45_board_compat,
MACHINE_END
static void __init at91sam9x5_dt_device_init(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-
- arm_pm_idle = at91sam9_idle;
+ at91sam9_common_init();
at91sam9x5_pm_init();
}
@@ -81,7 +124,6 @@ static const char *at91sam9x5_board_compat[] __initconst = {
DT_MACHINE_START(at91sam9x5_dt, "Atmel AT91SAM9")
/* Maintainer: Atmel */
- .map_io
[PATCH v2 6/9] ARM: at91: at91rm9200 use SoC detection infrastructure
Use the soc detection infrastructure for at91rm9200 initialization.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/at91rm9200.c | 34 --
arch/arm/mach-at91/soc.h| 3 +++
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
index 8fcfb70f7124..9f3f91daf9fe 100644
--- a/arch/arm/mach-at91/at91rm9200.c
+++ b/arch/arm/mach-at91/at91rm9200.c
@@ -8,25 +8,27 @@
* Licensed under GPLv2 or later.
*/
-#include
-#include
-#include
-#include
+#include
#include
-#include
#include
-#include
-#include
-#include
#include
-#include
-#include
#include
#include
#include "generic.h"
+#include "soc.h"
+
+static const struct at91_soc rm9200_socs[] = {
+ AT91_SOC(AT91RM9200_CIDR_MATCH, 0, "at91rm9200", "at91rm9200 BGA"),
+ { /* sentinel */ },
+};
+
+static const struct at91_soc_family rm9200_families[] = {
+ AT91_SOC_FAMILY(ARCH_ID_AT91RM9200, "AT91RM9200", rm9200_socs),
+ { /* sentinel */ },
+};
static void at91rm9200_restart(enum reboot_mode reboot_mode, const char *cmd)
{
@@ -45,15 +47,20 @@ static void __init at91rm9200_dt_timer_init(void)
static void __init at91rm9200_dt_device_init(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ struct soc_device *soc;
+ struct device *soc_dev = NULL;
+
+ soc = at91_soc_init(rm9200_families);
+ if (soc != NULL)
+ soc_dev = soc_device_to_device(soc);
+
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
arm_pm_idle = at91rm9200_idle;
arm_pm_restart = at91rm9200_restart;
at91rm9200_pm_init();
}
-
-
static const char *at91rm9200_dt_board_compat[] __initconst = {
"atmel,at91rm9200",
NULL
@@ -61,7 +68,6 @@ static const char *at91rm9200_dt_board_compat[] __initconst =
{
DT_MACHINE_START(at91rm9200_dt, "Atmel AT91RM9200")
.init_time = at91rm9200_dt_timer_init,
- .map_io = at91_map_io,
.init_machine = at91rm9200_dt_device_init,
.dt_compat = at91rm9200_dt_board_compat,
MACHINE_END
diff --git a/arch/arm/mach-at91/soc.h b/arch/arm/mach-at91/soc.h
index 66dcd146601a..b330fcfe18a3 100644
--- a/arch/arm/mach-at91/soc.h
+++ b/arch/arm/mach-at91/soc.h
@@ -45,4 +45,7 @@ struct at91_soc_family {
struct soc_device * __init
at91_soc_init(const struct at91_soc_family *families);
+#define ARCH_ID_AT91RM9200 0x92
+#define AT91RM9200_CIDR_MATCH 0x09290780
+
#endif /* __AT91_SOC_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 9/9] ARM: at91: remove old setup
The old setup is not used anymore, remove it
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/Makefile | 2 +-
arch/arm/mach-at91/setup.c | 320
2 files changed, 1 insertion(+), 321 deletions(-)
delete mode 100644 arch/arm/mach-at91/setup.c
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index 44a5c1a92b39..50c0b526dcd8 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -2,7 +2,7 @@
# Makefile for the linux kernel.
#
-obj-y := setup.o soc.o
+obj-y := soc.o
obj-$(CONFIG_SOC_AT91SAM9) += sam9_smc.o
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
deleted file mode 100644
index ef778f33c488..
--- a/arch/arm/mach-at91/setup.c
+++ /dev/null
@@ -1,320 +0,0 @@
-/*
- * Copyright (C) 2007 Atmel Corporation.
- * Copyright (C) 2011 Jean-Christophe PLAGNIOL-VILLARD
- *
- * Under GPLv2
- */
-
-#define pr_fmt(fmt)"AT91: " fmt
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-
-#include
-#include
-#include
-
-#include "generic.h"
-#include "pm.h"
-
-struct at91_socinfo at91_soc_initdata;
-EXPORT_SYMBOL(at91_soc_initdata);
-
-static struct map_desc at91_io_desc __initdata __maybe_unused = {
- .virtual= (unsigned long)AT91_VA_BASE_SYS,
- .pfn= __phys_to_pfn(AT91_BASE_SYS),
- .length = SZ_16K,
- .type = MT_DEVICE,
-};
-
-static struct map_desc at91_alt_io_desc __initdata __maybe_unused = {
- .virtual= (unsigned long)AT91_ALT_VA_BASE_SYS,
- .pfn= __phys_to_pfn(AT91_ALT_BASE_SYS),
- .length = 24 * SZ_1K,
- .type = MT_DEVICE,
-};
-
-static void __init soc_detect(u32 dbgu_base)
-{
- u32 cidr, socid;
-
- cidr = __raw_readl(AT91_IO_P2V(dbgu_base) + AT91_DBGU_CIDR);
- socid = cidr & ~AT91_CIDR_VERSION;
-
- switch (socid) {
- case ARCH_ID_AT91RM9200:
- at91_soc_initdata.type = AT91_SOC_RM9200;
- if (at91_soc_initdata.subtype == AT91_SOC_SUBTYPE_UNKNOWN)
- at91_soc_initdata.subtype = AT91_SOC_RM9200_BGA;
- break;
-
- case ARCH_ID_AT91SAM9260:
- at91_soc_initdata.type = AT91_SOC_SAM9260;
- at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
- break;
-
- case ARCH_ID_AT91SAM9261:
- at91_soc_initdata.type = AT91_SOC_SAM9261;
- at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
- break;
-
- case ARCH_ID_AT91SAM9263:
- at91_soc_initdata.type = AT91_SOC_SAM9263;
- at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
- break;
-
- case ARCH_ID_AT91SAM9G20:
- at91_soc_initdata.type = AT91_SOC_SAM9G20;
- at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
- break;
-
- case ARCH_ID_AT91SAM9G45:
- at91_soc_initdata.type = AT91_SOC_SAM9G45;
- if (cidr == ARCH_ID_AT91SAM9G45ES)
- at91_soc_initdata.subtype = AT91_SOC_SAM9G45ES;
- break;
-
- case ARCH_ID_AT91SAM9RL64:
- at91_soc_initdata.type = AT91_SOC_SAM9RL;
- at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
- break;
-
- case ARCH_ID_AT91SAM9X5:
- at91_soc_initdata.type = AT91_SOC_SAM9X5;
- break;
-
- case ARCH_ID_AT91SAM9N12:
- at91_soc_initdata.type = AT91_SOC_SAM9N12;
- break;
-
- case ARCH_ID_SAMA5:
- at91_soc_initdata.exid = __raw_readl(AT91_IO_P2V(dbgu_base) +
AT91_DBGU_EXID);
- if (at91_soc_initdata.exid & ARCH_EXID_SAMA5D3) {
- at91_soc_initdata.type = AT91_SOC_SAMA5D3;
- }
- break;
- }
-
- /* at91sam9g10 */
- if ((socid & ~AT91_CIDR_EXT) == ARCH_ID_AT91SAM9G10) {
- at91_soc_initdata.type = AT91_SOC_SAM9G10;
- at91_soc_initdata.subtype = AT91_SOC_SUBTYPE_NONE;
- }
- /* at91sam9xe */
- else if ((cidr & AT91_CIDR_ARCH) == ARCH_FAMILY_AT91SAM9XE) {
- at91_soc_initdata.type = AT91_SOC_SAM9260;
- at91_soc_initdata.subtype = AT91_SOC_SAM9XE;
- }
-
- if (!at91_soc_is_detected())
- return;
-
- at91_soc_initdata.cidr = cidr;
-
- /* sub version of soc */
- if (!at91_soc_initdata.exid)
- at91_soc_initdata.exid = __raw_readl(AT91_IO_P2V(dbgu_base) +
AT91_DBGU_EXID);
-
- if (at91_soc_initdata.type == AT91_SOC_SAM9G45) {
- switch (at91_soc_initdata.exid) {
- case ARCH_EXID_AT91SAM9M10:
- at91_soc_initdata.subtype = AT91_SOC_SAM9M10;
- break;
- case
[PATCH v2 8/9] ARM: at91: sama5 use SoC detection infrastructure
Use the soc detection infrastructure for sama5 initialization.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/sama5.c | 54 +-
arch/arm/mach-at91/soc.h | 14
2 files changed, 53 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-at91/sama5.c b/arch/arm/mach-at91/sama5.c
index 03dcb441f3d2..c033c58faf35 100644
--- a/arch/arm/mach-at91/sama5.c
+++ b/arch/arm/mach-at91/sama5.c
@@ -7,27 +7,46 @@
* Licensed under GPLv2 or later.
*/
-#include
-#include
-#include
-#include
#include
#include
-#include
#include
#include
-#include
-#include
-
-#include
-#include
-#include
#include
#include
-#include
+#include
+
+#include
#include "generic.h"
+#include "soc.h"
+
+static const struct at91_soc sama5_socs[] = {
+ AT91_SOC(SAMA5D3_CIDR_MATCH, SAMA5D31_EXID_MATCH,
+"sama5d3", "sama5d31"),
+ AT91_SOC(SAMA5D3_CIDR_MATCH, SAMA5D33_EXID_MATCH,
+"sama5d3", "sama5d33"),
+ AT91_SOC(SAMA5D3_CIDR_MATCH, SAMA5D34_EXID_MATCH,
+"sama5d3", "sama5d34"),
+ AT91_SOC(SAMA5D3_CIDR_MATCH, SAMA5D35_EXID_MATCH,
+"sama5d3", "sama5d35"),
+ AT91_SOC(SAMA5D3_CIDR_MATCH, SAMA5D36_EXID_MATCH,
+"sama5d3", "sama5d36"),
+ AT91_SOC(SAMA5D4_CIDR_MATCH, SAMA5D41_EXID_MATCH,
+"sama5d4", "sama5d41"),
+ AT91_SOC(SAMA5D4_CIDR_MATCH, SAMA5D42_EXID_MATCH,
+"sama5d4", "sama5d41"),
+ AT91_SOC(SAMA5D4_CIDR_MATCH, SAMA5D43_EXID_MATCH,
+"sama5d4", "sama5d43"),
+ AT91_SOC(SAMA5D4_CIDR_MATCH, SAMA5D44_EXID_MATCH,
+"sama5d4", "sama5d44"),
+ { /* sentinel */ },
+};
+
+static const struct at91_soc_family sama5_families[] = {
+ AT91_SOC_FAMILY(ARCH_ID_SAMA5, "SAMA5", sama5_socs),
+ { /* sentinel */ },
+};
static int ksz8081_phy_fixup(struct phy_device *phy)
{
@@ -42,13 +61,20 @@ static int ksz8081_phy_fixup(struct phy_device *phy)
static void __init sama5_dt_device_init(void)
{
+ struct soc_device *soc;
+ struct device *soc_dev = NULL;
+
+ soc = at91_soc_init(sama5_families);
+ if (soc != NULL)
+ soc_dev = soc_device_to_device(soc);
+
if (of_machine_is_compatible("atmel,sama5d4ek") &&
IS_ENABLED(CONFIG_PHYLIB)) {
phy_register_fixup_for_id("fc028000.etherne:00",
ksz8081_phy_fixup);
}
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
at91sam9x5_pm_init();
}
@@ -59,7 +85,6 @@ static const char *sama5_dt_board_compat[] __initconst = {
DT_MACHINE_START(sama5_dt, "Atmel SAMA5")
/* Maintainer: Atmel */
- .map_io = at91_map_io,
.init_machine = sama5_dt_device_init,
.dt_compat = sama5_dt_board_compat,
MACHINE_END
@@ -93,7 +118,6 @@ static struct map_desc at91_io_desc[] __initdata = {
static void __init sama5_alt_map_io(void)
{
- at91_alt_map_io();
iotable_init(at91_io_desc, ARRAY_SIZE(at91_io_desc));
}
diff --git a/arch/arm/mach-at91/soc.h b/arch/arm/mach-at91/soc.h
index 4ed7e0bd7a62..ed14c387e1b8 100644
--- a/arch/arm/mach-at91/soc.h
+++ b/arch/arm/mach-at91/soc.h
@@ -78,4 +78,18 @@ at91_soc_init(const struct at91_soc_family *families);
#define AT91SAM9XE256_CIDR_MATCH 0x329a93a0
#define AT91SAM9XE512_CIDR_MATCH 0x329aa3a0
+#define ARCH_ID_SAMA5 0xa5
+#define SAMA5D3_CIDR_MATCH 0x0a5c07c0
+#define SAMA5D31_EXID_MATCH0x00444300
+#define SAMA5D33_EXID_MATCH0x00414300
+#define SAMA5D34_EXID_MATCH0x00414301
+#define SAMA5D35_EXID_MATCH0x00584300
+#define SAMA5D36_EXID_MATCH0x4301
+
+#define SAMA5D4_CIDR_MATCH 0x0a5c07c0
+#define SAMA5D41_EXID_MATCH0x0001
+#define SAMA5D42_EXID_MATCH0x0002
+#define SAMA5D43_EXID_MATCH0x0003
+#define SAMA5D44_EXID_MATCH0x0004
+
#endif /* __AT91_SOC_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] enhance configuring an ITS
On 04/03/15 03:18, Yun Wu wrote: > This patch series makes some enhancement to ITS configuration in the > following aspects: > > o make allocation of the ITS tables more sensible > o replace magic numbers with sensible macros > o guarantees a safe quiescent status before initializing an ITS > > This patch series is based on Marc's branch[1], and tested on Hisilion > ARM64 board with GICv3 ITS hardware. So this now looks pretty good (assuming you fix the couple of nits I mentioned). As this relies on my branch, shall I take it and ask Jason to look at the branch as a whole? Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/9] ARM: at91: remove unused at91_ioremap_matrix and header
at91_ioremap_matrix and the at91_matrix.h header are not used anymore, remove
them.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-at91/generic.h | 4
arch/arm/mach-at91/include/mach/at91_matrix.h | 23 ---
arch/arm/mach-at91/setup.c| 10 --
3 files changed, 37 deletions(-)
delete mode 100644 arch/arm/mach-at91/include/mach/at91_matrix.h
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index 583369ffc284..2b396c4e1fc1 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -25,10 +25,6 @@ extern void at91rm9200_timer_init(void);
extern void at91rm9200_idle(void);
extern void at91sam9_idle(void);
-/* Matrix */
-extern void at91_ioremap_matrix(u32 base_addr);
-
-
#ifdef CONFIG_PM
extern void __init at91rm9200_pm_init(void);
extern void __init at91sam9260_pm_init(void);
diff --git a/arch/arm/mach-at91/include/mach/at91_matrix.h
b/arch/arm/mach-at91/include/mach/at91_matrix.h
deleted file mode 100644
index f8996c954131..
--- a/arch/arm/mach-at91/include/mach/at91_matrix.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * Copyright (C) 2011 Jean-Christophe PLAGNIOL-VILLARD
- *
- * Under GPLv2
- */
-
-#ifndef __MACH_AT91_MATRIX_H__
-#define __MACH_AT91_MATRIX_H__
-
-#ifndef __ASSEMBLY__
-extern void __iomem *at91_matrix_base;
-
-#define at91_matrix_read(field) \
- __raw_readl(at91_matrix_base + field)
-
-#define at91_matrix_write(field, value) \
- __raw_writel(value, at91_matrix_base + field)
-
-#else
-.extern at91_matrix_base
-#endif
-
-#endif /* __MACH_AT91_MATRIX_H__ */
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index 4e58bc90ed21..ef778f33c488 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -318,13 +318,3 @@ void __init at91_alt_map_io(void)
pr_info("AT91: Detected soc subtype: %s\n",
at91_get_soc_subtype(_soc_initdata));
}
-
-void __iomem *at91_matrix_base;
-EXPORT_SYMBOL_GPL(at91_matrix_base);
-
-void __init at91_ioremap_matrix(u32 base_addr)
-{
- at91_matrix_base = ioremap(base_addr, 512);
- if (!at91_matrix_base)
- panic(pr_fmt("Impossible to ioremap at91_matrix_base\n"));
-}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/9] ARM: at91/dt: introduce atmel,-dbgu
The DBGU is not a simple UART and we need to be able to distinguish it from the
other UARTs, in particular to get its address and check the chip id.
Signed-off-by: Alexandre Belloni
---
Documentation/devicetree/bindings/serial/atmel-usart.txt | 3 ++-
arch/arm/boot/dts/at91rm9200.dtsi| 2 +-
arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
arch/arm/boot/dts/at91sam9261.dtsi | 2 +-
arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
arch/arm/boot/dts/at91sam9rl.dtsi| 2 +-
arch/arm/boot/dts/at91sam9x5.dtsi| 2 +-
arch/arm/boot/dts/sama5d3.dtsi | 2 +-
arch/arm/boot/dts/sama5d4.dtsi | 2 +-
11 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt
b/Documentation/devicetree/bindings/serial/atmel-usart.txt
index a6391e70a8fd..90787aa2e648 100644
--- a/Documentation/devicetree/bindings/serial/atmel-usart.txt
+++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt
@@ -1,9 +1,10 @@
* Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART)
Required properties:
-- compatible: Should be "atmel,-usart"
+- compatible: Should be "atmel,-usart" or "atmel,-dbgu"
The compatible indicated will be the first SoC to support an
additional mode or an USART new feature.
+ For the dbgu UART, use "atmel,-dbgu", "atmel,-usart"
- reg: Should contain registers location and length
- interrupts: Should contain interrupt
- clock-names: tuple listing input clock names.
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
b/arch/arm/boot/dts/at91rm9200.dtsi
index 21c2b504f977..c515e4b160be 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -830,7 +830,7 @@
};
dbgu: serial@f200 {
- compatible = "atmel,at91rm9200-usart";
+ compatible = "atmel,at91rm9200-dbgu",
"atmel,at91rm9200-usart";
reg = <0xf200 0x200>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index fff0ee69aab4..9ea347eff3a7 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -753,7 +753,7 @@
};
dbgu: serial@f200 {
- compatible = "atmel,at91sam9260-usart";
+ compatible = "atmel,at91sam9260-dbgu",
"atmel,at91sam9260-usart";
reg = <0xf200 0x200>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/at91sam9261.dtsi
b/arch/arm/boot/dts/at91sam9261.dtsi
index e247b0b5fdab..45973554f229 100644
--- a/arch/arm/boot/dts/at91sam9261.dtsi
+++ b/arch/arm/boot/dts/at91sam9261.dtsi
@@ -275,7 +275,7 @@
};
dbgu: serial@f200 {
- compatible = "atmel,at91sam9260-usart";
+ compatible = "atmel,at91sam9260-dbgu",
"atmel,at91sam9260-usart";
reg = <0xf200 0x200>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
index 1f67bb4c144e..111a4e029cca 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -762,7 +762,7 @@
};
dbgu: serial@ee00 {
- compatible = "atmel,at91sam9260-usart";
+ compatible = "atmel,at91sam9260-dbgu",
"atmel,at91sam9260-usart";
reg = <0xee00 0x200>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index ee80aa9c0759..d5ec0fb935fb 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -893,7 +893,7 @@
};
dbgu: serial@ee00 {
- compatible = "atmel,at91sam9260-usart";
+ compatible = "atmel,at91sam9260-dbgu",
"atmel,at91sam9260-usart";
reg = <0xee00 0x200>;
[PATCH v2 1/9] ARM: at91: remove NEED_MACH_IO_H
From: Arnd Bergmann
The mach/io.h header on at91 is used to support a nonstandard I/O space
window for the cf card driver. This changes the driver to use pci_ioremap_io
in order to have the standard location, and then removes the custom
mach/io.h.
[alexandre.bell...@free-electrons.com: Added PCI dependency]
Signed-off-by: Alexandre Belloni
Signed-off-by: Arnd Bergmann
---
arch/arm/Kconfig | 1 -
arch/arm/mach-at91/Kconfig | 1 +
arch/arm/mach-at91/include/mach/io.h | 27 ---
drivers/pcmcia/Kconfig | 1 +
drivers/pcmcia/at91_cf.c | 13 +++--
5 files changed, 9 insertions(+), 34 deletions(-)
delete mode 100644 arch/arm/mach-at91/include/mach/io.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9f1f09a2bc9b..e7ce6612bc42 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -361,7 +361,6 @@ config ARCH_AT91
select ARCH_REQUIRE_GPIOLIB
select CLKDEV_LOOKUP
select IRQ_DOMAIN
- select NEED_MACH_IO_H if PCCARD
select PINCTRL
select PINCTRL_AT91
select USE_OF
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index c74a44324e5b..7ecde7de69da 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -81,6 +81,7 @@ config SOC_AT91RM9200
select CPU_ARM920T
select GENERIC_CLOCKEVENTS
select HAVE_AT91_USB_CLK
+ select MIGHT_HAVE_PCI
config SOC_AT91SAM9
bool "AT91SAM9"
diff --git a/arch/arm/mach-at91/include/mach/io.h
b/arch/arm/mach-at91/include/mach/io.h
deleted file mode 100644
index 2d9ca0455745..
--- a/arch/arm/mach-at91/include/mach/io.h
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * arch/arm/mach-at91/include/mach/io.h
- *
- * Copyright (C) 2003 SAN People
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#ifndef __ASM_ARCH_IO_H
-#define __ASM_ARCH_IO_H
-
-#define IO_SPACE_LIMIT 0x
-#define __io(a)__typesafe_io(a)
-
-#endif
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index 3bb49252a098..075d5cd4c5ab 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -278,6 +278,7 @@ config BFIN_CFPCMCIA
config AT91_CF
tristate "AT91 CompactFlash Controller"
+ depends on PCI
depends on PCMCIA && ARCH_AT91
depends on !ARCH_MULTIPLATFORM
help
diff --git a/drivers/pcmcia/at91_cf.c b/drivers/pcmcia/at91_cf.c
index bfb799c7b343..e7775a41ae5d 100644
--- a/drivers/pcmcia/at91_cf.c
+++ b/drivers/pcmcia/at91_cf.c
@@ -317,13 +317,14 @@ static int at91_cf_probe(struct platform_device *pdev)
} else
cf->socket.pci_irq = nr_irqs + 1;
- /* pcmcia layer only remaps "real" memory not iospace */
- cf->socket.io_offset = (unsigned long) devm_ioremap(>dev,
- cf->phys_baseaddr + CF_IO_PHYS, SZ_2K);
- if (!cf->socket.io_offset) {
- status = -ENXIO;
+ /*
+* pcmcia layer only remaps "real" memory not iospace
+* io_offset is set to 0x1 to avoid the check in static_find_io().
+* */
+ cf->socket.io_offset = 0x1;
+ status = pci_ioremap_io(0x1, cf->phys_baseaddr + CF_IO_PHYS);
+ if (status)
goto fail0a;
- }
/* reserve chip-select regions */
if (!devm_request_mem_region(>dev, io->start, resource_size(io),
"at91_cf")) {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0-rc1 v17 4/6] printk: Simple implementation for NMI backtracing
On Wed, 2015-03-04 at 09:21 -0800, Joe Perches wrote: > On Wed, 2015-03-04 at 16:33 +, Daniel Thompson wrote: > > On Wed, 2015-03-04 at 11:20 -0500, Steven Rostedt wrote: > > > On Wed, 04 Mar 2015 08:13:21 -0800 > > > Joe Perches wrote: > > > > > > > On Wed, 2015-03-04 at 10:12 +, Daniel Thompson wrote: > > > > > Currently there is a quite a pile of code sitting in > > > > > arch/x86/kernel/apic/hw_nmi.c to support safe all-cpu backtracing > > > > > from NMI. > > > > > The code is inaccessible to backtrace implementations for other > > > > > architectures, which is a shame because they would probably like to be > > > > > safe too. > > > > > > > > > > Copy this code into printk. We'll port the x86 NMI backtrace to it in > > > > > a > > > > > later patch. > > > > > > > > I think this would be better as a separate file > > > > rather than increasing the bulk of printk.c > > > > > > > I agree, as printk already has its own directory. Perhaps a > > > "nmi_backtrace.c"? > > > > I agree on moving the code. However, after Thomas' review I made sure > > all the external symbols were prefixed printk_nmi and, as a result of > > the same review I started using CONFIG_PRINTK_NMI to enable/disable the > > feature). For that reason I'm much more inclined to name it > > "printk_nmi.c". Any objections? > > Steven's suggestion seems more sensible. > > sed 's/CONFIG_PRINTK_NMI/CONFIG_PRINTK_NMI_BACKTRACE/g' > sed 's/printk_nmi/printk_nmib/g' > or > sed 's/printk_nmi/nmi_backtrace/g' > > might work well. Ok. The later rename is consistent and makes is much less likely the facility will be (accidentally) misused in future. I'll change like this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set
On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja wrote: > > On 02/23/2015 09:09 PM, Daniel Vetter wrote: >> >> On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote: >>> >>> On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter wrote: On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote: > > On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja > wrote: >> >> The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV >> config is >> selected. The driver accesses drm_fb_helper_* functions even when >> legacy fbdev >> support is disabled in msm. Wrap around these functions with #ifdef >> checks to >> prevent build break. > > > hmm, perhaps rather than solving this in each driver, we should do > some stub versions of those fb-helper fxns? > > There are at least one or two other drivers that can build without > fbdev, and I guess more going forward.. It's not quite that easy since you also have to start/stop the vt subsystem at the right point in time in your own driver. See intel_fbdev_set_suspend. If you don't do that there's no synchronization between fbcon shutting down/resuming and your driver, which in the best case means fbcon does some writes to nowhere and worst case means your chip dies (mmio to offline chip blocks) or writes go to somewhere random in system memory (iommu contains some stale ptes since not yet fully restored, more an issue with hibernate). >>> >>> >>> I guess I don't fully follow the vt/fbcon interaction if there is no >>> fbdev driver... but then again I don't have vesafb/efifb to contend >>> with, so I'm assuming something to do with that.. >> >> >> It's the other way round: There's interaction when we have fbdev enabled >> beyond just calling a few fbdev helper functions. And we should compile >> that out too since the console_lock is way too evil ;-) >> >> Only with these additional #ifdefs is i915 completely console_lock free if >> you disable i915 fbdev support. Just stubbing out the fbdev helper >> functions is not enough. >> And because the console_lock is massively contended we do that in a async worker in i915. But anyway I agree it would still simply drivers quite a bit if we'd have support for dummy fb helpers in the core, maybe with an explicit Kconfig. Then drivers could switch to using that for the additional #ifdef (like the vt stuff i915 does) and otherwise rely upon dummy static inline. That would give us fbdev-less support for most drivers for free, which is kinda neat. >>> >>> >>> I guess at least for all the arm drivers, life without fbdev doesn't >>> have these extra complications, so at least they could use stubs.. >> >> >> Does the problem sound more tricky with the above clarification? If you >> don't do the fb_set_suspend call then I expect you'll have some >> interesting problems. >> >>> Plus, I kind of expect phone/tablet/chromebook type stuff would lead >>> the charge into an fbdev-less world.. >> >> >> Yeah, that's another reason to support fbdev-less in the helpers instead >> of each driver. > > > I was trying to create a patch with the idea above. This works well if we > want the kernel to support only one DRM driver. If the kernel supports > multiple platforms and one DRM driver sets its config to enable legacy fbdev > and another doesn't, we still end up building the fbdev helper funcs. > Drivers built without legacy fbdev would need to be very strict(check for > priv->fbdev not NULL) to prevent calling them. > > The fb cma helper also adds to the difficulties. The cma helper seems to > have some functions that provide legacy fbdev support and others that allow > allocation of drm_framebuffers and gem objects. We'd need to be careful > about our stub functions not messing up the drivers using the fb cma > helpers. > > Rather than creating fb helper stub functions, maybe we could help each drm > driver create two variants of functions needed by drm core(like > output_poll_changed and dev_lastclose), one variant supporting legacy fbdev, > and the other not? So one quick thought.. building without fbdev would ideally/eventually be a distro level decision, not a driver level decision.. so I think it is *eventually* not a problem for it being a global drm level decision. The only problem is right now some drivers support no-fbdev config, and some do not. Maybe it is worth fixing that? BR, -R > Archit > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] make automatic device_id generation possible
On Thu, Mar 05, 2015 at 11:04:36AM +0900, Minchan Kim wrote: > On Thu, Mar 05, 2015 at 10:47:52AM +0900, Sergey Senozhatsky wrote: > > On (03/05/15 10:33), Minchan Kim wrote: > > > > hm, I can think of a huge build server with tons of users. > > > > /dev/zram$(id -u) > > > > created during user login and destroyed during logout. so users use > > > > theirs own > > > > zram devices with predictable device ids (which also makes it simpler > > > > for admin) > > > > for compilation/etc., and don't pressure hdds that much. > > > > > > They upgraded the system and from now on, one of app tries automatic > > > id with zram for some reason. What happens if he gets some user id > > > before the user login? The system should have fallback in the case of > > > failing to create own userid assignment. > > > > we upgraded our scripts but landed some bugs there? it's up to particular > > implementation. in your example, I assume, someone used zram with > > num_devices >= 1000? > > that's impossible. current num_devices limitation is 32. and uid-s start > > from 1000. > > I meant it. > If we support use-defined id and someone have used your idea so he can make > zram > per-user as uid. After a while, new application stats automatic id assignment > so upcoming users can consume upcoming user id. yeah, automaic id will start > from 0 so it's very rare to reach 1000 but who knows? Why 1000? The UID_MIN and UID_MAX is nothing strictly defined, it's just option in /etc/login.defs. I guess it's nothing unusually to have system where UID_MIN is 500 :-) Karel -- Karel Zak http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] genirq: describe IRQF_COND_SUSPEND
On Thu, Mar 05, 2015 at 11:33:06AM +, Alexandre Belloni wrote: > On 05/03/2015 at 11:04:11 +, Mark Rutland wrote : > > > > +In rare cases an IRQ can be shared between a wakeup device driver and > > > > an > > > > +IRQF_NO_SUSPEND user. In order for this to be safe, the wakeup device > > > > driver > > > > +must be able to discern spurious IRQs from genuine wakeup events > > > > (signalling > > > > > > And genuine question, should we use British English or American English > > > or we don't care ? > > > > Have I written something that isn't valid American English there? I read > > over this a few times and failed to spot anything obvious. > > > > I'm happy to change for consistency, I generally assume that's the most > > important thing. > > I'd say signalling vs signaling. I actually had to look up which one was > correct. I'm personally using Incorrect/Broken English so I'm definitely > not here to give lessons. Easy option to keep everyone happy: s/signalling/indicating/ That should be valid for the English variants I'm aware of, and it has the same number of characters so we don't need to reflow the text. Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] irqchip: gicv3-its: support safe initialization
On 04/03/15 03:18, Yun Wu wrote:
> It's unsafe to change the configurations of an activated ITS directly
> since this will lead to unpredictable results. This patch guarantees
> the ITSes being initialized are quiescent.
>
> Signed-off-by: Yun Wu
> ---
> drivers/irqchip/irq-gic-v3-its.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index d13c24e..9e09aa0 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1320,6 +1320,34 @@ static const struct irq_domain_ops its_domain_ops = {
> .deactivate = its_irq_domain_deactivate,
> };
>
> +static int its_check_quiesced(void __iomem *base)
Another nitpick: Rather than "its_check_quiesced", how about
"its_force_quiescent" instead? Because this does a lot more than just
checking.
> +{
> + u32 count = 100;/* 1s */
> + u32 val;
> +
> + val = readl_relaxed(base + GITS_CTLR);
> + if (val & GITS_CTLR_QUIESCENT)
> + return 0;
> +
> + /* Disable the generation of all interrupts to this ITS */
> + val &= ~GITS_CTLR_ENABLE;
> + writel_relaxed(val, base + GITS_CTLR);
> +
> + /* Poll GITS_CTLR and wait until ITS becomes quiescent */
> + while (1) {
> + val = readl_relaxed(base + GITS_CTLR);
> + if (val & GITS_CTLR_QUIESCENT)
> + return 0;
> +
> + count--;
> + if (!count)
> + return -EBUSY;
> +
> + cpu_relax();
> + udelay(1);
> + }
> +}
> +
I still dislike this repeated pattern, but I don't have a good solution
so far.
> static int its_probe(struct device_node *node, struct irq_domain *parent)
> {
> struct resource res;
> @@ -1348,6 +1376,13 @@ static int its_probe(struct device_node *node, struct
> irq_domain *parent)
> goto out_unmap;
> }
>
> + err = its_check_quiesced(its_base);
> + if (err) {
> + pr_warn("%s: failed to quiesce, giving up\n",
> + node->full_name);
> + goto out_unmap;
> + }
> +
> pr_info("ITS: %s\n", node->full_name);
>
> its = kzalloc(sizeof(*its), GFP_KERNEL);
> --
> 1.8.0
>
>
>
Assuming you fix the above nitpick:
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] make automatic device_id generation possible
Cc Sami Kerola, Timofey Titovets, Karel Zak, util-linux (don't have Jóhann B. Guðmundsson's email). also published on google+. On (03/05/15 09:20), Minchan Kim wrote: > > Make zram-contol/zram_add interface easier to use. Extend it to support > > read and write operations. > > > > Write operation remains the same: > > > > echo X > /sys/class/zram-control/zram_add > > > > will add /dev/zramX (or return error). > > > > > > Read operation is treated as 'pick up available device_id, add new > > device and return device_id'. > > > > Example: > > cat /sys/class/zram-control/zram_add > > 2 > > cat /sys/class/zram-control/zram_add > > 3 > > Thanks for handling my concern quickly and sorry for not sending > active feedback in realtime. Maybe I should turn on CONFIG_PREEMPT > in my brain. > > I'm not against but I want to know why we should support > user-defined device id. What usecase do you have in mind? > > Could we support automatic id support only at this moment? > Then, if some user complains about that in future, we could turn > on user-defined device id easily and we could know the usecase. > > In summary, I want to support only "cat /sys/class/zram-control/zram_add" > unless you have feasible usecase. > > What do you think about it? Hello guys, call for opinions. we currently discuss on-demand device creation/removal (you can find mail thread here https://lkml.org/lkml/2015/3/4/1414) and we want to hear some opinions. to add a new device, zram implements two modes (schematically): -- forced mode which is "add device /dev/zram". user must provide new device id. here we expect user to ensure that devide_id uniqueness and to handle errors if it's not. (zram will return -EEXIST if device_id is already in use). I can think of... a build server with tons of users and /dev/zram$(id -u) devices being created for every user during login (and destroyed during logout). so users don't pressure hdd, they have zram devices to play with, these devices have predictable names, which also makes admin's life a bit easier -- he can find out device user by simply checking its name (to remove abandoned devices, for example. anyway). there might be other more or less real life use-cases. usage example: echo `id -u` > /sys/class/zram-control/zram_add -- automatic mode which is "pick device_id automatically, add device /dev/zram, and return back to user". usage example: cat /sys/class/zram-control/zram_add 7 cat /sys/class/zram-control/zram_add 8 we tend to ditch `forced' mode and leave `automatic' mode only. before we do that we'd like to see how many guys will be pissed off and... basically, if 'forced' mode is of any actual use. so the question is: should there be two modes or one is just enough? -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] make automatic device_id generation possible
On Thu, Mar 05, 2015 at 09:58:29AM +0900, Sergey Senozhatsky wrote: > Hello, > > On (03/05/15 09:20), Minchan Kim wrote: > > I'm not against but I want to know why we should support > > user-defined device id. What usecase do you have in mind? > > > > hm, you never know what people can come up with. that's probably the > strongest support argument I can provide. I wish there was something > like - my friend Mike has a "device /dev/zram1 is always swap device, > device /dev/zram$(id -u) is a per-user zram device (he finds it useful, I have doubts that promise stable device names is good idea. The usual way is to care about FS/SWAP identifiers (LABEL=, or UUID=), and for example udevd should be able to create a stable /dev/disk/by-* symlinks. So for your friend Mike is better to have UUID= in /etc/fstab and force mkswap or mkfs to use still the same UUID. > user defined id support comes at a price of ~10 lines of code, or even > less. we waste much more code to show ->stats, and not all of them are I think it's not about number of code lines, it's kernel, you have to support it forever, etc. It's easy to add a new feature, but you don't have to do it right now :) Karel -- Karel Zak http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next 07/12] serial: earlycon: Common log banner for command line and DT
Hi Peter,
On Wed, Mar 4, 2015 at 6:24 PM, Peter Hurley wrote:
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -69,6 +69,7 @@ static void __init earlycon_init(struct earlycon_device
> *device,
> const char *name)
> {
> struct console *earlycon = device->con;
> + struct uart_port *port = >port;
> const char *s;
> size_t len;
>
> @@ -82,6 +83,16 @@ static void __init earlycon_init(struct earlycon_device
> *device,
> len = s - name;
> strlcpy(earlycon->name, name, min(len + 1, sizeof(earlycon->name)));
> earlycon->data = _console_dev;
> +
> + if (port->iotype == UPIO_MEM || port->iotype == UPIO_MEM32)
> + pr_info("Early serial console at MMIO%s 0x%llx (options
> '%s')\n",
> + (port->iotype == UPIO_MEM32) ? "32" : "",
> + (unsigned long long)port->mapbase,
I know you're just moving this piece of code around, but mapbase is a
resource_size_t (it should actually be phys_addr_t, which probably didn't
exist in 2007), so it should be printed using %pa and passing a reference,
instead of %llx and using a cast.
> + device->options);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] OUT-OF-TREE: pmem: Allow request_mem to fail (BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET)
With old Kernels there was a bug in x86 where any unknown
memory chip type would come up BUSY when calling
request_mem_region_exclusive().
So for pmem to work with old Kernels and real NvDIMM chips
we have a new Kconfig option CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET.
People have been running with hacked up pmem that will ignore
the return code from request_mem_region_exclusive. So here it is
official
Signed-off-by: Boaz Harrosh
---
drivers/block/Kconfig | 12
drivers/block/pmem.c | 9 ++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 635fa6a..58a2c69 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -435,6 +435,18 @@ config BLK_DEV_PMEM_USE_PAGES
to other devices in the system, then you must say "Yes" here.
If unsure leave as Yes.
+config BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET
+ bool "Ignore the return code from request_mem_region_exclusive"
+ depends on BLK_DEV_PMEM
+ help
+ In Old Kernels type-12 Memory type which is used by NvDIMM
+ chips Comes out busy when calling request_mem_region_exclusive,
+ because of a bug.
+ If this option is set to "yes". The pmem will ignore the
+ failure, and continue as usual. If you have an old Kernel and
+ a real NvDIMM chip you must say yes here.
+ (Ignored if BLK_DEV_PMEM_USE_PAGES=y)
+
config CDROM_PKTCDVD
tristate "Packet writing on CD/DVD media"
depends on !UML
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index d0c80f4..ba1167c 100644
--- a/drivers/block/pmem.c
+++ b/drivers/block/pmem.c
@@ -172,8 +172,10 @@ int pmem_mapmem(struct pmem_device *pmem)
"pmem");
if (unlikely(!res_mem)) {
pr_warn("pmem: request_mem_region_exclusive phys=0x%llx
size=0x%zx failed\n",
- pmem->phys_addr, pmem->size);
- return -EINVAL;
+ pmem->phys_addr, pmem->size);
+#ifndef CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET
+ return -EBUSY;
+#endif
}
pmem->virt_addr = ioremap_cache(pmem->phys_addr, pmem->size);
@@ -184,7 +186,8 @@ int pmem_mapmem(struct pmem_device *pmem)
return 0;
out_release:
- release_mem_region(pmem->phys_addr, pmem->size);
+ if (res_mem)
+ release_mem_region(pmem->phys_addr, pmem->size);
return err;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] pmem: Add support for page structs
One of the current shortcomings of the NVDIMM/PMEM
support is that this memory does not have a page-struct(s)
associated with its memory and therefor cannot be passed
to a block-device or network or DMAed in any way through
another device in the system.
The use of add_persistent_memory() fixes all this. After this patch
an FS can do:
bdev_direct_access(,,);
page = pfn_to_page(pfn);
And use that page for a lock_page(), set_page_dirty(), and/or
anything else one might do with a page *.
(Note that with brd one can already do this)
[pmem-pages-ref-count]
pmem will serve it's pages with ref==0. Once an FS does
an blkdev_get_XXX(,FMODE_EXCL,), that memory is own by the FS.
The FS needs to manage its allocation, just as it already does
for its disk blocks. The fs should set page->count = 2, before
submission to any Kernel subsystem so when it returns it will
never be released to the Kernel's page-allocators. (page_freeze)
Signed-off-by: Boaz Harrosh
---
drivers/block/Kconfig | 13 +
drivers/block/pmem.c | 20
2 files changed, 33 insertions(+)
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 1530c2a..635fa6a 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -422,6 +422,19 @@ config BLK_DEV_PMEM
Most normal users won't need this functionality, and can thus say N
here.
+config BLK_DEV_PMEM_USE_PAGES
+ bool "Enable use of page struct pages with pmem"
+ depends on BLK_DEV_PMEM
+ depends on PERSISTENT_MEMORY_DEPENDENCY
+ select DRIVER_NEEDS_PERSISTENT_MEMORY
+ default y
+ help
+ If a user of PMEM device needs "struct page" associated
+ with its memory, so this memory can be sent to other
+ block devices, or sent on the network, or be DMA transferred
+ to other devices in the system, then you must say "Yes" here.
+ If unsure leave as Yes.
+
config CDROM_PKTCDVD
tristate "Packet writing on CD/DVD media"
depends on !UML
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index f0f0ba0..d0c80f4 100644
--- a/drivers/block/pmem.c
+++ b/drivers/block/pmem.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -141,6 +142,24 @@ MODULE_PARM_DESC(map,
static LIST_HEAD(pmem_devices);
+#ifdef CONFIG_BLK_DEV_PMEM_USE_PAGES
+/* pmem->phys_addr and pmem->size need to be set.
+ * Will then set pmem->virt_addr if successful.
+ */
+int pmem_mapmem(struct pmem_device *pmem)
+{
+ return add_persistent_memory(pmem->phys_addr, pmem->size,
+>virt_addr);
+}
+
+static void pmem_unmapmem(struct pmem_device *pmem)
+{
+ remove_persistent_memory(pmem->phys_addr, pmem->size);
+}
+
+#define PMEM_ALIGNMEM (1UL << SECTION_SIZE_BITS)
+#else /* !CONFIG_BLK_DEV_PMEM_USE_PAGES */
+
/* pmem->phys_addr and pmem->size need to be set.
* Will then set virt_addr if successful.
*/
@@ -180,6 +199,7 @@ void pmem_unmapmem(struct pmem_device *pmem)
}
#define PMEM_ALIGNMEM PAGE_SIZE
+#endif /* ! CONFIG_BLK_DEV_PMEM_USE_PAGES */
static struct pmem_device *pmem_alloc(phys_addr_t phys_addr, size_t disk_size,
int i)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/5] irqchip: gicv3-its: define macros for GITS_CTLR fields
On 04/03/15 03:18, Yun Wu wrote:
> Define macros for GITS_CTLR fields to avoid using magic numbers.
>
> Signed-off-by: Yun Wu
Acked-by: Marc Zyngier
M.
> ---
> drivers/irqchip/irq-gic-v3-its.c | 2 +-
> include/linux/irqchip/arm-gic-v3.h | 3 +++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index e8bda0b..d13c24e 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1388,7 +1388,7 @@ static int its_probe(struct device_node *node, struct
> irq_domain *parent)
> writeq_relaxed(baser, its->base + GITS_CBASER);
> tmp = readq_relaxed(its->base + GITS_CBASER);
> writeq_relaxed(0, its->base + GITS_CWRITER);
> - writel_relaxed(1, its->base + GITS_CTLR);
> + writel_relaxed(GITS_CTLR_ENABLE, its->base + GITS_CTLR);
>
> if ((tmp ^ baser) & GITS_BASER_SHAREABILITY_MASK) {
> pr_info("ITS: using cache flushing for cmd queue\n");
> diff --git a/include/linux/irqchip/arm-gic-v3.h
> b/include/linux/irqchip/arm-gic-v3.h
> index 3459b43..c9d3002 100644
> --- a/include/linux/irqchip/arm-gic-v3.h
> +++ b/include/linux/irqchip/arm-gic-v3.h
> @@ -134,6 +134,9 @@
>
> #define GITS_TRANSLATER 0x10040
>
> +#define GITS_CTLR_ENABLE (1U << 0)
> +#define GITS_CTLR_QUIESCENT (1U << 31)
> +
> #define GITS_TYPER_DEVBITS_SHIFT 13
> #define GITS_TYPER_DEVBITS(r)r) >>
> GITS_TYPER_DEVBITS_SHIFT) & 0x1f) + 1)
> #define GITS_TYPER_PTA (1UL << 19)
> --
> 1.8.0
>
>
>
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] mm: New add_persistent_memory/remove_persistent_memory
Persistent Memory is not Memory. It is not presented as
a Memory Zone and is not available through the page allocators
for application/kernel volatile usage.
It belongs to A block device just as any other Persistent storage,
the novelty here is that it is directly mapped on the CPU Memory
bus, and usually as fast or almost as fast as system RAM.
The main motivation of add_persistent_memory is to allocate a
page-struct "Section" for a given physical memory region. This is because
The user of this memory mapped device might need to pass pages-struct
of this memory to a Kernel subsytem like block-layer or networking
and have it's content directly DMAed to other devices
(For example these pages can be put on a bio and sent to disk
in a copy-less manner)
It will also request_mem_region_exclusive(.., "persistent_memory")
to own that physical memory region.
And will map that physical region to the Kernel's VM at the
address expected for page_address() of those pages allocated
above
remove_persistent_memory() must be called to undo what
add_persistent_memory did.
A user of this API will then use pfn_to_page(PHISICAL_ADDR >> PAGE_SIZE)
to receive a page-struct for use on its pmem.
Any operation like page_address() page_to_pfn() page_lock() ... can
be preformed on these pages just as usual.
An example user is presented in the next patch to pmem.c Block Device
driver (There are 3 more such drivers in the Kernel that could use this
API)
This patch is based on research and patch made by
Yigal Korman to the pmem driver. I took his code
and adapted it to mm, where it belongs.
[v2 SQUASHME1]
Fixing 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
'__meminit' should be added
Signed-off-by: Yigal Korman
[v3 SQUASHME2]
We need to calculate the nid for every section, it is
possible that the same contiguous range will span two
numa-nodes.
Signed-off-by: Boaz Harrosh
Signed-off-by: Yigal Korman
Signed-off-by: Boaz Harrosh
---
include/linux/memory_hotplug.h | 4 +
mm/Kconfig | 23 ++
mm/memory_hotplug.c| 177 +
3 files changed, 204 insertions(+)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 77ca3a4..b7d6c6e 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -192,6 +192,10 @@ extern void get_page_bootmem(unsigned long ingo, struct
page *page,
void get_online_mems(void);
void put_online_mems(void);
+int add_persistent_memory(phys_addr_t phys_addr, size_t size,
+ void **o_virt_addr);
+void remove_persistent_memory(phys_addr_t phys_addr, size_t size);
+
#else /* ! CONFIG_MEMORY_HOTPLUG */
/*
* Stub functions for when hotplug is off
diff --git a/mm/Kconfig b/mm/Kconfig
index a03131b..05c9585 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -200,6 +200,29 @@ config MEMORY_HOTREMOVE
depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
depends on MIGRATION
+
+# User of PERSISTENT_MEMORY_SECTION should:
+# depends on PERSISTENT_MEMORY_DEPENDENCY and
+# select DRIVER_NEEDS_PERSISTENT_MEMORY
+# Note that it will not be enabled if MEMORY_HOTPLUG is not enabled
+#
+# If you have changed the dependency/select of MEMORY_HOTREMOVE please also
+# update here
+#
+config PERSISTENT_MEMORY_DEPENDENCY
+ def_bool y
+ depends on MEMORY_HOTPLUG
+ depends on ARCH_ENABLE_MEMORY_HOTREMOVE && MIGRATION
+
+config DRIVER_NEEDS_PERSISTENT_MEMORY
+ bool
+
+config PERSISTENT_MEMORY_SECTION
+ def_bool y
+ depends on PERSISTENT_MEMORY_DEPENDENCY
+ depends on DRIVER_NEEDS_PERSISTENT_MEMORY
+ select MEMORY_HOTREMOVE
+
#
# If we have space for more page flags then we can enable additional
# optimizations and functionality.
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 7a73d30..416efdb 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -2025,3 +2025,180 @@ void __ref remove_memory(int nid, u64 start, u64 size)
}
EXPORT_SYMBOL_GPL(remove_memory);
#endif /* CONFIG_MEMORY_HOTREMOVE */
+
+#ifdef CONFIG_PERSISTENT_MEMORY_SECTION
+
+/* This helper is so we do not need to allocate a page_array bigger
+ * than PAGE_SIZE
+ */
+static int _map_sec_range(ulong sec_start_pfn, struct page **page_array)
+{
+ const uint NUM_PAGES = PAGE_SIZE / sizeof(*page_array);
+ const uint ARRAYS_IN_SECTION = PAGES_PER_SECTION / NUM_PAGES;
+ ulong pfn = sec_start_pfn;
+ uint a;
+
+ for (a = 0; a < ARRAYS_IN_SECTION; ++a) {
+ ulong virt_addr = (ulong)page_address(pfn_to_page(pfn));
+ uint p;
+ int ret;
+
+ for (p = 0; p < NUM_PAGES; ++p)
+ page_array[p] = pfn_to_page(pfn++);
+
+ ret = map_kernel_range_noflush(virt_addr, NUM_PAGES * PAGE_SIZE,
+ PAGE_KERNEL, page_array);
+ if
[PATCH 5/8] mm: Let sparse_{add,remove}_one_section receive a node_id
From: Yigal Korman
Refactored the arguments of sparse_add_one_section / sparse_remove_one_section
to use node id instead of struct zone * - A memory section has no direct
connection to zones, all that was needed from zone was the node id.
This is for add_persistent_memory that will want a section of pages
allocated but without any zone associated. This is because belonging
to a zone will give the memory to the page allocators, but
persistent_memory belongs to a block device, and is not available for
regular volatile usage.
Signed-off-by: Yigal Korman
Signed-off-by: Boaz Harrosh
---
include/linux/memory_hotplug.h | 4 ++--
mm/memory_hotplug.c| 4 ++--
mm/sparse.c| 9 +
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 8f1a419..77ca3a4 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -265,8 +265,8 @@ extern int arch_add_memory(int nid, u64 start, u64 size);
extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
extern bool is_memblock_offlined(struct memory_block *mem);
extern void remove_memory(int nid, u64 start, u64 size);
-extern int sparse_add_one_section(struct zone *zone, unsigned long start_pfn);
-extern void sparse_remove_one_section(struct zone *zone, struct mem_section
*ms);
+extern int sparse_add_one_section(int nid, unsigned long start_pfn);
+extern void sparse_remove_one_section(int nid, struct mem_section *ms);
extern struct page *sparse_decode_mem_map(unsigned long coded_mem_map,
unsigned long pnum);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 9fab107..7a73d30 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -472,7 +472,7 @@ static int __meminit __add_section(int nid, struct zone
*zone,
if (pfn_valid(phys_start_pfn))
return -EEXIST;
- ret = sparse_add_one_section(zone, phys_start_pfn);
+ ret = sparse_add_one_section(zone->zone_pgdat->node_id, phys_start_pfn);
if (ret < 0)
return ret;
@@ -738,7 +738,7 @@ static int __remove_section(struct zone *zone, struct
mem_section *ms)
start_pfn = section_nr_to_pfn(scn_nr);
__remove_zone(zone, start_pfn);
- sparse_remove_one_section(zone, ms);
+ sparse_remove_one_section(zone->zone_pgdat->node_id, ms);
return 0;
}
diff --git a/mm/sparse.c b/mm/sparse.c
index d1b48b6..12a10ab 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -690,10 +690,10 @@ static void free_map_bootmem(struct page *memmap)
* set. If this is <=0, then that means that the passed-in
* map was not consumed and must be freed.
*/
-int __meminit sparse_add_one_section(struct zone *zone, unsigned long
start_pfn)
+int __meminit sparse_add_one_section(int nid, unsigned long start_pfn)
{
unsigned long section_nr = pfn_to_section_nr(start_pfn);
- struct pglist_data *pgdat = zone->zone_pgdat;
+ struct pglist_data *pgdat = NODE_DATA(nid);
struct mem_section *ms;
struct page *memmap;
unsigned long *usemap;
@@ -788,11 +788,11 @@ static void free_section_usemap(struct page *memmap,
unsigned long *usemap)
free_map_bootmem(memmap);
}
-void sparse_remove_one_section(struct zone *zone, struct mem_section *ms)
+void sparse_remove_one_section(int nid, struct mem_section *ms)
{
struct page *memmap = NULL;
unsigned long *usemap = NULL, flags;
- struct pglist_data *pgdat = zone->zone_pgdat;
+ struct pglist_data *pgdat = NODE_DATA(nid);
pgdat_resize_lock(pgdat, );
if (ms->section_mem_map) {
@@ -807,5 +807,6 @@ void sparse_remove_one_section(struct zone *zone, struct
mem_section *ms)
clear_hwpoisoned_pages(memmap, PAGES_PER_SECTION);
free_section_usemap(memmap, usemap);
}
+
#endif /* CONFIG_MEMORY_HOTREMOVE */
#endif /* CONFIG_MEMORY_HOTPLUG */
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bcma: Kconfig: Let it depend on PCI
> bcma also needs PCI, just like IOMEM and DMA, so let it depend on PCI, > or will cause building break for allmodconfig under c6x: > > CC [M] drivers/bcma/driver_pcie2.o > drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up': > drivers/bcma/driver_pcie2.c:196:8: error: implicit declaration of function > 'pcie_set_readrq' [-Werror=implicit-function-declaration] > err = pcie_set_readrq(dev, pcie2->reqsize); > ^ > > Signed-off-by: Chen Gang Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] pmem: Add support for direct_access()
From: Ross Zwisler
Also fixed a top the initial version
[boaz]
SQUASHME pmem: Micro optimization the hotpath 002
Signed-off-by: Ross Zwisler
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index 750ffdf..f0f0ba0 100644
--- a/drivers/block/pmem.c
+++ b/drivers/block/pmem.c
@@ -111,9 +111,25 @@ static int pmem_rw_page(struct block_device *bdev,
sector_t sector,
return 0;
}
+static long pmem_direct_access(struct block_device *bdev, sector_t sector,
+ void **kaddr, unsigned long *pfn, long size)
+{
+ struct pmem_device *pmem = bdev->bd_disk->private_data;
+ size_t offset = sector << 9;
+
+ if (unlikely(!pmem))
+ return -ENODEV;
+
+ *kaddr = pmem->virt_addr + offset;
+ *pfn = (pmem->phys_addr + offset) >> PAGE_SHIFT;
+
+ return pmem->size - offset;
+}
+
static const struct block_device_operations pmem_fops = {
.owner =THIS_MODULE,
.rw_page = pmem_rw_page,
+ .direct_access =pmem_direct_access,
};
/* Kernel module stuff */
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] pmem: Add support for rw_page()
From: Ross Zwisler
Based on commit a72132c31d58 ("brd: add support for rw_page()")
Signed-off-by: Ross Zwisler
---
drivers/block/pmem.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index bba53af..750ffdf 100644
--- a/drivers/block/pmem.c
+++ b/drivers/block/pmem.c
@@ -101,8 +101,19 @@ out:
bio_endio(bio, err);
}
+static int pmem_rw_page(struct block_device *bdev, sector_t sector,
+ struct page *page, int rw)
+{
+ struct pmem_device *pmem = bdev->bd_disk->private_data;
+
+ pmem_do_bvec(pmem, page, PAGE_CACHE_SIZE, 0, rw, sector);
+ page_endio(page, rw & WRITE, 0);
+ return 0;
+}
+
static const struct block_device_operations pmem_fops = {
.owner =THIS_MODULE,
+ .rw_page = pmem_rw_page,
};
/* Kernel module stuff */
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] pmem: KISS, remove register_blkdev
Though this looks revolutionary, it actually does nothing
but removes dead code.
Since the move of pmem to the dynamic BLOCK_EXT_MAJOR
range, by Ross, pmem_major returned from register_blkdev
is not used.
If inspecting the code at add_disk() we can see that
whatever number we will put at
disk->major = ...
disk->first_minor = ...
will be immediately overwritten with the BLOCK_EXT_MAJOR
and a dynamically allocated minor. Regardless of the
registration and/or what ever we put at disk->major.
I have tested all the tests that I know how to perform
on the devices, fdisk, partitions, multiple pmemX devices,
mknode, lsblk, blkid, and it all behaves exactly as
before this patch.
I have also done:
find /sys/ -name "*pmem*"
find /proc/ -name "*pmem*"
find /dev/ -name "*pmem*"
And get the same output as before this patch.
The only thing missing is an entry in /proc/devices of
the form: "250 pmem" (250 or what ever is free at the moment)
But this is good because if one tries to look for 250
devices after loading pmem he will fail because pmem
is always registered as 259 (blkext) now.
If anyone knows of what would work differently after this
patch please do tell.
But it looks like the calls to register_blkdev is just dead
code for us right now
Thanks
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index 02cd118..bba53af 100644
--- a/drivers/block/pmem.c
+++ b/drivers/block/pmem.c
@@ -113,7 +113,6 @@ MODULE_PARM_DESC(map,
"mapS=nn[KMG]$ss[KMG] or mapS=nn[KMG]@ss[KMG], nn=size, ss=offset.");
static LIST_HEAD(pmem_devices);
-static int pmem_major;
/* pmem->phys_addr and pmem->size need to be set.
* Will then set virt_addr if successful.
@@ -204,8 +203,6 @@ static struct pmem_device *pmem_alloc(phys_addr_t
phys_addr, size_t disk_size,
goto out_free_queue;
}
- disk->major = pmem_major;
- disk->first_minor = 0;
disk->fops = _fops;
disk->private_data = pmem;
disk->queue = pmem->pmem_queue;
@@ -268,12 +265,6 @@ static int __init pmem_init(void)
return -EINVAL;
}
- result = register_blkdev(0, "pmem");
- if (unlikely(result < 0))
- return -EIO;
-
- pmem_major = result;
-
map_dup = pmem_map = kstrdup(map, GFP_KERNEL);
if (unlikely(!pmem_map)) {
pr_debug("pmem_init strdup(%s) failed\n", map);
@@ -312,7 +303,6 @@ out_free:
pmem_free(pmem);
}
kfree(map_dup);
- unregister_blkdev(pmem_major, "pmem");
return result;
}
@@ -324,7 +314,6 @@ static void __exit pmem_exit(void)
list_for_each_entry_safe(pmem, next, _devices, pmem_list)
pmem_del_one(pmem);
- unregister_blkdev(pmem_major, "pmem");
pr_info("pmem: module unloaded\n");
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] pmem: Initial version of persistent memory driver
From: Ross Zwisler PMEM is a new driver That supports any physical contiguous iomem range as a single block device. The driver has support for as many as needed iomem ranges each as its own device. The driver is not only good for NvDIMMs, It is good for any flat memory mapped device. We've used it with NvDIMMs, Kernel reserved DRAM (memmap= on command line), PCIE Battery backed memory cards, VM shared memory, and so on. The API to pmem module a single string parameter named "map" of the form: map=mapS[,mapS...] where mapS=nn[KMG]$ss[KMG], ormapS=nn[KMG]@ss[KMG], nn=size, ss=offset Just like the Kernel command line map && memmap parameters, so anything you did at grub just copy/paste to here. The "@" form is exactly the same as the "$" form only that at bash prompt we need to escape the "$" with \$ so also support the '@' char for convenience. For each specified mapS there will be a device created. [This is the accumulated version of the driver developed by multiple programmers. To see the real history of these patches see: git://git.open-osd.org/pmem.git https://github.com/01org/prd This patch is based on (git://git.open-osd.org/pmem.git): [5ccf703] SQUASHME: Don't clobber the map module param [boaz] SQUASHME: pmem: Remove unused #include headers SQUASHME: pmem: Request from fdisk 4k alignment SQUASHME: pmem: Let each device manage private memory region SQUASHME: pmem: Support of multiple memory regions SQUASHME: pmem: Micro optimization the hotpath 001 SQUASHME: pmem: no need to copy a page at a time SQUASHME: pmem that 4k sector thing SQUASHME: pmem: Cleanliness is neat SQUASHME: Don't clobber the map module param SQUASHME: pmem: Few changes to Initial version of pmem SQUASHME: Changes to copyright text (trivial) TODO: Add Documentation/blockdev/pmem.txt Need-signed-by: Ross Zwisler Signed-off-by: Boaz Harrosh --- MAINTAINERS| 7 ++ drivers/block/Kconfig | 18 +++ drivers/block/Makefile | 1 + drivers/block/pmem.c | 334 + 4 files changed, 360 insertions(+) create mode 100644 drivers/block/pmem.c diff --git a/MAINTAINERS b/MAINTAINERS index ddc5a8c..21c5384 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8053,6 +8053,13 @@ S: Maintained F: Documentation/blockdev/ramdisk.txt F: drivers/block/brd.c +PERSISTENT MEMORY DRIVER +M: Ross Zwisler +M: Boaz Harrosh +L: linux-nvd...@lists.01.org +S: Supported +F: drivers/block/pmem.c + RANDOM NUMBER DRIVER M: "Theodore Ts'o" S: Maintained diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 1b8094d..1530c2a 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -404,6 +404,24 @@ config BLK_DEV_RAM_DAX and will prevent RAM block device backing store memory from being allocated from highmem (only a problem for highmem systems). +config BLK_DEV_PMEM + tristate "pmem: Persistent memory block device support" + help + If you have Persistent memory in your system say Y/m + here. The driver can support real Persistent memory chips + such as NVDIMMs , as well as volatile memory that was set + aside from Kernel use by the "memmap" kernel parameter. + And/or any contiguous physical memory ranges that you want + to represent as a block device. (Even PCIE flat memory mapped + devices) + See Documentation/block/pmem.txt for how to use + + To compile this driver as a module, choose M here: the module will be + called pmem. Created Devices will be named: /dev/pmemX + + Most normal users won't need this functionality, and can thus say N + here. + config CDROM_PKTCDVD tristate "Packet writing on CD/DVD media" depends on !UML diff --git a/drivers/block/Makefile b/drivers/block/Makefile index 02b688d..9cc6c18 100644 --- a/drivers/block/Makefile +++ b/drivers/block/Makefile @@ -14,6 +14,7 @@ obj-$(CONFIG_PS3_VRAM)+= ps3vram.o obj-$(CONFIG_ATARI_FLOPPY) += ataflop.o obj-$(CONFIG_AMIGA_Z2RAM) += z2ram.o obj-$(CONFIG_BLK_DEV_RAM) += brd.o +obj-$(CONFIG_BLK_DEV_PMEM) += pmem.o obj-$(CONFIG_BLK_DEV_LOOP) += loop.o obj-$(CONFIG_BLK_CPQ_DA) += cpqarray.o obj-$(CONFIG_BLK_CPQ_CISS_DA) += cciss.o diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c new file mode 100644 index 000..02cd118 --- /dev/null +++ b/drivers/block/pmem.c @@ -0,0 +1,334 @@ +/* + * Persistent Memory Driver + * Copyright (c) 2014, Intel Corporation. + * Copyright (c) 2014, Boaz Harrosh . + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but
Re: Fwd: Re: unbind/bind w1-gpio with device tree produce a crash
Dear Markus, Am 05.03.2015 um 08:35 schrieb Markus Pargmann: Good point. The easy way to solve this may be to check in the remove function if the devicetree node for this device is available. If it is, we know that platform_data was allocated with devm_* and we can set platform_data to NULL. I think the better solution would be to create a private structure with the same data as w1_gpio_platform_data. It may even use the same struct. But it should not be stored in platform_data. Instead it should be handled seperately. For DT we can allocate it using devm_kzalloc(). And for probing with pdata, this could just be the pointer to the pdata within the device struct. Could you give me more details about the "private structure" idea, perhaps off-list? The backup method via w1_gpio_*_orig collides when more than 1 bus is used, this data could be stored in the private structure too. Kind regards, Ingo Flaschberger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/6] watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND
Hi Boris, TL;DR - I guess using IRQF_NO_SUSPEND for now is OK a a best-effort approach for now, so don't let my comments block this patch. However, there are still some potential issues in what would already be a failure case: your usual wakeup mechanism not waking the system up in time to poke the watchdog, and then the watchdog raising an IRQ that never gets taken because the system is in a suspended state. > > Is the timer we use to ping the watchdog guaranted to result in a wakeup > > before an interrupt will be triggered? If so, then I think we're ok. > > It should be (I don't recall exactly what the logic is, but it's at > least half the watchdog time limit). Ok. If that's the case then my main fear is gone. [...] > If we want the watchdog to be inactive when entering suspend, then we > shouldn't reboot the machine when receiving a watchdog irq while the > system is suspended. For this I would expect IRQF_COND_SUSPEND, because we don't care about the suspended case. We just don't want to negatively impact the timers. > ITOH, with the hardware mode (reset handled by the watchdog IP) you > can't disable the watchdog when entering suspend, so I would expect the > same behavior for the SW mode. For this I would expect IRQF_COND_SUSPEND and enable_irq_wake(). If we really want a wakeup IRQ guaranteed to be called immediately (without bothering to do most of the resume work first), none of the current semantics align. > > Regardless, if the only reason we care about taking the interrupt during > > the suspend/resume phases is due to the timer sharing the IRQ, then > > shouldn't we be using IRQF_COND_SUSPEND? > > I'm not sure, but IMO this interrupt should be flagged as NO_SUSPEND, > because it's here to reset the system (even if it is suspended). > If you flag the irq line as COND_SUSPEND, and atmel decide to give this > peripheral its own IRQ line (on new SoCs), then your watchdog will not > reboot the system when it is suspended. > Another solution would be to support wakeup for this peripheral and > delay the system reboot until it has resumed. >From the above it sounds like we'd need wakeup and guaranteed immediate handler calling. That either needs rethink of IRQF_NO_SUSPEND + enable_irq_wake(), or something like a new IRQF_SW_WATCHDOG + enable_irq_wake(). > Anyway, if we decide to go for the wakeup approach, I'd prefer to post > another patch on top of this one. If everyone else is happy with this using IRQF_NO_SUSPEND for now then don't let my comments above block this patch. Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 16/21] irqchip: Add GICv2 specific ACPI boot support
On Wed, Mar 04, 2015 at 11:50:36PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, February 25, 2015 04:39:56 PM Hanjun Guo wrote:
> > From: Tomasz Nowicki
> >
> > ACPI kernel uses MADT table for proper GIC initialization. It needs to
> > parse GIC related subtables, collect CPU interface and distributor
> > addresses and call driver initialization function (which is hardware
> > abstraction agnostic). In a similar way, FDT initialize GICv1/2.
> >
> > NOTE: This commit allow to initialize GICv1/2 basic functionality.
> > While now simple GICv2 init call is used, any further GIC features
> > require generic infrastructure for proper ACPI irqchip initialization.
> > That mechanism and stacked irqdomains to support GICv2 MSI/virtualization
> > extension, GICv3/4 and its ITS are considered as next steps.
> >
> > CC: Jason Cooper
> > CC: Marc Zyngier
> > CC: Thomas Gleixner
> > Tested-by: Suravee Suthikulpanit
> > Tested-by: Yijing Wang
> > Tested-by: Mark Langsdorf
> > Tested-by: Jon Masters
> > Tested-by: Timur Tabi
> > Tested-by: Robert Richter
> > Acked-by: Robert Richter
> > Signed-off-by: Tomasz Nowicki
> > Signed-off-by: Hanjun Guo
> > ---
> > arch/arm64/include/asm/acpi.h| 2 +
> > arch/arm64/kernel/acpi.c | 25 +
> > drivers/irqchip/irq-gic.c| 102
> > +++
> > drivers/irqchip/irqchip.c| 3 ++
> > include/linux/acpi.h | 14 +
> > include/linux/irqchip/arm-gic-acpi.h | 29 ++
> > 6 files changed, 175 insertions(+)
> > create mode 100644 include/linux/irqchip/arm-gic-acpi.h
> >
> > diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> > index 9a23369..a720a61 100644
> > --- a/arch/arm64/include/asm/acpi.h
> > +++ b/arch/arm64/include/asm/acpi.h
> > @@ -13,6 +13,8 @@
> > #define _ASM_ACPI_H
> >
> > #include
> > +#include
> > +
> > #include
> > #include
> >
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index 31f080e..af308c3 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -359,3 +359,28 @@ void __init acpi_boot_table_init(void)
> > pr_err("Can't find FADT\n");
> > }
> > }
> > +
> > +void __init acpi_gic_init(void)
> > +{
> > + struct acpi_table_header *table;
> > + acpi_status status;
> > + acpi_size tbl_size;
> > + int err;
> > +
> > + if (acpi_disabled)
> > + return;
> > +
> > + status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, , _size);
> > + if (ACPI_FAILURE(status)) {
> > + const char *msg = acpi_format_exception(status);
> > +
> > + pr_err("Failed to get MADT table, %s\n", msg);
> > + return;
> > + }
> > +
> > + err = gic_v2_acpi_init(table);
> > + if (err)
> > + pr_err("Failed to initialize GIC IRQ controller");
> > +
> > + early_acpi_os_unmap_memory((char *)table, tbl_size);
> > +}
> > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > index 4634cf7..929d668 100644
> > --- a/drivers/irqchip/irq-gic.c
> > +++ b/drivers/irqchip/irq-gic.c
> > @@ -33,12 +33,14 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -1086,3 +1088,103 @@ IRQCHIP_DECLARE(msm_8660_qgic,
> > "qcom,msm-8660-qgic", gic_of_init);
> > IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
> >
> > #endif
> > +
> > +#ifdef CONFIG_ACPI
> > +static phys_addr_t dist_phy_base, cpu_phy_base __initdata;
> > +
> > +static int __init
> > +gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
> > + const unsigned long end)
> > +{
> > + struct acpi_madt_generic_interrupt *processor;
> > + phys_addr_t gic_cpu_base;
> > + static int cpu_base_assigned;
> > +
> > + processor = (struct acpi_madt_generic_interrupt *)header;
> > +
> > + if (BAD_MADT_ENTRY(processor, end))
> > + return -EINVAL;
> > +
> > + /*
> > +* There is no support for non-banked GICv1/2 register in ACPI spec.
> > +* All CPU interface addresses have to be the same.
> > +*/
> > + gic_cpu_base = processor->base_address;
> > + if (cpu_base_assigned && gic_cpu_base != cpu_phy_base)
> > + return -EINVAL;
> > +
> > + cpu_phy_base = gic_cpu_base;
> > + cpu_base_assigned = 1;
> > + return 0;
> > +}
> > +
> > +static int __init
> > +gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
> > + const unsigned long end)
> > +{
> > + struct acpi_madt_generic_distributor *dist;
> > +
> > + dist = (struct acpi_madt_generic_distributor *)header;
> > +
> > + if (BAD_MADT_ENTRY(dist, end))
> > + return -EINVAL;
> > +
> > + dist_phy_base = dist->base_address;
> > + return 0;
> > +}
> > +
> > +int __init
> > +gic_v2_acpi_init(struct acpi_table_header *table)
[tip:x86/mm] x86/mm/pat: Initialize __cachemode2pte_tbl[] and __pte2cachemode_tbl[] in a bit more readable fashion
Commit-ID: c709feda56886c38af3116254f84cbe6a78b3a5d
Gitweb: http://git.kernel.org/tip/c709feda56886c38af3116254f84cbe6a78b3a5d
Author: Ingo Molnar
AuthorDate: Thu, 5 Mar 2015 08:58:44 +0100
Committer: Ingo Molnar
CommitDate: Thu, 5 Mar 2015 09:48:17 +0100
x86/mm/pat: Initialize __cachemode2pte_tbl[] and __pte2cachemode_tbl[] in a bit
more readable fashion
The initialization of these two arrays is a bit difficult to follow:
restructure it optically so that a 2D structure shows which bit in
the PTE is set and which not.
Also improve on comments a bit.
No code or data changed:
# arch/x86/mm/init.o:
textdata bss dec hex filename
4585 424 29776 3478587e1 init.o.before
4585 424 29776 3478587e1 init.o.after
md5:
a82e11ff58bcfd0af3a94662a701f65d init.o.before.asm
a82e11ff58bcfd0af3a94662a701f65d init.o.after.asm
Reviewed-by: Juergen Gross
Cc: Andy Lutomirski
Cc: Dave Hansen
Cc: Jan Beulich
Cc: Linus Torvalds
Cc: Luis R. Rodriguez
Cc: Toshi Kani
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/20150305082135.gb5...@gmail.com
Signed-off-by: Ingo Molnar
---
arch/x86/mm/init.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 6dc85d5..4469563 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -29,29 +29,33 @@
/*
* Tables translating between page_cache_type_t and pte encoding.
- * Minimal supported modes are defined statically, modified if more supported
- * cache modes are available.
- * Index into __cachemode2pte_tbl is the cachemode.
- * Index into __pte2cachemode_tbl are the caching attribute bits of the pte
- * (_PAGE_PWT, _PAGE_PCD, _PAGE_PAT) at index bit positions 0, 1, 2.
+ *
+ * Minimal supported modes are defined statically, they are modified
+ * during bootup if more supported cache modes are available.
+ *
+ * Index into __cachemode2pte_tbl[] is the cachemode.
+ *
+ * Index into __pte2cachemode_tbl[] are the caching attribute bits of the pte
+ * (_PAGE_PWT, _PAGE_PCD, _PAGE_PAT) at index bit positions 0, 1, 2.
*/
uint16_t __cachemode2pte_tbl[_PAGE_CACHE_MODE_NUM] = {
- [_PAGE_CACHE_MODE_WB] = 0,
- [_PAGE_CACHE_MODE_WC] = _PAGE_PWT,
- [_PAGE_CACHE_MODE_UC_MINUS] = _PAGE_PCD,
- [_PAGE_CACHE_MODE_UC] = _PAGE_PCD | _PAGE_PWT,
- [_PAGE_CACHE_MODE_WT] = _PAGE_PCD,
- [_PAGE_CACHE_MODE_WP] = _PAGE_PCD,
+ [_PAGE_CACHE_MODE_WB ] = 0 | 0,
+ [_PAGE_CACHE_MODE_WC ] = _PAGE_PWT | 0,
+ [_PAGE_CACHE_MODE_UC_MINUS] = 0 | _PAGE_PCD,
+ [_PAGE_CACHE_MODE_UC ] = _PAGE_PWT | _PAGE_PCD,
+ [_PAGE_CACHE_MODE_WT ] = 0 | _PAGE_PCD,
+ [_PAGE_CACHE_MODE_WP ] = 0 | _PAGE_PCD,
};
EXPORT_SYMBOL(__cachemode2pte_tbl);
+
uint8_t __pte2cachemode_tbl[8] = {
- [__pte2cm_idx(0)] = _PAGE_CACHE_MODE_WB,
- [__pte2cm_idx(_PAGE_PWT)] = _PAGE_CACHE_MODE_WC,
- [__pte2cm_idx(_PAGE_PCD)] = _PAGE_CACHE_MODE_UC_MINUS,
- [__pte2cm_idx(_PAGE_PWT | _PAGE_PCD)] = _PAGE_CACHE_MODE_UC,
- [__pte2cm_idx(_PAGE_PAT)] = _PAGE_CACHE_MODE_WB,
- [__pte2cm_idx(_PAGE_PWT | _PAGE_PAT)] = _PAGE_CACHE_MODE_WC,
- [__pte2cm_idx(_PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC_MINUS,
+ [__pte2cm_idx( 0| 0 | 0)] = _PAGE_CACHE_MODE_WB,
+ [__pte2cm_idx(_PAGE_PWT | 0 | 0)] = _PAGE_CACHE_MODE_WC,
+ [__pte2cm_idx( 0| _PAGE_PCD | 0)] =
_PAGE_CACHE_MODE_UC_MINUS,
+ [__pte2cm_idx(_PAGE_PWT | _PAGE_PCD | 0)] = _PAGE_CACHE_MODE_UC,
+ [__pte2cm_idx( 0| 0 | _PAGE_PAT)] = _PAGE_CACHE_MODE_WB,
+ [__pte2cm_idx(_PAGE_PWT | 0 | _PAGE_PAT)] = _PAGE_CACHE_MODE_WC,
+ [__pte2cm_idx(0 | _PAGE_PCD | _PAGE_PAT)] =
_PAGE_CACHE_MODE_UC_MINUS,
[__pte2cm_idx(_PAGE_PWT | _PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC,
};
EXPORT_SYMBOL(__pte2cachemode_tbl);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] x86/mm: Use early_param_on_off() for direct_gbpages
Commit-ID: 73c8c861dc5bddf1b24c6aeffee2292c96cf8db2
Gitweb: http://git.kernel.org/tip/73c8c861dc5bddf1b24c6aeffee2292c96cf8db2
Author: Luis R. Rodriguez
AuthorDate: Wed, 4 Mar 2015 17:24:14 -0800
Committer: Ingo Molnar
CommitDate: Thu, 5 Mar 2015 08:02:12 +0100
x86/mm: Use early_param_on_off() for direct_gbpages
The enabler / disabler is pretty simple, just use the
provided wrappers, this lets us easily relate the variable
to the associated Kconfig entry.
Signed-off-by: Luis R. Rodriguez
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: David Vrabel
Cc: Dexuan Cui
Cc: Greg Kroah-Hartman
Cc: H. Peter Anvin
Cc: jbeul...@suse.com
Cc: Jan Beulich
Cc: Joonsoo Kim
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Tony Lindgren
Cc: Toshi Kani
Cc: Vlastimil Babka
Cc: Xishi Qiu
Cc: julia.law...@lip6.fr
Link:
http://lkml.kernel.org/r/1425518654-3403-5-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
arch/x86/mm/init.c| 3 ++-
arch/x86/mm/init_64.c | 14 --
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 2ce2c8e..c35ba8b 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -133,7 +133,8 @@ int after_bootmem;
static int page_size_mask;
-int direct_gbpages = IS_ENABLED(CONFIG_DIRECT_GBPAGES);
+early_param_on_off("gbpages", "nogbpages",
+ direct_gbpages, CONFIG_DIRECT_GBPAGES);
static void __init init_gbpages(void)
{
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 30eb05a..3fba623 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -130,20 +130,6 @@ int kernel_ident_mapping_init(struct x86_mapping_info
*info, pgd_t *pgd_page,
return 0;
}
-static int __init parse_direct_gbpages_off(char *arg)
-{
- direct_gbpages = 0;
- return 0;
-}
-early_param("nogbpages", parse_direct_gbpages_off);
-
-static int __init parse_direct_gbpages_on(char *arg)
-{
- direct_gbpages = 1;
- return 0;
-}
-early_param("gbpages", parse_direct_gbpages_on);
-
/*
* NOTE: pagetable_init alloc all the fixmap pagetables contiguous on the
* physical space so we can cache the place of the first one and move
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] x86/mm: Use IS_ENABLED() for direct_gbpages
Commit-ID: d9fd579c218e22c897f0f1b9e132af9b436cf445
Gitweb: http://git.kernel.org/tip/d9fd579c218e22c897f0f1b9e132af9b436cf445
Author: Luis R. Rodriguez
AuthorDate: Wed, 4 Mar 2015 17:24:11 -0800
Committer: Ingo Molnar
CommitDate: Thu, 5 Mar 2015 08:02:11 +0100
x86/mm: Use IS_ENABLED() for direct_gbpages
Replace #ifdef eyesore with IS_ENABLED() use.
Signed-off-by: Luis R. Rodriguez
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: David Vrabel
Cc: Dexuan Cui
Cc: Greg Kroah-Hartman
Cc: H. Peter Anvin
Cc: jbeul...@suse.com
Cc: Jan Beulich
Cc: Joonsoo Kim
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Tony Lindgren
Cc: Toshi Kani
Cc: Vlastimil Babka
Cc: Xishi Qiu
Cc: julia.law...@lip6.fr
Link:
http://lkml.kernel.org/r/1425518654-3403-2-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
arch/x86/mm/init.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index a110efc..74f2b37 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -131,11 +131,7 @@ void __init early_alloc_pgt_buf(void)
int after_bootmem;
-int direct_gbpages
-#ifdef CONFIG_DIRECT_GBPAGES
- = 1
-#endif
-;
+int direct_gbpages = IS_ENABLED(CONFIG_DIRECT_GBPAGES);
static void __init init_gbpages(void)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] x86/mm: Simplify enabling direct_gbpages
Commit-ID: e5008abe929c160d36e44b8c2b644d4330d2e389
Gitweb: http://git.kernel.org/tip/e5008abe929c160d36e44b8c2b644d4330d2e389
Author: Luis R. Rodriguez
AuthorDate: Wed, 4 Mar 2015 17:24:12 -0800
Committer: Ingo Molnar
CommitDate: Thu, 5 Mar 2015 08:02:12 +0100
x86/mm: Simplify enabling direct_gbpages
direct_gbpages can be force enabled as an early parameter
but not really have taken effect when DEBUG_PAGEALLOC
or KMEMCHECK is enabled. You can also enable direct_gbpages
right now if you have an x86_64 architecture but your CPU
doesn't really have support for this feature. In both cases
PG_LEVEL_1G won't actually be enabled but direct_gbpages is used
in other areas under the assumptions that PG_LEVEL_1G
was set. Fix this by putting together all requirements
which make this feature sensible to enable under, and only
enable both finally flipping on PG_LEVEL_1G and leaving
PG_LEVEL_1G set when this is true.
We only enable this feature then to be possible on sensible
builds defined by the new ENABLE_DIRECT_GBPAGES. If the
CPU has support for it you can either enable this by using
the DIRECT_GBPAGES option or using the early kernel parameter.
If a platform had support for this you can always force disable
it as well.
Signed-off-by: Luis R. Rodriguez
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: David Vrabel
Cc: Dexuan Cui
Cc: Greg Kroah-Hartman
Cc: H. Peter Anvin
Cc: jbeul...@suse.com
Cc: Jan Beulich
Cc: Joonsoo Kim
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Tony Lindgren
Cc: Toshi Kani
Cc: Vlastimil Babka
Cc: Xishi Qiu
Cc: julia.law...@lip6.fr
Link:
http://lkml.kernel.org/r/1425518654-3403-3-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
arch/x86/Kconfig | 18 +-
arch/x86/mm/init.c | 17 +
arch/x86/mm/pageattr.c | 2 --
3 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c2fb8a8..4d06e1c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1299,14 +1299,22 @@ config ARCH_DMA_ADDR_T_64BIT
def_bool y
depends on X86_64 || HIGHMEM64G
+config ENABLE_DIRECT_GBPAGES
+ def_bool y
+ depends on X86_64 && !DEBUG_PAGEALLOC && !KMEMCHECK
+
config DIRECT_GBPAGES
bool "Enable 1GB pages for kernel pagetables" if EXPERT
default y
- depends on X86_64
- ---help---
- Allow the kernel linear mapping to use 1GB pages on CPUs that
- support it. This can improve the kernel's performance a tiny bit by
- reducing TLB pressure. If in doubt, say "Y".
+ depends on ENABLE_DIRECT_GBPAGES
+ ---help---
+ Enable by default the kernel linear mapping to use 1GB pages on CPUs
+ that support it. This can improve the kernel's performance a tiny bit
+ by reducing TLB pressure. If in doubt, say "Y". If you've disabled
+ option but your platform is capable of handling support for this
+ you can use the gbpages kernel parameter. Likewise if you've enabled
+ this but you'd like to force disable this option you can use the
+ nogbpages kernel parameter.
# Common NUMA Features
config NUMA
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 74f2b37..2ce2c8e 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -131,16 +131,21 @@ void __init early_alloc_pgt_buf(void)
int after_bootmem;
+static int page_size_mask;
+
int direct_gbpages = IS_ENABLED(CONFIG_DIRECT_GBPAGES);
static void __init init_gbpages(void)
{
-#ifdef CONFIG_X86_64
- if (direct_gbpages && cpu_has_gbpages)
+ if (!IS_ENABLED(CONFIG_ENABLE_DIRECT_GBPAGES)) {
+ direct_gbpages = 0;
+ return;
+ }
+ if (direct_gbpages && cpu_has_gbpages) {
printk(KERN_INFO "Using GB pages for direct mapping\n");
- else
+ page_size_mask |= 1 << PG_LEVEL_1G;
+ } else
direct_gbpages = 0;
-#endif
}
struct map_range {
@@ -149,8 +154,6 @@ struct map_range {
unsigned page_size_mask;
};
-static int page_size_mask;
-
static void __init probe_page_size_mask(void)
{
init_gbpages();
@@ -161,8 +164,6 @@ static void __init probe_page_size_mask(void)
* This will simplify cpa(), which otherwise needs to support splitting
* large pages into small in interrupt context, etc.
*/
- if (direct_gbpages)
- page_size_mask |= 1 << PG_LEVEL_1G;
if (cpu_has_pse)
page_size_mask |= 1 << PG_LEVEL_2M;
#endif
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 81e8282..89af288 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -81,11 +81,9 @@ void arch_report_meminfo(struct seq_file *m)
seq_printf(m, "DirectMap4M:%8lu kB\n",
direct_pages_count[PG_LEVEL_2M]
Re: [PATCH] locks: fix fasync_struct memory leak in lease upgrade/downgrade handling
On Thu, 5 Mar 2015 07:57:09 +0100 Daniel Wagner wrote: > Hi Jeff, > > On 03/05/2015 01:06 AM, Jeff Layton wrote: > > Commit 8634b51f6ca2 (locks: convert lease handling to file_lock_context) > > introduced a regression in the handling of lease upgrade/downgrades. > > > > In the event that we already have a lease on a file and are going to > > either upgrade or downgrade it, we skip doing any list insertion or > > deletion and skip to re-calling lm_setup on the existing lease. > > > > As of commit 8634b51f6ca2 however, we end up calling lm_setup on the > > lease that was passed in, instead of on the existing lease. This causes > > us to leak the fasync_struct that was allocated in the event that there > > was not already an existing one (as it always appeared that there > > wasn't one). > > > > Fixes: 8634b51f6ca2 (locks: convert lease handling to file_lock_context) > > Yes, that fixes the problem. Thanks! > > > Reported-by: Daniel Wagner > > Signed-off-by: Jeff Layton > > Tested-by: Daniel Wagner > > > cheers, > daniel Thanks for testing it! I'll let it soak in linux-next for a day or so and then send a pull request to Linus. Cheers! -- Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] init.h: Add early_param_on_off()
Commit-ID: bfb33bad83f650f265ed65cbfe8352b7c3ce8c76
Gitweb: http://git.kernel.org/tip/bfb33bad83f650f265ed65cbfe8352b7c3ce8c76
Author: Luis R. Rodriguez
AuthorDate: Wed, 4 Mar 2015 17:24:13 -0800
Committer: Ingo Molnar
CommitDate: Thu, 5 Mar 2015 08:02:12 +0100
init.h: Add early_param_on_off()
At times all you need is a kconfig variable to enable a feature,
by default but you may want to also enable / disable it through
a kernel parameter. In such cases the parameter routines to turn
the thing on / off are really simple. Just use a wrapper for
this, it lets us generalize the code and makes it easier to
associate parameters with related kernel configuration options.
Signed-off-by: Luis R. Rodriguez
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: David Vrabel
Cc: Dexuan Cui
Cc: Greg Kroah-Hartman
Cc: H. Peter Anvin
Cc: jbeul...@suse.com
Cc: Jan Beulich
Cc: Joonsoo Kim
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Tony Lindgren
Cc: Toshi Kani
Cc: Vlastimil Babka
Cc: Xishi Qiu
Cc: julia.law...@lip6.fr
Link:
http://lkml.kernel.org/r/1425518654-3403-4-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Ingo Molnar
---
include/linux/init.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/init.h b/include/linux/init.h
index 2df8e8d..bc11ff9 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -268,6 +268,21 @@ struct obs_kernel_param {
#define early_param(str, fn) \
__setup_param(str, fn, fn, 1)
+#define early_param_on_off(str_on, str_off, var, config)
\
+ int var = IS_ENABLED(config); \
+ static int __init parse_##var##_on(char *arg) \
+ { \
+ var = 1;\
+ return 0; \
+ } \
+ static int __init parse_##var##_off(char *arg) \
+ { \
+ var = 0;\
+ return 0; \
+ } \
+ __setup_param(str_on, parse_##var##_on, parse_##var##_on, 1); \
+ __setup_param(str_off, parse_##var##_off, parse_##var##_off, 1)
+
/* Relies on boot_command_line being set */
void __init parse_early_param(void);
void __init parse_early_options(char *cmdline);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimization
Commit-ID: 956421fbb74c3a6261903f3836c0740187cf038b Gitweb: http://git.kernel.org/tip/956421fbb74c3a6261903f3836c0740187cf038b Author: Andy Lutomirski AuthorDate: Thu, 5 Mar 2015 01:09:44 +0100 Committer: Ingo Molnar CommitDate: Thu, 5 Mar 2015 01:12:23 +0100 x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimization 'ret_from_fork' checks TIF_IA32 to determine whether 'pt_regs' and the related state make sense for 'ret_from_sys_call'. This is entirely the wrong check. TS_COMPAT would make a little more sense, but there's really no point in keeping this optimization at all. This fixes a return to the wrong user CS if we came from int 0x80 in a 64-bit task. Signed-off-by: Andy Lutomirski Cc: Borislav Petkov Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Thomas Gleixner Cc: Link: http://lkml.kernel.org/r/4710be56d76ef994ddf59087aad98c000fbab9a4.1424989793.git.l...@amacapital.net [ Backported from tip:x86/asm. ] Signed-off-by: Ingo Molnar --- arch/x86/kernel/entry_64.S | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 10074ad..1d74d16 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -269,11 +269,14 @@ ENTRY(ret_from_fork) testl $3, CS-ARGOFFSET(%rsp)# from kernel_thread? jz 1f - testl $_TIF_IA32, TI_flags(%rcx)# 32-bit compat task needs IRET - jnz int_ret_from_sys_call - - RESTORE_TOP_OF_STACK %rdi, -ARGOFFSET - jmp ret_from_sys_call # go to the SYSRET fastpath + /* +* By the time we get here, we have no idea whether our pt_regs, +* ti flags, and ti status came from the 64-bit SYSCALL fast path, +* the slow path, or one of the ia32entry paths. +* Use int_ret_from_sys_call to return, since it can safely handle +* all of the above. +*/ + jmp int_ret_from_sys_call 1: subq $REST_SKIP, %rsp # leave space for volatiles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH wq/for-4.0-fixes v2] workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE
On Thu, Mar 05, 2015 at 04:36:38AM -0500, Tejun Heo wrote: > On Thu, Mar 05, 2015 at 10:24:50AM +0100, Tomeu Vizoso wrote: > ... > > [ 317.251001] PC is at bit_waitqueue+0x38/0x6c > ... > > [ 317.420658] [] (bit_waitqueue) from [] > > (__cancel_work_timer+0x28/0x1b0) > > [ 317.430598] [] (__cancel_work_timer) from [] > > (cancel_work_sync+0x1c/0x20) > > [ 317.440672] [] (cancel_work_sync) from [] > > (regulatory_exit+0x24/0x17c [cfg80211]) > > [ 317.451396] [] (regulatory_exit [cfg80211]) from > > [] (cfg80211_exit+0x38/0x4c [cfg80211]) > > [ 317.462726] [] (cfg80211_exit [cfg80211]) from > > [] (SyS_delete_module+0x1b4/0x1f8) > > [ 317.473411] [] (SyS_delete_module) from [] > > (ret_fast_syscall+0x0/0x34) > > Ah, I think that's from feeding static address to virt_to_page. :( > Reverted the patch from the branch. Will think more about what to do. So, it's from feeding a static address of a module which is allocated on the vmalloc space to bit_waitqueue() which then tries to find out the backing page struct which vmalloc area obviously doesn't have. Currently testing an alternative patch which uses a single waitqueue w/ a custom wakeup function which can filter the target work item. Will soon post the new version. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ASoC: Add support for NAU8824 codec to ASoC
On Wed, Mar 04, 2015 at 11:32:12PM +0100, Paul Bolle wrote:
> Chih-Chiang Chang schreef op wo 04-03-2015 om 20:53 [+0800]:
> > +struct nau8824_platform_data {
> In the future something other than just sound/soc/codecs/nau8824.h is
> going to include this header, right?
It's platform data, that's the whole point of platform data...
signature.asc
Description: Digital signature
[PATCH] mfd: rt5033: MFD_RT5033 needs to select REGMAP_IRQ
Since commit 0b2712585(linux-next.git) this driver uses regmap_irq and so needs to select REGMAP_IRQ. This fixes the following compilation errors: ERROR: "regmap_irq_get_domain" [drivers/mfd/rt5033.ko] undefined! ERROR: "regmap_add_irq_chip" [drivers/mfd/rt5033.ko] undefined! Signed-off-by: Artem Savkov --- drivers/mfd/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index f8ef77d9a..f49f404 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -680,6 +680,7 @@ config MFD_RT5033 depends on I2C=y select MFD_CORE select REGMAP_I2C + select REGMAP_IRQ help This driver provides for the Richtek RT5033 Power Management IC, which includes the I2C driver and the Core APIs. This driver provides -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + zram-support-compaction.patch added to -mm tree
On (03/05/15 14:29), Sergey Senozhatsky wrote: > On (03/04/15 14:02), a...@linux-foundation.org wrote: > > +What: /sys/block/zram/compact > > +Date: August 2015 > > +Contact: Minchan Kim > > +Description: > > + The compact file is write-only and trigger compaction for > > + allocator zrm uses. The allocator moves some objects so that > > + it could free fragment space. > > + > > +What: /sys/block/zram/num_migrated > > +Date: August 2015 > > +Contact: Minchan Kim > > +Description: > > + The compact file is read-only and shows how many object > > + migrated by compaction. > Minchan, do you want to provide num_migrated as part of zsmalloc stats rather > than having yet another zram attr? we already provide zsmalloc stats and this > type of information seems to belong there. just idea. > can compaction memory gain be calculated as, for example, mem_used_total #before_compaction - mem_used_total #after_compaction ? if yes, then do we need this attr at all? the other thing is - why does this attr return the sum of all compactions? wouldn't it be more informative to return the number of bytes gained after the most recent compaction? but, once again, is this attr worth having? -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
GOOD NEWS
Gloria C. Mackenzie Donate $ 2,000,000 00. to you, Email me on:
{mackenziegloria...@gmail.com} for more details
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bcma: Kconfig: Let it depend on PCI
Rafał Miłecki writes: > Kalle, I guess the recent discussion and work on this problem could be > confusing, so let me try to sum it up it a bit. > > First of all, please note there are 3 awaiting bcma patches that > should be applied independently of what we decide to do with this > patch. They are of course inspired by the recent building problems. > List of these patches: > [PATCH next] bcma: make bcma_host_pci_(up|down) calls safe for every config > [PATCH next] bcma: move internal function declarations to private header > [PATCH next] bcma: prepare Kconfig symbol for PCI driver > > Now, the building problem is obviously caused by me, my work on > driver_pcie2.c and using pcie_set_readrq there without making sure > that is PCI available. I'm sorry for that. > > All 3 above patches are moving us toward the the most optimal solution > of this problem. Depending on PCI only when it's really required. > There is still one more change missing that I'm working on. It'll take > me about 2 more days to get the last patch. > On the other way, patch proposed by Chen fixes building problem right > now. It's much simpler but bumps bcma requirements a bit too high. > bcma doesn't really have to depend on PCI. Thanks for the good summary, it clarified things for me. > So you have 2 options there and I'll be happy with whatever you choose to do: > 1) Pick Chen patch now and in ~2 days apply my final fix + revert Chen > patch. I'll prefer this option so that we can quickly solve the build problem. Also once your final fix is ready, please remember that you need to revert Chen's patch within the same patch. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Bypass legacy PIC and PIT on ACPI hardware reduced platform
* Li, Aubrey wrote:
> On 2015/3/5 4:11, Ingo Molnar wrote:
> >
> > * Arjan van de Ven wrote:
> >
> >> On 3/4/2015 1:50 AM, Borislav Petkov wrote:
> >>> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
> >
> > Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
> > is a mistake.
>
> ideally, the presence of that flag in the firmware table will clear/set
> more global settings,
> for example, having that flag should cause the 8042 input code to not
> probe for the 8042.
>
> for interrupts, there really ought to be a "apic first/only" mode, which
> is then used on
> all modern systems (not just hw reduced).
> >>>
> >>> Do we need some sort of platform-specific querying interfaces now too,
> >>> similar to cpu_has()? I.e., platform_has()...
> >>>
> >>> if (platform_has(X86_PLATFORM_REDUCED_HW))
> >>> do stuff..
> >>
> >> more like
> >>
> >> platform_has(X86_PLATFORM_PIT)
> >>
> >> etc, one for each legacy io item
> >
> > Precisely. The main problem is the generic, 'lumps everything
> > together' nature of the acpi_gbl_reduced_hardware flag.
> >
> > (Like the big kernel lock lumped together all sorts of locking rules
> > and semantics.)
> >
> > Properly split out, feature-ish or driver-ish interfaces for PIT and
> > other legacy details are the proper approach to 'turn them off'.
> >
> > - x86_platform is a function pointer driven, driver-ish interface.
> >
> > - platform_has(X86_PLATFORM_IT) is a flag driven, feature-flag-ish
> >interface.
> >
> > Both are fine - for something as separate as the PIT (or the PIC)
> > it might make more sense to go towards a 'driver' interface
> > though, as modern drivers are (and will be) much different from
> > the legacy PIT.
> >
> > Whichever method is used, low level platforms can just switch them
> > on/off in their enumeration/detection routines, while the generic
> > code will have them enabled by default.
>
> Whichever method is used, we will face a problem how to determine
> PIT exists or not.
>
> When we enabled Bay Trail-T platform at the beginning, we were
> trying to make the code as generic as possible, and it works
> properly up to now. So we don't have a SUBARCH like
> X86_SUBARCH_INTEL_MID to use the platform specific functions. And
> for now I'm not quite sure it's a good idea to create one.
>
> If we make it as a flag driven, I don't know there is a flag in
> firmware better than ACPI HW reduced flag(Of course it's not good
> enough to cover all the cases). Or if we want to use platform info
> to turn on/off this flag, we'll have to maintain a platform list,
> which may be longer and more complicated than worth doing that.
Well, it's not nearly so difficult, because you already have a
platform flag: acpi_gbl_reduced_hardware.
What I object against is to infest generic codepaths with unreadable,
unrobust crap like:
+ if (acpi_gbl_reduced_hardware) {
+ pr_info("Using NULL legacy PIC\n");
+ legacy_pic = _legacy_pic;
+ } else
+ legacy_pic->init(0);
To solve that, add a small (early) init function (say
'x86_reduced_hw_init()') that sets up the right driver
selections if acpi_gbl_reduced_hardware is set:
- in x86_reduced_hw_init() set 'legacy_pic' to 'null_legacy_pic'
- clean up 'global_clock_event' handling: instead of a global
variable, move its management into x86_platform_ops::get_clockevent()
and set the method to hpet/pit/abp/etc. specific handlers that
return the right clockevent device.
- in your x86_reduced_hw_init() function add the hpet clockevent
device to x86_platform_ops::get_clockevent, overriding the default
PIT.
- in x86_reduced_hw_init() set pm_power_off.
- set 'reboot_type' and remove the acpi_gbl_reduced_hardware hack
from efi_reboot_required().
etc.
Just keep the generic init codepaths free of those random selections
based on global flags, okay?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] genirq: describe IRQF_COND_SUSPEND
On 05/03/2015 at 11:04:11 +, Mark Rutland wrote : > > > +In rare cases an IRQ can be shared between a wakeup device driver and an > > > +IRQF_NO_SUSPEND user. In order for this to be safe, the wakeup device > > > driver > > > +must be able to discern spurious IRQs from genuine wakeup events > > > (signalling > > > > And genuine question, should we use British English or American English > > or we don't care ? > > Have I written something that isn't valid American English there? I read > over this a few times and failed to spot anything obvious. > > I'm happy to change for consistency, I generally assume that's the most > important thing. I'd say signalling vs signaling. I actually had to look up which one was correct. I'm personally using Incorrect/Broken English so I'm definitely not here to give lessons. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: mediatek: Export CPU mux clocks for CPU frequency control
On 5 March 2015 at 18:51, Sascha Hauer wrote: > On Thu, Mar 05, 2015 at 05:39:12PM +0800, Pi-Cheng Chen wrote: >> On 5 March 2015 at 17:19, Sascha Hauer wrote: >> > On Thu, Mar 05, 2015 at 02:29:50PM +0530, Viresh Kumar wrote: >> >> On 5 March 2015 at 13:12, Sascha Hauer wrote: >> >> > We have clk_set_parent for changing the parent and clk_set_rate to >> >> > change the rate. Use the former for changing the parent and the latter >> >> > for changing the rate. What you are interested in is changing the >> >> > parent, so use clk_set_parent for this and not abuse a side effect >> >> > of clk_set_rate. >> >> >> >> clk_set_rate() for CPUs clock is responsible to change clock rate >> >> of the CPU. Whether it plays with PLLs or muxes, its not that relevant. >> > >> > The sequence to change the CPU frequency on the Mediatek SoCs is like this: >> > >> > - Change CPU from CPU PLL to another clock source (intermediate source) >> > - Change CPU PLL frequency >> > - wait until PLL has settled >> > - switch back to CPU PLL >> > >> > The frequency of the intermediate source is irrelevant, the important >> > thing is that the CPU is switched to this source while the CPU PLL is >> > reconfigured. >> > >> > In Pi-Chengs patches the switch to th eintermediate clock is done like: >> > >> > rate = clk_get_rate(intermediate_clk); >> > clk_set_rate(cpu_clk, rate); >> > >> > Now the clk framework does the switch not because it's told to switch >> > to another parent, but only because the other parent happens to be the >> > only provider for that rate. That's rubbish, when the parent must be >> > changed, then it should be done explicitly. >> >> Hi, >> >> Please correct me if I was wrong. But I think that's the reason why we have >> a determine_rate hook here, isn't it? >> >> > What if the CPU PLL and the intermediate clk happen to have the same >> > rate? Then the clk_set_rate above simply does nothing, no parent is >> > changed and the following rate change of the CPU PLL just crashes the >> > system. >> >> I think what I am trying to do in the determine_rate hook of cpumux is: >> >> * if the target rate of clk_set_rate is equal to the rate of MAINPLL, >> then switch >> the mux to MAINPLL >> * otherwise, set the rate directly on ARMPLL and switch the mux back to >> ARMPLL if the current parent of mux is not ARMPLL >> >> And if the CPU PLL and the intermediate clk happen to have the same rate, >> I think the cpufreq-dt driver will change nothing on the clk framework. Or do >> I misunderstand your point? > > Imagine the board starts with both the CPU PLL and Intermediate PLL > running with the same frequency with the CPU driven from the CPU PLL. > Now the cpufreq driver does it's very first frequency transition. Now > when clk_set_rate is used with the intention to switch to the > intermediate PLL nothing will happen because the CPU PLL already runs > at the desired frequency. Reconfiguring the CPU PLL then crashes your > system. > > Another reason why abusing clk_set_rate to change the parent is this: > You have this in your SoC: > > --- > CPU_PLL ---| | >| | >| |- CPU >| | > IM_PLL | | > --- > > Now you do a clk_set_rate(CPU, clk_get_rate(IM_PLL)) which (often) works > in your case. Many SoCs have an additional divider though, like this: > > --- > CPU_PLL ---| | >| | >| |--| :x | --- CPU >| | > IM_PLL | | > --- > > Now clk_set_rate(CPU, clk_get_rate(IM_PLL)) doesn't give anything > sensible anymore. > > Given the variance of different SoCs I don't think it makes sense > to try to handle all these cases. Instead the cpufreq-dt driver > should just call clk_set_rate() on the CPU clock with the desired > target frequency. Everything else should be handled in the clock > driver which has intimate knowledge about the SoC anyway. Now I got it. Thanks for your elaboration. I will investigate the way you suggested to implement intermediate clock switching. Best Regards, Pi-Cheng > > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 5/5] KVM: arm/arm64: add irqfd support
On 05/03/15 11:27, Paolo Bonzini wrote: > > > On 05/03/2015 11:53, Marc Zyngier wrote: >>> +#ifdef CONFIG_HAVE_KVM_IRQFD >>> + case KVM_CAP_IRQFD: >>> + r = vgic_present; >>> + break; >>> +#endif >> >> Nitpick: we have "select HAVE_KVM_IRQFD", so we can lose the #ifdef-ery. > > Alternatively, I've just posted a patch to move the KVM_CAP_IRQFD case > to common code. > > vgic_present probably should be replaced by > IS_ENABLED(CONFIG_KVM_ARM_VGIC). I've sent a patch for this. Right. We can probably take this at the same time as Eric's series. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/6] watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND
On Thu, 5 Mar 2015 12:17:23 +0100 Boris Brezillon wrote: > Hi Boris, ^ Mark, I'm suffering from a dual personality disorder :-) > > On Thu, 5 Mar 2015 10:53:08 + > Mark Rutland wrote: > > > Hi Boris, > > > > I'd missed the fact that this was for SW watchdog as opposed to HW > > watchdog, which may explain my confusion. > > > > [...] > > > > > > > err = request_irq(wdt->irq, wdt_interrupt, > > > > > - IRQF_SHARED | IRQF_IRQPOLL, > > > > > + IRQF_SHARED | IRQF_IRQPOLL | > > > > > + IRQF_NO_SUSPEND, > > > > > > > > I'm a little confused by this. What happens if the watchdog fires when > > > > we're actually in the suspended state (when IRQF_NO_SUSPEND interrupts > > > > aren't guaranteed to be delivered). > > > > > > It reboot the system. > > > > Is the timer we use to ping the watchdog guaranted to result in a wakeup > > before an interrupt will be triggered? If so, then I think we're ok. > > It should be (I don't recall exactly what the logic is, but it's at > least half the watchdog time limit). > > > > > If not, then don't we need to clear a potentially pending watchdog irq > > at resume time so at to not immediately reboot the machine? I couldn't > > see any logic to that effect in the driver. > > That depends on what we want. > If we want the watchdog to be inactive when entering suspend, then we > shouldn't reboot the machine when receiving a watchdog irq while the > system is suspended. > ITOH, with the hardware mode (reset handled by the watchdog IP) you > can't disable the watchdog when entering suspend, so I would expect the > same behavior for the SW mode. > > > > > Regardless, if the only reason we care about taking the interrupt during > > the suspend/resume phases is due to the timer sharing the IRQ, then > > shouldn't we be using IRQF_COND_SUSPEND? > > I'm not sure, but IMO this interrupt should be flagged as NO_SUSPEND, > because it's here to reset the system (even if it is suspended). > If you flag the irq line as COND_SUSPEND, and atmel decide to give this > peripheral its own IRQ line (on new SoCs), then your watchdog will not > reboot the system when it is suspended. > Another solution would be to support wakeup for this peripheral and > delay the system reboot until it has resumed. > > Anyway, if we decide to go for the wakeup approach, I'd prefer to post > another patch on top of this one. > > Best Regards, > > Boris > > -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 0/2] N900 Modem Speech Support
Hi!
> Userland access goes via /dev/cmt_speech. The API is implemented in
> libcmtspeechdata, which is used by ofono and the freesmartphone.org project.
> Apart from that the device is also used by the phone binaries distributed
> with Maemo. So while this is a new userland ABI for the mainline kernel it
> has been tested in the wild for some years.
I'm sorry, Dave. I can't let you do that.
Yes, the ABI is "tested" for some years, but it is not documented, and
it is very wrong ABI.
I'm not sure what they do with the "read()". I was assuming it is
meant for passing voice data, but it can return at most 4 bytes,
AFAICT.
We already have perfectly good ABI for passing voice data around. It
is called "ALSA". libcmtspeech will then become unneccessary, and the
daemon routing voice data will be as simple as "read sample from
ALSA/modem, write sample to ALSA/rx-51_soundcard" & "read sample from
ALSA/rx-51_soundcard, write sample to ALSA/modem" & .
Should this driver be merged to drivers/staging while the interface is
fixed? Big part of driver should stay the same, userspace interface is
only small part of the driver...
Sorry about that,
Pavel
Signed-off-by: Pavel Machek
diff --git a/drivers/hsi/clients/cmt_speech.c b/drivers/hsi/clients/cmt_speech.c
index 5dbbc67..06dc81c 100644
--- a/drivers/hsi/clients/cmt_speech.c
+++ b/drivers/hsi/clients/cmt_speech.c
@@ -21,6 +21,8 @@
* 02110-1301 USA
*/
+/* Thanks to
http://ben-collins.blogspot.cz/2010/05/writing-alsa-driver-basics.html */
+
#include
#include
#include
@@ -39,6 +41,11 @@
#include
#include
+#include
+#include
+#include
+#include
+
#define CS_MMAP_SIZE PAGE_SIZE
struct char_queue {
@@ -62,8 +69,12 @@ struct cs_char {
/* hsi channel ids */
int channel_id_cmd;
int channel_id_data;
+ /* alsa */
+ struct snd_card *card;
};
+#define cs_char cs_char
+
#define SSI_CHANNEL_STATE_READING 1
#define SSI_CHANNEL_STATE_WRITING (1 << 1)
#define SSI_CHANNEL_STATE_POLL (1 << 2)
@@ -168,6 +179,8 @@ static void cs_notify(u32 message, struct list_head *head)
wake_up_interruptible(_char_data.wait);
kill_fasync(_char_data.async_queue, SIGIO, POLL_IN);
+ /* snd_pcm_period_elapsed(my_dev->ss); ?? FIXME */
+
out:
return;
}
@@ -1134,10 +1147,8 @@ static unsigned int cs_char_poll(struct file *file,
poll_table *wait)
return ret;
}
-static ssize_t cs_char_read(struct file *file, char __user *buf, size_t count,
- loff_t *unused)
+static ssize_t __cs_char_read(struct cs_char *csdata, char __user *buf, size_t
count, int nonblock)
{
- struct cs_char *csdata = file->private_data;
u32 data;
ssize_t retval;
@@ -1161,7 +1172,7 @@ static ssize_t cs_char_read(struct file *file, char
__user *buf, size_t count,
if (data)
break;
- if (file->f_flags & O_NONBLOCK) {
+ if (nonblock) {
retval = -EAGAIN;
goto out;
} else if (signal_pending(current)) {
@@ -1182,10 +1193,17 @@ out:
return retval;
}
-static ssize_t cs_char_write(struct file *file, const char __user *buf,
- size_t count, loff_t *unused)
+
+static ssize_t cs_char_read(struct file *file, char __user *buf, size_t count,
+ loff_t *unused)
{
struct cs_char *csdata = file->private_data;
+ return __cs_char_read(csdata, buf, count, file->f_flags & O_NONBLOCK);
+}
+
+static ssize_t __cs_char_write(struct cs_char *csdata, const char __user *buf,
+ size_t count)
+{
u32 data;
int err;
ssize_t retval;
@@ -1205,6 +1223,13 @@ static ssize_t cs_char_write(struct file *file, const
char __user *buf,
return retval;
}
+static ssize_t cs_char_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *unused)
+{
+ struct cs_char *csdata = file->private_data;
+ return __cs_char_write(csdata, buf, count);
+}
+
static long cs_char_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
@@ -1269,7 +1294,7 @@ static int cs_char_mmap(struct file *file, struct
vm_area_struct *vma)
return 0;
}
-static int cs_char_open(struct inode *unused, struct file *file)
+static int __cs_char_open(void)
{
int ret = 0;
unsigned long p;
@@ -1300,8 +1325,6 @@ static int cs_char_open(struct inode *unused, struct file
*file)
cs_char_data.mmap_base = p;
cs_char_data.mmap_size = CS_MMAP_SIZE;
- file->private_data = _char_data;
-
return
Re: [PATCH v9 14/21] ACPI / processor: Make it possible to get CPU hardware ID via GICC
On Thu, Mar 05, 2015 at 04:03:21PM +0800, Hanjun Guo wrote: > On 2015/3/5 6:46, Rafael J. Wysocki wrote: > > IMO, you really need to define phys_cpuid_t in a common place or people will > > forget that it may be 64-bit, because they'll only be looking at their arch. > > Since x86 and ARM64 are using different types for phys_cpuid_t, we need to > introduce something like following if define it in common place: > > in linux/acpi.h, > > #if defined(CONFIG_X86) || defined(CONFIG_IA64) > typedef u32 phys_cpuid_t; > #define PHYS_CPUID_INVALID (phys_cpuid_t)(-1) > #else if defined(CONFIG_ARM64) > typedef u64 phys_cpuid_t; > #define PHYS_CPUID_INVALID INVALID_HWID > #endif > > I think it's awful, did I miss something? I also think that's awful. I'm rather in favour of a per-arch phys_cpuid_t. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 5/5] KVM: arm/arm64: add irqfd support
On 05/03/2015 11:53, Marc Zyngier wrote: > > +#ifdef CONFIG_HAVE_KVM_IRQFD > > + case KVM_CAP_IRQFD: > > + r = vgic_present; > > + break; > > +#endif > > Nitpick: we have "select HAVE_KVM_IRQFD", so we can lose the #ifdef-ery. Alternatively, I've just posted a patch to move the KVM_CAP_IRQFD case to common code. vgic_present probably should be replaced by IS_ENABLED(CONFIG_KVM_ARM_VGIC). I've sent a patch for this. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] KVM: arm/arm64: prefer IS_ENABLED to a static variable
IS_ENABLED gives compile-time checking and keeps the code clearer.
The one exception is inside kvm_vm_ioctl_check_extension, where
the established idiom is to wrap the case labels with an #ifdef.
Signed-off-by: Paolo Bonzini
--
Untested...
---
arch/arm/kvm/arm.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 07e7eb1d7ab6..706769fb0f2e 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -61,8 +61,6 @@ static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
static u8 kvm_next_vmid;
static DEFINE_SPINLOCK(kvm_vmid_lock);
-static bool vgic_present;
-
static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
{
BUG_ON(preemptible());
@@ -172,9 +170,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
{
int r;
switch (ext) {
+#ifdef CONFIG_KVM_ARM_VGIC
case KVM_CAP_IRQCHIP:
- r = vgic_present;
- break;
+#endif
case KVM_CAP_DEVICE_CTRL:
case KVM_CAP_USER_MEMORY:
case KVM_CAP_SYNC_MMU:
@@ -831,7 +829,7 @@ static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
switch (dev_id) {
case KVM_ARM_DEVICE_VGIC_V2:
- if (!vgic_present)
+ if (!IS_ENABLED(CONFIG_KVM_ARM_VGIC))
return -ENXIO;
return kvm_vgic_addr(kvm, type, _addr->addr, true);
default:
@@ -847,10 +845,9 @@ long kvm_arch_vm_ioctl(struct file *filp,
switch (ioctl) {
case KVM_CREATE_IRQCHIP: {
- if (vgic_present)
- return kvm_vgic_create(kvm, KVM_DEV_TYPE_ARM_VGIC_V2);
- else
+ if (!IS_ENABLED(CONFIG_KVM_ARM_VGIC))
return -ENXIO;
+ return kvm_vgic_create(kvm, KVM_DEV_TYPE_ARM_VGIC_V2);
}
case KVM_ARM_SET_DEVICE_ADDR: {
struct kvm_arm_device_addr dev_addr;
@@ -1035,10 +1032,6 @@ static int init_hyp_mode(void)
if (err)
goto out_free_context;
-#ifdef CONFIG_KVM_ARM_VGIC
- vgic_present = true;
-#endif
-
/*
* Init HYP architected timer support
*/
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Bypass legacy PIC and PIT on ACPI hardware reduced platform
On 2015/3/5 5:52, Rafael J. Wysocki wrote: > On Wednesday, March 04, 2015 08:21:01 PM Alan Cox wrote: >> On Wed, 2015-03-04 at 15:05 +0100, Borislav Petkov wrote: >>> On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote: Sort of. What we need is a "do not touch PIC/PIT" bit for the code that tries to fall back to them in some cases (which may appear to work if the hardware is physically there, but it may confuse the platform). >>> >>> Can "some cases" detection be nicely put into a x86_platform >>> platform-specific method? >> >> In some cases they don't belong in x86, ACPI is also used for ARM64. >> >> However >> >> if ( has_8259_pic() ) >> >> is trivally 0, 1 or some platform or acpi provided method. > > And which is how that should have been implemented to start with IMO. > > Besides, the "ACPI reduced hardware" case is kind of a red herring here, > because it most likely is not the only case when we'll want has_8259_pic() > to return 0 (quite likely, we'll want that on all BayTrail-based systems, > for example). > BayTrail-based systems has BayTrail-I, BayTrail-M, BayTrail-D, BayTrail-T, BayTrail-T/CR. BayTrail-D is a desktop and BayTrail-M is a mobile/laptop and 8259 exists on both systems and I don't think we want to bypass it. ACPI reduced hardware is the best case in my mind unless you want to enumerate the platform one by one. can we make a global variable u8 has_8259; and initialize it by acpi reduced hardware flag? or a wrapper function? Thanks, -Aubrey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/5] irqchip: gicv3-its: add limitation to page order
On 04/03/15 03:18, Yun Wu wrote:
> When required size of Device Table is out of the page allocator's
> capability, the whole ITS will fail in probing. This actually is
> not the hardware's problem and is mainly a limitation of the kernel
> page allocator. This patch will keep ITS going on to the next
> initializaion stage with an explicit warning.
>
> Signed-off-by: Yun Wu
> ---
> drivers/irqchip/irq-gic-v3-its.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index f5bfa42..e8bda0b 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -828,6 +828,11 @@ static int its_alloc_tables(struct its_node *its)
> u32 ids = GITS_TYPER_DEVBITS(typer);
>
> order = get_order((1UL << ids) * entry_size);
> + if (order >= MAX_ORDER) {
> + order = MAX_ORDER - 1;
> + pr_warn("%s: DT size too large, reduce page
> order to %u\n",
Please spell out device table instead of DT. Most people will interpret
DT as Device Tree, and won't immediately get what is happening.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] bq2415x_charger: Remove unnecessary else after return
Fix coding style to comply with checkpatch.pl Signed-off-by: Anda-Maria Nicolae --- drivers/power/bq2415x_charger.c | 24 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/drivers/power/bq2415x_charger.c b/drivers/power/bq2415x_charger.c index e384844..628a2ed 100644 --- a/drivers/power/bq2415x_charger.c +++ b/drivers/power/bq2415x_charger.c @@ -352,8 +352,7 @@ static int bq2415x_exec_command(struct bq2415x_device *bq, BQ2415X_BIT_CE); if (ret < 0) return ret; - else - return ret > 0 ? 0 : 1; + return ret > 0 ? 0 : 1; case BQ2415X_CHARGER_ENABLE: return bq2415x_i2c_write_bit(bq, BQ2415X_REG_CONTROL, 0, BQ2415X_BIT_CE); @@ -426,20 +425,17 @@ static enum bq2415x_chip bq2415x_detect_chip(struct bq2415x_device *bq) case 0: if (bq->chip == BQ24151A) return bq->chip; - else - return BQ24151; + return BQ24151; case 1: if (bq->chip == BQ24150A || bq->chip == BQ24152 || bq->chip == BQ24155) return bq->chip; - else - return BQ24150; + return BQ24150; case 2: if (bq->chip == BQ24153A) return bq->chip; - else - return BQ24153; + return BQ24153; default: return BQUNKNOWN; } @@ -450,8 +446,7 @@ static enum bq2415x_chip bq2415x_detect_chip(struct bq2415x_device *bq) case 0: if (bq->chip == BQ24156A) return bq->chip; - else - return BQ24156; + return BQ24156; case 2: return BQ24158; default: @@ -480,8 +475,7 @@ static int bq2415x_detect_revision(struct bq2415x_device *bq) case BQ24152: if (ret >= 0 && ret <= 3) return ret; - else - return -1; + return -1; case BQ24153: case BQ24153A: case BQ24156: @@ -491,13 +485,11 @@ static int bq2415x_detect_revision(struct bq2415x_device *bq) return 0; else if (ret == 1) return 1; - else - return -1; + return -1; case BQ24155: if (ret == 3) return 3; - else - return -1; + return -1; case BQUNKNOWN: return -1; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] bq2415x_charger: Fix coding style issues and add new charger in the list of supported chargers
Hello, First patch from patchset fixes coding style issues: removes unnecessary else after return. This way, the coding style complies with checkpatch.pl. Second patch from patchset updates bq2415x driver to support bq24157s charger. Thanks, Anda Anda-Maria Nicolae (2): bq2415x_charger: Remove unnecessary else after return bq2415x_charger: Add support for bq24157s drivers/power/bq2415x_charger.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] bq2415x_charger: Add support for bq24157s
This patch adds bq24157s charger in the list of supported chargers.
bq24157s is similar to bq24158, except for Bit6 from Special Charger
Voltage/Enable Pin Status register, but this register is currently
not used by bq2415x_charger.
Signed-off-by: Anda-Maria Nicolae
---
drivers/power/bq2415x_charger.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/power/bq2415x_charger.c b/drivers/power/bq2415x_charger.c
index 628a2ed..41f6c4c 100644
--- a/drivers/power/bq2415x_charger.c
+++ b/drivers/power/bq2415x_charger.c
@@ -26,6 +26,8 @@
* http://www.ti.com/product/bq24153
* http://www.ti.com/product/bq24153a
* http://www.ti.com/product/bq24155
+ * http://www.ti.com/product/bq24157s
+ * http://www.ti.com/product/bq24158
*/
#include
@@ -147,6 +149,7 @@ enum bq2415x_chip {
BQ24155,
BQ24156,
BQ24156A,
+ BQ24157S,
BQ24158,
};
@@ -162,6 +165,7 @@ static char *bq2415x_chip_name[] = {
"bq24155",
"bq24156",
"bq24156a",
+ "bq24157s",
"bq24158",
};
@@ -448,6 +452,8 @@ static enum bq2415x_chip bq2415x_detect_chip(struct
bq2415x_device *bq)
return bq->chip;
return BQ24156;
case 2:
+ if (bq->chip == BQ24157S)
+ return bq->chip;
return BQ24158;
default:
return BQUNKNOWN;
@@ -480,6 +486,7 @@ static int bq2415x_detect_revision(struct bq2415x_device
*bq)
case BQ24153A:
case BQ24156:
case BQ24156A:
+ case BQ24157S:
case BQ24158:
if (ret == 3)
return 0;
@@ -1716,6 +1723,7 @@ static const struct i2c_device_id bq2415x_i2c_id_table[]
= {
{ "bq24155", BQ24155 },
{ "bq24156", BQ24156 },
{ "bq24156a", BQ24156A },
+ { "bq24157s", BQ24157S },
{ "bq24158", BQ24158 },
{},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -stable] ath6kl: fix struct hif_scatter_req list handling
On 02/20/2015, 04:20 PM, Kalle Valo wrote: > Josh Cartwright writes: > >> From: Kalle Valo >> >> commit 31b9cc9a873dcab161999622314f98a75d838975 upstream. >> >> Jason noticed that with Yocto GCC 4.8.1 ath6kl crashes with this iperf >> command: >> >> iperf -c $TARGET_IP -i 5 -t 50 -w 1M >> >> The crash was: >> >> Unable to handle kernel paging request at virtual address 1a48 >> pgd = 80004000 >> [1a48] *pgd= >> Internal error: Oops: 805 [#1] SMP ARM >> Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core] >> CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1 >> Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio] >> task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000 >> PC is at v7_dma_clean_range+0x20/0x38 >> LR is at dma_cache_maint_page+0x50/0x54 >> pc : [<8001a6f8>]lr : [<800170fc>]psr: 2093 >> sp : dc9afcf8 ip : 8001a748 fp : 0004 >> r10: r9 : 0001 r8 : >> r7 : 0001 r6 : r5 : 80cb7000 r4 : 03f9a480 >> r3 : 001f r2 : 0020 r1 : 1a48 r0 : 1a48 >> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel >> Control: 10c53c7d Table: 6cc5004a DAC: 0015 >> Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238) >> Stack: (0xdc9afcf8 to 0xdc9b) >> fce0: 80c9b29c >> fd00: 80017134 8001a748 dc302ac0 dc454a00 80c12ed8 >> fd20: dc115410 80017238 dc454a10 0001 80017588 0001 >> fd40: dc302ac0 dc9afe38 dc9afe68 0004 80c12ed8 dc454a00 >> fd60: 0004 80436f88 0600 000c 80c113c4 >> fd80: 80c9b29c 0001 0004 dc115470 6013 dc302ac0 dc46e000 dc302800 >> fda0: dc9afe10 dc302b78 6013 dc302ac0 dc46e000 0035 dc46e5b0 80438c90 >> fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 0005 dc9afe10 >> fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00 >> fe00: 01b5 7f619d64 dcc7c830 dc9afe38 dc9afe68 >> fe20: dc9afe28 dc9afe28 80424d80 0035 9cac0034 >> fe40: 01b5 >> fe60: dc9afe68 dc9afe10 3b9aca00 0080 0034 0100 >> fe80: dc9afe10 0004 dc454a00 dc46e010 dc46e96c >> fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 0600 80c0e770 >> fec0: dc15a900 dcc7c838 dc46e954 8042d434 dcc44680 dc46e954 dc004400 >> fee0: dc454500 dc9ae038 dc004400 8003c450 dcc44680 dc004414 >> ff00: dc46e954 dc454500 0001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030 >> ff20: 0001 dc9ae000 dc004400 8003d158 8003d020 80c53941 >> ff40: dc9aff64 dcb71ea0 dcc44680 8003d020 >> ff60: 80042480 00f8 dcc44680 >> ff80: dc9aff80 dc9aff80 dc9aff90 dc9aff90 dc9affac dcb71ea0 >> ffa0: 800423cc 8000e018 >> ffc0: >> ffe0: 0013 >> [<8001a6f8>] (v7_dma_clean_range+0x20/0x38) from [<800170fc>] >> (dma_cache_maint_page+0x50/0x54) >> [<800170fc>] (dma_cache_maint_page+0x50/0x54) from [<80017134>] >> (__dma_page_cpu_to_dev+0x34/0x9c) >> [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) from [<80017238>] >> (arm_dma_map_page+0x64/0x68) >> [<80017238>] (arm_dma_map_page+0x64/0x68) from [<80017588>] >> (arm_dma_map_sg+0x7c/0xf4) >> [<80017588>] (arm_dma_map_sg+0x7c/0xf4) from [<80436f88>] >> (sdhci_send_command+0x894/0xe00) >> [<80436f88>] (sdhci_send_command+0x894/0xe00) from [<80438c90>] >> (sdhci_request+0xc0/0x1ec) >> [<80438c90>] (sdhci_request+0xc0/0x1ec) from [<80424cb4>] >> (mmc_start_request+0xb8/0xd4) >> [<80424cb4>] (mmc_start_request+0xb8/0xd4) from [<80424de8>] >> (__mmc_start_req+0x60/0x84) >> [<80424de8>] (__mmc_start_req+0x60/0x84) from [<80424e90>] >> (mmc_wait_for_req+0x10/0x20) >> [<80424e90>] (mmc_wait_for_req+0x10/0x20) from [<7f619d64>] >> (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) >> [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from >> [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) >> [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from >> [<8003c450>] (process_one_work+0x10c/0x370) >> [<8003c450>] (process_one_work+0x10c/0x370) from [<8003d158>] >> (worker_thread+0x138/0x3fc) >> [<8003d158>] (worker_thread+0x138/0x3fc) from [<80042480>] >> (kthread+0xb4/0xb8) >> [<80042480>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c) >> Code: e1a02312 e2423001 e1c3 f57ff04f (ee070f3a) >> ---[ end trace 0c038f0b8e0b67a3 ]--- >>
Re: [PATCH] do_fork(): Rename 'stack_size' argument to reflect actual use
On 05/03/15 01:07, David Rientjes wrote:
On Wed, 4 Mar 2015, Alex Dowad wrote:
The 'stack_size' argument is never used to pass a stack size. It's only used
when
forking a kernel thread, in which case it is an argument which should be passed
to the 'main' function which the kernel thread executes. Hence, rename it to
'kthread_arg'.
Signed-off-by: Alex Dowad
---
Hi,
Please have a look at this patch. If this is accepted, I have a series of
patches
ready for a similar cleanup to all the arch-specific implementations of
copy_thread()
(as suggested by Andrew Morton in a private e-mail).
Thank you,
Alex Dowad
kernel/fork.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index cf65139..b38a2ae 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1186,10 +1186,12 @@ init_task_pid(struct task_struct *task, enum pid_type
type, struct pid *pid)
* It copies the registers, and all the appropriate
* parts of the process environment (as per the clone
* flags). The actual kick-off is left to the caller.
+ *
+ * When copying a kernel thread, 'stack_start' is the function to run.
*/
static struct task_struct *copy_process(unsigned long clone_flags,
unsigned long stack_start,
- unsigned long stack_size,
+ unsigned long kthread_arg,
int __user *child_tidptr,
struct pid *pid,
int trace)
@@ -1401,7 +1403,7 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
retval = copy_io(clone_flags, p);
if (retval)
goto bad_fork_cleanup_namespaces;
- retval = copy_thread(clone_flags, stack_start, stack_size, p);
+ retval = copy_thread(clone_flags, stack_start, kthread_arg, p);
if (retval)
goto bad_fork_cleanup_io;
@@ -1629,8 +1631,8 @@ struct task_struct *fork_idle(int cpu)
* it and waits for it to finish using the VM if required.
*/
long do_fork(unsigned long clone_flags,
- unsigned long stack_start,
- unsigned long stack_size,
+ unsigned long stack_start, /* or function for kthread to run */
+ unsigned long kthread_arg,
int __user *parent_tidptr,
int __user *child_tidptr)
{
Looks fine, but I'm not sure about commenting functional formals. Since
copy_process() and do_fork() can have formals with different meanings,
then why not just rename them "arg1" and "arg2" respectively and then
define in the comment above the function what the possible combinations
are?
The second argument is *only* ever used for one thing: an argument
passed to a kernel thread. That's why I would like to rename it to
"kthread_arg". The previous argument (currently named "stack_start") is
indeed used for 2 different things: a new stack pointer for a user
thread, or a function to be executed by a kernel thread. Rather than
"arg1", what would you think of something like "sp_or_fn", or "usp_or_fn"?
Thanks for your feedback!
@@ -1656,7 +1658,7 @@ long do_fork(unsigned long clone_flags,
trace = 0;
}
- p = copy_process(clone_flags, stack_start, stack_size,
+ p = copy_process(clone_flags, stack_start, kthread_arg,
child_tidptr, NULL, trace);
/*
* Do this prior waking up the new thread - the thread pointer
@@ -1740,7 +1742,7 @@ SYSCALL_DEFINE5(clone, unsigned long, newsp, unsigned
long, clone_flags,
int, tls_val)
#elif defined(CONFIG_CLONE_BACKWARDS3)
SYSCALL_DEFINE6(clone, unsigned long, clone_flags, unsigned long, newsp,
- int, stack_size,
+ int, ignored,
int __user *, parent_tidptr,
int __user *, child_tidptr,
int, tls_val)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/6] watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND
Hi Boris, On Thu, 5 Mar 2015 10:53:08 + Mark Rutland wrote: > Hi Boris, > > I'd missed the fact that this was for SW watchdog as opposed to HW > watchdog, which may explain my confusion. > > [...] > > > > > err = request_irq(wdt->irq, wdt_interrupt, > > > > - IRQF_SHARED | IRQF_IRQPOLL, > > > > + IRQF_SHARED | IRQF_IRQPOLL | > > > > + IRQF_NO_SUSPEND, > > > > > > I'm a little confused by this. What happens if the watchdog fires when > > > we're actually in the suspended state (when IRQF_NO_SUSPEND interrupts > > > aren't guaranteed to be delivered). > > > > It reboot the system. > > Is the timer we use to ping the watchdog guaranted to result in a wakeup > before an interrupt will be triggered? If so, then I think we're ok. It should be (I don't recall exactly what the logic is, but it's at least half the watchdog time limit). > > If not, then don't we need to clear a potentially pending watchdog irq > at resume time so at to not immediately reboot the machine? I couldn't > see any logic to that effect in the driver. That depends on what we want. If we want the watchdog to be inactive when entering suspend, then we shouldn't reboot the machine when receiving a watchdog irq while the system is suspended. ITOH, with the hardware mode (reset handled by the watchdog IP) you can't disable the watchdog when entering suspend, so I would expect the same behavior for the SW mode. > > Regardless, if the only reason we care about taking the interrupt during > the suspend/resume phases is due to the timer sharing the IRQ, then > shouldn't we be using IRQF_COND_SUSPEND? I'm not sure, but IMO this interrupt should be flagged as NO_SUSPEND, because it's here to reset the system (even if it is suspended). If you flag the irq line as COND_SUSPEND, and atmel decide to give this peripheral its own IRQ line (on new SoCs), then your watchdog will not reboot the system when it is suspended. Another solution would be to support wakeup for this peripheral and delay the system reboot until it has resumed. Anyway, if we decide to go for the wakeup approach, I'd prefer to post another patch on top of this one. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
