* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Pavel Machek @ 2016-10-19 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018224259.jrwbaal27irzjqyo@earth>
Hi!
[Ccing lists.]
> Can you push the patch, which gets further than negotiation into
> some git branch available to me? I tried to apply your patch to
> my code, but it did not work for me.
Ok, I've pushed the branch to kernel.org:
git push git at gitolite.kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900.git bt-2-v4.9:bt-2-v4.9
In retrospect, I did make some changes to dts, they may be neccessary,
too.
If it still does not work, please try with my .config. I'm using
modules here, using this script:
pavel at n900:/my/modules$ cat run2
echo removing...
sudo killall a.out
rmmod nokia_h4p
#rmmod omap_serial
#rmmod serial_core
rmmod hci_uart.ko
#rmmod bcm2048.ko
echo installing...
insmod serial_core.ko
insmod omap-serial.ko
insmod bcm2048.ko
insmod hci_uart.ko
ls -al /dev/ttyO1
sleep 1
stty crtscts < /dev/ttyO1
/my/tui/ofone/a.out &
For the record, dmesg says:
Good luck,
Pavel
[ 30.694274] g_ether gadget: notify connect true
[ 30.714080] g_ether gadget: notify speed 425984000
[ 127.719146] ssi-protocol ssi-protocol: WAKELINES TEST OK
[ 218.542694] of_get_named_gpiod_flags: can't parse 'rts-gpio'
property of node '/ocp at 68000000/serial at 4806c000[0]'
[ 218.546264] 4806c000.serial: ttyO1 at MMIO 0x4806c000 (irq = 89,
base_baud = 3000000) is a OMAP UART1
[ 218.574157] of_get_named_gpiod_flags: can't parse 'rts-gpio'
property of node '/ocp at 68000000/serial at 49020000[0]'
[ 218.574340] 49020000.serial: ttyO2 at MMIO 0x49020000 (irq = 90,
base_baud = 3000000) is a OMAP UART2
[ 218.650115] bcm2048: probe
[ 218.650177] bcm2048 4806c000.serial:bluetooth: GPIO lookup for
consumer reset
[ 218.650177] bcm2048 4806c000.serial:bluetooth: using device tree
for GPIO lookup
[ 218.650360] of_get_named_gpiod_flags: parsed 'reset-gpios' property
of node '/ocp at 68000000/serial at 4806c000/bluetooth[0]' - status (0)
[ 218.650390] bcm2048 4806c000.serial:bluetooth: GPIO lookup for
consumer host-wakeup
[ 218.650421] bcm2048 4806c000.serial:bluetooth: using device tree
for GPIO lookup
[ 218.650482] of_get_named_gpiod_flags: parsed 'host-wakeup-gpios'
property of node '/ocp at 68000000/serial at 4806c000/bluetooth[0]' - status
(0)
[ 218.650512] bcm2048 4806c000.serial:bluetooth: GPIO lookup for
consumer bluetooth-wakeup
[ 218.650543] bcm2048 4806c000.serial:bluetooth: using device tree
for GPIO lookup
[ 218.650604] of_get_named_gpiod_flags: parsed
'bluetooth-wakeup-gpios' property of node
'/ocp at 68000000/serial@4806c000/bluetooth[0]' - status (0)
[ 218.650817] bcm2048 4806c000.serial:bluetooth: parent uart: ttyO1
[ 218.650817] bcm2048 4806c000.serial:bluetooth: sysclk speed: 38400
kHz
[ 218.650848] bcm2048 4806c000.serial:bluetooth: probe: 0
[ 218.774139] Bluetooth: HCI UART driver ver 2.3
[ 218.774169] Bluetooth: HCI UART protocol H4 registered
[ 218.774169] Bluetooth: HCI UART protocol H4+ registered
[ 218.774169] Bluetooth: HCI UART protocol BCSP registered
[ 218.774200] Bluetooth: HCI UART protocol LL registered
[ 218.774200] Bluetooth: HCI UART protocol ATH3K registered
[ 218.774200] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 219.904876] tty ttyO1: Nokia H4+ protocol initialized with
4806c000.serial:bluetooth!
[ 219.921112] tty ttyO1: Nokia H4+ protocol setup...
[ 219.921142] h4p_reset: reset
[ 219.921142] hci_uart_init_tty
[ 219.983520] h4p_reset: flush
[ 219.983551] h4p_reset: speed
[ 219.983581] tty ttyO1: setting speed to 120000 baud
[ 219.983673] h4p_reset: safety
[ 219.986480] tty ttyO1: wakeup received: 0 -> 1
[ 220.013488] tty ttyO1: wait for cts... received!
[ 220.013519] h4p_reset: flow
[ 220.013549] tty ttyO1: Sending negotiation...
[ 220.013580] tty ttyO1: gpio state: reset=1 wakehost=1 wakebt=1
[ 220.013610] enqueue: hu c304cc80 skb cd4da000
[ 220.017425] tty ttyO1: H4P negotiation:
[ 220.017456] tty ttyO1: baudrate = 416
[ 220.017486] tty ttyO1: system clock = 38400
[ 220.017486] tty ttyO1: manufacturer id = 4
[ 220.017486] tty ttyO1: version id = 11
[ 220.017578] tty ttyO1: setting speed to 921600 baud
[ 220.043457] tty ttyO1: wait for cts... received!
[ 220.043548] tty ttyO1: Negotiation successful...
[ 220.043579] tty ttyO1: Sending alive packet...
[ 220.043579] enqueue: hu c304cc80 skb cd4dacc0
[ 220.043853] tty ttyO1: Received alive packet!
[ 220.047851] tty ttyO1: FW: Skip negotion packet!
[ 220.047882] tty ttyO1: FW: Skip alive packet!
[ 220.052185] enqueue: hu c304cc80 skb cd4da480
[ 220.055175] enqueue: hu c304cc80 skb cd4dae40
[ 220.058776] enqueue: hu c304cc80 skb cd4da6c0
[ 220.058898] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.058929] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.064605] enqueue: hu c304cc80 skb cd4daf00
[ 220.068389] enqueue: hu c304cc80 skb cd4da0c0
[ 220.068542] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.068542] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.071960] enqueue: hu c304cc80 skb cd4da840
[ 220.072082] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.072082] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.075592] enqueue: hu c304cc80 skb cd4da180
[ 220.079803] enqueue: hu c304cc80 skb cd479cc0
[ 220.084381] enqueue: hu c304cc80 skb cd479180
[ 220.087982] enqueue: hu c304cc80 skb cd4793c0
[ 220.088104] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.088134] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.091522] enqueue: hu c304cc80 skb cd479e40
[ 220.095336] enqueue: hu c304cc80 skb cd479540
[ 220.098876] enqueue: hu c304cc80 skb cd479000
[ 220.102386] enqueue: hu c304cc80 skb cd479600
[ 220.102478] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.102508] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.105987] enqueue: hu c304cc80 skb cd479780
[ 220.109527] enqueue: hu c304cc80 skb cd450cc0
[ 220.109619] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.109649] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.113098] enqueue: hu c304cc80 skb cd484600
[ 220.113220] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.113250] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.116760] enqueue: hu c304cc80 skb cd4a9b40
[ 220.120300] enqueue: hu c304cc80 skb cd77c840
[ 220.124786] enqueue: hu c304cc80 skb cd4f7900
[ 220.128387] enqueue: hu c304cc80 skb c4fb2180
[ 220.131896] enqueue: hu c304cc80 skb c4fb23c0
[ 220.135498] enqueue: hu c304cc80 skb c4fb2cc0
[ 220.139007] enqueue: hu c304cc80 skb c4fb2000
[ 220.142486] enqueue: hu c304cc80 skb cd44fcc0
[ 220.146118] enqueue: hu c304cc80 skb cd4b60c0
[ 220.149627] enqueue: hu c304cc80 skb cf1986c0
[ 220.153106] enqueue: hu c304cc80 skb cf198480
[ 220.156738] enqueue: hu c304cc80 skb cf1980c0
[ 220.160278] enqueue: hu c304cc80 skb cf198240
[ 220.164733] enqueue: hu c304cc80 skb cd49f780
[ 220.168365] enqueue: hu c304cc80 skb cd4daf00
[ 220.171844] enqueue: hu c304cc80 skb cd4da6c0
[ 220.175445] enqueue: hu c304cc80 skb cd4dab40
[ 220.175567] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.175567] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.178955] enqueue: hu c304cc80 skb cd479780
[ 220.182434] enqueue: hu c304cc80 skb cd479540
[ 220.182525] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.182556] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.186035] enqueue: hu c304cc80 skb cd4793c0
[ 220.188140] enqueue: hu c304cc80 skb cd479b40
[ 220.188537] enqueue: hu c304cc80 skb cd484600
[ 220.236480] enqueue: hu c304cc80 skb cd4a9f00
[ 220.237701] enqueue: hu c304cc80 skb cd4f7900
[ 220.238830] enqueue: hu c304cc80 skb c4fb23c0
[ 220.239959] enqueue: hu c304cc80 skb c4fb2b40
[ 220.241119] enqueue: hu c304cc80 skb c3107000
[ 220.242187] enqueue: hu c304cc80 skb cd724240
[ 220.243286] enqueue: hu c304cc80 skb cf198540
[ 220.244781] enqueue: hu c304cc80 skb cf198540
[ 220.245758] enqueue: hu c304cc80 skb cd49f780
[ 220.246612] enqueue: hu c304cc80 skb cd4daf00
[ 220.247436] enqueue: hu c304cc80 skb cd479540
[ 220.248535] tty ttyO1: Sending radio packet...
[ 220.248565] enqueue: hu c304cc80 skb cd479cc0
[ 220.248596] tty ttyO1: Radio packet sent
[ 220.249328] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.272949] tty ttyO1: wakeup received: 1 -> 0
[ 221.283477] tty ttyO1: radio packet timeout!
[ 221.283630] enqueue: hu c304cc80 skb cd4a9b40
[ 223.363372] Bluetooth: hci0 command 0xfc18 tx timeout
pavel at n900:~$
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/4903439f/attachment-0001.sig>
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Michal Hocko @ 2016-10-19 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019090646.GA24243@lucifer>
On Wed 19-10-16 10:06:46, Lorenzo Stoakes wrote:
> On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote:
> > yes this is the desirable and expected behavior.
> >
> > > wonder if this is desirable behaviour or whether this ought to be limited to
> > > ptrace system calls. Regardless, by making the flag more visible it makes it
> > > easier to see that this is happening.
> >
> > mem_open already enforces PTRACE_MODE_ATTACH
>
> Ah I missed this, that makes a lot of sense, thanks!
>
> I still wonder whether other invocations of access_remote_vm() in fs/proc/base.c
> (the principle caller of this function) need FOLL_FORCE, for example the various
> calls that simply read data from other processes, so I think the point stands
> about keeping this explicit.
I do agree. Making them explicit will help to clean them up later,
should there be a need.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v2] hwrng: meson: Fix module autoload for OF registration
From: Neil Armstrong @ 2016-10-19 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476733877-20275-1-git-send-email-javier@osg.samsung.com>
On 10/17/2016 09:51 PM, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
>
> After this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
> alias: of:N*T*Camlogic,meson-rngC*
> alias: of:N*T*Camlogic,meson-rng
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> Changes in v2:
> - Remove unrelated changes added by mistake. Suggested by Jason Gunthorpe.
>
> drivers/char/hw_random/meson-rng.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
> index 58bef39f7286..51864a509be7 100644
> --- a/drivers/char/hw_random/meson-rng.c
> +++ b/drivers/char/hw_random/meson-rng.c
> @@ -110,6 +110,7 @@ static const struct of_device_id meson_rng_of_match[] = {
> { .compatible = "amlogic,meson-rng", },
> {},
> };
> +MODULE_DEVICE_TABLE(of, meson_rng_of_match);
>
> static struct platform_driver meson_rng_driver = {
> .probe = meson_rng_probe,
>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Will Deacon @ 2016-10-19 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_A1XOL=yST_isyvMZL=9wUcuiFXdfmOqw7PO5te24Ktw@mail.gmail.com>
On Wed, Oct 19, 2016 at 09:49:46AM +0100, Ard Biesheuvel wrote:
> On 19 October 2016 at 09:46, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
> >> I was planning merging these for 4.10. But I'm fine with them
> >> going through the arm tree. Let me know what you guys want to
> >> do.
> >
> > I assumed you'd take them through crypto, as per usual, so I didn't
> > queue anything in the arm64 tree.
> >
> > Ard -- were you planning to get these in for 4.9?
> >
>
> These are arguably bug fixes, but I spotted them by accident, they
> weren't reported to me or anything. But it seems strange to add a cc
> stable and then hold off until the next merge window.
>
> In any case, I don't care deeply either way, as long as they get
> merged in the end. I think it makes sense to keep them together (arm64
> + ARM), so Herbert's tree is a more natural route for them to take. I
> will leave it up to Herbert whether they are sent onward as fixes or
> as part of v4.10
Sounds good to me.
Will
^ permalink raw reply
* [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Michal Hocko @ 2016-10-19 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019085815.GA22239@lucifer>
On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> > I am wondering whether we can go further. E.g. it is not really clear to
> > me whether we need an explicit FOLL_REMOTE when we can in fact check
> > mm != current->mm and imply that. Maybe there are some contexts which
> > wouldn't work, I haven't checked.
>
> This flag is set even when /proc/self/mem is used. I've not looked deeply into
> this flag but perhaps accessing your own memory this way can be considered
> 'remote' since you're not accessing it directly. On the other hand, perhaps this
> is just mistaken in this case?
My understanding of the flag is quite limited as well. All I know it is
related to protection keys and it is needed to bypass protection check.
See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
enforce PKEY permissions on remote mm access").
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Lorenzo Stoakes @ 2016-10-19 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019085204.GD7517@dhcp22.suse.cz>
On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote:
> yes this is the desirable and expected behavior.
>
> > wonder if this is desirable behaviour or whether this ought to be limited to
> > ptrace system calls. Regardless, by making the flag more visible it makes it
> > easier to see that this is happening.
>
> mem_open already enforces PTRACE_MODE_ATTACH
Ah I missed this, that makes a lot of sense, thanks!
I still wonder whether other invocations of access_remote_vm() in fs/proc/base.c
(the principle caller of this function) need FOLL_FORCE, for example the various
calls that simply read data from other processes, so I think the point stands
about keeping this explicit.
^ permalink raw reply
* [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Lorenzo Stoakes @ 2016-10-19 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018153050.GC13117@dhcp22.suse.cz>
On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> I am wondering whether we can go further. E.g. it is not really clear to
> me whether we need an explicit FOLL_REMOTE when we can in fact check
> mm != current->mm and imply that. Maybe there are some contexts which
> wouldn't work, I haven't checked.
This flag is set even when /proc/self/mem is used. I've not looked deeply into
this flag but perhaps accessing your own memory this way can be considered
'remote' since you're not accessing it directly. On the other hand, perhaps this
is just mistaken in this case?
> I guess there is more work in that area and I do not want to impose all
> that work on you, but I couldn't resist once I saw you playing in that
> area ;) Definitely a good start!
Thanks, I am more than happy to go as far down this rabbit hole as is helpful,
no imposition at all :)
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Laurent Pinchart @ 2016-10-19 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJXwZ8pQ58OgV4w88yNuG1Fd8++1yP-Frd2QJFO9uJJueQ@mail.gmail.com>
Hi Bartosz,
On Wednesday 19 Oct 2016 10:26:57 Bartosz Golaszewski wrote:
> 2016-10-18 22:49 GMT+02:00 Laurent Pinchart:
> > On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote:
> >> Create the driver for the da8xx System Configuration and implement
> >> support for writing to the three Master Priority registers.
> >>
> >> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> [snip]
>
> >> +
> >> +Documentation:
> >> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: "ti,da850-syscfg"
> >
> > Don't you need a reg property ?
>
> Yes, Kevin already pointed that out. I'll add it in v2. Same for [1/3].
>
> >> +Optional properties:
> >> +
> >> +The below properties are used to specify the priority of master
> >> peripherals.
> >> +They must be between 0-7 where 0 is the highest priority and 7 is the
> >> lowest.
> >> +
> >> +- ti,pri-arm-i: ARM_I port priority.
> >> +
> >> +- ti,pri-arm-d: ARM_D port priority.
> >> +
> >> +- ti,pri-upp: uPP port priority.
> >> +
> >> +- ti,pri-sata: SATA port priority.
> >> +
> >> +- ti,pri-pru0: PRU0 port priority.
> >> +
> >> +- ti,pri-pru1: PRU1 port priority.
> >> +
> >> +- ti,pri-edma30tc0: EDMA3_0_TC0 port priority.
> >> +
> >> +- ti,pri-edma30tc1: EDMA3_0_TC1 port priority.
> >> +
> >> +- ti,pri-edma31tc0: EDMA3_1_TC0 port priority.
> >> +
> >> +- ti,pri-vpif-dma-0: VPIF DMA0 port priority.
> >> +
> >> +- ti,pri-vpif-dma-1: VPIF DMA1 port priority.
> >> +
> >> +- ti,pri-emac: EMAC port priority.
> >> +
> >> +- ti,pri-usb0cfg: USB0 CFG port priority.
> >> +
> >> +- ti,pri-usb0cdma: USB0 CDMA port priority.
> >> +
> >> +- ti,pri-uhpi: HPI port priority.
> >> +
> >> +- ti,pri-usb1: USB1 port priority.
> >> +
> >> +- ti,pri-lcdc: LCDC port priority.
> >
> > I'm afraid this looks more like system configuration than hardware
> > description to me.
>
> While you're certainly right, this approach is already implemented in
> several other memory and bus drivers and it was also suggested by
> Sekhar in one of the tilcdc rev1 threads. There's also no real
> alternative that I know of.
The fact that other drivers get it wrong is no excuse for copying them :-)
> > There was a BoF session about how to support this kind of performance
> > knobs at ELCE last week:
> > https://openiotelceurope2016.sched.org/event/7rss/bof-linux-device-perfor
> > mance-framework-michael-turquette-baylibre :-)
>
> I know, I was there. ;)
That's why I mentioned it :-)
> Unfortunately it was just a discussion about potential approaches -
> there's no code yet.
Patches are welcome ;-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v3 2/4] drivers: iio: ti_am335x_adc: add dma support
From: Mugunthan V N @ 2016-10-19 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d0105217-a8ee-cd8e-221d-34c19257765e@kernel.org>
On Sunday 09 October 2016 02:00 PM, Jonathan Cameron wrote:
> On 05/10/16 10:04, Mugunthan V N wrote:
>> This patch adds the required pieces to ti_am335x_adc driver for
>> DMA support
>>
>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> Hi,
>
> Just the one question inline. I'll also need an Ack from Lee as
> this touches code in mfd (as does the previous patch).
> We have obviously missed this merge window, so no particular rush.
>
> Otherwise, looking very nice indeed. Got to get my BBB out and play
> with this now ;)
>
> Jonathan
>> ---
>> drivers/iio/adc/ti_am335x_adc.c | 148 ++++++++++++++++++++++++++++++++++-
>> include/linux/mfd/ti_am335x_tscadc.h | 7 ++
>> 2 files changed, 152 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
>> index c3cfacca..ad9dec3 100644
>> --- a/drivers/iio/adc/ti_am335x_adc.c
>> +++ b/drivers/iio/adc/ti_am335x_adc.c
>> @@ -30,10 +30,28 @@
>> #include <linux/iio/buffer.h>
>> #include <linux/iio/kfifo_buf.h>
>>
>> +#include <linux/dmaengine.h>
>> +#include <linux/dma-mapping.h>
>> +
>> +#define DMA_BUFFER_SIZE SZ_2K
>> +
>> +struct tiadc_dma {
>> + struct dma_slave_config conf;
>> + struct dma_chan *chan;
>> + dma_addr_t addr;
>> + dma_cookie_t cookie;
>> + u8 *buf;
>> + int current_period;
>> + int period_size;
>> + u8 fifo_thresh;
>> +};
>> +
>> struct tiadc_device {
>> struct ti_tscadc_dev *mfd_tscadc;
>> + struct tiadc_dma dma;
>> struct mutex fifo1_lock; /* to protect fifo access */
>> int channels;
>> + int total_ch_enabled;
>> u8 channel_line[8];
>> u8 channel_step[8];
>> int buffer_en_ch_steps;
>> @@ -198,6 +216,67 @@ static irqreturn_t tiadc_worker_h(int irq, void *private)
>> return IRQ_HANDLED;
>> }
>>
>> +static void tiadc_dma_rx_complete(void *param)
>> +{
>> + struct iio_dev *indio_dev = param;
>> + struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> + u8 *data;
>> + int i;
>> +
>> + data = dma->buf + dma->current_period * dma->period_size;
>> + dma->current_period = 1 - dma->current_period; /* swap the buffer ID */
>> +
>> + for (i = 0; i < dma->period_size; i += indio_dev->scan_bytes) {
>> + iio_push_to_buffers(indio_dev, data);
>> + data += indio_dev->scan_bytes;
>> + }
> Hmm. Another case for the mooted iio_push_to_buffers_multi. Guess
> we should move on with that one ;)
>> +}
>> +
>> +static int tiadc_start_dma(struct iio_dev *indio_dev)
>> +{
>> + struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> + struct dma_async_tx_descriptor *desc;
>> +
>> + dma->current_period = 0; /* We start to fill period 0 */
>> + /*
>> + * Make the fifo thresh as the multiple of total number of
>> + * channels enabled, so make sure that cyclic DMA period
>> + * length is also a multiple of total number of channels
>> + * enabled. This ensures that no invalid data is reported
>> + * to the stack via iio_push_to_buffers().
>> + */
>> + dma->fifo_thresh = rounddown(FIFO1_THRESHOLD + 1,
>> + adc_dev->total_ch_enabled) - 1;
>> + /* Make sure that period length is multiple of fifo thresh level */
>> + dma->period_size = rounddown(DMA_BUFFER_SIZE / 2,
>> + (dma->fifo_thresh + 1) * sizeof(u16));
>> +
>> + dma->conf.src_maxburst = dma->fifo_thresh + 1;
>> + dmaengine_slave_config(dma->chan, &dma->conf);
>> +
>> + desc = dmaengine_prep_dma_cyclic(dma->chan, dma->addr,
>> + dma->period_size * 2,
>> + dma->period_size, DMA_DEV_TO_MEM,
>> + DMA_PREP_INTERRUPT);
>> + if (!desc)
>> + return -EBUSY;
>> +
>> + desc->callback = tiadc_dma_rx_complete;
>> + desc->callback_param = indio_dev;
>> +
>> + dma->cookie = dmaengine_submit(desc);
>> +
>> + dma_async_issue_pending(dma->chan);
>> +
>> + tiadc_writel(adc_dev, REG_FIFO1THR, dma->fifo_thresh);
>> + tiadc_writel(adc_dev, REG_DMA1REQ, dma->fifo_thresh);
>> + tiadc_writel(adc_dev, REG_DMAENABLE_SET, DMA_FIFO1);
>> +
>> + return 0;
>> +}
>> +
>> static int tiadc_buffer_preenable(struct iio_dev *indio_dev)
>> {
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> @@ -218,20 +297,30 @@ static int tiadc_buffer_preenable(struct iio_dev *indio_dev)
>> static int tiadc_buffer_postenable(struct iio_dev *indio_dev)
>> {
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> + unsigned int irq_enable;
>> unsigned int enb = 0;
>> u8 bit;
>>
>> tiadc_step_config(indio_dev);
>> - for_each_set_bit(bit, indio_dev->active_scan_mask, adc_dev->channels)
>> + for_each_set_bit(bit, indio_dev->active_scan_mask, adc_dev->channels) {
>> enb |= (get_adc_step_bit(adc_dev, bit) << 1);
>> + adc_dev->total_ch_enabled++;
>> + }
>> adc_dev->buffer_en_ch_steps = enb;
>>
>> + if (dma->chan)
>> + tiadc_start_dma(indio_dev);
>> +
>> am335x_tsc_se_set_cache(adc_dev->mfd_tscadc, enb);
>>
>> tiadc_writel(adc_dev, REG_IRQSTATUS, IRQENB_FIFO1THRES
>> | IRQENB_FIFO1OVRRUN | IRQENB_FIFO1UNDRFLW);
>> - tiadc_writel(adc_dev, REG_IRQENABLE, IRQENB_FIFO1THRES
>> - | IRQENB_FIFO1OVRRUN);
>> +
>> + irq_enable = IRQENB_FIFO1OVRRUN;
>> + if (!dma->chan)
>> + irq_enable |= IRQENB_FIFO1THRES;
> This changes the non dma behaviour as we no longer set IRQENB_FIFO1THRES.
> Why? Was it wrong before?
In non DMA case, dms->chan will be NULL and IRQENB_FIFO1THRES interrupt
will be enabled to pop the ADC samples.
Regards
Mugunthan V N
>> + tiadc_writel(adc_dev, REG_IRQENABLE, irq_enable);
>>
>> return 0;
>> }
>> @@ -239,12 +328,18 @@ static int tiadc_buffer_postenable(struct iio_dev *indio_dev)
>> static int tiadc_buffer_predisable(struct iio_dev *indio_dev)
>> {
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> int fifo1count, i, read;
>>
>> tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
>> IRQENB_FIFO1OVRRUN | IRQENB_FIFO1UNDRFLW));
>> am335x_tsc_se_clr(adc_dev->mfd_tscadc, adc_dev->buffer_en_ch_steps);
>> adc_dev->buffer_en_ch_steps = 0;
>> + adc_dev->total_ch_enabled = 0;
>> + if (dma->chan) {
>> + tiadc_writel(adc_dev, REG_DMAENABLE_CLEAR, 0x2);
>> + dmaengine_terminate_async(dma->chan);
>> + }
>>
>> /* Flush FIFO of leftover data in the time it takes to disable adc */
>> fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
>> @@ -430,6 +525,41 @@ static const struct iio_info tiadc_info = {
>> .driver_module = THIS_MODULE,
>> };
>>
>> +static int tiadc_request_dma(struct platform_device *pdev,
>> + struct tiadc_device *adc_dev)
>> +{
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> + dma_cap_mask_t mask;
>> +
>> + /* Default slave configuration parameters */
>> + dma->conf.direction = DMA_DEV_TO_MEM;
>> + dma->conf.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>> + dma->conf.src_addr = adc_dev->mfd_tscadc->tscadc_phys_base + REG_FIFO1;
>> +
>> + dma_cap_zero(mask);
>> + dma_cap_set(DMA_CYCLIC, mask);
>> +
>> + /* Get a channel for RX */
>> + dma->chan = dma_request_chan(adc_dev->mfd_tscadc->dev, "fifo1");
>> + if (IS_ERR(dma->chan)) {
>> + int ret = PTR_ERR(dma->chan);
>> +
>> + dma->chan = NULL;
>> + return ret;
>> + }
>> +
>> + /* RX buffer */
>> + dma->buf = dma_alloc_coherent(dma->chan->device->dev, DMA_BUFFER_SIZE,
>> + &dma->addr, GFP_KERNEL);
>> + if (!dma->buf)
>> + goto err;
>> +
>> + return 0;
>> +err:
>> + dma_release_channel(dma->chan);
>> + return -ENOMEM;
>> +}
>> +
>> static int tiadc_parse_dt(struct platform_device *pdev,
>> struct tiadc_device *adc_dev)
>> {
>> @@ -512,8 +642,14 @@ static int tiadc_probe(struct platform_device *pdev)
>>
>> platform_set_drvdata(pdev, indio_dev);
>>
>> + err = tiadc_request_dma(pdev, adc_dev);
>> + if (err && err == -EPROBE_DEFER)
>> + goto err_dma;
>> +
>> return 0;
>>
>> +err_dma:
>> + iio_device_unregister(indio_dev);
>> err_buffer_unregister:
>> tiadc_iio_buffered_hardware_remove(indio_dev);
>> err_free_channels:
>> @@ -525,8 +661,14 @@ static int tiadc_remove(struct platform_device *pdev)
>> {
>> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> u32 step_en;
>>
>> + if (dma->chan) {
>> + dma_free_coherent(dma->chan->device->dev, DMA_BUFFER_SIZE,
>> + dma->buf, dma->addr);
>> + dma_release_channel(dma->chan);
>> + }
>> iio_device_unregister(indio_dev);
>> tiadc_iio_buffered_hardware_remove(indio_dev);
>> tiadc_channels_remove(indio_dev);
>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>> index e45a208..b9a53e0 100644
>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>> @@ -23,6 +23,8 @@
>> #define REG_IRQENABLE 0x02C
>> #define REG_IRQCLR 0x030
>> #define REG_IRQWAKEUP 0x034
>> +#define REG_DMAENABLE_SET 0x038
>> +#define REG_DMAENABLE_CLEAR 0x03c
>> #define REG_CTRL 0x040
>> #define REG_ADCFSM 0x044
>> #define REG_CLKDIV 0x04C
>> @@ -36,6 +38,7 @@
>> #define REG_FIFO0THR 0xE8
>> #define REG_FIFO1CNT 0xF0
>> #define REG_FIFO1THR 0xF4
>> +#define REG_DMA1REQ 0xF8
>> #define REG_FIFO0 0x100
>> #define REG_FIFO1 0x200
>>
>> @@ -126,6 +129,10 @@
>> #define FIFOREAD_DATA_MASK (0xfff << 0)
>> #define FIFOREAD_CHNLID_MASK (0xf << 16)
>>
>> +/* DMA ENABLE/CLEAR Register */
>> +#define DMA_FIFO0 BIT(0)
>> +#define DMA_FIFO1 BIT(1)
>> +
>> /* Sequencer Status */
>> #define SEQ_STATUS BIT(5)
>> #define CHARGE_STEP 0x11
>>
>
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Michal Hocko @ 2016-10-19 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019084045.GA19441@lucifer>
On Wed 19-10-16 09:40:45, Lorenzo Stoakes wrote:
> On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote:
> > On Wed 19-10-16 09:59:03, Jan Kara wrote:
> > > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
> > > > This patch removes the write parameter from __access_remote_vm() and replaces it
> > > > with a gup_flags parameter as use of this function previously _implied_
> > > > FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
> > > >
> > > > We make this explicit as use of FOLL_FORCE can result in surprising behaviour
> > > > (and hence bugs) within the mm subsystem.
> > > >
> > > > Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
> > >
> > > So I'm not convinced this (and the following two patches) is actually
> > > helping much. By grepping for FOLL_FORCE we will easily see that any caller
> > > of access_remote_vm() gets that semantics and can thus continue search
> >
> > I am really wondering. Is there anything inherent that would require
> > FOLL_FORCE for access_remote_vm? I mean FOLL_FORCE is a really
> > non-trivial thing. It doesn't obey vma permissions so we should really
> > minimize its usage. Do all of those users really need FOLL_FORCE?
>
> I wonder about this also, for example by accessing /proc/self/mem you trigger
> access_remote_vm() and consequently get_user_pages_remote() meaning FOLL_FORCE
> is implied and you can use /proc/self/mem to override any VMA permissions. I
yes this is the desirable and expected behavior.
> wonder if this is desirable behaviour or whether this ought to be limited to
> ptrace system calls. Regardless, by making the flag more visible it makes it
> easier to see that this is happening.
mem_open already enforces PTRACE_MODE_ATTACH
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-19 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019084607.GB9193@arm.com>
On 19 October 2016 at 09:46, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
>> On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
>> > On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
>> > >> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
>> > >> currently work, or have ever worked correctly when built for big endian. So this
>> > >> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
>> > >> well, and an additional fix for XTS which escaped my attention before.
>> > >>
>> > >> Each of these patches carries a fixes tag, and could be backported to stable.
>> > >> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
>> > >> fix is compatible with, not the patch that introduced the algorithm.
>> > >
>> > > I think for future reference, the Fixes tag should denote the commit
>> > > that introduced the issue. An explicit Cc: stable tag would state how
>> > > far back it should be applied.
>> > >
>> >
>> > OK, that sounds reasonable.
>> >
>> > >> Ard Biesheuvel (8):
>> > >> crypto: arm64/aes-ce - fix for big endian
>> > >> crypto: arm64/ghash-ce - fix for big endian
>> > >> crypto: arm64/sha1-ce - fix for big endian
>> > >> crypto: arm64/sha2-ce - fix for big endian
>> > >> crypto: arm64/aes-ccm-ce: fix for big endian
>> > >> crypto: arm64/aes-neon - fix for big endian
>> > >> crypto: arm64/aes-xts-ce: fix for big endian
>> > >> crypto: arm/aes-ce - fix for big endian
>> > >
>> > > The changes look fine to me but I can't claim I fully understand these
>> > > algorithms. FWIW:
>> > >
>> > > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>> > >
>> > > (Will may pick them up for 4.9-rcX)
>> >
>> > Thanks, although I was kind of expecting Herbert to pick these up,
>> > given that #8 affects ARM not arm64.
>> >
>> > But if you (or Will) can pick up #1 to #7, that is also fine, then I
>> > can drop #8 into rmk's patch database.
>>
>> I was planning merging these for 4.10. But I'm fine with them
>> going through the arm tree. Let me know what you guys want to
>> do.
>
> I assumed you'd take them through crypto, as per usual, so I didn't
> queue anything in the arm64 tree.
>
> Ard -- were you planning to get these in for 4.9?
>
These are arguably bug fixes, but I spotted them by accident, they
weren't reported to me or anything. But it seems strange to add a cc
stable and then hold off until the next merge window.
In any case, I don't care deeply either way, as long as they get
merged in the end. I think it makes sense to keep them together (arm64
+ ARM), so Herbert's tree is a more natural route for them to take. I
will leave it up to Herbert whether they are sent onward as fixes or
as part of v4.10
Thanks,
Ard.
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Will Deacon @ 2016-10-19 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019030333.GA1269@gondor.apana.org.au>
On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
> On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
> > On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
> > >> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> > >> currently work, or have ever worked correctly when built for big endian. So this
> > >> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> > >> well, and an additional fix for XTS which escaped my attention before.
> > >>
> > >> Each of these patches carries a fixes tag, and could be backported to stable.
> > >> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> > >> fix is compatible with, not the patch that introduced the algorithm.
> > >
> > > I think for future reference, the Fixes tag should denote the commit
> > > that introduced the issue. An explicit Cc: stable tag would state how
> > > far back it should be applied.
> > >
> >
> > OK, that sounds reasonable.
> >
> > >> Ard Biesheuvel (8):
> > >> crypto: arm64/aes-ce - fix for big endian
> > >> crypto: arm64/ghash-ce - fix for big endian
> > >> crypto: arm64/sha1-ce - fix for big endian
> > >> crypto: arm64/sha2-ce - fix for big endian
> > >> crypto: arm64/aes-ccm-ce: fix for big endian
> > >> crypto: arm64/aes-neon - fix for big endian
> > >> crypto: arm64/aes-xts-ce: fix for big endian
> > >> crypto: arm/aes-ce - fix for big endian
> > >
> > > The changes look fine to me but I can't claim I fully understand these
> > > algorithms. FWIW:
> > >
> > > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> > >
> > > (Will may pick them up for 4.9-rcX)
> >
> > Thanks, although I was kind of expecting Herbert to pick these up,
> > given that #8 affects ARM not arm64.
> >
> > But if you (or Will) can pick up #1 to #7, that is also fine, then I
> > can drop #8 into rmk's patch database.
>
> I was planning merging these for 4.10. But I'm fine with them
> going through the arm tree. Let me know what you guys want to
> do.
I assumed you'd take them through crypto, as per usual, so I didn't
queue anything in the arm64 tree.
Ard -- were you planning to get these in for 4.9?
Will
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Lorenzo Stoakes @ 2016-10-19 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019081352.GB7562@dhcp22.suse.cz>
On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote:
> On Wed 19-10-16 09:59:03, Jan Kara wrote:
> > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
> > > This patch removes the write parameter from __access_remote_vm() and replaces it
> > > with a gup_flags parameter as use of this function previously _implied_
> > > FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
> > >
> > > We make this explicit as use of FOLL_FORCE can result in surprising behaviour
> > > (and hence bugs) within the mm subsystem.
> > >
> > > Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
> >
> > So I'm not convinced this (and the following two patches) is actually
> > helping much. By grepping for FOLL_FORCE we will easily see that any caller
> > of access_remote_vm() gets that semantics and can thus continue search
>
> I am really wondering. Is there anything inherent that would require
> FOLL_FORCE for access_remote_vm? I mean FOLL_FORCE is a really
> non-trivial thing. It doesn't obey vma permissions so we should really
> minimize its usage. Do all of those users really need FOLL_FORCE?
I wonder about this also, for example by accessing /proc/self/mem you trigger
access_remote_vm() and consequently get_user_pages_remote() meaning FOLL_FORCE
is implied and you can use /proc/self/mem to override any VMA permissions. I
wonder if this is desirable behaviour or whether this ought to be limited to
ptrace system calls. Regardless, by making the flag more visible it makes it
easier to see that this is happening.
Note that this /proc/self/mem behaviour is what triggered the bug that brought
about this discussion in the first place -
https://marc.info/?l=linux-mm&m=147363447105059 - as using /proc/self/mem this
way on PROT_NONE memory broke some assumptions.
On the other hand I see your point Jan in that you know any caller of these
functions will have FOLL_FORCE implied, and you have to decide to stop passing
the flag at _some_ point in the stack, however it seems fairly sane to have that
stopping point exist outside of exported gup functions so the gup interface
forces explicitness but callers can wrap things as they need.
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Lorenzo Pieralisi @ 2016-10-19 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3d228f5f-8fb8-91f4-4572-4aeda679d36e@arm.com>
On Mon, Oct 17, 2016 at 06:31:58PM +0100, Sudeep Holla wrote:
>
>
> On 23/09/16 15:03, Lorenzo Pieralisi wrote:
> >On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
> >>Current vexpress smp init code detects whether to override the
> >>default smp ops with MCPM smp ops by matching the "cci-400"
> >>compatible string, in that MCPM requires control over CCI ports
> >>to manage low-power states entry/exit.
> >>
> >>The "cci-400" compatible string check is a necessary but not
> >>sufficient condition for MCPM to work, because the cci-400
> >>can be made visible to the kernel, but firmware can nonetheless
> >>disable non-secure CCI ports control, while still allowing PMU
> >>access; if booted in non-secure world, the kernel would still
> >>blindly override smp operations with MCPM operations, resulting
> >>in kernel faults when the CCI ports programming interface is
> >>accessed from non-secure world.
> >>
> >>This means that the "cci-400" compatible string check would
> >>result in a false positive in systems that eg boot in HYP mode,
> >>where CCI ports non-secure access is explicitly not allowed,
> >>and it is reported in the respective device tree nodes with
> >>CCI ports marked as disabled.
> >>
> >>Refactor the smp operations initialization to make sure that
> >>the kernel is actually allowed to take control over CCI ports
> >>(by enabling MCPM smp operations) before overriding default
> >>vexpress smp operations.
> >>
> >>Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>Cc: Liviu Dudau <liviu.dudau@arm.com>
> >>Cc: Sudeep Holla <sudeep.holla@arm.com>
> >>Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> >>Cc: Marc Zyngier <marc.zyngier@arm.com>
> >>---
> >> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
> >> 1 file changed, 24 insertions(+), 7 deletions(-)
> >>
> >>diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> >>index 8b8d072..6cfd782 100644
> >>--- a/arch/arm/mach-vexpress/platsmp.c
> >>+++ b/arch/arm/mach-vexpress/platsmp.c
> >>@@ -26,17 +26,34 @@
> >> bool __init vexpress_smp_init_ops(void)
> >> {
> >> #ifdef CONFIG_MCPM
> >>+ int cpu;
> >>+ struct device_node *cpu_node, *cci_node;
> >>+
> >> /*
> >>- * The best way to detect a multi-cluster configuration at the moment
> >>- * is to look for the presence of a CCI in the system.
> >>+ * The best way to detect a multi-cluster configuration
> >>+ * is to detect if the kernel can take over CCI ports
> >>+ * control. Loop over possible CPUs and check if CCI
> >>+ * port control is available.
> >> * Override the default vexpress_smp_ops if so.
> >> */
> >>- struct device_node *node;
> >>- node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
> >>- if (node && of_device_is_available(node)) {
> >>- mcpm_smp_set_ops();
> >>- return true;
> >>+ for_each_possible_cpu(cpu) {
> >>+ bool available;
> >>+
> >>+ cpu_node = of_get_cpu_node(cpu, NULL);
> >>+ if (WARN(!cpu_node, "Missing cpu device node!"))
> >>+ return false;
> >>+
> >>+ cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
> >>+ available = cci_node && of_device_is_available(cci_node);
> >>+ of_node_put(cci_node);
> >>+ of_node_put(cpu_node);
> >>+
> >>+ if (!available)
> >>+ return false;
> >> }
> >>+
> >>+ mcpm_smp_set_ops();
> >>+ return true;
> >> #endif
> >> return false;
> >
> >For the records, while moving the code around I missed I was ending
> >up with this idiotic double return, I have already reworked the patch
> >and will squash changes in the final version if we agree on the bulk of
> >the code.
> >
>
> I applied both patches to [1] with the fix for the above issue. Let me
> know if that's fine. I have tested both hyp mode boot and SVC mode +
> MCPM boot with latest u-boot by just fliping a bit in the firmware
> (board.txt) without recompiling the kernel.
I updated the patch to remove the double return will send an updated
patch today.
Thanks !
Lorenzo
>
> --
> Regards,
> Sudeep
>
> [1] git.kernel.org/sudeep.holla/linux/h/vexpress/for-next
>
^ permalink raw reply
* [PATCH v3 06/11] ARM: dts: r8a7743: add [H]SCIF{A|B} support
From: Geert Uytterhoeven @ 2016-10-19 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14213508.lp3q5ZvmbF@wasted.cogentembedded.com>
On Wed, Oct 5, 2016 at 11:41 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe [H]SCIF[AB] ports in the R8A7743 device tree.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
With the modifications indicated below:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
> @@ -162,6 +162,267 @@
> #dma-cells = <1>;
> dma-channels = <15>;
> };
> +
> + scifa0: serial at e6c40000 {
> + compatible = "renesas,scifa-r8a7743",
> + "renesas,rzg-scifa", "renesas,scifa";
Please use "renesas,rcar-gen2-scifa" instead of "renesas,rzg-scifa".
> + scifb0: serial at e6c20000 {
> + compatible = "renesas,scifb-r8a7743",
> + "renesas,rzg-scifb", "renesas,scifb";
"renesas,rcar-gen2-scifb"
> + scif0: serial at e6e60000 {
> + compatible = "renesas,scif-r8a7743", "renesas,rzg-scif",
"renesas,rcar-gen2-scif"
> + hscif0: serial at e62c0000 {
> + compatible = "renesas,hscif-r8a7743",
> + "renesas,rzg-hscif", "renesas,hscif";
"renesas,rcar-gen2-hscif"
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply
* [PATCH v2 0/6] STM32F4 Add RTC & QSPI clocks
From: Gabriel Fernandez @ 2016-10-19 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018235108.GP8871@codeaurora.org>
Hi Stephen,
On 10/19/2016 01:51 AM, Stephen Boyd wrote:
> On 10/14, gabriel.fernandez at st.com wrote:
>> Gabriel Fernandez (6):
>> clk: stm32f4: Add LSI & LSE clocks
>> ARM: dts: stm32f429: add LSI and LSE clocks
>> arm: stmf32: Enable SYSCON
>> clk: stm32f4: Add RTC clock
>> clk: stm32f469: Add QSPI clock
>> ARM: dts: stm32f429: Add QSPI clock
> Can the clk patches be picked without causing problems for
> existing dt changes? Do you want an ack from clk maintainers
> instead of us picking the clk patches up? The series has
> intermingled clk and dts changes so I'm confused.
>
Thanks for reviewing.
Normally DT patches will be taken by STM32 maintainer, but yes there is
a dependency between patch 1 & 2, so if you push the patch 1 into
clk-next tree you have to take also patch 2.
You have to be synchronized with Alexandre Torgue.
Best Regards
Gabriel
^ permalink raw reply
* [PATCH 2/3] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC
From: Masahiro Yamada @ 2016-10-19 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112548.GA11471@vireshk-i7>
Hi Viresh,
2016-10-18 20:25 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> On 16-10-16, 23:59, Masahiro Yamada wrote:
>> + cluster0_opp: opp_table {
>> + compatible = "operating-points-v2";
>> + opp-shared;
>> +
>> + opp at 245000000 {
>> + opp-hz = /bits/ 64 <245000000>;
>> + clock-latency-ns = <300>;
>> + };
>> + opp at 250000000 {
>> + opp-hz = /bits/ 64 <250000000>;
>> + clock-latency-ns = <300>;
>> + };
>> + opp at 490000000 {
>> + opp-hz = /bits/ 64 <490000000>;
>> + clock-latency-ns = <300>;
>> + };
>> + opp at 500000000 {
>> + opp-hz = /bits/ 64 <500000000>;
>> + clock-latency-ns = <300>;
>> + };
>> + opp at 653333333 {
>
> Why isn't ^^ matching with below values ? Same in next patch as well.
When I try to update /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq,
it did not work as I had expected.
scaling_max_freq is specified by kHz unit,
on the other hand, clock frequency in the clk driver is specified by Hz.
If the operating point is 653333kHz, the cpufreq requests
the clk driver to set 653333000, but it is lower than
the exact clock, 653333333.
So, the next lower frequency, 500000000 is selected.
As a result, the operating point 653333kHz is never enabled.
So, the operating point must be equal or a little bit bigger.
Do you know a better way to solve this distortion?
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [v12, 0/8] Fix eSDHC host version register bug
From: gregkh at linuxfoundation.org @ 2016-10-19 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM5PR0401MB2529BA70C6E7AF7C71631A47F8D20@AM5PR0401MB2529.eurprd04.prod.outlook.com>
On Wed, Oct 19, 2016 at 02:47:07AM +0000, Y.B. Lu wrote:
> + Greg
>
> Hi Greg,
>
> I submitted this patchset for a MMC bug fix, and introduce the below patch which needs your ACK.
> > > Arnd Bergmann (1):
> > > base: soc: introduce soc_device_match() interface
> https://patchwork.kernel.org/patch/9342913/
>
> Could you help to review it and give some comments or ACK.
> Thank you very much.
Now acked.
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Bartosz Golaszewski @ 2016-10-19 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4369153.vCOQzI7OET@avalon>
2016-10-18 22:49 GMT+02:00 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Bartosz,
>
> Thank you for the patch.
>
> On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote:
>> Create the driver for the da8xx System Configuration and implement
>> support for writing to the three Master Priority registers.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[snip]
>> +
>> +Documentation:
>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> +
>> +Required properties:
>> +
>> +- compatible: "ti,da850-syscfg"
>
> Don't you need a reg property ?
>
Yes, Kevin already pointed that out. I'll add it in v2. Same for [1/3].
>> +Optional properties:
>> +
>> +The below properties are used to specify the priority of master
>> peripherals.
>> +They must be between 0-7 where 0 is the highest priority and 7 is the
>> lowest.
>> +
>> +- ti,pri-arm-i: ARM_I port priority.
>> +
>> +- ti,pri-arm-d: ARM_D port priority.
>> +
>> +- ti,pri-upp: uPP port priority.
>> +
>> +- ti,pri-sata: SATA port priority.
>> +
>> +- ti,pri-pru0: PRU0 port priority.
>> +
>> +- ti,pri-pru1: PRU1 port priority.
>> +
>> +- ti,pri-edma30tc0: EDMA3_0_TC0 port priority.
>> +
>> +- ti,pri-edma30tc1: EDMA3_0_TC1 port priority.
>> +
>> +- ti,pri-edma31tc0: EDMA3_1_TC0 port priority.
>> +
>> +- ti,pri-vpif-dma-0: VPIF DMA0 port priority.
>> +
>> +- ti,pri-vpif-dma-1: VPIF DMA1 port priority.
>> +
>> +- ti,pri-emac: EMAC port priority.
>> +
>> +- ti,pri-usb0cfg: USB0 CFG port priority.
>> +
>> +- ti,pri-usb0cdma: USB0 CDMA port priority.
>> +
>> +- ti,pri-uhpi: HPI port priority.
>> +
>> +- ti,pri-usb1: USB1 port priority.
>> +
>> +- ti,pri-lcdc: LCDC port priority.
>
> I'm afraid this looks more like system configuration than hardware description
> to me.
>
While you're certainly right, this approach is already implemented in
several other memory and bus drivers and it was also suggested by
Sekhar in one of the tilcdc rev1 threads. There's also no real
alternative that I know of.
> There was a BoF session about how to support this kind of performance knobs at
> ELCE last week: https://openiotelceurope2016.sched.org/event/7rss/bof-linux-device-performance-framework-michael-turquette-baylibre :-)
>
I know, I was there. ;)
Unfortunately it was just a discussion about potential approaches -
there's no code yet.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH 3/4] base: soc: Check for NULL SoC device attributes
From: Greg Kroah-Hartman @ 2016-10-19 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475572167-29581-4-git-send-email-geert+renesas@glider.be>
On Tue, Oct 04, 2016 at 11:09:26AM +0200, Geert Uytterhoeven wrote:
> If soc_device_match() is used to check the value of a specific
> attribute that is not present for the current SoC, the kernel crashes
> with a NULL pointer dereference.
>
> Fix this by explicitly checking for the absence of a needed property,
> and considering this a non-match.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH 2/4] base: soc: Introduce soc_device_match() interface
From: Greg Kroah-Hartman @ 2016-10-19 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475572167-29581-3-git-send-email-geert+renesas@glider.be>
On Tue, Oct 04, 2016 at 11:09:25AM +0200, Geert Uytterhoeven wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> We keep running into cases where device drivers want to know the exact
> version of the a SoC they are currently running on. In the past, this has
> usually been done through a vendor specific API that can be called by a
> driver, or by directly accessing some kind of version register that is
> not part of the device itself but that belongs to a global register area
> of the chip.
>
> Common reasons for doing this include:
>
> - A machine is not using devicetree or similar for passing data about
> on-chip devices, but just announces their presence using boot-time
> platform devices, and the machine code itself does not care about the
> revision.
>
> - There is existing firmware or boot loaders with existing DT binaries
> with generic compatible strings that do not identify the particular
> revision of each device, but the driver knows which SoC revisions
> include which part.
>
> - A prerelease version of a chip has some quirks and we are using the same
> version of the bootloader and the DT blob on both the prerelease and the
> final version. An update of the DT binding seems inappropriate because
> that would involve maintaining multiple copies of the dts and/or
> bootloader.
>
> This patch introduces the soc_device_match() interface that is meant to
> work like of_match_node() but instead of identifying the version of a
> device, it identifies the SoC itself using a vendor-agnostic interface.
>
> Unlike of_match_node(), we do not do an exact string compare but instead
> use glob_match() to allow wildcards in strings.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/sys_soc.h | 3 +++
> 3 files changed, 70 insertions(+)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH] reset: uniphier: rename MIO reset to SD reset for Pro5, PXs2, LD20 SoCs
From: Masahiro Yamada @ 2016-10-19 8:23 UTC (permalink / raw)
To: linux-arm-kernel
I made a mistake as for naming for this block. The MIO block is not
implemented for these 3 SoCs in the first place. The current naming
will be a trouble if an SoC with both MIO and SD-ctrl blocks appear
in the future.
This driver has just been merged in the previous merge window.
Rename it before the release.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Philipp,
If you do not mind, may I include this in my PR
along with the "select ARCH_HAS_RESET_CONTROLLER" patches?
.../devicetree/bindings/reset/uniphier-reset.txt | 22 +++++++++++-----------
drivers/reset/reset-uniphier.c | 16 ++++++++--------
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
index e6bbfcc..78cd735 100644
--- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
+++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
@@ -19,12 +19,12 @@ Required properties:
Example:
sysctrl at 61840000 {
- compatible = "socionext,uniphier-ld20-sysctrl",
+ compatible = "socionext,uniphier-ld11-sysctrl",
"simple-mfd", "syscon";
reg = <0x61840000 0x4000>;
reset {
- compatible = "socionext,uniphier-ld20-reset";
+ compatible = "socionext,uniphier-ld11-reset";
#reset-cells = <1>;
};
@@ -32,8 +32,8 @@ Example:
};
-Media I/O (MIO) reset
----------------------
+Media I/O (MIO) reset, SD reset
+-------------------------------
Required properties:
- compatible: should be one of the following:
@@ -41,21 +41,21 @@ Required properties:
"socionext,uniphier-ld4-mio-reset" - for PH1-LD4 SoC.
"socionext,uniphier-pro4-mio-reset" - for PH1-Pro4 SoC.
"socionext,uniphier-sld8-mio-reset" - for PH1-sLD8 SoC.
- "socionext,uniphier-pro5-mio-reset" - for PH1-Pro5 SoC.
- "socionext,uniphier-pxs2-mio-reset" - for ProXstream2/PH1-LD6b SoC.
+ "socionext,uniphier-pro5-sd-reset" - for PH1-Pro5 SoC.
+ "socionext,uniphier-pxs2-sd-reset" - for ProXstream2/PH1-LD6b SoC.
"socionext,uniphier-ld11-mio-reset" - for PH1-LD11 SoC.
- "socionext,uniphier-ld20-mio-reset" - for PH1-LD20 SoC.
+ "socionext,uniphier-ld20-sd-reset" - for PH1-LD20 SoC.
- #reset-cells: should be 1.
Example:
mioctrl at 59810000 {
- compatible = "socionext,uniphier-ld20-mioctrl",
+ compatible = "socionext,uniphier-ld11-mioctrl",
"simple-mfd", "syscon";
reg = <0x59810000 0x800>;
reset {
- compatible = "socionext,uniphier-ld20-mio-reset";
+ compatible = "socionext,uniphier-ld11-mio-reset";
#reset-cells = <1>;
};
@@ -80,12 +80,12 @@ Required properties:
Example:
perictrl at 59820000 {
- compatible = "socionext,uniphier-ld20-perictrl",
+ compatible = "socionext,uniphier-ld11-perictrl",
"simple-mfd", "syscon";
reg = <0x59820000 0x200>;
reset {
- compatible = "socionext,uniphier-ld20-peri-reset";
+ compatible = "socionext,uniphier-ld11-peri-reset";
#reset-cells = <1>;
};
diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 8b2558e..968c3ae 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -154,7 +154,7 @@ struct uniphier_reset_data {
UNIPHIER_RESET_END,
};
-const struct uniphier_reset_data uniphier_pro5_mio_reset_data[] = {
+const struct uniphier_reset_data uniphier_pro5_sd_reset_data[] = {
UNIPHIER_MIO_RESET_SD(0, 0),
UNIPHIER_MIO_RESET_SD(1, 1),
UNIPHIER_MIO_RESET_EMMC_HW_RESET(6, 1),
@@ -360,7 +360,7 @@ static int uniphier_reset_probe(struct platform_device *pdev)
.compatible = "socionext,uniphier-ld20-reset",
.data = uniphier_ld20_sys_reset_data,
},
- /* Media I/O reset */
+ /* Media I/O reset, SD reset */
{
.compatible = "socionext,uniphier-sld3-mio-reset",
.data = uniphier_sld3_mio_reset_data,
@@ -378,20 +378,20 @@ static int uniphier_reset_probe(struct platform_device *pdev)
.data = uniphier_sld3_mio_reset_data,
},
{
- .compatible = "socionext,uniphier-pro5-mio-reset",
- .data = uniphier_pro5_mio_reset_data,
+ .compatible = "socionext,uniphier-pro5-sd-reset",
+ .data = uniphier_pro5_sd_reset_data,
},
{
- .compatible = "socionext,uniphier-pxs2-mio-reset",
- .data = uniphier_pro5_mio_reset_data,
+ .compatible = "socionext,uniphier-pxs2-sd-reset",
+ .data = uniphier_pro5_sd_reset_data,
},
{
.compatible = "socionext,uniphier-ld11-mio-reset",
.data = uniphier_sld3_mio_reset_data,
},
{
- .compatible = "socionext,uniphier-ld20-mio-reset",
- .data = uniphier_pro5_mio_reset_data,
+ .compatible = "socionext,uniphier-ld20-sd-reset",
+ .data = uniphier_pro5_sd_reset_data,
},
/* Peripheral reset */
{
--
1.9.1
^ permalink raw reply related
* [PATCH v3 11/11] ARM: dts: sk-rzg1m: add Ether support
From: Geert Uytterhoeven @ 2016-10-19 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1764267.cmIUehPqzi@wasted.cogentembedded.com>
On Wed, Oct 5, 2016 at 11:48 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Define the SK-RZG1M board dependent part of the Ether device node.
> Enable DHCP and NFS root for the kernel booting.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply
* [PATCH v3 04/11] ARM: dts: r8a7743: initial SoC device tree
From: Geert Uytterhoeven @ 2016-10-19 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2883940.Oo8sg10L7m@wasted.cogentembedded.com>
On Wed, Oct 5, 2016 at 11:38 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> The initial R8A7743 SoC device tree including CPU cores, GIC, timer, SYSC,
> CPG, and the required clock descriptions.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Michal Hocko @ 2016-10-19 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019075903.GP29967@quack2.suse.cz>
On Wed 19-10-16 09:59:03, Jan Kara wrote:
> On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
> > This patch removes the write parameter from __access_remote_vm() and replaces it
> > with a gup_flags parameter as use of this function previously _implied_
> > FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
> >
> > We make this explicit as use of FOLL_FORCE can result in surprising behaviour
> > (and hence bugs) within the mm subsystem.
> >
> > Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
>
> So I'm not convinced this (and the following two patches) is actually
> helping much. By grepping for FOLL_FORCE we will easily see that any caller
> of access_remote_vm() gets that semantics and can thus continue search
I am really wondering. Is there anything inherent that would require
FOLL_FORCE for access_remote_vm? I mean FOLL_FORCE is a really
non-trivial thing. It doesn't obey vma permissions so we should really
minimize its usage. Do all of those users really need FOLL_FORCE?
Anyway I would rather see the flag explicit and used at more places than
hidden behind a helper function.
--
Michal Hocko
SUSE Labs
^ 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