Re: [PATCH v4 04/46] staging: emxx_udc: add ep capabilities support
Hi,
On Thu, Jul 30, 2015 at 09:15:38AM +0200, Robert Baldyga wrote:
On 07/29/2015 05:20 PM, Felipe Balbi wrote:
On Mon, Jul 27, 2015 at 11:16:14AM +0200, Robert Baldyga wrote:
Convert endpoint configuration to new capabilities model.
Fixed typo in epc-nulk to epc-bulk.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/staging/emxx_udc/emxx_udc.c | 60
++---
1 file changed, 29 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.c
index 3b7aa36..0d64bee 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -3153,36 +3153,33 @@ static const struct usb_gadget_ops
nbu2ss_gadget_ops = {
.ioctl = nbu2ss_gad_ioctl,
};
-static const char g_ep0_name[] = ep0;
-static const char g_ep1_name[] = ep1-bulk;
-static const char g_ep2_name[] = ep2-bulk;
-static const char g_ep3_name[] = ep3in-int;
-static const char g_ep4_name[] = ep4-iso;
-static const char g_ep5_name[] = ep5-iso;
-static const char g_ep6_name[] = ep6-bulk;
-static const char g_ep7_name[] = ep7-bulk;
-static const char g_ep8_name[] = ep8in-int;
-static const char g_ep9_name[] = ep9-iso;
-static const char g_epa_name[] = epa-iso;
-static const char g_epb_name[] = epb-bulk;
-static const char g_epc_name[] = epc-nulk;
-static const char g_epd_name[] = epdin-int;
-
-static const char *gp_ep_name[NUM_ENDPOINTS] = {
- g_ep0_name,
- g_ep1_name,
- g_ep2_name,
- g_ep3_name,
- g_ep4_name,
- g_ep5_name,
- g_ep6_name,
- g_ep7_name,
- g_ep8_name,
- g_ep9_name,
- g_epa_name,
- g_epb_name,
- g_epc_name,
- g_epd_name,
+static const struct {
+ const char *name;
+ const struct usb_ep_caps caps;
+} ep_info[NUM_ENDPOINTS] = {
+#define EP_INFO(_name, _type, _dir) \
+ { \
+ .name = _name, \
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+ USB_EP_CAPS_DIR_ ## _dir), \
+ }
+
+ EP_INFO(ep0, CONTROL, ALL),
+ EP_INFO(ep1-bulk, BULK, ALL),
+ EP_INFO(ep2-bulk, BULK, ALL),
+ EP_INFO(ep3in-int,INT,IN),
+ EP_INFO(ep4-iso, INT,ALL),
+ EP_INFO(ep5-iso, ISO,ALL),
+ EP_INFO(ep6-bulk, ISO,ALL),
+ EP_INFO(ep7-bulk, BULK, ALL),
+ EP_INFO(ep8in-int,INT,IN),
+ EP_INFO(ep9-iso, ISO,ALL),
+ EP_INFO(epa-iso, ISO,ALL),
+ EP_INFO(epb-bulk, BULK, ALL),
+ EP_INFO(epc-bulk, BULK, ALL),
+ EP_INFO(epdin-int,INT,IN),
IMO, this is pointless obfuscation. It just makes it a pain to grep
source around. Why don't you have UDC drivers initialize the 1-bit flags
directly ?
Do you mean something like this? It just makes it a pain to scroll this
source ;)
but it's at least easy to grep. Another option would be the following:
EP_INFO(ep0, USB_EP_CAPS(USB_EP_CAPS_TYPE_CONTROL,
USB_EP_CAPS_DIR_ALL)),
that also helps grepping.
--
balbi
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -v2 6/8] jump_label: Add a new static_key interface
On Tue, 2015-07-28 at 15:21 +0200, Peter Zijlstra wrote: There are various problems and short-comings with the current static_key interface: ... --- arch/powerpc/include/asm/jump_label.h | 19 This looks sane and seems to be working, so powerpc bits: Acked-by: Michael Ellerman m...@ellerman.id.au cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
AC'97 bus can support asymmetric playback/capture rates
so enable them in this case in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero m...@maciej.szmigiero.name
---
sound/soc/fsl/fsl_ssi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index a83b900..7f4f0b9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1377,7 +1377,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
/* Are the RX and the TX clocks locked? */
if (!of_find_property(np, fsl,ssi-asynchronous, NULL)) {
- ssi_private-cpu_dai_drv.symmetric_rates = 1;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ ssi_private-cpu_dai_drv.symmetric_rates = 1;
+
ssi_private-cpu_dai_drv.symmetric_channels = 1;
ssi_private-cpu_dai_drv.symmetric_samplebits = 1;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/6] ASoC: fsl_ssi: adjust set DAI format in AC'97 mode
Adjust set DAI format function in fsl_ssi driver so it
doesn't fail and clears RXDIR in AC'97 mode.
Signed-off-by: Maciej Szmigiero m...@maciej.szmigiero.name
---
sound/soc/fsl/fsl_ssi.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 8e5ff5e..37aabe3 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -900,14 +900,16 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
scr = ~CCSR_SSI_SCR_SYS_CLK_EN;
break;
default:
- return -EINVAL;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ return -EINVAL;
}
stcr |= strcr;
srcr |= strcr;
- if (ssi_private-cpu_dai_drv.symmetric_rates) {
- /* Need to clear RXDIR when using SYNC mode */
+ if (ssi_private-cpu_dai_drv.symmetric_rates
+ || fsl_ssi_is_ac97(ssi_private)) {
+ /* Need to clear RXDIR when using SYNC or AC97 mode */
srcr = ~CCSR_SSI_SRCR_RXDIR;
scr |= CCSR_SSI_SCR_SYN;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/6] ASoC: fsl_ssi: instantiate AC'97 CODEC
Instantiate AC'97 CODEC in fsl_ssi driver AC'97 mode.
Signed-off-by: Maciej Szmigiero m...@maciej.szmigiero.name
---
sound/soc/fsl/fsl_ssi.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 154bcf6..8e5ff5e 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1460,6 +1460,27 @@ done:
_fsl_ssi_set_dai_fmt(pdev-dev, ssi_private,
ssi_private-dai_fmt);
+ if (fsl_ssi_is_ac97(ssi_private)) {
+ u32 ssi_idx;
+
+ ret = of_property_read_u32(np, cell-index, ssi_idx);
+ if (ret) {
+ dev_err(pdev-dev, cannot get SSI index property\n);
+ goto error_sound_card;
+ }
+
+ ssi_private-pdev =
+ platform_device_register_data(NULL,
+ ac97-codec, ssi_idx, NULL, 0);
+ if (IS_ERR(ssi_private-pdev)) {
+ ret = PTR_ERR(ssi_private-pdev);
+ dev_err(pdev-dev,
+ failed to register AC97 codec platform: %d\n,
+ ret);
+ goto error_sound_card;
+ }
+ }
+
return 0;
error_sound_card:
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] ASoC: fsl_ssi: enable IPG clock during AC'97 reg access
Hi Maciej,
On Thu, Jul 30, 2015 at 11:33 AM, Maciej S. Szmigiero
m...@maciej.szmigiero.name wrote:
static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
@@ -1151,6 +1160,14 @@ static unsigned short fsl_ssi_ac97_read(struct
snd_ac97 *ac97,
unsigned short val = -1;
u32 reg_val;
unsigned int lreg;
+ int ret;
+
+ ret = clk_prepare_enable(fsl_ac97_data-clk);
+ if (ret) {
+ pr_err(ac97 read clk_prepare_enable failed: %d\n,
+ ret);
+ return -1;
return ret, please.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH 8/8] powerpc/fsl: Use new clockgen binding
Regards, Igal Liberman. -Original Message- From: Wood Scott-B07421 Sent: Friday, June 19, 2015 5:49 AM To: Mike Turquette; Tang Yuantian-B29983 Cc: Rafael J. Wysocki; Liberman Igal-B31950; Bucur Madalin-Cristian-B32716; linux-...@vger.kernel.org; linux...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; Wood Scott-B07421 Subject: [RFC PATCH 8/8] powerpc/fsl: Use new clockgen binding The driver retains compatibility with old device trees, but we don't want the old nodes lying around to be copied, or used as a reference (some of the mux options are incorrect), or even just being clutter. We will also need the #clock-cells in the clockgen node in order to add fman nodes. Signed-off-by: Scott Wood scottw...@freescale.com --- Tested on: several e500mc, e5500 and e6500 platforms. Tested-by: Igal Liberman igal.liber...@freescale.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/6] ASoC: fsl_ssi: enable IPG clock during AC'97 reg access
IPG clock have to be enabled during AC'97 CODEC register
access in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero m...@maciej.szmigiero.name
---
sound/soc/fsl/fsl_ssi.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 484ff20..8185edc 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1127,10 +1127,17 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97,
unsigned short reg,
struct regmap *regs = fsl_ac97_data-regs;
unsigned int lreg;
unsigned int lval;
+ int ret;
if (reg 0x7f)
return;
+ ret = clk_prepare_enable(fsl_ac97_data-clk);
+ if (ret) {
+ pr_err(ac97 write clk_prepare_enable failed: %d\n,
+ ret);
+ return;
+ }
lreg = reg 12;
regmap_write(regs, CCSR_SSI_SACADD, lreg);
@@ -1141,6 +1148,8 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97,
unsigned short reg,
regmap_update_bits(regs, CCSR_SSI_SACNT, CCSR_SSI_SACNT_RDWR_MASK,
CCSR_SSI_SACNT_WR);
udelay(100);
+
+ clk_disable_unprepare(fsl_ac97_data-clk);
}
static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
@@ -1151,6 +1160,14 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97
*ac97,
unsigned short val = -1;
u32 reg_val;
unsigned int lreg;
+ int ret;
+
+ ret = clk_prepare_enable(fsl_ac97_data-clk);
+ if (ret) {
+ pr_err(ac97 read clk_prepare_enable failed: %d\n,
+ ret);
+ return -1;
+ }
lreg = (reg 0x7f) 12;
regmap_write(regs, CCSR_SSI_SACADD, lreg);
@@ -1162,6 +1179,8 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97
*ac97,
regmap_read(regs, CCSR_SSI_SACDAT, reg_val);
val = (reg_val 4) 0x;
+ clk_disable_unprepare(fsl_ac97_data-clk);
+
return val;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/6] ASoC: fsl_ssi: add AC'97 ops setting check and cleanup
Check whether setting AC'97 ops succeeded and clean them
on removal so the fsl_ssi driver can be reloaded.
Signed-off-by: Maciej Szmigiero m...@maciej.szmigiero.name
---
sound/soc/fsl/fsl_ssi.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 7f4f0b9..154bcf6 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1340,7 +1340,11 @@ static int fsl_ssi_probe(struct platform_device *pdev)
fsl_ac97_data = ssi_private;
- snd_soc_set_ac97_ops_of_reset(fsl_ssi_ac97_ops, pdev);
+ ret = snd_soc_set_ac97_ops_of_reset(fsl_ssi_ac97_ops, pdev);
+ if (ret) {
+ dev_err(pdev-dev, could not set AC'97 ops\n);
+ return ret;
+ }
} else {
/* Initialize this copy of the CPU DAI driver structure */
memcpy(ssi_private-cpu_dai_drv, fsl_ssi_dai_template,
@@ -1480,6 +1484,9 @@ static int fsl_ssi_remove(struct platform_device *pdev)
if (ssi_private-soc-imx)
fsl_ssi_imx_clean(pdev, ssi_private);
+ if (fsl_ssi_is_ac97(ssi_private))
+ snd_soc_set_ac97_ops(NULL);
+
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/6] ASoC: fsl_ssi: AC'97 DAI driver needs probe method too
AC'97 DAI driver struct need the same probe method as
I2S one to setup DMA params in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero m...@maciej.szmigiero.name
---
sound/soc/fsl/fsl_ssi.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 8185edc..a83b900 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1101,6 +1101,7 @@ static const struct snd_soc_component_driver
fsl_ssi_component = {
static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
.bus_control = true,
+ .probe = fsl_ssi_dai_probe,
.playback = {
.stream_name = AC97 Playback,
.channels_min = 2,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] ASoC: fsl_ssi: enable IPG clock during AC'97 reg access
Hi Fabio,
On 30.07.2015 17:20, Fabio Estevam wrote:
Hi Maciej,
On Thu, Jul 30, 2015 at 11:33 AM, Maciej S. Szmigiero
m...@maciej.szmigiero.name wrote:
static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
@@ -1151,6 +1160,14 @@ static unsigned short fsl_ssi_ac97_read(struct
snd_ac97 *ac97,
unsigned short val = -1;
u32 reg_val;
unsigned int lreg;
+ int ret;
+
+ ret = clk_prepare_enable(fsl_ac97_data-clk);
+ if (ret) {
+ pr_err(ac97 read clk_prepare_enable failed: %d\n,
+ ret);
+ return -1;
return ret, please.
This function normal return value is an AC'97 register value,
so isn't more appropriate to return 0x in case of error
than linux error code?
Best regards,
Maciej Szmigiero
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 27/27] i2c: (RFC, don't apply) report OF style modalias when probing using DT
An I2C driver that supports both OF and legacy platforms, will have both a OF and I2C ID table. This means that when built as a module, the aliases will be filled from both tables but currently always an alias of the form i2c:deviceId is reported, e.g: $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias i2c:maxtouch So if a device is probed by matching its compatible string, udev can get a MODALIAS uevent env var that doesn't match with one of the valid aliases so the module won't be auto-loaded. This patch changes the I2C core to report a OF related MODALIAS uevent (of:N*T*C) env var instead so the module can be auto-loaded and also report the correct alias using sysfs: $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias of:NtrackpadTNULLCatmel,maxtouch Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com --- drivers/i2c/i2c-core.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 92dddfeb3f39..c0668c2ed9da 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -489,6 +489,10 @@ static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env) struct i2c_client *client = to_i2c_client(dev); int rc; + rc = of_device_uevent_modalias(dev, env); + if (rc != -ENODEV) + return rc; + rc = acpi_device_uevent_modalias(dev, env); if (rc != -ENODEV) return rc; @@ -726,6 +730,10 @@ show_modalias(struct device *dev, struct device_attribute *attr, char *buf) struct i2c_client *client = to_i2c_client(dev); int len; + len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1); + if (len != -ENODEV) + return len; + len = acpi_device_modalias(dev, buf, PAGE_SIZE -1); if (len != -ENODEV) return len; -- 2.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 22/27] macintosh: therm_windtunnel: Export OF module alias information
The I2C core always reports the MODALIAS uevent as i2c:client name
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.
In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.
And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.
To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.
Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
---
drivers/macintosh/therm_windtunnel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/macintosh/therm_windtunnel.c
b/drivers/macintosh/therm_windtunnel.c
index 97269567ec01..68dcbcb4fc5b 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -460,6 +460,7 @@ static const struct of_device_id therm_of_match[] = {{
.compatible = adm1030
}, {}
};
+MODULE_DEVICE_TABLE(of, therm_of_match);
static struct platform_driver therm_of_driver = {
.driver = {
--
2.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node
On Thu, 30 Jul 2015, Vlastimil Babka wrote: NAK. This is changing slob behavior. With no node specified it must use alloc_pages because that obeys NUMA memory policies etc etc. It should not force allocation from the current node like what is happening here after the patch. See the code in slub.c that is similar. Doh, somehow I convinced myself that there's #else and alloc_pages() is only used for !CONFIG_NUMA so it doesn't matter. Here's a fixed version. Acked-by: Christoph Lameter c...@linux.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 05/27] macintosh: therm_windtunnel: Export I2C module alias information
The I2C core always reports the MODALIAS uevent as i2c:client name
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.
Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
---
drivers/macintosh/therm_windtunnel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/macintosh/therm_windtunnel.c
b/drivers/macintosh/therm_windtunnel.c
index 109dcaa15934..97269567ec01 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -408,6 +408,7 @@ static const struct i2c_device_id therm_windtunnel_id[] = {
{ therm_adm1030, adm1030 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, therm_windtunnel_id);
static int
do_probe(struct i2c_client *cl, const struct i2c_device_id *id)
--
2.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node
On 07/30/2015 07:58 PM, Christoph Lameter wrote: On Thu, 30 Jul 2015, Vlastimil Babka wrote: --- a/mm/slob.c +++ b/mm/slob.c void *page; -#ifdef CONFIG_NUMA -if (node != NUMA_NO_NODE) -page = alloc_pages_exact_node(node, gfp, order); -else -#endif -page = alloc_pages(gfp, order); +page = alloc_pages_node(node, gfp, order); NAK. This is changing slob behavior. With no node specified it must use alloc_pages because that obeys NUMA memory policies etc etc. It should not force allocation from the current node like what is happening here after the patch. See the code in slub.c that is similar. Doh, somehow I convinced myself that there's #else and alloc_pages() is only used for !CONFIG_NUMA so it doesn't matter. Here's a fixed version. --8-- From: Vlastimil Babka vba...@suse.cz Date: Fri, 24 Jul 2015 15:49:47 +0200 Subject: [PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node The function alloc_pages_exact_node() was introduced in 6484eb3e2a81 (page allocator: do not check NUMA node ID when the caller knows the node is valid) as an optimized variant of alloc_pages_node(), that doesn't fallback to current node for nid == NUMA_NO_NODE. Unfortunately the name of the function can easily suggest that the allocation is restricted to the given node and fails otherwise. In truth, the node is only preferred, unless __GFP_THISNODE is passed among the gfp flags. The misleading name has lead to mistakes in the past, see 5265047ac301 (mm, thp: really limit transparent hugepage allocation to local node) and b360edb43f8e (mm, mempolicy: migrate_to_node should only migrate to node). Another issue with the name is that there's a family of alloc_pages_exact*() functions where 'exact' means exact size (instead of page order), which leads to more confusion. To prevent further mistakes, this patch effectively renames alloc_pages_exact_node() to __alloc_pages_node() to better convey that it's an optimized variant of alloc_pages_node() not intended for general usage. Both functions get described in comments. It has been also considered to really provide a convenience function for allocations restricted to a node, but the major opinion seems to be that __GFP_THISNODE already provides that functionality and we shouldn't duplicate the API needlessly. The number of users would be small anyway. Existing callers of alloc_pages_exact_node() are simply converted to call __alloc_pages_node(), with the exception of sba_alloc_coherent() which open-codes the check for NUMA_NO_NODE, so it is converted to use alloc_pages_node() instead. This means it no longer performs some VM_BUG_ON checks, and since the current check for nid in alloc_pages_node() uses a 'nid 0' comparison (which includes NUMA_NO_NODE), it may hide wrong values which would be previously exposed. Both differences will be rectified by the next patch. To sum up, this patch makes no functional changes, except temporarily hiding potentially buggy callers. Restricting the checks in alloc_pages_node() is left for the next patch which can in turn expose more existing buggy callers. Signed-off-by: Vlastimil Babka vba...@suse.cz Acked-by: Johannes Weiner han...@cmpxchg.org Cc: Mel Gorman mgor...@suse.de Cc: David Rientjes rient...@google.com Cc: Greg Thelen gthe...@google.com Cc: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Cc: Christoph Lameter c...@linux.com Cc: Pekka Enberg penb...@kernel.org Cc: Joonsoo Kim iamjoonsoo@lge.com Cc: Naoya Horiguchi n-horigu...@ah.jp.nec.com Cc: Tony Luck tony.l...@intel.com Cc: Fenghua Yu fenghua...@intel.com Cc: Arnd Bergmann a...@arndb.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Acked-by: Michael Ellerman m...@ellerman.id.au Cc: Gleb Natapov g...@kernel.org Cc: Paolo Bonzini pbonz...@redhat.com Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: Cliff Whickman c...@sgi.com Acked-by: Robin Holt robinmh...@gmail.com --- arch/ia64/hp/common/sba_iommu.c | 6 +- arch/ia64/kernel/uncached.c | 2 +- arch/ia64/sn/pci/pci_dma.c| 2 +- arch/powerpc/platforms/cell/ras.c | 2 +- arch/x86/kvm/vmx.c| 2 +- drivers/misc/sgi-xp/xpc_uv.c | 2 +- include/linux/gfp.h | 23 +++ kernel/profile.c | 8 mm/filemap.c | 2 +- mm/huge_memory.c | 6 ++ mm/hugetlb.c | 4 ++-- mm/memory-failure.c | 2 +- mm/mempolicy.c| 4 ++-- mm/migrate.c | 4 ++-- mm/page_alloc.c | 2 -- mm/slab.c | 2 +- mm/slob.c | 4 ++-- mm/slub.c | 2 +- 18 files changed, 39 insertions(+), 40 deletions(-) diff --git a/arch/ia64/hp/common/sba_iommu.c
Re: [PATCH 00/27] Export I2C and OF module aliases in missing drivers
Hello Dmitry, Thanks a lot for your feedback. On 07/30/2015 06:37 PM, Dmitry Torokhov wrote: On Thu, Jul 30, 2015 at 09:35:17AM -0700, Dmitry Torokhov wrote: Hi Javier, On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote: Hello, Short version: This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables to export that information so modules have the correct aliases built-in and autoloading works correctly. Longer version: Currently it's mandatory for I2C drivers to have an I2C device ID table regardless if the device was registered using platform data or OF. This is because the I2C core needs an I2C device ID table for two reasons: 1) Match the I2C client with a I2C device ID so a struct i2c_device_id is passed to the I2C driver probe() function. 2) Export the module aliases from the I2C device ID table so userspace can auto-load the correct module. This is because i2c_device_uevent always reports a MODALIAS of the form i2c:client-name. Why are we not fixing this? We emit specially carved uevent for ACPI-based devices, why not the same for OF? Platform bus does this... Ah, now I see the 27/27 patch. I think it is exactly what we need. And Yes, patch 27/27 is needed but the problem is as I explained before that there are drivers relying on the current behavior. The item c) in the list of issues that I mentioned. So those drivers need to be fixed before that patch is merged... probably for SPI bus as well. Yes, I didn't mention SPI because the cover letter became too long already but it does indeed have the same issue and I discussed this with Mark already some time ago [0]. Once I2C uevent report is fixed, I plan to do the same for SPI. Thanks. [0]: https://lkml.org/lkml/2014/9/11/458 Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4] powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)
On Thu, 2015-07-30 at 07:47 +0300, Igal.Liberman wrote: From: Igal Liberman igal.liber...@freescale.com Describe the PHY topology for all configurations supported by each board Based on prior work by Andy Fleming aflem...@freescale.com Signed-off-by: Igal Liberman igal.liber...@freescale.com Signed-off-by: Shruti Kanetkar shr...@freescale.com Signed-off-by: Emil Medve emilian.me...@freescale.com Signoffs should be in chronological order. You were the last to touch/submit this, so yours should go last. Likewise in the other patches you just posted. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan
On Thu, 2015-07-30 at 07:32 +0300, Igal.Liberman wrote:
+fman0: fman@40{
+ #address-cells = 1;
+ #size-cells = 1;
+ cell-index = 0;
+ compatible = fsl,fman;
+ ranges = 0 0x40 0x10;
+ reg = 0x40 0x10;
+ interrupts = 96 2 0 0, 16 2 1 1;
+ clocks = clockgen 3 0;
+ clock-names = fm0clk;
clock-names should be fmanclk as per the binding. And why would you want
the driver to have to encode the fman index into the name in order to look
the clock up by name?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the SoC device tree(s)
On Thu, 2015-07-30 at 07:33 +0300, Igal.Liberman wrote:
@@ -307,4 +307,117 @@
reg = 0xe 0x1000;
fsl,has-rstcr;
};
+
+ fman@10{
+ #address-cells = 1;
+ #size-cells = 1;
+ cell-index = 0;
+ ranges = 0 0x10 0x10;
+ compatible = fsl,fman;
+ reg = 0x10 0x10;
+ interrupts = 24 2 0 0, 16 2 1 30;
+ clock-frequency = 0;
+ fsl,qman-channel-range = 0x40 0x7;
fman is supposed to have clocks/clock-names, not clock-frequency.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/27] Export I2C and OF module aliases in missing drivers
Hello, Short version: This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables to export that information so modules have the correct aliases built-in and autoloading works correctly. Longer version: Currently it's mandatory for I2C drivers to have an I2C device ID table regardless if the device was registered using platform data or OF. This is because the I2C core needs an I2C device ID table for two reasons: 1) Match the I2C client with a I2C device ID so a struct i2c_device_id is passed to the I2C driver probe() function. 2) Export the module aliases from the I2C device ID table so userspace can auto-load the correct module. This is because i2c_device_uevent always reports a MODALIAS of the form i2c:client-name. Lee Jones posted a patch series [0] to solve 1) by allowing the I2C drivers to have a probe() function that does not get a i2c_device_id. The problem is that his series didn't take into account 2) so if that was merged and the I2C ID table is removed from all the drivers that don't needed it, module auto-loading will break for those. But even now there are many I2C drivers were module auto-loading is not working because of the fact that the I2C core always reports the MODALIAS as i2c:client-name and many developers didn't expect this. I've identified I2C drivers with 3 types of different issues: a) Those that have an i2c_table but are not exported. The match works and the correct i2c_device_id is passed on probe but since the ID table is not exported, module auto-load won't work. b) Those that have a of_table but are not exported. This is currently not an issue since even when the of_table is used to match the dev with the driver, an OF modalias is not reported by the I2C core. But if the I2C core is changed to report the MODALIAS of the form of:N*T*C as it's made by other subsystems, then module auto-load will break for these drivers. c) Those that don't have a of_table but should since are OF drivers with DT bindings doc for them. Since the I2C core does not report a OF modalias and since i2c_device_match() fallbacks to match the device part of the compatible string with the I2C device ID table, many OF drivers don't have an of_table to match. After all having a I2C device ID table is mandatory so it works without a of_table. So, in order to not make mandatory to have a I2C device ID table, at least a) and b) needs to be addressed, this series does that. c) should be fixed too since it seems wrong that a driver with a DT binding document, does not have a OF table and export it to modules. Also stripping the vendor part from the compatible string to match with the I2C devices ID table and reporting only the device name to user-space doesn't seem to be correct. I've identified at least two drivers that have the same name on their I2C device ID table so the manufacturer prefix is important. But I've not tried to fix c) yet since that is not so easy to automate due drivers not having all the information (i.e: the device name can match a documented compatible string device part but without the vendor prefix is hard to tell). I split the changes so the patches in this series are independent and can be picked individually by subsystem maintainers. Patch #27 changes the logic of i2c_device_uevent() to report an OF modalias if the device was registered using OF. But this patch is included in the series only as an RFC for illustration purposes since changing that without fixing c) will break module auto-loading for the drivers of devices registered with OF but that don't have a of_match_table. Although arguably, those drivers were relying on the assumption that a MODALIAS=i2c:foo would always be reported even for the OF case which is not the true on other subsystems. [0]: https://lkml.org/lkml/2014/8/28/283 Best regards, Javier Javier Martinez Canillas (27): mfd: stw481x: Export I2C module alias information spi: xcomm: Export I2C module alias information iio: Export I2C module alias information in missing drivers [media] Export I2C module alias information in missing drivers macintosh: therm_windtunnel: Export I2C module alias information misc: eeprom: Export I2C module alias information in missing drivers Input: Export I2C module alias information in missing drivers power: Export I2C module alias information in missing drivers i2c: core: Export I2C module alias information in dummy driver backlight: tosa: Export I2C module alias information [media] staging: media: lirc: Export I2C module alias information usb: phy: isp1301: Export I2C module alias information ALSA: ppc: keywest: Export I2C module alias information hwmon: (nct7904) Export I2C module alias information regulator: fan53555: Export I2C module alias information mfd: Export OF module alias information in missing drivers iio: Export OF module alias information in missing drivers hwmon: (g762) Export OF module alias information
[PATCH 1/2] powerpc/85xx: Make defconfigs consistent
The mpc85xx and corenet configs have many differences between them that can't be explained by the target hardware of each config. The next patch will consolidate these targets using kconfig fragments; this patch shows what the resulting defconfigs will look like (generated by using savedefconfig on a fragment-generated config). Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/configs/corenet32_smp_defconfig | 97 arch/powerpc/configs/corenet64_smp_defconfig | 97 +--- arch/powerpc/configs/mpc85xx_defconfig | 40 +++- arch/powerpc/configs/mpc85xx_smp_defconfig | 59 +++-- 4 files changed, 262 insertions(+), 31 deletions(-) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index e47c1ff..c05f8b7 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -1,10 +1,11 @@ CONFIG_PPC_85xx=y CONFIG_SMP=y -CONFIG_NR_CPUS=8 +CONFIG_NR_CPUS=24 CONFIG_SYSVIPC=y -CONFIG_FHANDLE=y CONFIG_POSIX_MQUEUE=y +CONFIG_FHANDLE=y CONFIG_AUDIT=y +CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BSD_PROCESS_ACCT=y @@ -16,10 +17,9 @@ CONFIG_CPUSETS=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_SCHED=y CONFIG_BLK_DEV_INITRD=y +CONFIG_EXPERT=y CONFIG_KALLSYMS_ALL=y -CONFIG_EMBEDDED=y CONFIG_PERF_EVENTS=y -CONFIG_SLAB=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y @@ -27,7 +27,10 @@ CONFIG_MODVERSIONS=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y CONFIG_MAC_PARTITION=y +CONFIG_C293_PCIE=y CONFIG_CORENET_GENERIC=y +CONFIG_QUICC_ENGINE=y +CONFIG_QE_GPIO=y CONFIG_HIGHMEM=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_BINFMT_MISC=m @@ -64,6 +67,7 @@ CONFIG_IP_PIMSM_V2=y CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_IPCOMP=y +# CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_LRO is not set CONFIG_IPV6=y CONFIG_IP_SCTP=m @@ -73,20 +77,29 @@ CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y +CONFIG_FTL=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_PHYSMAP=y CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_PLATRAM=y +CONFIG_MTD_M25P80=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_FSL_ELBC=y CONFIG_MTD_NAND_FSL_IFC=y CONFIG_MTD_SPI_NOR=y +CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_NBD=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=131072 +CONFIG_EEPROM_AT24=y +CONFIG_EEPROM_LEGACY=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y +CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SYM53C8XX_2=y @@ -95,17 +108,27 @@ CONFIG_SATA_AHCI=y CONFIG_SATA_FSL=y CONFIG_SATA_SIL24=y CONFIG_SATA_SIL=y +CONFIG_PATA_ALI=y CONFIG_PATA_SIL680=y +CONFIG_PATA_VIA=y CONFIG_NETDEVICES=y -CONFIG_FSL_PQ_MDIO=y +CONFIG_DUMMY=y CONFIG_FSL_XGMAC_MDIO=y +CONFIG_UCC_GETH=y +CONFIG_GIANFAR=y CONFIG_E1000=y CONFIG_E1000E=y +CONFIG_IGB=y CONFIG_AT803X_PHY=y +CONFIG_MARVELL_PHY=y +CONFIG_DAVICOM_PHY=y +CONFIG_CICADA_PHY=y CONFIG_VITESSE_PHY=y +CONFIG_BROADCOM_PHY=y CONFIG_FIXED_PHY=y CONFIG_MDIO_BUS_MUX_GPIO=y CONFIG_MDIO_BUS_MUX_MMIOREG=y +CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set @@ -114,21 +137,51 @@ CONFIG_SERIO_LIBPS2=y CONFIG_PPC_EPAPR_HV_BYTECHAN=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=6 +CONFIG_SERIAL_8250_RUNTIME_UARTS=6 CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y +CONFIG_SERIAL_QE=m CONFIG_NVRAM=y -CONFIG_I2C=y CONFIG_I2C_CHARDEV=y -CONFIG_I2C_MPC=y CONFIG_I2C_MUX=y CONFIG_I2C_MUX_PCA954x=y +CONFIG_I2C_MPC=y CONFIG_SPI=y CONFIG_SPI_GPIO=y CONFIG_SPI_FSL_SPI=y CONFIG_SPI_FSL_ESPI=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_INA2XX=y +CONFIG_FB=y +CONFIG_FB_FSL_DIU=y +# CONFIG_VGA_CONSOLE is not set +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_SOUND=y +CONFIG_SND=y +# CONFIG_SND_SUPPORT_OLD_API is not set +# CONFIG_SND_DRIVERS is not set +CONFIG_SND_INTEL8X0=y +# CONFIG_SND_PPC is not set +# CONFIG_SND_USB is not set +CONFIG_SND_SOC=y +CONFIG_SND_POWERPC_SOC=y +CONFIG_HID_A4TECH=y +CONFIG_HID_APPLE=y +CONFIG_HID_BELKIN=y +CONFIG_HID_CHERRY=y +CONFIG_HID_CHICONY=y +CONFIG_HID_CYPRESS=y +CONFIG_HID_EZKEY=y +CONFIG_HID_GYRATION=y +CONFIG_HID_LOGITECH=y +CONFIG_HID_MICROSOFT=y +CONFIG_HID_MONTEREY=y +CONFIG_HID_PANTHERLORD=y +CONFIG_HID_PETALYNX=y +CONFIG_HID_SAMSUNG=y +CONFIG_HID_SUNPLUS=y CONFIG_USB_HID=m CONFIG_USB=y CONFIG_USB_MON=y @@ -149,14 +202,14 @@ CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_DS1374=y CONFIG_RTC_DRV_DS3232=y -CONFIG_UIO=y +CONFIG_RTC_DRV_CMOS=y CONFIG_DMADEVICES=y CONFIG_FSL_DMA=y +CONFIG_UIO=y CONFIG_VIRT_DRIVERS=y CONFIG_FSL_HV_MANAGER=y -CONFIG_STAGING=y -CONFIG_FSL_CORENET_CF=y CONFIG_CLK_QORIQ=y
[PATCH 0/2] powerpc/85xx: Kconfig fragments
These patches sit on top of the following patches: http://patchwork.ozlabs.org/patch/499211/ http://patchwork.ozlabs.org/patch/499200/ http://patchwork.ozlabs.org/patch/468592/ Scott Wood (2): powerpc/85xx: Make defconfigs consistent powerpc/85xx: Use kconfig fragments arch/powerpc/Makefile| 20 +++ arch/powerpc/configs/85xx-32bit.config | 5 + arch/powerpc/configs/85xx-64bit.config | 4 + arch/powerpc/configs/85xx-hw.config | 140 +++ arch/powerpc/configs/85xx-smp.config | 2 + arch/powerpc/configs/altivec.config | 1 + arch/powerpc/configs/corenet32_smp_defconfig | 195 - arch/powerpc/configs/corenet64_smp_defconfig | 178 --- arch/powerpc/configs/corenet_basic_defconfig | 1 + arch/powerpc/configs/fsl-emb-nonhw.config| 126 ++ arch/powerpc/configs/mpc85xx_basic_defconfig | 23 +++ arch/powerpc/configs/mpc85xx_defconfig | 252 --- arch/powerpc/configs/mpc85xx_smp_defconfig | 244 -- 13 files changed, 322 insertions(+), 869 deletions(-) create mode 100644 arch/powerpc/configs/85xx-32bit.config create mode 100644 arch/powerpc/configs/85xx-64bit.config create mode 100644 arch/powerpc/configs/85xx-hw.config create mode 100644 arch/powerpc/configs/85xx-smp.config create mode 100644 arch/powerpc/configs/altivec.config delete mode 100644 arch/powerpc/configs/corenet32_smp_defconfig delete mode 100644 arch/powerpc/configs/corenet64_smp_defconfig create mode 100644 arch/powerpc/configs/corenet_basic_defconfig create mode 100644 arch/powerpc/configs/fsl-emb-nonhw.config create mode 100644 arch/powerpc/configs/mpc85xx_basic_defconfig delete mode 100644 arch/powerpc/configs/mpc85xx_defconfig delete mode 100644 arch/powerpc/configs/mpc85xx_smp_defconfig -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/85xx: Use kconfig fragments
Unify mpc85xx and corenet configs using fragments, to ease maintenance and avoid the sort of drift that the previous patch fixed. Hardware and software options are separated, with the hope that other embedded platforms could share the software options, and to make it easier to maintain custom/alternate configs that focus on either hardware or software options. Due to the previous patch, this patch should not affect the results of any of the affected defconfigs -- only how those results are achieved. The resulting config is more or less the union of the options that any of the configs previously selected. No attempt was made in this (or the previous) patch to edit out questionable options, but this patch will make it easier to do so in future patches. Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/Makefile| 20 ++ arch/powerpc/configs/85xx-32bit.config | 5 + arch/powerpc/configs/85xx-64bit.config | 4 + arch/powerpc/configs/85xx-hw.config | 140 + arch/powerpc/configs/85xx-smp.config | 2 + arch/powerpc/configs/altivec.config | 1 + arch/powerpc/configs/corenet32_smp_defconfig | 264 arch/powerpc/configs/corenet64_smp_defconfig | 259 arch/powerpc/configs/corenet_basic_defconfig | 1 + arch/powerpc/configs/fsl-emb-nonhw.config| 126 arch/powerpc/configs/mpc85xx_basic_defconfig | 23 +++ arch/powerpc/configs/mpc85xx_defconfig | 288 -- arch/powerpc/configs/mpc85xx_smp_defconfig | 289 --- 13 files changed, 322 insertions(+), 1100 deletions(-) create mode 100644 arch/powerpc/configs/85xx-32bit.config create mode 100644 arch/powerpc/configs/85xx-64bit.config create mode 100644 arch/powerpc/configs/85xx-hw.config create mode 100644 arch/powerpc/configs/85xx-smp.config create mode 100644 arch/powerpc/configs/altivec.config delete mode 100644 arch/powerpc/configs/corenet32_smp_defconfig delete mode 100644 arch/powerpc/configs/corenet64_smp_defconfig create mode 100644 arch/powerpc/configs/corenet_basic_defconfig create mode 100644 arch/powerpc/configs/fsl-emb-nonhw.config create mode 100644 arch/powerpc/configs/mpc85xx_basic_defconfig delete mode 100644 arch/powerpc/configs/mpc85xx_defconfig delete mode 100644 arch/powerpc/configs/mpc85xx_smp_defconfig diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 05f464e..4ca54fd 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -288,6 +288,26 @@ PHONY += pseries_le_defconfig pseries_le_defconfig: $(call merge_into_defconfig,pseries_defconfig,le) +PHONY += mpc85xx_defconfig +mpc85xx_defconfig: + $(call merge_into_defconfig,mpc85xx_basic_defconfig,\ + 85xx-32bit 85xx-hw fsl-emb-nonhw) + +PHONY += mpc85xx_smp_defconfig +mpc85xx_smp_defconfig: + $(call merge_into_defconfig,mpc85xx_basic_defconfig,\ + 85xx-32bit 85xx-smp 85xx-hw fsl-emb-nonhw) + +PHONY += corenet32_smp_defconfig +corenet32_smp_defconfig: + $(call merge_into_defconfig,corenet_basic_defconfig,\ + 85xx-32bit 85xx-smp 85xx-hw fsl-emb-nonhw) + +PHONY += corenet64_smp_defconfig +corenet64_smp_defconfig: + $(call merge_into_defconfig,corenet_basic_defconfig,\ + 85xx-64bit 85xx-smp altivec 85xx-hw fsl-emb-nonhw) + define archhelp @echo '* zImage - Build default images selected by kernel config' @echo ' zImage.*- Compressed kernel image (arch/$(ARCH)/boot/zImage.*)' diff --git a/arch/powerpc/configs/85xx-32bit.config b/arch/powerpc/configs/85xx-32bit.config new file mode 100644 index 000..6b8894d --- /dev/null +++ b/arch/powerpc/configs/85xx-32bit.config @@ -0,0 +1,5 @@ +CONFIG_HIGHMEM=y +CONFIG_KEXEC=y +CONFIG_PPC_85xx=y +CONFIG_PROC_KCORE=y +CONFIG_PHYS_64BIT=y diff --git a/arch/powerpc/configs/85xx-64bit.config b/arch/powerpc/configs/85xx-64bit.config new file mode 100644 index 000..4aba812 --- /dev/null +++ b/arch/powerpc/configs/85xx-64bit.config @@ -0,0 +1,4 @@ +CONFIG_MATH_EMULATION=y +CONFIG_MATH_EMULATION_HW_UNIMPLEMENTED=y +CONFIG_PPC64=y +CONFIG_PPC_BOOK3E_64=y diff --git a/arch/powerpc/configs/85xx-hw.config b/arch/powerpc/configs/85xx-hw.config new file mode 100644 index 000..fa84e88 --- /dev/null +++ b/arch/powerpc/configs/85xx-hw.config @@ -0,0 +1,140 @@ +CONFIG_AT803X_PHY=y +CONFIG_ATA=y +CONFIG_BLK_DEV_SD=y +CONFIG_BLK_DEV_SR_VENDOR=y +CONFIG_BLK_DEV_SR=y +CONFIG_BROADCOM_PHY=y +CONFIG_C293_PCIE=y +CONFIG_CHR_DEV_SG=y +CONFIG_CHR_DEV_ST=y +CONFIG_CICADA_PHY=y +CONFIG_CLK_QORIQ=y +CONFIG_CRYPTO_DEV_FSL_CAAM=y +CONFIG_CRYPTO_DEV_TALITOS=y +CONFIG_DAVICOM_PHY=y +CONFIG_DMADEVICES=y +CONFIG_E1000E=y +CONFIG_E1000=y +CONFIG_EDAC_MM_EDAC=y +CONFIG_EDAC_MPC85XX=y +CONFIG_EDAC=y +CONFIG_EEPROM_AT24=y +CONFIG_EEPROM_LEGACY=y +CONFIG_FB_FSL_DIU=y +CONFIG_FS_ENET=y +CONFIG_FSL_CORENET_CF=y +CONFIG_FSL_DMA=y
Re: [PATCH] powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR
On Thu, Jul 30, 2015 at 01:43:59PM +0800, Wei Yang wrote:
On Thu, Jul 30, 2015 at 11:15:01AM +1000, Gavin Shan wrote:
On Wed, Jul 29, 2015 at 03:22:07PM +0800, Wei Yang wrote:
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BAR in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
This patch changes the design by using one M64 BAR in Single PE mode for
one VF BAR. This gives absolute isolation for VFs.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/pci-bridge.h |5 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 104
+
2 files changed, 18 insertions(+), 91 deletions(-)
questions regarding this:
(1) When M64 BAR is running in single-PE-mode for VFs, the alignment for one
particular IOV BAR still have to be (IOV_BAR_size * max_vf_number), or
M64 segment size of last BAR (0x1000) is fine? If the later one is
fine,
more M64 space would be saved. On the other hand, if the IOV BAR size
(for all VFs) is less than 256MB, will the allocated resource conflict
with the M64 segments in last BAR?
Not need to be IOV BAR size aligned, be individual VF BAR size aligned is fine.
IOV BAR size = VF BAR size * expended_num_vfs
The (15th) last PHB's M64 BAR is divided into 256 segments and the size for
each of them is 256MB. Lets have an example: PF has one M64 BAR (128MB) and it
supports 8 VFs. The VF BAR size is 128MB and the IOV BAR size is (128MB * 8).
If we take the VF BAR size (128MB) as the alignment, the MMIO might be assigned
to have following layout. PF and VF will be put into different PE#. So I think
the correct alignment would be max{VF_bar_size, M64_segment_size}, or I missed
something?
+---++
| PF's M64 BAR | VF BARs|
+---++
0 128MB (128MB *9)
(2) When M64 BAR is in single-PE-mode, the PE numbers allocated for VFs need
continuous or not.
No, not need.
Ok. If you like, you can improve it to have discrete PE numbers when the PHB's
M64 BARs for VFs runs in single-mode in separate patch.
(3) Each PF could have 6 IOV BARs and there're 15 available M64 BAR. It means
only two VFs can be enabled in the extreme case. Would it be a problem?
Yes, you are right.
Based on Alexey's mail, full isolation is more important than more VFs.
Ok. Lets ignore this issue for now. Maybe it has to be considered in future.
Here's another problem:
(4) In pnv_pci_sriov_enable(), we can bail early when num_vfs =
phb_avaiable_M64_BARs.
no need to allocate PE number and PHB's M64 BARs, then hit failure and
release
the allocated resources.
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 712add5..1997e5d 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -214,10 +214,9 @@ struct pci_dn {
u16 vfs_expanded; /* number of VFs IOV BAR expanded */
u16 num_vfs;/* number of VFs enabled*/
int offset; /* PE# for the first VF PE */
-#define M64_PER_IOV 4
-int m64_per_iov;
+#define MAX_M64_WINDOW 16
#define IODA_INVALID_M64(-1)
-int m64_wins[PCI_SRIOV_NUM_BARS][M64_PER_IOV];
+int m64_wins[PCI_SRIOV_NUM_BARS][MAX_M64_WINDOW];
#endif /* CONFIG_PCI_IOV */
#endif
The m64_wins would be renamed to m64_map. Also, it would have dynamic
size:
- When the IOV BAR is extended to 256 segments, its size is sizeof(int) *
PCI_SRIOV_NUM_BARS;
- When the IOV BAR is extended to max_vf_num, its size is sizeof(int) *
max_vf_num;
struct list_head child_list;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 5738d31..b3e7909 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1168,7 +1168,7 @@ static int pnv_pci_vf_release_m64(struct pci_dev *pdev)
pdn = pci_get_pdn(pdev);
for (i = 0; i PCI_SRIOV_NUM_BARS; i++)
-for (j = 0; j M64_PER_IOV; j++) {
+for (j = 0; j MAX_M64_WINDOW; j++) {
if (pdn-m64_wins[i][j] == IODA_INVALID_M64)
continue;
opal_pci_phb_mmio_enable(phb-opal_id,
@@ -1193,8 +1193,7 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev,
u16 num_vfs)
inttotal_vfs;
resource_size_tsize, start;
intpe_num;
-intvf_groups;
-intvf_per_group;
+intm64s;
m64s could have better name. For example, vfs_per_m64_bar...
m64s is used to represent number of M64 BARs necessary to enable num_vfs.
Re: powerpc/eeh-powernv: Fix unbalanced IRQ warning
On Thu, 2015-30-07 at 06:53:54 UTC, Alistair Popple wrote: pnv_eeh_next_error() re-enables the eeh opal event interrupt but it gets called from a loop if there are more outstanding events to process, resulting in a warning due to enabling an already enabled interrupt. Instead the interrupt should only be re-enabled once the last outstanding event has been processed. Tested-by: Daniel Axtens d...@axtens.net Reported-by: Daniel Axtens d...@axtens.net Signed-off-by: Alistair Popple alist...@popple.id.au Acked-by: Gavin Shan gws...@linux.vnet.ibm.com Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/b8d65e9662b1ffb3b52a cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [kernel] powerpc/powernv/ioda2: Fix calculation for memory allocated for TCE table
On Mon, 2015-20-07 at 10:45:51 UTC, Alexey Kardashevskiy wrote: The existing code stores the amount of memory allocated for a TCE table. At the moment it uses @offset which is a virtual offset in the TCE table which is only correct for a one level tables and it does not include memory allocated for intermediate levels. When multilevel TCE table is requested, WARN_ON in tce_iommu_create_table() prints a warning. This adds an additional counter to pnv_pci_ioda2_table_do_alloc_pages() to count actually allocated memory. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Reviewed-by: David Gibson da...@gibson.dropbear.id.au Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/3ba3a73e9f204ce7904c cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: macintosh/ans-lcd: fix build failure after module_init/exit relocation
On Fri, 2015-17-07 at 13:20:31 UTC, Luis Henriques wrote: After commit 0fd972a7d91d (module: relocate module_init from init.h to module.h) ans-lcd module fails to build with: drivers/macintosh/ans-lcd.c:201:1: warning: data definition has no type or storage class [enabled by default] module_init(anslcd_init); ^ drivers/macintosh/ans-lcd.c:201:1: error: type defaults to 'int' in declaration of 'module_init' [-Werror=implicit-int] drivers/macintosh/ans-lcd.c:201:1: warning: parameter names (without types) in function declaration [enabled by default] drivers/macintosh/ans-lcd.c:202:1: warning: data definition has no type or storage class [enabled by default] module_exit(anslcd_exit); ^ drivers/macintosh/ans-lcd.c:202:1: error: type defaults to 'int' in declaration of 'module_exit' [-Werror=implicit-int] drivers/macintosh/ans-lcd.c:202:1: warning: parameter names (without types) in function declaration [enabled by default] drivers/macintosh/ans-lcd.c:155:1: warning: 'anslcd_init' defined but not used [-Wunused-function] anslcd_init(void) ^ drivers/macintosh/ans-lcd.c:195:1: warning: 'anslcd_exit' defined but not used [-Wunused-function] anslcd_exit(void) ^ This commit fixes it by replacing linux/init.h by linux/module.h. Fixes: 0fd972a7d91d (module: relocate module_init from init.h to module.h) Signed-off-by: Luis Henriques luis.henriq...@canonical.com Acked-by: Paul Gortmaker paul.gortma...@windriver.com Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/120d200a86273d1840d0 cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR
On Fri, Jul 31, 2015 at 10:13:26AM +1000, Gavin Shan wrote:
On Thu, Jul 30, 2015 at 01:43:59PM +0800, Wei Yang wrote:
On Thu, Jul 30, 2015 at 11:15:01AM +1000, Gavin Shan wrote:
On Wed, Jul 29, 2015 at 03:22:07PM +0800, Wei Yang wrote:
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BAR in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
This patch changes the design by using one M64 BAR in Single PE mode for
one VF BAR. This gives absolute isolation for VFs.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/pci-bridge.h |5 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 104
+
2 files changed, 18 insertions(+), 91 deletions(-)
questions regarding this:
(1) When M64 BAR is running in single-PE-mode for VFs, the alignment for one
particular IOV BAR still have to be (IOV_BAR_size * max_vf_number), or
M64 segment size of last BAR (0x1000) is fine? If the later one is
fine,
more M64 space would be saved. On the other hand, if the IOV BAR size
(for all VFs) is less than 256MB, will the allocated resource conflict
with the M64 segments in last BAR?
Not need to be IOV BAR size aligned, be individual VF BAR size aligned is
fine.
IOV BAR size = VF BAR size * expended_num_vfs
The (15th) last PHB's M64 BAR is divided into 256 segments and the size for
each of them is 256MB. Lets have an example: PF has one M64 BAR (128MB) and it
supports 8 VFs. The VF BAR size is 128MB and the IOV BAR size is (128MB * 8).
If we take the VF BAR size (128MB) as the alignment, the MMIO might be assigned
to have following layout. PF and VF will be put into different PE#. So I think
the correct alignment would be max{VF_bar_size, M64_segment_size}, or I missed
something?
+---++
| PF's M64 BAR | VF BARs|
+---++
0 128MB (128MB *9)
Ok, got your point. So the layout should be
++---+
| VF BARs| PF's M64 BAR |
++---+
0MB (128MB * 8)
(2) When M64 BAR is in single-PE-mode, the PE numbers allocated for VFs need
continuous or not.
No, not need.
Ok. If you like, you can improve it to have discrete PE numbers when the PHB's
M64 BARs for VFs runs in single-mode in separate patch.
Yep, good suggestion.
(3) Each PF could have 6 IOV BARs and there're 15 available M64 BAR. It means
only two VFs can be enabled in the extreme case. Would it be a problem?
Yes, you are right.
Based on Alexey's mail, full isolation is more important than more VFs.
Ok. Lets ignore this issue for now. Maybe it has to be considered in future.
Here's another problem:
(4) In pnv_pci_sriov_enable(), we can bail early when num_vfs =
phb_avaiable_M64_BARs.
no need to allocate PE number and PHB's M64 BARs, then hit failure and
release
the allocated resources.
Yep, good suggestion.
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 712add5..1997e5d 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -214,10 +214,9 @@ struct pci_dn {
u16 vfs_expanded; /* number of VFs IOV BAR expanded */
u16 num_vfs;/* number of VFs enabled*/
int offset; /* PE# for the first VF PE */
-#define M64_PER_IOV 4
- int m64_per_iov;
+#define MAX_M64_WINDOW 16
#define IODA_INVALID_M64(-1)
- int m64_wins[PCI_SRIOV_NUM_BARS][M64_PER_IOV];
+ int m64_wins[PCI_SRIOV_NUM_BARS][MAX_M64_WINDOW];
#endif /* CONFIG_PCI_IOV */
#endif
The m64_wins would be renamed to m64_map. Also, it would have dynamic
size:
- When the IOV BAR is extended to 256 segments, its size is sizeof(int) *
PCI_SRIOV_NUM_BARS;
- When the IOV BAR is extended to max_vf_num, its size is sizeof(int) *
max_vf_num;
struct list_head child_list;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 5738d31..b3e7909 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1168,7 +1168,7 @@ static int pnv_pci_vf_release_m64(struct pci_dev
*pdev)
pdn = pci_get_pdn(pdev);
for (i = 0; i PCI_SRIOV_NUM_BARS; i++)
- for (j = 0; j M64_PER_IOV; j++) {
+ for (j = 0; j MAX_M64_WINDOW; j++) {
if (pdn-m64_wins[i][j] == IODA_INVALID_M64)
continue;
opal_pci_phb_mmio_enable(phb-opal_id,
@@ -1193,8 +1193,7 @@ static int pnv_pci_vf_assign_m64(struct pci_dev
*pdev, u16 num_vfs)
inttotal_vfs;
Re: [PATCH v2] powerpc/ftrace: add powerpc timebase as a trace clock source
On 2015/04/24 02:24PM, Naveen N Rao wrote: Add a new powerpc-specific trace clock using the timebase register, similar to x86-tsc. This gives us - a fast, monotonic, hardware clock source for trace entries, and - a clock that can be used to correlate events across cpus as well as across hypervisor and guests. Signed-off-by: Naveen N. Rao naveen.n@linux.vnet.ibm.com --- Changes since v1: - removed unnecessary #ifdef in trace_clock.h - changed config build dependency for trace_clock.o from TRACE_CLOCK to TRACING Bump. Michael, can you please pick this up? - Naveen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
Hi,
On Thu, Jul 30, 2015 at 04:34:19PM +0200, Maciej S. Szmigiero wrote:
AC'97 bus can support asymmetric playback/capture rates
so enable them in this case in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero m...@maciej.szmigiero.name
---
sound/soc/fsl/fsl_ssi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index a83b900..7f4f0b9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1377,7 +1377,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
/* Are the RX and the TX clocks locked? */
if (!of_find_property(np, fsl,ssi-asynchronous, NULL)) {
- ssi_private-cpu_dai_drv.symmetric_rates = 1;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ ssi_private-cpu_dai_drv.symmetric_rates = 1;
+
Why don't you use the DT property that is parsed here to enable
asymmetric rates?
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
On Fri, Jul 31, 2015 at 07:27:19AM +0200, Markus Pargmann wrote:
Hi,
On Thu, Jul 30, 2015 at 04:34:19PM +0200, Maciej S. Szmigiero wrote:
AC'97 bus can support asymmetric playback/capture rates
so enable them in this case in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero m...@maciej.szmigiero.name
---
sound/soc/fsl/fsl_ssi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index a83b900..7f4f0b9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1377,7 +1377,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
/* Are the RX and the TX clocks locked? */
if (!of_find_property(np, fsl,ssi-asynchronous, NULL)) {
- ssi_private-cpu_dai_drv.symmetric_rates = 1;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ ssi_private-cpu_dai_drv.symmetric_rates = 1;
+
Why don't you use the DT property that is parsed here to enable
asymmetric rates?
Just found the last version of this series. Please use v2 and describe
changes for a new iteration of a series.
There is also a different setup with AC97 which does not use DMA. See
the long comment at the top of the file about how ac97 is already used.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] ASoC: fsl_ssi: instantiate AC'97 CODEC
On Thu, Jul 30, 2015 at 04:35:23PM +0200, Maciej S. Szmigiero wrote:
Instantiate AC'97 CODEC in fsl_ssi driver AC'97 mode.
Signed-off-by: Maciej Szmigiero m...@maciej.szmigiero.name
---
sound/soc/fsl/fsl_ssi.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 154bcf6..8e5ff5e 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1460,6 +1460,27 @@ done:
_fsl_ssi_set_dai_fmt(pdev-dev, ssi_private,
ssi_private-dai_fmt);
+ if (fsl_ssi_is_ac97(ssi_private)) {
+ u32 ssi_idx;
+
+ ret = of_property_read_u32(np, cell-index, ssi_idx);
This property is not set anywhere in the imx* DTs.
+ if (ret) {
+ dev_err(pdev-dev, cannot get SSI index property\n);
+ goto error_sound_card;
+ }
+
+ ssi_private-pdev =
+ platform_device_register_data(NULL,
+ ac97-codec, ssi_idx, NULL, 0);
If you really want to create a device at this point you should use
PLATFORM_DEVID_AUTO. I would prefer something where this is created in
DT. On the other side it is a discoverable bus..
Regards,
Markus
+ if (IS_ERR(ssi_private-pdev)) {
+ ret = PTR_ERR(ssi_private-pdev);
+ dev_err(pdev-dev,
+ failed to register AC97 codec platform: %d\n,
+ ret);
+ goto error_sound_card;
+ }
+ }
+
return 0;
error_sound_card:
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6] ASoC: fsl_ssi: adjust set DAI format in AC'97 mode
On Thu, Jul 30, 2015 at 04:35:58PM +0200, Maciej S. Szmigiero wrote:
Adjust set DAI format function in fsl_ssi driver so it
doesn't fail and clears RXDIR in AC'97 mode.
Signed-off-by: Maciej Szmigiero m...@maciej.szmigiero.name
---
sound/soc/fsl/fsl_ssi.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 8e5ff5e..37aabe3 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -900,14 +900,16 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
scr = ~CCSR_SSI_SCR_SYS_CLK_EN;
break;
default:
- return -EINVAL;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ return -EINVAL;
I think it would be better to add another case for the other mode which
is supported (AC97) instead of using the default case.
}
stcr |= strcr;
srcr |= strcr;
- if (ssi_private-cpu_dai_drv.symmetric_rates) {
- /* Need to clear RXDIR when using SYNC mode */
+ if (ssi_private-cpu_dai_drv.symmetric_rates
+ || fsl_ssi_is_ac97(ssi_private)) {
Please fix this indention. Most of the driver is written with 2 tab
indention after a line break and the new policy seems to be to indent on
the opening bracket.
Regards,
Markus
+ /* Need to clear RXDIR when using SYNC or AC97 mode */
srcr = ~CCSR_SSI_SRCR_RXDIR;
scr |= CCSR_SSI_SCR_SYN;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/powernv: Fix unbalanced IRQ warning in eeh-powernv.c
To avoid EEH getting invoked repeatedly for the same error, the OPAL interrupt that invokes EEH is masked at the start of the process. Currently, pnv_eeh_next_error() re-enables the interrupt but it gets called from a loop if there are more outstanding events to process. This causes an unbalanced enable warning. Check that there are no more errors before enabling interrupts. Fixed-by: Alistair Popple alist...@popple.id.au Tested-by: Daniel Axtens d...@axtens.net [and changelog] Signed-off-by: Michael Ellerman m...@ellerman.id.au --- arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c b/arch/powerpc/platforms/powernv/eeh-powernv.c index 5cf5e6ea213b..7cf0df859d05 100644 --- a/arch/powerpc/platforms/powernv/eeh-powernv.c +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c @@ -1478,7 +1478,7 @@ static int pnv_eeh_next_error(struct eeh_pe **pe) } /* Unmask the event */ - if (eeh_enabled()) + if (ret == EEH_NEXT_ERR_NONE eeh_enabled()) enable_irq(eeh_event_irq); return ret; -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V2] QorIQ/TMU: add thermal management support based on TMU
- Any specific reason why not using OF thermal?
- No, actually.
I'd like to use OF thermal after some clarification.
Regarding to cooling-maps. For some cases there should be more than one cpus
as cooling device and they are independent.
1. Let's say 4. So we need to provide 4 maps like map0-map3. Right?
2. cooling-max-level may vary depend on switch settings or firmware. Is that
OK if I do not provide cooling-min-level and cooling-max-level property?
Thanks.
-Hongtao
-Original Message-
From: Eduardo Valentin [mailto:edubez...@gmail.com]
Sent: Thursday, July 30, 2015 2:56 PM
To: Jia Hongtao-B38951
Cc: linux...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Wood Scott-
B07421
Subject: Re: [PATCH V2] QorIQ/TMU: add thermal management support based
on TMU
On Wed, Jul 29, 2015 at 02:19:39PM +0800, Jia Hongtao wrote:
It supports one critical trip point and one passive trip point.
The cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
Signed-off-by: Jia Hongtao hongtao@freescale.com
---
This patch based on:
http://patchwork.ozlabs.org/patch/482987/
Changes for V2:
* Add tmu-range parse.
* Use default trend hook.
* Using latest thermal_zone_bind_cooling_device API.
* Add calibration check during initialization.
* Disable/enalbe device when suspend/resume.
drivers/thermal/Kconfig | 11 ++
drivers/thermal/Makefile| 1 +
drivers/thermal/qoriq_thermal.c | 406
3 files changed, 418 insertions(+)
create mode 100644 drivers/thermal/qoriq_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index
118938e..a200745 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -180,6 +180,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config QORIQ_THERMAL
+ tristate Freescale QorIQ Thermal Monitoring Unit
+ depends on CPU_THERMAL
+ depends on OF
+ default n
+ help
+ Enable thermal management based on Freescale QorIQ Thermal
Monitoring
+ Unit (TMU). It supports one critical trip point and one passive
trip
+ point. The cpufreq is used as the cooling device to throttle CPUs
when
+ the passive trip is crossed.
+
config SPEAR_THERMAL
bool SPEAr thermal sensor driver
depends on PLAT_SPEAR
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index
535dfee..8c25859 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_DOVE_THERMAL)+= dove_thermal.o
obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
diff --git a/drivers/thermal/qoriq_thermal.c
b/drivers/thermal/qoriq_thermal.c new file mode 100644 index
000..0694f42
--- /dev/null
+++ b/drivers/thermal/qoriq_thermal.c
@@ -0,0 +1,406 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
+WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
+License for
+ * more details.
+ *
+ */
+
+/*
+ * Based on Freescale QorIQ Thermal Monitoring Unit (TMU) */
+#include linux/cpufreq.h #include linux/cpu_cooling.h #include
+linux/module.h #include linux/platform_device.h #include
+linux/err.h #include linux/io.h #include linux/of.h #include
+linux/of_address.h #include linux/thermal.h
+
+#define SITES_MAX 16
+
+#define TMU_TEMP_PASSIVE 85000
+#define TMU_TEMP_CRITICAL 95000
+
+#define TMU_PASSIVE_DELAY 1000/* Milliseconds */
+#define TMU_POLLING_DELAY 5000
+
+/* The driver supports 1 passive trip point and 1 critical trip point
+*/ enum tmu_thermal_trip {
+ TMU_TRIP_PASSIVE,
+ TMU_TRIP_CRITICAL,
+ TMU_TRIP_NUM,
+};
+
+/*
+ * QorIQ TMU Registers
+ */
+struct qoriq_tmu_site_regs {
+ __be32 tritsr; /* Immediate Temperature Site Register */
+ __be32 tratsr; /* Average Temperature Site Register */
+ u8 res0[0x8];
+} __packed;
+
+struct qoriq_tmu_regs {
+ __be32 tmr; /* Mode Register */
+#define TMR_DISABLE0x0
+#define TMR_ME
[PATCH v4] powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)
From: Igal Liberman igal.liber...@freescale.com
Describe the PHY topology for all configurations supported by each board
Based on prior work by Andy Fleming aflem...@freescale.com
Signed-off-by: Igal Liberman igal.liber...@freescale.com
Signed-off-by: Shruti Kanetkar shr...@freescale.com
Signed-off-by: Emil Medve emilian.me...@freescale.com
---
Depends on the following patch set:
https://patchwork.ozlabs.org/patch/502018/
https://patchwork.ozlabs.org/patch/502019/
v3 --- v4:
- Added T1024 support
v2 --- v3:
- Fixed incorrect E-Mail address (signed-off-by)
v1 --- v2
- Remove 'Change-Id'
arch/powerpc/boot/dts/b4860qds.dts| 60 -
arch/powerpc/boot/dts/b4qds.dtsi | 51 -
arch/powerpc/boot/dts/p1023rdb.dts| 24 +-
arch/powerpc/boot/dts/p2041rdb.dts| 92 +++-
arch/powerpc/boot/dts/p3041ds.dts | 112 -
arch/powerpc/boot/dts/p4080ds.dts | 184 ++-
arch/powerpc/boot/dts/p5020ds.dts | 112 -
arch/powerpc/boot/dts/p5040ds.dts | 234 ++-
arch/powerpc/boot/dts/t1023rdb.dts| 41
arch/powerpc/boot/dts/t1024rdb.dts| 45
arch/powerpc/boot/dts/t1040rdb.dts| 32 ++-
arch/powerpc/boot/dts/t1042rdb.dts| 30 ++-
arch/powerpc/boot/dts/t1042rdb_pi.dts | 18 +-
arch/powerpc/boot/dts/t104xqds.dtsi | 178 ++-
arch/powerpc/boot/dts/t104xrdb.dtsi | 33 ++-
arch/powerpc/boot/dts/t2080qds.dts| 158 -
arch/powerpc/boot/dts/t2080rdb.dts| 67 +-
arch/powerpc/boot/dts/t2081qds.dts| 221 +-
arch/powerpc/boot/dts/t4240qds.dts| 400 -
arch/powerpc/boot/dts/t4240rdb.dts| 149 +++-
20 files changed, 2221 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/boot/dts/b4860qds.dts
b/arch/powerpc/boot/dts/b4860qds.dts
index 6bb3707..98b1ef4 100644
--- a/arch/powerpc/boot/dts/b4860qds.dts
+++ b/arch/powerpc/boot/dts/b4860qds.dts
@@ -1,7 +1,7 @@
/*
* B4860DS Device Tree Source
*
- * Copyright 2012 Freescale Semiconductor Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -39,12 +39,69 @@
model = fsl,B4860QDS;
compatible = fsl,B4860QDS;
+ aliases {
+ phy_sgmii_1e = phy_sgmii_1e;
+ phy_sgmii_1f = phy_sgmii_1f;
+ phy_xaui_slot1 = phy_xaui_slot1;
+ phy_xaui_slot2 = phy_xaui_slot2;
+ };
+
ifc: localbus@ffe124000 {
board-control@3,0 {
compatible = fsl,b4860qds-fpga, fsl,fpga-qixis;
};
};
+ soc@ffe00 {
+ fman@40 {
+ ethernet@e8000 {
+ phy-handle = phy_sgmii_1e;
+ phy-connection-type = sgmii;
+ };
+
+ ethernet@ea000 {
+ phy-handle = phy_sgmii_1f;
+ phy-connection-type = sgmii;
+ };
+
+ ethernet@f {
+ phy-handle = phy_xaui_slot1;
+ phy-connection-type = xgmii;
+ };
+
+ ethernet@f2000 {
+ phy-handle = phy_xaui_slot2;
+ phy-connection-type = xgmii;
+ };
+
+ mdio@fc000 {
+ phy_sgmii_1e: ethernet-phy@1e {
+ reg = 0x1e;
+ status = disabled;
+ };
+
+ phy_sgmii_1f: ethernet-phy@1f {
+ reg = 0x1f;
+ status = disabled;
+ };
+ };
+
+ mdio@fd000 {
+ phy_xaui_slot1: xaui-phy@slot1 {
+ compatible =
ethernet-phy-ieee802.3-c45;
+ reg = 0x7;
+ status = disabled;
+ };
+
+ phy_xaui_slot2: xaui-phy@slot2 {
+ compatible =
ethernet-phy-ieee802.3-c45;
+ reg = 0x6;
+ status = disabled;
+ };
+ };
+ };
+ };
+
rio: rapidio@ffe0c {
reg = 0xf 0xfe0c 0 0x11000;
@@ -55,7 +112,6 @@
ranges = 0 0 0xc 0x3000 0 0x1000;
};
[PATCH v2 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the SoC device tree(s)
From: Igal Liberman igal.liber...@freescale.com
Based on prior work by Andy Fleming aflem...@freescale.com
Signed-off-by: Igal Liberman igal.liber...@freescale.com
Signed-off-by: Shruti Kanetkar shr...@freescale.com
Signed-off-by: Emil Medve emilian.me...@freescale.com
---
v1 --- v2:
- Added T1024 support
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi |9 ++-
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 20 -
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 12 ++-
arch/powerpc/boot/dts/fsl/b4si-post.dtsi| 31 +++-
arch/powerpc/boot/dts/fsl/p1023si-post.dtsi | 115 ++-
arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi |5 +-
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 29 ++-
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 10 ++-
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 29 ++-
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 10 ++-
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 48 ++-
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 15 +++-
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 29 ++-
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 10 ++-
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 56 -
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 17 +++-
arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 19 +
arch/powerpc/boot/dts/fsl/t102xsi-pre.dtsi |6 ++
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 31
arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi |9 ++-
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 43 ++
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 11 +++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 88 +++-
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 22 -
24 files changed, 654 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
index 9cfeaef..5d54ec7 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
@@ -1,7 +1,7 @@
/*
* B4420 Silicon/SoC Device Tree Source (pre include)
*
- * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor, Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -54,8 +54,13 @@
dma0 = dma0;
dma1 = dma1;
sdhc = sdhc;
- };
+ fman0 = fman0;
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+ };
cpus {
#address-cells = 1;
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index 26585d6..3065833 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -1,7 +1,7 @@
/*
* B4860 Silicon/SoC Device Tree Source (post include)
*
- * Copyright 2012 - 2014 Freescale Semiconductor Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -271,6 +271,24 @@
compatible = fsl,b4860-rcpm, fsl,qoriq-rcpm-2.0;
};
+/include/ qoriq-fman3-0-1g-4.dtsi
+/include/ qoriq-fman3-0-1g-5.dtsi
+/include/ qoriq-fman3-0-10g-0.dtsi
+/include/ qoriq-fman3-0-10g-1.dtsi
+ fman@40 {
+ enet4: ethernet@e8000 {
+ };
+
+ enet5: ethernet@ea000 {
+ };
+
+ enet6: ethernet@f {
+ };
+
+ enet7: ethernet@f2000 {
+ };
+ };
+
L2: l2-cache-controller@c2 {
compatible = fsl,b4860-l2-cache-controller;
};
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
index bc914f2..a738f7c 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
@@ -1,7 +1,7 @@
/*
* B4860 Silicon/SoC Device Tree Source (pre include)
*
- * Copyright 2012 Freescale Semiconductor Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -54,6 +54,16 @@
dma0 = dma0;
dma1 = dma1;
sdhc = sdhc;
+
+ fman0 = fman0;
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+ ethernet4 = enet4;
+ ethernet5 = enet5;
+ ethernet6 = enet6;
+ ethernet7 = enet7;
};
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
[PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()
numa_mem_id() is able to handle allocation from CPUs on memory-less nodes,
so it's a more robust fallback than the currently used numa_node_id().
Suggested-by: Christoph Lameter c...@linux.com
Signed-off-by: Vlastimil Babka vba...@suse.cz
Acked-by: David Rientjes rient...@google.com
Acked-by: Mel Gorman mgor...@techsingularity.net
---
include/linux/gfp.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 4a12cae2..f92cbd2 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -318,13 +318,14 @@ __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int
order)
/*
* Allocate pages, preferring the node given as nid. When nid == NUMA_NO_NODE,
- * prefer the current CPU's node. Otherwise node must be valid and online.
+ * prefer the current CPU's closest node. Otherwise node must be valid and
+ * online.
*/
static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
unsigned int order)
{
if (nid == NUMA_NO_NODE)
- nid = numa_node_id();
+ nid = numa_mem_id();
return __alloc_pages_node(nid, gfp_mask, order);
}
--
2.4.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/3] mm: unify checks in alloc_pages_node() and __alloc_pages_node()
Perform the same debug checks in alloc_pages_node() as are done in
__alloc_pages_node(), by making the former function a wrapper of the latter
one.
In addition to better diagnostics in DEBUG_VM builds for situations which
have been already fatal (e.g. out-of-bounds node id), there are two visible
changes for potential existing buggy callers of alloc_pages_node():
- calling alloc_pages_node() with any negative nid (e.g. due to arithmetic
overflow) was treated as passing NUMA_NO_NODE and fallback to local node was
applied. This will now be fatal.
- calling alloc_pages_node() with an offline node will now be checked for
DEBUG_VM builds. Since it's not fatal if the node has been previously online,
and this patch may expose some existing buggy callers, change the VM_BUG_ON
in __alloc_pages_node() to VM_WARN_ON.
Signed-off-by: Vlastimil Babka vba...@suse.cz
Acked-by: David Rientjes rient...@google.com
---
v3: I think this is enough for what patch 4/4 in v2 tried to provide on top,
so there's no patch 4/4 anymore. The DEBUG_VM-only fixup didn't seem
justified to me.
include/linux/gfp.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index d2c142b..4a12cae2 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -310,23 +310,23 @@ __alloc_pages(gfp_t gfp_mask, unsigned int order,
static inline struct page *
__alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
{
- VM_BUG_ON(nid 0 || nid = MAX_NUMNODES || !node_online(nid));
+ VM_BUG_ON(nid 0 || nid = MAX_NUMNODES);
+ VM_WARN_ON(!node_online(nid));
return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
}
/*
* Allocate pages, preferring the node given as nid. When nid == NUMA_NO_NODE,
- * prefer the current CPU's node.
+ * prefer the current CPU's node. Otherwise node must be valid and online.
*/
static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
unsigned int order)
{
- /* Unknown node is current node */
- if (nid 0)
+ if (nid == NUMA_NO_NODE)
nid = numa_node_id();
- return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
+ return __alloc_pages_node(nid, gfp_mask, order);
}
#ifdef CONFIG_NUMA
--
2.4.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/27] Export I2C and OF module aliases in missing drivers
On Thu, Jul 30, 2015 at 09:35:17AM -0700, Dmitry Torokhov wrote: Hi Javier, On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote: Hello, Short version: This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables to export that information so modules have the correct aliases built-in and autoloading works correctly. Longer version: Currently it's mandatory for I2C drivers to have an I2C device ID table regardless if the device was registered using platform data or OF. This is because the I2C core needs an I2C device ID table for two reasons: 1) Match the I2C client with a I2C device ID so a struct i2c_device_id is passed to the I2C driver probe() function. 2) Export the module aliases from the I2C device ID table so userspace can auto-load the correct module. This is because i2c_device_uevent always reports a MODALIAS of the form i2c:client-name. Why are we not fixing this? We emit specially carved uevent for ACPI-based devices, why not the same for OF? Platform bus does this... Ah, now I see the 27/27 patch. I think it is exactly what we need. And probably for SPI bus as well. Thanks. -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/kernel: Enable seccomp filter
On Wed, Jul 29, 2015 at 10:56 PM, Michael Ellerman m...@ellerman.id.au wrote: This commit enables seccomp filter on powerpc, now that we have all the necessary pieces in place. To support seccomp's desire to modify the syscall return value under some circumstances, we use a different ABI to the ptrace ABI. That is we use r3 as the syscall return value, and orig_gpr3 is the first syscall parameter. This means the seccomp code, or a ptracer via SECCOMP_RET_TRACE, will see -ENOSYS preloaded in r3. This is identical to the behaviour on x86, and allows seccomp or the ptracer to either leave the -ENOSYS or change it to something else, as well as rejecting or not the syscall by modifying r0. If seccomp does not reject the syscall, we restore the register state to match what ptrace and audit expect, ie. r3 is the first syscall parameter again. We do this restore using orig_gpr3, which may have been modified by seccomp, which allows seccomp to modify the first syscall paramater and allow the syscall to proceed. We need to #ifdef the the additional handling of r3 for seccomp, so move it all out of line. Signed-off-by: Michael Ellerman m...@ellerman.id.au Reviewed-by: Kees Cook keesc...@chromium.org --- arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/ptrace.c | 41 - 2 files changed, 41 insertions(+), 1 deletion(-) v2: The previous version didn't compile for CONFIG_SECCOMP=n. To fix it up I moved the logic out of line and #ifdef'ed that. It gets inlined by the compiler so the end result is the same. Kees I kept your Reviewed-by on the basis that the interesting logic is the same, hope that's OK by you. Totally fine. Thanks! -Kees -- Kees Cook Chrome OS Security ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/eeh-powernv: Fix unbalanced IRQ warning
pnv_eeh_next_error() re-enables the eeh opal event interrupt but it gets called from a loop if there are more outstanding events to process, resulting in a warning due to enabling an already enabled interrupt. Instead the interrupt should only be re-enabled once the last outstanding event has been processed. Tested-by: Daniel Axtens d...@axtens.net Reported-by: Daniel Axtens d...@axtens.net Signed-off-by: Alistair Popple alist...@popple.id.au Acked-by: Gavin Shan gws...@linux.vnet.ibm.com --- arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c b/arch/powerpc/platforms/powernv/eeh-powernv.c index ca825ec..ff41c03 100644 --- a/arch/powerpc/platforms/powernv/eeh-powernv.c +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c @@ -1478,7 +1478,7 @@ static int pnv_eeh_next_error(struct eeh_pe **pe) } /* Unmask the event */ - if (eeh_enabled()) + if (ret == EEH_NEXT_ERR_NONE eeh_enabled()) enable_irq(eeh_event_irq); return ret; -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 04/46] staging: emxx_udc: add ep capabilities support
On 07/29/2015 05:20 PM, Felipe Balbi wrote:
On Mon, Jul 27, 2015 at 11:16:14AM +0200, Robert Baldyga wrote:
Convert endpoint configuration to new capabilities model.
Fixed typo in epc-nulk to epc-bulk.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/staging/emxx_udc/emxx_udc.c | 60
++---
1 file changed, 29 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.c
index 3b7aa36..0d64bee 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -3153,36 +3153,33 @@ static const struct usb_gadget_ops nbu2ss_gadget_ops
= {
.ioctl = nbu2ss_gad_ioctl,
};
-static const char g_ep0_name[] = ep0;
-static const char g_ep1_name[] = ep1-bulk;
-static const char g_ep2_name[] = ep2-bulk;
-static const char g_ep3_name[] = ep3in-int;
-static const char g_ep4_name[] = ep4-iso;
-static const char g_ep5_name[] = ep5-iso;
-static const char g_ep6_name[] = ep6-bulk;
-static const char g_ep7_name[] = ep7-bulk;
-static const char g_ep8_name[] = ep8in-int;
-static const char g_ep9_name[] = ep9-iso;
-static const char g_epa_name[] = epa-iso;
-static const char g_epb_name[] = epb-bulk;
-static const char g_epc_name[] = epc-nulk;
-static const char g_epd_name[] = epdin-int;
-
-static const char *gp_ep_name[NUM_ENDPOINTS] = {
-g_ep0_name,
-g_ep1_name,
-g_ep2_name,
-g_ep3_name,
-g_ep4_name,
-g_ep5_name,
-g_ep6_name,
-g_ep7_name,
-g_ep8_name,
-g_ep9_name,
-g_epa_name,
-g_epb_name,
-g_epc_name,
-g_epd_name,
+static const struct {
+const char *name;
+const struct usb_ep_caps caps;
+} ep_info[NUM_ENDPOINTS] = {
+#define EP_INFO(_name, _type, _dir) \
+{ \
+.name = _name, \
+.caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+USB_EP_CAPS_DIR_ ## _dir), \
+}
+
+EP_INFO(ep0, CONTROL, ALL),
+EP_INFO(ep1-bulk, BULK, ALL),
+EP_INFO(ep2-bulk, BULK, ALL),
+EP_INFO(ep3in-int,INT,IN),
+EP_INFO(ep4-iso, INT,ALL),
+EP_INFO(ep5-iso, ISO,ALL),
+EP_INFO(ep6-bulk, ISO,ALL),
+EP_INFO(ep7-bulk, BULK, ALL),
+EP_INFO(ep8in-int,INT,IN),
+EP_INFO(ep9-iso, ISO,ALL),
+EP_INFO(epa-iso, ISO,ALL),
+EP_INFO(epb-bulk, BULK, ALL),
+EP_INFO(epc-bulk, BULK, ALL),
+EP_INFO(epdin-int,INT,IN),
IMO, this is pointless obfuscation. It just makes it a pain to grep
source around. Why don't you have UDC drivers initialize the 1-bit flags
directly ?
Do you mean something like this? It just makes it a pain to scroll this
source ;)
static const struct {
const char *name;
const struct usb_ep_caps caps;
} ep_info[NUM_ENDPOINTS] = {
{
.name = ep0,
.caps = {
.type_control = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = ep1-bulk,
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = ep2-bulk,
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = ep3in-int,
.caps = {
.type_int = true,
.dir_in = true,
},
},
{
.name = ep4-iso,
.caps = {
.type_iso = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = ep5-iso,
.caps = {
.type_iso = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = ep6-bulk,
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = ep7-bulk,
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = ep8in-int,
.caps = {
.type_int = true,
.dir_in = true,
},
},
{
.name = ep9-iso,
.caps = {
.type_iso = true,
[PATCH v2] powerpc/kernel: Enable seccomp filter
This commit enables seccomp filter on powerpc, now that we have all the
necessary pieces in place.
To support seccomp's desire to modify the syscall return value under
some circumstances, we use a different ABI to the ptrace ABI. That is we
use r3 as the syscall return value, and orig_gpr3 is the first syscall
parameter.
This means the seccomp code, or a ptracer via SECCOMP_RET_TRACE, will
see -ENOSYS preloaded in r3. This is identical to the behaviour on x86,
and allows seccomp or the ptracer to either leave the -ENOSYS or change
it to something else, as well as rejecting or not the syscall by
modifying r0.
If seccomp does not reject the syscall, we restore the register state to
match what ptrace and audit expect, ie. r3 is the first syscall
parameter again. We do this restore using orig_gpr3, which may have been
modified by seccomp, which allows seccomp to modify the first syscall
paramater and allow the syscall to proceed.
We need to #ifdef the the additional handling of r3 for seccomp, so move
it all out of line.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
Reviewed-by: Kees Cook keesc...@chromium.org
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/ptrace.c | 41 -
2 files changed, 41 insertions(+), 1 deletion(-)
v2: The previous version didn't compile for CONFIG_SECCOMP=n. To fix it up I
moved the logic out of line and #ifdef'ed that. It gets inlined by the
compiler
so the end result is the same.
Kees I kept your Reviewed-by on the basis that the interesting logic is the
same, hope that's OK by you.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fe2f2c595fd9..4139644030fb 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -159,6 +159,7 @@ config PPC
select EDAC_SUPPORT
select EDAC_ATOMIC_SCRUB
select ARCH_HAS_DMA_SET_COHERENT_MASK
+ select HAVE_ARCH_SECCOMP_FILTER
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 7484221bb3f8..737c0d0b53ac 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1762,6 +1762,44 @@ long arch_ptrace(struct task_struct *child, long request,
return ret;
}
+#ifdef CONFIG_SECCOMP
+static int do_seccomp(struct pt_regs *regs)
+{
+ if (!test_thread_flag(TIF_SECCOMP))
+ return 0;
+
+ /*
+* The ABI we present to seccomp tracers is that r3 contains
+* the syscall return value and orig_gpr3 contains the first
+* syscall parameter. This is different to the ptrace ABI where
+* both r3 and orig_gpr3 contain the first syscall parameter.
+*/
+ regs-gpr[3] = -ENOSYS;
+
+ /*
+* We use the __ version here because we have already checked
+* TIF_SECCOMP. If this fails, there is nothing left to do, we
+* have already loaded -ENOSYS into r3, or seccomp has put
+* something else in r3 (via SECCOMP_RET_ERRNO/TRACE).
+*/
+ if (__secure_computing())
+ return -1;
+
+ /*
+* The syscall was allowed by seccomp, restore the register
+* state to what ptrace and audit expect.
+* Note that we use orig_gpr3, which means a seccomp tracer can
+* modify the first syscall parameter (in orig_gpr3) and also
+* allow the syscall to proceed.
+*/
+ regs-gpr[3] = regs-orig_gpr3;
+
+ return 0;
+}
+#else
+static inline int do_seccomp(struct pt_regs *regs) { return 0; }
+#endif /* CONFIG_SECCOMP */
+
/**
* do_syscall_trace_enter() - Do syscall tracing on kernel entry.
* @regs: the pt_regs of the task to trace (current)
@@ -1787,7 +1825,8 @@ long do_syscall_trace_enter(struct pt_regs *regs)
user_exit();
- secure_computing_strict(regs-gpr[0]);
+ if (do_seccomp(regs))
+ return -1;
if (test_thread_flag(TIF_SYSCALL_TRACE)) {
/*
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] QorIQ/TMU: add thermal management support based on TMU
On Wed, Jul 29, 2015 at 02:19:39PM +0800, Jia Hongtao wrote:
It supports one critical trip point and one passive trip point.
The cpufreq is used as the cooling device to throttle CPUs when
the passive trip is crossed.
Signed-off-by: Jia Hongtao hongtao@freescale.com
---
This patch based on:
http://patchwork.ozlabs.org/patch/482987/
Changes for V2:
* Add tmu-range parse.
* Use default trend hook.
* Using latest thermal_zone_bind_cooling_device API.
* Add calibration check during initialization.
* Disable/enalbe device when suspend/resume.
drivers/thermal/Kconfig | 11 ++
drivers/thermal/Makefile| 1 +
drivers/thermal/qoriq_thermal.c | 406
3 files changed, 418 insertions(+)
create mode 100644 drivers/thermal/qoriq_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 118938e..a200745 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -180,6 +180,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config QORIQ_THERMAL
+ tristate Freescale QorIQ Thermal Monitoring Unit
+ depends on CPU_THERMAL
+ depends on OF
+ default n
+ help
+ Enable thermal management based on Freescale QorIQ Thermal Monitoring
+ Unit (TMU). It supports one critical trip point and one passive trip
+ point. The cpufreq is used as the cooling device to throttle CPUs when
+ the passive trip is crossed.
+
config SPEAR_THERMAL
bool SPEAr thermal sensor driver
depends on PLAT_SPEAR
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 535dfee..8c25859 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o
obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_IMX_THERMAL)+= imx_thermal.o
+obj-$(CONFIG_QORIQ_THERMAL) += qoriq_thermal.o
obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
new file mode 100644
index 000..0694f42
--- /dev/null
+++ b/drivers/thermal/qoriq_thermal.c
@@ -0,0 +1,406 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+/*
+ * Based on Freescale QorIQ Thermal Monitoring Unit (TMU)
+ */
+#include linux/cpufreq.h
+#include linux/cpu_cooling.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/thermal.h
+
+#define SITES_MAX16
+
+#define TMU_TEMP_PASSIVE 85000
+#define TMU_TEMP_CRITICAL95000
+
+#define TMU_PASSIVE_DELAY1000/* Milliseconds */
+#define TMU_POLLING_DELAY5000
+
+/* The driver supports 1 passive trip point and 1 critical trip point */
+enum tmu_thermal_trip {
+ TMU_TRIP_PASSIVE,
+ TMU_TRIP_CRITICAL,
+ TMU_TRIP_NUM,
+};
+
+/*
+ * QorIQ TMU Registers
+ */
+struct qoriq_tmu_site_regs {
+ __be32 tritsr; /* Immediate Temperature Site Register */
+ __be32 tratsr; /* Average Temperature Site Register */
+ u8 res0[0x8];
+} __packed;
+
+struct qoriq_tmu_regs {
+ __be32 tmr; /* Mode Register */
+#define TMR_DISABLE 0x0
+#define TMR_ME 0x8000
+#define TMR_ALPF 0x0c00
+#define TMR_MSITE0x8000
+#define TMR_ALL (TMR_ME | TMR_ALPF | TMR_MSITE)
+ __be32 tsr; /* Status Register */
+ __be32 tmtmir; /* Temperature measurement interval Register */
+#define TMTMIR_DEFAULT 0x0007
+ u8 res0[0x14];
+ __be32 tier;/* Interrupt Enable Register */
+#define TIER_DISABLE 0x0
+ __be32 tidr;/* Interrupt Detect Register */
+ __be32 tiscr; /* Interrupt Site Capture Register */
+ __be32 ticscr; /* Interrupt Critical Site Capture Register */
+ u8 res1[0x10];
+ __be32 tmhtcrh; /* High Temperature Capture Register */
+ __be32 tmhtcrl; /* Low Temperature Capture Register */
+ u8 res2[0x8];
+ __be32 tmhtitr; /* High Temperature
[PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node
The function alloc_pages_exact_node() was introduced in 6484eb3e2a81 (page allocator: do not check NUMA node ID when the caller knows the node is valid) as an optimized variant of alloc_pages_node(), that doesn't fallback to current node for nid == NUMA_NO_NODE. Unfortunately the name of the function can easily suggest that the allocation is restricted to the given node and fails otherwise. In truth, the node is only preferred, unless __GFP_THISNODE is passed among the gfp flags. The misleading name has lead to mistakes in the past, see 5265047ac301 (mm, thp: really limit transparent hugepage allocation to local node) and b360edb43f8e (mm, mempolicy: migrate_to_node should only migrate to node). Another issue with the name is that there's a family of alloc_pages_exact*() functions where 'exact' means exact size (instead of page order), which leads to more confusion. To prevent further mistakes, this patch effectively renames alloc_pages_exact_node() to __alloc_pages_node() to better convey that it's an optimized variant of alloc_pages_node() not intended for general usage. Both functions get described in comments. It has been also considered to really provide a convenience function for allocations restricted to a node, but the major opinion seems to be that __GFP_THISNODE already provides that functionality and we shouldn't duplicate the API needlessly. The number of users would be small anyway. Existing callers of alloc_pages_exact_node() are simply converted to call __alloc_pages_node(), with two exceptions. sba_alloc_coherent() and slob_new_page() both open-code the check for NUMA_NO_NODE, so they are converted to use alloc_pages_node() instead. This means they no longer perform some VM_BUG_ON checks, and since the current check for nid in alloc_pages_node() uses a 'nid 0' comparison (which includes NUMA_NO_NODE), it may hide wrong values which would be previously exposed. Both differences will be rectified by the next patch. To sum up, this patch makes no functional changes, except temporarily hiding potentially buggy callers. Restricting the checks in alloc_pages_node() is left for the next patch which can in turn expose more existing buggy callers. Signed-off-by: Vlastimil Babka vba...@suse.cz Cc: Mel Gorman mgor...@suse.de Cc: David Rientjes rient...@google.com Cc: Greg Thelen gthe...@google.com Cc: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Cc: Christoph Lameter c...@linux.com Cc: Pekka Enberg penb...@kernel.org Cc: Joonsoo Kim iamjoonsoo@lge.com Cc: Naoya Horiguchi n-horigu...@ah.jp.nec.com Cc: Tony Luck tony.l...@intel.com Cc: Fenghua Yu fenghua...@intel.com Cc: Arnd Bergmann a...@arndb.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Acked-by: Michael Ellerman m...@ellerman.id.au Cc: Gleb Natapov g...@kernel.org Cc: Paolo Bonzini pbonz...@redhat.com Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: Cliff Whickman c...@sgi.com Acked-by: Robin Holt robinmh...@gmail.com --- Based on feedback from v1 and v2, The name is __alloc_pages_node() instead of alloc_pages_prefer_node() from v1. Two callsites were also converted to alloc_pages_node() instead. v2 was a RFC for linux-mm to settle on the API first. It tried keeping alloc_pages_exact_node() as a wrapper that adds __GFP_THISNODE but the consensus was to drop it. I'm CC'ing also maintainers of the callsites so they can verify that the callsites that don't pass __GFP_THISNODE are really not intended to restrict allocation to the given node. I went through them myself and each looked like it's better off if it can successfully allocate on a fallback node rather than fail. DavidR checked them also I think, but it's better if maintainers can verify that. I'm not completely sure about all the usages in sl*b due to multiple layers through which gfp flags are being passed. Patches 2 and 3 are mm-only so I don't CC everyone. arch/ia64/hp/common/sba_iommu.c | 6 +- arch/ia64/kernel/uncached.c | 2 +- arch/ia64/sn/pci/pci_dma.c| 2 +- arch/powerpc/platforms/cell/ras.c | 2 +- arch/x86/kvm/vmx.c| 2 +- drivers/misc/sgi-xp/xpc_uv.c | 2 +- include/linux/gfp.h | 23 +++ kernel/profile.c | 8 mm/filemap.c | 2 +- mm/huge_memory.c | 6 ++ mm/hugetlb.c | 4 ++-- mm/memory-failure.c | 2 +- mm/mempolicy.c| 4 ++-- mm/migrate.c | 4 ++-- mm/page_alloc.c | 2 -- mm/slab.c | 2 +- mm/slob.c | 14 -- mm/slub.c | 2 +- 18 files changed, 41 insertions(+), 48 deletions(-) diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c index 344387a..a6d6190 100644 ---
Re: [PATCH 00/27] Export I2C and OF module aliases in missing drivers
Hi Javier, On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote: Hello, Short version: This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables to export that information so modules have the correct aliases built-in and autoloading works correctly. Longer version: Currently it's mandatory for I2C drivers to have an I2C device ID table regardless if the device was registered using platform data or OF. This is because the I2C core needs an I2C device ID table for two reasons: 1) Match the I2C client with a I2C device ID so a struct i2c_device_id is passed to the I2C driver probe() function. 2) Export the module aliases from the I2C device ID table so userspace can auto-load the correct module. This is because i2c_device_uevent always reports a MODALIAS of the form i2c:client-name. Why are we not fixing this? We emit specially carved uevent for ACPI-based devices, why not the same for OF? Platform bus does this... Thanks. -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v2] genalloc:add an gen_pool_first_fit_align algo to genalloc
On Wed, 2015-07-29 at 20:27 -0500, Zhao Qiang-B45475 wrote: On Thu, 2015-07-30 at 5:21, Scott Wood wrote: -Original Message- From: Wood Scott-B07421 Sent: Thursday, July 30, 2015 12:19 AM To: Zhao Qiang-B45475 Cc: lau...@codeaurora.org; linux-ker...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org; a...@linux-foundation.org; o...@lixom.net; catalin.mari...@arm.com; Xie Xiaobo-R63061 Subject: Re: [RFC v2] genalloc:add an gen_pool_first_fit_align algo to genalloc On Tue, 2015-07-28 at 00:32 -0500, Zhao Qiang-B45475 wrote: On Tue, 2015-07-28 at 5:21, Scott Wood wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, July 28, 2015 5:21 AM To: Zhao Qiang-B45475 Cc: lau...@codeaurora.org; linux-ker...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org; a...@linux-foundation.org; o...@lixom.net; catalin.mari...@arm.com; Xie Xiaobo-R63061 Subject: Re: [RFC v2] genalloc:add an gen_pool_first_fit_align algo to genalloc On Mon, 2015-07-27 at 17:57 +0800, Zhao Qiang wrote: Where's the part that adds the ability to pass in data to each allocation call, as per the previous discussion? You means to use gen_pool_alloc_data()? Yes. Previously you said that the format of data is algorithm-specific, So I think it is better to handle data in algorithm function. It is a channel for communication from the API caller to the algorithm. If you still prefer gen_pool_alloc_data(), I will modify it. But there still are details I want to confirm with you. 1. If use gen_pool_alloc_data(), should I pass data as a parameter? Yes. 2. Should I count align_mask in gen_pool_alloc_data(), meanwhile, add a align_mask to data as a member? gen_pool_alloc_data() should just pass data to the algorithm. The algorithm should calculate align_mask based on align. I don't think exposing align_mask to API users would be very friendly. If calculate align_mask in algorithm, I need to get pool-min_alloc_order in algorithm, Like: order = data-pool-min_alloc_order; align_mask = ((data-align + (1UL order) - 1) order) - 1; so I add pool to structure data as a member. Is there any other better idea? Pass pool as a parameter to the algorithm. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()
On Thu, Jul 30, 2015 at 06:34:31PM +0200, Vlastimil Babka wrote: numa_mem_id() is able to handle allocation from CPUs on memory-less nodes, so it's a more robust fallback than the currently used numa_node_id(). Won't it fall through to the next closest memory node in the zonelist anyway? Is this for callers doing NUMA_NO_NODE with __GFP_THISZONE? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()
On Thu, 30 Jul 2015, Vlastimil Babka wrote: numa_mem_id() is able to handle allocation from CPUs on memory-less nodes, so it's a more robust fallback than the currently used numa_node_id(). Suggested-by: Christoph Lameter c...@linux.com Signed-off-by: Vlastimil Babka vba...@suse.cz Acked-by: David Rientjes rient...@google.com Acked-by: Mel Gorman mgor...@techsingularity.net You can add my ack too if it helps. Acked-by: Christoph Lameter c...@linux.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] mm: unify checks in alloc_pages_node() and __alloc_pages_node()
Acked-by: Christoph Lameter c...@linux.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node
On Thu, 30 Jul 2015, Vlastimil Babka wrote: --- a/mm/slob.c +++ b/mm/slob.c void *page; -#ifdef CONFIG_NUMA - if (node != NUMA_NO_NODE) - page = alloc_pages_exact_node(node, gfp, order); - else -#endif - page = alloc_pages(gfp, order); + page = alloc_pages_node(node, gfp, order); NAK. This is changing slob behavior. With no node specified it must use alloc_pages because that obeys NUMA memory policies etc etc. It should not force allocation from the current node like what is happening here after the patch. See the code in slub.c that is similar. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/fsl-pci: fix pcie range issue for some P1/P2 boards
Hi Scott, -Original Message- From: Wood Scott-B07421 Sent: 2015年7月29日 10:35 To: Hou Zhiqiang-B48286 Cc: linuxppc-dev@lists.ozlabs.org; b...@kernel.crashing.org; pau...@samba.org; m...@ellerman.id.au; Hu Mingkai-B21284 Subject: Re: [PATCH] powerpc/fsl-pci: fix pcie range issue for some P1/P2 boards On Tue, 2015-07-28 at 21:34 -0500, Hou Zhiqiang-B48286 wrote: Hi Scott and all, Please ignore this patch! Did you figure out what was actually causing you to see CPU stalls? This issue fixed by cf4d1cf5ac5e7d2b886af6ed906ea0dcdc5b6855 in upstream. -Scott Thanks, Zhiqiang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
