[SMP BUG?] the return value of is_smp() is bug?
Hi,all
In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
in .config file. the secondary core can not boot.
when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file,
the secondary core can boot.
But this does not happen in kernel 3.10 lts kernel, Whether the
CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot.
Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in kernel
3.17-rc2 ?
I write the following patch to test the return value of is_smp().
Signed-off-by: Wang Long
---
arch/arm/kernel/setup.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 84db893d..fbeb67f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -925,6 +925,11 @@ void __init setup_arch(char **cmdline_p)
arm_dt_init_cpu_maps();
psci_init();
#ifdef CONFIG_SMP
+
+ if (is_smp() == 1)
+ printk("is_smp() return true;\n");
+ else if (is_smp() == 0)
+ printk("is_smp() return false;\n");
if (is_smp()) {
if (!mdesc->smp_init || !mdesc->smp_init()) {
if (psci_smp_available())
kernel version: 3.17-rc2
config: set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
command:# qemu-system-arm -M vexpress-a9 -smp 2 -m 128M -kernel
arch/arm/boot/zImage -nographic
The output:
..
is_smp() return false;
CPU: Testing write buffer coherency: ok
missing device node for CPU 0
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting up static identity map for 0x604643d8 - 0x60464430
Brought up 1 CPUs
SMP: Total of 1 processors activated.
CPU: All CPU(s) started in SVC mode.
...
config: set CONFIG_HAVE_SMP = y and not set CONFIG_SMP_ON_UP
command:# qemu-system-arm -M vexpress-a9 -smp 2 -m 128M -kernel
arch/arm/boot/zImage -nographic
The output:
.
Memory policy: Data cache writealloc
is_smp() return true;
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
..
..
CPU: Testing write buffer coherency: ok
missing device node for CPU 0
missing device node for CPU 1
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting up static identity map for 0x60463ef8 - 0x60463f50
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 8001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
...
Any ideas?
--
1.7.9.5
--
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/
[PATCH] ARM: Kconfig: Open force maximum zone order for all SoCs
Signed-off-by: Xiubo Li --- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c49a775..bf8445c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1687,7 +1687,7 @@ config ARCH_WANT_GENERAL_HUGETLB source "mm/Kconfig" config FORCE_MAX_ZONEORDER - int "Maximum zone order" if ARCH_SHMOBILE_LEGACY + int "Maximum zone order" range 11 64 if ARCH_SHMOBILE_LEGACY default "12" if SOC_AM33XX default "9" if SA || ARCH_EFM32 -- 1.8.4 -- 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/
Re: [PATCH v2] cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec
On 1 September 2014 10:48, Shilpa Bhat wrote: > Hi Viresh, > On Fri, 2014-08-29 at 05:33 +0530, Viresh Kumar wrote: >> On 28 August 2014 19:36, Shilpasri G Bhat >> wrote: >> > >> > Changes v1->v2: >> > Invoke .target() driver callback to set the cpus to nominal frequency >> > in reboot notifier, instead of calling cpufreq_suspend() as suggested >> > by Viresh Kumar. >> > Modified the commit message. >> >> This changelog will get commited, is this what you want? You skipped replying to this and commited the same mistake again.. > > This patch ensures the cpus to kexec/reboot at nominal frequency. > Nominal frequency is the highest cpu frequency on PowerPC at > which the cores can run without getting throttled. > > If the host kernel had set the cpus to a low pstate and then it > kexecs/reboots to a cpufreq disabled kernel it would cause the target > kernel to perform poorly. It will also increase the boot up time of > the target kernel. So set the cpus to high pstate, in this case to > nominal frequency before rebooting to avoid such scenarios. > > The reboot notifier will set the cpus to nominal frequncy. > > Changes v1->v2: > Invoke .target() driver callback to set the cpus to nominal frequency > in reboot notifier, instead of calling cpufreq_suspend() as suggested > by Viresh Kumar. > Modified the commit message. This would get commited in git changelogs and probably you don't want this. So please place them after the three dash '-' symbols below.. > Signed-off-by: Shilpasri G Bhat > Suggested-by: Viresh Kumar > Reviewed-by: Preeti U Murthy > --- HERE>>> > drivers/cpufreq/powernv-cpufreq.c | 35 +++ > 1 file changed, 35 insertions(+) I have already Acked this, so you could have added that yourself on this resend. -- 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/
[PATCHv1 3/7] ASoC: dts: vf610-twr: To support simple card newest style.
This patch depends on the following simple card patch:
===
ASoC: simple-card: Merge single and muti DAI link code.
This patch merge single DAI link and muti-DAI links code together,
and simply the simple-card driver code.
And also do some other improvement:
Since from the DAI format micro SND_SOC_DAIFMT_CBx_CFx, the 'CBx'
mean Codec's bit clock is as master/slave and the 'CFx' mean Codec's
frame clock is as master/slave.
So these same DAI formats should be informed to CPU and CODE DAIs at
the same time. For the Codec driver will set the bit clock and frame
clock as the DAI formats said, but for the CPU driver, if the the
bit clock or frame clock is as Codec master, so it should be set CPU
DAI device as bit clock or frame clock as slave, and vice versa.
The old code will cause confusion, and we should be clear that the
letter 'C' here mean to Codec.
===
Signed-off-by: Xiubo Li
---
arch/arm/boot/dts/vf610-twr.dts | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index b8a5e8c..841a45a 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -61,7 +61,6 @@
sound {
compatible = "simple-audio-card";
- simple-audio-card,format = "i2s";
simple-audio-card,widgets =
"Microphone", "Microphone Jack",
"Headphone", "Headphone Jack",
@@ -74,17 +73,17 @@
"Headphone Jack", "HP_OUT",
"Speaker Ext", "LINE_OUT";
- simple-audio-card,cpu {
- sound-dai = <>;
- master-clkdir-out;
+ simple-audio-card,dai-link {
+ format = "i2s";
frame-master;
bitclock-master;
- };
- simple-audio-card,codec {
- sound-dai = <>;
- frame-master;
- bitclock-master;
+ cpu {
+ sound-dai = <>;
+ };
+ codec {
+ sound-dai = <>;
+ };
};
};
};
--
1.8.4
--
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/
[PATCHv1 0/7] simple-card: simplify the code.
Change in v1: - Add simple-card dts node patches. - Fix format parsing bug from Jean-Francois's comment. - Rebase to Kuninori-san's newest changes in next branch. Xiubo Li (7): ASoC: simple-card: Merge single and muti DAI link code. ASoC: simple-card: Adjust the comments of simple card. ASoC: dts: vf610-twr: To support simple card newest style. ASoC: dts: kirkwood-t5325: To support simple card newest style. ASoC: dts: r8a7740-armadillo800eva-reference: To support simple card newest style. ASoC: dts: sh73a0-kzm9g-reference: To support simple card newest style. ASoC: dts: kirkwood-openrd-client: To support simple card newest style. .../devicetree/bindings/sound/simple-card.txt | 101 ++-- arch/arm/boot/dts/kirkwood-openrd-client.dts | 15 +- arch/arm/boot/dts/kirkwood-t5325.dts | 15 +- .../boot/dts/r8a7740-armadillo800eva-reference.dts | 21 +-- arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 18 ++- arch/arm/boot/dts/vf610-twr.dts| 17 +- sound/soc/generic/simple-card.c| 176 - 7 files changed, 160 insertions(+), 203 deletions(-) -- 1.8.4 -- 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/
Re: [PATCH 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
Hi Greg,
On 2014-08-05 12:47, Marek Szyprowski wrote:
This patch adds a new flags for device drivers. This flag instructs
kernel that the device driver does it own management of IOMMU assisted
IO address space translations, so no default dma-mapping structures
should be initialized.
Signed-off-by: Marek Szyprowski
---
include/linux/device.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 5f4ff02..2e62371 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -253,6 +253,8 @@ struct device_driver {
/* disables bind/unbind via sysfs */
#define DRIVER_SUPPRESS_BIND_ATTRS(1 << 0)
+/* driver uses own methods to manage IO address space */
+#define DRIVER_HAS_OWN_IOMMU_MANAGER (1 << 1)
extern int __must_check driver_register(struct device_driver *drv);
extern void driver_unregister(struct device_driver *drv);
Could you comment if the approach of using flags in the struct driver
could be accepted? I've converted suppress_bind_attrs entry to flags to
avoid extending the structure, please see patch "[PATCH 05/29] drivers:
convert suppress_bind_attrs parameter into flags".
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
--
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/
[PATCHv1 1/7] ASoC: simple-card: Merge single and muti DAI link code.
This patch merge single DAI link and muti-DAI links code together, and simply the simple-card driver code. And also do some other improvement: Since from the DAI format micro SND_SOC_DAIFMT_CBx_CFx, the 'CBx' mean Codec's bit clock is as master/slave and the 'CFx' mean Codec's frame clock is as master/slave. So these same DAI formats should be informed to CPU and CODE DAIs at the same time. For the Codec driver will set the bit clock and frame clock as the DAI formats said, but for the CPU driver, if the the bit clock or frame clock is as Codec master, so it should be set CPU DAI device as bit clock or frame clock as slave, and vice versa. The old code will cause confusion, and we should be clear that the letter 'C' here mean to Codec. Signed-off-by: Xiubo Li Cc: Kuninori Morimoto Cc: Jean-Francois Moine Cc: Jyri Sarha Cc: Nicolin Chen --- .../devicetree/bindings/sound/simple-card.txt | 101 +++--- sound/soc/generic/simple-card.c| 152 +++-- 2 files changed, 102 insertions(+), 151 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index c2e9841..6cc44a6a 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -1,13 +1,12 @@ Simple-Card: + Simple-Card specifies audio DAI connections of SoC <-> codec. Required properties: - - compatible : "simple-audio-card" Optional properties: - - simple-audio-card,name : User specified audio sound card name, one string property. - simple-audio-card,widgets: Please refer to widgets.txt. @@ -18,68 +17,57 @@ Optional properties: - simple-audio-card,mclk-fs : Multiplication factor between stream rate and codec mclk. -Optional subnodes: - -- simple-audio-card,dai-link : Container for dai-link level - properties and the CPU and CODEC - sub-nodes. This container may be - omitted when the card has only one - DAI link. See the examples and the - section bellow. - -Dai-link subnode properties and subnodes: - -If dai-link subnode is omitted and the subnode properties are directly -under "sound"-node the subnode property and subnode names have to be -prefixed with "simple-audio-card,"-prefix. + +DAI link node(s) and its or their subnodes: -Required dai-link subnodes: +There must be one DAI link node exsit at least, and each DAI link must +contain one CPU subnode and one CODEC subnode. -- cpu : CPU sub-node -- codec: CODEC sub-node - -Optional dai-link subnode properties: +Required DAI link node(s): +- simple-audio-card,dai-link : Container for DAI link level + properties and the CPU and CODEC + sub-nodes. +Optional DAI link node properties: - format : CPU/CODEC common audio format. "i2s", "right_j", "left_j" , "dsp_a" "dsp_b", "ac97", "pdm", "msb", "lsb" -- frame-master : Indicates dai-link frame master. - phandle to a cpu or codec subnode. -- bitclock-master : Indicates dai-link bit clock master. - phandle to a cpu or codec subnode. -- bitclock-inversion : bool property. Add this if the - dai-link uses bit clock inversion. -- frame-inversion : bool property. Add this if the - dai-link uses frame clock inversion. - -For backward compatibility the frame-master and bitclock-master -properties can be used as booleans in codec subnode to indicate if the -codec is the dai-link frame or bit clock master. In this case there -should be no dai-link node, the same properties should not be present -at sound-node level, and the bitclock-inversion and frame-inversion -properties should also be placed in the codec node if needed. - -Required CPU/CODEC subnodes properties: - -- sound-dai: phandle and port of CPU/CODEC +- frame-master : Boolean property. If present, for this + DAI link the Codec DAI's frame will be + as master and the CPU DAI's frame will + be as slave, or vice versa. +- bitclock-master
[PATCHv1 6/7] ASoC: dts: sh73a0-kzm9g-reference: To support simple card newest style.
This patch depends on the following simple card patch:
===
ASoC: simple-card: Merge single and muti DAI link code.
This patch merge single DAI link and muti-DAI links code together,
and simply the simple-card driver code.
And also do some other improvement:
Since from the DAI format micro SND_SOC_DAIFMT_CBx_CFx, the 'CBx'
mean Codec's bit clock is as master/slave and the 'CFx' mean Codec's
frame clock is as master/slave.
So these same DAI formats should be informed to CPU and CODE DAIs at
the same time. For the Codec driver will set the bit clock and frame
clock as the DAI formats said, but for the CPU driver, if the the
bit clock or frame clock is as Codec master, so it should be set CPU
DAI device as bit clock or frame clock as slave, and vice versa.
The old code will cause confusion, and we should be clear that the
letter 'C' here mean to Codec.
===
Signed-off-by: Xiubo Li
---
arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index 18662ae..e689ae3 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -160,15 +160,19 @@
sound {
compatible = "simple-audio-card";
- simple-audio-card,format = "left_j";
- simple-audio-card,cpu {
- sound-dai = <_fsi2 0>;
- };
- simple-audio-card,codec {
- sound-dai = <>;
+
+ simple-audio-card,dai-link {
+ format = "left_j";
bitclock-master;
frame-master;
- system-clock-frequency = <11289600>;
+
+ cpu {
+ sound-dai = <_fsi2 0>;
+ };
+ codec {
+ sound-dai = <>;
+ system-clock-frequency = <11289600>;
+ };
};
};
};
--
1.8.4
--
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/
[PATCHv1 2/7] ASoC: simple-card: Adjust the comments of simple card.
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index d45c8dd..e9d5a69 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -131,7 +131,7 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
*daifmt &= ~(SND_SOC_DAIFMT_MASTER_MASK | SND_SOC_DAIFMT_FORMAT_MASK);
/*
-* get node via "sound-dai = < port>"
+* Get node via "sound-dai = < port>"
* it will be used as xxx_of_node on soc_bind_dai_link()
*/
node = of_parse_phandle(np, "sound-dai", 0);
@@ -139,12 +139,12 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
return -ENODEV;
*p_node = node;
- /* get dai->name */
+ /* Get dai->name */
ret = snd_soc_of_get_dai_name(np, name);
if (ret < 0)
return ret;
- /* parse TDM slot */
+ /* Parse TDM slot */
ret = snd_soc_of_parse_tdm_slot(np, >slots, >slot_width);
if (ret)
return ret;
@@ -189,7 +189,7 @@ static int asoc_simple_card_dai_link_of(struct device_node
*node,
daifmt &= (SND_SOC_DAIFMT_MASTER_MASK | SND_SOC_DAIFMT_FORMAT_MASK);
dai_props->cpu_dai.fmt = dai_props->codec_dai.fmt = daifmt;
- /* Parse CPU DAI */
+ /* Parse CPU DAI node */
np = of_get_child_by_name(node, "cpu");
if (!np) {
ret = -EINVAL;
@@ -207,7 +207,7 @@ static int asoc_simple_card_dai_link_of(struct device_node
*node,
dai_props->cpu_dai.fmt |= daifmt;
of_node_put(np);
- /* Parse CODEC DAI */
+ /* Parse CODEC DAI node */
np = of_get_child_by_name(node, "codec");
if (!np) {
ret = -EINVAL;
@@ -229,10 +229,10 @@ static int asoc_simple_card_dai_link_of(struct
device_node *node,
dai_props->codec_dai.fmt |= daifmt;
- /* simple-card assumes platform == cpu */
+ /* Simple Card assumes platform == cpu */
dai_link->platform_of_node = dai_link->cpu_of_node;
- /* Link name is created from CPU/CODEC dai name */
+ /* DAI Link's name is created from CPU/CODEC dai name */
name = devm_kzalloc(dev,
strlen(dai_link->cpu_dai_name) +
strlen(dai_link->codec_dai_name) + 2,
@@ -254,7 +254,7 @@ static int asoc_simple_card_dai_link_of(struct device_node
*node,
dai_props->codec_dai.sysclk);
/*
-* soc_bind_dai_link() will check cpu name
+* asoc_bind_dai_link() will check cpu name
* after of_node matching if dai_link has cpu_dai_name.
* but, it will never match if name was created by fmt_single_name()
* remove cpu_dai_name to escape name matching.
@@ -296,10 +296,10 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
u32 val;
int ret, i = 0;
- /* parsing the card name from DT */
+ /* Parse the card name from DT */
snd_soc_of_parse_card_name(>snd_card, "simple-audio-card,name");
- /* off-codec widgets */
+ /* Parse off-codec widgets */
if (of_property_read_bool(node, "simple-audio-card,widgets")) {
ret = snd_soc_of_parse_audio_simple_widgets(>snd_card,
"simple-audio-card,widgets");
@@ -352,13 +352,13 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
struct device *dev = >dev;
int num_links, ret;
- /* get the number of DAI links */
+ /* Get the number of DAI links */
if (np && of_get_child_by_name(np, "simple-audio-card,dai-link"))
num_links = of_get_child_count(np);
else
return -EINVAL;
- /* allocate the private data and the DAI link array */
+ /* Allocate the private data and the DAI link array */
priv = devm_kzalloc(dev,
sizeof(*priv) + sizeof(*dai_link) * num_links,
GFP_KERNEL);
@@ -366,7 +366,7 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
return -ENOMEM;
/*
-* init snd_soc_card
+* Init snd_soc_card
*/
priv->snd_card.owner = THIS_MODULE;
priv->snd_card.dev = dev;
@@ -374,7 +374,7 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
priv->snd_card.dai_link = dai_link;
priv->snd_card.num_links = num_links;
- /* get room for the other properties */
+ /* Get room for the other properties */
priv->dai_props = devm_kzalloc(dev,
sizeof(*priv->dai_props) * num_links,
GFP_KERNEL);
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCHv1 5/7] ASoC: dts: r8a7740-armadillo800eva-reference: To support simple card newest style.
This patch depends on the following simple card patch:
===
ASoC: simple-card: Merge single and muti DAI link code.
This patch merge single DAI link and muti-DAI links code together,
and simply the simple-card driver code.
And also do some other improvement:
Since from the DAI format micro SND_SOC_DAIFMT_CBx_CFx, the 'CBx'
mean Codec's bit clock is as master/slave and the 'CFx' mean Codec's
frame clock is as master/slave.
So these same DAI formats should be informed to CPU and CODE DAIs at
the same time. For the Codec driver will set the bit clock and frame
clock as the DAI formats said, but for the CPU driver, if the the
bit clock or frame clock is as Codec master, so it should be set CPU
DAI device as bit clock or frame clock as slave, and vice versa.
The old code will cause confusion, and we should be clear that the
letter 'C' here mean to Codec.
===
Signed-off-by: Xiubo Li
---
.../boot/dts/r8a7740-armadillo800eva-reference.dts | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index ee9e7d5..b83d95a 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -150,18 +150,19 @@
sound {
compatible = "simple-audio-card";
- simple-audio-card,format = "i2s";
-
- simple-audio-card,cpu {
- sound-dai = <_fsi2 0>;
- bitclock-inversion;
- };
-
- simple-audio-card,codec {
- sound-dai = <>;
+ simple-audio-card,dai-link {
+ format = "i2s";
bitclock-master;
frame-master;
- system-clock-frequency = <12288000>;
+
+ cpu {
+ sound-dai = <_fsi2 0>;
+ bitclock-inversion;
+ };
+ codec {
+ sound-dai = <>;
+ system-clock-frequency = <12288000>;
+ };
};
};
};
--
1.8.4
--
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/
[PATCHv1 7/7] ASoC: dts: kirkwood-openrd-client: To support simple card newest style.
This patch depends on the following simple card patch:
===
ASoC: simple-card: Merge single and muti DAI link code.
This patch merge single DAI link and muti-DAI links code together,
and simply the simple-card driver code.
And also do some other improvement:
Since from the DAI format micro SND_SOC_DAIFMT_CBx_CFx, the 'CBx'
mean Codec's bit clock is as master/slave and the 'CFx' mean Codec's
frame clock is as master/slave.
So these same DAI formats should be informed to CPU and CODE DAIs at
the same time. For the Codec driver will set the bit clock and frame
clock as the DAI formats said, but for the CPU driver, if the the
bit clock or frame clock is as Codec master, so it should be set CPU
DAI device as bit clock or frame clock as slave, and vice versa.
The old code will cause confusion, and we should be clear that the
letter 'C' here mean to Codec.
===
Signed-off-by: Xiubo Li
---
arch/arm/boot/dts/kirkwood-openrd-client.dts | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-openrd-client.dts
b/arch/arm/boot/dts/kirkwood-openrd-client.dts
index 887b9c1..3b6f169 100644
--- a/arch/arm/boot/dts/kirkwood-openrd-client.dts
+++ b/arch/arm/boot/dts/kirkwood-openrd-client.dts
@@ -33,15 +33,16 @@
sound {
compatible = "simple-audio-card";
- simple-audio-card,format = "i2s";
simple-audio-card,mclk-fs = <256>;
- simple-audio-card,cpu {
- sound-dai = <>;
- };
-
- simple-audio-card,codec {
- sound-dai = <>;
+ simple-audio-card,dai-link {
+ format = "i2s";
+ cpu {
+ sound-dai = <>;
+ };
+ codec {
+ sound-dai = <>;
+ };
};
};
};
--
1.8.4
--
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/
[PATCHv1 4/7] ASoC: dts: kirkwood-t5325: To support simple card newest style.
This patch depends on the following simple card patch:
===
ASoC: simple-card: Merge single and muti DAI link code.
This patch merge single DAI link and muti-DAI links code together,
and simply the simple-card driver code.
And also do some other improvement:
Since from the DAI format micro SND_SOC_DAIFMT_CBx_CFx, the 'CBx'
mean Codec's bit clock is as master/slave and the 'CFx' mean Codec's
frame clock is as master/slave.
So these same DAI formats should be informed to CPU and CODE DAIs at
the same time. For the Codec driver will set the bit clock and frame
clock as the DAI formats said, but for the CPU driver, if the the
bit clock or frame clock is as Codec master, so it should be set CPU
DAI device as bit clock or frame clock as slave, and vice versa.
The old code will cause confusion, and we should be clear that the
letter 'C' here mean to Codec.
===
Signed-off-by: Xiubo Li
---
arch/arm/boot/dts/kirkwood-t5325.dts | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-t5325.dts
b/arch/arm/boot/dts/kirkwood-t5325.dts
index 610ec0f..25d1223 100644
--- a/arch/arm/boot/dts/kirkwood-t5325.dts
+++ b/arch/arm/boot/dts/kirkwood-t5325.dts
@@ -189,7 +189,6 @@
sound {
compatible = "simple-audio-card";
- simple-audio-card,format = "i2s";
simple-audio-card,routing =
"Headphone Jack", "HPL",
"Headphone Jack", "HPR",
@@ -204,12 +203,14 @@
simple-audio-card,mclk-fs = <256>;
- simple-audio-card,cpu {
- sound-dai = <>;
- };
-
- simple-audio-card,codec {
- sound-dai = <>;
+ simple-audio-card,dai-link {
+ format = "i2s";
+ cpu {
+ sound-dai = <>;
+ };
+ codec {
+ sound-dai = <>;
+ };
};
};
};
--
1.8.4
--
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/
Re: [PATCH v2] cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec
Hi Viresh,
On Fri, 2014-08-29 at 05:33 +0530, Viresh Kumar wrote:
> On 28 August 2014 19:36, Shilpasri G Bhat
> wrote:
> >
> > Changes v1->v2:
> > Invoke .target() driver callback to set the cpus to nominal frequency
> > in reboot notifier, instead of calling cpufreq_suspend() as suggested
> > by Viresh Kumar.
> > Modified the commit message.
>
> This changelog will get commited, is this what you want?
> > + if (unlikely(rebooting) && new_index != get_nominal_index())
> > + return -EBUSY;
>
> Have you placed the unlikely only around 'rebooting' intentionally or
> should it cover whole if statement?
>
Yes unlikely() should cover the whole if statement. Thank you for pointing it
out.
I have corrected my mistake in the below patch.
Thanks and regards,
Shilpa
This patch ensures the cpus to kexec/reboot at nominal frequency.
Nominal frequency is the highest cpu frequency on PowerPC at
which the cores can run without getting throttled.
If the host kernel had set the cpus to a low pstate and then it
kexecs/reboots to a cpufreq disabled kernel it would cause the target
kernel to perform poorly. It will also increase the boot up time of
the target kernel. So set the cpus to high pstate, in this case to
nominal frequency before rebooting to avoid such scenarios.
The reboot notifier will set the cpus to nominal frequncy.
Changes v1->v2:
Invoke .target() driver callback to set the cpus to nominal frequency
in reboot notifier, instead of calling cpufreq_suspend() as suggested
by Viresh Kumar.
Modified the commit message.
Signed-off-by: Shilpasri G Bhat
Suggested-by: Viresh Kumar
Reviewed-by: Preeti U Murthy
---
drivers/cpufreq/powernv-cpufreq.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index 379c083..f8b83c8 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -35,6 +36,7 @@
#define POWERNV_MAX_PSTATES256
static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
+static bool rebooting;
/*
* Note: The set of pstates consists of contiguous integers, the
@@ -284,6 +286,15 @@ static void set_pstate(void *freq_data)
}
/*
+ * get_nominal_index: Returns the index corresponding to the nominal
+ * pstate in the cpufreq table
+ */
+static inline unsigned int get_nominal_index(void)
+{
+ return powernv_pstate_info.max - powernv_pstate_info.nominal;
+}
+
+/*
* powernv_cpufreq_target_index: Sets the frequency corresponding to
* the cpufreq table entry indexed by new_index on the cpus in the
* mask policy->cpus
@@ -293,6 +304,9 @@ static int powernv_cpufreq_target_index(struct
cpufreq_policy *policy,
{
struct powernv_smp_call_data freq_data;
+ if (unlikely(rebooting && new_index != get_nominal_index()))
+ return -EBUSY;
+
freq_data.pstate_id = powernv_freqs[new_index].driver_data;
/*
@@ -317,6 +331,25 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy
*policy)
return cpufreq_table_validate_and_show(policy, powernv_freqs);
}
+static int powernv_cpufreq_reboot_notifier(struct notifier_block *nb,
+ unsigned long action, void *unused)
+{
+ int cpu;
+ struct cpufreq_policy cpu_policy;
+
+ rebooting = true;
+ for_each_online_cpu(cpu) {
+ cpufreq_get_policy(_policy, cpu);
+ powernv_cpufreq_target_index(_policy, get_nominal_index());
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block powernv_cpufreq_reboot_nb = {
+ .notifier_call = powernv_cpufreq_reboot_notifier,
+};
+
static struct cpufreq_driver powernv_cpufreq_driver = {
.name = "powernv-cpufreq",
.flags = CPUFREQ_CONST_LOOPS,
@@ -342,12 +375,14 @@ static int __init powernv_cpufreq_init(void)
return rc;
}
+ register_reboot_notifier(_cpufreq_reboot_nb);
return cpufreq_register_driver(_cpufreq_driver);
}
module_init(powernv_cpufreq_init);
static void __exit powernv_cpufreq_exit(void)
{
+ unregister_reboot_notifier(_cpufreq_reboot_nb);
cpufreq_unregister_driver(_cpufreq_driver);
}
module_exit(powernv_cpufreq_exit);
--
1.9.3
--
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/
Re: [PATCH v4 0/6] kvm, mem-hotplug: Do not pin ept identity pagetable and apic access page.
Hi Gleb, Would you please help to review these patches ? Thanks. On 08/27/2014 06:17 PM, Tang Chen wrote: ept identity pagetable and apic access page in kvm are pinned in memory. As a result, they cannot be migrated/hot-removed. But actually they don't need to be pinned in memory. [For ept identity page] Just do not pin it. When it is migrated, guest will be able to find the new page in the next ept violation. [For apic access page] The hpa of apic access page is stored in VMCS APIC_ACCESS_ADDR pointer. When apic access page is migrated, we update VMCS APIC_ACCESS_ADDR pointer for each vcpu in addition. NOTE: Tested with -cpu xxx,-x2apic option. But since nested vm pins some other pages in memory, if user uses nested vm, memory hot-remove will not work. Change log v3 -> v4: 1. The original patch 6 is now patch 5. ( by Jan Kiszka ) 2. The original patch 1 is now patch 6 since we should unpin apic access page at the very last moment. Tang Chen (6): kvm: Use APIC_DEFAULT_PHYS_BASE macro as the apic access page address. kvm: Remove ept_identity_pagetable from struct kvm_arch. kvm: Make init_rmode_identity_map() return 0 on success. kvm, mem-hotplug: Reload L1' apic access page on migration in vcpu_enter_guest(). kvm, mem-hotplug: Reload L1's apic access page on migration when L2 is running. kvm, mem-hotplug: Do not pin apic access page in memory. arch/x86/include/asm/kvm_host.h | 3 +- arch/x86/kvm/svm.c | 15 +- arch/x86/kvm/vmx.c | 103 +++- arch/x86/kvm/x86.c | 22 +++-- include/linux/kvm_host.h| 3 ++ virt/kvm/kvm_main.c | 30 +++- 6 files changed, 135 insertions(+), 41 deletions(-) -- 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/
Re: early microcode: how to disable at runtime?
On Sun, Aug 31, 2014 at 05:11:26PM -0300, Henrique de Moraes Holschuh wrote: > > Probably more like something more like arch/x86/boot/cmdline.c. Maybe > > we could even make it sharable. > > Looks like that would work, yes. Guys, guys, please relax and check the code first: "dis_ucode_ldr". -- Regards/Gruss, Boris. -- -- 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/
[PATCH v2] DRBG: remove check for uninitialized DRBG handle
The drbg_healthcheck() contained a test to call the DRBG with an uninitialized DRBG cipher handle. As this is an inappropriate use of the kernel crypto API to try to generate random numbers before initialization, checks verifying for an initialized DRBG have been removed in previous patches. Now, the drbg_healthcheck test must also be removed. Changes V2: Added patch marker to email subject line. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index 39ed918..54cfd48 100644 --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1872,9 +1872,6 @@ static inline int __init drbg_healthcheck_sanity(void) /* overflow max addtllen with personalization string */ ret = drbg_instantiate(drbg, , coreref, pr); BUG_ON(0 == ret); - /* test uninstantated DRBG */ - len = drbg_generate(drbg, buf, (max_request_bytes + 1), NULL); - BUG_ON(0 < len); /* all tests passed */ rc = 0; -- 1.9.3 -- 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/
Re: [PATCH net-next v2] r8152: reduce the number of Tx
From: Hayes Wang Date: Mon, 1 Sep 2014 02:46:38 + > From: David Miller [mailto:da...@davemloft.net] > [...] >> This driver has a loop that iterates MAX_TX times to initialize both >> the RX and TX buffers. >> >> So if they are not equal, it can't possibly work. > > Excuse me. I don't find that the "RTL8152_MAX_TX" is used by > rx buffer. The rx buffer only use "RTL8152_MAX_RX". Although > the tx buffer size is determined by "rx_buf_sz", the tx buffers > are independent of rx buffers. Ok, but that is really confusing code. -- 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/
[PATCH] crypto: caam - Dynamic allocation of addresses for various memory blocks in CAAM.
CAAM's memory is broken into following address blocks:
Block Included Registers
0 General Registers
1-4 Job ring registers
6 RTIC registers
7 QI registers
8 DECO and CCB
Size of the above stated blocks varies in various platforms. The block size can
be 4K or 64K.
The block size can be dynamically determined by reading CTPR register in CAAM.
This patch initializes the block addresses dynamically based on the value read
from this register.
Signed-off-by: Ruchika Gupta
Signed-off-by: Nitesh Narayan Lal
---
drivers/crypto/caam/ctrl.c | 114 ++-
drivers/crypto/caam/intern.h | 9 ++--
drivers/crypto/caam/regs.h | 38 +++
3 files changed, 81 insertions(+), 80 deletions(-)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 3cade79..cd7af27 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -1,5 +1,4 @@
-/*
- * CAAM control-plane driver backend
+/* * CAAM control-plane driver backend
* Controller-level driver, kernel property detection, initialization
*
* Copyright 2008-2012 Freescale Semiconductor, Inc.
@@ -81,38 +80,37 @@ static inline int run_descriptor_deco0(struct device
*ctrldev, u32 *desc,
u32 *status)
{
struct caam_drv_private *ctrlpriv = dev_get_drvdata(ctrldev);
- struct caam_full __iomem *topregs;
+ struct caam_ctrl __iomem *ctrl = ctrlpriv->ctrl;
+ struct caam_deco __iomem *deco = ctrlpriv->deco;
unsigned int timeout = 10;
u32 deco_dbg_reg, flags;
int i;
- /* Set the bit to request direct access to DECO0 */
- topregs = (struct caam_full __iomem *)ctrlpriv->ctrl;
if (ctrlpriv->virt_en == 1) {
- setbits32(>ctrl.deco_rsr, DECORSR_JR0);
+ setbits32(>deco_rsr, DECORSR_JR0);
- while (!(rd_reg32(>ctrl.deco_rsr) & DECORSR_VALID) &&
+ while (!(rd_reg32(>deco_rsr) & DECORSR_VALID) &&
--timeout)
cpu_relax();
timeout = 10;
}
- setbits32(>ctrl.deco_rq, DECORR_RQD0ENABLE);
+ setbits32(>deco_rq, DECORR_RQD0ENABLE);
- while (!(rd_reg32(>ctrl.deco_rq) & DECORR_DEN0) &&
+ while (!(rd_reg32(>deco_rq) & DECORR_DEN0) &&
--timeout)
cpu_relax();
if (!timeout) {
dev_err(ctrldev, "failed to acquire DECO 0\n");
- clrbits32(>ctrl.deco_rq, DECORR_RQD0ENABLE);
+ clrbits32(>deco_rq, DECORR_RQD0ENABLE);
return -ENODEV;
}
for (i = 0; i < desc_len(desc); i++)
- wr_reg32(>deco.descbuf[i], *(desc + i));
+ wr_reg32(>descbuf[i], *(desc + i));
flags = DECO_JQCR_WHL;
/*
@@ -123,11 +121,11 @@ static inline int run_descriptor_deco0(struct device
*ctrldev, u32 *desc,
flags |= DECO_JQCR_FOUR;
/* Instruct the DECO to execute it */
- wr_reg32(>deco.jr_ctl_hi, flags);
+ wr_reg32(>jr_ctl_hi, flags);
timeout = 1000;
do {
- deco_dbg_reg = rd_reg32(>deco.desc_dbg);
+ deco_dbg_reg = rd_reg32(>desc_dbg);
/*
* If an error occured in the descriptor, then
* the DECO status field will be set to 0x0D
@@ -138,14 +136,14 @@ static inline int run_descriptor_deco0(struct device
*ctrldev, u32 *desc,
cpu_relax();
} while ((deco_dbg_reg & DESC_DBG_DECO_STAT_VALID) && --timeout);
- *status = rd_reg32(>deco.op_status_hi) &
+ *status = rd_reg32(>op_status_hi) &
DECO_OP_STATUS_HI_ERR_MASK;
if (ctrlpriv->virt_en == 1)
- clrbits32(>ctrl.deco_rsr, DECORSR_JR0);
+ clrbits32(>deco_rsr, DECORSR_JR0);
/* Mark the DECO as free */
- clrbits32(>ctrl.deco_rq, DECORR_RQD0ENABLE);
+ clrbits32(>deco_rq, DECORR_RQD0ENABLE);
if (!timeout)
return -EAGAIN;
@@ -176,13 +174,13 @@ static int instantiate_rng(struct device *ctrldev, int
state_handle_mask,
int gen_sk)
{
struct caam_drv_private *ctrlpriv = dev_get_drvdata(ctrldev);
- struct caam_full __iomem *topregs;
+ struct caam_ctrl __iomem *ctrl;
struct rng4tst __iomem *r4tst;
u32 *desc, status, rdsta_val;
int ret = 0, sh_idx;
- topregs = (struct caam_full __iomem *)ctrlpriv->ctrl;
- r4tst = >ctrl.r4tst[0];
+ ctrl = (struct caam_ctrl __iomem *)ctrlpriv->ctrl;
+ r4tst = >r4tst[0];
desc = kmalloc(CAAM_CMD_SZ * 7, GFP_KERNEL);
if (!desc)
@@ -212,12 +210,11 @@ static int instantiate_rng(struct device *ctrldev, int
state_handle_mask,
* CAAM eras),
RE: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
Sorry I forgot to add maintainer into CC.
+Lee Jones
Any comments on this patch.
As a lot of Exynos PMU patch sets are dependent on this patch.
Thanks,
Pankaj Dubey
> -Original Message-
> From: Pankaj Dubey [mailto:pankaj.du...@samsung.com]
> Sent: Friday, August 22, 2014 1:40 PM
> To: linux-arm-ker...@lists.infradead.org;
linux-samsung-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: kgene@samsung.com; li...@arm.linux.org.uk; a...@arndb.de;
> vikas.saj...@samsung.com; jo...@samsung.com; naus...@samsung.com;
> thomas...@samsung.com; chow@samsung.com; Tomasz Figa; Pankaj Dubey
> Subject: [PATCH] mfd: syscon: Decouple syscon interface from syscon
devices
>
> From: Tomasz Figa
>
> Currently a syscon entity can be only registered directly through a
platform device
> that binds to a dedicated driver. However in certain use cases it is
desirable to make a
> device used with another driver a syscon interface provider. For example,
certain
> SoCs (e.g. Exynos) contain system controller blocks which perform various
functions
> such as power domain control, CPU power management, low power mode
control,
> but in addition contain certain IP integration glue, such as various
signal masks,
> coprocessor power control, etc. In such case, there is a need to have a
dedicated
> driver for such system controller but also share registers with other
drivers. The latter
> is where the syscon interface is helpful.
>
> This patch decouples syscon object from syscon driver, so that it can be
registered
> from any driver in addition to the original "syscon" platform driver.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Pankaj Dubey
> ---
>
> RFC patch [1] was posted by Tomasz Figa. This patch addresses some of
comments
> given by Arnd to RFC patch, and further decouples syscon from device
model. It also
> gives flexibility of registering with syscon at early stage using
device_node object.
>
> [1]: https://lkml.org/lkml/2014/6/17/331
>
> drivers/mfd/syscon.c | 112
>
> include/linux/mfd/syscon.h | 14 ++
> 2 files changed, 86 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c index
ca15878..a91db30
> 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -14,6 +14,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -22,33 +23,32 @@
> #include
> #include
> #include
> +#include
>
> -static struct platform_driver syscon_driver;
> +static DEFINE_SPINLOCK(syscon_list_slock);
> +static LIST_HEAD(syscon_list);
>
> struct syscon {
> + struct device_node *np;
> struct regmap *regmap;
> + struct list_head list;
> };
>
> -static int syscon_match_node(struct device *dev, void *data) -{
> - struct device_node *dn = data;
> -
> - return (dev->of_node == dn) ? 1 : 0;
> -}
> -
> struct regmap *syscon_node_to_regmap(struct device_node *np) {
> - struct syscon *syscon;
> - struct device *dev;
> + struct syscon *entry, *syscon = NULL;
>
> - dev = driver_find_device(_driver.driver, NULL, np,
> - syscon_match_node);
> - if (!dev)
> - return ERR_PTR(-EPROBE_DEFER);
> + spin_lock(_list_slock);
>
> - syscon = dev_get_drvdata(dev);
> + list_for_each_entry(entry, _list, list)
> + if (entry->np == np) {
> + syscon = entry;
> + break;
> + }
>
> - return syscon->regmap;
> + spin_unlock(_list_slock);
> +
> + return syscon ? syscon->regmap : ERR_PTR(-EPROBE_DEFER);
> }
> EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
>
> @@ -68,24 +68,22 @@ struct regmap
> *syscon_regmap_lookup_by_compatible(const char *s) }
> EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
>
> -static int syscon_match_pdevname(struct device *dev, void *data) -{
> - return !strcmp(dev_name(dev), (const char *)data);
> -}
> -
> struct regmap *syscon_regmap_lookup_by_pdevname(const char *s) {
> - struct device *dev;
> - struct syscon *syscon;
> -
> - dev = driver_find_device(_driver.driver, NULL, (void *)s,
> - syscon_match_pdevname);
> - if (!dev)
> - return ERR_PTR(-EPROBE_DEFER);
> -
> - syscon = dev_get_drvdata(dev);
> + struct syscon *entry, *syscon = NULL;
> + struct platform_device *pdev = NULL;
> +
> + spin_lock(_list_slock);
> + list_for_each_entry(entry, _list, list) {
> + pdev = of_find_device_by_node(entry->np);
> + if (pdev && !strcmp(dev_name(>dev), s)) {
> + syscon = entry;
> + break;
> + }
> + }
> + spin_unlock(_list_slock);
>
> - return syscon->regmap;
> + return syscon ? syscon->regmap : ERR_PTR(-EPROBE_DEFER);
> }
> EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
>
> @@ -121,17 +119,49 @@ static
Re: [PATCH v2 4/6] block: loop: say goodby to bio
On Sun, Aug 31, 2014 at 6:14 AM, Elliott, Robert (Server Storage)
wrote:
>
>
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>> ow...@vger.kernel.org] On Behalf Of Ming Lei
>> Sent: Saturday, 30 August, 2014 11:08 AM
>> To: Jens Axboe; linux-kernel@vger.kernel.org; Dave Kleikamp
>> Cc: Zach Brown; Christoph Hellwig; Maxim Patlasov; Ming Lei
>> Subject: [PATCH v2 4/6] block: loop: say goodby to bio
> ...
>> -static int do_bio_filebacked(struct loop_device *lo, struct bio
>> *bio)
>> +static int do_req_filebacked(struct loop_device *lo, struct request
>> *rq)
>> {
>> loff_t pos;
>> int ret;
>>
>> - pos = ((loff_t) bio->bi_iter.bi_sector << 9) + lo->lo_offset;
>> + pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset;
>>
>> - if (bio_rw(bio) == WRITE) {
>> + if (rq->cmd_flags & REQ_WRITE) {
>> struct file *file = lo->lo_backing_file;
>>
>> - if (bio->bi_rw & REQ_FLUSH) {
>> + if (rq->cmd_flags & REQ_FLUSH) {
>> ret = vfs_fsync(file, 0);
>> if (unlikely(ret && ret != -EINVAL)) {
>> ret = -EIO;
>> @@ -436,7 +439,7 @@ static int do_bio_filebacked(struct loop_device
>> *lo, struct bio *bio)
>>* encryption is enabled, because it may give an attacker
>>* useful information.
>>*/
>> - if (bio->bi_rw & REQ_DISCARD) {
>> + if (rq->cmd_flags & REQ_DISCARD) {
>> struct file *file = lo->lo_backing_file;
>> int mode = FALLOC_FL_PUNCH_HOLE |
>> FALLOC_FL_KEEP_SIZE;
>
> Can a REQ_WRITE_SAME make it through to here?
It can't because loop doesn't support WRITE_SAME.
Thanks,
--
Ming Lei
--
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/
Re: [PATCH 0/6] hugepage migration fixes (v3)
On Sun, Aug 31, 2014 at 08:27:35AM -0700, Andi Kleen wrote: > Naoya Horiguchi writes: > > > This is the ver.3 of hugepage migration fix patchset. > > I wonder how far we are away from support THP migration with the > standard migrate_pages() syscall? I don't think that we are very far from this because we can borrow some code from migrate_misplaced_transhuge_page(), and the experience in hugetlb migration will be also helpful. The difficulties are rather in integrating thp support in the existing migrate code which is already very complicated, so careful code-reading and testing is necessary. This topic was in my agenda for long, but no highlight at this point. Thanks, Naoya Horiguchi -- 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/
Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle
On 08/29/2014 04:55 PM, Konrad Rzeszutek Wilk wrote: On Fri, Aug 29, 2014 at 03:44:06PM +0100, Jan Beulich wrote: On 29.08.14 at 16:27, wrote: Sure. Btw, someone also contacted me saying they have the same problem without changing the layout but having really big initrd (500M). While that feels like it should be impossible (if the kernel+initrd+xen stuff has to fix the 512M kernel image size area then). But if it can happen, then surely it does cause mappings to be where the module space starts then. Since the initrd doesn't really need to be mapped into the (limited) virtual address space a pv guest starts with, we specifically got /* * Whether or not the guest can deal with being passed an initrd not * mapped through its initial page tables. */ #define XEN_ELFNOTE_MOD_START_PFN 16 to deal with that situation. The hypervisor side for Dom0 is in place, and the kernel side works in our (classic) kernels. Whether it got implemented for DomU meanwhile I don't know; I'm pretty certain pv-ops kernels don't support it so far. Correct - Not implemented. Here is what I had mentioned in the past: (see http://lists.xen.org/archives/html/xen-devel/2014-03/msg00580.html) XEN_ELFNOTE_INIT_P2M, XEN_ELFNOTE_MOD_START_PFN - I had been looking at that but I can't figure out a nice way of implementing this without the usage of SPARSEMAP_VMAP virtual addresses - which is how the classic Xen does it. But then - I don't know who is using huge PV guests - as the PVHVM does a fine job? But then with PVH, now you can boot with large amount of memory (1TB?) - so some of these issues would go away? Except the 'large ramdisk' as that would eat in the MODULES_VADDR I think? Needs more thinking. .. and then I left it and to my suprise saw on Luis's slides that Jurgen is going to take a look at that (500GB support). I have a patch which should do the job. It is based on the classic kernel patch Jan mentioned above. The system is coming up with it, I haven't tested it with a huge initrd up to now. My plan was to post the patch together with the rest of the >500GB support, but I can send it on it's own if required. Juergen -- 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/
Re: Status of 'unicore32' architecture in Linux kernel
Firstly, what you have done encourage me, thanks. On 9/1/14 7:51, Guenter Roeck wrote: > Status of 'unicore32' architecture in Linux kernel > -- > > The idea was to create a working kernel and initramfs for the ongoing Linux > kernel test project. This summary describes the result of this effort. > > Overall, conclusion is that the architecture would need some work > (both in qemu and the kernel itself) to make it testable with qemu. > > Guenter > > - > Toolchain used was from [1]. I did not attempt to build my own toolchain. > I also use it, but for me, hope we can use an open source toolchain for it, in the future. If possible, I will be glad to join for it (develop open source unicore32 gcc cross compiler with other related members). > Configuration: > > make ARCH=unicore32 defconfig && make ARCH=unicore32 > > This configuration currently fails to build in the upstream kernel. > A patch to fix the problem has been submitted and is pending upstream > integration [2]. With this patch merged, the 'defconfig' image can > be built. > Thank you for what you have done. > > qemu > > Attempts to load the unicore32:defconfig image with qemu failed. > > Research points to [3], which includes a working unicore32 linux kernel > in its linux repository [4], in branch unicore32-working. This branch > includes a working unicore32 qemu configuration. It also includes > a critical patch which is not available in the upstream kernel. > > unicore32: Add ocd console and qemu-defconfig to support qemu simulator > This patch adds a primitive OCD console to communicate with qemu. > The same code is already used for early console support. > > With this patch added, and with qemu_defconfig as provided by the same patch, > it is possible to build and load a unicore32 image in qemu using the following > qemu command line. > > qemu-system-unicore32 -curses -M puv3 -m 512 -kernel > arch/unicore32/boot/zImage > For me, hope they also can be merged into upstream main line, next. > Caveats: > - The use of -nographic instead of -curses causes a qemu crash > - The qemu emulation only accepts a built-in initramfs. > - The only working image is arch/unicore32/boot/zImage. > All other variants, arch/unicore32/boot/Image and vmlinux, cause a crash. > The same (or a similar) crash is also seen if I don't provide a built-in > kernel command line and try to load zImage. > - There is no networking. There is another patch in the github linux > respository [4] which is not available upstream. The driver was submitted > for integration back in 2011 [5] but it was never accepted or merged. > For me, suggest also Cc to qemu-de...@nongnu.org, and gxt is the related maintainer for qemu unicore32, too. In the future (maybe several months later), I am glad to try to analyze these caveats (but excuse me, at present, I have no enough time resource on it). > [1] http://mprc.pku.edu.cn/~guanxuetao/linux/ > [2] https://lkml.org/lkml/2014/8/31/86 > [3] https://github.com/gxt > [4] git://github.com/gxt/linux.git > [5] https://lkml.org/lkml/2011/5/27/17 > Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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/
Re: Status of 'cris' architecture support in Linux kernel
Jesper is actually back at work today but give him a few days to catch up. > 31 aug 2014 kl. 20:51 skrev "Sam Ravnborg" : > >> On Sun, Aug 31, 2014 at 10:50:10AM -0700, Guenter Roeck wrote: >> The idea was to create a crisv32 kernel and initramfs to work with qemu >> for the ongoing Linux kernel test project. >> >> After spending a number of days (and nights) on it, the results don't look >> very encouraging. >> >> My overall conclusion is that 'cris' architecture support in the Linux kernel >> is in bad shape, does not work anymore, and would require substantial effort >> to get it into working state. >> >> Anyway, below are my individual findings. If there is an ongoing effort to >> improve cris support in the upstream kernel, specifically support for >> crisv32, >> please let me know. I'll be happy to test the resulting kernels. > > Jesper is on parental leave so do not expect any prompt reply from him. > >> >> Individual findings: >> >> headers_install >> >> make ARCH=cris INSTALL_HDR_PATH=/tmp headers_install >> >> results in: >> >> ./scripts/Makefile.headersinst:14: >> arch/cris/include/uapi/asm/arch-v10/Kbuild: >>No such file or directory >> make[2]: *** No rule to make target >> `arch/cris/include/uapi/asm/arch-v10/Kbuild'. Stop. > I have already sent a fix for this that Michael said he wanted to deal with. > >Sam -- 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/
[PATCH] perf/documentation: Fix typo in perf/Documentation
This patch fix spelling typo found in tool/perf/Documentation. Signed-off-by: Masanari Iida --- tools/perf/Documentation/perf-diff.txt | 6 +++--- tools/perf/Documentation/perf-kvm.txt | 4 ++-- tools/perf/Documentation/perf-list.txt | 2 +- tools/perf/Documentation/perf-record.txt| 2 +- tools/perf/Documentation/perf-script-perl.txt | 4 ++-- tools/perf/Documentation/perf-script-python.txt | 6 +++--- tools/perf/Documentation/perf-script.txt| 2 +- tools/perf/Documentation/perf-test.txt | 2 +- tools/perf/Documentation/perf-trace.txt | 2 +- 9 files changed, 15 insertions(+), 15 deletions(-) diff --git a/tools/perf/Documentation/perf-diff.txt b/tools/perf/Documentation/perf-diff.txt index b3b8aba..e463caa 100644 --- a/tools/perf/Documentation/perf-diff.txt +++ b/tools/perf/Documentation/perf-diff.txt @@ -196,10 +196,10 @@ If specified the 'Weighted diff' column is displayed with value 'd' computed as: - period being the hist entry period value - - WEIGHT-A/WEIGHT-B being user suplied weights in the the '-c' option + - WEIGHT-A/WEIGHT-B being user supplied weights in the the '-c' option behind ':' separator like '-c wdiff:1,2'. -- WIEGHT-A being the weight of the data file -- WIEGHT-B being the weight of the baseline data file +- WEIGHT-A being the weight of the data file +- WEIGHT-B being the weight of the baseline data file SEE ALSO diff --git a/tools/perf/Documentation/perf-kvm.txt b/tools/perf/Documentation/perf-kvm.txt index 6e689dc..6039eb0 100644 --- a/tools/perf/Documentation/perf-kvm.txt +++ b/tools/perf/Documentation/perf-kvm.txt @@ -100,7 +100,7 @@ OPTIONS STAT REPORT OPTIONS --- --vcpu=:: - analyze events which occures on this vcpu. (default: all vcpus) + analyze events which occurres on this vcpu. (default: all vcpus) --event=:: event to be analyzed. Possible values: vmexit, mmio (x86 only), @@ -134,7 +134,7 @@ STAT LIVE OPTIONS Analyze events only for given process ID(s) (comma separated list). --vcpu=:: - analyze events which occures on this vcpu. (default: all vcpus) + analyze events which occurres on this vcpu. (default: all vcpus) --event=:: diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt index 6fce6a6..cbb4f74 100644 --- a/tools/perf/Documentation/perf-list.txt +++ b/tools/perf/Documentation/perf-list.txt @@ -19,7 +19,7 @@ various perf commands with the -e option. EVENT MODIFIERS --- -Events can optionally have a modifer by appending a colon and one or +Events can optionally have a modifier by appending a colon and one or more modifiers. Modifiers allow the user to restrict the events to be counted. The following modifiers exist: diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt index d460049..398f8d5 100644 --- a/tools/perf/Documentation/perf-record.txt +++ b/tools/perf/Documentation/perf-record.txt @@ -146,7 +146,7 @@ the thread executes on the designated CPUs. Default is to monitor all CPUs. -N:: --no-buildid-cache:: -Do not update the builid cache. This saves some overhead in situations +Do not update the buildid cache. This saves some overhead in situations where the information in the perf.data file (which includes buildids) is sufficient. diff --git a/tools/perf/Documentation/perf-script-perl.txt b/tools/perf/Documentation/perf-script-perl.txt index d00bef2..dfbb506 100644 --- a/tools/perf/Documentation/perf-script-perl.txt +++ b/tools/perf/Documentation/perf-script-perl.txt @@ -181,8 +181,8 @@ strings for flag and symbolic fields. These correspond to the strings and values parsed from the 'print fmt' fields of the event format files: - flag_str($event_name, $field_name, $field_value) - returns the string represention corresponding to $field_value for the flag field $field_name of event $event_name - symbol_str($event_name, $field_name, $field_value) - returns the string represention corresponding to $field_value for the symbolic field $field_name of event $event_name + flag_str($event_name, $field_name, $field_value) - returns the string representation corresponding to $field_value for the flag field $field_name of event $event_name + symbol_str($event_name, $field_name, $field_value) - returns the string representation corresponding to $field_value for the symbolic field $field_name of event $event_name Perf::Trace::Context Module ~~~ diff --git a/tools/perf/Documentation/perf-script-python.txt b/tools/perf/Documentation/perf-script-python.txt index 9f1f054..54acba2 100644 --- a/tools/perf/Documentation/perf-script-python.txt +++ b/tools/perf/Documentation/perf-script-python.txt @@ -263,7 +263,7 @@ and having the counts we've tallied as values. The print_syscall_totals() function iterates over the entries in the dictionary and
[PATCH 4/4] staging: comedi: hwdrv_apci1500: miscellaneous cleanup
This patch completes two final matters of cleanup which are each too small
for their own patch. It corrects a couple of indentation issues and
removes a return statement at the end of a void function.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../staging/comedi/drivers/addi-data/hwdrv_apci1500.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
index d98636b..e637be1 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
@@ -986,7 +986,7 @@ static int apci1500_timer_config(struct comedi_device *dev,
devpriv->tsk_Current = current;
-/* Selection of the input clock */
+ /* Selection of the input clock */
if (data[0] == 0 || data[0] == 1 || data[0] == 2) {
outw(data[0], devpriv->i_IobaseAddon + APCI1500_CLK_SELECT);
} else {
@@ -2180,7 +2180,6 @@ static void apci1500_interrupt(int irq, void *d)
"Interrupt from unknown source\n");
}
- return;
}
static int apci1500_reset(struct comedi_device *dev)
@@ -2329,36 +2328,36 @@ static int apci1500_reset(struct comedi_device *dev)
outb(0, devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
/* reset all the digital outputs */
outw(0x0, devpriv->i_IobaseAddon + APCI1500_DIGITAL_OP);
-/* Disable the board interrupt */
+ /* Disable the board interrupt */
/* Selects the master interrupt control register */
outb(APCI1500_RW_MASTER_INTERRUPT_CONTROL,
devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
-/* Deactivates all interrupts */
+ /* Deactivates all interrupts */
outb(0, devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
/* Selects the command and status register of port A */
outb(APCI1500_RW_PORT_A_COMMAND_AND_STATUS,
devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
-/* Deactivates all interrupts */
+ /* Deactivates all interrupts */
outb(0x00, devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
/* Selects the command and status register of port B */
outb(APCI1500_RW_PORT_B_COMMAND_AND_STATUS,
devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
-/* Deactivates all interrupts */
+ /* Deactivates all interrupts */
outb(0x00, devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
/* Selects the command and status register of timer 1 */
outb(APCI1500_RW_CPT_TMR1_CMD_STATUS,
devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
-/* Deactivates all interrupts */
+ /* Deactivates all interrupts */
outb(0x00, devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
/* Selects the command and status register of timer 2 */
outb(APCI1500_RW_CPT_TMR2_CMD_STATUS,
devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
-/* Deactivates all interrupts */
+ /* Deactivates all interrupts */
outb(0x00, devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
-/* Selects the command and status register of timer 3*/
+ /* Selects the command and status register of timer 3*/
outb(APCI1500_RW_CPT_TMR3_CMD_STATUS,
devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
-/* Deactivates all interrupts */
+ /* Deactivates all interrupts */
outb(0x00, devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
return 0;
}
--
2.1.0
--
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/
[PATCH 3/4] staging: comedi: hwdrv_apci1500: clean some whitespace style issues
Now that commented out code has been removed, else statements can move to
the same line as the close brace of the if statement. Also, a blank line
has been added between declarations and code where needed.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../comedi/drivers/addi-data/hwdrv_apci1500.c | 139 -
1 file changed, 49 insertions(+), 90 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
index 031882e..d98636b 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
@@ -172,12 +172,10 @@ static int apci1500_di_config(struct comedi_device *dev,
if (data[0] == 1) {
i_MaxChannel = 8;
- }
- else {
+ } else {
if (data[0] == 2) {
i_MaxChannel = 6;
- }
- else {
+ } else {
dev_warn(dev->hw_dev,
"The specified port event does not exist\n");
return -EINVAL;
@@ -347,8 +345,7 @@ static int apci1500_di_config(struct comedi_device *dev,
devpriv->iobase +
APCI1500_Z8536_CONTROL_REGISTER);
- }
- else {
+ } else {
dev_warn(dev->hw_dev,
"The choice for interrupt logic does not
exist\n");
return -EINVAL;
@@ -448,8 +445,7 @@ static int apci1500_di_config(struct comedi_device *dev,
outb(0xF4,
devpriv->iobase +
APCI1500_Z8536_CONTROL_REGISTER);
- }
- else {
+ } else {
dev_warn(dev->hw_dev,
"The choice for interrupt logic does not
exist\n");
return -EINVAL;
@@ -518,8 +514,7 @@ static int apci1500_di_write(struct comedi_device *dev,
devpriv->iobase +
APCI1500_Z8536_CONTROL_REGISTER);
- }
- else {
+ } else {
dev_warn(dev->hw_dev,
"Event 1 not initialised\n");
return -EINVAL;
@@ -555,15 +550,13 @@ static int apci1500_di_write(struct comedi_device *dev,
devpriv->iobase +
APCI1500_Z8536_CONTROL_REGISTER);
i_Event2InterruptStatus = 1;
- }
- else {
+ } else {
dev_warn(dev->hw_dev,
"Event 2 not initialised\n");
return -EINVAL;
}
}
- }
- else {
+ } else {
dev_warn(dev->hw_dev,
"The port parameter is in error\n");
return -EINVAL;
@@ -600,8 +593,7 @@ static int apci1500_di_write(struct comedi_device *dev,
devpriv->iobase +
APCI1500_Z8536_CONTROL_REGISTER);
i_Event1InterruptStatus = 0;
- }
- else {
+ } else {
dev_warn(dev->hw_dev,
"Event 1 not initialised\n");
return -EINVAL;
@@ -630,16 +622,15 @@ static int apci1500_di_write(struct comedi_device *dev,
devpriv->iobase +
APCI1500_Z8536_CONTROL_REGISTER);
i_Event2InterruptStatus = 0;
- }
- else {
+ } else {
+
dev_warn(dev->hw_dev,
"Event 2 not initialised\n");
return -EINVAL;
}
}
- }
- else {
+ } else {
dev_warn(dev->hw_dev,
"The port parameter is in error\n");
[PATCH 0/4] staging: comedi: hwdrv_apci1500: coding style cleanups
This patchset begins by removing unneeded braces and commented out lines of code, and then tidies whitespace issues that are revealed after the braces/dead code is removed. Chase Southwood (4): staging: comedi: hwdrv_apci1500: remove unneeded braces staging: comedi: hwdrv_apci1500: remove commented out code staging: comedi: hwdrv_apci1500: clean some whitespace style issues staging: comedi: hwdrv_apci1500: miscellaneous cleanup .../comedi/drivers/addi-data/hwdrv_apci1500.c | 349 + 1 file changed, 149 insertions(+), 200 deletions(-) -- 2.1.0 -- 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/
[PATCH 1/4] staging: comedi: hwdrv_apci1500: remove unneeded braces
We don't need braces around single-statement blocks.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../comedi/drivers/addi-data/hwdrv_apci1500.c | 30 +-
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
index 1e2fe66..3cc827e 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
@@ -835,10 +835,9 @@ static int apci1500_do_write(struct comedi_device *dev,
unsigned int ui_Temp1;
unsigned int ui_NoOfChannel = CR_CHAN(insn->chanspec); /* get the
channel */
- if (!devpriv->b_OutputMemoryStatus) {
+ if (!devpriv->b_OutputMemoryStatus)
ui_Temp = 0;
- } /* if(!devpriv->b_OutputMemoryStatus ) */
if (data[3] == 0) {
if (data[1] == 0) {
data[0] = (data[0] << ui_NoOfChannel) | ui_Temp;
@@ -1502,12 +1501,11 @@ static int apci1500_timer_write(struct comedi_device
*dev,
switch (data[1]) {
case START:
if (i_TimerCounter1Init == 1) {
- if (i_TimerCounterWatchdogInterrupt == 1) {
+ if (i_TimerCounterWatchdogInterrupt == 1)
i_CommandAndStatusValue = 0xC4; /*
Enable the interrupt */
- } /*
if(i_TimerCounterWatchdogInterrupt==1) */
- else {
+ else
i_CommandAndStatusValue = 0xE4; /*
disable the interrupt */
- } /*
elseif(i_TimerCounterWatchdogInterrupt==1) */
+
/* Starts timer/counter 1 */
i_TimerCounter1Enabled = 1;
/* Selects the commands and status register */
@@ -1578,12 +1576,11 @@ static int apci1500_timer_write(struct comedi_device
*dev,
switch (data[1]) {
case START:
if (i_TimerCounter2Init == 1) {
- if (i_TimerCounterWatchdogInterrupt == 1) {
+ if (i_TimerCounterWatchdogInterrupt == 1)
i_CommandAndStatusValue = 0xC4; /*
Enable the interrupt */
- } /*
if(i_TimerCounterWatchdogInterrupt==1) */
- else {
+ else
i_CommandAndStatusValue = 0xE4; /*
disable the interrupt */
- } /*
elseif(i_TimerCounterWatchdogInterrupt==1) */
+
/* Starts timer/counter 2 */
i_TimerCounter2Enabled = 1;
/* Selects the commands and status register */
@@ -1652,12 +1649,11 @@ static int apci1500_timer_write(struct comedi_device
*dev,
case START:
if (i_WatchdogCounter3Init == 1) {
- if (i_TimerCounterWatchdogInterrupt == 1) {
+ if (i_TimerCounterWatchdogInterrupt == 1)
i_CommandAndStatusValue = 0xC4; /*
Enable the interrupt */
- } /*
if(i_TimerCounterWatchdogInterrupt==1) */
- else {
+ else
i_CommandAndStatusValue = 0xE4; /*
disable the interrupt */
- } /*
elseif(i_TimerCounterWatchdogInterrupt==1) */
+
/* Starts Watchdog/counter 3 */
i_WatchdogCounter3Enabled = 1;
/* Selects the commands and status register */
@@ -2208,12 +2204,10 @@ static void apci1500_interrupt(int irq, void *d)
outb(i_RegValue,
devpriv->iobase +
APCI1500_Z8536_CONTROL_REGISTER);
- if (i_CounterLogic == APCI1500_COUNTER) {
+ if (i_CounterLogic == APCI1500_COUNTER)
i_InterruptMask = i_InterruptMask | 0x10;
- } /* if(i_CounterLogic==APCI1500_COUNTER) */
- else {
+ else
i_InterruptMask = i_InterruptMask | 0x20;
- }
} /* if ((i_RegValue & 0x60) == 0x60) */
send_sig(SIGIO, devpriv->tsk_Current, 0); /* send signal
to the sample */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe
[PATCH 2/4] staging: comedi: hwdrv_apci1500: remove commented out code
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../comedi/drivers/addi-data/hwdrv_apci1500.c | 249 ++---
1 file changed, 123 insertions(+), 126 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
index 3cc827e..031882e 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
@@ -172,17 +172,17 @@ static int apci1500_di_config(struct comedi_device *dev,
if (data[0] == 1) {
i_MaxChannel = 8;
- } /* if (data[0] == 1) */
+ }
else {
if (data[0] == 2) {
i_MaxChannel = 6;
- } /* if(data[0]==2) */
+ }
else {
dev_warn(dev->hw_dev,
"The specified port event does not exist\n");
return -EINVAL;
- } /* else if(data[0]==2) */
- } /* else if (data[0] == 1) */
+ }
+ }
switch (data[1]) {
case 0:
data[1] = APCI1500_AND;
@@ -197,7 +197,7 @@ static int apci1500_di_config(struct comedi_device *dev,
dev_warn(dev->hw_dev,
"The specified interrupt logic does not exist\n");
return -EINVAL;
- } /* switch(data[1]); */
+ }
i_Logic = data[1];
for (i_Count = i_MaxChannel, i = 0; i_Count > 0; i_Count--, i++) {
@@ -242,8 +242,8 @@ static int apci1500_di_config(struct comedi_device *dev,
dev_warn(dev->hw_dev,
"The option indicated in the event mask does
not exist\n");
return -EINVAL;
- } /* switch(i_EventMask) */
- } /* for (i_Count = i_MaxChannel; i_Count
>0;i_Count --) */
+ }
+ }
if (data[0] == 1) {
/* Test the interrupt logic */
@@ -259,7 +259,7 @@ static int apci1500_di_config(struct comedi_device *dev,
dev_warn(dev->hw_dev,
"Transition error on an OR PRIORITY
logic\n");
return -EINVAL;
- } /* if (data[1]== APCI1500_OR_PRIORITY &&
i_PatternTransition != 0) */
+ }
/* Tests if more than one transition */
/* was declared for an AND logic */
@@ -271,14 +271,14 @@ static int apci1500_di_config(struct comedi_device *dev,
((i_PatternTransition >>
i_Count) & 0x1);
- } /* for (i_Count = 0; i_Count < 8;
i_Count++) */
+ }
if (i_PatternTransitionCount > 1) {
dev_warn(dev->hw_dev,
"Transition error on an AND
logic\n");
return -EINVAL;
- } /* if (i_PatternTransitionCount > 1) */
- } /* if (data[1]== APCI1500_AND) */
+ }
+ }
/* Selects the APCI1500_RW_MASTER_CONFIGURATION_CONTROL
register */
outb(APCI1500_RW_MASTER_CONFIGURATION_CONTROL,
@@ -347,13 +347,13 @@ static int apci1500_di_config(struct comedi_device *dev,
devpriv->iobase +
APCI1500_Z8536_CONTROL_REGISTER);
- } /*
if(data[1]==APCI1500_AND||data[1]==APCI1500_OR||data[1]==APCI1500_OR_PRIORITY)
*/
+ }
else {
dev_warn(dev->hw_dev,
"The choice for interrupt logic does not
exist\n");
return -EINVAL;
- } /* else }//
if(data[1]==APCI1500_AND||data[1]==APCI1500_OR||data[1]==APCI1500_OR_PRIORITY)
*/
- } /*if (data[0]== 1) */
+ }
+ }
/* Test if event setting for port 2 */
@@ -448,13 +448,13 @@ static int apci1500_di_config(struct comedi_device *dev,
outb(0xF4,
devpriv->iobase +
APCI1500_Z8536_CONTROL_REGISTER);
- } /* if (data[1] == APCI1500_OR) */
+ }
else {
dev_warn(dev->hw_dev,
"The choice for interrupt logic does not
exist\n");
[PATCH] staging: comedi: hwdrv_apci3501: change printk to dev_err
dev_err() is preferred to printk() in device drivers.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
drivers/staging/comedi/drivers/addi-data/hwdrv_apci3501.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3501.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3501.c
index e82c3fc..339519a 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3501.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3501.c
@@ -168,7 +168,7 @@ static int apci3501_read_insn_timer(struct comedi_device
*dev,
else if ((devpriv->b_TimerSelectMode != ADDIDATA_TIMER)
&& (devpriv->b_TimerSelectMode != ADDIDATA_WATCHDOG)) {
- printk("\nIn ReadTimerCounterWatchdog :: Invalid Subdevice \n");
+ dev_err(dev->class_dev, "Invalid subdevice.\n");
}
return insn->n;
}
--
2.1.0
--
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/
[SMP BUG?] the return value of is_smp() is bug?
Hi,all
In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
in .config file. the secondary core can not boot.
when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file,
the secondary core can boot.
But this does not happen in kernel 3.10 lts kernel, Whether the
CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot.
Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in kernel
3.17-rc2 ?
I write the following patch to test the return value of is_smp().
Signed-off-by: Wang Long
---
arch/arm/kernel/setup.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 84db893d..fbeb67f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -925,6 +925,11 @@ void __init setup_arch(char **cmdline_p)
arm_dt_init_cpu_maps();
psci_init();
#ifdef CONFIG_SMP
+
+ if (is_smp() == 1)
+ printk("is_smp() return true;\n");
+ else if (is_smp() == 0)
+ printk("is_smp() return false;\n");
if (is_smp()) {
if (!mdesc->smp_init || !mdesc->smp_init()) {
if (psci_smp_available())
kernel version: 3.17-rc2
config: set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
command:# qemu-system-arm -M vexpress-a9 -smp 2 -m 128M -kernel
arch/arm/boot/zImage -nographic
The output:
..
is_smp() return false;
CPU: Testing write buffer coherency: ok
missing device node for CPU 0
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting up static identity map for 0x604643d8 - 0x60464430
Brought up 1 CPUs
SMP: Total of 1 processors activated.
CPU: All CPU(s) started in SVC mode.
...
config: set CONFIG_HAVE_SMP = y and not set CONFIG_SMP_ON_UP
command:# qemu-system-arm -M vexpress-a9 -smp 2 -m 128M -kernel
arch/arm/boot/zImage -nographic
The output:
.
Memory policy: Data cache writealloc
is_smp() return true;
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
..
..
CPU: Testing write buffer coherency: ok
missing device node for CPU 0
missing device node for CPU 1
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting up static identity map for 0x60463ef8 - 0x60463f50
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 8001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
...
Any ideas?
--
1.7.9.5
--
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/
[PATCH] staging: comedi: hwdrv_apci035: remove useless return statement
Checkpatch pointed out a void function with a return statement. It can be removed. Signed-off-by: Chase Southwood Cc: Ian Abbott Cc: H Hartley Sweeten --- drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c index cad33f1..53bb51b 100644 --- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c +++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c @@ -477,6 +477,4 @@ static void apci035_interrupt(int irq, void *d) /* send signal to the sample */ send_sig(SIGIO, devpriv->tsk_Current, 0); } - - return; } -- 2.1.0 -- 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/
RE: SEA& AIR & COURIER FREIGHT FORWARDER IN CHINA
Dear Sir, Good day! I'm Rain Mao from Shenzhen Top Way International Forwarding Co.,ltd We are providing the best service for Air and sea shipment from all cities of China Our competitive advantages : 1. Full container shipment china ports to central and south American ports 2. DHL,UPS,FEDEX courier door to door price 30% discount to worldwide 3. Door to door sea freight cargo Guangzhou to Singapore,Thailand,Malaysia 4. Free samples & small orders consolidation service. 5. 15 days free warehousing. PS: Special sea freight by CMA CGM from China to North Africa, Black Sea,Adriatic Sea and Russia inland ports. To view more details, plz click in: www.topwayfreight.com Thanks regards Ms.Rain Shenzhen Top Way International Forwarding Co., Ltd MOBILE:+86-13528787227 TEL:+86-755-89367755-802 Email:r...@topwayfreight.com Skype:rain-blestocean QQ:840626628 website: topwayfreight.com http://hkkingway.en.alibaba.com
RE: [PATCH 3/3] GPIO: gpio-dwapb: Suspend & Resume PM enabling
> > +/* Store GPIO context across system-wide suspend/resume transitions
> > +*/ static struct gpio_saved_regs {
> > + unsigned long data;
> > + unsigned long dir;
> > + unsigned long int_en;
> > + unsigned long int_mask;
> > + unsigned long int_type;
> > + unsigned long int_pol;
> > + unsigned long int_deb;
> > +} saved_regs;
> > +
> > +static int dwapb_gpio_suspend(struct device *dev) {
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct dwapb_gpio *gpio = platform_get_drvdata(pdev);
> > + struct bgpio_chip *bgc = >ports[0].bgc;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(>lock, flags);
> > +
> > + saved_regs.int_mask = dwapb_read(gpio, GPIO_INTMASK);
> > + saved_regs.int_en = dwapb_read(gpio, GPIO_INTEN);
> > + saved_regs.int_deb = dwapb_read(gpio, GPIO_PORTA_DEBOUNCE);
> > + saved_regs.int_pol = dwapb_read(gpio, GPIO_INT_POLARITY);
> > + saved_regs.int_type = dwapb_read(gpio, GPIO_INTTYPE_LEVEL);
> > + saved_regs.dir = dwapb_read(gpio, GPIO_SWPORTA_DDR);
> > + saved_regs.data = dwapb_read(gpio, GPIO_SWPORTA_DR);
>
> Hello,
>
> The DesignWare GPIO IP can be configured to have ports a, b, c, and d. So you
> will need to save and restore any ports that are present. I think that *some*
> configurations of the IP include a register that can tell us how it was
> configured,
> but that register is also optional :) I don't have confidence that we can
> read/write the registers blindly whether they are known to be there or not.
> So you may be stuck with looking at the device tree or platform data to know
> whether banks b, c, or d exist.
>
>From the code, the device node has one property for port index. If the index
>is '0', then it is port A.
So I think we can store the status according to the port index.
--
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/
[SMP BUG?] the return value of is_smp() is bug?
Hi,all
In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
in .config file. the secondary core can not boot.
when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file,
the secondary core can boot.
But this does not happen in kernel 3.10 lts kernel, Whether the
CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot.
Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in kernel
3.17-rc2 ?
I write the following patch to test the return value of is_smp().
Signed-off-by: Wang Long
---
arch/arm/kernel/setup.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 84db893d..fbeb67f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -925,6 +925,11 @@ void __init setup_arch(char **cmdline_p)
arm_dt_init_cpu_maps();
psci_init();
#ifdef CONFIG_SMP
+
+ if (is_smp() == 1)
+ printk("is_smp() return true;\n");
+ else if (is_smp() == 0)
+ printk("is_smp() return false;\n");
if (is_smp()) {
if (!mdesc->smp_init || !mdesc->smp_init()) {
if (psci_smp_available())
kernel version: 3.17-rc2
config: set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
command:# qemu-system-arm -M vexpress-a9 -smp 2 -m 128M -kernel
arch/arm/boot/zImage -nographic
The output:
..
is_smp() return false;
CPU: Testing write buffer coherency: ok
missing device node for CPU 0
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting up static identity map for 0x604643d8 - 0x60464430
Brought up 1 CPUs
SMP: Total of 1 processors activated.
CPU: All CPU(s) started in SVC mode.
...
config: set CONFIG_HAVE_SMP = y and not set CONFIG_SMP_ON_UP
command:# qemu-system-arm -M vexpress-a9 -smp 2 -m 128M -kernel
arch/arm/boot/zImage -nographic
The output:
.
Memory policy: Data cache writealloc
is_smp() return true;
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
..
..
CPU: Testing write buffer coherency: ok
missing device node for CPU 0
missing device node for CPU 1
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting up static identity map for 0x60463ef8 - 0x60463f50
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 8001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
...
Any ideas?
--
1.7.9.5
--
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/
Re: [RFC PATCH v2 4/4] ftracetest: Add XFAIL/XPASS/UNSUPPORTED as result code
(2014/08/29 10:05), Shuah Khan wrote:
> On 08/26/2014 05:15 AM, Masami Hiramatsu wrote:
>> Add XFAIL, XPASS and UNSUPPORTED as a result code. These are
>> used for the results that test case is expected to fail or
>> unsupported feature (by config).
>> This also introduces PASS/FAIL/XFAIL/XPASS/UNSUP result codes
>> for each testcase. Since the results are not binary, each
>> testcase must use these code to return the test result.
>>
>> Signed-off-by: Masami Hiramatsu
>> ---
>> tools/testing/ftrace/ftracetest| 61
>> +++-
>> tools/testing/ftrace/test.d/basic1.tc |6 ++
>> tools/testing/ftrace/test.d/basic2.tc |6 +-
>> tools/testing/ftrace/test.d/basic3.tc |9 ++-
>> .../testing/ftrace/test.d/kprobe/add_and_remove.tc | 15 +++--
>> tools/testing/ftrace/test.d/kprobe/busy_check.tc | 20 +++
>> tools/testing/ftrace/test.d/template |6 ++
>> 7 files changed, 84 insertions(+), 39 deletions(-)
>>
>> diff --git a/tools/testing/ftrace/ftracetest
>> b/tools/testing/ftrace/ftracetest
>> index 0378c8a..bfcd56a 100755
>> --- a/tools/testing/ftrace/ftracetest
>> +++ b/tools/testing/ftrace/ftracetest
>> @@ -107,22 +107,53 @@ catlog() { #file
>> }
>>
>> # Testcase management
>> +# Test result codes
>> +PASS=0 # The test succeeded.
>> +FAIL=1 # The test failed, but was expected to succeed.
>> +XFAIL=2 # The test failed, and was expected to fail.
>> +XPASS=3 # The test succeeded, but was expected to fail.
>
> This one is confusing. It is still a failure. XFAIL case is
> expected to fail, using that convention XPASS should be
> expected to pass?
I see, but they have been already used as above by Dejagnu testing framework.
http://www.delorie.com/gnu/docs/dejagnu/dejagnu_6.html
Of course, it might be better to support only POSIX compatible results at
first.
> Can we use XFAIL0 for XFAIL pass case and XFAIL1 for XFAIL fail
> case?
No, new definition can confuse developers.
To avoid confusion, I'd like to use the same definitions as Dejegnu does.
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
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/
[PATCH v2] arm64: fix bug for reloading FPSIMD state after cpu power off
Now arm64 defers reloading FPSIMD state, but this optimization also introduces the bug after cpu resume back from low power mode. The reason is after the cpu has been powered off, s/w need set the cpu's fpsimd_last_state to NULL so that it will force to reload FPSIMD state for the thread, otherwise there has the chance to meet the condition for both the task's fpsimd_state.cpu field contains the id of the current cpu, and the cpu's fpsimd_last_state per-cpu variable points to the task's fpsimd_state, so finally kernel will skip to reload the context during it return back to userland. Signed-off-by: Leo Yan --- arch/arm64/kernel/fpsimd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index ad8aebb..3dca156 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -270,6 +270,7 @@ static int fpsimd_cpu_pm_notifier(struct notifier_block *self, case CPU_PM_ENTER: if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE)) fpsimd_save_state(>thread.fpsimd_state); + this_cpu_write(fpsimd_last_state, NULL); break; case CPU_PM_EXIT: if (current->mm) -- 1.9.1 -- 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/
RE: [PATCH 2/3] GPIO: gpio-dwapb: Support Debounce
> > > > I don't understand the reason for adding dwapb_read and dwapb_write here. > > The rest of the driver is using readl and writel. I'd rather not see > > two different methods being used in the same driver for register access. > > Maybe I'm missing something, but if we need to add dwapb_read/write, > > then it should be used for all register access. > > Alan, it was my proposal. I rather agree that is better to convert all > accesses to > that. OK, I will convert all readl to dwapb_read_write.
Re: workqueue: WARN at at kernel/workqueue.c:2176
Hi, Peter
Could you make a patch for it, please? Jason J. Herne's test showed we
addressed the bug. But the fix is not in kernel yet. Some new highly
related reports are come up again.
I don't want to argue any more, no matter how the patch will be,
I will accept. And please add the following tags in your patch:
Reported-by: Sasha Levin
Reported-by: Jason J. Herne
Tested-by: Jason J. Herne
Acked-by: Lai Jiangshan
Thanks,
Lai
On 06/06/2014 09:36 PM, Peter Zijlstra wrote:
> On Thu, Jun 05, 2014 at 06:54:35PM +0800, Lai Jiangshan wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 268a45e..d05a5a1 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1474,20 +1474,24 @@ static int ttwu_remote(struct task_struct *p, int
>> wake_flags)
>> }
>>
>> #ifdef CONFIG_SMP
>> -static void sched_ttwu_pending(void)
>> +static void sched_ttwu_pending_locked(struct rq *rq)
>> {
>> -struct rq *rq = this_rq();
>> struct llist_node *llist = llist_del_all(>wake_list);
>> struct task_struct *p;
>>
>> -raw_spin_lock(>lock);
>> -
>> while (llist) {
>> p = llist_entry(llist, struct task_struct, wake_entry);
>> llist = llist_next(llist);
>> ttwu_do_activate(rq, p, 0);
>> }
>> +}
>>
>> +static void sched_ttwu_pending(void)
>> +{
>> +struct rq *rq = this_rq();
>> +
>> +raw_spin_lock(>lock);
>> +sched_ttwu_pending_locked(rq);
>> raw_spin_unlock(>lock);
>> }
>
> OK, so this won't apply to a recent kernel.
>
>> @@ -4530,6 +4534,11 @@ int set_cpus_allowed_ptr(struct task_struct *p, const
>> struct cpumask *new_mask)
>> goto out;
>>
>> dest_cpu = cpumask_any_and(cpu_active_mask, new_mask);
>> +
>> +/* Ensure it is on rq for migration if it is waking */
>> +if (p->state == TASK_WAKING)
>> +sched_ttwu_pending_locked(rq);
>
> So I would really rather like to avoid this if possible, its doing full
> remote queueing, exactly what we tried to avoid.
>
>> +
>> if (p->on_rq) {
>> struct migration_arg arg = { p, dest_cpu };
>> /* Need help from migration thread: drop lock and wait. */
>> @@ -4576,6 +4585,10 @@ static int __migrate_task(struct task_struct *p, int
>> src_cpu, int dest_cpu)
>> if (!cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
>> goto fail;
>>
>> +/* Ensure it is on rq for migration if it is waking */
>> +if (p->state == TASK_WAKING)
>> +sched_ttwu_pending_locked(rq_src);
>> +
>> /*
>> * If we're not on a rq, the next wake-up will ensure we're
>> * placed properly.
>
> Oh man, another variant.. why did you change it again? And without
> explanation for why you changed it.
>
> I don't see a reason to call sched_ttwu_pending() with rq->lock held,
> seeing as how we append to that list without it held.
>
> I'm still thinking the previous version is good, can you explain why you
> changed it?
>
>
>
>
>
>
> .
>
--
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/
RE: [RFC][PATCH] ASoC: simple-card: Merge single and muti DAI link code.
> > ---
> >
> > Hi,
> >
> > This patch will break the old DT, so i just send one RFC version, and
> > will add the old DT patches in next version if this patch can work
> > well.
> >
> > Any comments and advices are welcome.
>
> Hi Xiubo,
>
> My DT is
>
> sound {
> compatible = "simple-audio-card";
> simple-audio-card,name = "Cubox Audio";
>
> simple-audio-card,dai-link@0 { /* I2S - HDMI */
> format = "i2s";
> cpu {
> sound-dai = < 0>;
> };
> codec {
> sound-dai = < 0>;
> };
> };
> ...
>
> I was getting 0x1001 as the format (codec clk & FRM master and i2s').
>
> With your patch, I get 0x4000 (clk master & frame slave and no format).
>
Well, yes, If your DAI link's bit clock & frame using the CODEC as master,
You should specify it in your DAI link node like:
> sound {
> compatible = "simple-audio-card";
> simple-audio-card,name = "Cubox Audio";
>
> simple-audio-card,dai-link@0 { /* I2S - HDMI */
> format = "i2s";
> cpu {
> sound-dai = < 0>;
> };
> codec {
> sound-dai = < 0>;
> };
bitclock-master;
frame-master;
> };
> ...
And the reason for cannot parsing the "i2s" format is that there is one bug
in this patch and I will fix it in next version.
Thanks very much for your comment.
BRs
Xiubo
Re: [PATCH 1/1] mtd: cfi_cmdset_0002:add fixup for Micron M29EW after erase operation
On Monday, September 01, 2014 11:21 AM, Bean Huo wrote:
>
> For Micron M29EW,20ms delay is needed after erase operation.
You already added the reason to cfi_fixup_m29ew_delay_after_erase().
However, please add the comment to this commit message.
>
> Signed-off-by: BeanHuo
BeanHuo/Bean Huo
Others look good.
Best regards,
Jingoo Han
> ---
> drivers/mtd/chips/cfi_cmdset_0002.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
> b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 5a4bfe3..9b0de91 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -509,6 +509,16 @@ static void cfi_fixup_m29ew_delay_after_resume(struct
> cfi_private *cfi)
> cfi_udelay(500);
> }
>
> +static void cfi_fixup_m29ew_delay_after_erase(struct cfi_private *cfi)
> +{
> + /*
> + * Resolving the Delay After ERASE Issue @low temperature.
> + * 20ms delay is needed after erase operation.
> + */
> + if (is_m29ew(cfi))
> + cfi_udelay(2);
> +}
> +
> struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary) {
> struct cfi_private *cfi = map->fldrv_priv; @@ -2397,6 +2407,7 @@ static
> int __xipram
> do_erase_oneblock(struct map_info *map, struct flchip *chip,
> ret = -EIO;
> }
>
> + cfi_fixup_m29ew_delay_after_erase(cfi);
> chip->state = FL_READY;
> DISABLE_VPP(map);
> put_chip(map, chip, adr);
> --
> 1.7.9.5
--
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/
RE: [PATCH net-next v2] r8152: reduce the number of Tx
From: David Miller [mailto:da...@davemloft.net] [...] > This driver has a loop that iterates MAX_TX times to initialize both > the RX and TX buffers. > > So if they are not equal, it can't possibly work. Excuse me. I don't find that the "RTL8152_MAX_TX" is used by rx buffer. The rx buffer only use "RTL8152_MAX_RX". Although the tx buffer size is determined by "rx_buf_sz", the tx buffers are independent of rx buffers. Best Regards, Hayes -- 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/
Re: [PATCH v2 5/7] Adding SKY81452 regulator device tree bindings document
Please ingnore 'only' this patch.
When sky81452-regulator driver was applied before,
The previous version of this document 'sky81452-regulator.txt' was applied.
I will resubmit the changes as incremental patches against current code of
sky81452-regulator.txt.
I am sorry for confusiong.
Thank you.
On Thu, Aug 28, 2014 at 07:58:38PM +0900, Gyungoh Yoo wrote:
> v2:
> Added 'compatible' attribute in child drivers
>
> ---
> .../bindings/regulator/sky81452-regulator.txt | 18
> ++
> 1 file changed, 18 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/regulator/sky81452-regulator.txt
>
> diff --git
> a/Documentation/devicetree/bindings/regulator/sky81452-regulator.txt
> b/Documentation/devicetree/bindings/regulator/sky81452-regulator.txt
> new file mode 100644
> index 000..7b9ff18
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/sky81452-regulator.txt
> @@ -0,0 +1,18 @@
> +SKY81452 voltage regulator
> +
> +Required properties:
> +- compatible : Must be "skyworks,sky81452-regulator"
> +- any required generic properties defined in regulator.txt
> +
> +Optional properties:
> +- any available generic properties defined in regulator.txt
> +
> +Example:
> +
> + regulator {
> + compatible = "skyworks,sky81452-regulator";
> + /* generic regulator properties */
> + regulator-name = "touch_en";
> + regulator-min-microvolt = <450>;
> + regulator-max-microvolt = <800>;
> + };
> --
> 1.9.1
>
--
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/
[PATCH v2.2 2/2] dt-bindings: Adding compatible attribute for SKY81452 regulator
Adding compatible attribute for SKY81452 regulator driver.
---
Documentation/devicetree/bindings/regulator/sky81452-regulator.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/regulator/sky81452-regulator.txt
b/Documentation/devicetree/bindings/regulator/sky81452-regulator.txt
index f98b5ed..7b9ff18 100644
--- a/Documentation/devicetree/bindings/regulator/sky81452-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/sky81452-regulator.txt
@@ -1,6 +1,7 @@
SKY81452 voltage regulator
Required properties:
+- compatible : Must be "skyworks,sky81452-regulator"
- any required generic properties defined in regulator.txt
Optional properties:
@@ -8,7 +9,8 @@ Optional properties:
Example:
- regualtor {
+ regulator {
+ compatible = "skyworks,sky81452-regulator";
/* generic regulator properties */
regulator-name = "touch_en";
regulator-min-microvolt = <450>;
--
1.9.1
--
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/
[PATCH v2.2 1/2] regulator: sky81452: Adding compatible attribute in DT
Adding compatible attriubute in DT.
Fixed typo.
---
drivers/regulator/sky81452-regulator.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/sky81452-regulator.c
b/drivers/regulator/sky81452-regulator.c
index 97aff0c..b9c54c6 100644
--- a/drivers/regulator/sky81452-regulator.c
+++ b/drivers/regulator/sky81452-regulator.c
@@ -68,12 +68,11 @@ static const struct regulator_desc sky81452_reg = {
static struct regulator_init_data *sky81452_reg_parse_dt(struct device *dev)
{
struct regulator_init_data *init_data;
- struct device_node *np;
+ struct device_node *np = of_node_get(dev->of_node);
- np = of_get_child_by_name(dev->parent->of_node, "regulator");
- if (unlikely(!np)) {
+ if (!np) {
dev_err(dev, "regulator node not found");
- return NULL;
+ return ERR_PTR(-ENODATA);
}
init_data = of_get_regulator_init_data(dev, np);
@@ -107,17 +106,28 @@ static int sky81452_reg_probe(struct platform_device
*pdev)
config.regmap = dev_get_drvdata(dev->parent);
rdev = devm_regulator_register(dev, _reg, );
- if (IS_ERR(rdev))
+ if (IS_ERR(rdev)) {
+ dev_err(dev, "failed to register regulator:%d", PTR_ERR(rdev));
return PTR_ERR(rdev);
+ }
platform_set_drvdata(pdev, rdev);
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id sky81452_reg_of_match[] = {
+ { .compatible = "skyworks,sky81452-regulator", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sky81452_reg_of_match);
+#endif
+
static struct platform_driver sky81452_reg_driver = {
.driver = {
.name = "sky81452-regulator",
+ .of_match_table = of_match_ptr(sky81452_reg_of_match),
},
.probe = sky81452_reg_probe,
};
@@ -127,4 +137,4 @@ module_platform_driver(sky81452_reg_driver);
MODULE_DESCRIPTION("Skyworks SKY81452 Regulator driver");
MODULE_AUTHOR("Gyungoh Yoo ");
MODULE_LICENSE("GPL");
-MODULE_VERSION("1.0");
+MODULE_VERSION("1.1");
--
1.9.1
--
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/
[PATCH v2.2 0/2] regulator: sky81452: Adding compatible attribute in DT document
Adding comptiable attribute in DT document. Splitted the patches for each subsystem. Fixed typo in DT document. Gyungoh Yoo (2): regulator: sky81452: Adding compatible attribute in DT dt-bindings: Adding compatible attribute for SKY81452 regulator .../bindings/regulator/sky81452-regulator.txt | 4 +++- drivers/regulator/sky81452-regulator.c | 22 -- 2 files changed, 19 insertions(+), 7 deletions(-) -- 1.9.1 -- 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/
Re: [PATCH] earlyprintk: re-enable earlyprintk calling early_param
On Fri, 29 Aug 2014, Stephen Warren wrote:
On 08/28/2014 11:28 PM, Sahara wrote:
On Wed, 27 Aug 2014, Thierry Reding wrote:
On Thu, Aug 14, 2014 at 07:13:36PM +0900, kpark3...@gmail.com wrote:
From: Sahara
Although there are many obs_kernel_param and its names are
earlyprintk and also EARLY_PRINTK is also enabled, we could not
see the early_printk output properly until now. This patch
considers earlycon as well as earlyprintk.
Signed-off-by: Sahara
---
init/main.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/init/main.c b/init/main.c
index bb1aed9..235d248 100644
--- a/init/main.c
+++ b/init/main.c
@@ -426,7 +426,8 @@ static int __init do_early_param(char *param, char
*val, const char *unused)
for (p = __setup_start; p < __setup_end; p++) {
if ((p->early && parameq(param, p->str)) ||
(strcmp(param, "console") == 0 &&
- strcmp(p->str, "earlycon") == 0)
+ ((strcmp(p->str, "earlycon") == 0) ||
+ (strcmp(p->str, "earlyprintk") == 0)))
) {
if (p->setup_func(val) != 0)
pr_warn("Malformed early option '%s'\n",
param);
It seems like this patch causes the following warning for me during
boot:
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.17.0-rc2-next-20140827
(thierry.reding@ulmo) (gcc version 4.9.0 (GCC) ) #18 SMP PREEMPT Wed Aug
27 17:08:12 CEST 2014
[0.00] CPU: ARMv7 Processor [413fc0f3] revision 3 (ARMv7),
cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
cache
[0.00] Machine model: NVIDIA Tegra124 Jetson TK1
[0.00] bootconsole [earlycon0] enabled
[0.00] debug: ignoring loglevel setting.
[0.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at
/home/thierry.reding/src/kernel/linux-work.git/kernel/printk/printk.c:2402
register_console+0x60/0x37c()
[0.00] console 'earlycon0' already registered
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
3.17.0-rc2-next-20140827 #18
[0.00] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[0.00] [] (show_stack) from []
(dump_stack+0x98/0xd8)
[0.00] [] (dump_stack) from []
(warn_slowpath_common+0x70/0x8c)
[0.00] [] (warn_slowpath_common) from []
(warn_slowpath_fmt+0x30/0x40)
[0.00] [] (warn_slowpath_fmt) from []
(register_console+0x60/0x37c)
[0.00] [] (register_console) from []
(setup_early_printk+0x20/0x28)
[0.00] [] (setup_early_printk) from []
(do_early_param+0x6c/0xd0)
[0.00] [] (do_early_param) from []
(parse_args+0x238/0x3d0)
[0.00] [] (parse_args) from []
(parse_early_options+0x38/0x40)
[0.00] [] (parse_early_options) from []
(parse_early_param+0x30/0x40)
[0.00] [] (parse_early_param) from []
(setup_arch+0x4b4/0x974)
[0.00] [] (setup_arch) from []
(start_kernel+0x98/0x3a8)
[0.00] [] (start_kernel) from [<80008074>]
(0x80008074)
[0.00] ---[ end trace cb88537fdc8fa200 ]---
[0.00] cma: Reserved 128 MiB at a780
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 524032
[0.00] free_area_init_node: node 0, pgdat c091cc00, node_mem_map
e67b7000
[0.00] Normal zone: 1520 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 194560 pages, LIFO batch:31
[0.00] HighMem zone: 2574 pages used for memmap
[0.00] HighMem zone: 329472 pages, LIFO batch:31
[0.00] PERCPU: Embedded 8 pages/cpu @e6767000 s8832 r8192 d15744
u32768
[0.00] pcpu-alloc: s8832 r8192 d15744 u32768 alloc=8*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 522512
[0.00] Kernel command line: console=ttyS0,115200n8
ignore_loglevel rootwait ro earlyprintk ip=:eth0:dhcp root=/dev/nfs
nfsroot=192.168.69.100:/srv/nfs/tegra124 drm.debug=0xf cma=128M
Reverting the patch eliminates the warning. earlyprintk does work fine
for me without this patch.
Thierry
This warning message is caused by specifying 'earlyprintk' in
your command line args. Same problem may happen if you specify 'earlycon'
in your command line args and enable CONFIG_SERIAL_EARLYCON with
the current code without this patch. I think it's appropriate result
letting a developer know that both ways of using earlyprintk are enabled.
With current code, although a developer enables CONFIG_EARLY_PRINTK and
has "console=" arg in command line args, he/she should specify the
'earlyprintk' in command line args also to see early_printk() outputs.
With this patch, simply enabling CONFIG_EARLY_PRINTK and having 'console='
line make you be able
[PATCHv2 1/2] ASoC: simple-card: Fix bug of forgetting decrement DT node's refcount
We shouldn't forget decrement the last DT node when the
for_each_child_of_node() has finished searching.
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index fd8b045..9e170fe 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -360,6 +360,7 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
}
i++;
}
+ of_node_put(np);
} else {
ret = asoc_simple_card_dai_link_of(node, dev,
dai_link, dai_props, true);
--
1.8.4
--
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/
[PATCHv2 2/2] ASoC: simple-card: Fix bug of wrong decrement DT node's refcount
DAI links's cpu_of_node's and codec_of_node's refcounts shouldn't
be decremented immediately at the end of the probe() fucntion.
Because we will still use them before the audio card is removed.
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 52 ++---
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 9e170fe..08c5d7d 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -307,6 +307,22 @@ dai_link_of_err:
return ret;
}
+static inline void
+asoc_simple_card_unref(const struct snd_soc_dai_link *dai_link,
+ int num_links)
+{
+ struct device_node *np;
+
+ while (num_links--) {
+ np = dai_link[num_links].cpu_of_node;
+ if (np)
+ of_node_put(np);
+ np = dai_link[num_links].codec_of_node;
+ if (np)
+ of_node_put(np);
+ }
+}
+
static int asoc_simple_card_parse_of(struct device_node *node,
struct simple_card_data *priv,
struct device *dev,
@@ -355,6 +371,7 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
dai_props + i,
false);
if (ret < 0) {
+ asoc_simple_card_unref(dai_link, i + 1);
of_node_put(np);
return ret;
}
@@ -374,27 +391,6 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
return 0;
}
-/* update the reference count of the devices nodes at end of probe */
-static int asoc_simple_card_unref(struct platform_device *pdev)
-{
- struct snd_soc_card *card = platform_get_drvdata(pdev);
- struct snd_soc_dai_link *dai_link;
- struct device_node *np;
- int num_links;
-
- for (num_links = 0, dai_link = card->dai_link;
-num_links < card->num_links;
-num_links++, dai_link++) {
- np = (struct device_node *) dai_link->cpu_of_node;
- if (np)
- of_node_put(np);
- np = (struct device_node *) dai_link->codec_of_node;
- if (np)
- of_node_put(np);
- }
- return 0;
-}
-
static int asoc_simple_card_probe(struct platform_device *pdev)
{
struct simple_card_data *priv;
@@ -441,7 +437,7 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
if (ret < 0) {
if (ret != -EPROBE_DEFER)
dev_err(dev, "parse error %d\n", ret);
- goto err;
+ return ret;
}
} else {
@@ -483,11 +479,18 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
ret = devm_snd_soc_register_card(>dev, >snd_card);
-err:
- asoc_simple_card_unref(pdev);
return ret;
}
+static int asoc_simple_card_remove(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+ asoc_simple_card_unref(card->dai_link, card->num_links);
+
+ return 0;
+}
+
static const struct of_device_id asoc_simple_of_match[] = {
{ .compatible = "simple-audio-card", },
{},
@@ -501,6 +504,7 @@ static struct platform_driver asoc_simple_card = {
.of_match_table = asoc_simple_of_match,
},
.probe = asoc_simple_card_probe,
+ .remove = asoc_simple_card_remove,
};
module_platform_driver(asoc_simple_card);
--
1.8.4
--
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/
[PATCHv2 0/2] ASoC: simple-card: Fix bug about DT node's refcount
Change for v2: - Just rebased to the next branch newest head. Xiubo Li (2): ASoC: simple-card: Fix bug of forgetting decrement DT node's refcount ASoC: simple-card: Fix bug of wrong decrement DT node's refcount sound/soc/generic/simple-card.c | 53 ++--- 1 file changed, 29 insertions(+), 24 deletions(-) -- 1.8.4 -- 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/
[PATCH 1/1] mtd: cfi_cmdset_0002:add fixup for Micron M29EW after erase operation
For Micron M29EW,20ms delay is needed after erase operation.
Signed-off-by: BeanHuo
---
drivers/mtd/chips/cfi_cmdset_0002.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
b/drivers/mtd/chips/cfi_cmdset_0002.c
index 5a4bfe3..9b0de91 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -509,6 +509,16 @@ static void cfi_fixup_m29ew_delay_after_resume(struct
cfi_private *cfi)
cfi_udelay(500);
}
+static void cfi_fixup_m29ew_delay_after_erase(struct cfi_private *cfi)
+{
+ /*
+* Resolving the Delay After ERASE Issue @low temperature.
+* 20ms delay is needed after erase operation.
+*/
+ if (is_m29ew(cfi))
+ cfi_udelay(2);
+}
+
struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary) {
struct cfi_private *cfi = map->fldrv_priv; @@ -2397,6 +2407,7 @@ static
int __xipram do_erase_oneblock(struct map_info *map, struct flchip *chip,
ret = -EIO;
}
+ cfi_fixup_m29ew_delay_after_erase(cfi);
chip->state = FL_READY;
DISABLE_VPP(map);
put_chip(map, chip, adr);
--
1.7.9.5
--
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/
Re: [RFC 1/2] USB: OTG: Hold wakeupsource when VBUS present
On Fri, Aug 22, 2014 at 03:19:32PM +0530, Kiran Kumar Raparthy wrote:
> From: Todd Poynor
>
> USB: OTG: Hold wakeupsource when VBUS present
>
It is not related to OTG, would you change a name?
> Enabled by default, can disable with:
>echo N > /sys/module/otg_wakeupsource/parameters/enabled
>
> This is one of the number of patches from the Android AOSP common.git tree,
> which is used on almost all Android devices. so I wanted to submit it for
> review to see if it should go upstream.
>
> Cc: Felipe Balbi
> Cc: Greg Kroah-Hartman
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: Android Kernel Team
> Cc: John Stultz
> Cc: Arve Hj�nnev�g
> Cc: Benoit Goby
> Signed-off-by: Todd Poynor
> Signed-off-by: Kiran Raparthy
> [kiran: Added context to commit message
> Included build fix from Benoit Goby and Arve Arve Hj�nnev�g
> Removed lock->held field in driver as this mechanism is provided in
> wakeup.c
> wakelock(wl) terminology replaced with wakeup_source(ws)
> sys entry(module param) field modified to otg_wakeupsource
> __pm_stay_awake and __pm_relax called directly from the main
> code instead of calling them via otgws_grab,otgws_drop]
> ---
> drivers/usb/phy/Kconfig| 8 ++
> drivers/usb/phy/Makefile | 1 +
> drivers/usb/phy/otg-wakeupsource.c | 171
> +
> 3 files changed, 180 insertions(+)
> create mode 100644 drivers/usb/phy/otg-wakeupsource.c
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index e253fa0..9c747b2 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -6,6 +6,14 @@ menu "USB Physical Layer drivers"
> config USB_PHY
> def_bool n
>
> +config USB_OTG_WAKEUPSOURCE
> + bool "Hold a wakeupsource when USB connected"
> + depends on PM_SLEEP
> + select USB_PHY
> + help
> + Select this to automatically hold a wakeupsource when USB is
> + connected, preventing suspend.
> +
I think it is a common driver, the UDC drivers are its best user, we
may only want to prevent the system entering suspend after UDC get
enumerated, not only just vbus is present, the PHY driver should not know
the UDC get enumerated or not, the state of enumeration belongs to
chapter 9 at USB 2.0 spec.
Peter
> #
> # USB Transceiver Drivers
> #
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index 24a9133..ca2fbaf 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -3,6 +3,7 @@
> #
> obj-$(CONFIG_USB_PHY)+= phy.o
> obj-$(CONFIG_OF) += of.o
> +obj-$(CONFIG_USB_OTG_WAKEUPSOURCE) += otg-wakeupsource.o
>
> # transceiver drivers, keep the list sorted
>
> diff --git a/drivers/usb/phy/otg-wakeupsource.c
> b/drivers/usb/phy/otg-wakeupsource.c
> new file mode 100644
> index 000..fa44e11
> --- /dev/null
> +++ b/drivers/usb/phy/otg-wakeupsource.c
> @@ -0,0 +1,171 @@
> +/*
> + * otg-wakeupsource.c
> + *
> + * Copyright (C) 2011 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that 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.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static bool enabled = true;
> +static struct usb_phy *otgws_xceiv;
> +static struct notifier_block otgws_nb;
> +
> +
> +static DEFINE_SPINLOCK(otgws_spinlock);
> +
> +/*
> + * Only one lock, but since these 2 fields are associated with each other...
> + */
> +
> +struct otgws_lock {
> + char name[40];
> + struct wakeup_source wsource;
> +};
> +
> +/*
> + * VBUS present lock.
> + */
> +
> +static struct otgws_lock vbus_lock;
> +
> +static int otgws_otg_notifications(struct notifier_block *nb,
> +unsigned long event, void *unused)
> +{
> + unsigned long irqflags;
> +
> + if (!enabled)
> + return NOTIFY_OK;
> +
> + spin_lock_irqsave(_spinlock, irqflags);
> +
> + switch (event) {
> + case USB_EVENT_VBUS:
> + case USB_EVENT_ENUMERATED:
> + __pm_stay_awake(_lock.wsource);
> + break;
> +
> + case USB_EVENT_NONE:
> + case USB_EVENT_ID:
> + case USB_EVENT_CHARGER:
> + __pm_relax(_lock.wsource);
> + break;
> +
> + default:
> + break;
> + }
> +
> + spin_unlock_irqrestore(_spinlock, irqflags);
> + return NOTIFY_OK;
> +}
> +
> +static void sync_with_xceiv_state(void)
> +{
> + if ((otgws_xceiv->last_event == USB_EVENT_VBUS) ||
> +
[PATCH V1] regulator: DA9211 : remove an unneeded semicolon
This is a patch for removing an unneeded semicolon. Signed-off-by: James Ban --- This patch is relative to linux-next repository tag next-20140829. drivers/regulator/da9211-regulator.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/da9211-regulator.c b/drivers/regulator/da9211-regulator.c index 5aabbac..9722728 100644 --- a/drivers/regulator/da9211-regulator.c +++ b/drivers/regulator/da9211-regulator.c @@ -278,7 +278,7 @@ static struct da9211_pdata *da9211_parse_regulators_dt( pdata->init_data[n] = da9211_matches[i].init_data; n++; - }; + } return pdata; } -- end-of-patch for regulator: DA9211 : remove an unneeded semicolon V1 -- 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/
RE: [RFC][PATCH] ASoC: simple-card: Merge single and muti DAI link code.
Hi Mark, Kuninori-san, Very sorry, I just missed that patch series. See the next version. Thanks, BRs Xiubo > -Original Message- > From: Mark Brown [mailto:broo...@kernel.org] > Sent: Friday, August 29, 2014 8:01 PM > To: Xiubo Li-B47053 > Cc: alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org; > devicet...@vger.kernel.org; Kuninori Morimoto; Jean-Francois Moine; Jyri > Sarha; > Nicolin Chen > Subject: Re: [RFC][PATCH] ASoC: simple-card: Merge single and muti DAI link > code. > > On Fri, Aug 29, 2014 at 02:46:37PM +0800, Xiubo Li wrote: > > This patch merge single DAI link and muti-DAI links code together, > > and simply the simple-card driver code. > > This will need to be rebased on Morimoto-san's changes I believe. -- 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/
Re: [PATCH v1] arm64: fix bug for reloading FPSIMD state after cpu power off
On 09/01/2014 06:11 AM, Catalin Marinas wrote:
On 31 Aug 2014, at 06:39, Leo Yan wrote:
Now arm64 defers reloading FPSIMD state, but this optimization also
introduces the bug after cpu resume back from low power mode.
You are right, I can see a bug here.
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index ad8aebb..4caef93 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -268,13 +268,9 @@ static int fpsimd_cpu_pm_notifier(struct notifier_block
*self,
{
switch (cmd) {
case CPU_PM_ENTER:
- if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE))
- fpsimd_save_state(>thread.fpsimd_state);
That’s needed if we enter a low power state directly from a task with
a valid mm (user). I’m not sure that’s possible, but just in case.
u are right, in some special cases (such like IKS, etc) a normal thread
also may call cpu_suspend() function so that it will run here; i will
commit another patch to reserve this part.
+ this_cpu_write(fpsimd_last_state, NULL);
That’s correct. In most cases, we enter low power state from the idle
thread which does not have an mm, so the CPU_PM_EXIT case wouldn’t set
a TIF_FOREIGN_FPSTATE, so thread switching would not detect the change.
break;
case CPU_PM_EXIT:
- if (current->mm)
- set_thread_flag(TIF_FOREIGN_FPSTATE);
See above for why this may still be needed (it case it returns to user
directly without fpsimd_thread_switch() to detect fpsimd_last_state).
Will reserve this part as well.
Thanks,
Leo Yan
--
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/
Re: [PATCH v2] ARM: dts: Add shmobile platform device tree bindings documentation
On Mon, Sep 01, 2014 at 09:55:45AM +0900, Simon Horman wrote: > On Fri, Aug 29, 2014 at 10:26:01AM +0200, Geert Uytterhoeven wrote: > > Hi Simon, > > > > On Fri, Aug 29, 2014 at 2:34 AM, Simon Horman wrote: > > > On Thu, Aug 28, 2014 at 10:05:20AM +0200, Geert Uytterhoeven wrote: > > >> Add Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings > > >> Documentation, listing supported SoCs and boards. > > >> > > >> This allows to use checkpatch to validate DTSes referring to Renesas > > >> shmobile SoCs, and boards containing those SoCs. > > >> > > >> Signed-off-by: Geert Uytterhoeven > > > > > > Thanks Geert, this looks good to me. > > > Is it for me to pick up? > > > > I think so. > > > > > If so I would prefer a slightly re-structured title: > > > > > > ARM: shmobile: Add platform device tree bindings documentation > > > > Fine for me. > > > > Do you want me to resend, or will you amend yourself? > > No need to resend at this time :) I have queued up the following: From: Geert Uytterhoeven [PATCH] ARM: shmobile: Add platform device tree bindings documentation Add Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings Documentation, listing supported SoCs and boards. This allows to use checkpatch to validate DTSes referring to Renesas shmobile SoCs, and boards containing those SoCs. Signed-off-by: Geert Uytterhoeven [horms+rene...@verge.net.au: tweaked title] Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/arm/shmobile.txt | 71 ++ 1 file changed, 71 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt new file mode 100644 index 000..5d1c5c0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -0,0 +1,71 @@ +Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings + + +SoCs: + + - Emma Mobile EV2 +compatible = "renesas,emev2" + - RZ/A1H (R7S72100) +compatible = "renesas,r7s72100" + - SH-Mobile AP4 (R8A73720/SH7372) +compatible = "renesas,sh7372" + - SH-Mobile AG5 (R8A73A00/SH73A0) +compatible = "renesas,sh73a0" + - R-Mobile APE6 (R8A73A40) +compatible = "renesas,r8a73a4" + - R-Mobile A1 (R8A77400) +compatible = "renesas,r8a7740" + - R-Car M1A (R8A77781) +compatible = "renesas,r8a7778" + - R-Car H1 (R8A77790) +compatible = "renesas,r8a7779" + - R-Car H2 (R8A77900) +compatible = "renesas,r8a7790" + - R-Car M2-W (R8A77910) +compatible = "renesas,r8a7791" + - R-Car V2H (R8A77920) +compatible = "renesas,r8a7792" + - R-Car M2-N (R8A77930) +compatible = "renesas,r8a7793" + - R-Car E2 (R8A77940) +compatible = "renesas,r8a7794" + + +Boards: + + - Alt +compatible = "renesas,alt", "renesas,r8a7794" + - APE6-EVM +compatible = "renesas,ape6evm", "renesas,r8a73a4" + - APE6-EVM - Reference Device Tree Implementation +compatible = "renesas,ape6evm-reference", "renesas,r8a73a4" + - Atmark Techno Armadillo-800 EVA +compatible = "renesas,armadillo800eva" + - BOCK-W +compatible = "renesas,bockw", "renesas,r8a7778" + - BOCK-W - Reference Device Tree Implementation +compatible = "renesas,bockw-reference", "renesas,r8a7778" + - Genmai (RTK772100BC0BR) +compatible = "renesas,genmai", "renesas,r7s72100" + - Gose +compatible = "renesas,gose", "renesas,r8a7793" + - Henninger +compatible = "renesas,henninger", "renesas,r8a7791" + - Koelsch (RTP0RC7791SEB00010S) +compatible = "renesas,koelsch", "renesas,r8a7791" + - KZM9D +compatible = "renesas,kzm9d", "renesas,emev2" + - KZM-A9-GT +compatible = "renesas,kzm9g", "renesas,sh73a0" + - KZM-A9-GT - Reference Device Tree Implementation +compatible = "renesas,kzm9g-reference", "renesas,sh73a0" + - Lager (RTP0RC7790SEB00010S) +compatible = "renesas,lager", "renesas,r8a7790" + - Mackerel (R0P7372LC0016RL, AP4 EVM 2nd) +compatible = "renesas,mackerel" + - Marzen +compatible = "renesas,marzen", "renesas,r8a7779" + +Note: Reference Device Tree Implementations are temporary implementations + to ease the migration from platform devices to Device Tree, and are + intended to be removed in the future. -- 2.0.1 -- 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/
Linux 3.17-rc3
I'm back to the usual Sunday release schedule, and -rc3 is out there
now. As expected, it is larger than rc2, since people are clearly
getting back from their Kernel Summit travels etc. But happily, it's
not *much* larger than rc2 was, and there's nothing particularly odd
going on, so I'm going to just ignore the whole "it's summer"
argument, and hope that things are just going that well.
Please don't prove me wrong,
Linus
---
Addy Ke (1):
spi/rockchip: fixup incorrect dma direction setting
Alan Cox (2):
spi/pxa2xx: Add ACPI ID for Intel Braswell
ACPI / LPSS: Add ACPI IDs for Intel Braswell
Alan Douglas (1):
xtensa: fix address checks in dma_{alloc,free}_coherent
Alex Deucher (1):
drm/radeon: handle broken disabled rb mask gracefully (6xx/7xx) (v2)
Alex Shi (1):
vexpress/spc: fix a build warning on array bounds
Alex Williamson (1):
radeon: Test for PCI root bus before assuming bus->self
Alexander Usyskin (2):
mei: reset client state on queued connect request
mei: nfc: fix memory leak in error path
Alexey Khoroshilov (1):
usb: dbgp gadget: fix use after free in dbgp_unbind()
Anand Jain (2):
Btrfs: device_list_add() should not update list when mounted
btrfs: check generation as replace duplicates devid+uuid
Andi Kleen (1):
intel_pstate: Turn per cpu printk into pr_debug
Andreas Noever (1):
thunderbolt: Clear hops before overwriting
Andrey Ryabinin (1):
ARM: 8127/1: module: add support for R_ARM_TARGET1 relocations
Andy Shevchenko (3):
x86: Fix non-PC platform kernel crash on boot due to NULL dereference
spi: dw-pci: fix bug when regs left uninitialized
spi: dw: fix kernel crash due to NULL pointer dereference
Arjun Sreedharan (1):
usb: phy: return -ENODEV on failure of try_module_get
Bartlomiej Zolnierkiewicz (1):
drivers/rtc/rtc-s5m.c: re-add support for devices without irq specified
Ben Hutchings (1):
ocfs2: do not write error flag to user structure we cannot copy from/to
Benjamin Tissoires (1):
HID: logitech-dj: prevent false errors to be shown
Bjorn Andersson (1):
pinctrl: qcom: apq8064: Correct interrupts in example
Bo Shen (1):
usb: atmel_usba_udc: fix it to deal with final dma channel
Brennan Ashton (1):
USB: option: add VIA Telecom CDS7 chipset device id
Brian Norris (1):
ARM: brcmstb: revert SMP support
Bryan O'Donoghue (1):
usb: pch_udc: usb gadget device support for Intel Quark X1000
Chao Yu (1):
zram: fix incorrect stat with failed_reads
Chris Mason (1):
Btrfs: fix filemap_flush call in btrfs_file_release
Christian König (1):
drm/radeon: save/restore the PD addr on suspend/resume
Christoph Hellwig (2):
block: cleanup error handling in sg_io
block: support > 16 byte CDBs for SG_IO
Clemens Ladisch (1):
ALSA: core: fix buffer overflow in snd_info_get_line()
Dan Carpenter (4):
pinctrl: tegra-xusb: fix an off by one test
pinctrl: tegra-xusb: testing wrong variable in probe()
usb: dwc3: omap: signedness bug in dwc3_omap_set_utmi_mode()
video: of: display_timing: double free on error
Darrick J. Wong (3):
jbd2: fix infinite loop when recovering corrupt journal blocks
jbd2: fix descriptor block size handling errors with journal_csum
ext4: fix same-dir rename when inline data directory overflows
Dave Jones (1):
lib: turn CONFIG_STACKTRACE into an actual option.
David Herrmann (1):
drm: fix division-by-zero on dumb_create()
Dmitry Monakhov (5):
brd: add ram disk visibility option
ext4: move i_size,i_disksize update routines to helper function
ext4: fix incorect journal credits reservation in ext4_zero_range
ext4: fix transaction issues for ext4_fallocate and ext_zero_range
ext4: update i_disksize coherently with block allocation on error path
Doug Anderson (1):
spi/rockchip: Avoid accidentally turning off the clock
Eric Sandeen (1):
btrfs: fix leak in qgroup_subtree_accounting() error path
Fabio Estevam (2):
ARM: dts: imx53-qsrb: Fix suspend/resume
mfd: ab8500-core: Use 'ifdef' for config options
Filipe Brandenburger (1):
xattr: fix check for simultaneous glibc header inclusion
Filipe Manana (5):
Btrfs: race free update of commit root for ro snapshots
Btrfs: ensure tmpfile inode is always persisted with link count of 0
Btrfs: fix hole detection during file fsync
Btrfs: don't monopolize a core when evicting inode
Btrfs: clone, don't create invalid hole extent map
Geert Uytterhoeven (3):
spi: sh-msiof: Fix leaking of unused DMA descriptors
spi: rspi: Fix leaking of unused DMA descriptors
spi: sh-msiof: Fix transmit-only DMA transfers
Gioh Kim (1):
Documentation/dma-buf-sharing.txt: update API descriptions
Greg KH (3):
USB: serial: pl2303: add device id for ztek device
Revert "usb:
[PATCH] mm: use pgprot_val to access vm_page_prot
pgprot is defined differently in every arch, use the per-arch pgprot_val to access it. This fixes a build failure on various arches such as tile and powerpc caused by "mm: introduce dump_vma". Signed-off-by: Sasha Levin --- mm/page_alloc.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index add97b8..1e1bd9a 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6734,7 +6734,8 @@ void dump_vma(const struct vm_area_struct *vma) "prot %lx anon_vma %p vm_ops %p\n" "pgoff %lx file %p private_data %p\n", vma, (void *)vma->vm_start, (void *)vma->vm_end, vma->vm_next, - vma->vm_prev, vma->vm_mm, vma->vm_page_prot.pgprot, + vma->vm_prev, vma->vm_mm, + (unsigned long)pgprot_val(vma->vm_page_prot), vma->anon_vma, vma->vm_ops, vma->vm_pgoff, vma->vm_file, vma->vm_private_data); dump_flags(vma->vm_flags, vmaflags_names, ARRAY_SIZE(vmaflags_names)); -- 1.7.10.4 -- 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/
Re: [PATCH] moduleparam: Resolve missing-field-initializer warning
Jeff Kirsher writes:
> From: Mark Rustad
>
> Resolve a missing-field-initializer warning, that is produced
> by every reference to module_param_call, by using designated
> initialization for the first field. That is enough to silence
> the complaint.
>
> Signed-off-by: Mark Rustad
> Signed-off-by: Jeff Kirsher
> ---
> include/linux/moduleparam.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Strange, I haven't seen this warning. Compiler version? And it's good
to quote the error message, so people can google it.
Cheers,
Rusty.
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index 494f99e..d99a9e9 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -196,7 +196,7 @@ struct kparam_array
> /* Obsolete - use module_param_cb() */
> #define module_param_call(name, set, get, arg, perm) \
> static struct kernel_param_ops __param_ops_##name = \
> - { 0, (void *)set, (void *)get };\
> + { .flags = 0, (void *)set, (void *)get }; \
> __module_param_call(MODULE_PARAM_PREFIX,\
> name, &__param_ops_##name, arg, \
> (perm) + sizeof(__check_old_set_param(set))*0, -1)
> --
> 1.9.3
--
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/
Re: [PATCH v3 8/9] usb: chipidea: move usb_otg into struct ci_hdrc
On Fri, Aug 29, 2014 at 04:25:35PM +0200, Antoine Tenart wrote:
> Hi,
>
> On Tue, Aug 26, 2014 at 06:22:40PM +0800, Peter Chen wrote:
> > On Fri, Aug 22, 2014 at 05:50:19PM +0200, Antoine Ténart wrote:
> >
> > If the common usb_otg and usb_phy struct still has another's pointer, you
> > may not need to add this patch.
>
> Except if we want to access the OTG member when not using an USB PHY.
If there is no USB PHY, the probe at core.c will turn error.
>
> > > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> > > index 0b67d78dd953..0952d4adfa4c 100644
> > > --- a/drivers/usb/chipidea/host.c
> > > +++ b/drivers/usb/chipidea/host.c
> > > @@ -85,13 +85,11 @@ static int host_start(struct ci_hdrc *ci)
> > > if (ret) {
> > > goto disable_reg;
> > > } else {
> > > - struct usb_otg *otg = ci->usb_phy->otg;
> > > + struct usb_otg *otg = >otg;
> > >
> > > ci->hcd = hcd;
> > > - if (otg) {
> > > - otg->host = >self;
> > > - hcd->self.otg_port = 1;
> > > - }
> > > + otg->host = >self;
> > > + hcd->self.otg_port = 1;
> > > }
> >
> > You may need use other way to identify if otg is supported or not
>
> How would you do that?
ci_otg_is_fsm_mode(ci)
>
> > > - otg->usb_phy = ci->usb_phy;
> > > - otg->gadget = >gadget;
> > > - ci->fsm.otg = otg;
> > > - ci->usb_phy->otg = ci->fsm.otg;
> > > + ci->otg.usb_phy = ci->usb_phy;
> > > + ci->fsm.otg = >otg;
> > > ci->fsm.power_up = 1;
> > > ci->fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
> > > ci->fsm.otg->state = OTG_STATE_UNDEFINED;
> >
> > Why otg->gadget and ci->usb_phy->otg initialization are deleted?
> > At least, the parameters of usb_otg_state_string at your 7th patch uses it.
>
> Sure, I'll fix this
>
> Antoine
>
> --
> Antoine Ténart, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
Best Regards,
Peter Chen
--
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/
[PATCH v2 1/1] USB: Add device quirk for ASUS T100 Base Station keyboard
This full-speed USB device generates spurious remote wakeup event
as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
Linux can't enter system suspend and S0ix power saving modes once
this keyboard is used.
This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk.
With this quirk set, wakeup capability will be ignored during
device configure.
This patch could be back-ported to kernels as old as 2.6.39.
Signed-off-by: Lu Baolu
---
drivers/usb/core/hub.c | 6 --
drivers/usb/core/quirks.c | 4
include/linux/usb/quirks.h | 3 +++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 8a4dcbc..5df1457 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1977,8 +1977,10 @@ void usb_set_device_state(struct usb_device *udev,
|| new_state == USB_STATE_SUSPENDED)
; /* No change to wakeup settings */
else if (new_state == USB_STATE_CONFIGURED)
- wakeup = udev->actconfig->desc.bmAttributes
-& USB_CONFIG_ATT_WAKEUP;
+ wakeup = (udev->quirks &
+ USB_QUIRK_IGNORE_REMOTE_WAKEUP) ? 0 :
+ udev->actconfig->desc.bmAttributes &
+ USB_CONFIG_ATT_WAKEUP;
else
wakeup = 0;
}
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index bae636e..e7d1e3c 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -159,6 +159,10 @@ static const struct usb_device_id usb_quirk_list[] = {
/* USB3503 */
{ USB_DEVICE(0x0424, 0x3503), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* ASUS Base Station(T100) */
+ { USB_DEVICE(0x0b05, 0x17e0), .driver_info =
+ USB_QUIRK_IGNORE_REMOTE_WAKEUP },
+
{ } /* terminating entry must be last */
};
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index 55a17b1..0f784c3 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -41,4 +41,7 @@
*/
#define USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL 0x0080
+/* device generates spurious wakeup, ignore remote wakeup capability */
+#define USB_QUIRK_IGNORE_REMOTE_WAKEUP 0x0100
+
#endif /* __LINUX_USB_QUIRKS_H */
--
1.9.1
--
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/
Re: clk: shmobile: CONFIG_ARCH_R8A7794?
On Sat, Aug 30, 2014 at 06:03:26PM +0200, Paul Bolle wrote:
> Hi Hisashi,
>
> Your commit 8de078f189da ("clk: shmobile: Add r8a7794 support") landed
> in next-20140828. It adds a single line to a Makefile. That new line
> contains a check for CONFIG_ARCH_R8A7794.
>
> There's no Kconfig symbol ARCH_R8A7794 so this line is basically a NOP
> currently. I assume that code to add the Kconfig symbol ARCH_R8A7794 is
> queued somewhere. Is that correct?
Hi Paul,
The r8a7794 is a new Renesas SoC that we are in the process
of adding support for to mainline. A patch to add CONFIG_ARCH_R8A7794
is in the pipeline.
https://patchwork.kernel.org/patch/4812021/
--
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/
[PATCH 0/5] beautify EFI memmap logs
It's a pain to analyze EFI memmap logs while debugging, especially to
verify the memory types (an enum) and the memory attributes (a bitmap).
This series renders those columns human-readable, and unifies their
formatting between x86, ia64 and arm64.
Example output with the patchset on arm64 (in a qemu-system-aarch64
guest, booted with Ard's v5 series from edk2-devel ("QEMU_EFI.fd")):
> Processing EFI memory map:
> 0x4000-0x4fff [Loader Data| | | | |
> |WB|WT|WC|UC]
> 0x40001000-0x4007 [Conventional Memory| | | | |
> |WB|WT|WC|UC]
> 0x4008-0x4072afff [Loader Data| | | | |
> |WB|WT|WC|UC]
> 0x4072b000-0x5fdf [Conventional Memory| | | | |
> |WB|WT|WC|UC]
> 0x5fe0-0x5fe0 [Loader Data| | | | |
> |WB|WT|WC|UC]
> 0x5fe1-0x964e8fff [Conventional Memory| | | | |
> |WB|WT|WC|UC]
> 0x964e9000-0x964e9fff [Loader Data| | | | |
> |WB|WT|WC|UC]
> 0x964ea000-0x96c52fff [Loader Code| | | | |
> |WB|WT|WC|UC]
> 0x96c53000-0x9709dfff [Boot Code | | | | |
> |WB|WT|WC|UC]*
> 0x9709e000-0x970b3fff [Runtime Code |RUN| | | |
> |WB|WT|WC|UC]*
> 0x970b4000-0x970f4fff [Runtime Data |RUN| | | |
> |WB|WT|WC|UC]*
> 0x970f5000-0x97117fff [Runtime Code |RUN| | | |
> |WB|WT|WC|UC]*
> 0x97118000-0x97199fff [Runtime Data |RUN| | | |
> |WB|WT|WC|UC]*
> 0x9719a000-0x971d [Runtime Code |RUN| | | |
> |WB|WT|WC|UC]*
> 0x971e-0x997f8fff [Conventional Memory| | | | |
> |WB|WT|WC|UC]
> 0x997f9000-0x998f1fff [Boot Data | | | | |
> |WB|WT|WC|UC]*
> 0x998f2000-0x999eafff [Conventional Memory| | | | |
> |WB|WT|WC|UC]
> 0x999eb000-0x9af09fff [Boot Data | | | | |
> |WB|WT|WC|UC]*
> 0x9af0a000-0x9af21fff [Conventional Memory| | | | |
> |WB|WT|WC|UC]
> 0x9af22000-0x9af46fff [Boot Data | | | | |
> |WB|WT|WC|UC]*
> 0x9af47000-0x9af5bfff [Conventional Memory| | | | |
> |WB|WT|WC|UC]
> 0x9af5c000-0x9afe1fff [Boot Data | | | | |
> |WB|WT|WC|UC]*
> 0x9afe2000-0x9afe2fff [Conventional Memory| | | | |
> |WB|WT|WC|UC]
> 0x9afe3000-0x9c01 [Boot Data | | | | |
> |WB|WT|WC|UC]*
> 0x9c02-0x9efb [Conventional Memory| | | | |
> |WB|WT|WC|UC]
> 0x9efc-0x9f14efff [Boot Code | | | | |
> |WB|WT|WC|UC]*
> 0x9f14f000-0x9f162fff [Runtime Code |RUN| | | |
> |WB|WT|WC|UC]*
> 0x9f163000-0x9f194fff [Runtime Data |RUN| | | |
> |WB|WT|WC|UC]*
> 0x9f195000-0x9f197fff [Boot Data | | | | |
> |WB|WT|WC|UC]*
> 0x9f198000-0x9f198fff [Runtime Data |RUN| | | |
> |WB|WT|WC|UC]*
> 0x9f199000-0x9f1acfff [Conventional Memory| | | | |
> |WB|WT|WC|UC]
> 0x9f1ad000-0x9f1a [Boot Data | | | | |
> |WB|WT|WC|UC]*
> 0x9f1b-0x9f1b0fff [Runtime Data |RUN| | | |
> |WB|WT|WC|UC]*
> 0x9f1b1000-0x9fff [Boot Data | | | | |
> |WB|WT|WC|UC]*
> 0x0400-0x07ff [Memory Mapped I/O |RUN| | | | | | |
> |UC]
> 0x0901-0x09010fff [Memory Mapped I/O |RUN| | | | | | |
> |UC]
Output on x86 (OVMF guest):
> [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC]
> range=[0x-0x0009f000) (0MB)
> [0.00] efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC]
> range=[0x0009f000-0x000a) (0MB)
> [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC]
> range=[0x0010-0x0040) (3MB)
> [0.00] efi: mem03: [Loader Data| | | | | |WB|WT|WC|UC]
> range=[0x0040-0x0080) (4MB)
> [0.00] efi: mem04: [ACPI Memory NVS| | | | | |WB|WT|WC|UC]
> range=[0x0080-0x00808000) (0MB)
> [0.00] efi: mem05: [Conventional Memory| | | | | |WB|WT|WC|UC]
> range=[0x00808000-0x0081) (0MB)
> [0.00] efi: mem06: [ACPI Memory NVS| | | | | |WB|WT|WC|UC]
> range=[0x0081-0x0090) (0MB)
> [0.00] efi: mem07: [Boot Data | | | | | |WB|WT|WC|UC]
> range=[0x0090-0x0110) (8MB)
> [0.00] efi: mem08: [Conventional Memory| | | | | |WB|WT|WC|UC]
> range=[0x0110-0x0140) (3MB)
> [0.00] efi: mem09: [Loader Data| | | | | |WB|WT|WC|UC]
> range=[0x0140-0x02613000) (18MB)
> [
[PATCH 4/5] ia64: efi: format EFI memory type & attrs with efi_md_typeattr_format()
Signed-off-by: Laszlo Ersek
---
arch/ia64/kernel/efi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 741b99c..c52d754 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -568,6 +568,7 @@ efi_init (void)
{
const char *unit;
unsigned long size;
+ char buf[64];
md = p;
size = md->num_pages << EFI_PAGE_SHIFT;
@@ -586,9 +587,10 @@ efi_init (void)
unit = "KB";
}
- printk("mem%02d: type=%2u, attr=0x%016lx, "
+ printk("mem%02d: %s "
"range=[0x%016lx-0x%016lx) (%4lu%s)\n",
- i, md->type, md->attribute, md->phys_addr,
+ i, efi_md_typeattr_format(buf, sizeof(buf), md),
+ md->phys_addr,
md->phys_addr + efi_md_size(md), size, unit);
}
}
--
1.8.3.1
--
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/
[PATCH 1/5] efi: add macro for EFI_MEMORY_UCE memory attribute
Add the following macro from the UEFI spec, for completeness:
EFI_MEMORY_UCE Memory cacheability attribute: The memory region
supports being configured as not cacheable, exported,
and supports the "fetch and add" semaphore mechanism.
Signed-off-by: Laszlo Ersek
---
include/linux/efi.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 45cb4ff..b4b1d8d 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -92,6 +92,7 @@ typedef struct {
#define EFI_MEMORY_WC ((u64)0x0002ULL)/*
write-coalescing */
#define EFI_MEMORY_WT ((u64)0x0004ULL)/*
write-through */
#define EFI_MEMORY_WB ((u64)0x0008ULL)/* write-back */
+#define EFI_MEMORY_UCE ((u64)0x0010ULL)/* uncached,
exported */
#define EFI_MEMORY_WP ((u64)0x1000ULL)/*
write-protect */
#define EFI_MEMORY_RP ((u64)0x2000ULL)/* read-protect
*/
#define EFI_MEMORY_XP ((u64)0x4000ULL)/*
execute-protect */
--
1.8.3.1
--
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/
Re: [PATCH v2] ARM: dts: Add shmobile platform device tree bindings documentation
On Fri, Aug 29, 2014 at 10:26:01AM +0200, Geert Uytterhoeven wrote: > Hi Simon, > > On Fri, Aug 29, 2014 at 2:34 AM, Simon Horman wrote: > > On Thu, Aug 28, 2014 at 10:05:20AM +0200, Geert Uytterhoeven wrote: > >> Add Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings > >> Documentation, listing supported SoCs and boards. > >> > >> This allows to use checkpatch to validate DTSes referring to Renesas > >> shmobile SoCs, and boards containing those SoCs. > >> > >> Signed-off-by: Geert Uytterhoeven > > > > Thanks Geert, this looks good to me. > > Is it for me to pick up? > > I think so. > > > If so I would prefer a slightly re-structured title: > > > > ARM: shmobile: Add platform device tree bindings documentation > > Fine for me. > > Do you want me to resend, or will you amend yourself? No need to resend at this time :) -- 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/
[PATCH 3/5] x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
Signed-off-by: Laszlo Ersek
---
arch/x86/platform/efi/efi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 850da94..ae2573a 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -210,9 +210,12 @@ static void __init print_efi_memmap(void)
for (p = memmap.map, i = 0;
p < memmap.map_end;
p += memmap.desc_size, i++) {
+ char buf[64];
+
md = p;
- pr_info("mem%02u: type=%u, attr=0x%llx,
range=[0x%016llx-0x%016llx) (%lluMB)\n",
- i, md->type, md->attribute, md->phys_addr,
+ pr_info("mem%02u: %s range=[0x%016llx-0x%016llx) (%lluMB)\n",
+ i, efi_md_typeattr_format(buf, sizeof(buf), md),
+ md->phys_addr,
md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
}
--
1.8.3.1
--
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/
[PATCH 5/5] arm64: efi: format EFI memory type & attrs with efi_md_typeattr_format()
Signed-off-by: Laszlo Ersek
---
arch/arm64/kernel/efi.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 03aaa99..3b1f23c 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -119,23 +119,6 @@ static int __init uefi_init(void)
return retval;
}
-static __initdata char memory_type_name[][32] = {
- {"Reserved"},
- {"Loader Code"},
- {"Loader Data"},
- {"Boot Code"},
- {"Boot Data"},
- {"Runtime Code"},
- {"Runtime Data"},
- {"Conventional Memory"},
- {"Unusable Memory"},
- {"ACPI Reclaim Memory"},
- {"ACPI Memory NVS"},
- {"Memory Mapped I/O"},
- {"MMIO Port Space"},
- {"PAL Code"},
-};
-
/*
* Return true for RAM regions we want to permanently reserve.
*/
@@ -166,10 +149,13 @@ static __init void reserve_regions(void)
paddr = md->phys_addr;
npages = md->num_pages;
- if (uefi_debug)
- pr_info(" 0x%012llx-0x%012llx [%s]",
+ if (uefi_debug) {
+ char buf[64];
+
+ pr_info(" 0x%012llx-0x%012llx %s",
paddr, paddr + (npages << EFI_PAGE_SHIFT) - 1,
- memory_type_name[md->type]);
+ efi_md_typeattr_format(buf, sizeof(buf), md));
+ }
memrange_efi_to_native(, );
size = npages << PAGE_SHIFT;
--
1.8.3.1
--
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/
[PATCH 2/5] efi: introduce efi_md_typeattr_format()
At the moment, there are three architectures debug-printing the EFI memory
map at initialization: x86, ia64, and arm64. They all use different format
strings, plus the EFI memory type and the EFI memory attributes are
similarly hard to decode for a human reader.
Introduce a helper __init function that formats the memory type and the
memory attributes in a unified way, to a user-provided character buffer.
The array "memory_type_name" is copied from the arm64 code, temporarily
duplicating it. The (otherwise optional) braces around each string literal
in the initializer list are dropped in order to match the kernel coding
style more closely. The element size is tightened from 32 to 20 bytes
(maximum actual string length + 1) so that we can derive the field width
from the element size.
Signed-off-by: Laszlo Ersek
---
include/linux/efi.h| 7 ++
drivers/firmware/efi/efi.c | 57 ++
2 files changed, 64 insertions(+)
diff --git a/include/linux/efi.h b/include/linux/efi.h
index b4b1d8d..d04d618 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -887,6 +887,13 @@ extern bool efi_poweroff_required(void);
(md) <= (efi_memory_desc_t *)((m)->map_end - (m)->desc_size); \
(md) = (void *)(md) + (m)->desc_size)
+/*
+ * Format an EFI memory descriptor's type and attributes to a user-provided
+ * character buffer, as per snprintf(), and return the buffer.
+ */
+char * __init efi_md_typeattr_format(char *buf, size_t size,
+const efi_memory_desc_t *md);
+
/**
* efi_range_is_wc - check the WC bit on an address range
* @start: starting kvirt address
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 64ecbb5..43d9d25 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -423,3 +423,60 @@ int __init efi_get_fdt_params(struct efi_fdt_params
*params, int verbose)
return ret;
}
#endif /* CONFIG_EFI_PARAMS_FROM_FDT */
+
+static __initdata char memory_type_name[][20] = {
+ "Reserved",
+ "Loader Code",
+ "Loader Data",
+ "Boot Code",
+ "Boot Data",
+ "Runtime Code",
+ "Runtime Data",
+ "Conventional Memory",
+ "Unusable Memory",
+ "ACPI Reclaim Memory",
+ "ACPI Memory NVS",
+ "Memory Mapped I/O",
+ "MMIO Port Space",
+ "PAL Code"
+};
+
+char * __init efi_md_typeattr_format(char *buf, size_t size,
+const efi_memory_desc_t *md)
+{
+ char *pos;
+ int type_len;
+ register u64 attr;
+
+ pos = buf;
+ if (md->type >= ARRAY_SIZE(memory_type_name))
+ type_len = snprintf(pos, size, "[type=%u", md->type);
+ else
+ type_len = snprintf(pos, size, "[%-*s",
+ (int)(sizeof(memory_type_name[0]) - 1),
+ memory_type_name[md->type]);
+ if (type_len >= size)
+ return buf;
+
+ pos += type_len;
+ size -= type_len;
+
+ attr = md->attribute;
+ if (attr & ~(EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
+EFI_MEMORY_WB | EFI_MEMORY_UCE | EFI_MEMORY_WP |
+EFI_MEMORY_RP | EFI_MEMORY_XP | EFI_MEMORY_RUNTIME))
+ snprintf(pos, size, "|attr=0x%016llx]",
+(unsigned long long)attr);
+ else
+ snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
+attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
+attr & EFI_MEMORY_XP ? "XP" : "",
+attr & EFI_MEMORY_RP ? "RP" : "",
+attr & EFI_MEMORY_WP ? "WP" : "",
+attr & EFI_MEMORY_UCE ? "UCE" : "",
+attr & EFI_MEMORY_WB ? "WB" : "",
+attr & EFI_MEMORY_WT ? "WT" : "",
+attr & EFI_MEMORY_WC ? "WC" : "",
+attr & EFI_MEMORY_UC ? "UC" : "");
+ return buf;
+}
--
1.8.3.1
--
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/
[PATCH] ata: Disabling the async PM for JMicron chip 363/361
After enabled the PM feature that supporting async noirq(76569faa62
(PM / sleep: Asynchronous threads for resume_noirq)),
Jay hit the system resuming issue, that one of the JMicron controller
can not be powered up.
His device tree is like below:
+-1c.4-[02]--+-00.0 JMicron Technology Corp. JMB363 SATA/IDE
Controller
|\-00.1 JMicron Technology Corp. JMB363 SATA/IDE
Controller
After investigation, we found the the Micron chip 363 included
one SATA controller(:02:00.0) and one PATA controller(:02:00.1),
these two controllers do not have parent-children relationship,
but the PATA controller only can be powered on after the SATA controller
has finished the powering on.
If we enabled the async noirq(), then the below error is hit during noirq
phase:
pata_jmicron :02:00.1: Refused to change power state, currently in D3
Here for JMicron chip 363/361, we need forcedly to disable the async method.
Bug detail: https://bugzilla.kernel.org/show_bug.cgi?id=81551
Reported-by: Jay
Signed-off-by: Chuansheng Liu
---
drivers/ata/ahci.c | 11 +++
drivers/ata/pata_jmicron.c | 11 +++
2 files changed, 22 insertions(+)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index a29f801..f5634cd 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1329,6 +1329,17 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
else if (pdev->vendor == 0x1c44 && pdev->device == 0x8000)
ahci_pci_bar = AHCI_PCI_BAR_ENMOTUS;
+ /* The JMicron chip 361/363 contains one SATA controller and
+* one PATA controller,for powering on these both controllers,
+* we must follow the sequence one by one, otherwise one of them
+* can not be powered on successfully.
+* So here we disabled the async suspend method for these chips.
+ */
+ if (pdev->vendor == PCI_VENDOR_ID_JMICRON &&
+ (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 ||
+ pdev->device == PCI_DEVICE_ID_JMICRON_JMB361))
+ device_disable_async_suspend(>dev);
+
/* acquire resources */
rc = pcim_enable_device(pdev);
if (rc)
diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c
index 4d1a5d2..6b7aa77 100644
--- a/drivers/ata/pata_jmicron.c
+++ b/drivers/ata/pata_jmicron.c
@@ -143,6 +143,17 @@ static int jmicron_init_one (struct pci_dev *pdev, const
struct pci_device_id *i
};
const struct ata_port_info *ppi[] = { , NULL };
+ /* The JMicron chip 361/363 contains one SATA controller and
+* one PATA controller,for powering on these both controllers,
+* we must follow the sequence one by one, otherwise one of them
+* can not be powered on successfully.
+* So here we disabled the async suspend method for these chips.
+*/
+ if (pdev->vendor == PCI_VENDOR_ID_JMICRON &&
+ (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 ||
+ pdev->device == PCI_DEVICE_ID_JMICRON_JMB361))
+ device_disable_async_suspend(>dev);
+
return ata_pci_bmdma_init_one(pdev, ppi, _sht, NULL, 0);
}
--
1.7.9.5
--
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/
Re: [GIT PULL] target updates for v3.17-rc3
On Sun, Aug 31, 2014 at 11:59 AM, Nicholas A. Bellinger wrote: > > Note that these patches where originally intended for -rc1, but missed > the merge window. They are mostly iser-target related bug-fixes, along > with a few other very minor cleanups. So this pull request was strictly speaking too late for rc3, but I went "what the hell, it's small" and pulled it anyway. And then I get this: drivers/target/target_core_transport.c: In function ‘transport_dump_vpd_ident_type’: drivers/target/target_core_transport.c:956:3: warning: passing argument 1 of ‘strlen’ makes pointer from integer without a cast [enabled by default] len = strlen(len); ^ In file included from include/linux/bitmap.h:8:0, from include/linux/cpumask.h:11, from ./arch/x86/include/asm/cpumask.h:4, from ./arch/x86/include/asm/msr.h:10, from ./arch/x86/include/asm/processor.h:20, from ./arch/x86/include/asm/archrandom.h:26, from include/linux/random.h:81, from include/linux/net.h:22, from drivers/target/target_core_transport.c:26: include/linux/string.h:80:24: note: expected ‘const char *’ but argument is of type ‘int’ extern __kernel_size_t strlen(const char *); ^ and I just go "Yeah, that broken crap can wait until 3.18 after all". So it got unpulled. That "strlen(len)" should clearly be a "strlen(buf)" in that commit 6cfa853ceee4, but equally clearly this pull request was pure and utter garbage, and that "cleanup" commit was shit that nobody had ever even bothered to compile. Thanks, but no. And please never send this kind of untested crap to me again, Linus -- 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/
[PATCH -next] ASoC: es8328: fix error return code in es8328_codec_probe()
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
sound/soc/codecs/es8328.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/es8328.c b/sound/soc/codecs/es8328.c
index 7a9f65a..3ff7870 100644
--- a/sound/soc/codecs/es8328.c
+++ b/sound/soc/codecs/es8328.c
@@ -665,6 +665,7 @@ static int es8328_codec_probe(struct snd_soc_codec *codec)
es8328->clk = devm_clk_get(codec->dev, NULL);
if (IS_ERR(es8328->clk)) {
dev_err(codec->dev, "codec clock missing or invalid\n");
+ ret = PTR_ERR(es8328->clk);
goto clk_fail;
}
--
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/
[PATCH] drivers: staging: rtl8723au: Fix return is not a function, parentheses are not required error
Fix checkpatch.pl return is not a function, parentheses are not required error
Signed-off-by: Greg Donald
---
drivers/staging/rtl8723au/include/osdep_service.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723au/include/osdep_service.h
b/drivers/staging/rtl8723au/include/osdep_service.h
index 51a5d7b..dedb418 100644
--- a/drivers/staging/rtl8723au/include/osdep_service.h
+++ b/drivers/staging/rtl8723au/include/osdep_service.h
@@ -54,7 +54,7 @@ struct rtw_queue {
static inline struct list_head *get_list_head(struct rtw_queue *queue)
{
- return (>queue);
+ return >queue;
}
static inline int rtw_netif_queue_stopped(struct net_device *pnetdev)
--
1.9.1
--
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/
Re: [PATCH v2 3/6] block: loop: convert to blk-mq
Hi Robert,
Great thanks for your so detailed review.
On Sun, Aug 31, 2014 at 6:03 AM, Elliott, Robert (Server Storage)
wrote:
>
>
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>> ow...@vger.kernel.org] On Behalf Of Ming Lei
>> Sent: Saturday, 30 August, 2014 11:08 AM
>> To: Jens Axboe; linux-kernel@vger.kernel.org; Dave Kleikamp
>> Cc: Zach Brown; Christoph Hellwig; Maxim Patlasov; Ming Lei
>> Subject: [PATCH v2 3/6] block: loop: convert to blk-mq
>>
> ...
>> -static inline void loop_handle_bio(struct loop_device *lo, struct
>> bio *bio)
>> +static inline int loop_handle_bio(struct loop_device *lo, struct bio
>> *bio)
>> {
>> - if (unlikely(!bio->bi_bdev)) {
>> - do_loop_switch(lo, bio->bi_private);
>> - bio_put(bio);
>> - } else {
>> - int ret = do_bio_filebacked(lo, bio);
>> - bio_endio(bio, ret);
>> - }
>> + int ret = do_bio_filebacked(lo, bio);
>> + return ret;
>
> No need for the temporary variable; just return the function
> call.
>
> ...
>> +static int loop_prepare_hctxs(struct loop_device *lo)
>> +{
>> + struct request_queue *q = lo->lo_queue;
>> + struct blk_mq_hw_ctx *hctx;
>> + struct loop_hctx_data *data;
>> + unsigned int i;
>> +
>> + queue_for_each_hw_ctx(q, hctx, i) {
>> + BUG_ON(i >= lo->tag_set.nr_hw_queues);
>
> If something goes bad in the loop driver like that, is it
> necessary to crash the whole kernel?
Actually, the BUG_ON() shouldn't have been added, will remove it.
>
>> + data = hctx->driver_data;
>> +
>> + data->lo = lo;
>> + init_kthread_worker(>worker);
>> + data->worker_task = kthread_run(kthread_worker_fn,
>> + >worker, "loop%d-%d",
>> + lo->lo_number, i);
>> + if (IS_ERR(data->worker_task)) {
>> + loop_unprepare_hctxs(lo, i);
>> + return -ENOMEM;
>> + }
>> + set_user_nice(data->worker_task, MIN_NICE);
>> + sched_getaffinity(data->worker_task->pid, hctx->cpumask);
>
> Is that supposed to be sched_setaffinity? It looks like
> getaffinity does have a side-effect of updating the CPU mask
> based on the current active cpus, but there won't be a CPU mask
> to update unless setaffinity was called.
Hmm, it is a typo, and I meant sched_setaffinity(), but it isn't exported,
so set_cpus_allowed_ptr() should be used.
>
> ...
>> @@ -906,14 +848,10 @@ static int loop_set_fd(struct loop_device *lo,
>> fmode_t mode,
>>
>> set_blocksize(bdev, lo_blocksize);
>>
>> - lo->lo_thread = kthread_create(loop_thread, lo, "loop%d",
>> - lo->lo_number);
>> - if (IS_ERR(lo->lo_thread)) {
>> - error = PTR_ERR(lo->lo_thread);
>> + if ((error = loop_prepare_hctxs(lo)) != 0)
>> goto out_clr;
>
> I've been told that linux kernel style is:
> error = x();
> if (error)
>
> ...
>> @@ -1014,7 +951,7 @@ static int loop_clr_fd(struct loop_device *lo)
>> lo->lo_state = Lo_rundown;
>> spin_unlock_irq(>lo_lock);
>>
>> - kthread_stop(lo->lo_thread);
>> + loop_unprepare_hctxs(lo, lo->tag_set.nr_hw_queues);
>>
>> spin_lock_irq(>lo_lock);
>> lo->lo_backing_file = NULL;
> ...
>> +
>> +static int loop_prepare_flush_rq(void *data, struct request_queue
>> *q,
>> + struct request *flush_rq,
>> + const struct request *src_rq)
>> +{
>> + /* borrow initialization helper for common rq */
>> + loop_init_request(data, flush_rq, 0, -1, NUMA_NO_NODE);
>> + return 0;
>> +}
>
> In patch 2/6 that function is called with:
> if (orig_rq->q->mq_ops->prepare_flush_rq)
> ret = orig_rq->q->mq_ops->prepare_flush_rq(
> orig_rq->q->tag_set->driver_data,
> orig_rq->q, flush_rq, orig_rq);
>
>
> The src_rq argument is not used in this new function.
> Do you anticipate it might be necessary in other drivers?
Yes, sooner or later the problem will be triggered in blk-mq
conversion for current drivers, and current default behaviour is to
copy pdu of src_rq to q->flush_rq, that is why the src_rq is passed.
> Is this new function allowed to modify *data, *flush_rq,
> or *src_rq? If not, const might be good to add.
Instance pointed by data and src_rq shouldn't be modified.
>
> If orig_rq is always passed, then this function could
> decode orig_rq->q and orig_rq->q->tag_set_>driver_data
> on its own, eliminating the need for the first two arguments.
Looks a good idea.
>
> Similarly, in the unprepare_flush_rq function in patch 2,
> which is not provided by the loop driver in this patch:
>
> + if (q->mq_ops->unprepare_flush_rq)
> + q->mq_ops->unprepare_flush_rq(
> +
Re: [PATCH -mmotm v2] mm: fix kmemcheck.c build errors
On Sun, Aug 31, 2014 at 05:17:14PM -0700, Randy Dunlap wrote:
> On 08/31/14 17:13, Joonsoo Kim wrote:
> > On Sun, Aug 31, 2014 at 04:33:12PM -0700, Randy Dunlap wrote:
> >> On 08/31/14 07:48, Randy Dunlap wrote:
> >>> On 08/31/14 04:36, Andrey Ryabinin wrote:
> 2014-08-30 5:48 GMT+04:00 Randy Dunlap :
> > From: Randy Dunlap
> >
> > Add header file to fix kmemcheck.c build errors:
> >
> > ../mm/kmemcheck.c:70:7: error: dereferencing pointer to incomplete type
> > ../mm/kmemcheck.c:83:15: error: dereferencing pointer to incomplete type
> > ../mm/kmemcheck.c:95:8: error: dereferencing pointer to incomplete type
> > ../mm/kmemcheck.c:95:21: error: dereferencing pointer to incomplete type
> >
> > Signed-off-by: Randy Dunlap
> > ---
> > mm/kmemcheck.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > Index: mmotm-2014-0829-1515/mm/kmemcheck.c
> > ===
> > --- mmotm-2014-0829-1515.orig/mm/kmemcheck.c
> > +++ mmotm-2014-0829-1515/mm/kmemcheck.c
> > @@ -2,6 +2,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> This will work only for CONFIG_SLAB=y. struct kmem_cache definition
> was moved to internal header [*],
> so you need to include it here:
> #include "slab.h"
>
> [*]
> http://ozlabs.org/~akpm/mmotm/broken-out/mm-slab_common-move-kmem_cache-definition-to-internal-header.patch
> >>>
> >>> Thanks. That makes sense. [testing] mm/kmemcheck.c still has a build
> >>> error:
> >>>
> >>> In file included from ../mm/kmemcheck.c:5:0:
> >>> ../mm/slab.h: In function 'cache_from_obj':
> >>> ../mm/slab.h:283:2: error: implicit declaration of function
> >>> 'memcg_kmem_enabled' [-Werror=implicit-function-declaration]
> >>>
> >>
> >> Naughty header file. It uses something from without
> >> #including that header file...
> >
> >
> > Hello.
> >
> > Indeed...
> > Thanks for catching this.
> >
> >>
> >> Working patch is below.
> >
> > With your patch, build also failed if CONFIG_MEMCG_KMEM=y.
> > Right fix is something like below.
> >
> > Thanks.
> >
> > ->8--
> > diff --git a/mm/kmemcheck.c b/mm/kmemcheck.c
> > index fd814fd..cab58bb 100644
> > --- a/mm/kmemcheck.c
> > +++ b/mm/kmemcheck.c
> > @@ -2,6 +2,7 @@
> > #include
> > #include
> > #include
> > +#include "slab.h"
> > #include
> >
> > void kmemcheck_alloc_shadow(struct page *page, int order, gfp_t flags, int
> > node)
> > diff --git a/mm/slab.h b/mm/slab.h
> > index 13845d0..963a3f8 100644
> > --- a/mm/slab.h
> > +++ b/mm/slab.h
> > @@ -37,6 +37,8 @@ struct kmem_cache {
> > #include
> > #endif
> >
> > +#include
> > +
> > /*
> > * State of the slab allocator.
> > *
> > --
>
> Um, yeah, looks equivalent to what I sent as v2.
>
The only difference is that memcg header is slightly move up in mm/slab.h. :)
Thanks.
--
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/
[PATCH] drivers: staging: ft1000: Fix return is not a function, parentheses are not required errors
Fix checkpatch.pl return is not a function, parentheses are not required errors
Signed-off-by: Greg Donald
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 9 +
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 21f09fe..a92bce8 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -125,7 +125,7 @@ u16 ft1000_read_dpram(struct net_device *dev, int offset)
data = ft1000_read_reg(dev, FT1000_REG_DPRAM_DATA);
spin_unlock_irqrestore(>dpram_lock, flags);
- return (data);
+ return data;
}
/*---
@@ -183,7 +183,7 @@ u16 ft1000_read_dpram_mag_16(struct net_device *dev, int
offset, int Index)
}
spin_unlock_irqrestore(>dpram_lock, flags);
- return (data);
+ return data;
}
/*---
@@ -240,7 +240,7 @@ u32 ft1000_read_dpram_mag_32(struct net_device *dev, int
offset)
data = inl(dev->base_addr + FT1000_REG_MAG_DPDATAL);
spin_unlock_irqrestore(>dpram_lock, flags);
- return (data);
+ return data;
}
/*---
@@ -1922,7 +1922,8 @@ static int ft1000_copy_down_pkt(struct net_device *dev,
u16 * packet, u16 len)
static struct net_device_stats *ft1000_stats(struct net_device *dev)
{
struct ft1000_info *info = netdev_priv(dev);
- return (>stats);
+
+ return >stats;
}
static int ft1000_open(struct net_device *dev)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
index 9f4c785..0f347ab 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
@@ -390,7 +390,7 @@ static unsigned int ft1000_poll_dev(struct file *file,
poll_table *wait)
poll_wait(file, >app_info[i].wait_dpram_msg, wait);
/* DEBUG("FT1000:ft1000_poll_dev:Polling for data from DSP\n"); */
-return (0);
+ return 0;
}
/*
--
1.9.1
--
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/
Re: [PATCH v2 3/3] KVM: x86: #GP when attempts to write reserved bits of Variable Range MTRRs
On Fri, Aug 29, 2014 at 06:47:54PM +0200, Paolo Bonzini wrote:
>Il 19/08/2014 11:04, Wanpeng Li ha scritto:
>> Section 11.11.2.3 of the SDM mentions "All other bits in the
>> IA32_MTRR_PHYSBASEn
>> and IA32_MTRR_PHYSMASKn registers are reserved; the processor generates a
>> general-protection exception(#GP) if software attempts to write to them".
>> This
>> patch do it in kvm.
>>
>> Signed-off-by: Wanpeng Li
>
>This breaks if the guest maxphyaddr is higher than the host's (which
>sometimes happens depending on your hardware and how QEMU is
>configured).
>
>You need to use cpuid_maxphyaddr, like this
>
>diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>index a375dfc42f6a..916e89515210 100644
>--- a/arch/x86/kvm/x86.c
>+++ b/arch/x86/kvm/x86.c
>@@ -1726,7 +1726,7 @@ static bool valid_mtrr_type(unsigned t)
> static bool mtrr_valid(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> {
> int i;
>- u64 mask = 0;
>+ u64 mask;
>
> if (!msr_mtrr_valid(msr))
> return false;
>@@ -1750,8 +1750,7 @@ static bool mtrr_valid(struct kvm_vcpu *vcpu, u32 msr,
>u64 data)
> /* variable MTRRs */
> WARN_ON(!(msr >= 0x200 && msr < 0x200 + 2 * KVM_NR_VAR_MTRR));
>
>- for (i = 63; i > boot_cpu_data.x86_phys_bits; i--)
>- mask |= (1ULL << i);
>+ mask = (~0ULL) << cpuid_maxphyaddr(vcpu);
> if ((msr & 1) == 0) {
> /* MTRR base */
> if (!valid_mtrr_type(data & 0xff))
>
>
Got it, thanks Paolo and Jan.
Regards,
Wanpeng Li
>Jan, can you see if this patch fixes the SeaBIOS triple fault you reported?
>
>Paolo
>
>> ---
>> arch/x86/kvm/x86.c | 18 +++---
>> 1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index fb3ea7a..b85da5f 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -1726,6 +1726,7 @@ static bool valid_mtrr_type(unsigned t)
>> static bool mtrr_valid(struct kvm_vcpu *vcpu, u32 msr, u64 data)
>> {
>> int i;
>> +u64 mask = 0;
>>
>> if (!msr_mtrr_valid(msr))
>> return false;
>> @@ -1749,10 +1750,21 @@ static bool mtrr_valid(struct kvm_vcpu *vcpu, u32
>> msr, u64 data)
>> /* variable MTRRs */
>> WARN_ON(!(msr >= 0x200 && msr < 0x200 + 2 * KVM_NR_VAR_MTRR));
>>
>> -if ((msr & 1) == 0)
>> +for (i = 63; i > boot_cpu_data.x86_phys_bits; i--)
>> +mask |= (1ULL << i);
>> +if ((msr & 1) == 0) {
>> /* MTRR base */
>> -return valid_mtrr_type(data & 0xff);
>> -/* MTRR mask */
>> +if (!valid_mtrr_type(data & 0xff))
>> +return false;
>> + mask |= 0xf00;
>> +} else
>> +/* MTRR mask */
>> +mask |= 0x7ff;
>> +if (data & mask) {
>> +kvm_inject_gp(vcpu, 0);
>> +return false;
>> +}
>> +
>> return true;
>> }
>>
>>
--
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/
Re: [PATCH 1/3] mm/slab: use percpu allocator for cpu cache
On Wed, Aug 27, 2014 at 06:37:33PM -0500, Christoph Lameter wrote:
> One minor nit. Otherwise
>
> Acked-by: Christoph Lameter
>
> On Thu, 21 Aug 2014, Joonsoo Kim wrote:
>
> > @@ -2041,56 +1982,63 @@ static size_t calculate_slab_order(struct
> > kmem_cache *cachep,
> > return left_over;
> > }
> >
> > +static int alloc_kmem_cache_cpus(struct kmem_cache *cachep, int entries,
> > + int batchcount)
> > +{
> > + cachep->cpu_cache = __alloc_kmem_cache_cpus(cachep, entries,
> > + batchcount);
> > + if (!cachep->cpu_cache)
> > + return 1;
> > +
> > + return 0;
> > +}
>
> Do we really need this trivial function? It doesnt do anything useful as
> far as I can tell.
Hello,
You are right. I will remove it in next spin.
Thanks.
--
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/
Re: [PATCH -mmotm v2] mm: fix kmemcheck.c build errors
On 08/31/14 17:13, Joonsoo Kim wrote:
> On Sun, Aug 31, 2014 at 04:33:12PM -0700, Randy Dunlap wrote:
>> On 08/31/14 07:48, Randy Dunlap wrote:
>>> On 08/31/14 04:36, Andrey Ryabinin wrote:
2014-08-30 5:48 GMT+04:00 Randy Dunlap :
> From: Randy Dunlap
>
> Add header file to fix kmemcheck.c build errors:
>
> ../mm/kmemcheck.c:70:7: error: dereferencing pointer to incomplete type
> ../mm/kmemcheck.c:83:15: error: dereferencing pointer to incomplete type
> ../mm/kmemcheck.c:95:8: error: dereferencing pointer to incomplete type
> ../mm/kmemcheck.c:95:21: error: dereferencing pointer to incomplete type
>
> Signed-off-by: Randy Dunlap
> ---
> mm/kmemcheck.c |1 +
> 1 file changed, 1 insertion(+)
>
> Index: mmotm-2014-0829-1515/mm/kmemcheck.c
> ===
> --- mmotm-2014-0829-1515.orig/mm/kmemcheck.c
> +++ mmotm-2014-0829-1515/mm/kmemcheck.c
> @@ -2,6 +2,7 @@
> #include
> #include
> #include
> +#include
This will work only for CONFIG_SLAB=y. struct kmem_cache definition
was moved to internal header [*],
so you need to include it here:
#include "slab.h"
[*]
http://ozlabs.org/~akpm/mmotm/broken-out/mm-slab_common-move-kmem_cache-definition-to-internal-header.patch
>>>
>>> Thanks. That makes sense. [testing] mm/kmemcheck.c still has a build
>>> error:
>>>
>>> In file included from ../mm/kmemcheck.c:5:0:
>>> ../mm/slab.h: In function 'cache_from_obj':
>>> ../mm/slab.h:283:2: error: implicit declaration of function
>>> 'memcg_kmem_enabled' [-Werror=implicit-function-declaration]
>>>
>>
>> Naughty header file. It uses something from without
>> #including that header file...
>
>
> Hello.
>
> Indeed...
> Thanks for catching this.
>
>>
>> Working patch is below.
>
> With your patch, build also failed if CONFIG_MEMCG_KMEM=y.
> Right fix is something like below.
>
> Thanks.
>
> ->8--
> diff --git a/mm/kmemcheck.c b/mm/kmemcheck.c
> index fd814fd..cab58bb 100644
> --- a/mm/kmemcheck.c
> +++ b/mm/kmemcheck.c
> @@ -2,6 +2,7 @@
> #include
> #include
> #include
> +#include "slab.h"
> #include
>
> void kmemcheck_alloc_shadow(struct page *page, int order, gfp_t flags, int
> node)
> diff --git a/mm/slab.h b/mm/slab.h
> index 13845d0..963a3f8 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -37,6 +37,8 @@ struct kmem_cache {
> #include
> #endif
>
> +#include
> +
> /*
> * State of the slab allocator.
> *
> --
Um, yeah, looks equivalent to what I sent as v2.
Thanks.
--
~Randy
--
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/
Re: [RFC PATCH v3 4/4] mm/page_alloc: restrict max order of merging on isolated pageblock
On Fri, Aug 29, 2014 at 12:52:44PM -0400, Naoya Horiguchi wrote:
> Hi Joonsoo,
>
> On Tue, Aug 26, 2014 at 05:08:18PM +0900, Joonsoo Kim wrote:
> > Current pageblock isolation logic could isolate each pageblock
> > individually. This causes freepage accounting problem if freepage with
> > pageblock order on isolate pageblock is merged with other freepage on
> > normal pageblock. We can prevent merging by restricting max order of
> > merging to pageblock order if freepage is on isolate pageblock.
> >
> > Side-effect of this change is that there could be non-merged buddy
> > freepage even if finishing pageblock isolation, because undoing pageblock
> > isolation is just to move freepage from isolate buddy list to normal buddy
> > list rather than to consider merging. But, I think it doesn't matter
> > because 1) almost allocation request are for equal or below pageblock
> > order, 2) caller of pageblock isolation will use this freepage so
> > freepage will split in any case and 3) merge would happen soon after
> > some alloc/free on this and buddy pageblock.
> >
> > Signed-off-by: Joonsoo Kim
> > ---
> > mm/page_alloc.c | 15 ---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 809bfd3..8ba9fb0 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -570,6 +570,7 @@ static inline void __free_one_page(struct page *page,
> > unsigned long combined_idx;
> > unsigned long uninitialized_var(buddy_idx);
> > struct page *buddy;
> > + int max_order = MAX_ORDER;
> >
> > VM_BUG_ON(!zone_is_initialized(zone));
> >
> > @@ -580,18 +581,26 @@ static inline void __free_one_page(struct page *page,
> > VM_BUG_ON(migratetype == -1);
> > if (unlikely(has_isolate_pageblock(zone))) {
> > migratetype = get_pfnblock_migratetype(page, pfn);
> > - if (is_migrate_isolate(migratetype))
> > + if (is_migrate_isolate(migratetype)) {
> > + /*
> > +* We restrict max order of merging to prevent merge
> > +* between freepages on isolate pageblock and normal
> > +* pageblock. Without this, pageblock isolation
> > +* could cause incorrect freepage accounting.
> > +*/
> > + max_order = pageblock_order + 1;
>
> When pageblock_order >= max_order, order in the while loop below could
> go beyond MAX_ORDER - 1. Or does it never happen?
Yes, you are right. Will fix it in next spin.
Thanks.
--
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/
Re: [RFC PATCH v3 1/4] mm/page_alloc: fix incorrect isolation behavior by rechecking migratetype
On Fri, Aug 29, 2014 at 01:46:41PM -0400, Naoya Horiguchi wrote:
> On Tue, Aug 26, 2014 at 05:08:15PM +0900, Joonsoo Kim wrote:
> > There are two paths to reach core free function of buddy allocator,
> > __free_one_page(), one is free_one_page()->__free_one_page() and the
> > other is free_hot_cold_page()->free_pcppages_bulk()->__free_one_page().
> > Each paths has race condition causing serious problems. At first, this
> > patch is focused on first type of freepath. And then, following patch
> > will solve the problem in second type of freepath.
> >
> > In the first type of freepath, we got migratetype of freeing page without
> > holding the zone lock, so it could be racy. There are two cases of this
> > race.
> >
> > 1. pages are added to isolate buddy list after restoring orignal
> > migratetype
> >
> > CPU1 CPU2
> >
> > get migratetype => return MIGRATE_ISOLATE
> > call free_one_page() with MIGRATE_ISOLATE
> >
> > grab the zone lock
> > unisolate pageblock
> > release the zone lock
> >
> > grab the zone lock
> > call __free_one_page() with MIGRATE_ISOLATE
> > freepage go into isolate buddy list,
> > although pageblock is already unisolated
> >
> > This may cause two problems. One is that we can't use this page anymore
> > until next isolation attempt of this pageblock, because freepage is on
> > isolate pageblock. The other is that freepage accouting could be wrong
> > due to merging between different buddy list. Freepages on isolate buddy
> > list aren't counted as freepage, but ones on normal buddy list are counted
> > as freepage. If merge happens, buddy freepage on normal buddy list is
> > inevitably moved to isolate buddy list without any consideration of
> > freepage accouting so it could be incorrect.
> >
> > 2. pages are added to normal buddy list while pageblock is isolated.
> > It is similar with above case.
> >
> > This also may cause two problems. One is that we can't keep these
> > freepages from being allocated. Although this pageblock is isolated,
> > freepage would be added to normal buddy list so that it could be
> > allocated without any restriction. And the other problem is same as
> > case 1, that it, incorrect freepage accouting.
> >
> > This race condition would be prevented by checking migratetype again
> > with holding the zone lock. Because it is somewhat heavy operation
> > and it isn't needed in common case, we want to avoid rechecking as much
> > as possible. So this patch introduce new variable, nr_isolate_pageblock
> > in struct zone to check if there is isolated pageblock.
> > With this, we can avoid to re-check migratetype in common case and do
> > it only if there is isolated pageblock. This solve above
> > mentioned problems.
> >
> > Signed-off-by: Joonsoo Kim
> > ---
> > include/linux/mmzone.h |4
> > include/linux/page-isolation.h |8
> > mm/page_alloc.c| 10 --
> > mm/page_isolation.c|2 ++
> > 4 files changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 318df70..23e69f1 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -431,6 +431,10 @@ struct zone {
> > */
> > int nr_migrate_reserve_block;
> >
> > +#ifdef CONFIG_MEMORY_ISOLATION
>
> It's worth adding some comment, especially about locking?
> The patch itself looks good me.
Okay. Will do. :)
Thanks.
--
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/
Re: [PATCH -mmotm v2] mm: fix kmemcheck.c build errors
On Sun, Aug 31, 2014 at 04:33:12PM -0700, Randy Dunlap wrote:
> On 08/31/14 07:48, Randy Dunlap wrote:
> > On 08/31/14 04:36, Andrey Ryabinin wrote:
> >> 2014-08-30 5:48 GMT+04:00 Randy Dunlap :
> >>> From: Randy Dunlap
> >>>
> >>> Add header file to fix kmemcheck.c build errors:
> >>>
> >>> ../mm/kmemcheck.c:70:7: error: dereferencing pointer to incomplete type
> >>> ../mm/kmemcheck.c:83:15: error: dereferencing pointer to incomplete type
> >>> ../mm/kmemcheck.c:95:8: error: dereferencing pointer to incomplete type
> >>> ../mm/kmemcheck.c:95:21: error: dereferencing pointer to incomplete type
> >>>
> >>> Signed-off-by: Randy Dunlap
> >>> ---
> >>> mm/kmemcheck.c |1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> Index: mmotm-2014-0829-1515/mm/kmemcheck.c
> >>> ===
> >>> --- mmotm-2014-0829-1515.orig/mm/kmemcheck.c
> >>> +++ mmotm-2014-0829-1515/mm/kmemcheck.c
> >>> @@ -2,6 +2,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>
> >> This will work only for CONFIG_SLAB=y. struct kmem_cache definition
> >> was moved to internal header [*],
> >> so you need to include it here:
> >> #include "slab.h"
> >>
> >> [*]
> >> http://ozlabs.org/~akpm/mmotm/broken-out/mm-slab_common-move-kmem_cache-definition-to-internal-header.patch
> >
> > Thanks. That makes sense. [testing] mm/kmemcheck.c still has a build
> > error:
> >
> > In file included from ../mm/kmemcheck.c:5:0:
> > ../mm/slab.h: In function 'cache_from_obj':
> > ../mm/slab.h:283:2: error: implicit declaration of function
> > 'memcg_kmem_enabled' [-Werror=implicit-function-declaration]
> >
>
> Naughty header file. It uses something from without
> #including that header file...
Hello.
Indeed...
Thanks for catching this.
>
> Working patch is below.
With your patch, build also failed if CONFIG_MEMCG_KMEM=y.
Right fix is something like below.
Thanks.
->8--
diff --git a/mm/kmemcheck.c b/mm/kmemcheck.c
index fd814fd..cab58bb 100644
--- a/mm/kmemcheck.c
+++ b/mm/kmemcheck.c
@@ -2,6 +2,7 @@
#include
#include
#include
+#include "slab.h"
#include
void kmemcheck_alloc_shadow(struct page *page, int order, gfp_t flags, int
node)
diff --git a/mm/slab.h b/mm/slab.h
index 13845d0..963a3f8 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -37,6 +37,8 @@ struct kmem_cache {
#include
#endif
+#include
+
/*
* State of the slab allocator.
*
--
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/
Re: [PATCH v2] serial: serial_core.c: printk replacement
On 29/08/14 00:15, Sudip Mukherjee wrote:
> printk replaced with corresponding pr_err, dev_alert, dev_notice and pr_info.
> fixed two broken user-visible strings used by the corresponding printk
>
> Signed-off-by: Sudip Mukherjee
> ---
>
> In the first patch i sent Greg suggested to use dev_err instead of pr_err ,
> but as later Jiri pointed out in my later patches that uport->dev is having a
> null check so can not be used , tty_dev is also having a put_device , so back
> to pr_err.
>
> drivers/tty/serial/serial_core.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> @@ -1975,12 +1976,11 @@ int uart_suspend_port(struct uart_driver *drv, struct
> uart_port *uport)
> for (tries = 3; !ops->tx_empty(uport) && tries; tries--)
> msleep(10);
> if (!tries)
> - printk(KERN_ERR "%s%s%s%d: Unable to drain "
> - "transmitter\n",
> -uport->dev ? dev_name(uport->dev) : "",
> -uport->dev ? ": " : "",
> -drv->dev_name,
> -drv->tty_driver->name_base + uport->line);
> + pr_err("%s%s%s%d: Unable to drain transmitter\n",
> + uport->dev ? dev_name(uport->dev) : "",
> + uport->dev ? ": " : "",
> + drv->dev_name,
> + drv->tty_driver->name_base + uport->line);
dev_printk() prints the value of dev_name() and handles the NULL case,
so this could be changed to:
dev_err(uport->dev, "%s%d: Unable to drain transmitter\n",
drv->dev_name,
drv->tty_driver->name_base + uport->line);
It might also be possible to remove drv->dev_name since dev_printk()
also prints the driver string, but I don't know if they are equivalent
in this case.
>
> if (console_suspend_enabled || !uart_console(uport))
> ops->shutdown(uport);
> @@ -2109,7 +2109,7 @@ uart_report_port(struct uart_driver *drv, struct
> uart_port *port)
> break;
> }
>
> - printk(KERN_INFO "%s%s%s%d at %s (irq = %d, base_baud = %d) is a %s\n",
> + pr_info("%s%s%s%d at %s (irq = %d, base_baud = %d) is a %s\n",
> port->dev ? dev_name(port->dev) : "",
> port->dev ? ": " : "",
> drv->dev_name,
Same here.
~Ryan
--
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/
Re: [PATCH] drm/vmwgfx: select FB when DRM_VMWGFX is selected
On Mon, Sep 1, 2014 at 3:20 AM, Randy Dunlap wrote: > On 08/31/14 16:07, Max Filippov wrote: >> Otherwise, if FB is not selected build fails at linking step: >> vmwgfx_fb.c:(.text+0x4098b): undefined reference to `register_framebuffer' >> vmwgfx_fb.c:(.text+0x409c0): undefined reference to `framebuffer_release' >> vmwgfx_fb.c:(.text+0x409f4): undefined reference to >> `unregister_framebuffer' >> vmwgfx_fb.c:(.text+0x40a0e): undefined reference to `framebuffer_release' >> >> Patch ae6445ac7475ff05 drm/vmwgfx: depends on FB >> added dependency on FB that was subsequently removed in patch >> 04381b987292256d drm: Move plane helpers into drm_kms_helper.ko >> >> Signed-off-by: Max Filippov >> --- >> drivers/gpu/drm/vmwgfx/Kconfig |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig >> index 67720f7..4fba548 100644 >> --- a/drivers/gpu/drm/vmwgfx/Kconfig >> +++ b/drivers/gpu/drm/vmwgfx/Kconfig >> @@ -1,6 +1,7 @@ >> config DRM_VMWGFX >> tristate "DRM driver for VMware Virtual GPU" >> depends on DRM && PCI >> + select FB >> select FB_DEFERRED_IO >> select FB_CFB_FILLRECT >> select FB_CFB_COPYAREA >> > > My experience with these "select FB_*" things is that this symbol (DRM_VMWGFX) > should still depend on FB. Has something changed recently to negate that? I see the following if I replace 'select FB' with 'depends on FB': drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:39: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:33: symbol DRM_KMS_HELPER is selected by DRM_VMWGFX drivers/gpu/drm/vmwgfx/Kconfig:1: symbol DRM_VMWGFX depends on FB -- Thanks. -- Max -- 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/
Status of 'unicore32' architecture in Linux kernel
Status of 'unicore32' architecture in Linux kernel -- The idea was to create a working kernel and initramfs for the ongoing Linux kernel test project. This summary describes the result of this effort. Overall, conclusion is that the architecture would need some work (both in qemu and the kernel itself) to make it testable with qemu. Guenter - Toolchain used was from [1]. I did not attempt to build my own toolchain. Configuration: make ARCH=unicore32 defconfig && make ARCH=unicore32 This configuration currently fails to build in the upstream kernel. A patch to fix the problem has been submitted and is pending upstream integration [2]. With this patch merged, the 'defconfig' image can be built. qemu Attempts to load the unicore32:defconfig image with qemu failed. Research points to [3], which includes a working unicore32 linux kernel in its linux repository [4], in branch unicore32-working. This branch includes a working unicore32 qemu configuration. It also includes a critical patch which is not available in the upstream kernel. unicore32: Add ocd console and qemu-defconfig to support qemu simulator This patch adds a primitive OCD console to communicate with qemu. The same code is already used for early console support. With this patch added, and with qemu_defconfig as provided by the same patch, it is possible to build and load a unicore32 image in qemu using the following qemu command line. qemu-system-unicore32 -curses -M puv3 -m 512 -kernel arch/unicore32/boot/zImage Caveats: - The use of -nographic instead of -curses causes a qemu crash - The qemu emulation only accepts a built-in initramfs. - The only working image is arch/unicore32/boot/zImage. All other variants, arch/unicore32/boot/Image and vmlinux, cause a crash. The same (or a similar) crash is also seen if I don't provide a built-in kernel command line and try to load zImage. - There is no networking. There is another patch in the github linux respository [4] which is not available upstream. The driver was submitted for integration back in 2011 [5] but it was never accepted or merged. [1] http://mprc.pku.edu.cn/~guanxuetao/linux/ [2] https://lkml.org/lkml/2014/8/31/86 [3] https://github.com/gxt [4] git://github.com/gxt/linux.git [5] https://lkml.org/lkml/2011/5/27/17 -- 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/
Re: [RFC v1 0/3] driver-core: add asynch module loading support
Hello, Dmitry. On Sun, Aug 31, 2014 at 04:06:51PM -0700, Dmitry Torokhov wrote: > On Sun, Aug 31, 2014 at 06:02:38PM -0400, Tejun Heo wrote: > > Hmmm... that is a different case from the one I'm aware of - userland > > timing out on module probing and sending SIGKILL aborting device > > probing, which is taking long but still making progress properly. > > Right, it is definitely different use case. Here we just have a touchpad > taking > 1.5-2 secs to initialize and thus stalling the overall boot progress. Ah, yeah, that's a completely different issue and what other drivers solve by using async_schedule() mechanism. > > Yeah, at first I was applying the async thing to built-in drivers too > > so the ordering was kinda necessary but I don't think it matters at > > all for modules. > > Why are we talking about modules? The touchpad driver is built-in in my case. Because that was the issue which started this patch series. It wasn't about speeding up boot process but about probe failure from SIGKILL from userland after timing out module loading. > > I don't get this. The relationship between the driver and its devices > > is 1:N. If a driver fails to bind to a device, it should properly > > unbind from that device but still remain available so that it can be > > used when another device becomes available. The two have completely > > different life cycles. If you take a look at > > drivers/base/dd.c::__driver_attach(), the function ignores error > > return from probing. The return types are pretty misleading due to > > historical reasons but we already do not fail module loading after > > probing failure, so making probing asynchronous shouldn't really > > change anything. > > I think we are talking about 2 different things. I am talking about probe() Heh, yeah, we sure are. > taking too long and stalling overall boot process. Yes, we can change > individual drivers to use async_schedule() to do longer operations That's the course we took for all other drivers. > asynchronously, but if something that was scheduled asynchronously fails we do > not have a convenient way to signal driver core that bind operation failed. We > would end up with driver being bound to the device but device would not be > operational. This is different from synchronous probing where any failure > would > cause probe() to return error and bind operation to fail. Hmmm... I guess there's genuine difference in probing sequence between input and scsi / libata. For scsi / libata, the probing of actual devices takes place outside the probe function of the controller itself. The controller probing is still synchronous but probing of devices attached to that controller is asynchronous. I guess the problem you have is that the controller probe function itself takes long time and there's no good way to make that asynchronous. Yeah, I suppose that can be solved together with the module probing timeout issue. Thanks. -- tejun -- 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/
[PATCH -mmotm v2] mm: fix kmemcheck.c build errors
On 08/31/14 07:48, Randy Dunlap wrote:
> On 08/31/14 04:36, Andrey Ryabinin wrote:
>> 2014-08-30 5:48 GMT+04:00 Randy Dunlap :
>>> From: Randy Dunlap
>>>
>>> Add header file to fix kmemcheck.c build errors:
>>>
>>> ../mm/kmemcheck.c:70:7: error: dereferencing pointer to incomplete type
>>> ../mm/kmemcheck.c:83:15: error: dereferencing pointer to incomplete type
>>> ../mm/kmemcheck.c:95:8: error: dereferencing pointer to incomplete type
>>> ../mm/kmemcheck.c:95:21: error: dereferencing pointer to incomplete type
>>>
>>> Signed-off-by: Randy Dunlap
>>> ---
>>> mm/kmemcheck.c |1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> Index: mmotm-2014-0829-1515/mm/kmemcheck.c
>>> ===
>>> --- mmotm-2014-0829-1515.orig/mm/kmemcheck.c
>>> +++ mmotm-2014-0829-1515/mm/kmemcheck.c
>>> @@ -2,6 +2,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>
>> This will work only for CONFIG_SLAB=y. struct kmem_cache definition
>> was moved to internal header [*],
>> so you need to include it here:
>> #include "slab.h"
>>
>> [*]
>> http://ozlabs.org/~akpm/mmotm/broken-out/mm-slab_common-move-kmem_cache-definition-to-internal-header.patch
>
> Thanks. That makes sense. [testing] mm/kmemcheck.c still has a build error:
>
> In file included from ../mm/kmemcheck.c:5:0:
> ../mm/slab.h: In function 'cache_from_obj':
> ../mm/slab.h:283:2: error: implicit declaration of function
> 'memcg_kmem_enabled' [-Werror=implicit-function-declaration]
>
Naughty header file. It uses something from without
#including that header file...
Working patch is below.
>
> Maybe Andrew should just drop that patch and its associated patches.
>
>
>>> #include
>>>
>>> void kmemcheck_alloc_shadow(struct page *page, int order, gfp_t flags, int
>>> node)
From: Randy Dunlap
Add header files to fix kmemcheck.c build errors:
../mm/kmemcheck.c:70:7: error: dereferencing pointer to incomplete type
../mm/kmemcheck.c:83:15: error: dereferencing pointer to incomplete type
../mm/kmemcheck.c:95:8: error: dereferencing pointer to incomplete type
../mm/kmemcheck.c:95:21: error: dereferencing pointer to incomplete type
../mm/slab.h: In function 'cache_from_obj':
../mm/slab.h:283:2: error: implicit declaration of function
'memcg_kmem_enabled' [-Werror=implicit-function-declaration]
Signed-off-by: Randy Dunlap
---
mm/kmemcheck.c |1 +
mm/slab.h |2 ++
2 files changed, 3 insertions(+)
Index: mmotm-2014-0829-1515/mm/kmemcheck.c
===
--- mmotm-2014-0829-1515.orig/mm/kmemcheck.c
+++ mmotm-2014-0829-1515/mm/kmemcheck.c
@@ -2,6 +2,7 @@
#include
#include
#include
+#include "slab.h"
#include
void kmemcheck_alloc_shadow(struct page *page, int order, gfp_t flags, int
node)
Index: mmotm-2014-0829-1515/mm/slab.h
===
--- mmotm-2014-0829-1515.orig/mm/slab.h
+++ mmotm-2014-0829-1515/mm/slab.h
@@ -268,6 +268,8 @@ static inline void memcg_uncharge_slab(s
}
#endif
+#include
+
static inline struct kmem_cache *cache_from_obj(struct kmem_cache *s, void *x)
{
struct kmem_cache *cachep;
--
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/
Re: [RFC v1 0/3] driver-core: add asynch module loading support
Hello, On Sun, Aug 31, 2014 at 04:20:08PM -0700, Arjan van de Ven wrote: > >Oh, but there already is a reported case which fails. Hard drives > >with a lot of platters take > 10secs to spin up and there are > >configurations which regularly fail the initial reset and it's quite > >rare but probing time taking over 30s does happen in the wild. We > >can't mark libata as requiring async probing on module load > >unconditionally but at the same time we need them to be asynchronous > >for use cases which don't depend on synchronous behavior has has > >timeout. > > libata probing is already async thankfully. Heh, why is there so much confusion on what the problem is in this thread? libata probing is fully parallelized but is still synchronous against module probing. module probing performs async_synchronize_full() if the the module loading thread did any async_schedule() calls and we need that behavior for backward compatibility; however, the exact same behavior is causing problem because it can take longer than 30s, so we need a way to separate out probing from loading so that probing actually becomes asynchronous against module loading. Thanks. -- tejun -- 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/
[3.16.1 REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16
So I upgraded to 3.16.1 and found that the Simtec Entropy Key (a cdc-acm device) was no longer operational: fold:~# ekeydctl stats 1 BytesRead=0 BytesWritten=0 ConnectionNonces=0 ConnectionPackets=0 ConnectionRekeys=0 ConnectionResets=0 ConnectionTime=65 EntropyRate=0 FipsFrameRate=0 FrameByteLast=0 FramesOk=0 FramingErrors=0 KeyDbsdShannonPerByteL=0 KeyDbsdShannonPerByteR=0 KeyEnglishBadness=No failure KeyRawBadness=0 KeyRawShannonPerByteL=0 KeyRawShannonPerByteR=0 KeyRawShannonPerByteX=0 KeyShortBadness=efm_ok KeyTemperatureC=-273.15 KeyTemperatureF=-459.67 KeyTemperatureK=0 KeyVoltage=0 PacketErrors=0 PacketOK=0 ReadRate=0 TotalEntropy=0 WriteRate=0 This device streams data continuously at at rate of several KiB/s, so normally we would never expect to see a report of zero bytes read or written if the key were functional (nor, indeed, a key temperature of absolute zero!) It appears that cdc-acm has broken such that no data is received from this device any more (though it's still being detected, according to the dmesg log). Something goes very askew with the entropy key -- even after rebooting back to an earlier kernel, a physical disconnection and reconnection of the entropy key is needed to make it work again. Whether this is some sort of cdc-acm-level protocol problem, or a key-level problem caused by interrupted communication, I have no clue. 3.15.8 works fine. I'll do a bisection of the cdc-acm changes since 3.15 tomorrow night and see if I can find the commit at fault. -- NULL && (void) -- 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/
Re: [PATCH] Documentation: misc-devices: Rename freefall.c from hpfall.c in lis2lv02d
On 08/31/14 06:18, Masanari Iida wrote: > hpfall.c was renamed to freefall.c in 3.16. > But this file still refer to hpfall.c instead of freefall.c > > Signed-off-by: Masanari Iida > --- > Documentation/misc-devices/lis3lv02d | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/misc-devices/lis3lv02d > b/Documentation/misc-devices/lis3lv02d > index af815b9..f89960a 100644 > --- a/Documentation/misc-devices/lis3lv02d > +++ b/Documentation/misc-devices/lis3lv02d > @@ -59,7 +59,7 @@ acts similar to /dev/rtc and reacts on free-fall interrupts > received > from the device. It supports blocking operations, poll/select and > fasync operation modes. You must read 1 bytes from the device. The > result is number of free-fall interrupts since the last successful > -read (or 255 if number of interrupts would not fit). See the hpfall.c > +read (or 255 if number of interrupts would not fit). See the freefall.c > file for an example on using the device. > > > Applied. Thanks. -- ~Randy -- 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/
Re: [RFC v1 0/3] driver-core: add asynch module loading support
On 8/31/2014 3:53 PM, Tejun Heo wrote: Hello, On Sun, Aug 31, 2014 at 03:15:34PM -0700, Greg KH wrote: For the use cases we have today, it would work. We have a few drivers that take a _long_ time in their probe callback, and they need to be made async for various reasons (modprobe timeout killer, touchscreen init sequence stalling boot, etc.) Oh, but there already is a reported case which fails. Hard drives with a lot of platters take > 10secs to spin up and there are configurations which regularly fail the initial reset and it's quite rare but probing time taking over 30s does happen in the wild. We can't mark libata as requiring async probing on module load unconditionally but at the same time we need them to be asynchronous for use cases which don't depend on synchronous behavior has has timeout. libata probing is already async thankfully. -- 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/
Re: [PATCH] drm/vmwgfx: select FB when DRM_VMWGFX is selected
On 08/31/14 16:07, Max Filippov wrote: > Otherwise, if FB is not selected build fails at linking step: > vmwgfx_fb.c:(.text+0x4098b): undefined reference to `register_framebuffer' > vmwgfx_fb.c:(.text+0x409c0): undefined reference to `framebuffer_release' > vmwgfx_fb.c:(.text+0x409f4): undefined reference to `unregister_framebuffer' > vmwgfx_fb.c:(.text+0x40a0e): undefined reference to `framebuffer_release' > > Patch ae6445ac7475ff05 drm/vmwgfx: depends on FB > added dependency on FB that was subsequently removed in patch > 04381b987292256d drm: Move plane helpers into drm_kms_helper.ko > > Signed-off-by: Max Filippov > --- > drivers/gpu/drm/vmwgfx/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig > index 67720f7..4fba548 100644 > --- a/drivers/gpu/drm/vmwgfx/Kconfig > +++ b/drivers/gpu/drm/vmwgfx/Kconfig > @@ -1,6 +1,7 @@ > config DRM_VMWGFX > tristate "DRM driver for VMware Virtual GPU" > depends on DRM && PCI > + select FB > select FB_DEFERRED_IO > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > My experience with these "select FB_*" things is that this symbol (DRM_VMWGFX) should still depend on FB. Has something changed recently to negate that? -- ~Randy -- 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/
[PATCH] scsi_debug: deadlock between completions and surprise module removal
A deadlock has been reported when the completion
of SCSI commands (simulated by a timer) was surprised
by a module removal. This patch removes one half of
the offending locks around timer deletions. This fix
is applied both to stop_all_queued() which is were
the deadlock was discovered and stop_queued_cmnd()
which has very similar logic.
This patch should be applied both to the lk 3.17 tree
and Christoph's drivers-for-3.18 tree.
Tested-and-reported-by: Milan Broz
Signed-off-by: Douglas Gilbert
--- a/drivers/scsi/scsi_debug.c 2014-08-26 13:24:51.646948507 -0400
+++ b/drivers/scsi/scsi_debug.c 2014-08-30 18:04:54.589226679 -0400
@@ -2743,6 +2743,13 @@ static int stop_queued_cmnd(struct scsi_
if (test_bit(k, queued_in_use_bm)) {
sqcp = _arr[k];
if (cmnd == sqcp->a_cmnd) {
+devip = (struct sdebug_dev_info *)
+ cmnd->device->hostdata;
+if (devip)
+ atomic_dec(>num_in_q);
+sqcp->a_cmnd = NULL;
+spin_unlock_irqrestore(_arr_lock,
+ iflags);
if (scsi_debug_ndelay > 0) {
if (sqcp->sd_hrtp)
hrtimer_cancel(
@@ -2755,18 +2762,13 @@ static int stop_queued_cmnd(struct scsi_
if (sqcp->tletp)
tasklet_kill(sqcp->tletp);
}
-__clear_bit(k, queued_in_use_bm);
-devip = (struct sdebug_dev_info *)
- cmnd->device->hostdata;
-if (devip)
- atomic_dec(>num_in_q);
-sqcp->a_cmnd = NULL;
-break;
+clear_bit(k, queued_in_use_bm);
+return 1;
}
}
}
spin_unlock_irqrestore(_arr_lock, iflags);
- return (k < qmax) ? 1 : 0;
+ return 0;
}
/* Deletes (stops) timers or tasklets of all queued commands */
@@ -2782,6 +2784,13 @@ static void stop_all_queued(void)
if (test_bit(k, queued_in_use_bm)) {
sqcp = _arr[k];
if (sqcp->a_cmnd) {
+devip = (struct sdebug_dev_info *)
+ sqcp->a_cmnd->device->hostdata;
+if (devip)
+ atomic_dec(>num_in_q);
+sqcp->a_cmnd = NULL;
+spin_unlock_irqrestore(_arr_lock,
+ iflags);
if (scsi_debug_ndelay > 0) {
if (sqcp->sd_hrtp)
hrtimer_cancel(
@@ -2794,12 +2803,8 @@ static void stop_all_queued(void)
if (sqcp->tletp)
tasklet_kill(sqcp->tletp);
}
-__clear_bit(k, queued_in_use_bm);
-devip = (struct sdebug_dev_info *)
- sqcp->a_cmnd->device->hostdata;
-if (devip)
- atomic_dec(>num_in_q);
-sqcp->a_cmnd = NULL;
+clear_bit(k, queued_in_use_bm);
+spin_lock_irqsave(_arr_lock, iflags);
}
}
}
[PATCH] drm/vmwgfx: select FB when DRM_VMWGFX is selected
Otherwise, if FB is not selected build fails at linking step: vmwgfx_fb.c:(.text+0x4098b): undefined reference to `register_framebuffer' vmwgfx_fb.c:(.text+0x409c0): undefined reference to `framebuffer_release' vmwgfx_fb.c:(.text+0x409f4): undefined reference to `unregister_framebuffer' vmwgfx_fb.c:(.text+0x40a0e): undefined reference to `framebuffer_release' Patch ae6445ac7475ff05 drm/vmwgfx: depends on FB added dependency on FB that was subsequently removed in patch 04381b987292256d drm: Move plane helpers into drm_kms_helper.ko Signed-off-by: Max Filippov --- drivers/gpu/drm/vmwgfx/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig index 67720f7..4fba548 100644 --- a/drivers/gpu/drm/vmwgfx/Kconfig +++ b/drivers/gpu/drm/vmwgfx/Kconfig @@ -1,6 +1,7 @@ config DRM_VMWGFX tristate "DRM driver for VMware Virtual GPU" depends on DRM && PCI + select FB select FB_DEFERRED_IO select FB_CFB_FILLRECT select FB_CFB_COPYAREA -- 1.7.7.6 -- 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/
Re: [RFC v1 0/3] driver-core: add asynch module loading support
On Sun, Aug 31, 2014 at 06:02:38PM -0400, Tejun Heo wrote: > Hello, Dmitry. > > On Sun, Aug 31, 2014 at 11:28:51AM -0700, Dmitry Torokhov wrote: > > HI Tejun, > > > > On Sun, Aug 31, 2014 at 06:13:58AM -0400, Tejun Heo wrote: > > > I haven't followed the previous discussions so please let me know if > > > this has been discussed before. It looks like you're trying to extend > > > the async mechanism and applying them to init functions themselves. > > > That sounds kinda weird to me. Isn't the root cause of the problem > > > doing device probings along with driver initilaization on module load? > > > > For my use case it is driver initialization itself (because most of the > > relevant drivers is compiled in). Although, come to think, if we could do > > Hmmm... that is a different case from the one I'm aware of - userland > timing out on module probing and sending SIGKILL aborting device > probing, which is taking long but still making progress properly. Right, it is definitely different use case. Here we just have a touchpad taking 1.5-2 secs to initialize and thus stalling the overall boot progress. > > > something about resume that would be nice too: then I'd be able to drop all > > stuff in serio that lies about device state and marks it as resumed even > > though > > mouse/touchpad will be actually reset and operable much later. > > > > > Wouldn't it be more logical to simply make bus_add_driver() -> > > > driver_attach() invocation asynchronous? There's no reason to make > > > them parallel either. We can use an ordered queue for it so that we > > > don't lose the probing order we used to have. > > > > Sometimes losing probing order is the desired outcome though. Like with my > > beloved touchpad :) > > Yeah, at first I was applying the async thing to built-in drivers too > so the ordering was kinda necessary but I don't think it matters at > all for modules. Why are we talking about modules? The touchpad driver is built-in in my case. > > > > Making things go > > > parallel is the responsibility of each probing function after all and > > > there isn't much to gain by making attach calls go parallel. > > > > If we make probe function schedule stuff asynchronously, then, in case of > > failures, we'll end up with half-bound driver. Also drivers would have to > > have > > additional code on removal to make sure probe full done before removing. PM > > methods need to be ready to be called on half-initialized device. It is a > > mess. > > I don't get this. The relationship between the driver and its devices > is 1:N. If a driver fails to bind to a device, it should properly > unbind from that device but still remain available so that it can be > used when another device becomes available. The two have completely > different life cycles. If you take a look at > drivers/base/dd.c::__driver_attach(), the function ignores error > return from probing. The return types are pretty misleading due to > historical reasons but we already do not fail module loading after > probing failure, so making probing asynchronous shouldn't really > change anything. I think we are talking about 2 different things. I am talking about probe() taking too long and stalling overall boot process. Yes, we can change individual drivers to use async_schedule() to do longer operations asynchronously, but if something that was scheduled asynchronously fails we do not have a convenient way to signal driver core that bind operation failed. We would end up with driver being bound to the device but device would not be operational. This is different from synchronous probing where any failure would cause probe() to return error and bind operation to fail. Thanks. -- Dmitry -- 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/
Re: [RFC v1 0/3] driver-core: add asynch module loading support
Hello, Dmitry. On Sun, Aug 31, 2014 at 03:51:40PM -0700, Dmitry Torokhov wrote: > > > Luis, care to redo the patches in this way? It should be a lot simpler > > > (no messing around with init levels and linker fun...) > > > > I don't think binding that switch to the driver is gonna work. This > > is mainly about the behavior expected by the entity which initiated > > module loading not about specific drivers. > > Why would you say that? In my particular userspace we do not have modules. Heh, I think we're just thinking about different problems. For me, this is all from the bug report that I was cc'd on where systemd times out module load after 30s and sends SIG_KILL to the module loading thread which aborts module loading which in turn leads to nasty things. The logical way to address that is separating out module loading and device probing. Given the way we associate drivers with devices these days, it makes a lot of sense to separate them out anyway. > > I'm fairly certain that > > there are userland scripts which depend on synchronous device probing > > on module loading, especially for storage devices, so we can't simply > > mark, say, libata as needing async probing and do it always > > asynchronously. > > Right. But for many devices (input ones for example, USB as well, etc) that > are > essentially hot-pluggable userspace has been long ready to handle async order. Sure, all modern userspace should be completely fine without ordering but there are niche userspaces out in the wild which don't do much of the dynamic things and just expect devices to be assigned consistent nodes across multiple boots, so keeping the order is mostly about backward compatibility. Thanks. -- tejun -- 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/
Re: [RFC v1 0/3] driver-core: add asynch module loading support
Hello, On Sun, Aug 31, 2014 at 03:15:34PM -0700, Greg KH wrote: > For the use cases we have today, it would work. We have a few drivers > that take a _long_ time in their probe callback, and they need to be > made async for various reasons (modprobe timeout killer, touchscreen > init sequence stalling boot, etc.) Oh, but there already is a reported case which fails. Hard drives with a lot of platters take > 10secs to spin up and there are configurations which regularly fail the initial reset and it's quite rare but probing time taking over 30s does happen in the wild. We can't mark libata as requiring async probing on module load unconditionally but at the same time we need them to be asynchronous for use cases which don't depend on synchronous behavior has has timeout. > I'm not saying to mark drivers that require synchronous probing with > this flag, that would be broken and wrong. I don't think we can distinguish the two sets by drivers. Thanks. -- tejun -- 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/
Re: [RFC v1 0/3] driver-core: add asynch module loading support
On Sun, Aug 31, 2014 at 05:53:13PM -0400, Tejun Heo wrote: > Hello, Greg. > > On Sun, Aug 31, 2014 at 01:40:35PM -0700, Greg KH wrote: > > > Right, all (well almost all) I wanted is for individual drivers to declare > > > their probe() functions asynchronous and driver core scheduling async > > > attach > > > and properly handle failures from it. > > > > Yes, that's what I want as well. > > > > Luis, care to redo the patches in this way? It should be a lot simpler > > (no messing around with init levels and linker fun...) > > I don't think binding that switch to the driver is gonna work. This > is mainly about the behavior expected by the entity which initiated > module loading not about specific drivers. Why would you say that? In my particular userspace we do not have modules. > I'm fairly certain that > there are userland scripts which depend on synchronous device probing > on module loading, especially for storage devices, so we can't simply > mark, say, libata as needing async probing and do it always > asynchronously. Right. But for many devices (input ones for example, USB as well, etc) that are essentially hot-pluggable userspace has been long ready to handle async order. Thanks. -- Dmitry -- 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/
Re: [RFC v1 0/3] driver-core: add asynch module loading support
On 8/31/2014 3:45 PM, Dmitry Torokhov wrote: On August 31, 2014 3:32:19 PM PDT, Arjan van de Ven wrote: On 8/31/2014 1:06 PM, 吴章金 wrote: Hi, folks I'm back to this discussion, The original requirement of my first RFC patchset is mainly for Android Smartphone use case: 1. We want light on LCD and draw a logo immediately after power key press(don't consider uboot or lk biotloader here). 2. We want the whole kernel boot fast to give user the Android Launch deaktop 3. The modem initialization/reset is slow 4. The Touchpad firmware upgrade is slow 5. We have many cpu cores(up to 8 in latest exynos 5430 and MT6595...) 6. We have few schedulable/parallellizable threads 7. We compiled all of the modules in the kernel(stupid? avoid modprobe...but lose parallelization in userspace) So, I think about is that possible to async most of the probes, but still reserve the requred dependencies to let them still work as expected. you can boot a whole kernel including all graphics in less than 0.5 seconds, even without this patchset. You forgot to add "on certain subset of hardware and configuration". certainly. for hardware that takes longer than 0.5s you certainly won't get that. asynchronous/parallel init helps, but it is not a miracle. Most devices I've worked on (wide range of hardware from PC to tablets to phones) there tend to be 4 to 5 big guys and a long tail of negliable ones. the big guys tend to be, even after going in parallel, so large that people who wanted instant boot have to accept that more miracles are needed. Like actual work in the driver or device firmware to split work up, rather than an "from the outside" make it asynchronous. -- 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/
