* [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
From: Robert Jarzmik @ 2018-01-11 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111122751.4bd74366@bbrezillon>
Boris Brezillon <boris.brezillon@free-electrons.com> writes:
Hi Boris and Miquel,
> So, here is the plan: since the driver has been tested on various mvebu
> platforms and is known to work fine on these platforms, I'd like to
> queue the driver and the patch modifying mvebu defconfigs (patches 1 to
> 4) for 4.16.
That's all right.
> I'll leave other patches for 4.17, which means I'd like remaining bugs
> to be fixed during the 4.16 release cycle so that we can eventually get
> rid of the old driver. That's really important to me that we don't keep
> both drivers around for too long, because my previous experience showed
> that, when you have 2 drivers for the same HW, people don't switch to
> the new one until they're forced to do it.
>
> Robert, are you fine with this approach? What about the tests you were
> doing? Did you make any progress? Did you find other issues?
So far, with the latest branch from Miquel of tip commit 12b9e62c851c ("ARM64:
dts: marvell: use reworked NAND controller driver on Armada 8K"), the bad blocks
issue is still there, ie :
- the old pxa3xx driver doesn't see any bad block and mounts the ext2/ubifs
correctly
- barebox doesn't see any bad block
- marvell_nand sees all (or most all) blocks as bad with "flash_bbt=0" in
platform data, which is very surprising
I'm really surprised that in your tests on the cm_x300, in a platform_data setup
(ie. not device-tree setup), you're not seeing these errors ...
As if I'm fine with this approach, I agree with step 1 (patches 1-4). As for
step 2, I'll agree if the current situation is solved and my boards recognize
correctly my ext2 over ubifs on the NAND.
Cheers.
--
Robert
[1] The dmesg extract (here with flash_bbt = 0)
Loading ARM Linux zImage '/mnt/tftp/zImage_jenkins'
commandline: ram=64M console=ttyS0,115200 ip=dhcp root=/dev/nfs nfsroot=/home/none/nfsroot/zylonite,v3,tcp earlycon mtdparts=pxa3xx_nand-0:128k at 0(TIMH)ro,128k at 128k(OBMI)ro,768k at 256k(barebox),256k at 1024k(barebox-env),12M at 1280k(kernel),38016k at 13568k(root)
arch_number: 1233
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.15.0-rc1-00044-g11cc68b (jenkins at belgarath) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29)) #879 PREEMPT Thu Jan 11 09:16:09 CET 2018
[ 0.000000] CPU: XScale-V3 based processor [69056891] revision 1 (ARMv5TE), cr=0000397f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: PXA3xx Platform Development Kit (aka Zylonite)
[ 0.000000] Ignoring tag cmdline (using the default kernel command line)
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] RO Mode clock: 0.00MHz
[ 0.000000] Run Mode clock: 0.00MHz
[ 0.000000] Turbo Mode clock: 0.00MHz
[ 0.000000] System bus clock: 0.00MHz
[ 0.000000] On node 0 totalpages: 16384
[ 0.000000] Normal zone: 128 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 16384 pages, LIFO batch:3
[ 0.000000] random: fast init done
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: root=/dev/ram0 ip=192.168.1.232:192.168.1.5::255.255.255.0::eth0:on console=ttyS0,115200 mem=64M mtdparts=pxa3xx_nand-0:128k at 0(TIMH)ro,128k at 128k(OBMI)ro,768k at 256k(barebox),256k at 1024k(barebox-env),12M at 1280k(kernel),38016k at 13568k(root) ubi.mtd=5 earlycon=pxa,io,0xf6200000,115200n8 debug no_console_suspend
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Memory: 56856K/65536K available (4225K kernel code, 202K rwdata, 972K rodata, 2396K init, 102K bss, 8680K reserved, 0K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[ 0.000000] .text : 0xc0008000 - 0xc04289e8 (4227 kB)
[ 0.000000] .init : 0xc053f000 - 0xc0796000 (2396 kB)
[ 0.000000] .data : 0xc0796000 - 0xc07c8bec ( 203 kB)
[ 0.000000] .bss : 0xc07c8bec - 0xc07e25fc ( 103 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] NR_IRQS: 16, nr_irqs: 336, preallocated irqs: 336
[ 0.000000] RJK: parent_rate=13000000, xl=8, xn=1
[ 0.000068] sched_clock: 32 bits at 3250kHz, resolution 307ns, wraps every 660764198758ns
[ 0.000267] clocksource: oscr0: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 588080137591 ns
[ 0.002139] Console: colour dummy device 80x30
[ 0.002298] Calibrating delay loop... 103.83 BogoMIPS (lpj=519168)
[ 0.081019] pid_max: default: 32768 minimum: 301
[ 0.081858] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.081958] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.085170] CPU: Testing write buffer coherency: ok
[ 0.088980] Setting up static identity map for 0x80008200 - 0x80008260
[ 0.089936] Hierarchical SRCU implementation.
[ 0.102958] devtmpfs: initialized
[ 0.113835] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.113974] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 0.116311] NET: Registered protocol family 16
[ 0.119126] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.385492] Advanced Linux Sound Architecture Driver Initialized.
[ 0.398200] clocksource: Switched to clocksource oscr0
[ 0.551166] NET: Registered protocol family 2
[ 0.556911] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.557135] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.557316] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.557858] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 0.558038] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 0.559740] NET: Registered protocol family 1
[ 0.561795] RPC: Registered named UNIX socket transport module.
[ 0.561891] RPC: Registered udp transport module.
[ 0.561946] RPC: Registered tcp transport module.
[ 0.562003] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2.497308] Initialise system trusted keyrings
[ 2.499900] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[ 2.503798] NFS: Registering the id_resolver key type
[ 2.504004] Key type id_resolver registered
[ 2.504066] Key type id_legacy registered
[ 2.510210] Key type asymmetric registered
[ 2.510311] Asymmetric key parser 'x509' registered
[ 2.510469] io scheduler noop registered
[ 2.510534] io scheduler deadline registered
[ 2.510928] io scheduler cfq registered (default)
[ 2.510999] io scheduler mq-deadline registered
[ 2.511060] io scheduler kyber registered
[ 2.571677] pxa-dma pxa-dma.0: initialized 32 channels on 100 requestors
[ 2.575099] pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 38, base_baud = 928571) is a UART1
[ 3.050644] console [ttyS0] enabled
[ 3.056987] pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 37, base_baud = 928571) is a UART2
[ 3.069918] pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 36, base_baud = 928571) is a UART3
[ 3.085482] nand: executing subop:
[ 3.091647] nand: ->CMD [0xff]
[ 3.095546] nand: ->WAITRDY [max 250 ms]
[ 3.100705] marvell-nfc pxa3xx-nand:
[ 3.100705] NDCR: 0x90079fff
[ 3.100705] NDCB0: 0x00a000ff
[ 3.100705] NDCB1: 0x00000000
[ 3.100705] NDCB2: 0x00000000
[ 3.100705] NDCB3: 0x00000000
[ 3.119968] nand: executing subop:
[ 3.123439] nand: ->CMD [0x90]
[ 3.127315] nand: ->ADDR [1 cyc: 00]
[ 3.131983] nand: ->DATA_IN [2 B, force 8-bit]
[ 3.136985] marvell-nfc pxa3xx-nand:
[ 3.136985] NDCR: 0x90079fff
[ 3.136985] NDCB0: 0x00610090
[ 3.136985] NDCB1: 0x00000000
[ 3.136985] NDCB2: 0x00000000
[ 3.136985] NDCB3: 0x00000000
[ 3.155819] nand: executing subop:
[ 3.159462] nand: ->CMD [0x90]
[ 3.163343] nand: ->ADDR [1 cyc: 00]
[ 3.167635] nand: ->DATA_IN [8 B, force 8-bit]
[ 3.172747] marvell-nfc pxa3xx-nand:
[ 3.172747] NDCR: 0x90079fff
[ 3.172747] NDCB0: 0x00610090
[ 3.172747] NDCB1: 0x00000000
[ 3.172747] NDCB2: 0x00000000
[ 3.172747] NDCB3: 0x00000000
[ 3.191422] nand: executing subop:
[ 3.194876] nand: ->CMD [0x90]
[ 3.198897] nand: ->ADDR [1 cyc: 20]
[ 3.203210] nand: ->DATA_IN [4 B, force 8-bit]
[ 3.208314] marvell-nfc pxa3xx-nand:
[ 3.208314] NDCR: 0x90079fff
[ 3.208314] NDCB0: 0x00610090
[ 3.208314] NDCB1: 0x00000020
[ 3.208314] NDCB2: 0x00000000
[ 3.208314] NDCB3: 0x00000000
[ 3.226920] nand: executing subop:
[ 3.230511] nand: ->CMD [0x90]
[ 3.234394] nand: ->ADDR [1 cyc: 40]
[ 3.238830] nand: ->DATA_IN [5 B, force 8-bit]
[ 3.243808] marvell-nfc pxa3xx-nand:
[ 3.243808] NDCR: 0x90079fff
[ 3.243808] NDCB0: 0x00610090
[ 3.243808] NDCB1: 0x00000040
[ 3.243808] NDCB2: 0x00000000
[ 3.243808] NDCB3: 0x00000000
[ 3.262444] nand: device found, Manufacturer ID: 0x20, Chip ID: 0xba
[ 3.268947] nand: ST Micro NAND 256MiB 1,8V 16-bit
[ 3.273791] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 3.281519] marvell-nfc pxa3xx-nand: No minimum ECC strength, using 1b/512B
[ 3.288669] Scanning device for bad blocks
[ 3.292845] nand: nand_do_read_oob: from = 0x00000000, len = 64
[ 3.299007] marvell-nfc pxa3xx-nand:
[ 3.299007] NDCR: 0x9d079fff
[ 3.299007] NDCB0: 0x000d3000
[ 3.299007] NDCB1: 0x00000000
[ 3.299007] NDCB2: 0x00000000
[ 3.299007] NDCB3: 0x00000000
[ 3.318075] Bad eraseblock 0 at 0x000000000000
[ 3.322773] nand: nand_do_read_oob: from = 0x00020000, len = 64
[ 3.328941] marvell-nfc pxa3xx-nand:
[ 3.328941] NDCR: 0x9d079fff
[ 3.328941] NDCB0: 0x000d3000
[ 3.328941] NDCB1: 0x00400000
[ 3.328941] NDCB2: 0x00000000
[ 3.328941] NDCB3: 0x00000000
[ 3.347848] nand: nand_do_read_oob: from = 0x00040000, len = 64
[ 3.354049] marvell-nfc pxa3xx-nand:
[ 3.354049] NDCR: 0x9d079fff
[ 3.354049] NDCB0: 0x000d3000
[ 3.354049] NDCB1: 0x00800000
[ 3.354049] NDCB2: 0x00000000
[ 3.354049] NDCB3: 0x00000000
[ 3.372925] Bad eraseblock 2 at 0x000000040000
[ 3.377451] nand: nand_do_read_oob: from = 0x00060000, len = 64
[ 3.383633] marvell-nfc pxa3xx-nand:
[ 3.383633] NDCR: 0x9d079fff
[ 3.383633] NDCB0: 0x000d3000
[ 3.383633] NDCB1: 0x00c00000
[ 3.383633] NDCB2: 0x00000000
[ 3.383633] NDCB3: 0x00000000
[ 3.402509] Bad eraseblock 3 at 0x000000060000
... and so on ...
[ 60.154031] marvell-nfc pxa3xx-nand:
[ 60.154031] NDCR: 0x9d079fff
[ 60.154031] NDCB0: 0x000d3000
[ 60.154031] NDCB1: 0x58410000
[ 60.154031] NDCB2: 0x00000000
[ 60.154031] NDCB3: 0x00000000
[ 60.173335] ubi0: scanning is finished
[ 60.177297] ubi0 error: ubi_read_volume_table: the layout volume was not found
[ 60.184878] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd5, error -22
[ 60.192397] UBI error: cannot attach mtd5
[ 60.197652] pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:01:25 UTC (946684885)
[ 60.282788] smc91x smc91x.0 eth0: link down
[ 62.152546] smc91x smc91x.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[ 62.198419] IP-Config: Complete:
[ 62.201766] device=eth0, hwaddr=00:0e:0c:a7:26:f7, ipaddr=192.168.1.232, mask=255.255.255.0, gw=255.255.255.255
[ 62.212438] host=192.168.1.232, domain=, nis-domain=(none)
[ 62.218511] bootserver=192.168.1.5, rootserver=192.168.1.5, rootpath=
[ 62.226759] ALSA device list:
[ 62.230209] #0: Zylonite
[ 62.255735] Freeing unused kernel memory: 2396K
[ 62.260675] This architecture does not have kernel memory protection.
Starting logging: OK
^ permalink raw reply
* [PATCH] IIO: ADC: stm32-dfsdm: avoid unused-variable warning
From: Arnaud Pouliquen @ 2018-01-11 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <866335ff-d9a8-99c0-0946-82b3f207f266@arm.com>
On 01/11/2018 03:27 PM, Robin Murphy wrote:
> On 11/01/18 10:34, Arnd Bergmann wrote:
>> Building with CONFIG_OF disabled produces a compiler warning:
>>
>> drivers/iio/adc/stm32-dfsdm-core.c: In function 'stm32_dfsdm_probe':
>> drivers/iio/adc/stm32-dfsdm-core.c:245:22: error: unused variable
>> 'pnode' [-Werror=unused-variable]
>>
>> This removes the variable and open-codes it in the only place
>> it gets used to avoid that warning.
>>
>> Fixes: bed73904e76f ("IIO: ADC: add stm32 DFSDM core support")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> ? drivers/iio/adc/stm32-dfsdm-core.c | 3 +--
>> ? 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/iio/adc/stm32-dfsdm-core.c
>> b/drivers/iio/adc/stm32-dfsdm-core.c
>> index 72427414db7f..6cd655f8239b 100644
>> --- a/drivers/iio/adc/stm32-dfsdm-core.c
>> +++ b/drivers/iio/adc/stm32-dfsdm-core.c
>> @@ -242,7 +242,6 @@ MODULE_DEVICE_TABLE(of, stm32_dfsdm_of_match);
>> ? static int stm32_dfsdm_probe(struct platform_device *pdev)
>> ? {
>> ????? struct dfsdm_priv *priv;
>> -??? struct device_node *pnode = pdev->dev.of_node;
>> ????? const struct of_device_id *of_id;
>> ????? const struct stm32_dfsdm_dev_data *dev_data;
>> ????? struct stm32_dfsdm *dfsdm;
>> @@ -254,7 +253,7 @@ static int stm32_dfsdm_probe(struct
>> platform_device *pdev)
>> ? ????? priv->pdev = pdev;
>> ? -??? of_id = of_match_node(stm32_dfsdm_of_match, pnode);
>> +??? of_id = of_match_node(stm32_dfsdm_of_match, pdev->dev.of_node);
>> ????? if (!of_id->data) {
>> ????????? dev_err(&pdev->dev, "Data associated to device is missing\n");
>> ????????? return -EINVAL;
>
> FWIW, it looks like this whole lot could be cleaned up by using
> of_device_get_match_data().
>
Right, and test of the return now seems to me an overprotection as data
structure is defined in the driver...
Same optimization could be applied to stm32_dfsdm_adc_probe function.
Here is the patch I tested:
---
drivers/iio/adc/stm32-dfsdm-adc.c | 9 +--------
drivers/iio/adc/stm32-dfsdm-core.c | 9 +--------
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c
b/drivers/iio/adc/stm32-dfsdm-adc.c
index b03ca3f..01836c9 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -1087,18 +1087,11 @@ static int stm32_dfsdm_adc_probe(struct
platform_device *pdev)
struct device_node *np = dev->of_node;
const struct stm32_dfsdm_dev_data *dev_data;
struct iio_dev *iio;
- const struct of_device_id *of_id;
char *name;
int ret, irq, val;
- of_id = of_match_node(stm32_dfsdm_adc_match, np);
- if (!of_id->data) {
- dev_err(&pdev->dev, "Data associated to device is missing\n");
- return -EINVAL;
- }
-
- dev_data = (const struct stm32_dfsdm_dev_data *)of_id->data;
+ dev_data = of_device_get_match_data(dev);
iio = devm_iio_device_alloc(dev, sizeof(*adc));
if (IS_ERR(iio)) {
dev_err(dev, "%s: Failed to allocate IIO\n", __func__);
diff --git a/drivers/iio/adc/stm32-dfsdm-core.c
b/drivers/iio/adc/stm32-dfsdm-core.c
index 7242741..6290332 100644
--- a/drivers/iio/adc/stm32-dfsdm-core.c
+++ b/drivers/iio/adc/stm32-dfsdm-core.c
@@ -242,8 +242,6 @@ MODULE_DEVICE_TABLE(of, stm32_dfsdm_of_match);
static int stm32_dfsdm_probe(struct platform_device *pdev)
{
struct dfsdm_priv *priv;
- struct device_node *pnode = pdev->dev.of_node;
- const struct of_device_id *of_id;
const struct stm32_dfsdm_dev_data *dev_data;
struct stm32_dfsdm *dfsdm;
int ret;
@@ -254,13 +252,8 @@ static int stm32_dfsdm_probe(struct platform_device
*pdev)
priv->pdev = pdev;
- of_id = of_match_node(stm32_dfsdm_of_match, pnode);
- if (!of_id->data) {
- dev_err(&pdev->dev, "Data associated to device is missing\n");
- return -EINVAL;
- }
+ dev_data = of_device_get_match_data(&pdev->dev);
- dev_data = (const struct stm32_dfsdm_dev_data *)of_id->data;
dfsdm = &priv->dfsdm;
dfsdm->fl_list = devm_kcalloc(&pdev->dev, dev_data->num_filters,
sizeof(*dfsdm->fl_list), GFP_KERNEL);
--
Arnd,
fell free to propose it (with my acked-by) or tell me if you
prefer that i send it.
Thanks,
Arnaud
^ permalink raw reply related
* [PATCH 2/2] kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
From: Will Deacon @ 2018-01-11 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff221eca3db7a1f208c30c625b7d209fba33abb9.1515684162.git.andreyknvl@google.com>
On Thu, Jan 11, 2018 at 04:29:09PM +0100, Andrey Konovalov wrote:
> Right now the fact that KASAN uses a single shadow byte for 8 bytes of
> memory is scattered all over the code.
>
> This change defines KASAN_SHADOW_SCALE_SHIFT early in asm include files
> and makes use of this constant where necessary.
>
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> arch/arm64/include/asm/kasan.h | 3 ++-
> arch/arm64/include/asm/memory.h | 3 ++-
> arch/arm64/mm/kasan_init.c | 3 ++-
> arch/x86/include/asm/kasan.h | 8 ++++++--
> include/linux/kasan.h | 2 --
> 5 files changed, 12 insertions(+), 7 deletions(-)
For the arm64 parts:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Kim Phillips @ 2018-01-11 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkzBi3M48VtUYJcSREshXBxiaN5m5RsCcdi=4C1Z7jmMoA@mail.gmail.com>
On Thu, 11 Jan 2018 08:45:21 -0700
Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On 11 January 2018 at 05:23, Mark Brown <broonie@kernel.org> wrote:
> > On Wed, Jan 10, 2018 at 06:08:21PM -0600, Kim Phillips wrote:
> >> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >
> >> > Instructions on how to build and install the openCSD library are provided
> >> > in the HOWTO.md of the project repository.
> >
> >> Usually when a perf builder sees something they need "on," they - or,
> >> at least I - start querying the host's package manager for something
> >> that provides it (e.g., apt search/install libopencsd), but since no
> >> distro provides libopencsd, this is bad because it misleads the user.
> >
> > It's on the radar to push this at distros fairly soon.
Adding packages to distros takes years, this patchset is being
submitted for inclusion *now*. So until then, it would greatly
facilitate users if the relevant libopencsd source files were
self-contained within perf from the get go.
> > Part of the
> > discussion was wanting to get things to the point where the tools using
> > the library were far enough along that we could be reasonably sure that
Curious, what other tools are there?
> > there weren't any problems that were going to require ABI breaks to fix
> > before pushing the library at distros since ABI churn isn't nice for
> > packagers to deal with.
Why make perf the guinea pig? Whatever, this doesn't preclude
adding the code into the tree; it can be removed years from now when
libopencsd becomes ubiquitous among distros.
> > There's also a bit of a chicken and egg problem
> > in that it's a lot easier to get distros to package libraries that have
> > users available (some are not really bothered about this of course but
> > it still helps).
>
> Moreover including in the kernel tree every library that can
> potentially be used by the perf tools simply doesn't scale.
This is a trace decoder library we're talking about: there are no
others in perf's system features autodetection list. And why wouldn't
adding such libraries scale?
> The perf
> tools project has come up with a very cleaver way to deal with
> external dependencies and I don't see why the OpenCSD library should
> be different.
Again, the opencsd library is a decoder library: this patchseries adds
it as a package dependency (when it isn't even a package in any
distro), and it's different in that it's the first decoder library to
be submitted as an external dependency (i.e., not fully built-in, like
Intel's, or even the Arm SPE's pending submission).
> >> Keeping the library external will also inevitably introduce more
> >> source level synchronization problems because the perf sources being
> >> built may not be compatible with their version of the library, whether
> >> due to new features like new trace hardware support, or API changes.
> >
> > Perf users installing from source rather than from a package (who do
> > tend to the more technical side even for kernel developers) already have
> > to cope with potentially installing at least dwarf, gtk2, libaudit,
> > libbfd, libelf, libnuma, libperl, libpython, libslang, libcrypto,
> > libunwind, libdw-dwarf-unwind, zlib, lzma, bpf and OpenJDK depending on
> > which features they want. I'm not sure that adding one more library is
> > going to be the end of the world here, especially once the packaging
> > starts to filter through distros. Until that happens at least people
> > are no worse off for not having the feature.
>
> I completely agree. Just like any other package, people that want the
> very latest code need to install from source.
A fully-integrated solution would work better for people, e.g., how are
people supposed to know what 'latest' is when there are separate,
unsynchronized git repos?
> >> As Mark Brown (cc'd) mentioned on the Coresight mailing list, this may
> >> be able to be done the same way the dtc is incorporated into the
> >> kernel, where only its relevant sources are included and updated as
> >> needed: see linux/scripts/dtc/update-dtc-source.sh.
> >
> > Bear in mind that we need dtc for essentially all kernel development on
> > ARM and when it was introduced it was a new requirement for existing
> > systems, it's a bit of a different case here where it's an optional
> > feature in an optional tool.
That argument applies to Intel-PT, yet its decoder is self-contained
within perf: all non-x86 perf binaries are capable of decoding PT.
We'd want that for Arm Coresight where perf gets statically built to
run on much more constrained systems like Android.
Or are you referring to the higher level linux/scripts/ location of the
dtc? That's not my point: the libopencsd sources can live under
somewhere like linux/tools/.
Kim
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: David Lechner @ 2018-01-11 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xKORFriQ2Gjx85OsCUzHO-mavCQXLOzh5D3n4kEG=i-Yg@mail.gmail.com>
On 01/11/2018 06:45 AM, Adam Ford wrote:
> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com> wrote:
>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>
>>>
>>> I am available tomorrow to build and test patches against the
>>> da850-evm. I just need to know which version(s) to test.
>>
>>
>> Great. As per the cover letter:
>>
>> You can find a working branch with everything included in the
>> "common-clk-v5"
>> branch of https://github.com/dlech/ev3dev-kernel.git.
>
> I wasn't sure if things had changed after some of the dialog about the
> bindings and device tree.
Not yet. ;-)
>
> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
> CST 2018
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> CPU: VIVT data cache, VIVT instruction cache
> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
OK, using device tree...
> Memory policy: Data cache writethrough
> cma: Reserved 16 MiB at 0xc2c00000
> DaVinci da850/omap-l138 variant 0x0
> random: fast init done
> Built 1 zonelists, mobility grouping on. Total pages: 16256
> Kernel command line: console=ttyS2,115200n8 root=PARTUUID= rw
> rootfstype=ext4 rootwait
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 42164K/65536K available (4548K kernel code, 280K rwdata, 1044K
> rodata, 232K init, 143K bss, 6988K reserved, 16384K cma-reserved)
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
> lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
> modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> .text : 0x(ptrval) - 0x(ptrval) (4550 kB)
> .init : 0x(ptrval) - 0x(ptrval) ( 232 kB)
> .data : 0x(ptrval) - 0x(ptrval) ( 281 kB)
> .bss : 0x(ptrval) - 0x(ptrval) ( 144 kB)
> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> Preemptible hierarchical RCU implementation.
> Tasks RCU enabled.
> NR_IRQS: 245
> clocksource: timer0_1: mask: 0xffffffff max_cycles: 0xffffffff,
> max_idle_ns: 79635851949 ns
> sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
> 89478484971ns
> Console: colour dummy device 80x30
> Calibrating delay loop... 148.88 BogoMIPS (lpj=744448)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0xc0008400 - 0xc0008458
> Hierarchical SRCU implementation.
> devtmpfs: initialized
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
> max_idle_ns: 19112604462750000 ns
> futex hash table entries: 256 (order: -1, 3072 bytes)
> pinctrl core: initialized pinctrl subsystem
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> cpuidle: using governor menu
> mux: initialized RTC_ALARM
> mux: Setting register RTC_ALARM
> mux: PINMUX0 (0x00000000) = 0x44080000 -> 0x24080000
> edma 1c00000.edma: memcpy is disabled
> edma 1c00000.edma: TI EDMA DMA engine driver
> edma 1e30000.edma: memcpy is disabled
> edma 1e30000.edma: TI EDMA DMA engine driver
> i2c_davinci 1c22000.i2c: could not find pctldev for node
> /soc at 1c00000/pinmux at 14120/pinmux_i2c0_pins, deferring probe
> clocksource: Switched to clocksource timer0_1
> NET: Registered protocol family 2
> TCP established hash table entries: 1024 (order: 0, 4096 bytes)
> TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> TCP: Hash tables configured (established 1024 bind 1024)
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> Initialise system trusted keyrings
> workingset: timestamp_bits=30 max_order=14 bucket_order=0
> Key type asymmetric registered
> Asymmetric key parser 'x509' registered
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> io scheduler noop registered (default)
> io scheduler mq-deadline registered
> io scheduler kyber registered
> pinctrl-single 1c14120.pinmux: 160 pins at pa fdfe34a6 size 80
> Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
> 1c42000.serial: ttyS0 at MMIO 0x1c42000 (irq = 25, base_baud =
> 9375000) is a TI DA8xx/66AK2x
> 1d0c000.serial: ttyS1 at MMIO 0x1d0c000 (irq = 53, base_baud =
> 8250000) is a TI DA8xx/66AK2x
> 1d0d000.serial: ttyS2 at MMIO 0x1d0d000 (irq = 61, base_baud =
> 8250000) is a TI DA8xx/66AK2x
> console [ttyS2] enabled
If you are getting to this point, you probably don't need DEBUG_LL.
It looks like "earlyprint" is not being passed to the command line
anyway, so CONFIG_EARLY_PRINTK is not actually doing anything.
> brd: module loaded
> libphy: Fixed MDIO Bus: probed
> davinci_mdio 1e24000.mdio: failed to get device clock
> davinci_mdio: probe of 1e24000.mdio failed with error -2
It looks like this needs a clock-names property in the device tree.
Please make this change and try again:
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 08a9817..fd3e316 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -713,6 +713,7 @@
#size-cells = <0>;
reg = <0x224000 0x1000>;
clocks = <&psc1 5>;
+ clock-names = "fck";
status = "disabled";
};
eth0: ethernet at 220000 {
> i2c /dev entries driver
> davinci_mmc 1c40000.mmc: Using DMA, 4-bit mode
> NET: Registered protocol family 10
> Segment Routing with IPv6
> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> NET: Registered protocol family 17
> Loading compiled-in X.509 certificates
> mmc0: host does not support reading read-only switch, assuming
> write-enable
> mmc0: new high speed SDHC card at address b368
> mmcblk0: mmc0:b368 00000 3.75 GiB
> mmcblk0: p1 p2
> pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
> pca953x 0-0020: failed reading register
> pca953x: probe of 0-0020 failed with error -121
I'm not sure why there is an error here. I'm using I2C0 on my board,
so I am fairly confident that it is not a problem introduced by this
series.
> console [netcon0] enabled
> netconsole: network logging started
> davinci_emac 1e20000.ethernet: incompatible machine/device type for
> reading mac address
> hctosys: unable to open rtc device (rtc0)
>
What is normally the next line after this in a working boot?
Also please try passing "clk_ignore_unused" to the kernel command line.
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
From: Timur Tabi @ 2018-01-11 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6vA652LCosMc+AsQ2Gb_mgiApx+Gxu9judXnO_p3AFcsw@mail.gmail.com>
On 01/11/2018 10:33 AM, Grant Likely wrote:
> What level of access control is implemented here? Is there access
> control for each GPIO individually, or is it done by banks of GPIOs?
> Just asking to make sure I understand the problem domain.
On our ACPI system, it's specific GPIOs. Each GPIO is in its own 64k
page, which is what allows us to block specific ones.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH net-next v4 0/4] net: mvpp2: 1000BaseX and 2500BaseX support
From: Thomas Petazzoni @ 2018-01-11 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111.113203.1899608306187914852.davem@davemloft.net>
Hello,
On Thu, 11 Jan 2018 11:32:03 -0500 (EST), David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 11 Jan 2018 11:23:37 -0500 (EST)
>
> > From: Antoine Tenart <antoine.tenart@free-electrons.com>
> > Date: Wed, 10 Jan 2018 16:58:04 +0100
> >
> >> This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
> >> driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
> >> common PHY driver (cp110-comphy).
> >
> > Series applied, thank you.
>
> Actually, this introduced build warnings, I'm reverting. Please fix this
> and repost.
>
> Thank you.
>
> drivers/net/ethernet/marvell/mvpp2.c: In function ?mvpp2_port_mii_gmac_configure_mode?:
> drivers/net/ethernet/marvell/mvpp2.c:4687:26: warning: suggest parentheses around comparison in operand of ?|? [-Wparentheses]
> if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX |
> ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is actually a very good warning: it should be a || and not |.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 06/19] drm/blend: Add a generic alpha property
From: Daniel Vetter @ 2018-01-11 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111155857.bbfp4772fx56s5k3@flea.lan>
On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
>> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
>> > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
>> > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
>> > > > Some drivers duplicate the logic to create a property to store a per-plane
>> > > > alpha.
>> > > >
>> > > > Let's create a helper in order to move that to the core.
>> > > >
>> > > > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
>> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>> > >
>> > > Do we have userspace for this?
>> >
>> > Wayland seems to be on its way to implement this, with ChromeOS using
>> > it:
>> > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
>> >
>> > and more specifically:
>> > https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118
>>
>> Yay, would be good to include these links in the patch description. Really
>> happy we're having a real standard now used by multiple people.
>
> I will.
>
>> > > Is encoding a fixed 0-255 range really the best idea?
>> >
>> > I don't really know, is there hardware or formats where there is more
>> > than 255? Or did you mean less than that?
>>
>> 30bit I'd assume wants more alpha. In the past we've done some fixed-point
>> stuff (e.g. for LUT), using the 0.0-1.0 float range. Using that for the
>> blend equation docs is also what I recommend (and that we map from 0-255
>> to 0.0-1.0 logically). Ofc the hw might not do any of that ... I think
>> 0.16 fixed point, stored in a u16 is probably best. That's what we're
>> doing for gamma tables already, and that way drivers can simply throw away
>> the lower bits.
>
> But that would also break the two users of that property that won't be
> able to move to the generic property (with the same name) without
> breaking userspace. The point of that patch was to allow some code
> consolidation, and that would mean failing to do so here :/
Let me try to clarify:
- We'll keep the exact existing property semantics with the 0-255
range for the userspace visible property.
- But internally, in the decode value that we store into
drm_plane_state, we'll do the slightly more future proof thing with a
few more bits.
That gives us the option of exposing those bits in the future without
having to change all the drivers again (which we have to do for this
series here already anyway, since the decoded value moves into
drm_plane_state from driver subclasses).
Definitely not asking to break userspace here :-)
Cheers, Daniel
>> > > I know other drivers have skimped on the rules here a bit ... But at least
>> > > internally (i.e. within the drm_plane_state) we probably should restrict
>> > > ourselves to u8. And this needs real docs (i.e. the full blend equation
>> > > drivers are supposed to implement).
>> >
>> > You mean straight vs premultiplied? Maybe we should implement this as
>> > an additional property in read only depending on how the hardware
>> > behaves?
>>
>> No need for an additional property right now, but definitely document
>> whether you mean straight or pre-multiplied. Just writing down the blend
>> equation is probably best.
>
> Ack.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
From: Grant Likely @ 2018-01-11 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaN6vmV4L4U76DvD5BN+j1RYCQakTysA+GGPdT8Chc-iw@mail.gmail.com>
On Wed, Jan 10, 2018 at 1:37 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Jan 10, 2018 at 2:58 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>
>> Some qcom platforms make some GPIOs or pins unavailable for use
>> by non-secure operating systems, and thus reading or writing the
>> registers for those pins will cause access control issues.
>> Introduce a DT property to describe the set of GPIOs that are
>> available for use so that higher level OSes are able to know what
>> pins to avoid reading/writing.
What level of access control is implemented here? Is there access
control for each GPIO individually, or is it done by banks of GPIOs?
Just asking to make sure I understand the problem domain.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>
> I like the idea, let's check what we think about the details regarding
> naming and semantics, I need feedback from some DT people
> in particular.
>
> Paging in Grant on this as he might have some input.
>
>> I stuck this inside msm8996, but maybe it can go somewhere more generic?
>
> Yeah just put it in Documentation/devicetree/bindings/gpio/gpio.txt
> Everyone and its dog doing GPIO reservations "from another world"
> will need to use this.
>
>> +- ngpios-ranges:
>> + Usage: optional
>> + Value type: <prop-encoded-array>
>> + Definition: Tuples of GPIO ranges (base, size) indicating
>> + GPIOs available for use.
>> +
>> Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
>> a general description of GPIO and interrupt bindings.
>
> I like the tuples syntax. That's fine. It's like gpio-ranges we have
> already to map between pin controllers and GPIO.
>
> I don't think we can reuse gpio-ranges because that is
> exclusively for pin control ATM, it would be fine if the ranges
> were for a specific device, like pin control does, like:
>
> gpio-ranges = <&secure_world_thing 0 20 10>;
>
> But you definately would need a node to tie it to, so that the
> driver for that node can specify that it's gonna take the
> GPIOs.
>
> But I think the semantics should be the inverse. That you
> point out "holes" with the lines we *can't* use.
>
> We already support a generic property "ngpios" that says how
> many of the GPIOs (counted from zero) that can be used,
> so if those should be able to use this as a generic property it
> is better with the inverse semantics and say that the
> "reserved-gpio-ranges", "secureworld-gpio-ranges"
> (or whatever we decide to call it) takes precedence over
> ngpios so we don't end up in ambigous places.
Heh, I just went down the same thought process on the naming before I
read the above. Yes I agree. The property name should have something
like "reserved" in it. I vote for "gpio-reserved-ranges" because it
puts the binding owner (gpio) at the front of the name, it indicates
that the list is unavailable GPIOs, and that the format is a set of
ranges.
The fiddly bit is it assumes the GPIOs are described by a single
number. It works fine as long as the GPIO controllers can use a single
cell to describe a gpio number (instead of having #gpio-cells = 3 with
the first cell being bank, the second being number in bank, and the
third being flags).
>
> Then, will it be possible to put the parsing, handling and
> disablement of these ranges into drivers/gpio/gpiolib-of.c
> where we handle the ranges today, or do we need to
> do it in the individual drivers?
I certainly would prefer parsing this in common code, and not in
individual drivers, but again it becomes hard for any driver using
multiple cells to describe the local GPIO number. I think the guidance
here needs to be that the property is relevant when the internal GPIO
number representation fits within a uint32, which realistically should
never be a problem.
g.
^ permalink raw reply
* [PATCH net-next v4 0/4] net: mvpp2: 1000BaseX and 2500BaseX support
From: David Miller @ 2018-01-11 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111.112337.98385023847631863.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 11 Jan 2018 11:23:37 -0500 (EST)
> From: Antoine Tenart <antoine.tenart@free-electrons.com>
> Date: Wed, 10 Jan 2018 16:58:04 +0100
>
>> This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
>> driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
>> common PHY driver (cp110-comphy).
>
> Series applied, thank you.
Actually, this introduced build warnings, I'm reverting. Please fix this
and repost.
Thank you.
drivers/net/ethernet/marvell/mvpp2.c: In function ?mvpp2_port_mii_gmac_configure_mode?:
drivers/net/ethernet/marvell/mvpp2.c:4687:26: warning: suggest parentheses around comparison in operand of ?|? [-Wparentheses]
if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX |
~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
* [PATCH v2] MAINTAINERS: mtd/nand: update Microchip nand entry
From: Nicolas Ferre @ 2018-01-11 16:26 UTC (permalink / raw)
To: linux-arm-kernel
Update Wenyou Yang email address.
Take advantage of this update to move this entry to the MICROCHIP / ATMEL
location and add the DT binding documentation link.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Wenyou Yang <wenyou.yang@microchip.com>
---
v2: - patch agains 09ec417b0ea8 ("mtd: nand: samsung: Disable subpage
writes on E-die NAND") of
http://git.infradead.org/linux-mtd.git/shortlog/refs/heads/nand/next
- Ack by Wenyou added
Hi,
v1 patch was part of a series because it was conflicting with the previous one
named:
"[PATCH 1/2] MAINTAINERS: linux-media: update Microchip ISI and ISC entries"
Boris asked me to rebase it so that they are independent.
So, if this first one goes upstream through another tree, conflicts will have
to be resolved at one point.
Best regards,
Nicolas
MAINTAINERS | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..37ee5ae4bae2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2382,13 +2382,6 @@ F: Documentation/devicetree/bindings/input/atmel,maxtouch.txt
F: drivers/input/touchscreen/atmel_mxt_ts.c
F: include/linux/platform_data/atmel_mxt_ts.h
-ATMEL NAND DRIVER
-M: Wenyou Yang <wenyou.yang@atmel.com>
-M: Josh Wu <rainyfeeling@outlook.com>
-L: linux-mtd at lists.infradead.org
-S: Supported
-F: drivers/mtd/nand/atmel/*
-
ATMEL SAMA5D2 ADC DRIVER
M: Ludovic Desroches <ludovic.desroches@microchip.com>
L: linux-iio at vger.kernel.org
@@ -9045,6 +9038,14 @@ F: drivers/media/platform/atmel/atmel-isc.c
F: drivers/media/platform/atmel/atmel-isc-regs.h
F: devicetree/bindings/media/atmel-isc.txt
+MICROCHIP / ATMEL NAND DRIVER
+M: Wenyou Yang <wenyou.yang@microchip.com>
+M: Josh Wu <rainyfeeling@outlook.com>
+L: linux-mtd at lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/atmel/*
+F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
+
MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
M: Woojung Huh <Woojung.Huh@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
--
2.9.0
^ permalink raw reply related
* [PATCH net-next v4 0/4] net: mvpp2: 1000BaseX and 2500BaseX support
From: David Miller @ 2018-01-11 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110155808.3484-1-antoine.tenart@free-electrons.com>
From: Antoine Tenart <antoine.tenart@free-electrons.com>
Date: Wed, 10 Jan 2018 16:58:04 +0100
> This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
> driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
> common PHY driver (cp110-comphy).
Series applied, thank you.
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Adam Ford @ 2018-01-11 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14320e05-c6f7-fa2d-35cd-c01414c59f2f@ti.com>
On Thu, Jan 11, 2018 at 9:47 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Thursday 11 January 2018 06:15 PM, Adam Ford wrote:
>> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com> wrote:
>>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>>
>>>>
>>>> I am available tomorrow to build and test patches against the
>>>> da850-evm. I just need to know which version(s) to test.
>>>
>>>
>>> Great. As per the cover letter:
>>>
>>> You can find a working branch with everything included in the
>>> "common-clk-v5"
>>> branch of https://github.com/dlech/ev3dev-kernel.git.
>>
>> I wasn't sure if things had changed after some of the dialog about the
>> bindings and device tree.
>>
>> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>>
>> Starting kernel ...
>>
>> Uncompressing Linux... done, booting the kernel.
>> Booting Linux on physical CPU 0x0
>> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
>> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
>> CST 2018
>> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
>> CPU: VIVT data cache, VIVT instruction cache
>> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
>> Memory policy: Data cache writethrough
>> cma: Reserved 16 MiB at 0xc2c00000
>> DaVinci da850/omap-l138 variant 0x0
>> random: fast init done
>> Built 1 zonelists, mobility grouping on. Total pages: 16256
>> Kernel command line: console=ttyS2,115200n8 root=PARTUUID= rw
>
> Pretty sure an actual UUID is missing here.
>
When I setup root to be on the /dev/mmcblk0, I get the same result.
The kernel still hangs. It doesn't hang using the mainline kernel
without this patch series
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
(Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
CST 2018
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
CPU: VIVT data cache, VIVT instruction cache
OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
Memory policy: Data cache writethrough
cma: Reserved 16 MiB at 0xc2c00000
DaVinci da850/omap-l138 variant 0x0
random: fast init done
Built 1 zonelists, mobility grouping on. Total pages: 16256
Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw
rootfstype=ext4 rootwait
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 42164K/65536K available (4548K kernel code, 280K rwdata, 1044K
rodata, 232K init, 143K bss, 6988K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0x(ptrval) - 0x(ptrval) (4550 kB)
.init : 0x(ptrval) - 0x(ptrval) ( 232 kB)
.data : 0x(ptrval) - 0x(ptrval) ( 281 kB)
.bss : 0x(ptrval) - 0x(ptrval) ( 144 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
Tasks RCU enabled.
NR_IRQS: 245
clocksource: timer0_1: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 79635851949 ns
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
Console: colour dummy device 80x30
Calibrating delay loop... 148.88 BogoMIPS (lpj=744448)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc0008400 - 0xc0008458
Hierarchical SRCU implementation.
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor menu
mux: initialized RTC_ALARM
mux: Setting register RTC_ALARM
mux: PINMUX0 (0x00000000) = 0x44080000 -> 0x24080000
edma 1c00000.edma: memcpy is disabled
edma 1c00000.edma: TI EDMA DMA engine driver
edma 1e30000.edma: memcpy is disabled
edma 1e30000.edma: TI EDMA DMA engine driver
i2c_davinci 1c22000.i2c: could not find pctldev for node
/soc at 1c00000/pinmux at 14120/pinmux_i2c0_pins, deferring probe
clocksource: Switched to clocksource timer0_1
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Initialise system trusted keyrings
workingset: timestamp_bits=30 max_order=14 bucket_order=0
Key type asymmetric registered
Asymmetric key parser 'x509' registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered (default)
io scheduler mq-deadline registered
io scheduler kyber registered
pinctrl-single 1c14120.pinmux: 160 pins at pa fdfe34a6 size 80
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
1c42000.serial: ttyS0 at MMIO 0x1c42000 (irq = 25, base_baud =
9375000) is a TI DA8xx/66AK2x
1d0c000.serial: ttyS1 at MMIO 0x1d0c000 (irq = 53, base_baud =
8250000) is a TI DA8xx/66AK2x
1d0d000.serial: ttyS2 at MMIO 0x1d0d000 (irq = 61, base_baud =
8250000) is a TI DA8xx/66AK2x
console [ttyS2] enabled
brd: module loaded
libphy: Fixed MDIO Bus: probed
davinci_mdio 1e24000.mdio: failed to get device clock
davinci_mdio: probe of 1e24000.mdio failed with error -2
i2c /dev entries driver
davinci_mmc 1c40000.mmc: Using DMA, 4-bit mode
NET: Registered protocol family 10
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
Loading compiled-in X.509 certificates
mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new high speed SDHC card at address b368
mmcblk0: mmc0:b368 00000 3.75 GiB
mmcblk0: p1 p2
pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
pca953x 0-0020: failed reading register
pca953x: probe of 0-0020 failed with error -121
console [netcon0] enabled
netconsole: network logging started
davinci_emac 1e20000.ethernet: incompatible machine/device type for
reading mac address
hctosys: unable to open rtc device (rtc0)
> Thanks,
> Sekhar
^ permalink raw reply
* [PATCH 06/19] drm/blend: Add a generic alpha property
From: Maxime Ripard @ 2018-01-11 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109142834.GZ26573@phenom.ffwll.local>
On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > > > Some drivers duplicate the logic to create a property to store a per-plane
> > > > alpha.
> > > >
> > > > Let's create a helper in order to move that to the core.
> > > >
> > > > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > >
> > > Do we have userspace for this?
> >
> > Wayland seems to be on its way to implement this, with ChromeOS using
> > it:
> > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
> >
> > and more specifically:
> > https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118
>
> Yay, would be good to include these links in the patch description. Really
> happy we're having a real standard now used by multiple people.
I will.
> > > Is encoding a fixed 0-255 range really the best idea?
> >
> > I don't really know, is there hardware or formats where there is more
> > than 255? Or did you mean less than that?
>
> 30bit I'd assume wants more alpha. In the past we've done some fixed-point
> stuff (e.g. for LUT), using the 0.0-1.0 float range. Using that for the
> blend equation docs is also what I recommend (and that we map from 0-255
> to 0.0-1.0 logically). Ofc the hw might not do any of that ... I think
> 0.16 fixed point, stored in a u16 is probably best. That's what we're
> doing for gamma tables already, and that way drivers can simply throw away
> the lower bits.
But that would also break the two users of that property that won't be
able to move to the generic property (with the same name) without
breaking userspace. The point of that patch was to allow some code
consolidation, and that would mean failing to do so here :/
> > > I know other drivers have skimped on the rules here a bit ... But at least
> > > internally (i.e. within the drm_plane_state) we probably should restrict
> > > ourselves to u8. And this needs real docs (i.e. the full blend equation
> > > drivers are supposed to implement).
> >
> > You mean straight vs premultiplied? Maybe we should implement this as
> > an additional property in read only depending on how the hardware
> > behaves?
>
> No need for an additional property right now, but definitely document
> whether you mean straight or pre-multiplied. Just writing down the blend
> equation is probably best.
Ack.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180111/3260f17f/attachment-0001.sig>
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Sekhar Nori @ 2018-01-11 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xKORFriQ2Gjx85OsCUzHO-mavCQXLOzh5D3n4kEG=i-Yg@mail.gmail.com>
On Thursday 11 January 2018 06:15 PM, Adam Ford wrote:
> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com> wrote:
>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>
>>>
>>> I am available tomorrow to build and test patches against the
>>> da850-evm. I just need to know which version(s) to test.
>>
>>
>> Great. As per the cover letter:
>>
>> You can find a working branch with everything included in the
>> "common-clk-v5"
>> branch of https://github.com/dlech/ev3dev-kernel.git.
>
> I wasn't sure if things had changed after some of the dialog about the
> bindings and device tree.
>
> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
> CST 2018
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> CPU: VIVT data cache, VIVT instruction cache
> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
> Memory policy: Data cache writethrough
> cma: Reserved 16 MiB at 0xc2c00000
> DaVinci da850/omap-l138 variant 0x0
> random: fast init done
> Built 1 zonelists, mobility grouping on. Total pages: 16256
> Kernel command line: console=ttyS2,115200n8 root=PARTUUID= rw
Pretty sure an actual UUID is missing here.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/9] iommu/rockchip: Fix error handling in attach
From: Robin Murphy @ 2018-01-11 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111082229.24011-3-jeffy.chen@rock-chips.com>
On 11/01/18 08:22, Jeffy Chen wrote:
> From: Tomasz Figa <tfiga@chromium.org>
>
> Currently if the driver encounters an error while attaching device, it
> will leave the IOMMU in an inconsistent state. Even though it shouldn't
> really happen in reality, let's just add proper error path to keep
> things consistent.
>
> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> ---
>
> drivers/iommu/rockchip-iommu.c | 26 +++++++++++++++++---------
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 9d991c2d8767..ee805e1dfba7 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -826,17 +826,10 @@ static int rk_iommu_attach_device(struct iommu_domain *domain,
>
> ret = rk_iommu_force_reset(iommu);
> if (ret)
> - return ret;
> + goto err_disable_stall;
>
> iommu->domain = domain;
>
> - for (i = 0; i < iommu->num_irq; i++) {
> - ret = devm_request_irq(iommu->dev, iommu->irq[i], rk_iommu_irq,
> - IRQF_SHARED, dev_name(dev), iommu);
> - if (ret)
> - return ret;
> - }
> -
> for (i = 0; i < iommu->num_mmu; i++) {
> rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR,
> rk_domain->dt_dma);
> @@ -844,9 +837,16 @@ static int rk_iommu_attach_device(struct iommu_domain *domain,
> rk_iommu_write(iommu->bases[i], RK_MMU_INT_MASK, RK_MMU_IRQ_MASK);
> }
>
> + for (i = 0; i < iommu->num_irq; i++) {
> + ret = devm_request_irq(iommu->dev, iommu->irq[i], rk_iommu_irq,
> + IRQF_SHARED, dev_name(dev), iommu);
Why aren't we simply requesting the IRQ once in rk_iommu_probe()? Given
that the hardware doesn't handle multiple translation contexts, there
doesn't seem to be much point in being this dynamic about it.
Robin.
> + if (ret)
> + goto err_free_irq;
> + }
> +
> ret = rk_iommu_enable_paging(iommu);
> if (ret)
> - return ret;
> + goto err_free_irq;
>
> spin_lock_irqsave(&rk_domain->iommus_lock, flags);
> list_add_tail(&iommu->node, &rk_domain->iommus);
> @@ -857,6 +857,14 @@ static int rk_iommu_attach_device(struct iommu_domain *domain,
> rk_iommu_disable_stall(iommu);
>
> return 0;
> +
> +err_free_irq:
> + while (i--)
> + devm_free_irq(iommu->dev, iommu->irq[i], iommu);
> +err_disable_stall:
> + rk_iommu_disable_stall(iommu);
> +
> + return ret;
> }
>
> static void rk_iommu_detach_device(struct iommu_domain *domain,
>
^ permalink raw reply
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Mathieu Poirier @ 2018-01-11 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111122317.GA7834@sirena.org.uk>
On 11 January 2018 at 05:23, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Jan 10, 2018 at 06:08:21PM -0600, Kim Phillips wrote:
>> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>
>> > Instructions on how to build and install the openCSD library are provided
>> > in the HOWTO.md of the project repository.
>
>> Usually when a perf builder sees something they need "on," they - or,
>> at least I - start querying the host's package manager for something
>> that provides it (e.g., apt search/install libopencsd), but since no
>> distro provides libopencsd, this is bad because it misleads the user.
>
> It's on the radar to push this at distros fairly soon. Part of the
> discussion was wanting to get things to the point where the tools using
> the library were far enough along that we could be reasonably sure that
> there weren't any problems that were going to require ABI breaks to fix
> before pushing the library at distros since ABI churn isn't nice for
> packagers to deal with. There's also a bit of a chicken and egg problem
> in that it's a lot easier to get distros to package libraries that have
> users available (some are not really bothered about this of course but
> it still helps).
Moreover including in the kernel tree every library that can
potentially be used by the perf tools simply doesn't scale. The perf
tools project has come up with a very cleaver way to deal with
external dependencies and I don't see why the OpenCSD library should
be different.
>
>> Keeping the library external will also inevitably introduce more
>> source level synchronization problems because the perf sources being
>> built may not be compatible with their version of the library, whether
>> due to new features like new trace hardware support, or API changes.
>
> Perf users installing from source rather than from a package (who do
> tend to the more technical side even for kernel developers) already have
> to cope with potentially installing at least dwarf, gtk2, libaudit,
> libbfd, libelf, libnuma, libperl, libpython, libslang, libcrypto,
> libunwind, libdw-dwarf-unwind, zlib, lzma, bpf and OpenJDK depending on
> which features they want. I'm not sure that adding one more library is
> going to be the end of the world here, especially once the packaging
> starts to filter through distros. Until that happens at least people
> are no worse off for not having the feature.
I completely agree. Just like any other package, people that want the
very latest code need to install from source.
>
>> As Mark Brown (cc'd) mentioned on the Coresight mailing list, this may
>> be able to be done the same way the dtc is incorporated into the
>> kernel, where only its relevant sources are included and updated as
>> needed: see linux/scripts/dtc/update-dtc-source.sh.
>
> Bear in mind that we need dtc for essentially all kernel development on
> ARM and when it was introduced it was a new requirement for existing
> systems, it's a bit of a different case here where it's an optional
> feature in an optional tool.
^ permalink raw reply
* [PATCH] clk: sunxi-ng: defaultly enable DE2 CCU for sun8i/sun50i
From: Maxime Ripard @ 2018-01-11 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111030451.9217-1-icenowy@aosc.io>
On Thu, Jan 11, 2018 at 11:04:51AM +0800, Icenowy Zheng wrote:
> As DE2 support for more SoCs are introducing, there's many reports that
> the DE2 is not functional due to DE2 CCU code not included in kernel.
>
> Defaultly enable DE2 CCU for sun8i/sun50i to reduce this kind of
> problems.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
One way to avoid this would have been to add the symbol to the sunxi
and multi_v7 defconfigs...
You're also adding a depends on. This should be explained or at least
mentionned in your commit log.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180111/4c116c1c/attachment.sig>
^ permalink raw reply
* [PATCH v1 2/4] ARM: PWM: add allwinner sun8i R40/V40/T3 pwm support.
From: Claudiu Beznea @ 2018-01-11 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111113241.GA21953@arx-s1>
On 11.01.2018 13:32, hao_zhang wrote:
> This patch add allwinner sun8i R40/V40/T3 pwm support.
>
> Signed-off-by: hao_zhang <hao5781286@gmail.com>
> ---
> drivers/pwm/Kconfig | 10 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-sun8i-r40.c | 394 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 405 insertions(+)
> create mode 100644 drivers/pwm/pwm-sun8i-r40.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 763ee50..cde5a70 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -444,6 +444,16 @@ config PWM_SUN4I
> To compile this driver as a module, choose M here: the module
> will be called pwm-sun4i.
>
> +config PWM_SUN8I_R40
> + tristate "Allwinner PWM SUN8I R40 support"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + depends on HAS_IOMEM && COMMON_CLK
> + help
> + Generic PWM framework driver for Allwinner SoCs R40, V40, T3.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-sun8i-r40.
> +
> config PWM_TEGRA
> tristate "NVIDIA Tegra PWM support"
> depends on ARCH_TEGRA
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 0258a74..026a55b 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -44,6 +44,7 @@ obj-$(CONFIG_PWM_STM32) += pwm-stm32.o
> obj-$(CONFIG_PWM_STM32_LP) += pwm-stm32-lp.o
> obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o
> obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
> +obj-$(CONFIG_PWM_SUN8I_R40) += pwm-sun8i-r40.o
> obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
> obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
> obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
> diff --git a/drivers/pwm/pwm-sun8i-r40.c b/drivers/pwm/pwm-sun8i-r40.c
> new file mode 100644
> index 0000000..3d34285
> --- /dev/null
> +++ b/drivers/pwm/pwm-sun8i-r40.c
> @@ -0,0 +1,394 @@
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/time.h>
> +#include <linux/regmap.h>
> +
> +#define PWM_IRQ_ENABLE_REG 0x0000
> +#define PCIE(ch) BIT(ch)
> +
> +#define PWM_IRQ_STATUS_REG 0x0004
> +#define PIS(ch) BIT(ch)
> +
> +#define CAPTURE_IRQ_ENABLE_REG 0x0010
> +#define CFIE(ch) BIT(ch << 1 + 1)
> +#define CRIE(ch) BIT(ch << 1)
> +
> +#define CAPTURE_IRQ_STATUS_REG 0x0014
> +#define CFIS(ch) BIT(ch << 1 + 1)
> +#define CRIS(ch) BIT(ch << 1)
> +
> +#define CLK_CFG_REG(ch) (0x0020 + (ch >> 1) * 4)
> +#define CLK_SRC BIT(7)
> +#define CLK_SRC_BYPASS_SEC BIT(6)
> +#define CLK_SRC_BYPASS_FIR BIT(5)
> +#define CLK_GATING BIT(4)
> +#define CLK_DIV_M GENMASK(3, 0)
> +
> +#define PWM_DZ_CTR_REG(ch) (0x0030 + (ch >> 1) * 4)
> +#define PWM_DZ_INTV GENMASK(15, 8)
> +#define PWM_DZ_EN BIT(0)
> +
> +#define PWM_ENABLE_REG 0x0040
> +#define PWM_EN(ch) BIT(ch)
> +
> +#define CAPTURE_ENABLE_REG 0x0044
> +#define CAP_EN(ch) BIT(ch)
> +
> +#define PWM_CTR_REG(ch) (0x0060 + ch * 0x20)
> +#define PWM_PERIOD_RDY BIT(11)
> +#define PWM_PUL_START BIT(10)
> +#define PWM_MODE BIT(9)
> +#define PWM_ACT_STA BIT(8)
> +#define PWM_PRESCAL_K GENMASK(7, 0)
> +
> +#define PWM_PERIOD_REG(ch) (0x0064 + ch * 0x20)
> +#define PWM_ENTIRE_CYCLE GENMASK(31, 16)
> +#define PWM_ACT_CYCLE GENMASK(15, 0)
> +
> +#define PWM_CNT_REG(ch) (0x0068 + ch * 0x20)
> +#define PWM_CNT_VAL GENMASK(15, 0)
> +
> +#define CAPTURE_CTR_REG(ch) (0x006c + ch * 0x20)
> +#define CAPTURE_CRLF BIT(2)
> +#define CAPTURE_CFLF BIT(1)
> +#define CAPINV BIT(0)
> +
> +#define CAPTURE_RISE_REG(ch) (0x0070 + ch * 0x20)
> +#define CAPTURE_CRLR GENMASK(15, 0)
> +
> +#define CAPTURE_FALL_REG(ch) (0x0074 + ch * 0x20)
> +#define CAPTURE_CFLR GENMASK(15, 0)
> +
> +struct sun8i_pwm_data {
> + bool has_prescaler_bypass;
> + bool has_rdy;
> + unsigned int npwm;
> +};
> +
> +struct sun8i_pwm_chip {
> + struct pwm_chip chip;
> + struct clk *clk;
> + void __iomem *base;
> + spinlock_t ctrl_lock;
> + const struct sun8i_pwm_data *data;
> + struct regmap *regmap;
> +};
> +
> +static const u16 div_m_table[] = {
> + 1,
> + 2,
> + 4,
> + 8,
> + 16,
> + 32,
> + 64,
> + 128,
> + 256
> +};
> +
> +static inline struct sun8i_pwm_chip *to_sun8i_pwm_chip(struct pwm_chip *chip)
> +{
> + return container_of(chip, struct sun8i_pwm_chip, chip);
> +}
> +
> +static u32 sun8i_pwm_read(struct sun8i_pwm_chip *sun8i_pwm,
> + unsigned long offset)
> +{
> + u32 val;
> +
> + regmap_read(sun8i_pwm->regmap, offset, &val);
> +
> + return val;
> +}
> +
> +static inline void sun8i_pwm_set_bit(struct sun8i_pwm_chip *sun8i_pwm,
> + unsigned long reg, u32 bit)
> +{
> + regmap_update_bits(sun8i_pwm->regmap, reg, bit, bit);
> +}
> +
> +static inline void sun8i_pwm_clear_bit(struct sun8i_pwm_chip *sun8i_pwm,
> + unsigned long reg, u32 bit)
> +{
> + regmap_update_bits(sun8i_pwm->regmap, reg, bit, 0);
> +}
> +
> +static inline void sun8i_pwm_set_value(struct sun8i_pwm_chip *sun8i_pwm,
> + unsigned long reg, u32 mask, u32 val)
> +{
> + regmap_update_bits(sun8i_pwm->regmap, reg, mask, val);
> +}
> +
> +static void sun8i_pwm_set_polarity(struct sun8i_pwm_chip *chip, u32 ch,
> + enum pwm_polarity polarity)
> +{
> + if (polarity == PWM_POLARITY_NORMAL)
> + sun8i_pwm_set_bit(chip, PWM_CTR_REG(ch), PWM_ACT_STA);
> + else
> + sun8i_pwm_clear_bit(chip, PWM_CTR_REG(ch), PWM_ACT_STA);
> +}
> +
> +static int sun8i_pwm_config(struct sun8i_pwm_chip *sun8i_pwm, u8 ch,
> + struct pwm_state *state)
> +{
> + u64 clk_rate, clk_div, val;
> + u16 prescaler = 0;
> + u8 id = 0;
> +
> + clk_rate = clk_get_rate(sun8i_pwm->clk);
> +
> + if (clk_rate == 24000000)
> + sun8i_pwm_clear_bit(sun8i_pwm, CLK_CFG_REG(ch), CLK_SRC);
> + else
> + sun8i_pwm_set_bit(sun8i_pwm, CLK_CFG_REG(ch), CLK_SRC);
> +
> + if (sun8i_pwm->data->has_prescaler_bypass) {
> + /* pwm output bypass */
> + if (ch % 2)
> + sun8i_pwm_set_bit(sun8i_pwm, CLK_CFG_REG(ch),
> + CLK_SRC_BYPASS_FIR);
> + else
> + sun8i_pwm_set_bit(sun8i_pwm, CLK_CFG_REG(ch),
> + CLK_SRC_BYPASS_SEC);
> + return 0;
> + }
> +
> + val = state->period * clk_rate;
> + do_div(val, NSEC_PER_SEC);
> + if (val < 1) {
> + dev_err(sun8i_pwm->chip.dev,
> + "period expects a larger value\n");
> + return -EINVAL;
> + }
> +
> + /* calculate and set prescalar, div table, pwn entrie cycle */
> + clk_div = val;
> +
> + while (clk_div > 65535) {
> + prescaler++;
> + clk_div = val;
> + do_div(clk_div, prescaler + 1);
> + do_div(clk_div, div_m_table[id]);
> +
> + if (prescaler == 255) {
> + prescaler = 0;
> + id++;
> + if (id == 9)
> + return -EINVAL;
> + }
> + }
> +
> + sun8i_pwm_set_value(sun8i_pwm, PWM_PERIOD_REG(ch),
> + PWM_ENTIRE_CYCLE, clk_div << 16);
> + sun8i_pwm_set_value(sun8i_pwm, PWM_CTR_REG(ch),
> + PWM_PRESCAL_K, prescaler << 0);
> + sun8i_pwm_set_value(sun8i_pwm, CLK_CFG_REG(ch),
> + CLK_DIV_M, id << 0);
> +
> + /* set duty cycle */
> + val = (prescaler + 1) * div_m_table[id] * clk_div;
> + val = state->period;
> + do_div(val, clk_div);
> + clk_div = state->duty_cycle;
> + do_div(clk_div, val);
> +
> + sun8i_pwm_set_value(sun8i_pwm, PWM_PERIOD_REG(ch),
> + PWM_ACT_CYCLE, clk_div << 0);
> +
> + return 0;
> +}
> +
> +static int sun8i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + int ret;
> + struct sun8i_pwm_chip *sun8i_pwm = to_sun8i_pwm_chip(chip);
> + struct pwm_state cstate;
> +
> + pwm_get_state(pwm, &cstate);
> + if (!cstate.enabled) {
> + ret = clk_prepare_enable(sun8i_pwm->clk);
You call clk_prepare_enable() here, under !cstate.enabled condition.
> + if (ret) {
> + dev_err(chip->dev, "failed to enable PWM clock\n");
> + return ret;
> + }
> + }
> +
> + spin_lock(&sun8i_pwm->ctrl_lock);
> +
> + if ((cstate.period != state->period) ||
> + (cstate.duty_cycle != state->duty_cycle)) {
> + ret = sun8i_pwm_config(sun8i_pwm, pwm->hwpwm, state);
> + if (ret) > + clk_disable_unprepare(sun8i_pwm->clk);
You need to call clk_disable_unprepare() only if !cstate.enabled:
if (!cstate.enabled)
clk_disable_unprepare();
> + spin_unlock(&sun8i_pwm->ctrl_lock);
> + dev_err(chip->dev, "failed to config PWM\n");
> + return ret;
> + }
> + }
> +
> + if (state->polarity != cstate.polarity)
> + sun8i_pwm_set_polarity(sun8i_pwm, pwm->hwpwm, state->polarity);
> +
> + if (state->enabled) {
> + sun8i_pwm_set_bit(sun8i_pwm,
> + CLK_CFG_REG(pwm->hwpwm), CLK_GATING);
> +
> + sun8i_pwm_set_bit(sun8i_pwm,
> + PWM_ENABLE_REG, PWM_EN(pwm->hwpwm));
> + } else {
> + sun8i_pwm_clear_bit(sun8i_pwm,
> + CLK_CFG_REG(pwm->hwpwm), CLK_GATING);
> +
> + sun8i_pwm_clear_bit(sun8i_pwm,
> + PWM_ENABLE_REG, PWM_EN(pwm->hwpwm));
> + }
> +
> + spin_unlock(&sun8i_pwm->ctrl_lock);
> +
> + return 0;
> +}
> +
> +static void sun8i_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct sun8i_pwm_chip *sun8i_pwm = to_sun8i_pwm_chip(chip);
> + u64 clk_rate, tmp;
> + u32 val;
> + u16 clk_div, act_cycle;
> + u8 prescal, id;
> +
> + clk_rate = clk_get_rate(sun8i_pwm->clk);
> +
> + val = sun8i_pwm_read(sun8i_pwm, PWM_CTR_REG(pwm->hwpwm));
> + if (PWM_ACT_STA & val)
> + state->polarity = PWM_POLARITY_NORMAL;
> + else
> + state->polarity = PWM_POLARITY_INVERSED;
> +
> + prescal = PWM_PRESCAL_K & val;
> +
> + val = sun8i_pwm_read(sun8i_pwm, PWM_ENABLE_REG);
> + if (PWM_EN(pwm->hwpwm) & val)
> + state->enabled = true;
> + else
> + state->enabled = false;
> +
> + val = sun8i_pwm_read(sun8i_pwm, PWM_PERIOD_REG(pwm->hwpwm));
> + act_cycle = PWM_ACT_CYCLE & val;
> + clk_div = val >> 16;
> +
> + val = sun8i_pwm_read(sun8i_pwm, CLK_CFG_REG(pwm->hwpwm));
> + id = CLK_DIV_M & val;
> +
> + tmp = act_cycle * prescal * div_m_table[id] * NSEC_PER_SEC;
> + state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
> + tmp = clk_div * prescal * div_m_table[id] * NSEC_PER_SEC;
> + state->period = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
> +}
> +
> +static const struct regmap_config sun8i_pwm_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> + .max_register = CAPTURE_FALL_REG(7),
> +};
> +
> +static const struct pwm_ops sun8i_pwm_ops = {
> + .apply = sun8i_pwm_apply,
> + .get_state = sun8i_pwm_get_state,
> + .owner = THIS_MODULE,
> +};
> +
> +static const struct sun8i_pwm_data sun8i_pwm_data_r40 = {
> + .has_prescaler_bypass = false,
> + .has_rdy = true,
> + .npwm = 8,
> +};
> +
> +static const struct of_device_id sun8i_pwm_dt_ids[] = {
> + {
> + .compatible = "allwinner,sun8i-r40-pwm",
> + .data = &sun8i_pwm_data_r40,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, sun8i_pwm_dt_ids);
> +
> +static int sun8i_pwm_probe(struct platform_device *pdev)
> +{
> + struct sun8i_pwm_chip *pwm;
> + struct resource *res;
> + int ret;
> + const struct of_device_id *match;
> +
> + match = of_match_device(sun8i_pwm_dt_ids, &pdev->dev);
check for !match
> +
> + pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
> + if (!pwm)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + pwm->base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(pwm->base))
> + return PTR_ERR(pwm->base);
> +
> + pwm->regmap = devm_regmap_init_mmio(&pdev->dev, pwm->base,
> + &sun8i_pwm_regmap_config);
Check for IS_ERR(pwm->regmap)
> +
> + pwm->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(pwm->clk))
> + return PTR_ERR(pwm->clk);
> +
> + pwm->data = match->data;
> + pwm->chip.dev = &pdev->dev;
> + pwm->chip.ops = &sun8i_pwm_ops;
> + pwm->chip.base = -1;
> + pwm->chip.npwm = pwm->data->npwm;
> + pwm->chip.of_xlate = of_pwm_xlate_with_flags;
> + pwm->chip.of_pwm_n_cells = 3;
> +
> + spin_lock_init(&pwm->ctrl_lock);
> +
> + ret = pwmchip_add(&pwm->chip);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, pwm);
> +
> + return 0;
> +}
> +
> +static int sun8i_pwm_remove(struct platform_device *pdev)
> +{
> + struct sun8i_pwm_chip *pwm = platform_get_drvdata(pdev);
> +
> + return pwmchip_remove(&pwm->chip);
> +}
> +
> +static struct platform_driver sun8i_pwm_driver = {
> + .driver = {
> + .name = "sun8i-r40-pwm",
> + .of_match_table = sun8i_pwm_dt_ids,
> + },
> + .probe = sun8i_pwm_probe,
> + .remove = sun8i_pwm_remove,
> +};
> +module_platform_driver(sun8i_pwm_driver);
> +
> +MODULE_ALIAS("platform:sun8i-r40-pwm");
> +MODULE_AUTHOR("Hao Zhang <hao5781286@gmail.com>");
> +MODULE_DESCRIPTION("Allwinner sun8i-r40 PWM driver");
> +MODULE_LICENSE("GPL v2");
>
^ permalink raw reply
* [PATCH 2/2] kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
From: Andrey Konovalov @ 2018-01-11 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1515684162.git.andreyknvl@google.com>
Right now the fact that KASAN uses a single shadow byte for 8 bytes of
memory is scattered all over the code.
This change defines KASAN_SHADOW_SCALE_SHIFT early in asm include files
and makes use of this constant where necessary.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
arch/arm64/include/asm/kasan.h | 3 ++-
arch/arm64/include/asm/memory.h | 3 ++-
arch/arm64/mm/kasan_init.c | 3 ++-
arch/x86/include/asm/kasan.h | 8 ++++++--
include/linux/kasan.h | 2 --
5 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
index e266f80e45b7..811643fe7640 100644
--- a/arch/arm64/include/asm/kasan.h
+++ b/arch/arm64/include/asm/kasan.h
@@ -27,7 +27,8 @@
* should satisfy the following equation:
* KASAN_SHADOW_OFFSET = KASAN_SHADOW_END - (1ULL << 61)
*/
-#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << (64 - 3)))
+#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << \
+ (64 - KASAN_SHADOW_SCALE_SHIFT)))
void kasan_init(void);
void kasan_copy_shadow(pgd_t *pgdir);
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index d4bae7d6e0d8..50fa96a49792 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -85,7 +85,8 @@
* stack size when KASAN is in use.
*/
#ifdef CONFIG_KASAN
-#define KASAN_SHADOW_SIZE (UL(1) << (VA_BITS - 3))
+#define KASAN_SHADOW_SCALE_SHIFT 3
+#define KASAN_SHADOW_SIZE (UL(1) << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
#define KASAN_THREAD_SHIFT 1
#else
#define KASAN_SHADOW_SIZE (0)
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index acba49fb5aac..6e02e6fb4c7b 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -135,7 +135,8 @@ static void __init kasan_pgd_populate(unsigned long addr, unsigned long end,
/* The early shadow maps everything to a single page of zeroes */
asmlinkage void __init kasan_early_init(void)
{
- BUILD_BUG_ON(KASAN_SHADOW_OFFSET != KASAN_SHADOW_END - (1UL << 61));
+ BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=
+ KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT)));
BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_START, PGDIR_SIZE));
BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE));
kasan_pgd_populate(KASAN_SHADOW_START, KASAN_SHADOW_END, NUMA_NO_NODE,
diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
index b577dd0916aa..737b7ea9bea3 100644
--- a/arch/x86/include/asm/kasan.h
+++ b/arch/x86/include/asm/kasan.h
@@ -4,6 +4,7 @@
#include <linux/const.h>
#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
+#define KASAN_SHADOW_SCALE_SHIFT 3
/*
* Compiler uses shadow offset assuming that addresses start
@@ -12,12 +13,15 @@
* 'kernel address space start' >> KASAN_SHADOW_SCALE_SHIFT
*/
#define KASAN_SHADOW_START (KASAN_SHADOW_OFFSET + \
- ((-1UL << __VIRTUAL_MASK_SHIFT) >> 3))
+ ((-1UL << __VIRTUAL_MASK_SHIFT) >> \
+ KASAN_SHADOW_SCALE_SHIFT))
/*
* 47 bits for kernel address -> (47 - 3) bits for shadow
* 56 bits for kernel address -> (56 - 3) bits for shadow
*/
-#define KASAN_SHADOW_END (KASAN_SHADOW_START + (1ULL << (__VIRTUAL_MASK_SHIFT - 3)))
+#define KASAN_SHADOW_END (KASAN_SHADOW_START + \
+ (1ULL << (__VIRTUAL_MASK_SHIFT - \
+ KASAN_SHADOW_SCALE_SHIFT)))
#ifndef __ASSEMBLY__
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index e3eb834c9a35..e9eaa964473a 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -11,8 +11,6 @@ struct task_struct;
#ifdef CONFIG_KASAN
-#define KASAN_SHADOW_SCALE_SHIFT 3
-
#include <asm/kasan.h>
#include <asm/pgtable.h>
--
2.16.0.rc1.238.g530d649a79-goog
^ permalink raw reply related
* [PATCH 1/2] kasan: fix prototype author email address
From: Andrey Konovalov @ 2018-01-11 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1515684162.git.andreyknvl@google.com>
Use the new one.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
mm/kasan/kasan.c | 2 +-
mm/kasan/report.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 405bba487df5..cb4065f31f7f 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -5,7 +5,7 @@
* Author: Andrey Ryabinin <ryabinin.a.a@gmail.com>
*
* Some code borrowed from https://github.com/xairy/kasan-prototype by
- * Andrey Konovalov <adech.fo@gmail.com>
+ * Andrey Konovalov <andreyknvl@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 410c8235e671..eee796a005ac 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -5,7 +5,7 @@
* Author: Andrey Ryabinin <ryabinin.a.a@gmail.com>
*
* Some code borrowed from https://github.com/xairy/kasan-prototype by
- * Andrey Konovalov <adech.fo@gmail.com>
+ * Andrey Konovalov <andreyknvl@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
--
2.16.0.rc1.238.g530d649a79-goog
^ permalink raw reply related
* [PATCH 0/2] kasan: a few cleanups
From: Andrey Konovalov @ 2018-01-11 15:29 UTC (permalink / raw)
To: linux-arm-kernel
Clean up usage of KASAN_SHADOW_SCALE_SHIFT and fix prototype author email
address.
Andrey Konovalov (2):
kasan: fix prototype author email address
kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
arch/arm64/include/asm/kasan.h | 3 ++-
arch/arm64/include/asm/memory.h | 3 ++-
arch/arm64/mm/kasan_init.c | 3 ++-
arch/x86/include/asm/kasan.h | 8 ++++++--
include/linux/kasan.h | 2 --
mm/kasan/kasan.c | 2 +-
mm/kasan/report.c | 2 +-
7 files changed, 14 insertions(+), 9 deletions(-)
--
2.16.0.rc1.238.g530d649a79-goog
^ permalink raw reply
* [PATCH] phy: work around 'phys' references to usb-phy devices
From: Arnd Bergmann @ 2018-01-11 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6dd37865-9c71-29f9-16b4-26e51e6b1c70@ti.com>
On Thu, Jan 11, 2018 at 2:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote:
>> On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote:
>>>> Stefan Wahren reports a problem with a warning fix that was merged
>>>> ---
>>>> This obviously needs to be tested, I wrote this up as a reply to
>>>> Stefan's bug report. I'm fairly sure that I covered all usb-phy
>>>> driver strings here. My goal is to have a fix merged into 4.15
>>>> rather than reverting all the DT fixes.
>>>
>>> Shouldn't the fix be in phy consumer drivers to not return error if it's able
>>> to find the phy either using usb-phy or generic phy?
>>
>> Stefan has posted a patch to that effect now, but I fear that might be
>> a little fragile, in particular this short before the release with the
>> regression
>> in place.
>>
>> The main problem is that we'd have to change the generic
>> usb_add_hcd() function in addition to dwc2 and dwc3 to ignore
>> -EPROBE_DEFER from phy_get() whenever usb_get_phy_dev()
>> has already succeeded.
>>
>> If there is any HCD that relies on usb_add_hcd() to get both the
>> usb_phy and the phy structures, and it may need to defer probing
>> when the latter one isn't ready yet, that fix would break another
>> driver.
>
> hmm.. IMO the better thing right now would be to revert the dt patch which adds
> #phy-cells.
> We have to see if there are better fixes in order to add #phy-cells warning fix
> in stable tree.
Let's see which patches that would be, I think this is the full list of
nodes that got an extra #phy-cells:
c22fe696157d ARM: dts: Fix dm814x missing phy-cells property
f0e11ff8ff65 ARM: dts: am33xx: Add missing #phy-cells to ti,am335x-usb-phy
c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
plus a couple in linux-next:
d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
It's a lot of patches to revert, and I guess it would get us back to hundreds
of warnings in an allmodconfig build, so I'd first try to come up with
ways to prove that at least some of them can stay.
Almost all the warnings are about "usb-nop-xceiv" phys, the only exceptions
I could find are the OMAP ones (the first two patches), which use
"ti,am335x-usb-phy" and are referenced from a "ti,musb-am33xx". That
particular driver is not affected by the bug, so we can leave that in.
To deal with all the "usb-nop-xceiv" references including the one that
Stefan reported, we could use a much simpler version of my earlier
patch, do you think this is any better?
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b4964b067aec..f056d8fb3921 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node
*np, int index)
if (ret)
return ERR_PTR(-ENODEV);
+ /* This phy type handled by the usb-phy subsystem for now */
+ if (of_device_is_compatible("usb-nop-xceiv"))
+ return ERR_PTR(-ENODEV);
+
mutex_lock(&phy_provider_mutex);
phy_provider = of_phy_provider_lookup(args.np);
if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
^ permalink raw reply related
* [PATCH v5 03/20] firmware: arm_scmi: add basic driver infrastructure for SCMI
From: Sudeep Holla @ 2018-01-11 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514904162-11201-4-git-send-email-sudeep.holla@arm.com>
On 02/01/18 14:42, Sudeep Holla wrote:
> The SCMI is intended to allow OSPM to manage various functions that are
> provided by the hardware platform it is running on, including power and
> performance functions. SCMI provides two levels of abstraction, protocols
> and transports. Protocols define individual groups of system control and
> management messages. A protocol specification describes the messages
> that it supports. Transports describe the method by which protocol
> messages are communicated between agents and the platform.
>
> This patch adds basic infrastructure to manage the message allocation,
> initialisation, packing/unpacking and shared memory management.
>
Any chance you could review patches 3-14 ? All the drivers (15-20) are
already acked by the maintainer. I know it's late for v4.16, I want it
to be ready for v4.17 ASAP. It's on the list without much progress for
few months now :(, hence the push. Sorry for the nag.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 12/25] arm: socfpga: dts: Remove leading 0x and 0s from bindings notation
From: Dinh Nguyen @ 2018-01-11 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215111620.20379-12-malat@debian.org>
On 12/15/2017 05:16 AM, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/arm/boot/dts/socfpga.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
Dinh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox