* [PATCH linux v1 0/4] Seven segment display support
From: Thomas Petazzoni @ 2016-12-14 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481702104-8617-1-git-send-email-jaghu@google.com>
Hello,
On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
Natarajan wrote:
> Documentation for the binding which provides an interface for adding clock,
> data and clear signal GPIO lines to control seven segment display.
>
> The platform device driver provides an API for displaying on two 7-segment
> displays, and implements the required bit-banging. The hardware assumed is
> 74HC164 wired to two 7-segment displays.
>
> The character device driver implements the user-space API for letting a user
> write to two 7-segment displays including any conversion methods necessary
> to map the user input to two 7-segment displays.
>
> Adding clock, data and clear signal GPIO lines in the devicetree to control
> seven segment display on zaius platform.
>
> The platform driver matches on the device tree node; the platform driver also
> initializes the character device.
>
> Tested that the seven segment display works properly by writing to the
> character device file on a EVB AST2500 board which also has 74HC164 wired
> to two 7-segment displays.
FWIW, I proposed a driver for seven segment displays back in 2013:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
And the feedback from Greg KH was: we don't need a driver for that, do
it from userspace. See:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
So: good luck :-)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] ARM: soft-reboot into same mode that we entered the kernel
From: Mark Rutland @ 2016-12-14 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214122945.GE14217@n2100.armlinux.org.uk>
On Wed, Dec 14, 2016 at 12:29:45PM +0000, Russell King - ARM Linux wrote:
> On Wed, Dec 14, 2016 at 12:17:47PM +0000, Mark Rutland wrote:
> > On Wed, Dec 14, 2016 at 12:05:41PM +0000, Russell King - ARM Linux wrote:
> > > The issue here is that a panic can happen at any time from any context
> > > with any hyp stub in place, so there _needs_ to be a uniform way to do
> > > this. It's very bad that we've got this far without this point having
> > > been considered - all we can do right now is to try and fix the issues
> > > as they come up.
> > >
> > > Right now, let's fix this so we get some kind of improvement, and later
> > > try to sort out some kind of uniform interface for this task.
> >
> > Sure, that's a bigger task, and this is definitely a step in the right
> > direction.
> >
> > We need to avoid the kdump regression somehow though; can we somehow
> > detect if KVM is active and avoid issuing the HVC_SOFT_RESTART?
>
> That's a question for KVM people.
>
> However, there's a bigger question, which is: what do we want to happen
> in the case of kdump - do we want to be entering the kdump kernel in
> HYP or SVC mode? As the kdump kernel exists to be able to save the
> state of a crashing system, the kdump kernel should do that and then
> restart the system in a clean way (iow, not via yet another kexec.)
>
> So maybe the right answer is that kdump should always invoke the kernel
> in SVC mode.
Personally, my view is the opposite -- we should always exit the way we
came, and kdump can go from there. Otherwise we're leaving context
active in hyp mode that might hinder kdump (or would otherwise be useful
for kdump to be able to access).
For example, we might want to do something like kernel guard, where even
the host kernel would have a stage-2 translation active in hyp that we'd
need to tear down. That, or the hyp page table might have been
corrupted, and tearing down ASAP might save us from asynchrnous issues
from page table walks. It's all a trade-off, either way -- the hyp code
could also be corrupt.
Certainly I would expect that once kdump's logged what it can, it should
trigger a real reboot.
Thanks,
Mark.
[1] https://01.org/intel-kgt
^ permalink raw reply
* [PATCH] ARM: dts: dra72-evm-tps65917: Add voltage supplies to usb_phy, mmc, dss
From: Lokesh Vutla @ 2016-12-14 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2bb73170-dbb5-01a3-5b3a-4d5d9414e3a9@ti.com>
On Wednesday 14 December 2016 04:30 PM, Roger Quadros wrote:
> Lokesh,
>
> On 14/12/16 10:57, Lokesh Vutla wrote:
>> Commit 5d080aa30681 ("ARM: dts: dra72: Add separate dtsi for tps65917")
>> added a separate dtsi for dra72-evm-tps65917 moving all the voltage supplies
>> to this file. But it missed adding voltage supplies to usb_phy, mmc,
>> dss and deleted from dra72-evm-common.dtsi. Adding the voltage supply
>> phandles to these nodes in dra72-evm-tps65917.dtsi
>>
>> Fixes: 5d080aa30681 ("ARM: dts: dra72: Add separate dtsi for tps65917")
>> Reported-by: Carlos Hernandez <ceh@ti.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> ---
>> Logs:
>> - DRA72-evm revC: http://pastebin.ubuntu.com/23627665/
>> - DRA72-evm revB: http://pastebin.ubuntu.com/23627658/
>> arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>> index ee6dac44edf1..e6df676886c0 100644
>> --- a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>> +++ b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>> @@ -132,3 +132,19 @@
>> ti,palmas-long-press-seconds = <6>;
>> };
>> };
>> +
>> +&usb2_phy1 {
>> + phy-supply = <&ldo4_reg>;
>> +};
>> +
>> +&usb2_phy2 {
>> + phy-supply = <&ldo4_reg>;
>> +};
>> +
>> +&dss {
>> + vdda_video-supply = <&ldo5_reg>;
>> +};
>> +
>> +&mmc1 {
>> + vmmc_aux-supply = <&ldo1_reg>;
>> +};
>>
>
> Are you sure that all future users of dra72-evm-tps65917.dtsi will use this same configuration?
> If not I'd rather put this in the board dts files.
hmm..This debate already happened when creating dra72-evm-tps65917 file
and concluded that all the common regulator stuff on dra72 evm revA,B,C
should go in this file. Any new board which is not similar to dra72-evm
will not be using this file.
Thanks and regards,
Lokesh
>
> cheers,
> -roger
>
^ permalink raw reply
* [PATCH linux v1 2/4] drivers: misc: Character device driver for seven segment display
From: Russell King - ARM Linux @ 2016-12-14 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481702104-8617-3-git-send-email-jaghu@google.com>
On Tue, Dec 13, 2016 at 11:55:02PM -0800, Jaghathiswari Rankappagounder Natarajan wrote:
> +int seven_seg_setup_cdev(struct seven_seg_disp_dev *disp_dev,
> + void (*update_disp_data)(struct device *, u16 data))
> +{
> + struct device *dev;
> + int err;
> +
> + dev = device_create(seven_seg_disp_class, &disp_dev->parent,
> + seven_seg_devno,
> + NULL, "seven_seg_disp_val");
> + if (dev == NULL)
> + return -1;
Do not use return -1 in kernel code.
> + disp_dev->dev = dev;
> + disp_dev->update_seven_seg_data = update_disp_data;
> + disp_dev->disp_data_valid = false;
> +
> + cdev_init(&disp_dev->cdev, &seven_seg_disp_fops);
> + err = cdev_add(&disp_dev->cdev, seven_seg_devno, 1);
> + if (err)
> + device_destroy(seven_seg_disp_class, seven_seg_devno);
> + return err;
> +}
> +
> +static int __init seven_seg_disp_init(void)
> +{
> + if (alloc_chrdev_region(&seven_seg_devno, 0, 1, "disp_state") < 0)
> + return -1;
Do not use return -1 in kernel code.
> +
> + seven_seg_disp_class = class_create(THIS_MODULE, "disp_state");
> + if (seven_seg_disp_class == NULL)
> + goto unreg_chrdev;
> +
> +unreg_chrdev:
> + unregister_chrdev_region(seven_seg_devno, 1);
> + return -1;
Do not use return -1 in kernel code.
(Look up what an errno value of '1' means. Negative values returned from
functions are interpreted as negated errno values.)
Always propagate error codes, or select an appropriate errno value to
return.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 2/2] ARM: soft-reboot into same mode that we entered the kernel
From: Russell King - ARM Linux @ 2016-12-14 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214121747.GH17982@leverpostej>
On Wed, Dec 14, 2016 at 12:17:47PM +0000, Mark Rutland wrote:
> On Wed, Dec 14, 2016 at 12:05:41PM +0000, Russell King - ARM Linux wrote:
> > The issue here is that a panic can happen at any time from any context
> > with any hyp stub in place, so there _needs_ to be a uniform way to do
> > this. It's very bad that we've got this far without this point having
> > been considered - all we can do right now is to try and fix the issues
> > as they come up.
> >
> > Right now, let's fix this so we get some kind of improvement, and later
> > try to sort out some kind of uniform interface for this task.
>
> Sure, that's a bigger task, and this is definitely a step in the right
> direction.
>
> We need to avoid the kdump regression somehow though; can we somehow
> detect if KVM is active and avoid issuing the HVC_SOFT_RESTART?
That's a question for KVM people.
However, there's a bigger question, which is: what do we want to happen
in the case of kdump - do we want to be entering the kdump kernel in
HYP or SVC mode? As the kdump kernel exists to be able to save the
state of a crashing system, the kdump kernel should do that and then
restart the system in a clean way (iow, not via yet another kexec.)
So maybe the right answer is that kdump should always invoke the kernel
in SVC mode.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] n900 device tree: cleanup
From: Pali Rohár @ 2016-12-14 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207031048.pi7j4dms5uuco3yf@earth>
On Wednesday 07 December 2016 04:10:48 Sebastian Reichel wrote:
> Hi Tony,
>
> It looks like this fell through the cracks. Apart from inconsistent
> patch subject:
>
> Reviewed-By: Sebastian Reichel <sre@kernel.org>
Fine for me too. Reviewed-By: Pali Roh?r <pali.rohar@gmail.com>
> -- Sebastian
>
> On Tue, Oct 11, 2016 at 10:12:43AM +0200, Pavel Machek wrote:
> > Fix GPIO comment to be consistent with rest of file and add comment
> > what tpa6130 is.
> >
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> >
> > diff --git a/arch/arm/boot/dts/omap3-n900.dts
> > b/arch/arm/boot/dts/omap3-n900.dts index bfffd6c..ca9fe8c 100644
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -47,7 +47,7 @@
> >
> > compatible = "gpio-leds";
> > heartbeat {
> >
> > label = "debug::sleep";
> >
> > - gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* gpio162 */
> > + gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* 162 */
> >
> > linux,default-trigger = "default-on";
> > pinctrl-names = "default";
> > pinctrl-0 = <&debug_leds>;
> >
> > @@ -637,6 +637,7 @@
> >
> > reg = <0x55>;
> >
> > };
> >
> > + /* Stereo headphone amplifier */
> >
> > tpa6130a2: tpa6130a2 at 60 {
> >
> > compatible = "ti,tpa6130a2";
> > reg = <0x60>;
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/38ca0953/attachment.sig>
^ permalink raw reply
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Pali Rohár @ 2016-12-14 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019092506.GA1461@amd>
On Wednesday 19 October 2016 11:25:06 Pavel Machek wrote:
> 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.gi
> t 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 at 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:~$
In log are still some failures, but ... is bluetooth working now?
I see that you applied this patch:
https://git.kernel.org/cgit/linux/kernel/git/pavel/linux-n900.git/commit/?id=051aa3fbf03ac770d8344690f5a936a7f04c6884
Looks like that pinmux is in DTS file incorrect. Can somebody verify it?
Maybe Tony?
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/d223c86e/attachment.sig>
^ permalink raw reply
* [GIT PULL] arm64 updates for 4.10
From: Catalin Marinas @ 2016-12-14 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFxxJy_xkGva8uX8LeFaBgb48mRpO05sJdGveBvRnK0uvg@mail.gmail.com>
On Tue, Dec 13, 2016 at 04:58:33PM -0800, Linus Torvalds wrote:
> On Tue, Dec 13, 2016 at 11:21 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> >
> > Please pull the arm64 updates for 4.10 below.
>
> Mind checking that I got the conflict resolution right?
>
> The conflict looked completely trivial, but with stuff moving across
> files and since I don't build the end result (much less boot it) I
> could easily have missed some screw-up of mine.
The conflict resolution is fine. Sorry, I forgot to mention it in the
pull request.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: Pratyush Anand @ 2016-12-14 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214113701.GE17982@leverpostej>
On Wednesday 14 December 2016 05:07 PM, Mark Rutland wrote:
> On Wed, Dec 14, 2016 at 11:16:17AM +0000, James Morse wrote:
>> Hi Pratyush,
>>
>> On 14/12/16 10:12, Pratyush Anand wrote:
>>> On Wednesday 14 December 2016 03:08 PM, Pratyush Anand wrote:
>>>>> I would go as far as to generate the page tables at 'kexec -l' time,
>>>>> and only if
>>>>
>>>> Ok..So you mean that I create a new section which will have page table
>>>> entries mapping physicalmemory represented by remaining section, and
>>>> then purgatory can just enable mmu with page table from that section,
>>>> right? Seems doable. can do that.
>>>
>>> I see a problem here. If we create page table as a new segment then, how can we
>>> verify in purgatory that sha for page table is correct? We need page table
>>> before sha verification start,and we can not rely the page table created by
>>> first kernel until it's sha is verified. So a chicken-egg problem.
>>
>> There is more than one of those! What happens if your sha256 calculation code is
>> corrupted? You have to run it before you know. The same goes for all the
>> purgatory code.
>>
>> This is why I think its better to do this in the kernel before we exit to
>> purgatory, but obviously that doesn't work for kdump.
>
> I see in an earlier message that the need for sha256 was being discussed
> in another thread. Do either of you happen to have a pointer to that.
>
patch 0/2 of this series.
> To me, it seems like it doesn't come with much benefit for the kdump
> case given that's best-effort anyway, and as above the verification code
> could have been be corrupted. In the non-kdump case it's not strictly
> necessary and seems like a debugging aid rather than a necessary piece
> of functionality -- if that's the case, a 20 second delay isn't the end
> of the world...
Even for the non-kdump ie `kexec -l` case we do not have a functionality
to bypass sha verification in kexec-tools. --lite option with the
kexec-tools was discouraged and not accepted. So,it is 20s for both
`kexec -l` and `kexec -p`.
Also other arch like x86_64 takes negligible time in sha verification.
~Pratyush
^ permalink raw reply
* [PATCH 2/2] ARM: soft-reboot into same mode that we entered the kernel
From: Mark Rutland @ 2016-12-14 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214120541.GD14217@n2100.armlinux.org.uk>
On Wed, Dec 14, 2016 at 12:05:41PM +0000, Russell King - ARM Linux wrote:
> On Wed, Dec 14, 2016 at 11:56:49AM +0000, Mark Rutland wrote:
> > On Wed, Dec 14, 2016 at 10:46:35AM +0000, Russell King wrote:
> > > When we soft-reboot (eg, kexec) from one kernel into the next, we need
> > > to ensure that we enter the new kernel in the same processor mode as
> > > when we were entered, so that (eg) the new kernel can install its own
> > > hypervisor - the old kernel's hypervisor will have been overwritten.
> > >
> > > In order to do this, we need to pass a flag to cpu_reset() so it knows
> > > what to do, and we need to modify the kernel's own hypervisor stub to
> > > allow it to handle a soft-reboot.
> > >
> > > As we are always guaranteed to install our own hypervisor if we're
> > > entered in HYP32 mode, and KVM will have moved itself out of the way
> > > on kexec/normal reboot, we can assume that our hypervisor is in place
> > > when we want to kexec, so changing our hypervisor API should not be a
> > > problem.
> >
> > Just to check, does that also hold true for kdump?
> >
> > I haven't gone digging yet, but it looks like KVM might still be
> > installed, rather than the hyp stub, and we might need some logic to
> > ensure that it's torn down...
>
> The same problem will be true of ARM64 - I don't see any solution to
> that in the present state.
Sure. We don't have kdump suppoort yet, and I intend for that to be
addressed before kdump support is merged.
> > > @@ -51,7 +52,9 @@ static void __soft_restart(void *addr)
> > >
> > > /* Switch to the identity mapping. */
> > > phys_reset = (phys_reset_t)virt_to_idmap(cpu_reset);
> > > - phys_reset((unsigned long)addr);
> > > +
> > > + /* original stub should be restored by kvm */
> > > + phys_reset((unsigned long)addr, is_hyp_mode_available());
> >
> > ... otherwise here we'd call into the KVM hyp code in a potentially
> > confusing manner.
> >
> > Otherwise, this looks fine to me.
>
> The only thing that I can think which would resolve that would be to
> lay down a standard API for the hyp code, so things like reboot into
> hyp mode can work irrespective of the hyp stub in place.
Sure; having the KVM hyp code also implement HVC_SOFT_RESTART seems
sensible. This would also work for arm64.
> The issue here is that a panic can happen at any time from any context
> with any hyp stub in place, so there _needs_ to be a uniform way to do
> this. It's very bad that we've got this far without this point having
> been considered - all we can do right now is to try and fix the issues
> as they come up.
>
> Right now, let's fix this so we get some kind of improvement, and later
> try to sort out some kind of uniform interface for this task.
Sure, that's a bigger task, and this is definitely a step in the right
direction.
We need to avoid the kdump regression somehow though; can we somehow
detect if KVM is active and avoid issuing the HVC_SOFT_RESTART?
Thanks,
Mark.
^ permalink raw reply
* [RFC PATCH] Memory hotplug support for arm64 platform
From: Maciej Bielski @ 2016-12-14 12:16 UTC (permalink / raw)
To: linux-arm-kernel
This patch relates to the work previously announced in [1]. This builds on the
work by Scott Branden [2] and, henceforth, it needs to be applied on top of
Scott's patches [2]. Comments are very welcome.
Changes from the original patchset and known issues:
- Compared to Scott's original patchset, this work adds the mapping of
the new hotplugged pages into the kernel page tables. This is done by
copying the old swapper_pg_dir over a new page, adding the new mappings,
and then switching to the newly built pg_dir (see `hotplug_paging` in
arch/arm64/mmu.c). There might be better ways to to this: suggestions
are more than welcome.
- The stub function for `arch_remove_memory` has been removed for now; we
are working in parallel on memory hot remove, and we plan to contribute
it as a separate patch.
- Corresponding Kconfig flags have been added;
- Note that this patch does not work when NUMA is enabled; in fact,
the function `memory_add_physaddr_to_nid` does not have an
implementation when the NUMA flag is on: this function is supposed to
return the nid the hotplugged memory should be associated with. However
it is not really clear to us yet what the semantics of this function
in the context of a NUMA system should be. A quick and dirty fix would
be to always attach to the first available NUMA node.
- In arch/arm64/mm/init.c `arch_add_memory`, we are doing a hack with the
nomap memory block flags to satisfy preconditions and postconditions of
`__add_pages` and postconditions of `arch_add_memory`. Compared to
memory hotplug implementation for other architectures, the "issue"
seems to be in the implemenation of `pfn_valid`. Suggestions on how
to cleanly avoid this hack are welcome.
This patchset can be tested by starting the kernel with the `mem=X` flag, where
X is less than the total available physical memory and has to be multiple of
MIN_MEMORY_BLOCK_SIZE. We also tested it on a customised version of QEMU
capable to emulate physical hotplug on arm64 platform.
To enable the feature the CONFIG_MEMORY_HOTPLUG compilation flag
needs to be set to true. Then, after memory is physically hotplugged,
the standard two steps to make it available (as also documented in
Documentation/memory-hotplug.txt) are:
(1) Notify memory hot-add
echo '0xYY000000' > /sys/devices/system/memory/probe
where 0xYY000000 is the first physical address of the new memory section.
(2) Online new memory block(s)
echo online > /sys/devices/system/memory/memoryXXX/state
where XXX corresponds to the ids of newly added blocks.
Onlining can optionally be automatic at hot-add notification by enabling
the global flag:
echo online > /sys/devices/system/memory/auto_online_blocks
or by setting the corresponding config flag in the kernel build.
Again, any comment is highly appreciated.
[1] https://lkml.org/lkml/2016/11/17/49
[2] https://lkml.org/lkml/2016/12/1/811
Signed-off-by: Maciej Bielski <m.bielski@virtualopensystems.com>
Signed-off-by: Andrea Reale <ar@linux.vnet.ibm.com>
---
arch/arm64/Kconfig | 4 +--
arch/arm64/include/asm/mmu.h | 3 +++
arch/arm64/mm/init.c | 58 +++++++++++++++++++++++++++++++-------------
arch/arm64/mm/mmu.c | 24 ++++++++++++++++++
include/linux/memblock.h | 1 +
mm/memblock.c | 10 ++++++++
6 files changed, 80 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 2482fdd..bd8ddf2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -577,9 +577,7 @@ config HOTPLUG_CPU
can be controlled through /sys/devices/system/cpu.
config ARCH_ENABLE_MEMORY_HOTPLUG
- def_bool y
-
-config ARCH_ENABLE_MEMORY_HOTREMOVE
+ depends on !NUMA
def_bool y
# Common NUMA Features
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 8d9fce0..2499745 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -36,5 +36,8 @@ extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
unsigned long virt, phys_addr_t size,
pgprot_t prot, bool allow_block_mappings);
extern void *fixmap_remap_fdt(phys_addr_t dt_phys);
+#ifdef CONFIG_MEMORY_HOTPLUG
+extern void hotplug_paging(phys_addr_t start, phys_addr_t size);
+#endif
#endif
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 687d087..a7c740e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -544,37 +544,61 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
struct zone *zone;
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
+ unsigned long end_pfn = start_pfn + nr_pages;
+ unsigned long max_sparsemem_pfn = 1UL << (MAX_PHYSMEM_BITS-PAGE_SHIFT);
+ unsigned long pfn;
int ret;
+ if (end_pfn > max_sparsemem_pfn) {
+ pr_err("end_pfn too big");
+ return -1;
+ }
+ hotplug_paging(start, size);
+
+ /*
+ * Mark all the page range as unsuable.
+ * This is needed because __add_section (within __add_pages)
+ * wants pfn_valid to be false, and in arm64 pfn falid is implemented
+ * by just checking at the nomap flag for existing blocks
+ */
+ memblock_mark_nomap(start, size);
+
pgdat = NODE_DATA(nid);
zone = pgdat->node_zones +
zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
ret = __add_pages(nid, zone, start_pfn, nr_pages);
- if (ret)
- pr_warn("%s: Problem encountered in __add_pages() ret=%d\n",
- __func__, ret);
+ /*
+ * Make the pages usable after they have been added.
+ * This will make pfn_valid return true
+ */
+ memblock_clear_nomap(start, size);
- return ret;
-}
+ /*
+ * This is a hack to avoid having to mix arch specific code into arch
+ * independent code. SetPageReserved is supposed to be called by __add_zone
+ * (within __add_section, within __add_pages). However, when it is called
+ * there, it assumes that pfn_valid returns true. For the way pfn_valid is
+ * implemented in arm64 (a check on the nomap flag), the only way to make
+ * this evaluate true inside __add_zone is to clear the nomap flags of
+ * blocks in architecture independent code.
+ *
+ * To avoid this, we set the Reserved flag here after we cleared the nomap
+ * flag in the line above.
+ */
+ for (pfn = start_pfn; pfn < start_pfn + nr_pages; pfn++) {
+ if (!pfn_valid(pfn))
+ continue;
-#ifdef CONFIG_MEMORY_HOTREMOVE
-int arch_remove_memory(u64 start, u64 size)
-{
- unsigned long start_pfn = start >> PAGE_SHIFT;
- unsigned long nr_pages = size >> PAGE_SHIFT;
- struct zone *zone;
- int ret;
+ SetPageReserved(pfn_to_page(pfn));
+ }
- zone = page_zone(pfn_to_page(start_pfn));
- ret = __remove_pages(zone, start_pfn, nr_pages);
if (ret)
- pr_warn("%s: Problem encountered in __remove_pages() ret=%d\n",
+ pr_warn("%s: Problem encountered in __add_pages() ret=%d\n",
__func__, ret);
return ret;
}
#endif
-#endif
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 05615a3..9efa7d1 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -493,6 +493,30 @@ void __init paging_init(void)
SWAPPER_DIR_SIZE - PAGE_SIZE);
}
+#ifdef CONFIG_MEMORY_HOTPLUG
+/*
+ * hotplug_paging() is used by memory hotplug to build new page tables
+ * for hot added memory.
+ */
+void hotplug_paging(phys_addr_t start, phys_addr_t size)
+{
+ phys_addr_t pgd_phys = pgd_pgtable_alloc();
+ pgd_t *pgd = pgd_set_fixmap(pgd_phys);
+
+ memcpy(pgd, swapper_pg_dir, PAGE_SIZE);
+
+ __create_pgd_mapping(pgd, start, __phys_to_virt(start), size,
+ PAGE_KERNEL, pgd_pgtable_alloc, false);
+
+ cpu_replace_ttbr1(__va(pgd_phys));
+ memcpy(swapper_pg_dir, pgd, PAGE_SIZE);
+ cpu_replace_ttbr1(swapper_pg_dir);
+
+ pgd_clear_fixmap();
+ memblock_free(pgd_phys, PAGE_SIZE);
+}
+#endif
+
/*
* Check whether a kernel address is valid (derived from arch/x86/).
*/
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5b759c9..5f78257 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -92,6 +92,7 @@ int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
+int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
ulong choose_memblock_flags(void);
/* Low level functions */
diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..05e7676 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -814,6 +814,16 @@ int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
}
/**
+ * memblock_clear_nomap - Clear a flag of MEMBLOCK_NOMAP memory region
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ */
+int __init_memblock memblock_clear_nomap(phys_addr_t base, phys_addr_t size)
+{
+ return memblock_setclr_flag(base, size, 0, MEMBLOCK_NOMAP);
+}
+
+/**
* __next_reserved_mem_region - next function for for_each_reserved_region()
* @idx: pointer to u64 loop variable
* @out_start: ptr to phys_addr_t for start address of the region, can be %NULL
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: Pratyush Anand @ 2016-12-14 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58512A01.70101@arm.com>
Hi James,
Thanks for your input !!
On Wednesday 14 December 2016 04:46 PM, James Morse wrote:
> Hi Pratyush,
>
> On 14/12/16 10:12, Pratyush Anand wrote:
>> > On Wednesday 14 December 2016 03:08 PM, Pratyush Anand wrote:
>>>> >>> I would go as far as to generate the page tables at 'kexec -l' time,
>>>> >>> and only if
>>> >>
>>> >> Ok..So you mean that I create a new section which will have page table
>>> >> entries mapping physicalmemory represented by remaining section, and
>>> >> then purgatory can just enable mmu with page table from that section,
>>> >> right? Seems doable. can do that.
>> >
>> > I see a problem here. If we create page table as a new segment then, how can we
>> > verify in purgatory that sha for page table is correct? We need page table
>> > before sha verification start,and we can not rely the page table created by
>> > first kernel until it's sha is verified. So a chicken-egg problem.
> There is more than one of those! What happens if your sha256 calculation code is
> corrupted? You have to run it before you know. The same goes for all the
> purgatory code.
>
OK, seems reasonable... will do it in kexec code.
> This is why I think its better to do this in the kernel before we exit to
> purgatory, but obviously that doesn't work for kdump.
>
>
>> > I think, creating page table will just take fraction of second and should be
>> > good even in purgatory, What do you say?
> If it's for kdump its best-effort. I think its easier/simpler to generate and
> debug them at 'kexec -l' time, but if you're worried about the increased area
> that could be corrupted then do it in purgatory.
>
~Pratyush
^ permalink raw reply
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: James Morse @ 2016-12-14 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214113701.GE17982@leverpostej>
Hi Mark,
On 14/12/16 11:37, Mark Rutland wrote:
> On Wed, Dec 14, 2016 at 11:16:17AM +0000, James Morse wrote:
>> On 14/12/16 10:12, Pratyush Anand wrote:
>>> On Wednesday 14 December 2016 03:08 PM, Pratyush Anand wrote:
>>>>> I would go as far as to generate the page tables at 'kexec -l' time,
>>>>> and only if
>>>>
>>>> Ok..So you mean that I create a new section which will have page table
>>>> entries mapping physicalmemory represented by remaining section, and
>>>> then purgatory can just enable mmu with page table from that section,
>>>> right? Seems doable. can do that.
>>>
>>> I see a problem here. If we create page table as a new segment then, how can we
>>> verify in purgatory that sha for page table is correct? We need page table
>>> before sha verification start,and we can not rely the page table created by
>>> first kernel until it's sha is verified. So a chicken-egg problem.
>>
>> There is more than one of those! What happens if your sha256 calculation code is
>> corrupted? You have to run it before you know. The same goes for all the
>> purgatory code.
>>
>> This is why I think its better to do this in the kernel before we exit to
>> purgatory, but obviously that doesn't work for kdump.
>
> I see in an earlier message that the need for sha256 was being discussed
> in another thread. Do either of you happen to have a pointer to that.
https://www.spinics.net/lists/arm-kernel/msg544472.html
Thanks,
James
^ permalink raw reply
* [PATCH 2/2] ARM: soft-reboot into same mode that we entered the kernel
From: Russell King - ARM Linux @ 2016-12-14 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214115648.GG17982@leverpostej>
On Wed, Dec 14, 2016 at 11:56:49AM +0000, Mark Rutland wrote:
> On Wed, Dec 14, 2016 at 10:46:35AM +0000, Russell King wrote:
> > When we soft-reboot (eg, kexec) from one kernel into the next, we need
> > to ensure that we enter the new kernel in the same processor mode as
> > when we were entered, so that (eg) the new kernel can install its own
> > hypervisor - the old kernel's hypervisor will have been overwritten.
> >
> > In order to do this, we need to pass a flag to cpu_reset() so it knows
> > what to do, and we need to modify the kernel's own hypervisor stub to
> > allow it to handle a soft-reboot.
> >
> > As we are always guaranteed to install our own hypervisor if we're
> > entered in HYP32 mode, and KVM will have moved itself out of the way
> > on kexec/normal reboot, we can assume that our hypervisor is in place
> > when we want to kexec, so changing our hypervisor API should not be a
> > problem.
>
> Just to check, does that also hold true for kdump?
>
> I haven't gone digging yet, but it looks like KVM might still be
> installed, rather than the hyp stub, and we might need some logic to
> ensure that it's torn down...
The same problem will be true of ARM64 - I don't see any solution to
that in the present state.
> > @@ -51,7 +52,9 @@ static void __soft_restart(void *addr)
> >
> > /* Switch to the identity mapping. */
> > phys_reset = (phys_reset_t)virt_to_idmap(cpu_reset);
> > - phys_reset((unsigned long)addr);
> > +
> > + /* original stub should be restored by kvm */
> > + phys_reset((unsigned long)addr, is_hyp_mode_available());
>
> ... otherwise here we'd call into the KVM hyp code in a potentially
> confusing manner.
>
> Otherwise, this looks fine to me.
The only thing that I can think which would resolve that would be to
lay down a standard API for the hyp code, so things like reboot into
hyp mode can work irrespective of the hyp stub in place.
The issue here is that a panic can happen at any time from any context
with any hyp stub in place, so there _needs_ to be a uniform way to do
this. It's very bad that we've got this far without this point having
been considered - all we can do right now is to try and fix the issues
as they come up.
Right now, let's fix this so we get some kind of improvement, and later
try to sort out some kind of uniform interface for this task.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 2/2] ARM: soft-reboot into same mode that we entered the kernel
From: Mark Rutland @ 2016-12-14 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cH751-0003kk-Ts@rmk-PC.armlinux.org.uk>
On Wed, Dec 14, 2016 at 10:46:35AM +0000, Russell King wrote:
> When we soft-reboot (eg, kexec) from one kernel into the next, we need
> to ensure that we enter the new kernel in the same processor mode as
> when we were entered, so that (eg) the new kernel can install its own
> hypervisor - the old kernel's hypervisor will have been overwritten.
>
> In order to do this, we need to pass a flag to cpu_reset() so it knows
> what to do, and we need to modify the kernel's own hypervisor stub to
> allow it to handle a soft-reboot.
>
> As we are always guaranteed to install our own hypervisor if we're
> entered in HYP32 mode, and KVM will have moved itself out of the way
> on kexec/normal reboot, we can assume that our hypervisor is in place
> when we want to kexec, so changing our hypervisor API should not be a
> problem.
Just to check, does that also hold true for kdump?
I haven't gone digging yet, but it looks like KVM might still be
installed, rather than the hyp stub, and we might need some logic to
ensure that it's torn down...
[...]
> @@ -51,7 +52,9 @@ static void __soft_restart(void *addr)
>
> /* Switch to the identity mapping. */
> phys_reset = (phys_reset_t)virt_to_idmap(cpu_reset);
> - phys_reset((unsigned long)addr);
> +
> + /* original stub should be restored by kvm */
> + phys_reset((unsigned long)addr, is_hyp_mode_available());
... otherwise here we'd call into the KVM hyp code in a potentially
confusing manner.
Otherwise, this looks fine to me.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] ARM: hyp-stub: improve ABI
From: Mark Rutland @ 2016-12-14 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cH74w-0003ke-Qp@rmk-PC.armlinux.org.uk>
On Wed, Dec 14, 2016 at 10:46:30AM +0000, Russell King wrote:
> Improve the hyp-stub ABI to allow it to do more than just get/set the
> vectors. We follow the example in ARM64, where r0 is used as an opcode
> with the other registers as an argument.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
This looks good to me, though I'd suggest s/ABI/calling convention/, as
this isn't strictly speaking an ABI. So FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm/kernel/hyp-stub.S | 27 ++++++++++++++++++++++-----
> 1 file changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
> index 15d073ae5da2..f3e9ba5fb642 100644
> --- a/arch/arm/kernel/hyp-stub.S
> +++ b/arch/arm/kernel/hyp-stub.S
> @@ -22,6 +22,9 @@
> #include <asm/assembler.h>
> #include <asm/virt.h>
>
> +#define HVC_GET_VECTORS 0
> +#define HVC_SET_VECTORS 1
> +
> #ifndef ZIMAGE
> /*
> * For the kernel proper, we need to find out the CPU boot mode long after
> @@ -202,9 +205,19 @@ ARM_BE8(orr r7, r7, #(1 << 25)) @ HSCTLR.EE
> ENDPROC(__hyp_stub_install_secondary)
>
> __hyp_stub_do_trap:
> - cmp r0, #-1
> - mrceq p15, 4, r0, c12, c0, 0 @ get HVBAR
> - mcrne p15, 4, r0, c12, c0, 0 @ set HVBAR
> + teq r0, #HVC_GET_VECTORS
> + bne 1f
> + mrc p15, 4, r0, c12, c0, 0 @ get HVBAR
> + b __hyp_stub_exit
> +
> +1: teq r0, #HVC_SET_VECTORS
> + bne 1f
> + mcr p15, 4, r1, c12, c0, 0 @ set HVBAR
> + b __hyp_stub_exit
> +
> +1: mov r0, #-1
> +
> +__hyp_stub_exit:
> __ERET
> ENDPROC(__hyp_stub_do_trap)
>
> @@ -231,10 +244,14 @@ ENDPROC(__hyp_stub_do_trap)
> * initialisation entry point.
> */
> ENTRY(__hyp_get_vectors)
> - mov r0, #-1
> + mov r0, #HVC_GET_VECTORS
> + __HVC(0)
> + ret lr
> ENDPROC(__hyp_get_vectors)
> - @ fall through
> +
> ENTRY(__hyp_set_vectors)
> + mov r1, r0
> + mov r0, #HVC_SET_VECTORS
> __HVC(0)
> ret lr
> ENDPROC(__hyp_set_vectors)
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH linux v1 4/4] arm: dts: Add dt-binding to support seven segment display on zaius
From: Russell King - ARM Linux @ 2016-12-14 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214110635.GB14217@n2100.armlinux.org.uk>
On Wed, Dec 14, 2016 at 11:06:35AM +0000, Russell King - ARM Linux wrote:
> On Wed, Dec 14, 2016 at 10:00:46AM +0100, Arnd Bergmann wrote:
> > On Wednesday, December 14, 2016 9:55:47 AM CET Arnd Bergmann wrote:
> > > According to your introductory mail, the interface is assumed to be
> > > a 74HC164. Should we use that ID in the compatible string?
> > >
> > > We can always add other strings later if we want to support multiple
> > > wire formats.
> >
> > Actually, looking up 74hc164, that seems to be a gpio expander,
> > so maybe a more flexible way to do the same is to put a driver
> > for the expander into drivers/gpio/ and have the main driver
> > access the outputs of that using the gpiolib interface.
>
> There already is - drivers/gpio/gpio-74x164.c
Looking at this more, it's a SPI driver, presumably because the first
case where it appeared was on a SPI bus.
However, it's not a SPI device as such, it's a piece of standard,
general purpose logic that's been around for many years, pre-dating
the SPI bus.
Now, as for DT, we have this "DT represents the hardware, not the
implementation" edict, which now brings up an interesting problem.
If we want to use this driver in its existing form, we need to:
- declare in DT a spi-gpio driver to provide a SPI bus on the GPIO
pins connected to the 74HC164.
- attach the 74HC164 to the SPI bus.
The problem with that is it's not representative of the hardware -
what we're saying is that we want to reuse our existing implementation
and make DT conform to the implementation. At that point, we might as
well scrap our "DT is implementation independent" edict above.
What if, tomorrow, we end up with 74HC164 connected to via a different
method?
I think a much more sensible approach would be to turn the GPIO side
of the 74x164 driver into a library, which can be re-used by multiple
bus-specific drivers - one for SPI which allows it to be used in its
current form, one for our platform bus which takes the GPIO lines for
the data, clock and clear signals.
I also don't see why they shouldn't use the same compatible - they're
the same _device_ at the end of the day, just wired up differently.
It makes the binding documentation a little fun wrt what are required
and optional properties, but nothing that shouldn't be too difficult.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: Mark Rutland @ 2016-12-14 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58512A01.70101@arm.com>
On Wed, Dec 14, 2016 at 11:16:17AM +0000, James Morse wrote:
> Hi Pratyush,
>
> On 14/12/16 10:12, Pratyush Anand wrote:
> > On Wednesday 14 December 2016 03:08 PM, Pratyush Anand wrote:
> >>> I would go as far as to generate the page tables at 'kexec -l' time,
> >>> and only if
> >>
> >> Ok..So you mean that I create a new section which will have page table
> >> entries mapping physicalmemory represented by remaining section, and
> >> then purgatory can just enable mmu with page table from that section,
> >> right? Seems doable. can do that.
> >
> > I see a problem here. If we create page table as a new segment then, how can we
> > verify in purgatory that sha for page table is correct? We need page table
> > before sha verification start,and we can not rely the page table created by
> > first kernel until it's sha is verified. So a chicken-egg problem.
>
> There is more than one of those! What happens if your sha256 calculation code is
> corrupted? You have to run it before you know. The same goes for all the
> purgatory code.
>
> This is why I think its better to do this in the kernel before we exit to
> purgatory, but obviously that doesn't work for kdump.
I see in an earlier message that the need for sha256 was being discussed
in another thread. Do either of you happen to have a pointer to that.
To me, it seems like it doesn't come with much benefit for the kdump
case given that's best-effort anyway, and as above the verification code
could have been be corrupted. In the non-kdump case it's not strictly
necessary and seems like a debugging aid rather than a necessary piece
of functionality -- if that's the case, a 20 second delay isn't the end
of the world...
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: Mark Rutland @ 2016-12-14 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <585129F7.6070704@arm.com>
On Wed, Dec 14, 2016 at 11:16:07AM +0000, James Morse wrote:
> Hi Pratyush,
> On 14/12/16 09:38, Pratyush Anand wrote:
> > On Saturday 26 November 2016 12:00 AM, James Morse wrote:
> >> On 22/11/16 04:32, Pratyush Anand wrote:
> >>> +/*
> >>> + * disable_dcache: Disable D-cache and flush RAM locations
> >>> + * ram_start - Start address of RAM
> >>> + * ram_end - End address of RAM
> >>> + */
> >>> +void disable_dcache(uint64_t ram_start, uint64_t ram_end)
> >>> +{
> >>> + switch(get_current_el()) {
> >>> + case 2:
> >>> + reset_sctlr_el2();
> >>> + break;
> >>> + case 1:
> >>> + reset_sctlr_el1();
> >>
> >> You have C code running between disabling the MMU and cleaning the cache. The
> >> compiler is allowed to move data on and off the stack in here, but after
> >> disabling the MMU it will see whatever was on the stack before we turned the MMU
> >> on. Any data written at the beginning of this function is left in the caches.
> >>
> >> I'm afraid this sort of stuff needs to be done in assembly!
> >
> > All these routines are self coded in assembly even though they are called
> > from C, so should be safe I think. Anyway, I can keep all of them in
> > assembly as well.
>
> You can't tell the compiler that the stack data is inaccessible until the dcache
> clean call completes. Some future version may do really crazy things in here.
> You can decompile what your compiler version produces to check it doesn't
> load/store to the stack, but that doesn't mean my compiler version does the
> same. This is the kind of thing that is extremely difficult to debug, its best
> not to take the risk.
FWIW, I completely agree.
We've been bitten in the past; see commit 5e051531447259e5 ("arm64:
convert part of soft_restart() to assembly") for an example.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v7] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Ard Biesheuvel @ 2016-12-14 11:20 UTC (permalink / raw)
To: linux-arm-kernel
Currently, we allow kernel mode NEON in softirq or hardirq context by
stacking and unstacking a slice of the NEON register file for each call
to kernel_neon_begin() and kernel_neon_end(), respectively.
Given that
a) a CPU typically spends most of its time in userland, during which time
no kernel mode NEON in process context is in progress,
b) a CPU spends most of its time in the kernel doing other things than
kernel mode NEON when it gets interrupted to perform kernel mode NEON
in softirq context
the stacking and subsequent unstacking is only necessary if we are
interrupting a thread while it is performing kernel mode NEON in process
context, which means that in all other cases, we can simply preserve the
userland FP/SIMD state once, and only restore it upon return to userland,
even if we are being invoked from softirq or hardirq context.
However, with support being added to teh arm64 kernel for Scalable Vector
Extensions (SVE), which shares the bottom 128 bits of each FP/SIMD register,
but could scale up to 2048 bits per register, the nested stacking and
unstacking that occurs in interrupt context is no longer sufficient, given
that the register contents will be truncated to 128 bits upon restore, unless
we add support for stacking/unstacking the entire SVE state, which does not
sound that appealing.
This means that the FP/SIMD save state operation that encounters the
userland state first *has* to be able to run to completion (since any
interruption could truncate the contents of the registers, which would
result in corrupted state to be restored once the interrupted context is
allowed to resume preserving the state)
Since executing all code involving the FP/SIMD state with interrupts
disabled is undesirable, let's ban kernel mode NEON in hardirq context
altogether. This is a small price to pay, given that the primary use
case of kernel mode NEON, crypto, can deal with this quite easily (and
simply falls back to generic scalar algorithms whose worse performance
should not matter in hardirq context anyway)
With hardirq context removed from the equation, we can modify the FP/SIMD
state manipulation code to execute with softirqs disable. This allows the
critical sections to complete without the risk of having the register
contents getting corrupted half way through.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
v7:
- ban kernel mode NEON in hardirq context, and execute all FP/SIMD state
manipulations with softirqs disabled
v6:
- use a spinlock instead of disabling interrupts
v5:
- perform the test-and-set and the fpsimd_save_state with interrupts disabled,
to prevent nested kernel_neon_begin()/_end() pairs to clobber the state
while it is being preserved
v4:
- use this_cpu_inc/dec, which give sufficient guarantees regarding
concurrency, but do not imply SMP barriers, which are not needed here
v3:
- avoid corruption by concurrent invocations of kernel_neon_begin()/_end()
v2:
- BUG() on unexpected values of the nesting level
- relax the BUG() on num_regs>32 to a WARN, given that nothing actually
breaks in that case
arch/arm64/include/asm/Kbuild | 1 -
arch/arm64/include/asm/simd.h | 16 ++++
arch/arm64/kernel/fpsimd.c | 77 ++++++++++++++------
3 files changed, 72 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 44e1d7f10add..39ca0409e157 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -33,7 +33,6 @@ generic-y += segment.h
generic-y += sembuf.h
generic-y += serial.h
generic-y += shmbuf.h
-generic-y += simd.h
generic-y += sizes.h
generic-y += socket.h
generic-y += sockios.h
diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h
new file mode 100644
index 000000000000..142eca29125a
--- /dev/null
+++ b/arch/arm64/include/asm/simd.h
@@ -0,0 +1,16 @@
+
+#include <linux/hardirq.h>
+
+/*
+ * may_use_simd - whether it is allowable at this time to issue SIMD
+ * instructions or access the SIMD register file
+ *
+ * On arm64, we allow kernel mode NEON in softirq context but not in hardirq
+ * context, due to the fact that the NEON register file may be shared with SVE,
+ * whose state may too large to preserve/restore efficiently at each invocation
+ * of kernel_neon_begin()/_end() in hardirq context.
+ */
+static __must_check inline bool may_use_simd(void)
+{
+ return !in_irq();
+}
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 394c61db5566..97344c94acae 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -127,6 +127,8 @@ void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
void fpsimd_thread_switch(struct task_struct *next)
{
+ BUG_ON(!irqs_disabled());
+
/*
* Save the current FPSIMD state to memory, but only if whatever is in
* the registers is in fact the most recent userland FPSIMD state of
@@ -169,8 +171,10 @@ void fpsimd_flush_thread(void)
void fpsimd_preserve_current_state(void)
{
preempt_disable();
+ local_bh_disable();
if (!test_thread_flag(TIF_FOREIGN_FPSTATE))
fpsimd_save_state(¤t->thread.fpsimd_state);
+ local_bh_enable();
preempt_enable();
}
@@ -182,6 +186,7 @@ void fpsimd_preserve_current_state(void)
void fpsimd_restore_current_state(void)
{
preempt_disable();
+ local_bh_disable();
if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
struct fpsimd_state *st = ¤t->thread.fpsimd_state;
@@ -189,6 +194,7 @@ void fpsimd_restore_current_state(void)
this_cpu_write(fpsimd_last_state, st);
st->cpu = smp_processor_id();
}
+ local_bh_enable();
preempt_enable();
}
@@ -200,6 +206,7 @@ void fpsimd_restore_current_state(void)
void fpsimd_update_current_state(struct fpsimd_state *state)
{
preempt_disable();
+ local_bh_disable();
fpsimd_load_state(state);
if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
struct fpsimd_state *st = ¤t->thread.fpsimd_state;
@@ -207,6 +214,7 @@ void fpsimd_update_current_state(struct fpsimd_state *state)
this_cpu_write(fpsimd_last_state, st);
st->cpu = smp_processor_id();
}
+ local_bh_enable();
preempt_enable();
}
@@ -220,45 +228,68 @@ void fpsimd_flush_task_state(struct task_struct *t)
#ifdef CONFIG_KERNEL_MODE_NEON
-static DEFINE_PER_CPU(struct fpsimd_partial_state, hardirq_fpsimdstate);
-static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
+static DEFINE_PER_CPU(struct fpsimd_partial_state, nested_fpsimdstate);
+static DEFINE_PER_CPU(int, kernel_neon_nesting_level);
/*
* Kernel-side NEON support functions
*/
void kernel_neon_begin_partial(u32 num_regs)
{
- if (in_interrupt()) {
- struct fpsimd_partial_state *s = this_cpu_ptr(
- in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
+ int level;
- BUG_ON(num_regs > 32);
- fpsimd_save_partial_state(s, roundup(num_regs, 2));
- } else {
+ /*
+ * We don't allow kernel mode NEON in hard IRQ context because we'd
+ * have to assume that any sequence involving preserve/restore of the
+ * FP/SIMD register file could be interrupted by nested use of the NEON.
+ *
+ * On SVE capable hardware, that would necessitate executing all
+ * manipulation of the preserved FP/SIMD state with interrupts disabled,
+ * unless we preserve/restore the *entire* SVE state in interrupt
+ * context as well.
+ */
+ BUG_ON(in_irq());
+
+ preempt_disable();
+ if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE)) {
/*
* Save the userland FPSIMD state if we have one and if we
* haven't done so already. Clear fpsimd_last_state to indicate
* that there is no longer userland FPSIMD state in the
* registers.
*/
- preempt_disable();
- if (current->mm &&
- !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
+ local_bh_disable();
+ if (!test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
fpsimd_save_state(¤t->thread.fpsimd_state);
- this_cpu_write(fpsimd_last_state, NULL);
+ local_bh_enable();
+ }
+ this_cpu_write(fpsimd_last_state, NULL);
+
+ level = this_cpu_inc_return(kernel_neon_nesting_level);
+ BUG_ON(level > 2);
+
+ if (level > 1) {
+ WARN_ON_ONCE(num_regs > 32);
+ num_regs = max(roundup(num_regs, 2), 32U);
+
+ fpsimd_save_partial_state(this_cpu_ptr(&nested_fpsimdstate),
+ num_regs);
}
}
EXPORT_SYMBOL(kernel_neon_begin_partial);
void kernel_neon_end(void)
{
- if (in_interrupt()) {
- struct fpsimd_partial_state *s = this_cpu_ptr(
- in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
- fpsimd_load_partial_state(s);
- } else {
- preempt_enable();
- }
+ int level;
+
+ level = this_cpu_read(kernel_neon_nesting_level);
+ BUG_ON(level < 1);
+
+ if (level > 1)
+ fpsimd_load_partial_state(this_cpu_ptr(&nested_fpsimdstate));
+
+ this_cpu_dec(kernel_neon_nesting_level);
+ preempt_enable();
}
EXPORT_SYMBOL(kernel_neon_end);
@@ -270,8 +301,12 @@ static int fpsimd_cpu_pm_notifier(struct notifier_block *self,
{
switch (cmd) {
case CPU_PM_ENTER:
- if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE))
- fpsimd_save_state(¤t->thread.fpsimd_state);
+ if (current->mm) {
+ local_bh_disable();
+ if (!test_thread_flag(TIF_FOREIGN_FPSTATE))
+ fpsimd_save_state(¤t->thread.fpsimd_state);
+ local_bh_enable();
+ }
this_cpu_write(fpsimd_last_state, NULL);
break;
case CPU_PM_EXIT:
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: James Morse @ 2016-12-14 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9a79b666-7990-2a23-2d74-52b3317ce272@redhat.com>
Hi Pratyush,
On 14/12/16 10:12, Pratyush Anand wrote:
> On Wednesday 14 December 2016 03:08 PM, Pratyush Anand wrote:
>>> I would go as far as to generate the page tables at 'kexec -l' time,
>>> and only if
>>
>> Ok..So you mean that I create a new section which will have page table
>> entries mapping physicalmemory represented by remaining section, and
>> then purgatory can just enable mmu with page table from that section,
>> right? Seems doable. can do that.
>
> I see a problem here. If we create page table as a new segment then, how can we
> verify in purgatory that sha for page table is correct? We need page table
> before sha verification start,and we can not rely the page table created by
> first kernel until it's sha is verified. So a chicken-egg problem.
There is more than one of those! What happens if your sha256 calculation code is
corrupted? You have to run it before you know. The same goes for all the
purgatory code.
This is why I think its better to do this in the kernel before we exit to
purgatory, but obviously that doesn't work for kdump.
> I think, creating page table will just take fraction of second and should be
> good even in purgatory, What do you say?
If it's for kdump its best-effort. I think its easier/simpler to generate and
debug them at 'kexec -l' time, but if you're worried about the increased area
that could be corrupted then do it in purgatory.
Thanks,
James
^ permalink raw reply
* [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
From: James Morse @ 2016-12-14 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d8f354da-1e61-feaf-f76a-18e90361e98b@redhat.com>
Hi Pratyush,
On 14/12/16 09:38, Pratyush Anand wrote:
> On Saturday 26 November 2016 12:00 AM, James Morse wrote:
>> On 22/11/16 04:32, Pratyush Anand wrote:
>>> This patch adds support to enable/disable d-cache, which can be used for
>>> faster purgatory sha256 verification.
>>
>> (I'm not clear why we want the sha256, but that is being discussed elsewhere on
>> the thread)
>>
>>
>>> We are supporting only 4K and 64K page sizes. This code will not work if a
>>> hardware is not supporting at least one of these page sizes. Therefore,
>>> D-cache is disabled by default and enabled only when "enable-dcache" is
>>> passed to the kexec().
>>
>> I don't think the maybe-4K/maybe-64K/maybe-neither logic is needed. It would be
>> a lot simpler to only support one page size, which should be 4K as that is what
>> UEFI requires. (If there are CPUs that only support one size, I bet its 4K!)
>
> Ok.. So, I will implement a new version after considering that 4K will always be
> supported. If 4K is not supported by hw(which is very unlikely) then there would
> be no d-cache enabling feature.
Sounds good tom me. I think its important to keep the purgatory code as small
and as simple as possible as its very hard to debug. If we do get bug reports
they are likely to be 'it didn't nothing', with no further details. If it only
fails on some platform we don't have access to its basically impossible.
>> I would go as far as to generate the page tables at 'kexec -l' time, and only if
>
> Ok..So you mean that I create a new section which will have page table entries
> mapping physicalmemory represented by remaining section, and then purgatory can
> just enable mmu with page table from that section, right? Seems doable. can do
> that.
>
>> '/sys/firmware/efi' exists to indicate we booted via UEFI. (and therefore must
>> support 4K pages). This would keep the purgatory code as simple as possible.
>
> What about reading ID_AA64MMFR0_EL1 instead of /sys/firmware/efi? That can also
> tell us that whether 4K is supported or not?
If you're doing it at EL1/EL2 in the purgatory code, sure. But if you generate
the page tables at 'kexec -l' time you can't read this register from EL0 so you
need another way to guess if 4K pages are supported (or just assume they are and
test that register once you're in purgatory).
I was looking for some way to print a message at 'kexec -l' time that the sha256
would be slow as 4K wasn't supported. (a message printed at any other time won't
get seen).
>>> +/*
>>> + * disable_dcache: Disable D-cache and flush RAM locations
>>> + * ram_start - Start address of RAM
>>> + * ram_end - End address of RAM
>>> + */
>>> +void disable_dcache(uint64_t ram_start, uint64_t ram_end)
>>> +{
>>> + switch(get_current_el()) {
>>> + case 2:
>>> + reset_sctlr_el2();
>>> + break;
>>> + case 1:
>>> + reset_sctlr_el1();
>>
>> You have C code running between disabling the MMU and cleaning the cache. The
>> compiler is allowed to move data on and off the stack in here, but after
>> disabling the MMU it will see whatever was on the stack before we turned the MMU
>> on. Any data written at the beginning of this function is left in the caches.
>>
>> I'm afraid this sort of stuff needs to be done in assembly!
>
> All these routines are self coded in assembly even though they are called
> from C, so should be safe I think. Anyway, I can keep all of them in
> assembly as well.
You can't tell the compiler that the stack data is inaccessible until the dcache
clean call completes. Some future version may do really crazy things in here.
You can decompile what your compiler version produces to check it doesn't
load/store to the stack, but that doesn't mean my compiler version does the
same. This is the kind of thing that is extremely difficult to debug, its best
not to take the risk.
Thanks,
James
^ permalink raw reply
* [PATCH linux v1 4/4] arm: dts: Add dt-binding to support seven segment display on zaius
From: Russell King - ARM Linux @ 2016-12-14 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10697525.O7CkPN6Gfl@wuerfel>
On Wed, Dec 14, 2016 at 10:00:46AM +0100, Arnd Bergmann wrote:
> On Wednesday, December 14, 2016 9:55:47 AM CET Arnd Bergmann wrote:
> > According to your introductory mail, the interface is assumed to be
> > a 74HC164. Should we use that ID in the compatible string?
> >
> > We can always add other strings later if we want to support multiple
> > wire formats.
>
> Actually, looking up 74hc164, that seems to be a gpio expander,
> so maybe a more flexible way to do the same is to put a driver
> for the expander into drivers/gpio/ and have the main driver
> access the outputs of that using the gpiolib interface.
There already is - drivers/gpio/gpio-74x164.c
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: dts: dra72-evm-tps65917: Add voltage supplies to usb_phy, mmc, dss
From: Roger Quadros @ 2016-12-14 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214085703.506-1-lokeshvutla@ti.com>
Lokesh,
On 14/12/16 10:57, Lokesh Vutla wrote:
> Commit 5d080aa30681 ("ARM: dts: dra72: Add separate dtsi for tps65917")
> added a separate dtsi for dra72-evm-tps65917 moving all the voltage supplies
> to this file. But it missed adding voltage supplies to usb_phy, mmc,
> dss and deleted from dra72-evm-common.dtsi. Adding the voltage supply
> phandles to these nodes in dra72-evm-tps65917.dtsi
>
> Fixes: 5d080aa30681 ("ARM: dts: dra72: Add separate dtsi for tps65917")
> Reported-by: Carlos Hernandez <ceh@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> Logs:
> - DRA72-evm revC: http://pastebin.ubuntu.com/23627665/
> - DRA72-evm revB: http://pastebin.ubuntu.com/23627658/
> arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
> index ee6dac44edf1..e6df676886c0 100644
> --- a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
> +++ b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
> @@ -132,3 +132,19 @@
> ti,palmas-long-press-seconds = <6>;
> };
> };
> +
> +&usb2_phy1 {
> + phy-supply = <&ldo4_reg>;
> +};
> +
> +&usb2_phy2 {
> + phy-supply = <&ldo4_reg>;
> +};
> +
> +&dss {
> + vdda_video-supply = <&ldo5_reg>;
> +};
> +
> +&mmc1 {
> + vmmc_aux-supply = <&ldo1_reg>;
> +};
>
Are you sure that all future users of dra72-evm-tps65917.dtsi will use this same configuration?
If not I'd rather put this in the board dts files.
cheers,
-roger
^ permalink raw reply
* [PATCH 2/2] ARM: soft-reboot into same mode that we entered the kernel
From: Russell King @ 2016-12-14 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213113044.GC19985@leverpostej>
When we soft-reboot (eg, kexec) from one kernel into the next, we need
to ensure that we enter the new kernel in the same processor mode as
when we were entered, so that (eg) the new kernel can install its own
hypervisor - the old kernel's hypervisor will have been overwritten.
In order to do this, we need to pass a flag to cpu_reset() so it knows
what to do, and we need to modify the kernel's own hypervisor stub to
allow it to handle a soft-reboot.
As we are always guaranteed to install our own hypervisor if we're
entered in HYP32 mode, and KVM will have moved itself out of the way
on kexec/normal reboot, we can assume that our hypervisor is in place
when we want to kexec, so changing our hypervisor API should not be a
problem.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/proc-fns.h | 4 ++--
arch/arm/kernel/hyp-stub.S | 13 +++++++++++++
arch/arm/kernel/reboot.c | 7 +++++--
arch/arm/mm/proc-v7.S | 12 ++++++++----
4 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
index 8877ad5ffe10..f2e1af45bd6f 100644
--- a/arch/arm/include/asm/proc-fns.h
+++ b/arch/arm/include/asm/proc-fns.h
@@ -43,7 +43,7 @@ extern struct processor {
/*
* Special stuff for a reset
*/
- void (*reset)(unsigned long addr) __attribute__((noreturn));
+ void (*reset)(unsigned long addr, bool hvc) __attribute__((noreturn));
/*
* Idle the processor
*/
@@ -88,7 +88,7 @@ extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte);
#else
extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte, unsigned int ext);
#endif
-extern void cpu_reset(unsigned long addr) __attribute__((noreturn));
+extern void cpu_reset(unsigned long addr, bool hvc) __attribute__((noreturn));
/* These three are private to arch/arm/kernel/suspend.c */
extern void cpu_do_suspend(void *);
diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
index f3e9ba5fb642..82915231c6f8 100644
--- a/arch/arm/kernel/hyp-stub.S
+++ b/arch/arm/kernel/hyp-stub.S
@@ -24,6 +24,7 @@
#define HVC_GET_VECTORS 0
#define HVC_SET_VECTORS 1
+#define HVC_SOFT_RESTART 2
#ifndef ZIMAGE
/*
@@ -215,6 +216,10 @@ ENDPROC(__hyp_stub_install_secondary)
mcr p15, 4, r1, c12, c0, 0 @ set HVBAR
b __hyp_stub_exit
+1: teq r0, #HVC_SOFT_RESTART
+ bne 1f
+ bx r3
+
1: mov r0, #-1
__hyp_stub_exit:
@@ -256,6 +261,14 @@ ENTRY(__hyp_set_vectors)
ret lr
ENDPROC(__hyp_set_vectors)
+ENTRY(__hyp_soft_restart)
+ mov r3, r0
+ mov r0, #HVC_SOFT_RESTART
+ __HVC(0)
+ mov r0, r3
+ ret lr
+ENDPROC(__hyp_soft_restart)
+
#ifndef ZIMAGE
.align 2
.L__boot_cpu_mode_offset:
diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c
index 3fa867a2aae6..3b2aa9a9fe26 100644
--- a/arch/arm/kernel/reboot.c
+++ b/arch/arm/kernel/reboot.c
@@ -12,10 +12,11 @@
#include <asm/cacheflush.h>
#include <asm/idmap.h>
+#include <asm/virt.h>
#include "reboot.h"
-typedef void (*phys_reset_t)(unsigned long);
+typedef void (*phys_reset_t)(unsigned long, bool);
/*
* Function pointers to optional machine specific functions
@@ -51,7 +52,9 @@ static void __soft_restart(void *addr)
/* Switch to the identity mapping. */
phys_reset = (phys_reset_t)virt_to_idmap(cpu_reset);
- phys_reset((unsigned long)addr);
+
+ /* original stub should be restored by kvm */
+ phys_reset((unsigned long)addr, is_hyp_mode_available());
/* Should never get here. */
BUG();
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index d00d52c9de3e..1846ca4255d0 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -53,11 +53,15 @@ ENDPROC(cpu_v7_proc_fin)
.align 5
.pushsection .idmap.text, "ax"
ENTRY(cpu_v7_reset)
- mrc p15, 0, r1, c1, c0, 0 @ ctrl register
- bic r1, r1, #0x1 @ ...............m
- THUMB( bic r1, r1, #1 << 30 ) @ SCTLR.TE (Thumb exceptions)
- mcr p15, 0, r1, c1, c0, 0 @ disable MMU
+ mrc p15, 0, r2, c1, c0, 0 @ ctrl register
+ bic r2, r2, #0x1 @ ...............m
+ THUMB( bic r2, r2, #1 << 30 ) @ SCTLR.TE (Thumb exceptions)
+ mcr p15, 0, r2, c1, c0, 0 @ disable MMU
isb
+#ifdef CONFIG_ARM_VIRT_EXT
+ teq r1, #0
+ bne __hyp_soft_restart
+#endif
bx r0
ENDPROC(cpu_v7_reset)
.popsection
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox