[PATCH v5 2/3] powerpc/powernv: Create LED platform device
This patch adds platform devices for leds. Also export LED related
OPAL API's so that led driver can use these APIs.
Signed-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/platforms/powernv/opal.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index f084afa..6839358 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -648,7 +648,7 @@ static void opal_init_heartbeat(void)
static int __init opal_init(void)
{
- struct device_node *np, *consoles;
+ struct device_node *np, *consoles, *leds;
int rc;
opal_node = of_find_node_by_path(/ibm,opal);
@@ -689,6 +689,13 @@ static int __init opal_init(void)
/* Setup a heatbeat thread if requested by OPAL */
opal_init_heartbeat();
+ /* Create leds platform devices */
+ leds = of_find_node_by_path(/ibm,opal/leds);
+ if (leds) {
+ of_platform_device_create(leds, opal_leds, NULL);
+ of_node_put(leds);
+ }
+
/* Create opal kobject under /sys/firmware */
rc = opal_sysfs_init();
if (rc == 0) {
@@ -841,3 +848,6 @@ EXPORT_SYMBOL_GPL(opal_rtc_write);
EXPORT_SYMBOL_GPL(opal_tpo_read);
EXPORT_SYMBOL_GPL(opal_tpo_write);
EXPORT_SYMBOL_GPL(opal_i2c_request);
+/* Export these symbols for PowerNV LED class driver */
+EXPORT_SYMBOL_GPL(opal_leds_get_ind);
+EXPORT_SYMBOL_GPL(opal_leds_set_ind);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 3/3] leds/powernv: Add driver for PowerNV platform
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particular FRU or resource in the
system.
- Fault
Indicates there is a problem with the FRU or resource at the
location with which the indicator is associated.
We register classdev structures for all individual LEDs detected on the
system through LED specific device tree nodes. Device tree nodes specify
what all kind of LEDs present on the same location code. It registers
LED classdev structure for each of them.
All the system LEDs can be found in the same regular path /sys/class/leds/.
We don't use LED colors. We use LED node and led-types property to form
LED classdev. Our LEDs have names in this format.
location_code:attention|identify|fault
Any positive brightness value would turn on the LED and a zero value would
turn off the LED. The driver will return LED_FULL (255) for any turned on
LED and LED_OFF (0) for any turned off LED.
As per the LED class framework, the 'brightness_set' function should not
sleep. Hence these functions have been implemented through global work
queue tasks which might sleep on OPAL async call completion.
The platform level implementation of LED get and set state has been achieved
through OPAL calls. These calls are made available for the driver by
exporting from architecture specific codes.
Signed-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
Tested-by: Stewart Smith stew...@linux.vnet.ibm.com
---
.../devicetree/bindings/leds/leds-powernv.txt | 24 ++
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-powernv.c| 463 +
4 files changed, 499 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-powernv.txt
create mode 100644 drivers/leds/leds-powernv.c
diff --git a/Documentation/devicetree/bindings/leds/leds-powernv.txt
b/Documentation/devicetree/bindings/leds/leds-powernv.txt
new file mode 100644
index 000..636f028
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-powernv.txt
@@ -0,0 +1,24 @@
+Device Tree binding for LEDs on IBM Power Systems
+-
+
+The 'leds' node under '/ibm,opal' lists service indicators available in the
+system and their capabilities.
+
+leds {
+ compatible = ibm,opal-v3-led;
+ led-mode = lightpath;
+
+ U78C9.001.RST0027-P1-C1 {
+ led-types = identify, fault;
+ };
+ ...
+ ...
+};
+
+Each node under 'leds' node describes location code of FRU/Enclosure.
+
+compatible : should be : ibm,opal-v3-led.
+
+The properties under each node:
+
+ led-types : Supported LED types (attention/identify/fault).
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 4191614..4f56c7a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -505,6 +505,17 @@ config LEDS_BLINKM
This option enables support for the BlinkM RGB LED connected
through I2C. Say Y to enable support for the BlinkM LED.
+config LEDS_POWERNV
+ tristate LED support for PowerNV Platform
+ depends on LEDS_CLASS
+ depends on PPC_POWERNV
+ depends on OF
+ help
+ This option enables support for the system LEDs present on
+ PowerNV platforms. Say 'y' to enable this support in kernel.
+ To compile this driver as a module, choose 'm' here: the module
+ will be called leds-powernv.
+
config LEDS_SYSCON
bool LED support for LEDs on system controllers
depends on LEDS_CLASS=y
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index bf46093..480814a 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
+obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
new file mode 100644
index 000..b5a307c
--- /dev/null
+++ b/drivers/leds/leds-powernv.c
@@ -0,0 +1,463 @@
+/*
+ * PowerNV LED Driver
+ *
+ * Copyright IBM Corp. 2015
+ *
+ * Author: Vasant Hegde hegdevas...@linux.vnet.ibm.com
+ * Author: Anshuman Khandual khand...@linux.vnet.ibm.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ *
[PATCH v5 1/3] powerpc/powernv: Add OPAL interfaces for accessing and modifying system LED states
From: Anshuman Khandual khand...@linux.vnet.ibm.com
This patch registers the following two new OPAL interfaces calls
for the platform LED subsystem. With the help of these new OPAL calls,
the kernel will be able to get or set the state of various individual
LEDs on the system at any given location code which is passed through
the LED specific device tree nodes.
(1) OPAL_LEDS_GET_INDICATOR opal_leds_get_ind
(2) OPAL_LEDS_SET_INDICATOR opal_leds_set_ind
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Signed-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
Tested-by: Stewart Smith stew...@linux.vnet.ibm.com
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/opal-api.h| 25 -
arch/powerpc/include/asm/opal.h| 4
arch/powerpc/platforms/powernv/opal-wrappers.S | 2 ++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index e9e4c52..8f8c45f 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -154,7 +154,9 @@
#define OPAL_FLASH_WRITE 111
#define OPAL_FLASH_ERASE 112
#define OPAL_PRD_MSG 113
-#define OPAL_LAST 113
+#define OPAL_LEDS_GET_INDICATOR114
+#define OPAL_LEDS_SET_INDICATOR115
+#define OPAL_LAST 115
/* Device tree flags */
@@ -756,6 +758,27 @@ struct opal_i2c_request {
__be64 buffer_ra; /* Buffer real address */
};
+/* LED Mode */
+#define POWERNV_LED_MODE_LIGHT_PATHlightpath
+#define POWERNV_LED_MODE_GUIDING_LIGHT guidinglight
+
+/* LED type */
+#define POWERNV_LED_TYPE_IDENTIFY identify
+#define POWERNV_LED_TYPE_FAULT fault
+#define POWERNV_LED_TYPE_ATTENTION attention
+
+enum OpalSlotLedType {
+ OPAL_SLOT_LED_TYPE_ID = 0, /* IDENTIFY LED */
+ OPAL_SLOT_LED_TYPE_FAULT = 1, /* FAULT LED */
+ OPAL_SLOT_LED_TYPE_ATTN = 2,/* System Attention LED */
+ OPAL_SLOT_LED_TYPE_MAX = 3
+};
+
+enum OpalSlotLedState {
+ OPAL_SLOT_LED_STATE_OFF = 0,/* LED is OFF */
+ OPAL_SLOT_LED_STATE_ON = 1 /* LED is ON */
+};
+
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_API_H */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 958e941..03ef848 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -195,6 +195,10 @@ int64_t opal_ipmi_recv(uint64_t interface, struct
opal_ipmi_msg *msg,
int64_t opal_i2c_request(uint64_t async_token, uint32_t bus_id,
struct opal_i2c_request *oreq);
int64_t opal_prd_msg(struct opal_prd_msg *msg);
+int64_t opal_leds_get_ind(char *loc_code, u64 *led_mask,
+ u64 *led_value, u64 *max_led_type);
+int64_t opal_leds_set_ind(uint64_t token, char *loc_code, const u64 led_mask,
+ const u64 led_value, u64 *max_led_type);
int64_t opal_flash_read(uint64_t id, uint64_t offset, uint64_t buf,
uint64_t size, uint64_t token);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index d6a7b82..34c2734 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -297,3 +297,5 @@ OPAL_CALL(opal_flash_read,
OPAL_FLASH_READ);
OPAL_CALL(opal_flash_write,OPAL_FLASH_WRITE);
OPAL_CALL(opal_flash_erase,OPAL_FLASH_ERASE);
OPAL_CALL(opal_prd_msg,OPAL_PRD_MSG);
+OPAL_CALL(opal_leds_get_ind, OPAL_LEDS_GET_INDICATOR);
+OPAL_CALL(opal_leds_set_ind, OPAL_LEDS_SET_INDICATOR);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 0/3] LED driver for PowerNV platform
The following series implements LED driver for PowerNV platform.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particular FRU or resource in the
system.
- Fault
Indicates there is a problem with the FRU or resource at the
location with which the indicator is associated.
On PowerNV (Non Virtualized) platform OPAL firmware provides LED information
to host via device tree (location code and LED type). During init we check
for 'ibm,opal/leds' node in device tree to enable LED driver. And we use
OPAL API's to get/set LEDs.
Note that on PowerNV platform firmware can activate fault LED, if it can isolate
the problem. Also one can modify the LEDs using service processor interface.
None
of these involes kernel. Hence we retain LED state in unload path.
Sample LED device tree output:
--
leds {
compatible = ibm,opal-v3-led;
led-mode = lightpath;
U78C9.001.RST0027-P1-C1 {
led-types = identify, fault;
};
...
...
}
Sample sysfs output:
.
├── U78CB.001.WZS008R-A1:fault
│ ├── brightness
│ ├── device - ../../../opal_leds
│ ├── max_brightness
│ ├── power
│ │ ├── async
│ │ ├── autosuspend_delay_ms
│ │ ├── control
│ │ ├── runtime_active_kids
│ │ ├── runtime_active_time
│ │ ├── runtime_enabled
│ │ ├── runtime_status
│ │ ├── runtime_suspended_time
│ │ └── runtime_usage
│ ├── subsystem - ../../../../../class/leds
│ ├── trigger
│ └── uevent
├── U78CB.001.WZS008R-A1:identify
│ ├── brightness
│ ├── device - ../../../opal_leds
│ ├── max_brightness
│ ├── power
│ │ ├── async
│ │ ├── autosuspend_delay_ms
│ │ ├── control
│ │ ├── runtime_active_kids
│ │ ├── runtime_active_time
│ │ ├── runtime_enabled
│ │ ├── runtime_status
│ │ ├── runtime_suspended_time
│ │ └── runtime_usage
│ ├── subsystem - ../../../../../class/leds
│ ├── trigger
│ └── uevent
patch 1/2: PowerNV architecture specific code. This adds necessary
OPAL APIs.
patch 2/2: Create LED platform device and export OPAL symbols
patch 3/3: Actual LED driver implemenation for PowerNV platform.
Note that this version of patchset is based on upstream Linus tree
as Jacek mention its better to go via LED subsystem (commit 05a8256c).
@Jacek,
Let me know if you want me to rebase this patchset on top of LED tree.
Previous patchset:
v4: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-April/128028.html
v3: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-April/127702.html
v2: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-March/126301.html
v1: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-March/125705.html
Changes in v5:
- Rebased on top of Linus tree
- Renamed led as leds and updated documentation
- As Ben and Arnd suggested, removed phandle from documenation
- As Ben suggested removed led-loc device tree property
- As Jacek suggested, added back compatible property to documentation
Changes in v4:
- Updated macros to reflect platform.
- s/u64/__be64/g for big endian data we get from firmware
- Addressed review comments from Jacek. Major once are:
Removed list in powernv_led_data structure
s/kzalloc/devm_kzalloc/
Removed compatible property from documentation
s/powernv_led_set_queue/powernv_brightness_set/
- Removed LED specific brightness_set/get function. Instead this version
uses single function to queue all LED set/get requests. Later we use
LED name to detect LED type and value.
- Removed hardcoded LED type used in previous version. Instead we use
led-types property to form LED classdev.
Changes in v3:
- Addressed review comments from Jacek. Major once are:
Replaced spin lock and mutex and removed redundant structures
Replaced pr_* with dev_*
Moved OPAL platform sepcific part to separate patch
Moved repteated code to common function
Added device tree documentation for LEDs
Changes in v2:
- Rebased patches on top of mpe's next branch
https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=next
- Added System Attention Indicator support
- Removed redundant code in leds-powernv.c file
Anshuman Khandual (1):
powerpc/powernv: Add OPAL interfaces for accessing and modifying
system LED states
Vasant Hegde (2):
powerpc/powernv: Create LED platform device
leds/powernv: Add driver for PowerNV platform
.../devicetree/bindings/leds/leds-powernv.txt | 27 ++
arch/powerpc/include/asm/opal-api.h| 29 +-
arch/powerpc/include/asm/opal.h| 4 +
arch/powerpc/platforms/powernv/opal-wrappers.S | 2 +
arch/powerpc/platforms/powernv/opal.c | 12 +-
drivers/leds/Kconfig |
Re: [PATCH SLOF v3 3/5] disk-label: rename confusing block word
On Tue, Jun 30, 2015 at 04:31:19PM +0530, Nikunj A Dadhania wrote: block word is not a block number, actually its an allocated host address. Rename it to disk-buf along with a associated size(disk-buf-size=4096) for using during allocation/free. Also renaming the helper routine read-sector to read-disk-buf. This routine assumes the address to be disk-buf and only takes sector number as argument. This isn't what I suggested, and I think it is a terrible idea. Just FWIW :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [HELP/RFC] Moving ppc8xx microcode patch from micropatch.c to firmware
Le 30/06/2015 22:38, christophe leroy a écrit :
I'm trying to move the 3 microcode patches included in
arch/powerpc/sysdev/micropatch.c into the firmware directory in order
to use request_firmware() and then be able to add additional
micropatch that I need to relocate SMC2 on my MPC885.
I've now been able to get it compiled in, was due to Makefile item
written fw_shipped- instead of fw-shipped-
I'm now facing an Oops for NULL pointer in kmem_cache_alloc() after a
call to kzalloc(sizeof(*firmware), GFP_KERNEL) in
_request_firmware_prepare() (drivers/base/firmware_class.c)
Is that due to cpm_reset() being called too early ? Shouldn't kzalloc()
allocate memory from the bootmem pool in that case ?
[0.00] Unable to handle kernel paging request for data at
address 0x
[0.00] Faulting instruction address: 0xc00a77cc
[0.00] Oops: Kernel access of bad area, sig: 11 [#1]
[0.00] PREEMPT CMPC885
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
3.18.17-local-knld-998-g9c4c6b6-svn-dirty #1022
[0.00] task: c04dc3d0 ti: c04fc000 task.ti: c04fc000
[0.00] NIP: c00a77cc LR: c01bc3b8 CTR:
[0.00] REGS: c04fde20 TRAP: 0300 Not tainted
(3.18.17-local-knld-998-g9c4c6b6-svn-dirty)
[0.00] MSR: 1032 ME,IR,DR,RI CR: 93d55d35 XER: a000fb40
[0.00] DAR: DSISR: c000
GPR00: c01bc3b8 c04fded0 c04dc3d0 80d0 0009
01ff
GPR08: 0022 c051 0158 53d55d39
07ff94e8
GPR16: 07bb5d70 07ff81f4 c0534468 c04fdf68
0009
GPR24: 07ffb3a0 0001 80d0 07ffb3a0 c04fc000
c0410878
[0.00] NIP [c00a77cc] kmem_cache_alloc+0x28/0x120
[0.00] LR [c01bc3b8] _request_firmware+0x58/0xa14
[0.00] Call Trace:
[0.00] [c04fded0] [c045f588] ___alloc_bootmem_nopanic+0x34/0x64
(unreliable)
[0.00] [c04fdef0] [c01bc3b8] _request_firmware+0x58/0xa14
[0.00] [c04fdf60] [c0458678] cpm_load_patch+0x34/0xac
[0.00] [c04fdf80] [c0458620] cpm_reset+0x5c/0x80
[0.00] [c04fdf90] [c0458c1c] cmpc885_setup_arch+0x10/0x30
[0.00] [c04fdfa0] [c0457cbc] setup_arch+0x130/0x168
[0.00] [c04fdfb0] [c045469c] start_kernel+0x84/0x37c
[0.00] [c04fdff0] [c0002214] start_here+0x38/0x98
[0.00] Instruction dump:
[0.00] 7c832378 4e800020 7c0802a6 9421ffe0 bf61000c 90010024
7c7d1b78 7c9b2378
[0.00] 543e0024 813e000c 39290001 913e000c 83fd 839f0004
813e000c 3929
[0.00] ---[ end trace dc8fa200cb88537f ]---
I have written the below patch in order to test the principle, but the
firmware never gets included in my kernel, allthough I have set the
below CONFIG items:
# CONFIG_NO_UCODE_PATCH is not set
CONFIG_USB_SOF_UCODE_PATCH=y
# CONFIG_I2C_SPI_UCODE_PATCH is not set
# CONFIG_I2C_SPI_SMC1_UCODE_PATCH is not set
CONFIG_UCODE_PATCH=y
#
# Generic Driver Options
#
# CONFIG_UEVENT_HELPER is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=
CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
Can anybody help in finding what's wrong there ?
Christophe
---
arch/powerpc/sysdev/micropatch.c | 655
++-
firmware/Makefile| 3 +
firmware/freescale/i2c_spi.bin.ihex | 257
firmware/freescale/i2c_spi_smc1.bin.ihex | 257
firmware/freescale/usb_sof.bin.ihex | 513
5 files changed, 1065 insertions(+), 620 deletions(-)
create mode 100644 firmware/freescale/i2c_spi.bin.ihex
create mode 100644 firmware/freescale/i2c_spi_smc1.bin.ihex
create mode 100644 firmware/freescale/usb_sof.bin.ihex
diff --git a/arch/powerpc/sysdev/micropatch.c
b/arch/powerpc/sysdev/micropatch.c
index 6727dc5..c24780c 100644
--- a/arch/powerpc/sysdev/micropatch.c
+++ b/arch/powerpc/sysdev/micropatch.c
@@ -12,6 +12,8 @@
#include linux/string.h
#include linux/mm.h
#include linux/interrupt.h
+#include linux/firmware.h
+#include linux/module.h
#include asm/irq.h
#include asm/page.h
#include asm/pgtable.h
@@ -19,652 +21,69 @@
#include asm/cpm.h
#include asm/cpm1.h
-/*
- * I2C/SPI relocation patch arrays.
- */
-
-#ifdef CONFIG_I2C_SPI_UCODE_PATCH
-
-static uint patch_2000[] __initdata = {
-0x7FFFEFD9,
-0x3FFD,
-0x7FFB49F7,
-0x7FF9,
-0x5FEFADF7,
-0x5F89ADF7,
-0x5FEFAFF7,
-0x5F89AFF7,
-0x3A9CFBC8,
-0xE7C0EDF0,
-0x77C1E1BB,
-0xF4DC7F1D,
-0xABAD932F,
-0x4E08FDCF,
-0x6E0FAFF8,
-0x7CCF76CF,
-0xFD1FF9CF,
-0xABF88DC6,
-0xAB5679F7,
-0xB0937383,
-0xDFCE79F7,
-0xB091E6BB,
-0xE5BBE74F,
-0xB3FA6F0F,
-0x6FFB76CE,
-0xEE0DF9CF,
-0x2BFBEFEF,
-0xCFEEF9CF,
-0x76CEAD24,
-
Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp
On Wed, Jul 1, 2015 at 12:18 AM, Michael Ellerman m...@ellerman.id.au wrote:
On Tue, 2015-06-30 at 10:48 +, Joseph Myers wrote:
On Tue, 30 Jun 2015, Michael Ellerman wrote:
Is there some way you can imagine of splitting this up into smaller
chunks, so
that different arches can merge the pieces separately?
Well, it could be split as:
1. Rename include/math-emu to math-emu-old and update architectures for
the renaming (mechanically).
2. Add new include/math-emu.
3,4,5,6,7. Move each architecture from math-emu-old to math-emu.
8. Remove math-emu-old.
You still have patch 1 affecting all five architectures, but with the
per-architecture changes being much simpler.
OK. That's obviously a bit more churn, but I think it's probably the best
approach. Unless someone else has a better idea?
Does it make that much of a difference?
You said:
| However in it's current form it's not easily mergeable, because it
touches five
| architectures and has the potential to cause breakage on all of them.
Patch 1 still touches five architectures.
Patches 3-7 still have the potential to break an architecture, but only one of
them at a time.
From a bisectability point of view there's no change.
Except that patch 1 (and 8) may break something, too ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] powerpc/numa: initialize distance lookup table from drconf path
On Thu, 2015-07-02 at 08:31 +1000, Anton Blanchard wrote: Hi Nikunj, Thanks for the patch. Have we tested that this doesn't regress the non dynamic representation? Yes, that is tested. And works as expected. Great, you can add: Acked-by: Anton Blanchard an...@samba.org Hi Nikunj, Please resend a non-RFC version, with the updated changelog and Anton's ack included. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add plain English description for alignment exception oopses
If we take an alignment exception which we cannot fix, the oops currently prints: Unable to handle kernel paging request for unknown fault Lets print something more useful: Unable to handle kernel paging request for unaligned access at address 0xc000f77bba8f Signed-off-by: Anton Blanchard an...@samba.org --- arch/powerpc/mm/fault.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c index b396868..661ba0a 100644 --- a/arch/powerpc/mm/fault.c +++ b/arch/powerpc/mm/fault.c @@ -528,6 +528,10 @@ void bad_page_fault(struct pt_regs *regs, unsigned long address, int sig) printk(KERN_ALERT Unable to handle kernel paging request for instruction fetch\n); break; + case 0x600: + printk(KERN_ALERT Unable to handle kernel paging request for + unaligned access at address 0x%08lx\n, regs-dar); + break; default: printk(KERN_ALERT Unable to handle kernel paging request for unknown fault\n); -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH SLOF v3 3/5] disk-label: rename confusing block word
Hi Segher, Segher Boessenkool seg...@kernel.crashing.org writes: On Tue, Jun 30, 2015 at 04:31:19PM +0530, Nikunj A Dadhania wrote: block word is not a block number, actually its an allocated host address. Rename it to disk-buf along with a associated size(disk-buf-size=4096) for using during allocation/free. Also renaming the helper routine read-sector to read-disk-buf. This routine assumes the address to be disk-buf and only takes sector number as argument. This isn't what I suggested, and I think it is a terrible idea. The comment was against the has-fat-filesystem. As the complete disk-label.fs had that same assumption, I went ahead and renamed block across the file. Are you suggesting to drop complete patch or just the rename of read-sector ? Just FWIW :-) Regards Nikunj ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cxl: Test the correct mmio space before unmapping
Acked-by: Ian Munsie imun...@au1.ibm.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND] powerpc/numa: initialize distance lookup table from drconf path
In some situations, a NUMA guest that supports
ibm,dynamic-memory-reconfiguration node will end up having flat NUMA
distances between nodes. This is because of two problems in the
current code.
1) Different representations of associativity lists.
There is an assumption about the associativity list in
initialize_distance_lookup_table(). Associativity list has two forms:
a) [cpu,memory]@x/ibm,associativity has following
format:
N N integers
b) ibm,dynamic-reconfiguration-memory/ibm,associativity-lookup-arrays
M N M associativity lists each having N integers
M = the number of associativity lists
N = the number of entries per associativity list
Fix initialize_distance_lookup_table() so that it does not assume
case a. And update the caller to skip the length field before
sending the associativity list.
2) Distance table not getting updated from drconf path.
Node distance table will not get initialized in certain cases as
ibm,dynamic-reconfiguration-memory path does not initialize the
lookup table.
Call initialize_distance_lookup_table() from drconf path with
appropriate associativity list.
Reported-by: Bharata B Rao bhar...@linux.vnet.ibm.com
Signed-off-by: Nikunj A Dadhania nik...@linux.vnet.ibm.com
Acked-by: Anton Blanchard an...@samba.org
---
* Rebased to mpe/next
* Dropped RFC tag
* Updated commit log
arch/powerpc/mm/numa.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 5e80621..8b9502a 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -225,7 +225,7 @@ static void initialize_distance_lookup_table(int nid,
for (i = 0; i distance_ref_points_depth; i++) {
const __be32 *entry;
- entry = associativity[be32_to_cpu(distance_ref_points[i])];
+ entry = associativity[be32_to_cpu(distance_ref_points[i]) - 1];
distance_lookup_table[nid][i] = of_read_number(entry, 1);
}
}
@@ -248,8 +248,12 @@ static int associativity_to_nid(const __be32
*associativity)
nid = -1;
if (nid 0
- of_read_number(associativity, 1) = distance_ref_points_depth)
- initialize_distance_lookup_table(nid, associativity);
+ of_read_number(associativity, 1) = distance_ref_points_depth) {
+ /*
+* Skip the length field and send start of associativity array
+*/
+ initialize_distance_lookup_table(nid, associativity + 1);
+ }
out:
return nid;
@@ -507,6 +511,12 @@ static int of_drconf_to_nid_single(struct of_drconf_cell
*drmem,
if (nid == 0x || nid = MAX_NUMNODES)
nid = default_nid;
+
+ if (nid 0) {
+ index = drmem-aa_index * aa-array_sz;
+ initialize_distance_lookup_table(nid,
+ aa-arrays[index]);
+ }
}
return nid;
--
2.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] cxl: Test the correct mmio space before unmapping
Before freeing p2n, test p2n, not p1n.
Signed-off-by: Daniel Axtens d...@axtens.net
---
While a potentially nasty bug, this is only hit (at the moment)
in cxl_remove, so it's probably not a candidate for stable.
---
drivers/misc/cxl/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index a16988d..fd43462 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -540,7 +540,7 @@ err:
static void cxl_unmap_slice_regs(struct cxl_afu *afu)
{
- if (afu-p1n_mmio)
+ if (afu-p2n_mmio)
iounmap(afu-p2n_mmio);
if (afu-p1n_mmio)
iounmap(afu-p1n_mmio);
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v3 02/24] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
On Mon, 29 Jun 2015, Geert Uytterhoeven wrote:
Hi Finn,
On Sun, Jun 28, 2015 at 3:42 AM, Finn Thain fth...@telegraphics.com.au
wrote:
Change the vmode calculation from logical OR to bitwise OR, since it
is obviously wrong.
Ideally, that should be a separate patch we can put on the fast track.
If you will fast track a portion of this patch series, that's great. I'll
send a separate patch. (However, IMHO, that portion which would ideally be
fast tracked is a matter of opinion.)
--
Gr{oetje,eeting}s,
Geert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v3 24/24] m68k: Dispatch nvram_ops calls to Atari or Mac functions
On Mon, 29 Jun 2015, Geert Uytterhoeven wrote:
On Sun, Jun 28, 2015 at 3:42 AM, Finn Thain fth...@telegraphics.com.au
wrote:
--- linux.orig/arch/m68k/kernel/setup_mm.c 2015-06-28
11:41:27.0 +1000
+++ linux/arch/m68k/kernel/setup_mm.c 2015-06-28 11:41:56.0 +1000
@@ -568,3 +569,109 @@ static int __init adb_probe_sync_enable
__setup(adb_sync, adb_probe_sync_enable);
#endif /* CONFIG_ADB */
+
+#if IS_ENABLED(CONFIG_NVRAM)
+extern unsigned char mac_pram_read_byte(int);
+extern void mac_pram_write_byte(unsigned char, int);
+extern ssize_t mac_pram_get_size(void);
+
+extern ssize_t atari_nvram_read(char *, size_t, loff_t *);
+extern ssize_t atari_nvram_write(char *, size_t, loff_t *);
+extern long atari_nvram_set_checksum(void);
+extern long atari_nvram_initialize(void);
+extern ssize_t atari_nvram_get_size(void);
Forward declarations belong in a header file, to be included by both
producers and consumers.
Right, will fix. (That was how the v1 patch did this. Looks like I messed
it up.)
--- linux.orig/arch/m68k/Kconfig2015-06-28 11:41:39.0 +1000
+++ linux/arch/m68k/Kconfig 2015-06-28 11:41:56.0 +1000
@@ -72,7 +72,7 @@ config PGTABLE_LEVELS
default 3
config HAVE_ARCH_NVRAM_OPS
- def_bool ATARI
+ def_bool ATARI || MAC
For maintainability, it's better to just have bool here, and let both
the ATARI and MAC config symbols select HAVE_ARCH_NVRAM_OPS.
OK, will fix.
Thanks for your review.
--
Gr{oetje,eeting}s,
Geert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] powerpc/numa: initialize distance lookup table from drconf path
Hi Nikunj, Thanks for the patch. Have we tested that this doesn't regress the non dynamic representation? Yes, that is tested. And works as expected. Great, you can add: Acked-by: Anton Blanchard an...@samba.org Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/powernv: Fix race in updating core_idle_state
core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcoreaAnother thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com --- arch/powerpc/kernel/idle_power7.S | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S index ccde8f0..48c7d4f 100644 --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -144,12 +144,26 @@ power7_enter_nap_mode: bge cr3,2f IDLE_STATE_ENTER_SEQ(PPC_NAP) /* No return */ + +core_idle_lock_held_entry: + HMT_LOW +core_idle_lock_loop_entry: + lwz r15,0(r14) + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bne core_idle_lock_loop_entry + HMT_MEDIUM + b lwarx_loop1 + 2: /* Sleep or winkle */ lbz r7,PACA_THREAD_MASK(r13) ld r14,PACA_CORE_IDLE_STATE_PTR(r13) lwarx_loop1: lwarx r15,0,r14 + + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bne core_idle_lock_held_entry + andcr15,r15,r7 /* Clear thread bit */ andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS -- 1.9.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
