Re: [PATCH 1/3] PM / OPP: Add support for descending order for cpufreq table
On 3 May 2014 05:46, Jonghwan Choi wrote: > Hi. Viresh Kumar > Your reply is so fast like Usain Bolt. Heh, that's not true.. See how slow I was this time :) >> So, create three flags: >> OPP_TABLE_ORDER_ASCENDING 0 >> OPP_TABLE_ORDER_DESCENDING1 >> OPP_TABLE_ORDER_ORIGINAL 2 (And use this for your case.) > > -> Actually, I want to use OPP_TABLE_ORDER_DESCENDING.(Not > OPP_TABLE_ORDER_ORIGINAL.) > I think that it is enough to support both descending and ascending ordering > only. > The meaning of "ORIGIANL" Amit, said, when he(and I) writes a frequency in > dts file with ordering(Ascending or Descending). He(and I) want the > frequency to be register according to ordering.(Ascending or Descending). But what if somebody doesn't have a ascending or descending list there? And want to preserve the original list? That's why I recommended it. > I concerned that if we use ORIGINAL ordering, opp_find_freq_ceil/foor can be > broken. I completely missed that earlier :) .. It would be broken with descending one as well.. To skip the complexity of finding right freq associated with "ORIGINAL" ordering, lets concentrate on Ascending/Descending ordering for now. So, this is what I would recommend now: - Create two macros: OPP_TABLE_ORDER_ASCENDING and OPP_TABLE_ORDER_DESCENDING - create of_init_opp_table_ordered(**, int order), order would be one of the above two macros - rename dev_pm_opp_add to __dev_pm_opp_add() and create a wrapper over it: dev_pm_opp_add(), which would pass OPP_TABLE_ORDER_ASCENDING to it by default and call it from of_init_opp_table_ordered() like this: __dev_pm_opp_add(***, order).. - Fix ceil/floor routines for these two cases. -- viresh -- 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 (for 3.15) 0/5] Fix cross rename race window for LSM.
Hello SELinux people, may I have your response?
Miklos Szeredi posted v3 of cross rename patchset at
http://marc.info/?l=linux-fsdevel=138921924707564=4 . In that thread,
I questioned him whether he already explained this proposal to LSM people.
He answered no and explained me what renameat2() does. I asked him to get
confirmation from LSM people before he merges this change to linux-next.git
tree, and he answered that patch 07/11 already does what LSM people need. But
I commented that TOMOYO wants to avoid re-calculation of pathnames and posted
a patch at http://marc.info/?l=linux-security-module=138970469226106=4 and
John Johansen commented that the changes in AppArmor directory looks OK and
John would re-factor AppArmor to avoid re-calculation in the future. Therefore,
I posted a patch for SELinux/SMACK/Capability at
http://marc.info/?l=linux-fsdevel=138973289404450=4 but Miklos responded
that he doesn't want to include my patch which temporarily breaks TOMOYO and
AppArmor. Instead, he asked me to post a complete patch right after his cross
rename patchset goes in. Thus, I was waiting for his cross rename patchset to
arrive at linux-next.git tree.
By the day Linux 3.14 was released, Miklos's cross rename patchset did not
arrive at linux-next.git tree. Therefore, I assumed that the cross rename
patchset will not go to Linux 3.15-rc1. However, the patchset committed after
Linux 3.14 release (commit da1ce067 "vfs: add cross-rename") directly went to
linux.git tree without letting it known to LSM people and the merge window for
Linux 3.15 was closed. Then, I noticed that renameat2() will be in 3.15 at
http://marc.info/?l=linux-fsdevel=139789855823422=2 .
At first, I assumed that renameat2() is not callable as of 3.15 because I
couldn't find "#define __NR_renameat2" line. But Miklos told me that
renameat2() will be callable as of 3.15 because x86 automatically generates
__NR_renameat2 entries. I realized that TOMOYO and AppArmor now have a race
window (a kind of regression) introduced by the cross rename functionality, and
I re-posted my patch as a patchset in this thread. I can approve the changes in
TOMOYO directory and John Johansen already gave me a sort of Reviewed-by:
response to the changes in AppArmor directory in January's thread. In this
thread, Casey Schaufler gave me an Acked-by: response to the changes in SMACK
directory, but so far I have gotten no response from SELinux people.
Would somebody in SELinux community please respond to the changes in SELinux
directory so that we can merge this race window fix patchset before 3.15-final?
Regards.
Tetsuo Handa wrote:
> James, would you send this patchset to Linus?
> This patchset is expected to go to 3.15 because this is a kind of regression
> fix.
>
> Tetsuo Handa wrote:
> > Miklos Szeredi wrote:
> > > On Sat, Apr 19, 2014 at 2:08 PM, Tetsuo Handa
> > > wrote:
> > > > Michael Kerrisk (man-pages) wrote:
> > > >> Now that renameat2() is in 3.15, I've taken these changes.
> > > >
> > > > What!? I didn't know renameat2() goes to 3.15.
> > > >
> > > > But I assume that renameat2() is not accessible in 3.15, for I can see
> > > > "asmlinkage long sys_renameat2(" but don't see "#define __NR_renameat2".
> > >
> > > x86 automatically generates __NR_foo entries and syscall tables from
> > > arch/x86/syscalls/syscall_*.tbl, which is why you don't find an
> > > explicit definition in the git tree.
> > >
> > > Thanks,
> > > Miklos
> > >
> >
> > Oh, I see. Then, I must submit patches for fixing a race window
> > caused by commit da1ce067 "vfs: add cross-rename".
> >
> > Regards.
> >
>
--
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-next: manual merge of the tty tree with Linus' tree
Hi Greg,
Today's linux-next merge of the tty tree got a conflict in
arch/arm64/kernel/early_printk.c between commit f774b7d10e21 ("arm64:
fixmap: fix missing sub-page offset for earlyprintk") from the tree and
commit 8ef0ed95ee04 ("arm64: remove arch specific earlyprintk") from the
tty tree.
I fixed it up (I removed the file) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp4S5Zs_EXME.pgp
Description: PGP signature
[PATCH] MAINTAINERS: add an entry for all the NCR5380 drivers
Signed-off-by: Finn Thain Cc: Michael Schmitz --- As requested: http://marc.info/?l=linux-arm-kernel=139853302724112=2 diff --git a/MAINTAINERS b/MAINTAINERS index e67ea24..60ea600 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5996,6 +5996,28 @@ M: Petr Vandrovec S: Odd Fixes F: fs/ncpfs/ +NCR 5380 SCSI DRIVERS +M: Finn Thain +M: Michael Schmitz +L: linux-s...@vger.kernel.org +S: Maintained +F: Documentation/scsi/g_NCR5380.txt +F: drivers/scsi/NCR5380.* +F: drivers/scsi/arm/cumana_1.c +F: drivers/scsi/arm/oak.c +F: drivers/scsi/atari_NCR5380.c +F: drivers/scsi/atari_scsi.* +F: drivers/scsi/dmx3191d.c +F: drivers/scsi/dtc.* +F: drivers/scsi/g_NCR5380.* +F: drivers/scsi/g_NCR5380_mmio.c +F: drivers/scsi/mac_scsi.* +F: drivers/scsi/pas16.* +F: drivers/scsi/sun3_NCR5380.c +F: drivers/scsi/sun3_scsi.* +F: drivers/scsi/sun3_scsi_vme.c +F: drivers/scsi/t128.* + NCR DUAL 700 SCSI DRIVER (MICROCHANNEL) M: "James E.J. Bottomley" L: linux-s...@vger.kernel.org -- 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 v3 5/7] ARM: berlin: add the pinctrl dependency for the Marvell Berlin SoCs
Signed-off-by: Antoine Ténart Acked-by: Sebastian Hesselbarth --- arch/arm/mach-berlin/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig index d3c5f14dc142..9c2b569e54ba 100644 --- a/arch/arm/mach-berlin/Kconfig +++ b/arch/arm/mach-berlin/Kconfig @@ -4,6 +4,7 @@ config ARCH_BERLIN select GENERIC_IRQ_CHIP select DW_APB_ICTL select DW_APB_TIMER_OF + select PINCTRL if ARCH_BERLIN @@ -14,11 +15,13 @@ config MACH_BERLIN_BG2 select CACHE_L2X0 select CPU_PJ4B select HAVE_ARM_TWD if SMP + select PINCTRL_BERLIN_BG2 config MACH_BERLIN_BG2CD bool "Marvell Armada 1500-mini (BG2CD)" select CACHE_L2X0 select HAVE_ARM_TWD if SMP + select PINCTRL_BERLIN_BG2CD config MACH_BERLIN_BG2Q bool "Marvell Armada 1500 Pro (BG2-Q)" @@ -26,6 +29,7 @@ config MACH_BERLIN_BG2Q select CPU_V7 select HAVE_ARM_TWD if SMP select HAVE_SMP + select PINCTRL_BERLIN_BG2Q endmenu -- 1.8.3.2 -- 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 v3 1/7] pinctrl: berlin: add the core pinctrl driver for Marvell Berlin SoCs
The Marvell Berlin boards have a group based pinmuxing mechanism. This
adds the core driver support. We actually do not need any information
about the pins here and only have the definition of the groups.
Let's take the example of the uart0 pinmuxing on the BG2Q. Balls BK4 and
BH6 are muxed to respectively UART0 RX and TX if the group GSM12 is set
to mode 0:
Group Modes Offset Base Offset LSB Bit Width
GSM12 3 sm_base 0x400x100x2
BallGroup Mode 0 Mode 1 Mode 2
BK4 GSM12 UART0_RXIrDA0_RXGPIO9
BH6 GSM12 UART0_TXIrDA0_TXGPIO10
So in order to configure BK4 -> UART0_TX and BH6 -> UART0_RX, we need
to set (sm_base + 0x40 + 0x10) &= ff3f.
Signed-off-by: Antoine Ténart
Acked-by: Sebastian Hesselbarth
---
drivers/pinctrl/Kconfig | 1 +
drivers/pinctrl/Makefile| 1 +
drivers/pinctrl/berlin/Kconfig | 7 +
drivers/pinctrl/berlin/Makefile | 1 +
drivers/pinctrl/berlin/berlin.c | 346
drivers/pinctrl/berlin/berlin.h | 71 +
6 files changed, 427 insertions(+)
create mode 100644 drivers/pinctrl/berlin/Kconfig
create mode 100644 drivers/pinctrl/berlin/Makefile
create mode 100644 drivers/pinctrl/berlin/berlin.c
create mode 100644 drivers/pinctrl/berlin/berlin.h
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index e00c02d0a094..f758fa43ab92 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -368,6 +368,7 @@ config PINCTRL_S3C64XX
depends on ARCH_S3C64XX
select PINCTRL_SAMSUNG
+source "drivers/pinctrl/berlin/Kconfig"
source "drivers/pinctrl/mvebu/Kconfig"
source "drivers/pinctrl/sh-pfc/Kconfig"
source "drivers/pinctrl/spear/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 6d3fd62b9ae8..0bd6dcb5baf9 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_PINCTRL_TB10X) += pinctrl-tb10x.o
obj-$(CONFIG_PINCTRL_ST) += pinctrl-st.o
obj-$(CONFIG_PINCTRL_VF610)+= pinctrl-vf610.o
+obj-$(CONFIG_ARCH_BERLIN) += berlin/
obj-$(CONFIG_PLAT_ORION)+= mvebu/
obj-$(CONFIG_ARCH_SHMOBILE)+= sh-pfc/
obj-$(CONFIG_SUPERH) += sh-pfc/
diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
new file mode 100644
index ..df843e01a001
--- /dev/null
+++ b/drivers/pinctrl/berlin/Kconfig
@@ -0,0 +1,7 @@
+if ARCH_BERLIN
+
+config PINCTRL_BERLIN
+ bool
+ select PINMUX
+
+endif
diff --git a/drivers/pinctrl/berlin/Makefile b/drivers/pinctrl/berlin/Makefile
new file mode 100644
index ..251a2b4e1057
--- /dev/null
+++ b/drivers/pinctrl/berlin/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PINCTRL_BERLIN) += berlin.o
diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c
new file mode 100644
index ..20c1374d11f0
--- /dev/null
+++ b/drivers/pinctrl/berlin/berlin.c
@@ -0,0 +1,346 @@
+/*
+ * Marvell Berlin SoC pinctrl core driver
+ *
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Ténart
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../core.h"
+#include "../pinctrl-utils.h"
+#include "berlin.h"
+
+static int berlin_pinctrl_get_group_count(struct pinctrl_dev *pctrl_dev)
+{
+ struct berlin_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrl_dev);
+
+ return pctrl->desc->ngroups;
+}
+
+static const char *berlin_pinctrl_get_group_name(struct pinctrl_dev *pctrl_dev,
+unsigned group)
+{
+ struct berlin_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrl_dev);
+
+ return pctrl->desc->groups[group].name;
+}
+
+static int berlin_pinctrl_dt_node_to_map(struct pinctrl_dev *pctrl_dev,
+struct device_node *node,
+struct pinctrl_map **map,
+unsigned *num_maps)
+{
+ struct berlin_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrl_dev);
+ struct property *prop;
+ const char *function_name, *group_name;
+ unsigned reserved_maps = 0;
+ int ret, ngroups;
+
+ *map = NULL;
+ *num_maps = 0;
+
+ ret = of_property_read_string(node, "marvell,function", _name);
+ if (ret) {
+ dev_err(pctrl->dev,
+ "missing 'marvell,function' property in node %s\n",
+ node->name);
+ return -EINVAL;
+ }
+
+ ngroups = of_property_count_strings(node, "marvell,groups");
+ if (ngroups < 0) {
+ dev_err(pctrl->dev,
+
[PATCH v3 2/7] pinctrl: berlin: add the BG2Q pinctrl driver
Add the pin-controller driver for the Berlin BG2Q SoC, with definition
of its groups and functions. This uses the core Berlin pinctrl driver.
Signed-off-by: Antoine Ténart
Acked-by: Sebastian Hesselbarth
---
drivers/pinctrl/berlin/Kconfig | 4 +
drivers/pinctrl/berlin/Makefile | 1 +
drivers/pinctrl/berlin/berlin-bg2q.c | 413 +++
3 files changed, 418 insertions(+)
create mode 100644 drivers/pinctrl/berlin/berlin-bg2q.c
diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
index df843e01a001..58ecfd797dd8 100644
--- a/drivers/pinctrl/berlin/Kconfig
+++ b/drivers/pinctrl/berlin/Kconfig
@@ -4,4 +4,8 @@ config PINCTRL_BERLIN
bool
select PINMUX
+config PINCTRL_BERLIN_BG2Q
+ bool
+ select PINCTRL_BERLIN
+
endif
diff --git a/drivers/pinctrl/berlin/Makefile b/drivers/pinctrl/berlin/Makefile
index 251a2b4e1057..1866b1f2d1cf 100644
--- a/drivers/pinctrl/berlin/Makefile
+++ b/drivers/pinctrl/berlin/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_PINCTRL_BERLIN) += berlin.o
+obj-$(CONFIG_PINCTRL_BERLIN_BG2Q) += berlin-bg2q.o
diff --git a/drivers/pinctrl/berlin/berlin-bg2q.c
b/drivers/pinctrl/berlin/berlin-bg2q.c
new file mode 100644
index ..4a997732f191
--- /dev/null
+++ b/drivers/pinctrl/berlin/berlin-bg2q.c
@@ -0,0 +1,413 @@
+/*
+ * Marvell Berlin BG2Q pinctrl driver
+ *
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Ténart
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+
+#include "berlin.h"
+
+static const struct berlin_desc_group berlin2q_soc_pinctrl_groups[] = {
+ /* G */
+ BERLIN_PINCTRL_GROUP("G0", 0x18, 0x3, 0x00,
+ BERLIN_PINCTRL_FUNCTION(0x0, "nand"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "mmc"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "gpio")),
+ BERLIN_PINCTRL_GROUP("G1", 0x18, 0x3, 0x03,
+ BERLIN_PINCTRL_FUNCTION(0x0, "nand"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "gpio")),
+ BERLIN_PINCTRL_GROUP("G2", 0x18, 0x3, 0x06,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "arc"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "lvds")),
+ BERLIN_PINCTRL_GROUP("G3", 0x18, 0x3, 0x09,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "i2s2"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "lvds")),
+ BERLIN_PINCTRL_GROUP("G4", 0x18, 0x3, 0x0c,
+ BERLIN_PINCTRL_FUNCTION(0x0, "pll"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sd0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "rgmii"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x5, "sata_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x6, "usb0_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x7, "usb1_dbg")),
+ BERLIN_PINCTRL_GROUP("G5", 0x18, 0x3, 0x0f,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sd0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "rgmii"),
+ BERLIN_PINCTRL_FUNCTION(0x5, "sata_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x6, "usb0_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x7, "usb1_dbg")),
+ BERLIN_PINCTRL_GROUP("G6", 0x18, 0x3, 0x12,
+ BERLIN_PINCTRL_FUNCTION(0x0, "jtag"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "twsi0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "gpio")),
+ BERLIN_PINCTRL_GROUP("G7", 0x18, 0x3, 0x15,
+ BERLIN_PINCTRL_FUNCTION(0x0, "jtag"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "twsi1"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "eddc")),
+ BERLIN_PINCTRL_GROUP("G8", 0x18, 0x3, 0x18,
+ BERLIN_PINCTRL_FUNCTION(0x0, "spi1"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "gpio")),
+ BERLIN_PINCTRL_GROUP("G9", 0x18, 0x3, 0x1b,
+ BERLIN_PINCTRL_FUNCTION(0x0, "spi1"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x5, "sata")),
+ BERLIN_PINCTRL_GROUP("G10", 0x1c, 0x3, 0x00,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "spi1"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "i2s0"),
+ BERLIN_PINCTRL_FUNCTION(0x4, "pwm"),
+ BERLIN_PINCTRL_FUNCTION(0x5, "sata")),
+
[PATCH v3 3/7] pinctrl: berlin: add the BG2 pinctrl driver
Add the pin-controller driver for the Berlin BG2 SoC, with definition
of its groups and functions. This uses the core Berlin pinctrl driver.
Signed-off-by: Antoine Ténart
Acked-by: Sebastian Hesselbarth
---
drivers/pinctrl/berlin/Kconfig | 4 +
drivers/pinctrl/berlin/Makefile | 1 +
drivers/pinctrl/berlin/berlin-bg2.c | 251
3 files changed, 256 insertions(+)
create mode 100644 drivers/pinctrl/berlin/berlin-bg2.c
diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
index 58ecfd797dd8..1b34943bef1c 100644
--- a/drivers/pinctrl/berlin/Kconfig
+++ b/drivers/pinctrl/berlin/Kconfig
@@ -4,6 +4,10 @@ config PINCTRL_BERLIN
bool
select PINMUX
+config PINCTRL_BERLIN_BG2
+ bool
+ select PINCTRL_BERLIN
+
config PINCTRL_BERLIN_BG2Q
bool
select PINCTRL_BERLIN
diff --git a/drivers/pinctrl/berlin/Makefile b/drivers/pinctrl/berlin/Makefile
index 1866b1f2d1cf..e37e4e7a8838 100644
--- a/drivers/pinctrl/berlin/Makefile
+++ b/drivers/pinctrl/berlin/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_PINCTRL_BERLIN) += berlin.o
+obj-$(CONFIG_PINCTRL_BERLIN_BG2) += berlin-bg2.o
obj-$(CONFIG_PINCTRL_BERLIN_BG2Q) += berlin-bg2q.o
diff --git a/drivers/pinctrl/berlin/berlin-bg2.c
b/drivers/pinctrl/berlin/berlin-bg2.c
new file mode 100644
index ..edbe409b2454
--- /dev/null
+++ b/drivers/pinctrl/berlin/berlin-bg2.c
@@ -0,0 +1,251 @@
+/*
+ * Marvell Berlin BG2 pinctrl driver.
+ *
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Ténart
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+
+#include "berlin.h"
+
+static const struct berlin_desc_group berlin2_soc_pinctrl_groups[] = {
+ /* G */
+ BERLIN_PINCTRL_GROUP("G0", 0x00, 0x1, 0x00,
+ BERLIN_PINCTRL_FUNCTION(0x0, "spi1"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "gpio")),
+ BERLIN_PINCTRL_GROUP("G1", 0x00, 0x2, 0x01,
+ BERLIN_PINCTRL_FUNCTION(0x0, "spi1"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "usb1")),
+ BERLIN_PINCTRL_GROUP("G2", 0x00, 0x2, 0x02,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "spi1"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "i2s0")),
+ BERLIN_PINCTRL_GROUP("G3", 0x00, 0x2, 0x04,
+ BERLIN_PINCTRL_FUNCTION(0x0, "soc"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "spi1"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "i2s1")),
+ BERLIN_PINCTRL_GROUP("G4", 0x00, 0x2, 0x06,
+ BERLIN_PINCTRL_FUNCTION(0x0, "spi1"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm")),
+ BERLIN_PINCTRL_GROUP("G5", 0x00, 0x3, 0x08,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sts1"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "et"),
+ /*
+* Mode 0x3 mux i2s2 mclk *and* i2s3 mclk:
+* add two functions so it can be used with other groups
+* within the same subnode in the device tree
+*/
+ BERLIN_PINCTRL_FUNCTION(0x3, "i2s2"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "i2s3")),
+ BERLIN_PINCTRL_GROUP("G6", 0x00, 0x2, 0x0b,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sts0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "et")),
+ BERLIN_PINCTRL_GROUP("G7", 0x00, 0x3, 0x0d,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sts0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "et"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "vdac")),
+ BERLIN_PINCTRL_GROUP("G8", 0x00, 0x3, 0x10,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sd0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "et"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "usb0_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x4, "sata_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x7, "usb1_dbg")),
+ BERLIN_PINCTRL_GROUP("G9", 0x00, 0x3, 0x13,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sd0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "et"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "usb0_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x4, "sata_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x7, "usb1_dbg")),
+ BERLIN_PINCTRL_GROUP("G10", 0x00, 0x2, 0x16,
+ BERLIN_PINCTRL_FUNCTION(0x0, "soc"),
+
[PATCH v3 6/7] Documentation: add the Marvell Berlin pinctrl documentation
Add the documentation related to the Berlin pin-controller driver and
explain how to configure this group based controller.
Signed-off-by: Antoine Ténart
Acked-by: Sebastian Hesselbarth
---
.../bindings/pinctrl/marvell,berlin-pinctrl.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
diff --git
a/Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
new file mode 100644
index ..4ca92ab2c1de
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
@@ -0,0 +1,45 @@
+* Pin-controller driver for the Marvell Berlin SoCs
+
+The pins controlled by the Marvell Berlin controller are organized in groups.
+Configuration is done by group, so no actual pin information is needed.
+
+Be aware the Marvell Berlin datasheets use the keyword 'mode' for what is
called
+a 'function' in the pin-controller subsystem.
+
+Required properties:
+- compatible: should be one of:
+ "marvell,berlin2-soc-pinctrl",
+ "marvell,berlin2-sysmgr-pinctrl",
+ "marvell,berlin2cd-soc-pinctrl",
+ "marvell,berlin2cd-sysmgr-pinctrl",
+ "marvell,berlin2q-soc-pinctrl",
+ "marvell,berlin2q-sysmgr-pinctrl"
+- reg: registers physical address and length of the pin controller.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pin-controller bindings used by client devices.
+
+A pin-controller node should contain subnodes representing the pin group
+configurations, one per function. Each subnode has the group name and the
muxing
+function used.
+
+Required subnode-properties:
+- marvell,groups: a list of strings describing the group names.
+- marvell,function: a string describing the function used to mux the groups.
+
+Example:
+
+sm_pinctrl: pin-controller@0 {
+ compatible = "marvell,berlin2q-sysmgr-pinctrl";
+ reg = <0xfc 0x44>;
+
+ uart0_pmux: uart0-pmux {
+ marvell,groups = "GSM12", "GSM13";
+ marvell,function = "uart0";
+ };
+}
+
+ {
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
+};
--
1.8.3.2
--
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 v3 0/7] ARM: berlin: add pinctrl support
This series adds support for the Marvell Berlin pin-controller, allowing to configure the pin muxing from the device tree. The Berlin pin-controller support is divided into 3 drivers, each driving one Berlin SoC. These drivers use a Berlin common part. This series applies on top of patches introducing the Marvell Berlin BG2Q you can find on Sebastian's berlin/for-next branch[1] and the patch allowing not to define the get_group_pins() function[2]. Tested on the Berlin BG2Q. [1] https://github.com/shesselba/linux-berlin/commits/berlin/for-next [2] https://patchwork.kernel.org/patch/3964491/ Changes since v2: - added the uart2 pin muxing node for BG2 - cosmetic fixes Changes since v1: - moved the driver to a specific berlin/ directory - divided the pin-controller driver into three (one per SoC) and reworked the driver dependencies accordingly - reworked the device tree bindings - removed the reg-names and reworked the driver to allow splitting the two pin-controllers into two separate nodes in the device tree - updated the documentation - removed unnecessary checks - added support to mux multiple groups with the same function - added BG2, BG2 and BG2CD function definitions Antoine Ténart (7): pinctrl: berlin: add the core pinctrl driver for Marvell Berlin SoCs pinctrl: berlin: add the BG2Q pinctrl driver pinctrl: berlin: add the BG2 pinctrl driver pinctrl: berlin: add the BG2CD pinctrl driver ARM: berlin: add the pinctrl dependency for the Marvell Berlin SoCs Documentation: add the Marvell Berlin pinctrl documentation ARM: dts: berlin: add the pinctrl node and muxing setup for uarts .../bindings/pinctrl/marvell,berlin-pinctrl.txt| 45 +++ arch/arm/boot/dts/berlin2.dtsi | 31 ++ arch/arm/boot/dts/berlin2cd.dtsi | 17 + arch/arm/boot/dts/berlin2q.dtsi| 24 ++ arch/arm/mach-berlin/Kconfig | 4 + drivers/pinctrl/Kconfig| 1 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/berlin/Kconfig | 19 + drivers/pinctrl/berlin/Makefile| 4 + drivers/pinctrl/berlin/berlin-bg2.c| 251 + drivers/pinctrl/berlin/berlin-bg2cd.c | 194 ++ drivers/pinctrl/berlin/berlin-bg2q.c | 413 + drivers/pinctrl/berlin/berlin.c| 346 + drivers/pinctrl/berlin/berlin.h| 71 14 files changed, 1421 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt create mode 100644 drivers/pinctrl/berlin/Kconfig create mode 100644 drivers/pinctrl/berlin/Makefile create mode 100644 drivers/pinctrl/berlin/berlin-bg2.c create mode 100644 drivers/pinctrl/berlin/berlin-bg2cd.c create mode 100644 drivers/pinctrl/berlin/berlin-bg2q.c create mode 100644 drivers/pinctrl/berlin/berlin.c create mode 100644 drivers/pinctrl/berlin/berlin.h -- 1.8.3.2 -- 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 v3 4/7] pinctrl: berlin: add the BG2CD pinctrl driver
Add the pin-controller driver for the Berlin BG2CD SoC, with definition
of its groups and functions. This uses the core Berlin pinctrl driver.
Signed-off-by: Antoine Ténart
Acked-by: Sebastian Hesselbarth
---
drivers/pinctrl/berlin/Kconfig| 4 +
drivers/pinctrl/berlin/Makefile | 1 +
drivers/pinctrl/berlin/berlin-bg2cd.c | 194 ++
3 files changed, 199 insertions(+)
create mode 100644 drivers/pinctrl/berlin/berlin-bg2cd.c
diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
index 1b34943bef1c..b2cee6f71ccd 100644
--- a/drivers/pinctrl/berlin/Kconfig
+++ b/drivers/pinctrl/berlin/Kconfig
@@ -8,6 +8,10 @@ config PINCTRL_BERLIN_BG2
bool
select PINCTRL_BERLIN
+config PINCTRL_BERLIN_BG2CD
+ bool
+ select PINCTRL_BERLIN
+
config PINCTRL_BERLIN_BG2Q
bool
select PINCTRL_BERLIN
diff --git a/drivers/pinctrl/berlin/Makefile b/drivers/pinctrl/berlin/Makefile
index e37e4e7a8838..deb0c6baf316 100644
--- a/drivers/pinctrl/berlin/Makefile
+++ b/drivers/pinctrl/berlin/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_PINCTRL_BERLIN) += berlin.o
obj-$(CONFIG_PINCTRL_BERLIN_BG2) += berlin-bg2.o
+obj-$(CONFIG_PINCTRL_BERLIN_BG2CD) += berlin-bg2cd.o
obj-$(CONFIG_PINCTRL_BERLIN_BG2Q) += berlin-bg2q.o
diff --git a/drivers/pinctrl/berlin/berlin-bg2cd.c
b/drivers/pinctrl/berlin/berlin-bg2cd.c
new file mode 100644
index ..9613b6a8134b
--- /dev/null
+++ b/drivers/pinctrl/berlin/berlin-bg2cd.c
@@ -0,0 +1,194 @@
+/*
+ * Marvell Berlin BG2CD pinctrl driver.
+ *
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Ténart
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+
+#include "berlin.h"
+
+static const struct berlin_desc_group berlin2cd_soc_pinctrl_groups[] = {
+ /* G */
+ BERLIN_PINCTRL_GROUP("G0", 0x00, 0x1, 0x00,
+ BERLIN_PINCTRL_FUNCTION(0x0, "jtag"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "led"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "pwm")),
+ BERLIN_PINCTRL_GROUP("G1", 0x00, 0x2, 0x01,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sd0"),
+ BERLIN_PINCTRL_FUNCTION(0x6, "usb0_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x7, "usb1_dbg")),
+ BERLIN_PINCTRL_GROUP("G2", 0x00, 0x2, 0x02,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sd0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "fe"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "pll"),
+ BERLIN_PINCTRL_FUNCTION(0x6, "usb0_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x7, "usb1_dbg")),
+ BERLIN_PINCTRL_GROUP("G3", 0x00, 0x2, 0x04,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sd0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "twsi2"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "pll"),
+ BERLIN_PINCTRL_FUNCTION(0x4, "fe"),
+ BERLIN_PINCTRL_FUNCTION(0x6, "usb0_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x7, "usb1_dbg")),
+ BERLIN_PINCTRL_GROUP("G4", 0x00, 0x2, 0x06,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sd0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "twsi3"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "pll"),
+ BERLIN_PINCTRL_FUNCTION(0x4, "pwm"),
+ BERLIN_PINCTRL_FUNCTION(0x6, "usb0_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x7, "usb1_dbg")),
+ BERLIN_PINCTRL_GROUP("G5", 0x00, 0x3, 0x08,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "sd0"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "twsi3"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "arc"),
+ BERLIN_PINCTRL_FUNCTION(0x4, "pwm"),
+ BERLIN_PINCTRL_FUNCTION(0x6, "usb0_dbg"),
+ BERLIN_PINCTRL_FUNCTION(0x7, "usb1_dbg")),
+ BERLIN_PINCTRL_GROUP("G6", 0x00, 0x2, 0x0b,
+ BERLIN_PINCTRL_FUNCTION(0x0, "uart0"), /* RX/TX */
+ BERLIN_PINCTRL_FUNCTION(0x1, "gpio")),
+ BERLIN_PINCTRL_GROUP("G7", 0x00, 0x3, 0x0d,
+ BERLIN_PINCTRL_FUNCTION(0x0, "eddc"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "twsi1"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "gpio")),
+ BERLIN_PINCTRL_GROUP("G8", 0x00, 0x3, 0x10,
+ BERLIN_PINCTRL_FUNCTION(0x0, "ss0"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "gpio")),
+ BERLIN_PINCTRL_GROUP("G9", 0x00, 0x3, 0x13,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"),
+ BERLIN_PINCTRL_FUNCTION(0x1, "spi1"),
+
[PATCH v3 7/7] ARM: dts: berlin: add the pinctrl node and muxing setup for uarts
The uart0 pinmux configuration is in the dtsi because uart0 will always
use uart0-pmux to work, no other possibility. Same thing for uart1 and
uart2 (BG2).
Signed-off-by: Antoine Ténart
Acked-by: Sebastian Hesselbarth
---
arch/arm/boot/dts/berlin2.dtsi | 31 +++
arch/arm/boot/dts/berlin2cd.dtsi | 17 +
arch/arm/boot/dts/berlin2q.dtsi | 24
3 files changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 56a1af2f1052..fb58f43eab52 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -176,6 +176,11 @@
};
};
+ soc_pinctrl: pin-controller@ea {
+ compatible = "marvell,berlin2-soc-pinctrl";
+ reg = <0xea 0x4c>;
+ };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -184,6 +189,26 @@
ranges = <0 0xfc 0x1>;
interrupt-parent = <>;
+ sm_pinctrl: pin-controller@ {
+ compatible = "marvell,berlin2-sysmgr-pinctrl";
+ reg = <0x 0x44>;
+
+ uart0_pmux: uart0-pmux {
+ marvell,groups = "GSM4";
+ marvell,function = "uart0";
+ };
+
+ uart1_pmux: uart1-pmux {
+ marvell,groups = "GSM5";
+ marvell,function = "uart1";
+ };
+
+ uart2_pmux: uart2-pmux {
+ marvell,groups = "GSM3";
+ marvell,function = "uart2";
+ };
+ };
+
uart0: serial@9000 {
compatible = "snps,dw-apb-uart";
reg = <0x9000 0x100>;
@@ -191,6 +216,8 @@
reg-io-width = <1>;
interrupts = <8>;
clocks = <>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
@@ -201,6 +228,8 @@
reg-io-width = <1>;
interrupts = <9>;
clocks = <>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
@@ -211,6 +240,8 @@
reg-io-width = <1>;
interrupts = <10>;
clocks = <>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 094968c27533..a802d3fe5da6 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -169,6 +169,11 @@
};
};
+ soc_pinctrl: pin-controller@ae {
+ compatible = "marvell,berlin2cd-soc-pinctrl";
+ reg = <0xea 0x4c>;
+ };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -177,6 +182,16 @@
ranges = <0 0xfc 0x1>;
interrupt-parent = <>;
+ sm_pinctrl: pin-controller@ {
+ compatible = "marvell,berlin2cd-sysmgr-pinctrl";
+ reg = <0x 0x44>;
+
+ uart0_pmux: uart0-pmux {
+ marvell,groups = "G6";
+ marvell,function = "uart0";
+ };
+ };
+
uart0: serial@9000 {
compatible = "snps,dw-apb-uart";
reg = <0x9000 0x100>;
@@ -184,6 +199,8 @@
reg-io-width = <1>;
interrupts = <8>;
clocks = <>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
diff --git
[PATCH] powerpc: Fix comment around arch specific definition of RECLAIM_DISTANCE
Commit 32e45ff43eaf5c17f changed the default value of RECLAIM_DISTANCE to 30. However the comment around arch specifc definition of RECLAIM_DISTANCE is not updated to reflect the same. Correct the value mentioned in the comment. Signed-off-by: Preeti U Murthy Cc: Anton Blanchard Cc: Benjamin Herrenschmidt Cc: KOSAKI Motohiro --- arch/powerpc/include/asm/topology.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h index c920215..356546d 100644 --- a/arch/powerpc/include/asm/topology.h +++ b/arch/powerpc/include/asm/topology.h @@ -12,7 +12,7 @@ struct device_node; * Before going off node we want the VM to try and reclaim from the local * node. It does this if the remote distance is larger than RECLAIM_DISTANCE. * With the default REMOTE_DISTANCE of 20 and the default RECLAIM_DISTANCE of - * 20, we never reclaim and go off node straight away. + * 30, we never reclaim and go off node straight away. * * To fix this we choose a smaller value of RECLAIM_DISTANCE. */ -- 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 1/2] introduce variable acpi_lapic into ia64
Hi Rafael,
Thanks for previous comments and suggestions.
I added the acpi_lapic in ia64. However I didn't find ia64 machine to
test it. Could you or anyone please help test this 2 patches?
I don't know how to test UP system running SMP kernel with no LAPIC in
MADT when it's ia64 arch.
Test steps for ia64 kdump:
1) get a multi-cpus ia64 machine, build a upstream kernel with SMP and
ACPI
2)install kexec-tools, and edit /etc/sysconfig/kdump to make sure
"nr_cpus=1" is in KDUMP_COMMANDLINE_APPEND. Then load the kdump kernel
by below command:
"kdumpctl restart" or "systemctl restart kdump"
3) After kdump kernel loaded, execute below shell command. This can make
crash happen in 2nd cpu.
taskset -c 1 sh -c "echo c >/proc/sysrq-trigger"
4) From console, below error message should not be printed any more. And
the cpu related to 2nd lapid is present, this can be checked by console
message and adding debugging code.
"acpi LNXCPU:0a: BIOS reported wrong ACPI id 0 for the processor."
For x86_64, the UP test is taken by adding "disableapic nr_cpus=1" into
cmdline of grub. The test for kdump is the same as above ia64.
Thanks
Baoquan
On 05/05/14 at 12:48pm, Baoquan He wrote:
> This variable was defined and assigned in x86, is used to indicate
> whether LAPIC exists in MADT. Now introduce it into ia64 to help
> make correct judgment when get information for acpi processor later.
>
> Signed-off-by: Baoquan He
> ---
> arch/ia64/include/asm/acpi.h | 1 +
> arch/ia64/kernel/acpi.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
> index d651102..b478219 100644
> --- a/arch/ia64/include/asm/acpi.h
> +++ b/arch/ia64/include/asm/acpi.h
> @@ -85,6 +85,7 @@ ia64_acpi_release_global_lock (unsigned int *lock)
> ((Acq) = ia64_acpi_release_global_lock(>global_lock))
>
> #ifdef CONFIG_ACPI
> +extern int acpi_lapic;
> #define acpi_disabled 0 /* ACPI always enabled on IA64 */
> #define acpi_noirq 0 /* ACPI always enabled on IA64 */
> #define acpi_pci_disabled 0 /* ACPI PCI always enabled on IA64 */
> diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
> index 0d407b3..615ef81 100644
> --- a/arch/ia64/kernel/acpi.c
> +++ b/arch/ia64/kernel/acpi.c
> @@ -56,6 +56,7 @@
>
> #define PREFIX "ACPI: "
>
> +int acpi_lapic;
> unsigned int acpi_cpei_override;
> unsigned int acpi_cpei_phys_cpuid;
>
> @@ -676,6 +677,8 @@ int __init early_acpi_boot_init(void)
> if (ret < 1)
> printk(KERN_ERR PREFIX
> "Error parsing MADT - no LAPIC entries\n");
> + else
> + acpi_lapic = 1;
>
> #ifdef CONFIG_SMP
> if (available_cpus == 0) {
> --
> 1.8.5.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/
[PATCH v4 2/4] usb: ehci-exynos: Use struct device instead of platform_device
Change to use struct device instead of struct platform_device
for some static functions.
Signed-off-by: Vivek Gautam
Acked-by: Alan Stern
Acked-by: Jingoo Han
Acked-by: Kukjin Kim
---
Changes since v1:
- none
drivers/usb/host/ehci-exynos.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7f425ac..4d763dc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -50,9 +50,8 @@ struct exynos_ehci_hcd {
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
-static void exynos_setup_vbus_gpio(struct platform_device *pdev)
+static void exynos_setup_vbus_gpio(struct device *dev)
{
- struct device *dev = >dev;
int err;
int gpio;
@@ -88,7 +87,7 @@ static int exynos_ehci_probe(struct platform_device *pdev)
if (err)
return err;
- exynos_setup_vbus_gpio(pdev);
+ exynos_setup_vbus_gpio(>dev);
hcd = usb_create_hcd(_ehci_hc_driver,
>dev, dev_name(>dev));
--
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/
[PATCH v4 1/4] usb: ohci-exynos: Use struct device instead of platform_device
Change to use struct device instead of struct platform_device
for some static functions.
Signed-off-by: Vivek Gautam
Acked-by: Alan Stern
Acked-by: Jingoo Han
Acked-by: Kukjin Kim
---
Changes since v1:
- none
drivers/usb/host/ohci-exynos.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 9cf80cb..05f00e3 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -39,18 +39,18 @@ struct exynos_ohci_hcd {
struct usb_otg *otg;
};
-static void exynos_ohci_phy_enable(struct platform_device *pdev)
+static void exynos_ohci_phy_enable(struct device *dev)
{
- struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
if (exynos_ohci->phy)
usb_phy_init(exynos_ohci->phy);
}
-static void exynos_ohci_phy_disable(struct platform_device *pdev)
+static void exynos_ohci_phy_disable(struct device *dev)
{
- struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
if (exynos_ohci->phy)
@@ -139,7 +139,7 @@ skip_phy:
platform_set_drvdata(pdev, hcd);
- exynos_ohci_phy_enable(pdev);
+ exynos_ohci_phy_enable(>dev);
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
@@ -150,7 +150,7 @@ skip_phy:
return 0;
fail_add_hcd:
- exynos_ohci_phy_disable(pdev);
+ exynos_ohci_phy_disable(>dev);
fail_io:
clk_disable_unprepare(exynos_ohci->clk);
fail_clk:
@@ -168,7 +168,7 @@ static int exynos_ohci_remove(struct platform_device *pdev)
if (exynos_ohci->otg)
exynos_ohci->otg->set_host(exynos_ohci->otg, >self);
- exynos_ohci_phy_disable(pdev);
+ exynos_ohci_phy_disable(>dev);
clk_disable_unprepare(exynos_ohci->clk);
@@ -190,7 +190,6 @@ static int exynos_ohci_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
- struct platform_device *pdev = to_platform_device(dev);
bool do_wakeup = device_may_wakeup(dev);
int rc = ohci_suspend(hcd, do_wakeup);
@@ -200,7 +199,7 @@ static int exynos_ohci_suspend(struct device *dev)
if (exynos_ohci->otg)
exynos_ohci->otg->set_host(exynos_ohci->otg, >self);
- exynos_ohci_phy_disable(pdev);
+ exynos_ohci_phy_disable(dev);
clk_disable_unprepare(exynos_ohci->clk);
@@ -211,14 +210,13 @@ static int exynos_ohci_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
- struct platform_device *pdev= to_platform_device(dev);
clk_prepare_enable(exynos_ohci->clk);
if (exynos_ohci->otg)
exynos_ohci->otg->set_host(exynos_ohci->otg, >self);
- exynos_ohci_phy_enable(pdev);
+ exynos_ohci_phy_enable(dev);
ohci_resume(hcd, false);
--
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/
[PATCH v6 3/4] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.
Signed-off-by: Vivek Gautam
Cc: Jingoo Han
Acked-by: Alan Stern
Acked-by: Kukjin Kim
---
Changes from v5:
- Removed setting phy explicitly to error pointer.
- Changed error check to '-ENOSYS' instead of '-ENXIO' in failure case of
devm_of_phy_get().
Changes from v4:
- Removed 'phy-names' property from the bindings since we don't need it.
- Restructured exynos_ohci_get_phy() function to handle error codes as
well as return relevant error codes effectively.
- Added IS_ERR() check for PHYs in exynos_ohci_phy_enable()/disable().
Changes from v3:
- Calling usb_phy_shutdown() when exynos_ohci_phy_enable() is failing.
- Made exynos_ohci_phy_disable() return void, since its return value
did not serve any purpose.
- Calling clk_disable_unprepare() in exynos_ohci_resume() when
exynos_ohci_phy_enable() is failed.
.../devicetree/bindings/usb/exynos-usb.txt | 16 +++
drivers/usb/host/ohci-exynos.c | 118 +---
2 files changed, 118 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index d967ba1..49a9c6f 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -38,6 +38,13 @@ Required properties:
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be "usbhost".
+ - port: if in the SoC there are OHCI phys, they should be listed here.
+ One phy per port. Each port should have following entries:
+ - reg: port number on OHCI controller, e.g
+ On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+ - phys: from the *Generic PHY* bindings, specifying phy used by port.
Example:
usb@1212 {
@@ -47,6 +54,15 @@ Example:
clocks = < 285>;
clock-names = "usbhost";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ phys = < 1>;
+ status = "disabled";
+ };
+
};
DWC3
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 05f00e3..32f2ff1 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -33,28 +34,110 @@ static struct hc_driver __read_mostly
exynos_ohci_hc_driver;
#define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)->priv)
+#define PHY_NUMBER 3
+
struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct phy *phy_g[PHY_NUMBER];
};
-static void exynos_ohci_phy_enable(struct device *dev)
+static int exynos_ohci_get_phy(struct device *dev,
+ struct exynos_ohci_hcd *exynos_ohci)
+{
+ struct device_node *child;
+ struct phy *phy;
+ int phy_number;
+ int ret = 0;
+
+ exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ohci->phy)) {
+ ret = PTR_ERR(exynos_ohci->phy);
+ if (ret != -ENXIO && ret != -ENODEV) {
+ dev_err(dev, "no usb2 phy configured\n");
+ return ret;
+ }
+ dev_dbg(dev, "Failed to get usb2 phy\n");
+ } else {
+ exynos_ohci->otg = exynos_ohci->phy->otg;
+ }
+
+ /*
+* Getting generic phy:
+* We are keeping both types of phys as a part of transiting OHCI
+* to generic phy framework, so as to maintain backward compatibilty
+* with old DTB.
+* If there are existing devices using DTB files built from them,
+* to remove the support for old bindings in this driver,
+* we need to make sure that such devices have their DTBs
+* updated to ones built from new DTS.
+*/
+ for_each_available_child_of_node(dev->of_node, child) {
+ ret = of_property_read_u32(child, "reg", _number);
+ if (ret) {
+ dev_err(dev, "Failed to parse device tree\n");
+ of_node_put(child);
+ return ret;
+ }
+
+ if (phy_number >= PHY_NUMBER) {
+ dev_err(dev, "Invalid number of PHYs\n");
+
[PATCH v12 4/4] usb: ehci-exynos: Change to use phy provided by the generic phy framework
From: Kamil Debski
Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for older USB phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ehci-exynos.
Once we move to new phy in the device nodes for ehci, we can
remove the support for older phys.
Signed-off-by: Kamil Debski
[gautam.vi...@samsung.com: Addressed review comments from mailing list]
[gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
added support for new exynos5-usb2phy in generic phy framework]
[gautam.vi...@samsung.com: Edited the commit message]
Signed-off-by: Vivek Gautam
Cc: Jingoo Han
Acked-by: Alan Stern
Acked-by: Kukjin Kim
---
Changes from v11:
- Removed setting phy explicitly to error pointer.
- Changed error check to '-ENOSYS' instead of '-ENXIO' in failure case of
devm_of_phy_get().
Changes from v10:
- Removed 'phy-names' property from the bindings since we don't need it.
- Restructured exynos_ehci_get_phy() function to handle error codes as
well as return relevant error codes effectively.
- Added IS_ERR() check for PHYs in exynos_ehci_phy_enable()/disable().
Changes from v9:
- Calling usb_phy_shutdown() when exynos_ehci_phy_enable() is failing.
- Made exynos_ehci_phy_disable() return void, since its return value
did not serve any purpose.
- Calling clk_disable_unprepare() in exynos_ehci_resume() when
exynos_ehci_phy_enable() is failed.
.../devicetree/bindings/usb/exynos-usb.txt | 15 +++
drivers/usb/host/ehci-exynos.c | 129 +---
2 files changed, 124 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 49a9c6f..a3b5990 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -12,6 +12,13 @@ Required properties:
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be "usbhost".
+ - port: if in the SoC there are EHCI phys, they should be listed here.
+ One phy per port. Each port should have following entries:
+ - reg: port number on EHCI controller, e.g
+ On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+ - phys: from the *Generic PHY* bindings; specifying phy used by port.
Optional properties:
- samsung,vbus-gpio: if present, specifies the GPIO that
@@ -27,6 +34,14 @@ Example:
clocks = < 285>;
clock-names = "usbhost";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ phys = < 1>;
+ status = "disabled";
+ };
};
OHCI
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 4d763dc..c7081c7 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -42,14 +43,104 @@
static const char hcd_name[] = "ehci-exynos";
static struct hc_driver __read_mostly exynos_ehci_hc_driver;
+#define PHY_NUMBER 3
+
struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct phy *phy_g[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
+static int exynos_ehci_get_phy(struct device *dev,
+ struct exynos_ehci_hcd *exynos_ehci)
+{
+ struct device_node *child;
+ struct phy *phy;
+ int phy_number;
+ int ret = 0;
+
+ exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ehci->phy)) {
+ ret = PTR_ERR(exynos_ehci->phy);
+ if (ret != -ENXIO && ret != -ENODEV) {
+ dev_err(dev, "no usb2 phy configured\n");
+ return ret;
+ }
+ dev_dbg(dev, "Failed to get usb2 phy\n");
+ } else {
+ exynos_ehci->otg = exynos_ehci->phy->otg;
+ }
+
+ for_each_available_child_of_node(dev->of_node, child) {
+ ret = of_property_read_u32(child, "reg", _number);
+ if (ret) {
+ dev_err(dev, "Failed to parse device tree\n");
+ of_node_put(child);
+ return ret;
+ }
+
+ if (phy_number >= PHY_NUMBER) {
+ dev_err(dev, "Invalid number of PHYs\n");
+ of_node_put(child);
+ return -EINVAL;
+ }
+
+ phy = devm_of_phy_get(dev, child, 0);
Re: [PATCH RFC/TEST] sched: make sync affine wakeups work
On 05/04/2014 06:11 PM, Rik van Riel wrote: > On 05/04/2014 07:44 AM, Preeti Murthy wrote: >> Hi Rik, Mike >> >> On Fri, May 2, 2014 at 12:00 PM, Rik van Riel wrote: >>> On 05/02/2014 02:13 AM, Mike Galbraith wrote: On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote: > Whether or not this is the right thing to do remains to be seen, > but it does allow us to verify whether or not the wake_affine > strategy of always doing affine wakeups and only disabling them > in a specific circumstance is sound, or needs rethinking... Yes, it needs rethinking. I know why you want to try this, yes, select_idle_sibling() is very much a two faced little bitch. >>> >>> My biggest problem with select_idle_sibling and wake_affine in >>> general is that it will override NUMA placement, even when >>> processes only wake each other up infrequently... >> >> As far as my understanding goes, the logic in select_task_rq_fair() >> does wake_affine() or calls select_idle_sibling() only at those >> levels of sched domains where the flag SD_WAKE_AFFINE is set. >> This flag is not set at the numa domain and hence they will not be >> balancing across numa nodes. So I don't understand how >> *these functions* are affecting NUMA placements. > > Even on 8-node DL980 systems, the NUMA distance in the > SLIT table is less than RECLAIM_DISTANCE, and we will > do wake_affine across the entire system. > >> The wake_affine() and select_idle_sibling() will shuttle tasks >> within a NUMA node as far as I can see.i.e. if the cpu that the task >> previously ran on and the waker cpu belong to the same node. >> Else they are not called. > > That is what I first hoped, too. I was wrong. > >> If the prev_cpu and the waker cpu are on different NUMA nodes >> then naturally the tasks will get shuttled across NUMA nodes but >> the culprits are the find_idlest* functions. >>They do a top-down search for the idlest group and cpu, starting >> at the NUMA domain *attached to the waker and not the prev_cpu*. >> This means that the task will end up on a different NUMA node. >> Looks to me that the problem lies here and not in the wake_affine() >> and select_idle_siblings(). > > I have a patch for find_idlest_group that takes the NUMA > distance between each group and the task's preferred node > into account. > > However, as long as the wake_affine stuff still gets to > override it, that does not make much difference :) > Yeah now I see it. But I still feel wake_affine() and select_idle_sibling() are not at fault primarily because when they were introduced, I don't think it was foreseen that the cpu topology would grow to the extent it is now. select_idle_sibling() for instance scans the cpus within the purview of the last level cache of a cpu and this was a small set. Hence there was no overhead. Now with many cpus sharing the L3 cache, we see an overhead. wake_affine() probably did not expect the NUMA nodes to come under its governance as well and hence it sees no harm in waking up tasks close to the waker because it still believes that it will be within a node. What has changed is the code around these two functions I feel. Take this problem for instance. We ourselves are saying in sd_local_flags() that this specific domain is fit for wake affine balance. So naturally the logic in wake_affine and select_idle_sibling() will follow. My point is the peripheral code is seeing the negative affect of these two functions because they pushed themselves under its ambit. Don't you think we should go conservative on the value of RECLAIM_DISTANCE in arch specific code at-least? On powerpc we set it to 10. Besides, the git log does not tell us the basis on which this value was set to a default of 30. Maybe this needs re-thought? Regards Preeti U Murthy -- 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/1] FS/CIFS: remove obsolete __constant
On Sun, 4 May 2014 18:52:43 -0400
Jeff Layton wrote:
> On Sat, May 3, 2014 at 4:15 PM, Fabian Frederick wrote:
> > Replacing all __constant_foo to foo()
> > except in smb2status.h (1700 lines to update).
> >
> > Cc: linux-c...@vger.kernel.org
> > Cc: Steve French
> > Cc: Andrew Morton
> > Signed-off-by: Fabian Frederick
> > ---
> > fs/cifs/cifsacl.c | 2 +-
> > fs/cifs/cifssmb.c | 20 ++--
> > fs/cifs/sess.c | 2 +-
> > fs/cifs/smb2misc.c | 38 +++---
> > fs/cifs/smb2ops.c | 2 +-
> > fs/cifs/smb2pdu.c | 2 +-
> > fs/cifs/smb2pdu.h | 28 ++--
> > 7 files changed, 47 insertions(+), 47 deletions(-)
> >
> > diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
> > index 7ff866d..54ac0e8 100644
> > --- a/fs/cifs/cifsacl.c
> > +++ b/fs/cifs/cifsacl.c
> > @@ -38,7 +38,7 @@ static const struct cifs_sid sid_everyone = {
> > 1, 1, {0, 0, 0, 0, 0, 1}, {0} };
> > /* security id for Authenticated Users system group */
> > static const struct cifs_sid sid_authusers = {
> > - 1, 1, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(11)} };
> > + 1, 1, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(11)} };
>
>
> Does the build still work on BE arches with this? I know at one point
> the above wouldn't compile on those
> arches. See commit 536abdb0802f, for an explanation.
Untested on BE but it would mean checkpatch
"don't use __constant functions outside of include/uapi/" stuff is wrong ?
--
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 v3 2/2] lapic need be checked if available when initialize acpi processor id
In acpi_processor_get_info(), acpi processor info is initialized including
id, namely cpu index. Currently, if on UP system running SMP kerenl with
no LAPIC in MADT, cpu0_initialized is checked if acpi processor id is
initialized.
However this check maybe is not sufficient for kdump kernel. Most of time
only 1 CPU is supported because of known problems in kdump kernel. So in
1st kernel multiple CPUs are present, then crash happened in one specific
CPU, say 2nd CPU. Then it jumped into kdump kernel with "nr_cpus=1" specified
in cmdline. In this situation, since kdump kernel is warm reset, it will
reuse the ACPI resource passed from crashed kernel directly, namely 1st
kernel. It means in MADT all LAPIC is enabled while only 1 CPU is
present in running system. The kdump kernel usually is the same as the
crashed 1st kernel. So now in kdump kernel, x86_cpu_to_apicid stored the
apicid and its related cpu id. If only check cpu0_initialized, it will
assign 0 to the acpi processor id of 1st CPU, it's not correct.
So in this patch, check acpi_lapic too. If acpi_lapic is 0, then LAPIC in
MADT is not available, assigne 0 to the handling acpi processor id. If
acpi_lapic is 1, then LAPIC in MADT is available, let's get apic processor
id from x86_cpu_to_apicid.
Signed-off-by: Baoquan He
---
drivers/acpi/acpi_processor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index b06f5f5..bf0cce9 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -268,7 +268,7 @@ static int acpi_processor_get_info(struct acpi_device
*device)
pr->apic_id = apic_id;
cpu_index = acpi_map_cpuid(pr->apic_id, pr->acpi_id);
- if (!cpu0_initialized) {
+ if (!cpu0_initialized && !acpi_lapic) {
cpu0_initialized = 1;
/* Handle UP system running SMP kernel, with no LAPIC in MADT */
if ((cpu_index == -1) && (num_online_cpus() == 1))
--
1.8.5.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/
[Patch v3 1/2] introduce variable acpi_lapic into ia64
This variable was defined and assigned in x86, is used to indicate
whether LAPIC exists in MADT. Now introduce it into ia64 to help
make correct judgment when get information for acpi processor later.
Signed-off-by: Baoquan He
---
arch/ia64/include/asm/acpi.h | 1 +
arch/ia64/kernel/acpi.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
index d651102..b478219 100644
--- a/arch/ia64/include/asm/acpi.h
+++ b/arch/ia64/include/asm/acpi.h
@@ -85,6 +85,7 @@ ia64_acpi_release_global_lock (unsigned int *lock)
((Acq) = ia64_acpi_release_global_lock(>global_lock))
#ifdef CONFIG_ACPI
+extern int acpi_lapic;
#define acpi_disabled 0/* ACPI always enabled on IA64 */
#define acpi_noirq 0 /* ACPI always enabled on IA64 */
#define acpi_pci_disabled 0 /* ACPI PCI always enabled on IA64 */
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 0d407b3..615ef81 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -56,6 +56,7 @@
#define PREFIX "ACPI: "
+int acpi_lapic;
unsigned int acpi_cpei_override;
unsigned int acpi_cpei_phys_cpuid;
@@ -676,6 +677,8 @@ int __init early_acpi_boot_init(void)
if (ret < 1)
printk(KERN_ERR PREFIX
"Error parsing MADT - no LAPIC entries\n");
+ else
+ acpi_lapic = 1;
#ifdef CONFIG_SMP
if (available_cpus == 0) {
--
1.8.5.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 RFC/TEST] sched: make sync affine wakeups work
On 05/04/2014 05:34 PM, Mike Galbraith wrote:
> On Sun, 2014-05-04 at 17:14 +0530, Preeti Murthy wrote:
>> Hi Rik, Mike
>>
>> On Fri, May 2, 2014 at 12:00 PM, Rik van Riel wrote:
>>> On 05/02/2014 02:13 AM, Mike Galbraith wrote:
On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
> Whether or not this is the right thing to do remains to be seen,
> but it does allow us to verify whether or not the wake_affine
> strategy of always doing affine wakeups and only disabling them
> in a specific circumstance is sound, or needs rethinking...
Yes, it needs rethinking.
I know why you want to try this, yes, select_idle_sibling() is very much
a two faced little bitch.
>>>
>>> My biggest problem with select_idle_sibling and wake_affine in
>>> general is that it will override NUMA placement, even when
>>> processes only wake each other up infrequently...
>>
>> As far as my understanding goes, the logic in select_task_rq_fair()
>> does wake_affine() or calls select_idle_sibling() only at those
>> levels of sched domains where the flag SD_WAKE_AFFINE is set.
>> This flag is not set at the numa domain and hence they will not be
>> balancing across numa nodes. So I don't understand how
>> *these functions* are affecting NUMA placements.
>
> Depends on how far away node yonder is I suppose.
>
> static inline int sd_local_flags(int level)
> {
> if (sched_domains_numa_distance[level] > RECLAIM_DISTANCE)
> return 0;
>
> return SD_BALANCE_EXEC | SD_BALANCE_FORK | SD_WAKE_AFFINE;
> }
>
>
Hmm thanks Mike, I totally missed this!
Regards
Preeti U Murthy
--
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 1/5] watchdog: Add API to trigger reboots
On Fri, May 02, 2014 at 09:29:25PM -0700, Guenter Roeck wrote: > > > + if (wdd->ops->reboot) > > > + wdd_reboot_dev = wdd; > > > + > > > > Overall, it looks really great, but I guess we can make it a > > list. Otherwise, we might end up in a situation where we could not > > reboot anymore, like this one for example: > > - a first watchdog is probed, registers a reboot function > > - a second watchdog is probed, registers a reboot function that > > overwrites the first one. > > - then, the second watchdog disappears for some reason, and the > > reboot is set to NULL > > > I thought about that, but how likely (or unlikely) is that to ever happen ? > So I figured it is not worth the effort, and would just add complexity without > real gain. We could always add the list later if we ever encounter a situation > where two watchdogs in the same system provide a reboot callback. The A31 we were discussing about in the other thread that doesn't have a watchdog driver yet has four, identical, watchogs. I'm not really concerned about the mentionned issue, since they will never be removed, but the situation might happen with an on-SoC watchdog and an i2c one (if that even exists). But yes, right, that can be postponed. > > Or maybe we can just use the start callback, with the min timeout already > > registered, and prevent the user to kick the watchdog. > > > Doesn't always work, unfortunately, even now. The moxart driver causes > an explicit and immediate reset. Also, some watchdogs don't reset the system > directly but get an interrupt, which then calls the reset handler. Which, > in our case, would call the start callback again, and you would have an > endless > loop. Ok. You have my Acked-by then. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v1.0 12/16] arcmsr: revise alloction of second dma_coherent_handle for type B adapter
Hi Dan, This patch is not a bugfix. It is a simplification and consistency of coding for both adapter type B and D. Regards, Ching 2014-05-02 16:57 GMT+08:00 Dan Carpenter : > On Wed, Apr 30, 2014 at 07:30:29PM +0800, ching wrote: >> From: Ching >> >> Revise allocation of second dma_coherent_handle for type_B adapter. >> > > Is this a bugfix? I think it is. Do you know what the user visible > effects are? > > regards, > dan carpenter > -- 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-next: manual merge of the tip tree with the net-next tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
net/ipv4/tcp_output.c between commit e114a710aa50 ("tcp: fix cwnd limited
checking to improve congestion control") from the tree and commit
4e857c58efeb ("arch: Mass conversion of smp_mb__*()") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/ipv4/tcp_output.c
index 694711a140d4,366cf06587b8..
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@@ -1946,18 -1930,10 +1946,16 @@@ static bool tcp_write_xmit(struct sock
/* It is possible TX completion already happened
* before we set TSQ_THROTTLED, so we must
* test again the condition.
-* We abuse smp_mb__after_clear_bit() because
-* there is no smp_mb__after_set_bit() yet
*/
- smp_mb__after_clear_bit();
+ smp_mb__after_atomic();
- if (atomic_read(>sk_wmem_alloc) > limit)
+ if (atomic_read(>sk_wmem_alloc) > limit) {
+ u32 unsent_bytes;
+
+compute_unsent_segs:
+ unsent_bytes = tp->write_seq - tp->snd_nxt;
+ unsent_segs = DIV_ROUND_UP(unsent_bytes,
mss_now);
break;
+ }
}
limit = mss_now;
pgpmpZrXCzi4s.pgp
Description: PGP signature
Re: [PATCH] spi: Force the registration of the spidev devices
On Fri, May 02, 2014 at 10:40:48AM -0700, Mark Brown wrote: > > i2c-dev works great in these cases, because you always have access to > > all the bus, and all the devices, except if the device is already used > > by someone. The patch I suggested is an attempt to mimic this. > > It seems better to implement something like this at the device model > level, provide a way to have a default UIO driver for anything on a > given bus. I don't see anything bus specific apart from saying what the > default driver to use is and it avoids the icky code fiddling about with > what devices are bound and the races that might be involved duplicated > in individual buses. Hmmm, yes, that's probably a great long-term way of dealing with this, but I don't see it happening soon. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
RE: [PATCH 20/27] ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table().
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Monday, May 05, 2014 8:43 AM
>
> On Saturday, May 03, 2014 08:59:14 AM Josh Boyer wrote:
> > On Tue, Apr 29, 2014 at 10:05 PM, Lv Zheng wrote:
> > > The commit of back porting Linux XSDT validation mechanism has introduced
> > > a regreession:
> > > Commit: 671cc68dc61f029d44b43a681356078e02d8dab8
> > > Subject: ACPICA: Back port and refine validation of the XSDT root table.
> > > There is a pointer still accessed after unmapping.
> > >
> > > This patch fixes this issue. Lv Zheng.
> > >
> > > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911
> > > Buglink: https://bugs.archlinux.org/task/39811
> > > Signed-off-by: Lv Zheng
> > > Reported-and-tested-by: Bruce Chiarelli
> > > Reported-and-tested-by: Spyros Stathopoulos
> > > Signed-off-by: Bob Moore
> > > Cc: # 3.14.x: 671cc68: ACPICA: Back port and
> > > refine validation of the XSDT root table.
> >
> > This patch should get into 3.15-rcX soon. It fixes a known regression
> > that prevents booting on machines with AMI firmware, and that is
> > present in 3.14 so we need it for stable as well. Rafael?
>
> Lv, is it safe to take this patch alone into 3.15-rc?
Yes, it's safe to only take this patch to be a regression fix.
I'm sorry for the regression I made in the bisected commit.
Thanks and best regards
-Lv
>
> Rafael
>
>
> > > ---
> > > drivers/acpi/acpica/tbutils.c |7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
> > > index 6c31d77..e1638ad 100644
> > > --- a/drivers/acpi/acpica/tbutils.c
> > > +++ b/drivers/acpi/acpica/tbutils.c
> > > @@ -355,6 +355,7 @@ acpi_status __init
> > > acpi_tb_parse_root_table(acpi_physical_address rsdp_address)
> > > u32 table_count;
> > > struct acpi_table_header *table;
> > > acpi_physical_address address;
> > > + acpi_physical_address rsdt_address;
> > > u32 length;
> > > u8 *table_entry;
> > > acpi_status status;
> > > @@ -383,11 +384,14 @@ acpi_status __init
> > > acpi_tb_parse_root_table(acpi_physical_address rsdp_address)
> > > * as per the ACPI specification.
> > > */
> > > address = (acpi_physical_address)
> > > rsdp->xsdt_physical_address;
> > > + rsdt_address =
> > > + (acpi_physical_address) rsdp->rsdt_physical_address;
> > > table_entry_size = ACPI_XSDT_ENTRY_SIZE;
> > > } else {
> > > /* Root table is an RSDT (32-bit physical addresses) */
> > >
> > > address = (acpi_physical_address)
> > > rsdp->rsdt_physical_address;
> > > + rsdt_address = address;
> > > table_entry_size = ACPI_RSDT_ENTRY_SIZE;
> > > }
> > >
> > > @@ -410,8 +414,7 @@ acpi_status __init
> > > acpi_tb_parse_root_table(acpi_physical_address rsdp_address)
> > >
> > > /* Fall back to the RSDT */
> > >
> > > - address =
> > > - (acpi_physical_address)
> > > rsdp->rsdt_physical_address;
> > > + address = rsdt_address;
> > > table_entry_size = ACPI_RSDT_ENTRY_SIZE;
> > > }
> > > }
> > > --
> > > 1.7.10
> > >
> > > --
> > > 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/
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] spi: Force the registration of the spidev devices
Hi Geert On Fri, May 02, 2014 at 01:28:26AM +0200, Geert Uytterhoeven wrote: > Hi Maxime, > > On Fri, May 2, 2014 at 12:36 AM, Maxime Ripard > wrote: > > But it actually doesn't work in a case where you can't really predict > > what is on the other side of the bus. Either because, on the board > > you're using the pins are exposed and it's pretty much up to the user > > to know what to put on it. That could be handled by DT overlays > > though. > > > > What never works is where the device on the other side is so generic > > that you really can't tell what it does. Think of a microcontroller > > that would behave as a SPI slave. It's behaviour and what it does is > > pretty much dependant of what we flashed on it, and suddenly the > > compatible string is not the proper reprensentation anymore. > > So you will (hopefully soon) use overlay DT to change the DTS to match what's > connected? Not really, because you can't declare a spidev device in the DT. > And then you want spidev to bind to it. Would it help if DT offered a feature > to add a compatible entry to a driver at runtime, cfr. > /sys/bus/pci/drivers/.../new_id on PCI? The thing is, in the core SPI bus, devices are only instiated (in the DT case), by parsing the DT. So, to bind a device to a new driver, it has to exist in the first place, and it won't exist, because there won't be any node in the DT for this device. But since DT is unsuitable for such a device, you go back to where we were initially. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH] ptrace: Fix PTRACE_GETREGSET/PTRACE_SETREGSET in code documentation
On 05/01/2014 07:43 PM, Pedro Alves wrote:
> On 04/28/2014 12:00 PM, Anshuman Khandual wrote:
>> The current documentation is bit misleading and does not explicitly
>> specify that iov.len need to be initialized failing which kernel
>> may just ignore the ptrace request and never read from/write into
>> the user specified buffer. This patch fixes the documentation.
>
> Well, it kind of does, here:
>
> * struct iovec iov = { buf, len};
:) Thats not explicit enough.
>
>> @@ -43,8 +43,12 @@
>> *
>> * ret = ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid, NT_XXX_TYPE, );
>> *
>> - * On the successful completion, iov.len will be updated by the kernel,
>> - * specifying how much the kernel has written/read to/from the user's
>> iov.buf.
>> + * A non-zero value upto the max size of data expected to be written/read
>> by the
>> + * kernel in response to any NT_XXX_TYPE request type must be assigned to
>> iov.len
>> + * before initiating the ptrace call. If iov.len is 0, then kernel will
>> neither
>> + * read from or write into the user buffer specified. On successful
>> completion,
>> + * iov.len will be updated by the kernel, specifying how much the kernel has
>> + * written/read to/from the user's iov.buf.
>
> I really appreciate that you're trying to make this clearer, but I
> find the new sentence very hard to read/reason. :-/
>
> I suggest:
>
> * This interface usage is as follows:
> - * struct iovec iov = { buf, len};
> + * struct iovec iov = { buf, len };
> *
> * ret = ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid, NT_XXX_TYPE,
> );
> *
> - * On the successful completion, iov.len will be updated by the kernel,
> - * specifying how much the kernel has written/read to/from the user's
> iov.buf.
> + * On entry, iov describes the buffer's address and length. The buffer's
> + * length must be equal to or shorter than the size of the NT_XXX_TYPE
> regset.
> + * On successful completion, iov.len is updated by the kernel, specifying how
> + * much the kernel has written/read to/from the user's iov.buf.
>
Yeah, sounds better. I may add "If the length is zero, the kernel will neither
read
from or write into the buffer"
> I'm not sure I understood what you're saying correctly, though. Specifically,
> I don't know whether the buffer's length must really be shorter than the
> size of the NT_XXX_TYPE regset.
No, it does not have to. From the code snippet below (ptrace_regset function)
the buffer length has to be multiple of regset->size for the given NT_XXX_TYPE
upto the max regset size for the user to see any valid data. The problem what I
faced was when you use any iovec structure with the length parameter
uninitialized,
the kernel simply ignores and does not return anything.
if (!regset || (kiov->iov_len % regset->size) != 0)
return -EINVAL;
>
>> The current documentation is bit misleading and does not explicitly
>> specify that iov.len need to be initialized failing which kernel
>> may just ignore the ptrace request and never read from/write into
>> the user specified buffer.
>
> You're saying that if iov.len is larger than the NT_XXX_TYPE regset,
> then the kernel returns _success_, but actually doesn't fill the
> buffer? That sounds like a bug to me.
No, I am not saying that. The kernel takes care of that situation by capping
the length to regset size of the NT_XXX_TYPE.
kiov->iov_len = min(kiov->iov_len,
(__kernel_size_t) (regset->n * regset->size));
Shall I resend the patch with the your proposed changes and your
"Signed-off-by" and
moving myself as "Reported-by" ?
--
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.0 14/16] arcmsr: fix sparse checking error
Hi Dan,
In this patch, there are several replace of call readl() or writel()
by direct access to memory.
Because in main memory, we allocated a block of memory for
post_qbuffer and done_qbuffer.
These memory are access by both of CPU and IOP, they are not hardware registers.
This change will not introduce a bug. I have verified it.
Thanks for your comment.
Regards,
Ching
2014-05-02 17:13 GMT+08:00 Dan Carpenter :
> On Wed, Apr 30, 2014 at 07:38:26PM +0800, ching wrote:
>> From: Ching
>>
>> Fix sparse utility checking errors.
>>
>
> I was expecting that this patch would add __iomem annotations throughout
> but in several places it actually removes calls to readl() and writel()
> as well.
>
>> case ACB_ADAPTER_TYPE_C:{
>> - struct MessageUnit_C *reg = (struct MessageUnit_C *)acb->pmuC;
>> + struct MessageUnit_C __iomem *reg = acb->pmuC;
>> /* disable all outbound interrupt */
>> orig_mask = readl(>host_int_mask); /* disable outbound
>> message0 int */
>> writel(orig_mask|ARCMSR_HBCMU_ALL_INTMASKENABLE,
>> >host_int_mask);v
>> @@ -1085,8 +1085,9 @@ static void arcmsr_done4abort_postqueue(
>> /*clear all outbound posted Q*/
>> writel(ARCMSR_DOORBELL_INT_CLEAR_PATTERN,
>> reg->iop2drv_doorbell); /* clear doorbell interrupt */
>> for (i = 0; i < ARCMSR_MAX_HBB_POSTQUEUE; i++) {
>> - if ((flag_ccb = readl(>done_qbuffer[i])) != 0) {
>> - writel(0, >done_qbuffer[i]);
>> + flag_ccb = reg->done_qbuffer[i];
>> + if (flag_ccb != 0) {
>> + reg->done_qbuffer[i] = 0;
>> pARCMSR_CDB = (struct ARCMSR_CDB
>> *)(acb->vir2phy_offset+(flag_ccb << 5));/*frame must be 32 bytes aligned*/
>> pCCB = container_of(pARCMSR_CDB, struct
>> CommandControlBlock, arcmsr_cdb);
>> error = (flag_ccb &
>> ARCMSR_CCBREPLY_FLAG_ERROR_MODE0) ? true : false;
>
> I don't know the hardware, but it doesn't even seem to make sense to me.
> if "reg" is an __iomem pointer surely an offset into reg is an iomem
> pointer as well.
>
> I am worried that this introduces a bug.
>
> regards,
> dan carpenter
--
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] bridge: Add port flap detection
On Sun, May 4, 2014 at 3:53 PM, Stephen Hemminger
wrote:
> On Mon, 5 May 2014 07:29:34 +1000
> Jon Maxwell wrote:
>
>> There has been a number incidents recently where customers running KVM have
>> reported that VM hosts on different Hypervisors are unreachable. Based on
>> pcap traces we found that the bridge was broadcasting the ARP request out
>> onto the network. However some NICs have an inbuilt switch which on
>> occasions were broadcasting the VMs ARP request back through the physical
>> NIC on the Hypervisor. This resulted in the bridge flapping ports and
>> incorrectly learning that the VMs mac address was external. As a result the
>> ARP reply was directed back onto the external network and VM never updated
>> it's ARP cache. This patch will detect port flapping and log a message so
>> that this condition can be detected earlier.
>>
>> Signed-off-by: Jon Maxwell
>> ---
>> net/bridge/br_fdb.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
>> index 9203d5a..c08607b 100644
>> --- a/net/bridge/br_fdb.c
>> +++ b/net/bridge/br_fdb.c
>> @@ -507,6 +507,13 @@ void br_fdb_update(struct net_bridge *br, struct
>> net_bridge_port *source,
>> source->dev->name);
>> } else {
>> /* fastpath: update of existing entry */
>> + if (source->port_no != fdb->dst->port_no &&
>> + net_ratelimit())
>> + br_warn(br, "Port flapping detected source
>> entry dev = %s mac = %pM, port_no = %d\n existing entry dev = %s mac = %pM,
>> port_no = %d\n",
>> + source->dev->name,
>> + addr, source->port_no,
>> + fdb->dst->dev->name, addr,
>> + fdb->dst->port_no);
>> fdb->dst = source;
>> fdb->updated = jiffies;
>> if (unlikely(added_by_user))
>
> Ok, but please shorten the message to a single line without excess wordage.
> Plus flapping to mean means link going up and down. Maybe use same message
> as BSD?
Isn't this normal mac move? Any message will be confusing.
VMs can spoof their src macs and trigger this warning.
I don't think it's worth adding it just to debug the learning on the
external interface.
--
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] zram: remove global tb_lock by using lock-free CAS
Currently, we use a rwlock tb_lock to protect concurrent access to
whole zram meta table. However, according to the actual access model,
there is only a small chance for upper user access the same table[index],
so the current lock granularity is too big.
This patch add a atomic state for every table[index] to record its access,
by using CAS operation, protect concurrent access to the same table[index],
meanwhile allow the maximum concurrency.
On 64-bit system, it will not increase the meta table memory overhead, and
on 32-bit system with 4K page_size, it will increase about 1MB memory overhead
for 1GB zram. So, it is cost-efficient.
Test result:
(x86-64 Intel Core2 Q8400, system memory 4GB, Ubuntu 12.04,
kernel v3.15.0-rc3, zram 1GB with 4 max_comp_streams LZO,
take the average of 5 tests)
iozone -t 4 -R -r 16K -s 200M -I +Z
Test base lock-freeratio
--
Initial write 1348017.601424141.62 +5.6%
Rewrite 1520189.161652504.81 +8.7%
Read 8294445.45 11404668.35 +37.5%
Re-read 8134448.83 11555483.75 +42.1%
Reverse Read 6748717.978394478.17 +24.4%
Stride read 7220276.669372229.95 +29.8%
Random read 7133010.069187221.90 +28.8%
Mixed workload 4056980.715843370.85 +44.0%
Random write 1470106.171608947.04 +9.4%
Pwrite 1259493.721311055.32 +4.1%
Pread 4247583.174652056.11 +9.5%
Signed-off-by: Weijie Yang
---
This patch is based on linux-next tree, commit b5c8d48bf8f42
drivers/block/zram/zram_drv.c | 41 ++---
drivers/block/zram/zram_drv.h |5 -
2 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 48eccb3..8b70945
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -255,7 +255,6 @@ static struct zram_meta *zram_meta_alloc(u64 disksize)
goto free_table;
}
- rwlock_init(>tb_lock);
return meta;
free_table:
@@ -339,12 +338,14 @@ static int zram_decompress_page(struct zram *zram, char
*mem, u32 index)
unsigned long handle;
u16 size;
- read_lock(>tb_lock);
+ while(atomic_cmpxchg(>table[index].state, IDLE, ACCESS) != IDLE)
+ cpu_relax();
+
handle = meta->table[index].handle;
size = meta->table[index].size;
if (!handle || zram_test_flag(meta, index, ZRAM_ZERO)) {
- read_unlock(>tb_lock);
+ atomic_set(>table[index].state, IDLE);
clear_page(mem);
return 0;
}
@@ -355,7 +356,7 @@ static int zram_decompress_page(struct zram *zram, char
*mem, u32 index)
else
ret = zcomp_decompress(zram->comp, cmem, size, mem);
zs_unmap_object(meta->mem_pool, handle);
- read_unlock(>tb_lock);
+ atomic_set(>table[index].state, IDLE);
/* Should NEVER happen. Return bio error if it does. */
if (unlikely(ret)) {
@@ -376,14 +377,16 @@ static int zram_bvec_read(struct zram *zram, struct
bio_vec *bvec,
struct zram_meta *meta = zram->meta;
page = bvec->bv_page;
- read_lock(>tb_lock);
+ while(atomic_cmpxchg(>table[index].state, IDLE, ACCESS) != IDLE)
+ cpu_relax();
+
if (unlikely(!meta->table[index].handle) ||
zram_test_flag(meta, index, ZRAM_ZERO)) {
- read_unlock(>tb_lock);
+ atomic_set(>table[index].state, IDLE);
handle_zero_page(bvec);
return 0;
}
- read_unlock(>tb_lock);
+ atomic_set(>table[index].state, IDLE);
if (is_partial_io(bvec))
/* Use a temporary buffer to decompress the page */
@@ -461,10 +464,13 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
if (page_zero_filled(uncmem)) {
kunmap_atomic(user_mem);
/* Free memory associated with this sector now. */
- write_lock(>meta->tb_lock);
+ while(atomic_cmpxchg(>table[index].state,
+ IDLE, ACCESS) != IDLE)
+ cpu_relax();
+
zram_free_page(zram, index);
zram_set_flag(meta, index, ZRAM_ZERO);
- write_unlock(>meta->tb_lock);
+ atomic_set(>table[index].state, IDLE);
atomic64_inc(>stats.zero_pages);
ret = 0;
@@ -514,12 +520,13 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
* Free memory associated with this sector
* before overwriting unused sectors.
*/
- write_lock(>meta->tb_lock);
+ while(atomic_cmpxchg(>table[index].state, IDLE, ACCESS) != IDLE)
+ cpu_relax();
Re: [PATCH 0/2] namespaces: log namespaces per task
Quoting James Bottomley (james.bottom...@hansenpartnership.com):
> On Tue, 2014-04-22 at 14:12 -0400, Richard Guy Briggs wrote:
> > Questions:
> > Is there a way to link serial numbers of namespaces involved in migration
> > of a
> > container to another kernel? (I had a brief look at CRIU.) Is there a
> > unique
> > identifier for each running instance of a kernel? Or at least some
> > identifier
> > within the container migration realm?
>
> Are you asking for a way of distinguishing an migrated container from an
> unmigrated one? The answer is pretty much "no" because the job of
> migration is to restore to the same state as much as possible.
>
> Reading between the lines, I think your goal is to correlate audit
> information across a container migration, right? Ideally the management
> system should be able to cough up an audit trail for a container
> wherever it's running and however many times it's been migrated?
>
> In that case, I think your idea of a numeric serial number in a dense
> range is wrong. Because the range is dense you're obviously never going
> to be able to use the same serial number across a migration. However,
Ah, but I was being silly before, we can actually address this pretty
simply. If we just (for instance) add
/proc/self/ns/{ic,mnt,net,pid,user,uts}_seq containing the serial number
for the relevant ns for the task, then criu can dump this info at
checkpoint. Then at restart it can dump an audit message per task and
ns saying old_serial=%x,new_serial=%x. That way the audit log reader
can if it cares keep track.
-serge
(Another, more heavyweight approach would be to track all ns hierarchies
and make the serial numbers per-namespace-instance. So my container's
pidns serial might be 0x2, and if it clones a new pidns that would be
"(0x2,0x1)" on the host, or just 0x1 inside the container. But we don't
need that if the simple userspace approach suffices)
--
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/6] ARM: sunxi: Machine code cleanup
Hi, This serie moves the restart code out of the mach-sunxi directory to either the watchdog driver or to a new driver in drivers/power/reset. Since the reset code was pretty much all the code left in the mach-sunxi directory for all the SoCs but the A31, the only thing left into mach-sunxi are empty machine definition. Thanks, Maxime Maxime Ripard (6): wdt: sunxi: Move restart code to the watchdog driver power: reset: Add Allwinner A31 reset code ARM: sunxi: Remove reset code from the platform ARM: sunxi: Remove init_machine callback ARM: sunxi: Add A31 reset driver to sunxi_defconfig ARM: multi_v7: Add Allwinner reset drivers to multi_v7_defconfig arch/arm/configs/multi_v7_defconfig | 2 + arch/arm/configs/sunxi_defconfig| 3 + arch/arm/mach-sunxi/sunxi.c | 107 drivers/power/reset/Kconfig | 7 +++ drivers/power/reset/Makefile| 1 + drivers/power/reset/sun6i-reboot.c | 85 drivers/watchdog/sunxi_wdt.c| 29 ++ 7 files changed, 127 insertions(+), 107 deletions(-) create mode 100644 drivers/power/reset/sun6i-reboot.c -- 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] ACPI / AC: Introduce the use of the managed version of kzalloc
2014-05-04 20:35 GMT+08:00 Himangi Saraogi :
> This patch moves data allocated using kzalloc to managed data allocated
> using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> functions.
Acked-by: Lan Tianyu
>
> The following Coccinelle semantic patch was used for making the change:
> @platform@
> identifier p, probefn, removefn;
> @@
> struct platform_driver p = {
> .probe = probefn,
> .remove = removefn,
> };
>
> @prb@
> identifier platform.probefn, pdev;
> expression e, e1, e2;
> @@
> probefn(struct platform_device *pdev, ...) {
> <+...
> - e = kzalloc(e1, e2)
> + e = devm_kzalloc(>dev, e1, e2)
> ...
> ?-kfree(e);
> ...+>
> }
>
> @rem depends on prb@
> identifier platform.removefn;
> expression e;
> @@
> removefn(...) {
> <...
> - kfree(e);
> ...>
> }
>
> Signed-off-by: Himangi Saraogi
> ---
> drivers/acpi/ac.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
> index 2c01c1d..98b613a 100644
> --- a/drivers/acpi/ac.c
> +++ b/drivers/acpi/ac.c
> @@ -205,7 +205,7 @@ static int acpi_ac_probe(struct platform_device *pdev)
> if (!adev)
> return -ENODEV;
>
> - ac = kzalloc(sizeof(struct acpi_ac), GFP_KERNEL);
> + ac = devm_kzalloc(>dev, sizeof(struct acpi_ac), GFP_KERNEL);
> if (!ac)
> return -ENOMEM;
>
> @@ -240,9 +240,6 @@ static int acpi_ac_probe(struct platform_device *pdev)
> ac->battery_nb.notifier_call = acpi_ac_battery_notify;
> register_acpi_notifier(>battery_nb);
> end:
> - if (result)
> - kfree(ac);
> -
> dmi_check_system(ac_dmi_table);
> return result;
> }
> @@ -287,8 +284,6 @@ static int acpi_ac_remove(struct platform_device *pdev)
> power_supply_unregister(>charger);
> unregister_acpi_notifier(>battery_nb);
>
> - kfree(ac);
> -
> return 0;
> }
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best regards
Tianyu Lan
--
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/6] wdt: sunxi: Move restart code to the watchdog driver
Most of the watchdog code is duplicated between the machine restart code and
the watchdog driver. Add the restart hook to the watchdog driver, to be able to
remove it from the machine code eventually.
Signed-off-by: Maxime Ripard
Acked-by: Arnd Bergmann
---
drivers/watchdog/sunxi_wdt.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
index cd00a7836cdc..0d07855bc88a 100644
--- a/drivers/watchdog/sunxi_wdt.c
+++ b/drivers/watchdog/sunxi_wdt.c
@@ -14,6 +14,7 @@
*/
#include
+#include
#include
#include
#include
@@ -22,9 +23,12 @@
#include
#include
#include
+#include
#include
#include
+#include
+
#define WDT_MAX_TIMEOUT 16
#define WDT_MIN_TIMEOUT 1
#define WDT_MODE_TIMEOUT(n) ((n) << 3)
@@ -70,6 +74,26 @@ static const int wdt_timeout_map[] = {
[16] = 0b1011, /* 16s */
};
+static void __iomem *reboot_wdt_base;
+
+static void sun4i_wdt_restart(enum reboot_mode mode, const char *cmd)
+{
+ /* Enable timer and set reset bit in the watchdog */
+ writel(WDT_MODE_EN | WDT_MODE_RST_EN, reboot_wdt_base + WDT_MODE);
+
+ /*
+* Restart the watchdog. The default (and lowest) interval
+* value for the watchdog is 0.5s.
+*/
+ writel(WDT_CTRL_RELOAD, reboot_wdt_base + WDT_CTRL);
+
+ while (1) {
+ mdelay(5);
+ writel(WDT_MODE_EN | WDT_MODE_RST_EN,
+ reboot_wdt_base + WDT_MODE);
+ }
+}
+
static int sunxi_wdt_ping(struct watchdog_device *wdt_dev)
{
struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
@@ -181,6 +205,9 @@ static int sunxi_wdt_probe(struct platform_device *pdev)
if (unlikely(err))
return err;
+ reboot_wdt_base = sunxi_wdt->wdt_base;
+ arm_pm_restart = sun4i_wdt_restart;
+
dev_info(>dev, "Watchdog enabled (timeout=%d sec, nowayout=%d)",
sunxi_wdt->wdt_dev.timeout, nowayout);
@@ -191,6 +218,8 @@ static int sunxi_wdt_remove(struct platform_device *pdev)
{
struct sunxi_wdt_dev *sunxi_wdt = platform_get_drvdata(pdev);
+ arm_pm_restart = NULL;
+
watchdog_unregister_device(_wdt->wdt_dev);
watchdog_set_drvdata(_wdt->wdt_dev, NULL);
--
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 5/6] ARM: sunxi: Add A31 reset driver to sunxi_defconfig
Now that the A31 reset code is a driver of its own, we need it in the defconfig. Signed-off-by: Maxime Ripard --- arch/arm/configs/sunxi_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig index 81ba78eaf54a..e0c91b23fde7 100644 --- a/arch/arm/configs/sunxi_defconfig +++ b/arch/arm/configs/sunxi_defconfig @@ -52,6 +52,9 @@ CONFIG_I2C_MV64XXX=y CONFIG_SPI=y CONFIG_SPI_SUN6I=y CONFIG_GPIO_SYSFS=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_SUN6I=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_SUNXI_WATCHDOG=y -- 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: [ANNOUNCE] 3.14.2-rt3
On Sat, 2014-05-03 at 19:01 +0200, Sebastian Andrzej Siewior wrote: > - Mike Galbraith sent a patch which might fix lazy preempt on x86_64. > Patch applied and my machine still explodes therefore lazy preempt > remains off on x86_64. Can you send me your config offline? I'll try to scrape up some cycles to take another peek. It seems to work fine on my boxen, so there must be a config dependent bug somewhere. > - Mike Galbraith sent a few patches to get cpu hoplug to work. This > includes lg_global_trylock_relax(). (applies frozen shark repellent.. liberally) -Mike -- 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/6] ARM: sunxi: Remove reset code from the platform
Now that reset is handled either by the watchdog driver for the sun4i, sun5i
and sun7i, and by a driver of its own for sun6i, we can remove it from the
platform code.
Signed-off-by: Maxime Ripard
Acked-by: Arnd Bergmann
---
arch/arm/mach-sunxi/sunxi.c | 98 -
1 file changed, 98 deletions(-)
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 460b5a4962ef..1c62a0a021d7 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -12,109 +12,14 @@
#include
#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
#include
-#include
-#include
#include "common.h"
-#define SUN4I_WATCHDOG_CTRL_REG0x00
-#define SUN4I_WATCHDOG_CTRL_RESTARTBIT(0)
-#define SUN4I_WATCHDOG_MODE_REG0x04
-#define SUN4I_WATCHDOG_MODE_ENABLE BIT(0)
-#define SUN4I_WATCHDOG_MODE_RESET_ENABLE BIT(1)
-
-#define SUN6I_WATCHDOG1_IRQ_REG0x00
-#define SUN6I_WATCHDOG1_CTRL_REG 0x10
-#define SUN6I_WATCHDOG1_CTRL_RESTART BIT(0)
-#define SUN6I_WATCHDOG1_CONFIG_REG 0x14
-#define SUN6I_WATCHDOG1_CONFIG_RESTART BIT(0)
-#define SUN6I_WATCHDOG1_CONFIG_IRQ BIT(1)
-#define SUN6I_WATCHDOG1_MODE_REG 0x18
-#define SUN6I_WATCHDOG1_MODE_ENABLEBIT(0)
-
-static void __iomem *wdt_base;
-
-static void sun4i_restart(enum reboot_mode mode, const char *cmd)
-{
- if (!wdt_base)
- return;
-
- /* Enable timer and set reset bit in the watchdog */
- writel(SUN4I_WATCHDOG_MODE_ENABLE | SUN4I_WATCHDOG_MODE_RESET_ENABLE,
- wdt_base + SUN4I_WATCHDOG_MODE_REG);
-
- /*
-* Restart the watchdog. The default (and lowest) interval
-* value for the watchdog is 0.5s.
-*/
- writel(SUN4I_WATCHDOG_CTRL_RESTART, wdt_base + SUN4I_WATCHDOG_CTRL_REG);
-
- while (1) {
- mdelay(5);
- writel(SUN4I_WATCHDOG_MODE_ENABLE |
SUN4I_WATCHDOG_MODE_RESET_ENABLE,
- wdt_base + SUN4I_WATCHDOG_MODE_REG);
- }
-}
-
-static void sun6i_restart(enum reboot_mode mode, const char *cmd)
-{
- if (!wdt_base)
- return;
-
- /* Disable interrupts */
- writel(0, wdt_base + SUN6I_WATCHDOG1_IRQ_REG);
-
- /* We want to disable the IRQ and just reset the whole system */
- writel(SUN6I_WATCHDOG1_CONFIG_RESTART,
- wdt_base + SUN6I_WATCHDOG1_CONFIG_REG);
-
- /* Enable timer. The default and lowest interval value is 0.5s */
- writel(SUN6I_WATCHDOG1_MODE_ENABLE,
- wdt_base + SUN6I_WATCHDOG1_MODE_REG);
-
- /* Restart the watchdog. */
- writel(SUN6I_WATCHDOG1_CTRL_RESTART,
- wdt_base + SUN6I_WATCHDOG1_CTRL_REG);
-
- while (1) {
- mdelay(5);
- writel(SUN6I_WATCHDOG1_MODE_ENABLE,
- wdt_base + SUN6I_WATCHDOG1_MODE_REG);
- }
-}
-
-static struct of_device_id sunxi_restart_ids[] = {
- { .compatible = "allwinner,sun4i-a10-wdt" },
- { .compatible = "allwinner,sun6i-a31-wdt" },
- { /*sentinel*/ }
-};
-
-static void sunxi_setup_restart(void)
-{
- struct device_node *np;
-
- np = of_find_matching_node(NULL, sunxi_restart_ids);
- if (WARN(!np, "unable to setup watchdog restart"))
- return;
-
- wdt_base = of_iomap(np, 0);
- WARN(!wdt_base, "failed to map watchdog base address");
-}
-
static void __init sunxi_dt_init(void)
{
- sunxi_setup_restart();
-
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
@@ -128,7 +33,6 @@ static const char * const sunxi_board_dt_compat[] = {
DT_MACHINE_START(SUNXI_DT, "Allwinner A1X (Device Tree)")
.init_machine = sunxi_dt_init,
.dt_compat = sunxi_board_dt_compat,
- .restart= sun4i_restart,
MACHINE_END
static const char * const sun6i_board_dt_compat[] = {
@@ -148,7 +52,6 @@ DT_MACHINE_START(SUN6I_DT, "Allwinner sun6i (A31) Family")
.init_machine = sunxi_dt_init,
.init_time = sun6i_timer_init,
.dt_compat = sun6i_board_dt_compat,
- .restart= sun6i_restart,
.smp= smp_ops(sun6i_smp_ops),
MACHINE_END
@@ -160,5 +63,4 @@ static const char * const sun7i_board_dt_compat[] = {
DT_MACHINE_START(SUN7I_DT, "Allwinner sun7i (A20) Family")
.init_machine = sunxi_dt_init,
.dt_compat = sun7i_board_dt_compat,
- .restart= sun4i_restart,
MACHINE_END
--
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 2/6] power: reset: Add Allwinner A31 reset code
That code used to be in the machine code, but it's more fit here with other
restart hooks.
That will allow to cleanup the machine directory, while waiting for a proper
watchdog driver for the A31.
Signed-off-by: Maxime Ripard
Acked-by: Arnd Bergmann
---
drivers/power/reset/Kconfig| 7
drivers/power/reset/Makefile | 1 +
drivers/power/reset/sun6i-reboot.c | 85 ++
3 files changed, 93 insertions(+)
create mode 100644 drivers/power/reset/sun6i-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index fa0e4e057b99..67aeb6ec08f9 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -43,6 +43,13 @@ config POWER_RESET_RESTART
Instead they restart, and u-boot holds the SoC until the
user presses a key. u-boot then boots into Linux.
+config POWER_RESET_SUN6I
+ bool "Allwinner A31 SoC reset driver"
+ depends on ARCH_SUNXI
+ depends on POWER_RESET
+ help
+ Reboot support for the Allwinner A31 SoCs.
+
config POWER_RESET_VEXPRESS
bool "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a5b4a77d1a41..950fdc011c7a 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -3,5 +3,6 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
+obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
diff --git a/drivers/power/reset/sun6i-reboot.c
b/drivers/power/reset/sun6i-reboot.c
new file mode 100644
index ..af2cd7ff2fe8
--- /dev/null
+++ b/drivers/power/reset/sun6i-reboot.c
@@ -0,0 +1,85 @@
+/*
+ * Allwinner A31 SoCs reset code
+ *
+ * Copyright (C) 2012-2014 Maxime Ripard
+ *
+ * Maxime Ripard
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define SUN6I_WATCHDOG1_IRQ_REG0x00
+#define SUN6I_WATCHDOG1_CTRL_REG 0x10
+#define SUN6I_WATCHDOG1_CTRL_RESTART BIT(0)
+#define SUN6I_WATCHDOG1_CONFIG_REG 0x14
+#define SUN6I_WATCHDOG1_CONFIG_RESTART BIT(0)
+#define SUN6I_WATCHDOG1_CONFIG_IRQ BIT(1)
+#define SUN6I_WATCHDOG1_MODE_REG 0x18
+#define SUN6I_WATCHDOG1_MODE_ENABLEBIT(0)
+
+static void __iomem *wdt_base;
+
+static void sun6i_wdt_restart(enum reboot_mode mode, const char *cmd)
+{
+ if (!wdt_base)
+ return;
+
+ /* Disable interrupts */
+ writel(0, wdt_base + SUN6I_WATCHDOG1_IRQ_REG);
+
+ /* We want to disable the IRQ and just reset the whole system */
+ writel(SUN6I_WATCHDOG1_CONFIG_RESTART,
+ wdt_base + SUN6I_WATCHDOG1_CONFIG_REG);
+
+ /* Enable timer. The default and lowest interval value is 0.5s */
+ writel(SUN6I_WATCHDOG1_MODE_ENABLE,
+ wdt_base + SUN6I_WATCHDOG1_MODE_REG);
+
+ /* Restart the watchdog. */
+ writel(SUN6I_WATCHDOG1_CTRL_RESTART,
+ wdt_base + SUN6I_WATCHDOG1_CTRL_REG);
+
+ while (1) {
+ mdelay(5);
+ writel(SUN6I_WATCHDOG1_MODE_ENABLE,
+ wdt_base + SUN6I_WATCHDOG1_MODE_REG);
+ }
+}
+
+static int sun6i_reboot_probe(struct platform_device *pdev)
+{
+ wdt_base = of_iomap(pdev->dev.of_node, 0);
+ if (!wdt_base) {
+ WARN(1, "failed to map watchdog base address");
+ return -ENODEV;
+ }
+
+ arm_pm_restart = sun6i_wdt_restart;
+
+ return 0;
+}
+
+static struct of_device_id sun6i_reboot_of_match[] = {
+ { .compatible = "allwinner,sun6i-a31-wdt" },
+ {}
+};
+
+static struct platform_driver sun6i_reboot_driver = {
+ .probe = sun6i_reboot_probe,
+ .driver = {
+ .name = "sun6i-reboot",
+ .of_match_table = sun6i_reboot_of_match,
+ },
+};
+module_platform_driver(sun6i_reboot_driver);
--
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 6/6] ARM: multi_v7: Add Allwinner reset drivers to multi_v7_defconfig
Now that the reset code are part of drivers of their own, we need those in the defconfig. Signed-off-by: Maxime Ripard --- arch/arm/configs/multi_v7_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index d4e8a47a2f7c..960187ac35e0 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -200,12 +200,14 @@ CONFIG_BATTERY_SBS=y CONFIG_CHARGER_TPS65090=y CONFIG_POWER_RESET_AS3722=y CONFIG_POWER_RESET_GPIO=y +CONFIG_POWER_RESET_SUN6I=y CONFIG_SENSORS_LM90=y CONFIG_THERMAL=y CONFIG_DOVE_THERMAL=y CONFIG_ARMADA_THERMAL=y CONFIG_WATCHDOG=y CONFIG_ORION_WATCHDOG=y +CONFIG_SUNXI_WATCHDOG=y CONFIG_MFD_AS3722=y CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_SPI=y -- 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 4/6] ARM: sunxi: Remove init_machine callback
The init_machine hook is now at its default value. We can remove it.
Even though the sun4i and sun7i machines are nothing more than generic machines
now, leave them in so that we won't have to add them back if needed, and so
that the machine is still displayed in /proc/cpuinfo.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-sunxi/sunxi.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 1c62a0a021d7..efb2f93b02e6 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -12,17 +12,11 @@
#include
#include
-#include
#include
#include "common.h"
-static void __init sunxi_dt_init(void)
-{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
static const char * const sunxi_board_dt_compat[] = {
"allwinner,sun4i-a10",
"allwinner,sun5i-a10s",
@@ -31,7 +25,6 @@ static const char * const sunxi_board_dt_compat[] = {
};
DT_MACHINE_START(SUNXI_DT, "Allwinner A1X (Device Tree)")
- .init_machine = sunxi_dt_init,
.dt_compat = sunxi_board_dt_compat,
MACHINE_END
@@ -49,7 +42,6 @@ static void __init sun6i_timer_init(void)
}
DT_MACHINE_START(SUN6I_DT, "Allwinner sun6i (A31) Family")
- .init_machine = sunxi_dt_init,
.init_time = sun6i_timer_init,
.dt_compat = sun6i_board_dt_compat,
.smp= smp_ops(sun6i_smp_ops),
@@ -61,6 +53,5 @@ static const char * const sun7i_board_dt_compat[] = {
};
DT_MACHINE_START(SUN7I_DT, "Allwinner sun7i (A20) Family")
- .init_machine = sunxi_dt_init,
.dt_compat = sun7i_board_dt_compat,
MACHINE_END
--
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] drivercore: fix a corner case for deferred probe
On Mon, May 05, 2014 at 10:28:05AM +0800, Wei Yang wrote: > Hi, all > > Anyone has some comment on this? Did you miss the patch from Grant that is now in Linus's tree that should resolve this issue? thanks, greg k-h -- 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.15-rc4
Nothing particularly unusual going on. 45% drivers (drm, sound, md, pin-control, acpi etc), 40% arch (mainly powerpc/powernv, but x86 and arm too), 15% misc (perf tooling, documentation updates, core code). The appended shortlog gives some kind of overview of the details without being _too_ big. There's a few known things pending still (pending fix for some interesting dentry list corruption, for example - not that any remotely normal use will likely ever hit it), but on the whole things are fairly calm and nothing horribly scary. We're in the middle of the calming-down period, so that's just how I like it. But the more testing we get, the better, so please do give this a whirl, Linus --- Alexander Gordeev (1): kvm: Use pci_enable_msix_exact() instead of pci_enable_msix() Alexander Shiyan (1): clocksource: nspire: Fix compiler warning Alexandre Belloni (1): ASoC: tlv320aic31xx: document that the regulators are mandatory Alistair Popple (1): powerpc/4xx: Fix section mismatch in ppc4xx_pci.c Anatol Pomozov (1): aio: block io_destroy() until all context requests are completed Andre Przywara (1): KVM: arm/arm64: vgic: fix GICD_ICFGR register accesses Andrew Bresticker (1): pinctrl: as3722: fix handling of GPIO invert bit Andrew Lunn (1): ASoC: alc5623: Fix regmap endianness Andrzej Hajda (1): drm/exynos: balance framebuffer refcount Aneesh Kumar K.V (1): powerpc/mm: Fix tlbie to add AVAL fields for 64K pages Anton Blanchard (11): powerpc/powernv: Fix little endian issues in OPAL flash code powerpc/powernv: Use uint64_t instead of size_t in OPAL APIs powerpc/powernv: Remove some OPAL function declaration duplication powerpc/powernv: Fix little endian issues with opal_do_notifier calls powerpc/powernv: Fix little endian issues in OPAL error log code powerpc/powernv: Create OPAL sglist helper functions and fix endian issues powerpc/powernv: Fix little endian issues in OPAL dump code powerpc: Rename duplicate COMMAND_LINE_SIZE define powerpc: Bump COMMAND_LINE_SIZE to 2048 powerpc: Bump BOOT_COMMAND_LINE_SIZE to 2048 powerpc: Fix error return in rtas_flash module init Axel Lin (2): ASoC: cs42l52: Convert to use devm_gpio_request_one ASoC: cs42l73: Convert to use devm_gpio_request_one Bandan Das (1): KVM: x86: Check for host supported fields in shadow vmcs Behan Webster (1): x86: LLVMLinux: Wrap -mno-80387 with cc-option Ben Dooks (1): ASoC: rsnd: fix clock prepare/unprepare Ben Widawsky (1): drm/i915: Allow full PPGTT with param override Benjamin Herrenschmidt (1): powerpc/powernv: Fix kexec races going back to OPAL Bjorn Helgaas (1): PNP: Fix compile error in quirks.c Catalin Marinas (3): arm64: Use bus notifiers to set per-device coherent DMA ops arm64: Mark the Applied Micro X-Gene SATA controller as DMA coherent vexpress: Initialise the sysregs before setting up the clocks Chris Wilson (2): drm/i915: Discard BIOS framebuffers too small to accommodate chosen mode drm/i915: Move all ring resets before setting the HWS page Christian Engelmayer (1): ASoC: Intel: Fix incorrect sizeof() in sst_hsw_stream_get_volume() Christian Ruppert (1): pinctrl/TB10x: Fix signedness bug Cody P Schafer (6): powerpc/perf/hv_24x7: Probe errors changed to pr_debug(), padding fixed powerpc/perf/hv_gpci: Probe failures use pr_debug(), and padding reduced powerpc/perf/hv-gpci: Make device attr static powerpc/perf/hv-24x7: Use (unsigned long) not (u32) values when calling plpar_hcall_norets() powerpc/perf/hv-24x7: Remove [static 4096], sparse chokes on it powerpc/perf/hv-24x7: Catalog version number is be64, not be32 Dan Carpenter (2): ASoC: Intel: some incorrect sizeof() usages irqchip: irq-crossbar: Not allocating enough memory Daniel Vetter (3): drm/i915: Don't check gmch state on inherited configs drm/tegra: restrict plane loops to legacy planes drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch platforms Dave Anderson (1): arm64: Fix for the arm64 kern_addr_valid() function Fam Zheng (1): [SCSI] virtio-scsi: Skip setting affinity on uninitialized vq Geert Uytterhoeven (1): dt: Fix binding typos in clock-names and interrupt-names Grant Likely (1): drivercore: deferral race condition fix Guenter Roeck (1): Revert "hwmon: (coretemp) Refine TjMax detection" Guido Piasenza (1): sh-pfc: r8a7790: Fix definition of IPSR5 H. Peter Anvin (1): word-at-a-time: simplify big-endian zero_bytemask macro Haibin Wang (2): KVM: ARM: vgic: Fix sgi dispatch problem KVM: ARM: vgic: Fix the overlap check action about setting the GICD & GICC base address. Hariprasad S (1): RDMA/cxgb4: Update Kconfig to include Chelsio T5 adapter Helge Deller (1):
Re: [PATCH] drivercore: fix a corner case for deferred probe
Hi, all
Anyone has some comment on this?
On Mon, Apr 21, 2014 at 09:53:22AM +0800, Wei Yang wrote:
>There is one corner case in deferred probe which will lead a device in
>"dream" in the deferred_probe_pending_list.
>
>Suppose we have three devices, Tom, Jerry and Spike. Tom and Jerry have a
>close relationship, Tom could be up until Jerry is up. Spike is an
>independent device.
>
>Device probe sequence: Tom -> Spike -> Jerry
>
>1. Tom probes, fails for deferred probe
> adds itself to pending list
>2. Spike probes, succeed
> move devices in pending list to active list
> trigger deferred probe
>3. Tom is taken off from active list
> probes and still fails, scheduled out
> not added to pending list this time
> (Tom is not in pending list neither in active list)
>4. Jerry probes, succeed
> move devices in pending list to active list(but Tom is not there)
> trigger deferred probe
> go through the active list
>5. Tom add itself to pending list
> and wait
>
>Tom will be trapped in the pending list until someone else help it out.
>
>This patch adds a counter of success probe. Every time a driver probe succeeds,
>this is increased by 1. In the deferred_probe_work_func, when probe fails and
>returns EPROBE_DEFER, it checks this counter. If some driver succeed to probe
>during this period, it adds itself to active list again.
>
>Signed-off-by: Wei Yang
>---
> drivers/base/base.h |2 +-
> drivers/base/bus.c |3 ++-
> drivers/base/dd.c | 14 +-
> 3 files changed, 16 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/base/base.h b/drivers/base/base.h
>index 24f4242..6315207 100644
>--- a/drivers/base/base.h
>+++ b/drivers/base/base.h
>@@ -105,7 +105,7 @@ extern void container_dev_init(void);
> struct kobject *virtual_device_parent(struct device *dev);
>
> extern int bus_add_device(struct device *dev);
>-extern void bus_probe_device(struct device *dev);
>+extern int bus_probe_device(struct device *dev);
> extern void bus_remove_device(struct device *dev);
>
> extern int bus_add_driver(struct device_driver *drv);
>diff --git a/drivers/base/bus.c b/drivers/base/bus.c
>index 59dc808..a050946 100644
>--- a/drivers/base/bus.c
>+++ b/drivers/base/bus.c
>@@ -543,7 +543,7 @@ out_put:
> *
> * - Automatically probe for a driver if the bus allows it.
> */
>-void bus_probe_device(struct device *dev)
>+int bus_probe_device(struct device *dev)
> {
> struct bus_type *bus = dev->bus;
> struct subsys_interface *sif;
>@@ -562,6 +562,7 @@ void bus_probe_device(struct device *dev)
> if (sif->add_dev)
> sif->add_dev(dev, sif);
> mutex_unlock(>p->mutex);
>+ return ret;
> }
>
> /**
>diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>index 0605176..a10526d 100644
>--- a/drivers/base/dd.c
>+++ b/drivers/base/dd.c
>@@ -52,6 +52,7 @@ static DEFINE_MUTEX(deferred_probe_mutex);
> static LIST_HEAD(deferred_probe_pending_list);
> static LIST_HEAD(deferred_probe_active_list);
> static struct workqueue_struct *deferred_wq;
>+static u32 success_probe;
>
> /**
> * deferred_probe_work_func() - Retry probing devices in the active list.
>@@ -60,6 +61,8 @@ static void deferred_probe_work_func(struct work_struct
>*work)
> {
> struct device *dev;
> struct device_private *private;
>+ u32 old_success;
>+ int ret = 0;
> /*
>* This block processes every device in the deferred 'active' list.
>* Each device is removed from the active list and passed to
>@@ -80,6 +83,7 @@ static void deferred_probe_work_func(struct work_struct
>*work)
> list_del_init(>deferred_probe);
>
> get_device(dev);
>+ old_success = ACCESS_ONCE(success_probe);
>
> /*
>* Drop the mutex while probing each device; the probe path may
>@@ -98,7 +102,14 @@ static void deferred_probe_work_func(struct work_struct
>*work)
> device_pm_unlock();
>
> dev_dbg(dev, "Retrying from deferred list\n");
>- bus_probe_device(dev);
>+ ret = bus_probe_device(dev);
>+ if (ret == -EPROBE_DEFER) {
>+ mutex_lock(_probe_mutex);
>+ if (old_success != success_probe)
>+ list_move(>deferred_probe,
>+_probe_active_list);
>+ mutex_unlock(_probe_mutex);
>+ }
>
> mutex_lock(_probe_mutex);
>
>@@ -147,6 +158,7 @@ static void driver_deferred_probe_trigger(void)
>* into the active list so they can be retried by the workqueue
>*/
> mutex_lock(_probe_mutex);
>+ success_probe++;
> list_splice_tail_init(_probe_pending_list,
> _probe_active_list);
> mutex_unlock(_probe_mutex);
>--
>1.7.9.5
--
Richard Yang
Help you, Help me
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline
Andrew Morton writes:
> On Mon, 07 Apr 2014 14:24:45 +0930 Rusty Russell
> wrote:
>
>> Subject: param: hand arguments after -- straight to init
>>
>> The kernel passes any args it doesn't need through to init, except it
>> assumes anything containing '.' belongs to the kernel (for a module).
>> This change means all users can clearly distinguish which arguments
>> are for init.
>>
>> For example, the kernel uses debug ("dee-bug") to mean log everything to
>> the console, where systemd uses the debug from the Scandinavian "day-boog"
>> meaning "fail to boot". If a future versions uses argv[] instead of
>> reading /proc/cmdline, this confusion will be avoided.
>>
>> eg: test 'FOO="this is --foo"' -- 'systemd.debug="true true true"'
>>
>> Gives:
>> argv[0] = '/debug-init'
>> argv[1] = 'test'
>> argv[2] = 'systemd.debug=true true true'
>> envp[0] = 'HOME=/'
>> envp[1] = 'TERM=linux'
>> envp[2] = 'FOO=this is --foo'
>
> This (user-facing) feature doesn't seem to have been documented
> anywhere. Documentation/kernel-parameters.txt, I guess.
That document does need some love. How's this?
1) __setup() is messy, prefer module_param and core_param.
2) Document --
3) Document modprobe scraping /proc/cmdline.
4) Document handing of leftover parameters to init.
5) Document use of quotes to protect whitespace.
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 43842177b771..56a4c2d0c741 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1,27 +1,37 @@
Kernel Parameters
~
-The following is a consolidated list of the kernel parameters as implemented
-(mostly) by the __setup() macro and sorted into English Dictionary order
-(defined as ignoring all punctuation and sorting digits before letters in a
-case insensitive manner), and with descriptions where known.
-
-Module parameters for loadable modules are specified only as the
-parameter name with optional '=' and value as appropriate, such as:
-
- modprobe usbcore blinkenlights=1
-
-Module parameters for modules that are built into the kernel image
-are specified on the kernel command line with the module name plus
-'.' plus parameter name, with '=' and value if appropriate, such as:
-
- usbcore.blinkenlights=1
+The following is a consolidated list of the kernel parameters as
+implemented by the __setup(), core_param() and module_param() macros
+and sorted into English Dictionary order (defined as ignoring all
+punctuation and sorting digits before letters in a case insensitive
+manner), and with descriptions where known.
+
+The kernel parses parameters from the kernel command line up to "--";
+if it doesn't recognize a parameter and it doesn't contain a '.', the
+parameter gets passed to init: parameters with '=' go into init's
+environment, others are passed as command line arguments to init.
+Everything after "--" is passed as an argument to init.
+
+Module parameters can be specified in two ways: via the kernel command
+line with a module name prefix, or via modprobe, eg:
+
+ (kernel command line) usbcore.blinkenlights=1
+ (modprobe command line) modprobe usbcore blinkenlights=1
+
+Parameters for modules which are built into the kernel need to be
+specified on the kernel command line. modprobe looks through the
+kernel command line (/proc/cmdline) and collects module parameters
+when it loads a module, so the kernel command line can be used for
+loadable modules too.
Hyphens (dashes) and underscores are equivalent in parameter names, so
log_buf_len=1M print-fatal-signals=1
can also be entered as
log-buf-len=1M print_fatal_signals=1
+Double-quotes can be used to protect spaces in values, eg:
+ param="spaces in here"
This document may not be entirely up to date and comprehensive. The command
"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
--
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 7/9] drivers/hid/hid-picolcd_fb: avoid world-writable sysfs files.
Bruno Prémont writes: > On Tue, 22 April 2014 Rusty Russell wrote: >> In line with practice for module parameters, we're adding a build-time >> check that sysfs files aren't world-writable. >> >> Cc: Bruno Prémont >> Signed-off-by: Rusty Russell > > Fine with me, > Acked-by: Bruno Prémont > > Not sure which tree you plan to push this through, CCing Jiri > as all picoLCD driver went in via HID tree. Currently plan is that they'll go through my modules-next tree (which is where this patch originated). Thanks, Rusty. -- 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-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got conflicts in
net/sched/sch_api.c and net/sched/cls_api.c between commit 90f62cf30a78
("net: Use netlink_ns_capable to verify the permisions of netlink
messages") from the net tree and commit 4e8bbb819d15 ("net: Allow tc
changes in user namespaces") from the net-next tree.
I fixed it up (hopefully, see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwell
diff --cc net/sched/cls_api.c
index bdbdb1a7920a,1a4a20267787..
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@@ -134,7 -134,8 +134,8 @@@ static int tc_ctl_tfilter(struct sk_buf
int err;
int tp_created = 0;
- if ((n->nlmsg_type != RTM_GETTFILTER) && !netlink_capable(skb,
CAP_NET_ADMIN))
+ if ((n->nlmsg_type != RTM_GETTFILTER) &&
- !ns_capable(net->user_ns, CAP_NET_ADMIN))
++ !netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))
return -EPERM;
replay:
diff --cc net/sched/sch_api.c
index 400769014bbd,86f8edfd6b8a..
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@@ -1084,7 -1084,8 +1084,8 @@@ static int tc_get_qdisc(struct sk_buff
struct Qdisc *p = NULL;
int err;
- if ((n->nlmsg_type != RTM_GETQDISC) && !netlink_capable(skb,
CAP_NET_ADMIN))
+ if ((n->nlmsg_type != RTM_GETQDISC) &&
- !ns_capable(net->user_ns, CAP_NET_ADMIN))
++ !netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))
return -EPERM;
err = nlmsg_parse(n, sizeof(*tcm), tca, TCA_MAX, NULL);
@@@ -1151,7 -1152,7 +1152,7 @@@ static int tc_modify_qdisc(struct sk_bu
struct Qdisc *q, *p;
int err;
- if (!netlink_capable(skb, CAP_NET_ADMIN))
- if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
++ if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))
return -EPERM;
replay:
@@@ -1490,7 -1491,8 +1491,8 @@@ static int tc_ctl_tclass(struct sk_buf
u32 qid;
int err;
- if ((n->nlmsg_type != RTM_GETTCLASS) && !netlink_capable(skb,
CAP_NET_ADMIN))
+ if ((n->nlmsg_type != RTM_GETTCLASS) &&
- !ns_capable(net->user_ns, CAP_NET_ADMIN))
++ !netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))
return -EPERM;
err = nlmsg_parse(n, sizeof(*tcm), tca, TCA_MAX, NULL);
pgpaxauayt9VT.pgp
Description: PGP signature
Re: [PATCH v2 08/12] ARM: marvell: add MTD_SPI_NOR (new dependency for M25P80)
On Wed, Apr 30, 2014 at 11:26:43PM -0700, Brian Norris wrote: > These defconfigs contain the CONFIG_M25P80 symbol, which is now > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to satisfy > the new dependency. > > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol. > > Signed-off-by: Brian Norris > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Sebastian Hesselbarth > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > Acked-by: Jason Cooper > --- > arch/arm/configs/dove_defconfig | 2 +- > arch/arm/configs/kirkwood_defconfig | 1 + > arch/arm/configs/mvebu_v5_defconfig | 1 + > arch/arm/configs/mvebu_v7_defconfig | 1 + > 4 files changed, 4 insertions(+), 1 deletion(-) Applied to mvebu/defconfig with Ezequiel's Ack, and a reworded subject: "ARM: mvebu: defconfig: add MTD_SPI_NOR (new dependency for M25P80)" thx, Jason. -- 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 02/15] ARM: dts: kirkwood: add node labels
On Wed, Apr 30, 2014 at 02:56:29PM +0200, Sebastian Hesselbarth wrote: > This adds missing node labels to Kirkwood common and SoC specific nodes > to allow to reference them more easily. > > Signed-off-by: Sebastian Hesselbarth > --- > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Ian Campbell > Cc: Kumar Gala > Cc: Russell King > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Gregory Clement > Cc: Thomas Petazzoni > Cc: devicet...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/boot/dts/kirkwood-6192.dtsi | 10 +- > arch/arm/boot/dts/kirkwood-6281.dtsi | 10 +- > arch/arm/boot/dts/kirkwood-6282.dtsi | 16 > arch/arm/boot/dts/kirkwood.dtsi | 16 > 4 files changed, 26 insertions(+), 26 deletions(-) Patches 2 through 15 applied to mvebu/dt with Andrew's Ack. thx, Jason. -- 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/
[tip:x86/x32] x86, x32: Use compat shims for io_{setup,submit}
Commit-ID: 7fd44dacdd803c0bbf38bf478d51d280902bb0f1
Gitweb: http://git.kernel.org/tip/7fd44dacdd803c0bbf38bf478d51d280902bb0f1
Author: Mike Frysinger
AuthorDate: Sun, 4 May 2014 20:43:15 -0400
Committer: H. Peter Anvin
CommitDate: Sun, 4 May 2014 17:49:22 -0700
x86, x32: Use compat shims for io_{setup,submit}
The io_setup takes a pointer to a context id of type aio_context_t.
This in turn is typed to a __kernel_ulong_t. We could tweak the
exported headers to define this as a 64bit quantity for specific
ABIs, but since we already have a 32bit compat shim for the x86 ABI,
let's just re-use that logic. The libaio package is also written to
expect this as a pointer type, so a compat shim would simplify that.
The io_submit func operates on an array of pointers to iocb structs.
Padding out the array to be 64bit aligned is a huge pain, so convert
it over to the existing compat shim too.
We don't convert io_getevents to the compat func as its only purpose
is to handle the timespec struct, and the x32 ABI uses 64bit times.
With this change, the libaio package can now pass its testsuite when
built for the x32 ABI.
Signed-off-by: Mike Frysinger
Link:
http://lkml.kernel.org/r/1399250595-5005-1-git-send-email-vap...@gentoo.org
Cc: H.J. Lu
Signed-off-by: H. Peter Anvin
Cc: # v3.4+
---
arch/x86/syscalls/syscall_64.tbl | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
index 04376ac..ec255a1 100644
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@ -212,10 +212,10 @@
203common sched_setaffinity sys_sched_setaffinity
204common sched_getaffinity sys_sched_getaffinity
20564 set_thread_area
-206common io_setupsys_io_setup
+20664 io_setupsys_io_setup
207common io_destroy sys_io_destroy
208common io_geteventssys_io_getevents
-209common io_submit sys_io_submit
+20964 io_submit sys_io_submit
210common io_cancel sys_io_cancel
21164 get_thread_area
212common lookup_dcookie sys_lookup_dcookie
@@ -359,3 +359,5 @@
540x32 process_vm_writev compat_sys_process_vm_writev
541x32 setsockopt compat_sys_setsockopt
542x32 getsockopt compat_sys_getsockopt
+543x32 io_setupcompat_sys_io_setup
+544x32 io_submit compat_sys_io_submit
--
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/
tracing: NULL ptr deref in ring_buffer_wait
Hi all, While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the following: [ 3589.386869] BUG: unable to handle kernel NULL pointer dereference at 01f0 [ 3589.389326] IP: __lock_acquire (kernel/locking/lockdep.c:3070 (discriminator 1)) [ 3589.390099] PGD 44bf8067 PUD 392d1067 PMD ac4c2067 PTE 0 [ 3589.390099] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 3589.390099] Dumping ftrace buffer: [ 3589.390099](ftrace buffer empty) [ 3589.390099] Modules linked in: [ 3589.395496] CPU: 37 PID: 28180 Comm: trinity-c168 Not tainted 3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432 [ 3589.396585] task: 8802c77d3000 ti: 88005c9d task.ti: 88005c9d [ 3589.396585] RIP: __lock_acquire (kernel/locking/lockdep.c:3070 (discriminator 1)) [ 3589.396585] RSP: 0018:88005c9d1c18 EFLAGS: 00010002 [ 3589.396585] RAX: 0086 RBX: 8802c77d3000 RCX: [ 3589.396585] RDX: RSI: RDI: 01f0 [ 3589.396585] RBP: 88005c9d1d08 R08: 0001 R09: 0001 [ 3589.396585] R10: 8802c77d3000 R11: 0001 R12: [ 3589.396585] R13: 01f0 R14: R15: [ 3589.396585] FS: 7f1cfe809700() GS:88017ce0() knlGS: [ 3589.407670] CS: 0010 DS: ES: CR0: 8005003b [ 3589.407670] CR2: 01f0 CR3: 5cba3000 CR4: 06a0 [ 3589.407670] DR0: 006de000 DR1: DR2: [ 3589.407670] DR3: DR6: 0ff0 DR7: 0600 [ 3589.407670] Stack: [ 3589.407670] 0025 88017cfd8380 001d8380 0025 [ 3589.407670] 88005c9d1c68 a81a5df8 0002fa098d2fe980 [ 3589.407670] 0002fa098d2fe980 0001 af415f20 00015ee0 [ 3589.407670] Call Trace: [ 3589.407670] ? sched_clock_cpu (kernel/sched/clock.c:311) [ 3589.407670] ? __lock_acquire (kernel/locking/lockdep.c:3189) [ 3589.407670] lock_acquire (arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602) [ 3589.407670] ? prepare_to_wait (kernel/sched/wait.c:177) [ 3589.407670] ? _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:109 kernel/locking/spinlock.c:159) [ 3589.407670] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:117 kernel/locking/spinlock.c:159) [ 3589.407670] ? prepare_to_wait (kernel/sched/wait.c:177) [ 3589.407670] ? get_parent_ip (kernel/sched/core.c:2485) [ 3589.407670] ? mutex_unlock (kernel/locking/mutex.c:220) [ 3589.407670] prepare_to_wait (kernel/sched/wait.c:177) [ 3589.407670] ? __mutex_unlock_slowpath (arch/x86/include/asm/paravirt.h:809 kernel/locking/mutex.c:713 kernel/locking/mutex.c:722) [ 3589.407670] ring_buffer_wait (kernel/trace/ring_buffer.c:587) [ 3589.407670] ? bit_waitqueue (kernel/sched/wait.c:291) [ 3589.407670] wait_on_pipe (kernel/trace/trace.c:1095) [ 3589.407670] tracing_buffers_read (kernel/trace/trace.c:5162) [ 3589.407670] vfs_read (fs/read_write.c:430) [ 3589.407670] SyS_read (fs/read_write.c:568 fs/read_write.c:560) [ 3589.407670] tracesys (arch/x86/kernel/entry_64.S:746) [ 3589.407670] Code: 85 cd 0c 00 00 48 c7 c1 5c e1 6d ac 48 c7 c2 af 89 6d ac 31 c0 be fa 0b 00 00 48 c7 c7 16 e1 6d ac e8 3c 68 f9 ff e9 a7 0c 00 00 <49> 81 7d 00 80 81 76 ae b8 00 00 00 00 44 0f 44 c0 eb 07 0f 1f [ 3589.407670] RIP __lock_acquire (kernel/locking/lockdep.c:3070 (discriminator 1)) [ 3589.407670] RSP [ 3589.407670] CR2: 01f0 Thanks, Sasha -- 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 01/15] ARM: dts: kirkwood: fix mislocated pcie-controller nodes
On Wed, Apr 30, 2014 at 02:56:28PM +0200, Sebastian Hesselbarth wrote:
> Commit 54397d85349f
> ("ARM: kirkwood: Relocate PCIe device tree nodes")
>
> moved the pcie-controller nodes for the Kirkwood SoCs to the mbus
> bus node. For some reason, two boards were not properly converted
> and have their pci-controller nodes still in the ocp bus node.
>
> As the corresponding SoC pcie-controller does not exist anymore,
> it is likely that pcie is broken on those boards since above commit.
> Fix it by moving the pcie related nodes to the correct location.
>
> Signed-off-by: Sebastian Hesselbarth
> ---
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: Russell King
> Cc: Jason Cooper
> Cc: Andrew Lunn
> Cc: Gregory Clement
> Cc: Thomas Petazzoni
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 18 ++
> arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi | 18 ++
> 2 files changed, 20 insertions(+), 16 deletions(-)
Applied to mvebu/dt-fixes with Andrew's Ack and flagged for backporting
to -stable v3.12+
thx,
Jason.
--
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] x32: use compat shims for io_{setup,submit}
The io_setup takes a pointer to a context id of type aio_context_t. This in turn is typed to a __kernel_ulong_t. We could tweak the exported headers to define this as a 64bit quantity for specific ABIs, but since we already have a 32bit compat shim for the x86 ABI, let's just re-use that logic. The libaio package is also written to expect this as a pointer type, so a compat shim would simplify that. The io_submit func operates on an array of pointers to iocb structs. Padding out the array to be 64bit aligned is a huge pain, so convert it over to the existing compat shim too. We don't convert io_getevents to the compat func as its only purpose is to handle the timespec struct, and the x32 ABI uses 64bit times. With this change, the libaio package can now pass its testsuite when built for the x32 ABI. Signed-off-by: Mike Frysinger --- arch/x86/syscalls/syscall_64.tbl | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl index 04376ac..ec255a1 100644 --- a/arch/x86/syscalls/syscall_64.tbl +++ b/arch/x86/syscalls/syscall_64.tbl @@ -212,10 +212,10 @@ 203common sched_setaffinity sys_sched_setaffinity 204common sched_getaffinity sys_sched_getaffinity 20564 set_thread_area -206common io_setupsys_io_setup +20664 io_setupsys_io_setup 207common io_destroy sys_io_destroy 208common io_geteventssys_io_getevents -209common io_submit sys_io_submit +20964 io_submit sys_io_submit 210common io_cancel sys_io_cancel 21164 get_thread_area 212common lookup_dcookie sys_lookup_dcookie @@ -359,3 +359,5 @@ 540x32 process_vm_writev compat_sys_process_vm_writev 541x32 setsockopt compat_sys_setsockopt 542x32 getsockopt compat_sys_getsockopt +543x32 io_setupcompat_sys_io_setup +544x32 io_submit compat_sys_io_submit -- 1.9.2 -- 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 20/27] ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table().
On Saturday, May 03, 2014 08:59:14 AM Josh Boyer wrote:
> On Tue, Apr 29, 2014 at 10:05 PM, Lv Zheng wrote:
> > The commit of back porting Linux XSDT validation mechanism has introduced
> > a regreession:
> > Commit: 671cc68dc61f029d44b43a681356078e02d8dab8
> > Subject: ACPICA: Back port and refine validation of the XSDT root table.
> > There is a pointer still accessed after unmapping.
> >
> > This patch fixes this issue. Lv Zheng.
> >
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911
> > Buglink: https://bugs.archlinux.org/task/39811
> > Signed-off-by: Lv Zheng
> > Reported-and-tested-by: Bruce Chiarelli
> > Reported-and-tested-by: Spyros Stathopoulos
> > Signed-off-by: Bob Moore
> > Cc: # 3.14.x: 671cc68: ACPICA: Back port and
> > refine validation of the XSDT root table.
>
> This patch should get into 3.15-rcX soon. It fixes a known regression
> that prevents booting on machines with AMI firmware, and that is
> present in 3.14 so we need it for stable as well. Rafael?
Lv, is it safe to take this patch alone into 3.15-rc?
Rafael
> > ---
> > drivers/acpi/acpica/tbutils.c |7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
> > index 6c31d77..e1638ad 100644
> > --- a/drivers/acpi/acpica/tbutils.c
> > +++ b/drivers/acpi/acpica/tbutils.c
> > @@ -355,6 +355,7 @@ acpi_status __init
> > acpi_tb_parse_root_table(acpi_physical_address rsdp_address)
> > u32 table_count;
> > struct acpi_table_header *table;
> > acpi_physical_address address;
> > + acpi_physical_address rsdt_address;
> > u32 length;
> > u8 *table_entry;
> > acpi_status status;
> > @@ -383,11 +384,14 @@ acpi_status __init
> > acpi_tb_parse_root_table(acpi_physical_address rsdp_address)
> > * as per the ACPI specification.
> > */
> > address = (acpi_physical_address)
> > rsdp->xsdt_physical_address;
> > + rsdt_address =
> > + (acpi_physical_address) rsdp->rsdt_physical_address;
> > table_entry_size = ACPI_XSDT_ENTRY_SIZE;
> > } else {
> > /* Root table is an RSDT (32-bit physical addresses) */
> >
> > address = (acpi_physical_address)
> > rsdp->rsdt_physical_address;
> > + rsdt_address = address;
> > table_entry_size = ACPI_RSDT_ENTRY_SIZE;
> > }
> >
> > @@ -410,8 +414,7 @@ acpi_status __init
> > acpi_tb_parse_root_table(acpi_physical_address rsdp_address)
> >
> > /* Fall back to the RSDT */
> >
> > - address =
> > - (acpi_physical_address)
> > rsdp->rsdt_physical_address;
> > + address = rsdt_address;
> > table_entry_size = ACPI_RSDT_ENTRY_SIZE;
> > }
> > }
> > --
> > 1.7.10
> >
> > --
> > 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/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] lib: check for strcpy() overflows to fixed length buffers
Hi, > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Thursday, May 01, 2014 4:15 AM > > On Wed, Apr 30, 2014 at 09:49:23PM +0200, Rafael J. Wysocki wrote: > > On Wednesday, April 30, 2014 06:08:44 PM Dan Carpenter wrote: > > > There are sometimes where we know that we are doing an strcpy() into a > > > fixed length buffer. In those cases, we could verify that the strcpy() > > > doesn't overflow. This patch introduces DEBUG_STRICT_SLOW_STRCPY_CHECKS > > > if you want to check for that. The downside is that it makes strcpy > > > slower. > > > > > > I introduced __compiletime_size() to make this work. It returns the > > > size of the destination buffer or zero if the size isn't known. The > > > __compiletime_object_size() is similar but if you pass it a struct > > > member then it returns the size of everything from there to the end of > > > the struct. Another difference is __compiletime_object_size() returns > > > -1 for unknown sizes. > > > > > > If you pass a char pointer to __compiletime_size() then it returns zero. > > > > > > The strcpy() check ignores buffers with just one byte because people > > > often use those for variable length strings at the end of a struct. > > > > > > I have tested this patch lightly and created some bugs for it to detect > > > but I have not detected any real life overflows. > > > > > > Signed-off-by: Dan Carpenter > > > > > > diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h > > > index e863dd5..5e0fc2b 100644 > > > --- a/include/acpi/platform/acenv.h > > > +++ b/include/acpi/platform/acenv.h > > > > This is an ACPICA header and changes to it need to be submitted to the > > ACPICA > > maintainers (as per MAINTAINERS). We only get ACPICA changes from the > > upstream project (except for really special situations). > > Ok. I should have added Robert and Lv to the CC list. My guess is > that the (void) is needed to avoid compile warnings but it's needed for > us to avoid compile breakage with this change. In normal ACPICA build environment, I didn't suffer from new build errors after deleting this "void". But this might be required by lint users. You can split ACPICA changes into a separate patch so that it could be easily reverted if someone complained. Thanks -Lv > > Anyway, I'll wait for a couple days and resend that bit broken out. > > regards, > dan carpenter > > > > > > @@ -320,7 +320,7 @@ > > > #define ACPI_STRSTR(s1,s2) strstr((s1), (s2)) > > > #define ACPI_STRCHR(s1,c) strchr((s1), (c)) > > > #define ACPI_STRLEN(s) (acpi_size) strlen((s)) > > > -#define ACPI_STRCPY(d,s)(void) strcpy((d), (s)) > > > +#define ACPI_STRCPY(d,s)strcpy((d), (s)) > > > #define ACPI_STRNCPY(d,s,n) (void) strncpy((d), (s), (acpi_size)(n)) > > > #define ACPI_STRNCMP(d,s,n) strncmp((d), (s), (acpi_size)(n)) > > > #define ACPI_STRCMP(d,s)strcmp((d), (s)) > > > > Thanks! > > > > -- > > I speak only for myself. > > Rafael J. Wysocki, Intel Open Source Technology Center. -- 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] sched: idle: Add sched balance option
On Tuesday, April 29, 2014 12:25:39 PM Daniel Lezcano wrote: > On 04/29/2014 01:11 AM, Rafael J. Wysocki wrote: > > On Monday, April 28, 2014 01:07:31 PM Daniel Lezcano wrote: [cut] > > In my opinion it would be much better to have a knob representing the > > current > > relative value of energy to the user (which may depend on things like > > whether > > or not the system is on battery etc) and meaning how far we need to go with > > energy saving efforts. > > > > So if that knob is 0, we'll do things that are known-good for performance. > > If it is 1, we'll do some extra effort to save enery as well possibly at > > a small expense of performance if that's necessary. If it is 100, we'll do > > all we can to save as much energy as possible without caring about > > performance > > at all. > > > > And it doesn't even have to be scheduler-specific, it very well may be > > global. > > That would be very nice but I don't see how we can quantify this energy > and handle that generically from the kernel for all the hardware. > > I am pretty sure we will discover for some kind of hardware a specific > option will consume more power, argh ! energy I mean, than another > hardware because of the architecture. > > From my personal experience, when we are facing this kind of complexity > and heuristic, it is the sign the userspace has some work to do. > > What I am proposing is not in contradiction with your approach, it is > about exporting a lot of knobs to userspace, and the userspace decide > how to map what is '0' <--> '100' regarding these options. Nothing > prevent the different platform to set a default value for these options. Our experience so far, however, is that user space is not really likely to change the default values of such knobs. > From my POV, the cgroup could be a good solution for that for different > reasons. Especially one good reason is we can stick the energy policy > per task instead of the entire system. > > Let's imagine the following scenario: > > An user has a laptop running a mailer looking for the email every 5 > minutes. The system switched to 'power'. The user wants to play a video > game but due to the 'power' policy, the game is not playable so it > forces the policy to 'performance'. All the tasks will use the > 'performance' policy, thus consuming more energy. This isn't all about the given task, but also about devices that are in use while it is being run. For example, to play a game the user would probably like the input subsystem to be more responsive and the screen to be brighter etc. If that is a network game, the network adapter will probably need to work in the "performance" mode too. > If we do per task, the video game will use the 'performance' policy and > the other tasks on the system will use the 'power' policy. The userspace > can take the decision to freeze the application running 'performance' if > we reach a critical battery level. Well, consider task packing in that context and suppose that according to the current policy task packing should be applied to "energy efficient" tasks, but not to "performance" tasks. Now, suppose that there's an "energy efficient" task to run and there's a core occupied by a "performace" task. Should the "energy efficient" task be run on that core or should we find another one for it? Who's more important in that case? > The cgroup is a good framework to do that and gives a lot of flexibility > to userspace. I understood Peter does not like the cgroup but I did not > give up to convince him, the cgroup could be good solution :) Will user space actually use that flexibility? > Looking forward, if the energy policy is tied with the task, in the > future we can normalize the energy consumption and stick to an 'energy > load' per task and reuse the load tracking for energy, do per task > energy accounting, nice per energy, etc ... That can be done, but some parts of the kernel that may benefit from an "energy conservation bias" knob are not tied to any particular task. The block layer may be one example here. > Going back to reality, concretely this sysctl patch did not reach a > consensus. So I will resend the two other patches, hoping the discussion > will lead to an agreement. Well, the discussion so far has been useful to me anyway. :-) Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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] irqchip: orion: reverse irq handling priority
On Mon, Apr 28, 2014 at 11:12:08PM +0200, Sebastian Hesselbarth wrote: > Non-DT irq handlers were working through irq causes from most-significant > to least-significant bit, while DT irqchip driver does it the other way > round. This revealed some more HW issues on Kirkwood peripheral IP, where > spurious sdio irqs can happen although irqs are masked. > > Also, the generated binaries show that original non-DT order compared > to DT order save two instructions for each bit count check: > > irqchip DT order with ffs(): > 60: e3a06001mov r6, #1 > 64: e2643000rsb r3, r4, #0 > 68: e0033004and r3, r3, r4 > 6c: e16f3f13clz r3, r3 > 70: e263301frsb r3, r3, #31 > 74: e1c44316bic r4, r4, r6, lsl r3 > 78: e5971004ldr r1, [r7, #4] > > Original non-DT order with fls(): > 60: e3a07001mov r7, #1 > 64: e16f3f14clz r3, r4 > 68: e263301frsb r3, r3, #31 > 6c: e1c44317bic r4, r4, r7, lsl r3 > 70: e5951004ldr r1, [r5, #4] > > Therefore, reverse irq bit handling back to original order by replacing > ffs() with fls(). > > Signed-off-by: Sebastian Hesselbarth > Acked-by: Jason Cooper > --- > Changelog: > v1->v2: > - reword commit msg to state less number of instructions > > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Gregory Clement > Cc: Thomas Gleixner > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/irqchip/irq-orion.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied to mvebu/irqchip for routing through the tip tree. Tweaked capitalization of subject line to match the other commits in that directory. thx, Jason. -- 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 01/12] cdrom: convert cdinfo to cd_dbg
It's a debugging message, mark it so.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 241 +-
1 file changed, 121 insertions(+), 120 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 8a3aff7..3828c92 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -312,17 +312,17 @@ static const char *mrw_format_status[] = {
static const char *mrw_address_space[] = { "DMA", "GAA" };
-#if (ERRLOGMASK!=CD_NOTHING)
-#define cdinfo(type, fmt, args...) \
+#if (ERRLOGMASK != CD_NOTHING)
+#define cd_dbg(type, fmt, ...) \
do { \
if ((ERRLOGMASK & type) || debug == 1) \
- pr_info(fmt, ##args); \
+ pr_debug(fmt, ##__VA_ARGS__); \
} while (0)
#else
-#define cdinfo(type, fmt, args...) \
+#define cd_dbg(type, fmt, ...) \
do { \
if (0 && (ERRLOGMASK & type) || debug == 1) \
- pr_info(fmt, ##args); \
+ pr_debug(fmt, ##__VA_ARGS__); \
} while (0)
#endif
@@ -395,7 +395,7 @@ int register_cdrom(struct cdrom_device_info *cdi)
struct cdrom_device_ops *cdo = cdi->ops;
int *change_capability = (int *)>capability; /* hack */
- cdinfo(CD_OPEN, "entering register_cdrom\n");
+ cd_dbg(CD_OPEN, "entering register_cdrom\n");
if (cdo->open == NULL || cdo->release == NULL)
return -EINVAL;
@@ -439,7 +439,7 @@ int register_cdrom(struct cdrom_device_info *cdi)
if (!cdo->generic_packet)
cdo->generic_packet = cdrom_dummy_generic_packet;
- cdinfo(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
+ cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
mutex_lock(_mutex);
list_add(>list, _list);
mutex_unlock(_mutex);
@@ -449,7 +449,7 @@ int register_cdrom(struct cdrom_device_info *cdi)
void unregister_cdrom(struct cdrom_device_info *cdi)
{
- cdinfo(CD_OPEN, "entering unregister_cdrom\n");
+ cd_dbg(CD_OPEN, "entering unregister_cdrom\n");
mutex_lock(_mutex);
list_del(>list);
@@ -459,7 +459,7 @@ void unregister_cdrom(struct cdrom_device_info *cdi)
cdi->exit(cdi);
cdi->ops->n_minors--;
- cdinfo(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
+ cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
}
int cdrom_get_media_event(struct cdrom_device_info *cdi,
@@ -839,7 +839,7 @@ static int cdrom_ram_open_write(struct cdrom_device_info
*cdi)
else if (CDF_RWRT == be16_to_cpu(rfd.feature_code))
ret = !rfd.curr;
- cdinfo(CD_OPEN, "can open for random write\n");
+ cd_dbg(CD_OPEN, "can open for random write\n");
return ret;
}
@@ -928,12 +928,12 @@ static void cdrom_dvd_rw_close_write(struct
cdrom_device_info *cdi)
struct packet_command cgc;
if (cdi->mmc3_profile != 0x1a) {
- cdinfo(CD_CLOSE, "%s: No DVD+RW\n", cdi->name);
+ cd_dbg(CD_CLOSE, "%s: No DVD+RW\n", cdi->name);
return;
}
if (!cdi->media_written) {
- cdinfo(CD_CLOSE, "%s: DVD+RW media clean\n", cdi->name);
+ cd_dbg(CD_CLOSE, "%s: DVD+RW media clean\n", cdi->name);
return;
}
@@ -981,7 +981,7 @@ int cdrom_open(struct cdrom_device_info *cdi, struct
block_device *bdev, fmode_t
{
int ret;
- cdinfo(CD_OPEN, "entering cdrom_open\n");
+ cd_dbg(CD_OPEN, "entering cdrom_open\n");
/* open is event synchronization point, check events first */
check_disk_change(bdev);
@@ -1010,13 +1010,13 @@ int cdrom_open(struct cdrom_device_info *cdi, struct
block_device *bdev, fmode_t
if (ret)
goto err;
- cdinfo(CD_OPEN, "Use count for \"/dev/%s\" now %d\n",
- cdi->name, cdi->use_count);
+ cd_dbg(CD_OPEN, "Use count for \"/dev/%s\" now %d\n",
+ cdi->name, cdi->use_count);
return 0;
err_release:
if (CDROM_CAN(CDC_LOCK) && cdi->options & CDO_LOCK) {
cdi->ops->lock_door(cdi, 0);
- cdinfo(CD_OPEN, "door unlocked.\n");
+ cd_dbg(CD_OPEN, "door unlocked\n");
}
cdi->ops->release(cdi);
err:
@@ -1030,21 +1030,21 @@ int open_for_data(struct cdrom_device_info * cdi)
int ret;
struct cdrom_device_ops *cdo = cdi->ops;
tracktype tracks;
- cdinfo(CD_OPEN, "entering open_for_data\n");
+ cd_dbg(CD_OPEN, "entering open_for_data\n");
/* Check if the driver can report drive status. If it can, we
can do clever things. If it can't, well, we at least
[PATCH 02/12] cdrom: Remove unused CHECKAUDIO macro
It's unused, make it disappear.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 3828c92..8eaba53 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -339,9 +339,6 @@ do {
\
a lot of places. This macro makes the code more clear. */
#define CDROM_CAN(type) (cdi->ops->capability & ~cdi->mask & (type))
-/* used in the audio ioctls */
-#define CHECKAUDIO if ((ret=check_for_audio_disc(cdi, cdo))) return ret
-
/*
* Another popular OS uses 7 seconds as the hard timeout for default
* commands, so it is a good choice for us as well.
--
1.8.1.2.459.gbcd45b4.dirty
--
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 06/12] cdrom: Remove unnecessary sanitize_format prototype
It's defined below without being called.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index a570e5f..08abbae 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -337,8 +337,6 @@ do {
\
#define CDROM_DEF_TIMEOUT (7 * HZ)
/* Not-exported routines. */
-static void sanitize_format(union cdrom_addr *addr,
- u_char * curr, u_char requested);
static int mmc_ioctl(struct cdrom_device_info *cdi, unsigned int cmd,
unsigned long arg);
--
1.8.1.2.459.gbcd45b4.dirty
--
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 07/12] cdrom: Move mmc_ioctls above cdrom_ioctl to remove unnecessary prototype
Neaten the spacing too.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 246 +-
1 file changed, 122 insertions(+), 124 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 08abbae..332c3ae 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -337,8 +337,6 @@ do {
\
#define CDROM_DEF_TIMEOUT (7 * HZ)
/* Not-exported routines. */
-static int mmc_ioctl(struct cdrom_device_info *cdi, unsigned int cmd,
-unsigned long arg);
int cdrom_get_last_written(struct cdrom_device_info *, long *);
static int cdrom_get_next_writable(struct cdrom_device_info *, long *);
@@ -2714,103 +2712,6 @@ static int cdrom_ioctl_audioctl(struct
cdrom_device_info *cdi,
}
/*
- * Just about every imaginable ioctl is supported in the Uniform layer
- * these days.
- * ATAPI / SCSI specific code now mainly resides in mmc_ioctl().
- */
-int cdrom_ioctl(struct cdrom_device_info *cdi, struct block_device *bdev,
- fmode_t mode, unsigned int cmd, unsigned long arg)
-{
- void __user *argp = (void __user *)arg;
- int ret;
-
- /*
-* Try the generic SCSI command ioctl's first.
-*/
- ret = scsi_cmd_blk_ioctl(bdev, mode, cmd, argp);
- if (ret != -ENOTTY)
- return ret;
-
- switch (cmd) {
- case CDROMMULTISESSION:
- return cdrom_ioctl_multisession(cdi, argp);
- case CDROMEJECT:
- return cdrom_ioctl_eject(cdi);
- case CDROMCLOSETRAY:
- return cdrom_ioctl_closetray(cdi);
- case CDROMEJECT_SW:
- return cdrom_ioctl_eject_sw(cdi, arg);
- case CDROM_MEDIA_CHANGED:
- return cdrom_ioctl_media_changed(cdi, arg);
- case CDROM_SET_OPTIONS:
- return cdrom_ioctl_set_options(cdi, arg);
- case CDROM_CLEAR_OPTIONS:
- return cdrom_ioctl_clear_options(cdi, arg);
- case CDROM_SELECT_SPEED:
- return cdrom_ioctl_select_speed(cdi, arg);
- case CDROM_SELECT_DISC:
- return cdrom_ioctl_select_disc(cdi, arg);
- case CDROMRESET:
- return cdrom_ioctl_reset(cdi, bdev);
- case CDROM_LOCKDOOR:
- return cdrom_ioctl_lock_door(cdi, arg);
- case CDROM_DEBUG:
- return cdrom_ioctl_debug(cdi, arg);
- case CDROM_GET_CAPABILITY:
- return cdrom_ioctl_get_capability(cdi);
- case CDROM_GET_MCN:
- return cdrom_ioctl_get_mcn(cdi, argp);
- case CDROM_DRIVE_STATUS:
- return cdrom_ioctl_drive_status(cdi, arg);
- case CDROM_DISC_STATUS:
- return cdrom_ioctl_disc_status(cdi);
- case CDROM_CHANGER_NSLOTS:
- return cdrom_ioctl_changer_nslots(cdi);
- }
-
- /*
-* Use the ioctls that are implemented through the generic_packet()
-* interface. this may look at bit funny, but if -ENOTTY is
-* returned that particular ioctl is not implemented and we
-* let it go through the device specific ones.
-*/
- if (CDROM_CAN(CDC_GENERIC_PACKET)) {
- ret = mmc_ioctl(cdi, cmd, arg);
- if (ret != -ENOTTY)
- return ret;
- }
-
- /*
-* Note: most of the cd_dbg() calls are commented out here,
-* because they fill up the sys log when CD players poll
-* the drive.
-*/
- switch (cmd) {
- case CDROMSUBCHNL:
- return cdrom_ioctl_get_subchnl(cdi, argp);
- case CDROMREADTOCHDR:
- return cdrom_ioctl_read_tochdr(cdi, argp);
- case CDROMREADTOCENTRY:
- return cdrom_ioctl_read_tocentry(cdi, argp);
- case CDROMPLAYMSF:
- return cdrom_ioctl_play_msf(cdi, argp);
- case CDROMPLAYTRKIND:
- return cdrom_ioctl_play_trkind(cdi, argp);
- case CDROMVOLCTRL:
- return cdrom_ioctl_volctrl(cdi, argp);
- case CDROMVOLREAD:
- return cdrom_ioctl_volread(cdi, argp);
- case CDROMSTART:
- case CDROMSTOP:
- case CDROMPAUSE:
- case CDROMRESUME:
- return cdrom_ioctl_audioctl(cdi, cmd);
- }
-
- return -ENOSYS;
-}
-
-/*
* Required when we need to use READ_10 to issue other than 2048 block
* reads
*/
@@ -2840,9 +2741,9 @@ static int cdrom_switch_blocksize(struct
cdrom_device_info *cdi, int size)
}
static noinline int mmc_ioctl_cdrom_read_data(struct cdrom_device_info *cdi,
- void __user *arg,
- struct packet_command *cgc,
- int cmd)
+ void __user *arg,
+ struct packet_command *cgc,
+
[PATCH 08/12] cdrom: Remove cdrom_get_last_written prototype
Move the function instead.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 193 +-
1 file changed, 97 insertions(+), 96 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 332c3ae..fac603a 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -338,7 +338,6 @@ do {
\
/* Not-exported routines. */
-int cdrom_get_last_written(struct cdrom_device_info *, long *);
static int cdrom_get_next_writable(struct cdrom_device_info *, long *);
static void cdrom_count_tracks(struct cdrom_device_info *, tracktype*);
@@ -2740,6 +2739,103 @@ static int cdrom_switch_blocksize(struct
cdrom_device_info *cdi, int size)
return cdo->generic_packet(cdi, );
}
+static int cdrom_get_track_info(struct cdrom_device_info *cdi,
+ __u16 track, __u8 type, track_information *ti)
+{
+ struct cdrom_device_ops *cdo = cdi->ops;
+ struct packet_command cgc;
+ int ret, buflen;
+
+ init_cdrom_command(, ti, 8, CGC_DATA_READ);
+ cgc.cmd[0] = GPCMD_READ_TRACK_RZONE_INFO;
+ cgc.cmd[1] = type & 3;
+ cgc.cmd[4] = (track & 0xff00) >> 8;
+ cgc.cmd[5] = track & 0xff;
+ cgc.cmd[8] = 8;
+ cgc.quiet = 1;
+
+ ret = cdo->generic_packet(cdi, );
+ if (ret)
+ return ret;
+
+ buflen = be16_to_cpu(ti->track_information_length) +
+ sizeof(ti->track_information_length);
+
+ if (buflen > sizeof(track_information))
+ buflen = sizeof(track_information);
+
+ cgc.cmd[8] = cgc.buflen = buflen;
+ ret = cdo->generic_packet(cdi, );
+ if (ret)
+ return ret;
+
+ /* return actual fill size */
+ return buflen;
+}
+
+/* return the last written block on the CD-R media. this is for the udf
+ file system. */
+int cdrom_get_last_written(struct cdrom_device_info *cdi, long *last_written)
+{
+ struct cdrom_tocentry toc;
+ disc_information di;
+ track_information ti;
+ __u32 last_track;
+ int ret = -1, ti_size;
+
+ if (!CDROM_CAN(CDC_GENERIC_PACKET))
+ goto use_toc;
+
+ ret = cdrom_get_disc_info(cdi, );
+ if (ret < (int)(offsetof(typeof(di), last_track_lsb)
+ + sizeof(di.last_track_lsb)))
+ goto use_toc;
+
+ /* if unit didn't return msb, it's zeroed by cdrom_get_disc_info */
+ last_track = (di.last_track_msb << 8) | di.last_track_lsb;
+ ti_size = cdrom_get_track_info(cdi, last_track, 1, );
+ if (ti_size < (int)offsetof(typeof(ti), track_start))
+ goto use_toc;
+
+ /* if this track is blank, try the previous. */
+ if (ti.blank) {
+ if (last_track == 1)
+ goto use_toc;
+ last_track--;
+ ti_size = cdrom_get_track_info(cdi, last_track, 1, );
+ }
+
+ if (ti_size < (int)(offsetof(typeof(ti), track_size)
+ + sizeof(ti.track_size)))
+ goto use_toc;
+
+ /* if last recorded field is valid, return it. */
+ if (ti.lra_v && ti_size >= (int)(offsetof(typeof(ti), last_rec_address)
+ + sizeof(ti.last_rec_address))) {
+ *last_written = be32_to_cpu(ti.last_rec_address);
+ } else {
+ /* make it up instead */
+ *last_written = be32_to_cpu(ti.track_start) +
+ be32_to_cpu(ti.track_size);
+ if (ti.free_blocks)
+ *last_written -= (be32_to_cpu(ti.free_blocks) + 7);
+ }
+ return 0;
+
+ /* this is where we end up if the drive either can't do a
+ GPCMD_READ_DISC_INFO or GPCMD_READ_TRACK_RZONE_INFO or if
+ it doesn't give enough information or fails. then we return
+ the toc contents. */
+use_toc:
+ toc.cdte_format = CDROM_MSF;
+ toc.cdte_track = CDROM_LEADOUT;
+ if ((ret = cdi->ops->audio_ioctl(cdi, CDROMREADTOCENTRY, )))
+ return ret;
+ sanitize_format(_addr, _format, CDROM_LBA);
+ *last_written = toc.cdte_addr.lba;
+ return 0;
+}
+
static noinline int mmc_ioctl_cdrom_read_data(struct cdrom_device_info *cdi,
void __user *arg,
struct packet_command *cgc,
@@ -3210,38 +3306,6 @@ int cdrom_ioctl(struct cdrom_device_info *cdi, struct
block_device *bdev,
return -ENOSYS;
}
-static int cdrom_get_track_info(struct cdrom_device_info *cdi, __u16 track,
__u8 type,
-track_information *ti)
-{
- struct cdrom_device_ops *cdo = cdi->ops;
- struct packet_command cgc;
- int ret, buflen;
-
- init_cdrom_command(, ti, 8, CGC_DATA_READ);
- cgc.cmd[0] = GPCMD_READ_TRACK_RZONE_INFO;
- cgc.cmd[1] =
[PATCH 09/12] cdrom: Remove cdrom_get_next_writeable prototype
Move the function to the right spot instead.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 101 +-
1 file changed, 51 insertions(+), 50 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index fac603a..ed3 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -338,7 +338,6 @@ do {
\
/* Not-exported routines. */
-static int cdrom_get_next_writable(struct cdrom_device_info *, long *);
static void cdrom_count_tracks(struct cdrom_device_info *, tracktype*);
static int cdrom_mrw_exit(struct cdrom_device_info *cdi);
@@ -2836,6 +2835,57 @@ use_toc:
return 0;
}
+/* return the next writable block. also for udf file system. */
+static int cdrom_get_next_writable(struct cdrom_device_info *cdi,
+ long *next_writable)
+{
+ disc_information di;
+ track_information ti;
+ __u16 last_track;
+ int ret, ti_size;
+
+ if (!CDROM_CAN(CDC_GENERIC_PACKET))
+ goto use_last_written;
+
+ ret = cdrom_get_disc_info(cdi, );
+ if (ret < 0 || ret < offsetof(typeof(di), last_track_lsb)
+ + sizeof(di.last_track_lsb))
+ goto use_last_written;
+
+ /* if unit didn't return msb, it's zeroed by cdrom_get_disc_info */
+ last_track = (di.last_track_msb << 8) | di.last_track_lsb;
+ ti_size = cdrom_get_track_info(cdi, last_track, 1, );
+ if (ti_size < 0 || ti_size < offsetof(typeof(ti), track_start))
+ goto use_last_written;
+
+ /* if this track is blank, try the previous. */
+ if (ti.blank) {
+ if (last_track == 1)
+ goto use_last_written;
+ last_track--;
+ ti_size = cdrom_get_track_info(cdi, last_track, 1, );
+ if (ti_size < 0)
+ goto use_last_written;
+ }
+
+ /* if next recordable address field is valid, use it. */
+ if (ti.nwa_v && ti_size >= offsetof(typeof(ti), next_writable)
+ + sizeof(ti.next_writable)) {
+ *next_writable = be32_to_cpu(ti.next_writable);
+ return 0;
+ }
+
+use_last_written:
+ ret = cdrom_get_last_written(cdi, next_writable);
+ if (ret) {
+ *next_writable = 0;
+ return ret;
+ } else {
+ *next_writable += 7;
+ return 0;
+ }
+}
+
static noinline int mmc_ioctl_cdrom_read_data(struct cdrom_device_info *cdi,
void __user *arg,
struct packet_command *cgc,
@@ -3339,55 +3389,6 @@ static int cdrom_get_disc_info(struct cdrom_device_info
*cdi, disc_information *
return buflen;
}
-/* return the next writable block. also for udf file system. */
-static int cdrom_get_next_writable(struct cdrom_device_info *cdi, long
*next_writable)
-{
- disc_information di;
- track_information ti;
- __u16 last_track;
- int ret, ti_size;
-
- if (!CDROM_CAN(CDC_GENERIC_PACKET))
- goto use_last_written;
-
- ret = cdrom_get_disc_info(cdi, );
- if (ret < 0 || ret < offsetof(typeof(di), last_track_lsb)
- + sizeof(di.last_track_lsb))
- goto use_last_written;
-
- /* if unit didn't return msb, it's zeroed by cdrom_get_disc_info */
- last_track = (di.last_track_msb << 8) | di.last_track_lsb;
- ti_size = cdrom_get_track_info(cdi, last_track, 1, );
- if (ti_size < 0 || ti_size < offsetof(typeof(ti), track_start))
- goto use_last_written;
-
-/* if this track is blank, try the previous. */
- if (ti.blank) {
- if (last_track == 1)
- goto use_last_written;
- last_track--;
- ti_size = cdrom_get_track_info(cdi, last_track, 1, );
- if (ti_size < 0)
- goto use_last_written;
- }
-
- /* if next recordable address field is valid, use it. */
- if (ti.nwa_v && ti_size >= offsetof(typeof(ti), next_writable)
- + sizeof(ti.next_writable)) {
- *next_writable = be32_to_cpu(ti.next_writable);
- return 0;
- }
-
-use_last_written:
- if ((ret = cdrom_get_last_written(cdi, next_writable))) {
- *next_writable = 0;
- return ret;
- } else {
- *next_writable += 7;
- return 0;
- }
-}
-
EXPORT_SYMBOL(cdrom_get_last_written);
EXPORT_SYMBOL(register_cdrom);
EXPORT_SYMBOL(unregister_cdrom);
--
1.8.1.2.459.gbcd45b4.dirty
--
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
[PATCH 03/12] cdrom: Remove obfuscating IOCTL_IN and IOCTL_OUT macros
Macros with hidden control flow aren't nice.
Just use copy_to/from_user directly instead.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 48 +++-
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 8eaba53..47dee5e 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -326,15 +326,6 @@ do {
\
} while (0)
#endif
-/* These are used to simplify getting data in from and back to user land */
-#define IOCTL_IN(arg, type, in)\
- if (copy_from_user(&(in), (type __user *) (arg), sizeof (in))) \
- return -EFAULT;
-
-#define IOCTL_OUT(arg, type, out) \
- if (copy_to_user((type __user *) (arg), &(out), sizeof (out))) \
- return -EFAULT;
-
/* The (cdo->capability & ~cdi->mask & CDC_XXX) construct was used in
a lot of places. This macro makes the code more clear. */
#define CDROM_CAN(type) (cdi->ops->capability & ~cdi->mask & (type))
@@ -2874,7 +2865,8 @@ static noinline int mmc_ioctl_cdrom_read_data(struct
cdrom_device_info *cdi,
blocksize = CD_FRAMESIZE_RAW0;
break;
}
- IOCTL_IN(arg, struct cdrom_msf, msf);
+ if (copy_from_user(, (struct cdrom_msf __user *)arg, sizeof(msf)))
+ return -EFAULT;
lba = msf_to_lba(msf.cdmsf_min0, msf.cdmsf_sec0, msf.cdmsf_frame0);
/* FIXME: we need upper bound checking, too!! */
if (lba < 0)
@@ -2916,7 +2908,9 @@ static noinline int mmc_ioctl_cdrom_read_audio(struct
cdrom_device_info *cdi,
struct cdrom_read_audio ra;
int lba;
- IOCTL_IN(arg, struct cdrom_read_audio, ra);
+ if (copy_from_user(, (struct cdrom_read_audio __user *)arg,
+ sizeof(ra)))
+ return -EFAULT;
if (ra.addr_format == CDROM_MSF)
lba = msf_to_lba(ra.addr.msf.minute,
@@ -2940,7 +2934,8 @@ static noinline int mmc_ioctl_cdrom_subchannel(struct
cdrom_device_info *cdi,
int ret;
struct cdrom_subchnl q;
u_char requested, back;
- IOCTL_IN(arg, struct cdrom_subchnl, q);
+ if (copy_from_user(, (struct cdrom_subchnl __user *)arg, sizeof(q)))
+ return -EFAULT;
requested = q.cdsc_format;
if (!((requested == CDROM_MSF) ||
(requested == CDROM_LBA)))
@@ -2952,7 +2947,8 @@ static noinline int mmc_ioctl_cdrom_subchannel(struct
cdrom_device_info *cdi,
back = q.cdsc_format; /* local copy */
sanitize_format(_absaddr, , requested);
sanitize_format(_reladdr, _format, requested);
- IOCTL_OUT(arg, struct cdrom_subchnl, q);
+ if (copy_to_user((struct cdrom_subchnl __user *)arg, , sizeof(q)))
+ return -EFAULT;
/* cd_dbg(CD_DO_IOCTL, "CDROMSUBCHNL successful\n"); */
return 0;
}
@@ -2964,7 +2960,8 @@ static noinline int mmc_ioctl_cdrom_play_msf(struct
cdrom_device_info *cdi,
struct cdrom_device_ops *cdo = cdi->ops;
struct cdrom_msf msf;
cd_dbg(CD_DO_IOCTL, "entering CDROMPLAYMSF\n");
- IOCTL_IN(arg, struct cdrom_msf, msf);
+ if (copy_from_user(, (struct cdrom_msf __user *)arg, sizeof(msf)))
+ return -EFAULT;
cgc->cmd[0] = GPCMD_PLAY_AUDIO_MSF;
cgc->cmd[3] = msf.cdmsf_min0;
cgc->cmd[4] = msf.cdmsf_sec0;
@@ -2983,7 +2980,8 @@ static noinline int mmc_ioctl_cdrom_play_blk(struct
cdrom_device_info *cdi,
struct cdrom_device_ops *cdo = cdi->ops;
struct cdrom_blk blk;
cd_dbg(CD_DO_IOCTL, "entering CDROMPLAYBLK\n");
- IOCTL_IN(arg, struct cdrom_blk, blk);
+ if (copy_from_user(, (struct cdrom_blk __user *)arg, sizeof(blk)))
+ return -EFAULT;
cgc->cmd[0] = GPCMD_PLAY_AUDIO_10;
cgc->cmd[2] = (blk.from >> 24) & 0xff;
cgc->cmd[3] = (blk.from >> 16) & 0xff;
@@ -3008,7 +3006,9 @@ static noinline int mmc_ioctl_cdrom_volume(struct
cdrom_device_info *cdi,
cd_dbg(CD_DO_IOCTL, "entering CDROMVOLUME\n");
- IOCTL_IN(arg, struct cdrom_volctrl, volctrl);
+ if (copy_from_user(, (struct cdrom_volctrl __user *)arg,
+ sizeof(volctrl)))
+ return -EFAULT;
cgc->buffer = buffer;
cgc->buflen = 24;
@@ -3045,7 +3045,9 @@ static noinline int mmc_ioctl_cdrom_volume(struct
cdrom_device_info *cdi,
volctrl.channel1 = buffer[offset+11];
volctrl.channel2 = buffer[offset+13];
volctrl.channel3 = buffer[offset+15];
- IOCTL_OUT(arg, struct cdrom_volctrl, volctrl);
+ if (copy_to_user((struct cdrom_volctrl __user *)arg, ,
+sizeof(volctrl)))
+ return -EFAULT;
return 0;
}
@@ -3131,11 +3133,13 @@ static
[PATCH 10/12] cdrom: Remove cdrom_count_tracks prototype
Move function to proper location instead.
Fix whitespace and embedded if too.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 94 +--
1 file changed, 47 insertions(+), 47 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index ed3..f614847 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -338,8 +338,6 @@ do {
\
/* Not-exported routines. */
-static void cdrom_count_tracks(struct cdrom_device_info *, tracktype*);
-
static int cdrom_mrw_exit(struct cdrom_device_info *cdi);
static int cdrom_get_disc_info(struct cdrom_device_info *cdi, disc_information
*di);
@@ -948,6 +946,53 @@ static int cdrom_close_write(struct cdrom_device_info *cdi)
#endif
}
+/* badly broken, I know. Is due for a fixup anytime. */
+static void cdrom_count_tracks(struct cdrom_device_info *cdi, tracktype
*tracks)
+{
+ struct cdrom_tochdr header;
+ struct cdrom_tocentry entry;
+ int ret, i;
+ tracks->data = 0;
+ tracks->audio = 0;
+ tracks->cdi = 0;
+ tracks->xa = 0;
+ tracks->error = 0;
+ cd_dbg(CD_COUNT_TRACKS, "entering cdrom_count_tracks\n");
+ /* Grab the TOC header so we can see how many tracks there are */
+ ret = cdi->ops->audio_ioctl(cdi, CDROMREADTOCHDR, );
+ if (ret) {
+ if (ret == -ENOMEDIUM)
+ tracks->error = CDS_NO_DISC;
+ else
+ tracks->error = CDS_NO_INFO;
+ return;
+ }
+ /* check what type of tracks are on this disc */
+ entry.cdte_format = CDROM_MSF;
+ for (i = header.cdth_trk0; i <= header.cdth_trk1; i++) {
+ entry.cdte_track = i;
+ if (cdi->ops->audio_ioctl(cdi, CDROMREADTOCENTRY, )) {
+ tracks->error = CDS_NO_INFO;
+ return;
+ }
+ if (entry.cdte_ctrl & CDROM_DATA_TRACK) {
+ if (entry.cdte_format == 0x10)
+ tracks->cdi++;
+ else if (entry.cdte_format == 0x20)
+ tracks->xa++;
+ else
+ tracks->data++;
+ } else {
+ tracks->audio++;
+ }
+ cd_dbg(CD_COUNT_TRACKS, "track %d: format=%d, ctrl=%d\n",
+ i, entry.cdte_format, entry.cdte_ctrl);
+ }
+ cd_dbg(CD_COUNT_TRACKS, "disc has %d tracks: %d=audio %d=data %d=Cd-I
%d=XA\n",
+ header.cdth_trk1, tracks->audio, tracks->data,
+ tracks->cdi, tracks->xa);
+}
+
static
int open_for_data(struct cdrom_device_info *cdi)
{
@@ -1457,51 +1502,6 @@ int cdrom_media_changed(struct cdrom_device_info *cdi)
return media_changed(cdi, 0);
}
-/* badly broken, I know. Is due for a fixup anytime. */
-static void cdrom_count_tracks(struct cdrom_device_info *cdi, tracktype*
tracks)
-{
- struct cdrom_tochdr header;
- struct cdrom_tocentry entry;
- int ret, i;
- tracks->data=0;
- tracks->audio=0;
- tracks->cdi=0;
- tracks->xa=0;
- tracks->error=0;
- cd_dbg(CD_COUNT_TRACKS, "entering cdrom_count_tracks\n");
- /* Grab the TOC header so we can see how many tracks there are */
- if ((ret = cdi->ops->audio_ioctl(cdi, CDROMREADTOCHDR, ))) {
- if (ret == -ENOMEDIUM)
- tracks->error = CDS_NO_DISC;
- else
- tracks->error = CDS_NO_INFO;
- return;
- }
- /* check what type of tracks are on this disc */
- entry.cdte_format = CDROM_MSF;
- for (i = header.cdth_trk0; i <= header.cdth_trk1; i++) {
- entry.cdte_track = i;
- if (cdi->ops->audio_ioctl(cdi, CDROMREADTOCENTRY, )) {
- tracks->error=CDS_NO_INFO;
- return;
- }
- if (entry.cdte_ctrl & CDROM_DATA_TRACK) {
- if (entry.cdte_format == 0x10)
- tracks->cdi++;
- else if (entry.cdte_format == 0x20)
- tracks->xa++;
- else
- tracks->data++;
- } else
- tracks->audio++;
- cd_dbg(CD_COUNT_TRACKS, "track %d: format=%d, ctrl=%d\n",
- i, entry.cdte_format, entry.cdte_ctrl);
- }
- cd_dbg(CD_COUNT_TRACKS, "disc has %d tracks: %d=audio %d=data %d=Cd-I
%d=XA\n",
- header.cdth_trk1, tracks->audio, tracks->data,
- tracks->cdi, tracks->xa);
-}
-
/* Requests to the low-level drivers will /always/ be done in the
following format convention:
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line
[PATCH 04/12] cdrom: Remove prototype for open_for_data
Move static function to the appropriate place to remove
the now unnecessary prototype.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 114 +-
1 file changed, 57 insertions(+), 57 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 47dee5e..5a38b56 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -337,7 +337,6 @@ do {
\
#define CDROM_DEF_TIMEOUT (7 * HZ)
/* Not-exported routines. */
-static int open_for_data(struct cdrom_device_info * cdi);
static int check_for_audio_disc(struct cdrom_device_info * cdi,
struct cdrom_device_ops * cdo);
static void sanitize_format(union cdrom_addr *addr,
@@ -957,63 +956,8 @@ static int cdrom_close_write(struct cdrom_device_info *cdi)
#endif
}
-/* We use the open-option O_NONBLOCK to indicate that the
- * purpose of opening is only for subsequent ioctl() calls; no device
- * integrity checks are performed.
- *
- * We hope that all cd-player programs will adopt this convention. It
- * is in their own interest: device control becomes a lot easier
- * this way.
- */
-int cdrom_open(struct cdrom_device_info *cdi, struct block_device *bdev,
fmode_t mode)
-{
- int ret;
-
- cd_dbg(CD_OPEN, "entering cdrom_open\n");
-
- /* open is event synchronization point, check events first */
- check_disk_change(bdev);
-
- /* if this was a O_NONBLOCK open and we should honor the flags,
-* do a quick open without drive/disc integrity checks. */
- cdi->use_count++;
- if ((mode & FMODE_NDELAY) && (cdi->options & CDO_USE_FFLAGS)) {
- ret = cdi->ops->open(cdi, 1);
- } else {
- ret = open_for_data(cdi);
- if (ret)
- goto err;
- cdrom_mmc3_profile(cdi);
- if (mode & FMODE_WRITE) {
- ret = -EROFS;
- if (cdrom_open_write(cdi))
- goto err_release;
- if (!CDROM_CAN(CDC_RAM))
- goto err_release;
- ret = 0;
- cdi->media_written = 0;
- }
- }
-
- if (ret)
- goto err;
-
- cd_dbg(CD_OPEN, "Use count for \"/dev/%s\" now %d\n",
- cdi->name, cdi->use_count);
- return 0;
-err_release:
- if (CDROM_CAN(CDC_LOCK) && cdi->options & CDO_LOCK) {
- cdi->ops->lock_door(cdi, 0);
- cd_dbg(CD_OPEN, "door unlocked\n");
- }
- cdi->ops->release(cdi);
-err:
- cdi->use_count--;
- return ret;
-}
-
static
-int open_for_data(struct cdrom_device_info * cdi)
+int open_for_data(struct cdrom_device_info *cdi)
{
int ret;
struct cdrom_device_ops *cdo = cdi->ops;
@@ -1119,6 +1063,62 @@ clean_up_and_return:
return ret;
}
+/* We use the open-option O_NONBLOCK to indicate that the
+ * purpose of opening is only for subsequent ioctl() calls; no device
+ * integrity checks are performed.
+ *
+ * We hope that all cd-player programs will adopt this convention. It
+ * is in their own interest: device control becomes a lot easier
+ * this way.
+ */
+int cdrom_open(struct cdrom_device_info *cdi, struct block_device *bdev,
+ fmode_t mode)
+{
+ int ret;
+
+ cd_dbg(CD_OPEN, "entering cdrom_open\n");
+
+ /* open is event synchronization point, check events first */
+ check_disk_change(bdev);
+
+ /* if this was a O_NONBLOCK open and we should honor the flags,
+* do a quick open without drive/disc integrity checks. */
+ cdi->use_count++;
+ if ((mode & FMODE_NDELAY) && (cdi->options & CDO_USE_FFLAGS)) {
+ ret = cdi->ops->open(cdi, 1);
+ } else {
+ ret = open_for_data(cdi);
+ if (ret)
+ goto err;
+ cdrom_mmc3_profile(cdi);
+ if (mode & FMODE_WRITE) {
+ ret = -EROFS;
+ if (cdrom_open_write(cdi))
+ goto err_release;
+ if (!CDROM_CAN(CDC_RAM))
+ goto err_release;
+ ret = 0;
+ cdi->media_written = 0;
+ }
+ }
+
+ if (ret)
+ goto err;
+
+ cd_dbg(CD_OPEN, "Use count for \"/dev/%s\" now %d\n",
+ cdi->name, cdi->use_count);
+ return 0;
+err_release:
+ if (CDROM_CAN(CDC_LOCK) && cdi->options & CDO_LOCK) {
+ cdi->ops->lock_door(cdi, 0);
+ cd_dbg(CD_OPEN, "door unlocked\n");
+ }
+ cdi->ops->release(cdi);
+err:
+ cdi->use_count--;
+ return ret;
+}
+
/* This code is similar to that in open_for_data. The routine is called
whenever an audio play operation is
[PATCH 11/12] cdrom: Remove unnecessary prototype for cdrom_mrw_exit
Move the function to appropriate locations instead.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 238 +-
1 file changed, 121 insertions(+), 117 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index f614847..c8ca342 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -338,8 +338,6 @@ do {
\
/* Not-exported routines. */
-static int cdrom_mrw_exit(struct cdrom_device_info *cdi);
-
static int cdrom_get_disc_info(struct cdrom_device_info *cdi, disc_information
*di);
static void cdrom_sysctl_register(void);
@@ -359,113 +357,29 @@ static int cdrom_dummy_generic_packet(struct
cdrom_device_info *cdi,
return -EIO;
}
-/* This macro makes sure we don't have to check on cdrom_device_ops
- * existence in the run-time routines below. Change_capability is a
- * hack to have the capability flags defined const, while we can still
- * change it here without gcc complaining at every line.
- */
-#define ENSURE(call, bits) if (cdo->call == NULL) *change_capability &= ~(bits)
-
-int register_cdrom(struct cdrom_device_info *cdi)
-{
- static char banner_printed;
-struct cdrom_device_ops *cdo = cdi->ops;
-int *change_capability = (int *)>capability; /* hack */
-
- cd_dbg(CD_OPEN, "entering register_cdrom\n");
-
- if (cdo->open == NULL || cdo->release == NULL)
- return -EINVAL;
- if (!banner_printed) {
- pr_info("Uniform CD-ROM driver " REVISION "\n");
- banner_printed = 1;
- cdrom_sysctl_register();
- }
-
- ENSURE(drive_status, CDC_DRIVE_STATUS );
- if (cdo->check_events == NULL && cdo->media_changed == NULL)
- *change_capability = ~(CDC_MEDIA_CHANGED | CDC_SELECT_DISC);
- ENSURE(tray_move, CDC_CLOSE_TRAY | CDC_OPEN_TRAY);
- ENSURE(lock_door, CDC_LOCK);
- ENSURE(select_speed, CDC_SELECT_SPEED);
- ENSURE(get_last_session, CDC_MULTI_SESSION);
- ENSURE(get_mcn, CDC_MCN);
- ENSURE(reset, CDC_RESET);
- ENSURE(generic_packet, CDC_GENERIC_PACKET);
- cdi->mc_flags = 0;
- cdo->n_minors = 0;
-cdi->options = CDO_USE_FFLAGS;
-
- if (autoclose==1 && CDROM_CAN(CDC_CLOSE_TRAY))
- cdi->options |= (int) CDO_AUTO_CLOSE;
- if (autoeject==1 && CDROM_CAN(CDC_OPEN_TRAY))
- cdi->options |= (int) CDO_AUTO_EJECT;
- if (lockdoor==1)
- cdi->options |= (int) CDO_LOCK;
- if (check_media_type==1)
- cdi->options |= (int) CDO_CHECK_TYPE;
-
- if (CDROM_CAN(CDC_MRW_W))
- cdi->exit = cdrom_mrw_exit;
-
- if (cdi->disk)
- cdi->cdda_method = CDDA_BPC_FULL;
- else
- cdi->cdda_method = CDDA_OLD;
-
- if (!cdo->generic_packet)
- cdo->generic_packet = cdrom_dummy_generic_packet;
-
- cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
- mutex_lock(_mutex);
- list_add(>list, _list);
- mutex_unlock(_mutex);
- return 0;
-}
-#undef ENSURE
-
-void unregister_cdrom(struct cdrom_device_info *cdi)
-{
- cd_dbg(CD_OPEN, "entering unregister_cdrom\n");
-
- mutex_lock(_mutex);
- list_del(>list);
- mutex_unlock(_mutex);
-
- if (cdi->exit)
- cdi->exit(cdi);
-
- cdi->ops->n_minors--;
- cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
-}
-
-int cdrom_get_media_event(struct cdrom_device_info *cdi,
- struct media_event_desc *med)
+static int cdrom_flush_cache(struct cdrom_device_info *cdi)
{
struct packet_command cgc;
- unsigned char buffer[8];
- struct event_header *eh = (struct event_header *) buffer;
-
- init_cdrom_command(, buffer, sizeof(buffer), CGC_DATA_READ);
- cgc.cmd[0] = GPCMD_GET_EVENT_STATUS_NOTIFICATION;
- cgc.cmd[1] = 1; /* IMMED */
- cgc.cmd[4] = 1 << 4;/* media event */
- cgc.cmd[8] = sizeof(buffer);
- cgc.quiet = 1;
-
- if (cdi->ops->generic_packet(cdi, ))
- return 1;
- if (be16_to_cpu(eh->data_len) < sizeof(*med))
- return 1;
+ init_cdrom_command(, NULL, 0, CGC_DATA_NONE);
+ cgc.cmd[0] = GPCMD_FLUSH_CACHE;
- if (eh->nea || eh->notification_class != 0x4)
- return 1;
+ cgc.timeout = 5 * 60 * HZ;
- memcpy(med, [sizeof(*eh)], sizeof(*med));
- return 0;
+ return cdi->ops->generic_packet(cdi, );
}
+/* This macro makes sure we don't have to check on cdrom_device_ops
+ * existence in the run-time routines below. Change_capability is a
+ * hack to have the capability flags defined const, while we can still
+ * change it here without gcc complaining at every line.
+ */
+#define ENSURE(call, bits) \
+do {
[PATCH 12/12] cdrom: Remove unnecessary prototype for cdrom_get_disc_info
Move the function to the proper spot instead.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 71 ++-
1 file changed, 36 insertions(+), 35 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index c8ca342..49ac566 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -338,8 +338,6 @@ do {
\
/* Not-exported routines. */
-static int cdrom_get_disc_info(struct cdrom_device_info *cdi, disc_information
*di);
-
static void cdrom_sysctl_register(void);
static LIST_HEAD(cdrom_list);
@@ -369,6 +367,42 @@ static int cdrom_flush_cache(struct cdrom_device_info *cdi)
return cdi->ops->generic_packet(cdi, );
}
+/* requires CD R/RW */
+static int cdrom_get_disc_info(struct cdrom_device_info *cdi,
+ disc_information *di)
+{
+ struct cdrom_device_ops *cdo = cdi->ops;
+ struct packet_command cgc;
+ int ret, buflen;
+
+ /* set up command and get the disc info */
+ init_cdrom_command(, di, sizeof(*di), CGC_DATA_READ);
+ cgc.cmd[0] = GPCMD_READ_DISC_INFO;
+ cgc.cmd[8] = cgc.buflen = 2;
+ cgc.quiet = 1;
+
+ ret = cdo->generic_packet(cdi, );
+ if (ret)
+ return ret;
+
+ /* not all drives have the same disc_info length, so requeue
+* packet with the length the drive tells us it can supply
+*/
+ buflen = be16_to_cpu(di->disc_information_length) +
+ sizeof(di->disc_information_length);
+
+ if (buflen > sizeof(disc_information))
+ buflen = sizeof(disc_information);
+
+ cgc.cmd[8] = cgc.buflen = buflen;
+ ret = cdo->generic_packet(cdi, );
+ if (ret)
+ return ret;
+
+ /* return actual fill size */
+ return buflen;
+}
+
/* This macro makes sure we don't have to check on cdrom_device_ops
* existence in the run-time routines below. Change_capability is a
* hack to have the capability flags defined const, while we can still
@@ -3360,39 +3394,6 @@ int cdrom_ioctl(struct cdrom_device_info *cdi, struct
block_device *bdev,
return -ENOSYS;
}
-/* requires CD R/RW */
-static int cdrom_get_disc_info(struct cdrom_device_info *cdi, disc_information
*di)
-{
- struct cdrom_device_ops *cdo = cdi->ops;
- struct packet_command cgc;
- int ret, buflen;
-
- /* set up command and get the disc info */
- init_cdrom_command(, di, sizeof(*di), CGC_DATA_READ);
- cgc.cmd[0] = GPCMD_READ_DISC_INFO;
- cgc.cmd[8] = cgc.buflen = 2;
- cgc.quiet = 1;
-
- if ((ret = cdo->generic_packet(cdi, )))
- return ret;
-
- /* not all drives have the same disc_info length, so requeue
-* packet with the length the drive tells us it can supply
-*/
- buflen = be16_to_cpu(di->disc_information_length) +
-sizeof(di->disc_information_length);
-
- if (buflen > sizeof(disc_information))
- buflen = sizeof(disc_information);
-
- cgc.cmd[8] = cgc.buflen = buflen;
- if ((ret = cdo->generic_packet(cdi, )))
- return ret;
-
- /* return actual fill size */
- return buflen;
-}
-
EXPORT_SYMBOL(cdrom_get_last_written);
EXPORT_SYMBOL(register_cdrom);
EXPORT_SYMBOL(unregister_cdrom);
--
1.8.1.2.459.gbcd45b4.dirty
--
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 05/12] cdrom: Remove unnecessary check_for_audio_disc prototype
The actual static is defined below it but not used until later.
Signed-off-by: Joe Perches
---
drivers/cdrom/cdrom.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 5a38b56..a570e5f 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -337,8 +337,6 @@ do {
\
#define CDROM_DEF_TIMEOUT (7 * HZ)
/* Not-exported routines. */
-static int check_for_audio_disc(struct cdrom_device_info * cdi,
-struct cdrom_device_ops * cdo);
static void sanitize_format(union cdrom_addr *addr,
u_char * curr, u_char requested);
static int mmc_ioctl(struct cdrom_device_info *cdi, unsigned int cmd,
--
1.8.1.2.459.gbcd45b4.dirty
--
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 00/12] cdrom: neatening
Hey Jens. I was cleaning up a bunch of old stuff on my computer and noticed these... On Mon, 2013-07-22 at 16:08 -0600, Jens Axboe wrote: > On 07/22/2013 04:08 PM, Joe Perches wrote: > > Anything going to happen via you with these patches? > I'll queue them up for 3.12. Awhile ago these might have been queued up somewhere, but as far as I can tell, never got applied. Joe Perches (12): cdrom: convert cdinfo to cd_dbg cdrom: Remove unused CHECKAUDIO macro cdrom: Remove obfuscating IOCTL_IN and IOCTL_OUT macros cdrom: Remove prototype for open_for_data cdrom: Remove unnecessary check_for_audio_disc prototype cdrom: Remove unnecessary sanitize_format prototype cdrom: Move mmc_ioctls above cdrom_ioctl to remove unnecessary prototype cdrom: Remove cdrom_get_last_written prototype cdrom: Remove cdrom_get_next_writeable prototype cdrom: Remove cdrom_count_tracks prototype cdrom: Remove unnecessary prototype for cdrom_mrw_exit cdrom: Remove unnecessary prototype for cdrom_get_disc_info drivers/cdrom/cdrom.c | 1357 + 1 file changed, 681 insertions(+), 676 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty -- 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 2/2] staging/rtl8192e: userspace ptr deref + incorrect declarations
Good evening,
Forgive my mistakes, I sent only a few patches yet and I'm still learning.
Nevertheless:
> What is that period in the commit message? And the semicolon?
Semicolons is what one use to ponctuate an enumerated list (at least
in french). In fact, it was their primary use before computer era.
Is there something wrong with it ? I check all my patches with
checkpatch.pl --strict before sending them and it didn't seem to
complain...
> You should also be a bit more specific. Also, the Subject line is
> very bad. Better go with something like this:
>
> staging: rtl8192e: fix userspace pointer dereference
Right. I used the slash as a subpart of the tree. Didn't know what
was the best for this situation.
> And when you resend a patchset, please resend the full patchset.
I usually do but I've got an acceptation message for the first one
(see below).
> This is totally unneccessary.
Should at least have gone in the body below indeed.
> When you cite a commit please don't include the full hash, that is
> non informational. Better put the first 7 characters of the hash and
> the first line of the commit message as well in parantheses, like so:
>
> 5169af2 ("Staging: rtl8192e: Fix declaration of symbols")
> (I even have a command for this in vim :-) )
I'm interested. I use vim too.
> Are you sure that 1/2 was applied to the staging tree?
> It's unlikely that 1/2 is applied while 2/2 is left alone.
As stated before, I received the common automatic mail from
Greg KH regarding this one. So I'll now wait before I do a v3
for this issue. If so, I'll resent the complete set if required.
> Oh, I am unable to find commit b5c8d48 in Linus' or staging-next.
> In which tree is it?
It's linux-next. If I quote a commit, I should the tree as well,
indeed. But since the v1 was performed partially for the Eudyptula
Project and since it was a response to a modification request,
I though it was implicit.
> Could you please as well remove that empty line in the declarations?
I'll do.
Cheers.
--
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 1/3] PM / sleep: Flags to speed up suspend-resume of runtime-suspended devices
On Friday, May 02, 2014 02:44:43 PM Alan Stern wrote: > On Fri, 2 May 2014, Rafael J. Wysocki wrote: > > > Well, I have a second update. > > > > It has different flag names and changelog (that should explain things better > > hopefully) and the purpose of both flags should be more clear now (patch > > [3/3] > > would need to be reworked on top of this, but for now let's just discuss the > > core changes). > > We've got patch descriptions passing in the night! :-) > > This doesn't contain any changes to the patch itself, apart from the > flag names, right? There is this change in the patch itself: + if (dev->power.leave_runtime_suspended) + dev->power.parent_needed = false; in __device_suspend() and power.parent_needed is set for all devices in dpm_prepare(). > The description below is much better than the earlier one, but I still feel > this deserves to be split in two: one patch for each new flag. Well, I guess I can introduce power.leave_runtime_suspended for leaf devices first, but that would be somewhat artificial, because in that case some code added by the first patch would be removed by the second one. :-) > > From: Rafael J. Wysocki > > Subject: PM / sleep: Flags to speed up suspend-resume of runtime-suspended > > devices > > > > Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to > > resume all runtime-suspended devices during system suspend, mostly > > because those devices may need to be reprogrammed due to different > > wakeup settings for system sleep and for runtime PM. However, at > > least in some cases, that isn't really necessary, because the wakeup > > settings may not be really different. > > > > The idea here is that subsystems should know whether or not it is > > necessary to resume a given device during system suspend as long as > > they know that the device's children will not need it to be functional > > during the late/early and noirq phases of their suspend and resume. > > Perhaps the matter of the children's requirements should be discussed > more fully. I skimmed over it in my suggested description too. > > Under what conditions will a child need the parent device to be > functional? Let's start by assuming the parent's ignore_children > bit isn't set. > > By this assumption, if the child was at full power during the suspend > stages then the parent would have to be at full power too. So let's > assume that the child is in runtime suspend when its ->suspend() > routine runs. I can't think of any scenario where the child's driver > would require the parent to be at full power without also needing the > child to be at full power. If the child really does need to be at full > power then the driver will have to do a runtime resume, which would > also bring the parent to full power. Either way, we don't have to do > anything special -- during the suspend stages, if the child needs the > parent to be at full power then it will be. > > (As a variant of this case, maybe the child belongs to one of the > subsystems like PCI, and its driver expects the subsystem to > runtime-resume the child before invoking its ->suspend() callback. > When the subsystem does this, the parent will automatically be resumed > as well. Again there are no special requirements; the point is moot > because the parent will never be runtime-suspended when its ->suspend() > routine is ready to run.) Yes. > During the resume stages, if the child is going to be restored to full > power then certainly the parent has to be at full power first. > Drivers expect this, so if we're going to leave the parent in runtime > suspend during system resume, we have to get the child driver's > permission first. _That's_ what the parent_needed flag should mean. There is a theoretical case where the child is runtime-suspended, but not actually zero-power, and it doesn't have leave_runtime_suspended set, but its driver doesn't implement ->suspend() at all and instead it waits until ->suspend_late() or even ->suspend_noirq() and then attempts to do something extra to the device. Then, if the parent is a bridge and is required to be functional for accessing the child, we can't leave it runtime-suspended too. I'm not sure how realistic that is, to be honest, but it does look like a valid thing to do to my eyes, so in my opinion we may need to get the child driver's permission to leave the parent in runtime suspend for that reason too. I guess it is fair to simply say that "we need to get the child driver's permission to leave the parent in runtime suspend". > What about the case where ignore_children _is_ set? Then the child's > driver might indeed need the parent to be at full power during system > suspend, since we could start off with the parent suspended and the > child active. > > Putting these arguments together, the result is that during system > suspend we don't care about the children's needs unless the parent's >
Re: [RFC/HACK] x86: Fast return to kernel
On 05/04/2014 04:46 PM, Paolo Bonzini wrote: > > Your suggested trick of splitting the return paths for IF=0/IF=1 can be > also done like this: > > movq EFLAGS-ARGOFFSET(%rsp), %rdi > btrq $9, %rdi# Clear IF, save old value in CF > movq %rdi, (%rsi) > ... > popfq > jnc1f# If IF was 0, just return > sti# Using STI gets us an interrupt shadow > 1f: > retq > That doesn't work, because CF gets restored by the popfq as well. Unfortunately. -hpa -- 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/HACK] x86: Fast return to kernel
Il 02/05/2014 21:51, Linus Torvalds ha scritto: > Also, are you *really* sure that "popf" has the same one-instruction > interrupt shadow that "sti" has? Because I'm not at all sure that is > true, and it's not documented as far as I can tell. In contrast, the > one-instruction shadow after "sti" very much _is_ documented. Yeah, I'm pretty sure about this. The only instructions with an interrupt shadow are "sti", "mov ss" and "pop ss". Yep. There may be specific microarchitectures that do it for a "popf" that enables interrupts too, but that is not documented _anywhere_ I could find. Btw, on the "really easy to get wrong in emulation" note and looking at the kernel sources: it looks like KVM gets "pop ss" wrong, and only does the shadow on "mov ss". Thanks, that's useful to know (and easy to fix). Note that in practice arch/x86/kvm/emulate.c will only emulate POP SS in big real mode or if the stack is in MMIO memory. The interrupt shadow will be handled by the processor in all other cases, and Intel calls the bit "Blocking by MOV SS" even if it also applies to POP SS. Your suggested trick of splitting the return paths for IF=0/IF=1 can be also done like this: movq EFLAGS-ARGOFFSET(%rsp), %rdi btrq $9, %rdi # Clear IF, save old value in CF movq %rdi, (%rsi) ... popfq jnc 1f # If IF was 0, just return sti # Using STI gets us an interrupt shadow 1f: retq Paolo -- 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] bridge: Add port flap detection
On Mon, 5 May 2014 07:29:34 +1000
Jon Maxwell wrote:
> There has been a number incidents recently where customers running KVM have
> reported that VM hosts on different Hypervisors are unreachable. Based on
> pcap traces we found that the bridge was broadcasting the ARP request out
> onto the network. However some NICs have an inbuilt switch which on occasions
> were broadcasting the VMs ARP request back through the physical NIC on the
> Hypervisor. This resulted in the bridge flapping ports and incorrectly
> learning that the VMs mac address was external. As a result the ARP reply was
> directed back onto the external network and VM never updated it's ARP cache.
> This patch will detect port flapping and log a message so that this condition
> can be detected earlier.
>
> Signed-off-by: Jon Maxwell
> ---
> net/bridge/br_fdb.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> index 9203d5a..c08607b 100644
> --- a/net/bridge/br_fdb.c
> +++ b/net/bridge/br_fdb.c
> @@ -507,6 +507,13 @@ void br_fdb_update(struct net_bridge *br, struct
> net_bridge_port *source,
> source->dev->name);
> } else {
> /* fastpath: update of existing entry */
> + if (source->port_no != fdb->dst->port_no &&
> + net_ratelimit())
> + br_warn(br, "Port flapping detected source
> entry dev = %s mac = %pM, port_no = %d\n existing entry dev = %s mac = %pM,
> port_no = %d\n",
> + source->dev->name,
> + addr, source->port_no,
> + fdb->dst->dev->name, addr,
> + fdb->dst->port_no);
> fdb->dst = source;
> fdb->updated = jiffies;
> if (unlikely(added_by_user))
Ok, but please shorten the message to a single line without excess wordage.
Plus flapping to mean means link going up and down. Maybe use same message
as BSD?
--
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/1] FS/CIFS: remove obsolete __constant
On Sat, May 3, 2014 at 4:15 PM, Fabian Frederick wrote:
> Replacing all __constant_foo to foo()
> except in smb2status.h (1700 lines to update).
>
> Cc: linux-c...@vger.kernel.org
> Cc: Steve French
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
> ---
> fs/cifs/cifsacl.c | 2 +-
> fs/cifs/cifssmb.c | 20 ++--
> fs/cifs/sess.c | 2 +-
> fs/cifs/smb2misc.c | 38 +++---
> fs/cifs/smb2ops.c | 2 +-
> fs/cifs/smb2pdu.c | 2 +-
> fs/cifs/smb2pdu.h | 28 ++--
> 7 files changed, 47 insertions(+), 47 deletions(-)
>
> diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
> index 7ff866d..54ac0e8 100644
> --- a/fs/cifs/cifsacl.c
> +++ b/fs/cifs/cifsacl.c
> @@ -38,7 +38,7 @@ static const struct cifs_sid sid_everyone = {
> 1, 1, {0, 0, 0, 0, 0, 1}, {0} };
> /* security id for Authenticated Users system group */
> static const struct cifs_sid sid_authusers = {
> - 1, 1, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(11)} };
> + 1, 1, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(11)} };
Does the build still work on BE arches with this? I know at one point
the above wouldn't compile on those
arches. See commit 536abdb0802f, for an explanation.
> /* group users */
> static const struct cifs_sid sid_user = {1, 2 , {0, 0, 0, 0, 0, 5}, {} };
>
> diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
> index 6ce4e09..c3dc52e 100644
> --- a/fs/cifs/cifssmb.c
> +++ b/fs/cifs/cifssmb.c
> @@ -2430,14 +2430,14 @@ CIFSSMBPosixLock(const unsigned int xid, struct
> cifs_tcon *tcon,
> }
> parm_data = (struct cifs_posix_lock *)
> ((char *)>hdr.Protocol + data_offset);
> - if (parm_data->lock_type ==
> __constant_cpu_to_le16(CIFS_UNLCK))
> + if (parm_data->lock_type == cpu_to_le16(CIFS_UNLCK))
> pLockData->fl_type = F_UNLCK;
> else {
> if (parm_data->lock_type ==
> - __constant_cpu_to_le16(CIFS_RDLCK))
> + cpu_to_le16(CIFS_RDLCK))
> pLockData->fl_type = F_RDLCK;
> else if (parm_data->lock_type ==
> - __constant_cpu_to_le16(CIFS_WRLCK))
> + cpu_to_le16(CIFS_WRLCK))
> pLockData->fl_type = F_WRLCK;
>
> pLockData->fl_start = le64_to_cpu(parm_data->start);
> @@ -3232,25 +3232,25 @@ CIFSSMB_set_compression(const unsigned int xid,
> struct cifs_tcon *tcon,
> pSMB->compression_state = cpu_to_le16(COMPRESSION_FORMAT_DEFAULT);
>
> pSMB->TotalParameterCount = 0;
> - pSMB->TotalDataCount = __constant_cpu_to_le32(2);
> + pSMB->TotalDataCount = cpu_to_le32(2);
> pSMB->MaxParameterCount = 0;
> pSMB->MaxDataCount = 0;
> pSMB->MaxSetupCount = 4;
> pSMB->Reserved = 0;
> pSMB->ParameterOffset = 0;
> - pSMB->DataCount = __constant_cpu_to_le32(2);
> + pSMB->DataCount = cpu_to_le32(2);
> pSMB->DataOffset =
> cpu_to_le32(offsetof(struct
> smb_com_transaction_compr_ioctl_req,
> compression_state) - 4); /* 84 */
> pSMB->SetupCount = 4;
> - pSMB->SubCommand = __constant_cpu_to_le16(NT_TRANSACT_IOCTL);
> + pSMB->SubCommand = cpu_to_le16(NT_TRANSACT_IOCTL);
> pSMB->ParameterCount = 0;
> - pSMB->FunctionCode = __constant_cpu_to_le32(FSCTL_SET_COMPRESSION);
> + pSMB->FunctionCode = cpu_to_le32(FSCTL_SET_COMPRESSION);
> pSMB->IsFsctl = 1; /* FSCTL */
> pSMB->IsRootFlag = 0;
> pSMB->Fid = fid; /* file handle always le */
> /* 3 byte pad, followed by 2 byte compress state */
> - pSMB->ByteCount = __constant_cpu_to_le16(5);
> + pSMB->ByteCount = cpu_to_le16(5);
> inc_rfc1001_len(pSMB, 5);
>
> rc = SendReceive(xid, tcon->ses, (struct smb_hdr *) pSMB,
> @@ -3386,10 +3386,10 @@ static __u16 ACL_to_cifs_posix(char *parm_data, const
> char *pACL,
> cifs_acl->version = cpu_to_le16(1);
> if (acl_type == ACL_TYPE_ACCESS) {
> cifs_acl->access_entry_count = cpu_to_le16(count);
> - cifs_acl->default_entry_count =
> __constant_cpu_to_le16(0x);
> + cifs_acl->default_entry_count = cpu_to_le16(0x);
> } else if (acl_type == ACL_TYPE_DEFAULT) {
> cifs_acl->default_entry_count = cpu_to_le16(count);
> - cifs_acl->access_entry_count = __constant_cpu_to_le16(0x);
> + cifs_acl->access_entry_count = cpu_to_le16(0x);
> } else {
> cifs_dbg(FYI, "unknown ACL type %d\n", acl_type);
> return 0;
> diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
> index e87387d..27e6175 100644
> ---
[PATCH 2/5] net: macb: Clear interrupt flags
A few interrupt flags were not cleared in the ISR, resulting in a sytem
trapped in the ISR in cases one of those interrupts occurred. Clear all
flags to avoid such situations.
Signed-off-by: Soren Brinkmann
---
drivers/net/ethernet/cadence/macb.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 18fdcd9d51b3..e38fe39d9589 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -951,6 +951,10 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
if (unlikely(status & (MACB_TX_ERR_FLAGS))) {
macb_writel(bp, IDR, MACB_TX_INT_FLAGS);
schedule_work(>tx_error_task);
+
+ if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
+ macb_writel(bp, ISR, MACB_TX_ERR_FLAGS);
+
break;
}
@@ -968,6 +972,9 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
bp->hw_stats.gem.rx_overruns++;
else
bp->hw_stats.macb.rx_overruns++;
+
+ if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
+ macb_writel(bp, ISR, MACB_BIT(ISR_ROVR));
}
if (status & MACB_BIT(HRESP)) {
@@ -977,6 +984,9 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
* (work queue?)
*/
netdev_err(dev, "DMA bus error: HRESP not OK\n");
+
+ if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
+ macb_writel(bp, ISR, MACB_BIT(HRESP));
}
status = macb_readl(bp, ISR);
--
1.9.2.1.g06c4abd
--
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] net: macb: Pass same size to DMA_UNMAP as used for DMA_MAP
Just as commit "net: macb: DMA-unmap full rx-buffer" (48330e08fa168395b9fd9f369f06cca1df204361), pass the size that was used for mapping the memory also to the unmap routine to avoid warnings from the DMA_API. Signed-off-by: Soren Brinkmann --- drivers/net/ethernet/cadence/macb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c index ca97005e24b4..18fdcd9d51b3 100644 --- a/drivers/net/ethernet/cadence/macb.c +++ b/drivers/net/ethernet/cadence/macb.c @@ -1113,7 +1113,7 @@ static void gem_free_rx_buffers(struct macb *bp) desc = >rx_ring[i]; addr = MACB_BF(RX_WADDR, MACB_BFEXT(RX_WADDR, desc->addr)); - dma_unmap_single(>pdev->dev, addr, skb->len, + dma_unmap_single(>pdev->dev, addr, bp->rx_buffer_size, DMA_FROM_DEVICE); dev_kfree_skb_any(skb); skb = NULL; -- 1.9.2.1.g06c4abd -- 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 4/5] net: macb: Remove 'unlikely' optimization
Coverage data suggests that the unlikely case of receiving data while
the receive handler is running may not be that unlikely.
Coverage data after running iperf for a while:
91320: 891:work_done = bp->macbgem_ops.mog_rx(bp, budget);
91320: 892:if (work_done < budget) {
2362: 893:napi_complete(napi);
-: 894:
-: 895:/* Packets received while interrupts were
disabled */
4724: 896:status = macb_readl(bp, RSR);
2362: 897:if (unlikely(status)) {
762: 898:if (bp->caps &
MACB_CAPS_ISR_CLEAR_ON_WRITE)
762: 899:macb_writel(bp, ISR,
MACB_BIT(RCOMP));
-: 900:napi_reschedule(napi);
-: 901:} else {
1600: 902:macb_writel(bp, IER, MACB_RX_INT_FLAGS);
-: 903:}
-: 904:}
Signed-off-by: Soren Brinkmann
---
drivers/net/ethernet/cadence/macb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 3f4b8ee0b0e7..3e13aa31548a 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -893,7 +893,7 @@ static int macb_poll(struct napi_struct *napi, int budget)
/* Packets received while interrupts were disabled */
status = macb_readl(bp, RSR);
- if (unlikely(status)) {
+ if (status) {
if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
macb_writel(bp, ISR, MACB_BIT(RCOMP));
napi_reschedule(napi);
--
1.9.2.1.g06c4abd
--
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] net: macb: Fix race between HW and driver
Under "heavy" RX load, the driver cannot handle the descriptors fast
enough. In detail, when a descriptor is consumed, its used flag is
cleared and once the RX budget is consumed all descriptors with a
cleared used flag are prepared to receive more data. Under load though,
the HW may constantly receive more data and use those descriptors with a
cleared used flag before they are actually prepared for next usage.
The head and tail pointers into the RX-ring should always be valid and
we can omit clearing and checking of the used flag.
Signed-off-by: Soren Brinkmann
---
---
drivers/net/ethernet/cadence/macb.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 3e13aa31548a..e9daa072ebb4 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -599,25 +599,16 @@ static void gem_rx_refill(struct macb *bp)
{
unsigned intentry;
struct sk_buff *skb;
- struct macb_dma_desc*desc;
dma_addr_t paddr;
while (CIRC_SPACE(bp->rx_prepared_head, bp->rx_tail, RX_RING_SIZE) > 0)
{
- u32 addr, ctrl;
-
entry = macb_rx_ring_wrap(bp->rx_prepared_head);
- desc = >rx_ring[entry];
/* Make hw descriptor updates visible to CPU */
rmb();
- addr = desc->addr;
- ctrl = desc->ctrl;
bp->rx_prepared_head++;
- if ((addr & MACB_BIT(RX_USED)))
- continue;
-
if (bp->rx_skbuff[entry] == NULL) {
/* allocate sk_buff for this free entry in ring */
skb = netdev_alloc_skb(bp->dev, bp->rx_buffer_size);
@@ -698,7 +689,6 @@ static int gem_rx(struct macb *bp, int budget)
if (!(addr & MACB_BIT(RX_USED)))
break;
- desc->addr &= ~MACB_BIT(RX_USED);
bp->rx_tail++;
count++;
--
1.9.2.1.g06c4abd
--
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] net: macb: Re-enable RX interrupt only when RX is done
When data is received during the driver processing received data the
NAPI is re-scheduled. In that case the RX interrupt should not be
re-enabled.
Signed-off-by: Soren Brinkmann
---
drivers/net/ethernet/cadence/macb.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index e38fe39d9589..3f4b8ee0b0e7 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -891,16 +891,15 @@ static int macb_poll(struct napi_struct *napi, int budget)
if (work_done < budget) {
napi_complete(napi);
- /*
-* We've done what we can to clean the buffers. Make sure we
-* get notified when new packets arrive.
-*/
- macb_writel(bp, IER, MACB_RX_INT_FLAGS);
-
/* Packets received while interrupts were disabled */
status = macb_readl(bp, RSR);
- if (unlikely(status))
+ if (unlikely(status)) {
+ if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
+ macb_writel(bp, ISR, MACB_BIT(RCOMP));
napi_reschedule(napi);
+ } else {
+ macb_writel(bp, IER, MACB_RX_INT_FLAGS);
+ }
}
/* TODO: Handle errors */
--
1.9.2.1.g06c4abd
--
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] net: macb: Fixes
Hi Nicolas, I think I found the cause of the issue I told you about. Looks like driver and HW are racing (a few more details in the commit message). On my way finding that, I found a few more minor issues which are fixed in the first patches. The last one is "fixing" the actual race. I don't know if I overlooked anything here, but this seems to work fine on Zynq. Thanks, Sören Soren Brinkmann (5): net: macb: Pass same size to DMA_UNMAP as used for DMA_MAP net: macb: Clear interrupt flags net: macb: Re-enable RX interrupt only when RX is done net: macb: Remove 'unlikely' optimization net: macb: Fix race between HW and driver drivers/net/ethernet/cadence/macb.c | 35 +-- 1 file changed, 17 insertions(+), 18 deletions(-) -- 1.9.2.1.g06c4abd -- 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: lock_task_sighand() && rcu_boost()
On Sun, May 04, 2014 at 09:17:57PM +0200, Oleg Nesterov wrote:
> On 05/04, Paul E. McKenney wrote:
> >
> > On Sat, May 03, 2014 at 06:11:33PM +0200, Oleg Nesterov wrote:
> > >
> > > OK, if we can't rcu_read_unlock() with irqs disabled, then we can at least
> > > cleanup it (and document the problem).
> >
> > Just to clarify (probably unnecessarily), it is OK to invoke
> > rcu_read_unlock()
> > with irqs disabled, but only if preemption has been disabled throughout
> > the entire RCU read-side critical section.
>
> Yes, yes, I understand, thanks.
>
> > > and add rcu_read_unlock() into unlock_task_sighand().
> >
> > That should also work.
>
> OK.
>
> > > But. I simply can't understand why lockdep should complain? Why it is bad
> > > to lock/unlock ->wait_lock with irqs disabled?
> >
> > Well, lockdep doesn't -always- complain, and some cases are OK.
> >
> > The problem is that if the RCU read-side critical section has been
> > preempted, and if this task gets RCU priority-boosted in the meantime,
> > then the task will need to acquire scheduler rq and pi locks at
> > rcu_read_unlock() time.
>
> Yes,
>
> > If the reason that interrupts are disabled at
> > rcu_read_unlock() time is that either rq or pi locks are held (or some
> > other locks are held that are normally acquired while holding rq or
> > pi locks), then we can deadlock. And lockdep will of course complain.
>
> Yes. but not in this case?
>
> > If I recall corectly, at one point, the ->siglock lock was acquired
> > while holding the rq locks, which would have resulted in lockdep
> > complaints.
>
> No, this must not be possible. signal_wake_up_state() was always called
> under ->siglock and it does wake_up_state() which takes rq/pi locks.
>
> And if lock_task_sighand() is preempted after rcu_read_lock(), then the
> caller doesn't hold any lock.
>
> So perhaps we can revert a841796f11c90d53 ?
Or just update it, your choice.
> Otherwise please see below.
>
> > Hmmm... A better description of the bad case might be as follows:
> >
> > Deadlock can occur if you have an RCU read-side critical
> > section that is anywhere preemptible, and where the outermost
> > rcu_read_unlock() is invoked while holding and lock acquired
> > by either wakeup_next_waiter() or rt_mutex_adjust_prio(),
> > or while holding any lock that is ever acquired while holding
> > one of those locks.
> >
> > Does that help?
> >
> > Avoiding this bad case could be a bit ugly, as it is a dynamic set
> > of locks that is acquired while holding any lock acquired by either
> > wakeup_next_waiter() or rt_mutex_adjust_prio(). So I simplified the
> > rule by prohibiting invoking rcu_read_unlock() with irqs disabled
> > if the RCU read-side critical section had ever been preemptible.
>
> OK, if you prefer to enforce this rule even if (say) lock_task_sighand()
> is fine, then it needs the comment. And a cleanup ;)
Please see below for a proposed comment. Thinking more about it, I list
both rules and leave the choice to the caller. Please see the end of
this email for a patch adding a comment to rcu_read_unlock().
> We can move rcu_read_unlock() into unlock_task_sighand() as I suggested
> before, or we can simply add preempt_disable/enable into lock_(),
>
> struct sighand_struct *__lock_task_sighand(struct task_struct *tsk,
> unsigned long *flags)
> {
> struct sighand_struct *sighand;
> /*
>* COMMENT TO EXPLAIN WHY
>*/
> preempt_disable();
> rcu_read_lock();
> for (;;) {
> sighand = rcu_dereference(tsk->sighand);
> if (unlikely(sighand == NULL))
> break;
>
> spin_lock_irqsave(>siglock, *flags);
> if (likely(sighand == tsk->sighand))
> break;
> spin_unlock_irqrestore(>siglock, *flags);
> }
> rcu_read_unlock();
> preempt_enable();
>
> return sighand;
> }
>
> The only problem is the "COMMENT" above. Perhaps the "prohibit invoking
> rcu_read_unlock() with irqs disabled if ..." rule should documented
> near/above rcu_read_unlock() ? In this case that COMMENT could simply
> say "see the comment above rcu_read_unlock()".
>
> What do you think?
Looks good to me!
Thanx, Paul
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index ca6fe55913b7..17ac3c63415f 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -884,6 +884,27 @@ static inline void rcu_read_lock(void)
/**
* rcu_read_unlock() - marks the end of an RCU read-side critical section.
*
+ * In most situations, rcu_read_unlock() is immune
[PATCH] PM / suspend: Always use deepest C-state in the "freeze" sleep state
From: Rafael J. Wysocki
If freeze_enter() is called, we want to bypass the current cpuidle
governor and always use the deepest available (that is, not disabled)
C-state, because we want to save as much energy as reasonably possible
then and runtime latency constraints don't matter at that point, since
the system is in a sleep state anyway.
Signed-off-by: Rafael J. Wysocki
---
This is on top of https://patchwork.kernel.org/patch/4071541/ .
---
drivers/cpuidle/cpuidle.c | 45 -
include/linux/cpuidle.h |2 ++
kernel/power/suspend.c|2 ++
3 files changed, 48 insertions(+), 1 deletion(-)
Index: linux-pm/drivers/cpuidle/cpuidle.c
===
--- linux-pm.orig/drivers/cpuidle/cpuidle.c
+++ linux-pm/drivers/cpuidle/cpuidle.c
@@ -32,6 +32,7 @@ LIST_HEAD(cpuidle_detected_devices);
static int enabled_devices;
static int off __read_mostly;
static int initialized __read_mostly;
+static bool use_deepest_state __read_mostly;
int cpuidle_disabled(void)
{
@@ -65,6 +66,45 @@ int cpuidle_play_dead(void)
}
/**
+ * cpuidle_use_deepest_state - Enable/disable the "deepest idle" mode.
+ * @enable: Whether enable or disable the feature.
+ *
+ * If the "deepest idle" mode is enabled, cpuidle will ignore the governor and
+ * always use the state with the greatest exit latency (out of the states that
+ * are not disabled).
+ *
+ * This function can only be called after cpuidle_pause() to avoid races.
+ */
+void cpuidle_use_deepest_state(bool enable)
+{
+ use_deepest_state = enable;
+}
+
+/**
+ * cpuidle_find_deepest_state - Find the state of the greatest exit latency.
+ * @drv: cpuidle driver for a given CPU.
+ * @dev: cpuidle device for a given CPU.
+ */
+static int cpuidle_find_deepest_state(struct cpuidle_driver *drv,
+ struct cpuidle_device *dev)
+{
+ unsigned int latency_req = 0;
+ int i, ret = CPUIDLE_DRIVER_STATE_START - 1;
+
+ for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) {
+ struct cpuidle_state *s = >states[i];
+ struct cpuidle_state_usage *su = >states_usage[i];
+
+ if (s->disabled || su->disable || s->exit_latency <=
latency_req)
+ continue;
+
+ latency_req = s->exit_latency;
+ ret = i;
+ }
+ return ret;
+}
+
+/**
* cpuidle_enter_state - enter the state and update stats
* @dev: cpuidle device for this cpu
* @drv: cpuidle driver for this cpu
@@ -124,6 +164,9 @@ int cpuidle_select(struct cpuidle_driver
if (!drv || !dev || !dev->enabled)
return -EBUSY;
+ if (unlikely(use_deepest_state))
+ return cpuidle_find_deepest_state(drv, dev);
+
return cpuidle_curr_governor->select(drv, dev);
}
@@ -155,7 +198,7 @@ int cpuidle_enter(struct cpuidle_driver
*/
void cpuidle_reflect(struct cpuidle_device *dev, int index)
{
- if (cpuidle_curr_governor->reflect)
+ if (cpuidle_curr_governor->reflect && !unlikely(use_deepest_state))
cpuidle_curr_governor->reflect(dev, index);
}
Index: linux-pm/include/linux/cpuidle.h
===
--- linux-pm.orig/include/linux/cpuidle.h
+++ linux-pm/include/linux/cpuidle.h
@@ -143,6 +143,7 @@ extern void cpuidle_resume(void);
extern int cpuidle_enable_device(struct cpuidle_device *dev);
extern void cpuidle_disable_device(struct cpuidle_device *dev);
extern int cpuidle_play_dead(void);
+extern void cpuidle_use_deepest_state(bool enable);
extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device
*dev);
#else
@@ -175,6 +176,7 @@ static inline int cpuidle_enable_device(
{return -ENODEV; }
static inline void cpuidle_disable_device(struct cpuidle_device *dev) { }
static inline int cpuidle_play_dead(void) {return -ENODEV; }
+static inline void cpuidle_use_deepest_state(bool enable) {}
static inline struct cpuidle_driver *cpuidle_get_cpu_driver(
struct cpuidle_device *dev) {return NULL; }
#endif
Index: linux-pm/kernel/power/suspend.c
===
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -54,9 +54,11 @@ static void freeze_begin(void)
static void freeze_enter(void)
{
+ cpuidle_use_deepest_state(true);
cpuidle_resume();
wait_event(suspend_freeze_wait_head, suspend_freeze_wake);
cpuidle_pause();
+ cpuidle_use_deepest_state(false);
}
void freeze_wake(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 2/2] cpuidle / menu: Return error code if there are no suitable states
On Friday, May 02, 2014 03:19:55 PM Daniel Lezcano wrote: > On 05/02/2014 02:20 PM, Rafael J. Wysocki wrote: > > On Friday, May 02, 2014 10:47:48 AM Daniel Lezcano wrote: > >> On 04/30/2014 01:16 AM, Rafael J. Wysocki wrote: > >>> On Tuesday, April 29, 2014 01:28:03 AM Rafael J. Wysocki wrote: > On Monday, April 28, 2014 01:14:32 PM Daniel Lezcano wrote: > > On 04/27/2014 02:55 PM, Rafael J. Wysocki wrote: > >> > >> [ ... ] > >> > >>> --- > >>> From: Rafael J. Wysocki > >>> Subject: cpuidle / menu: Return (-1) if there are no suitable states > >>> > >>> If there is a PM QoS latency limit and all of the sufficiently shallow > >>> C-states are disabled, the cpuidle menu governor returns 0 which on > >>> some systems is CPUIDLE_DRIVER_STATE_START and shouldn't be returned > >>> if that C-state has been disabled. > >>> > >>> Fix the issue by modifying the menu governor to return (-1) in such > >>> situations. > >>> > >>> Signed-off-by: Rafael J. Wysocki > >>> --- > >>>drivers/cpuidle/governors/menu.c |2 +- > >>>include/linux/cpuidle.h |2 ++ > >>>2 files changed, 3 insertions(+), 1 deletion(-) > >>> > >>> Index: linux-pm/drivers/cpuidle/governors/menu.c > >>> === > >>> --- linux-pm.orig/drivers/cpuidle/governors/menu.c > >>> +++ linux-pm/drivers/cpuidle/governors/menu.c > >>> @@ -296,7 +296,7 @@ static int menu_select(struct cpuidle_dr > >>> data->needs_update = 0; > >>> } > >>> > >>> - data->last_state_idx = 0; > >>> + data->last_state_idx = CPUIDLE_DRIVER_STATE_START - 1; > >> > >> In case of x86, CPUIDLE_DRIVER_STATE_START will be 1, so the select > >> function could return 0 even this one is disabled and this is not what > >> you want to happen, no ? > > > > OK, so that's a choice. We can choose to do the above or to return an error > > code if the 0 state is disabled too. The above is arguably simpler and > > matches the idea that 0 is a "fallback" state on x86. > > > > Of course, it also is confusing, because user space *can* set "disable" for > > the 0 state on x86, but that actually has no effect today AFAICS. > > Yes, the poll state is very rarely selected. > > Regarding the description of this patch, I think it would make sense to > move the duplicate pm qos checks to the cpuidle_idle_call function > directly and pass the latency req to the select function, so the zero > latency check could be done by the caller before entering select. I would prefer to have them in cpuidle_select() for various reasons (one of them being to avoid the need to pass latency_req from cpuidle_idle_call() to cpuidle_select() which isn't necessary). > > I'm mostly worried about systems where CPUIDLE_DRIVER_STATE_START is 0 > > and where menu_select() explicitly checks "disabled" and then it returns > > 0 anyway if it cannot find any other suitable state. > > For the ARM platform, the state0 and the default idle function are the > same, so disabling this state will result in calling the same idle function. > > > In my opinion that needs to be made consistent, but I don't care too much > > about > > which way as long as the change is not too intrusive. > > I think we can live with this patch until we remove the > CPUIDLE_DRIVER_STATE_START macro. It was introduced to factor out a > couple of drivers and now it results in a confusing-hard-to-fix-code. OK Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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/HACK] x86: Fast return to kernel
On 05/04/2014 02:31 PM, Linus Torvalds wrote:
> On Sun, May 4, 2014 at 12:59 PM, H. Peter Anvin
> wrote:
>>
>> Maybe let userspace sit in a tight loop doing RDTSC, and look for data
>> points too far apart to have been uninterrupted?
>
> That won't work, since Andy's patch improves on the "interrupt
> happened in kernel space", not on the user-space interrupt case.
>
I was thinking about your proposal, not Andy's.
> But some variation on that with a kernel module that does something like
>
> - take over one CPU and force tons of timer interrupts on that CPU
> using the local APIC
>
> - for (say) ten billion cycles, do something like this in that kernel module:
>
>#define TEN_BILLION (100)
>
> unsigned long prev = 0, sum = 0, end = rdtsc() + TEN_BILLION;
> for (;;) {
> unsigned long tsc = rdtsc();
> if (tsc > end)
> break;
> if (tsc < prev + 500) {
> sum += tsc - prev;
> }
> prev = tsc;
> }
>
> and see how big a fraction of the 10 billion cycles you capture in
> 'sum'. The bigger the fraction, the less time the timer interrupts
> stole from your CPU.
>
> That "500" is just a random cut-off. Any interrupt will take more than
> that many TSC cycles. So the above basically counts how much
> uninterrupted time that thread gets.
Yes, same idea, but in a kernel module.
-hpa
--
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 v5 1/1] Driver for Beckhoff CX5020 EtherCAT master module.
On Sun, May 04, 2014 at 11:19:28PM +0200, Francois Romieu wrote: > Darek Marcinkiewicz : > > On Sun, May 04, 2014 at 08:43:51PM +0200, Francois Romieu wrote: > [...] > > > Regarding tx_dnext updates, you may add a short notice in > > > ec_bhf_start_xmit > > > and ec_bhf_process_tx explaining that the periodic poller will somehow end > > > working with the right value, whence no (smp_)barrier at all. > > > > > Hmm, good point. I am not really sure that it is not a race. So, I've added > > memory barriers for the case when the tx ring becomes full. > > Without memory barrier, the hrtimer poller may be wrong but 1) it will > always be pessimistic and 2) it won't last. It would be sloppy though. > > Did you have some time to test the latest version ? > Yes, I have this code continuously running and it looks good. This is a regular application that I have running now, so not all interesting edge cases might have been exercised, though. -- DM -- 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 3.14 000/158] 3.14.3-stable review
On 05/04/2014 01:27 PM, Greg Kroah-Hartman wrote: On Sun, May 04, 2014 at 10:19:25AM -0700, Guenter Roeck wrote: On 05/04/2014 08:38 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.3 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue May 6 15:38:47 UTC 2014. Anything received after that time might be too late. Build results: total: 127 pass: 121 skipped: 4 fail: 2 Qemu tests all passed. Additional failure is from new build target unicore32:defconfig, which fails in all releases. The second failure is powerpc:allmodconfig which, together with powerpc:allyesconfig, fails to build in 3.14 and later kernels. Results are therefore as expected. Details are available at http://server.roeck-us.net:8010/builders. If unicore32 doesn't build on any kernel version, should we just drop the whole arch? Idea was to put the maintainer on notice. If nothing changes, that may be a good idea. I'd suggest the same for powerpc, but odds are, there are still users :) Yes, the company paying my salary, for example :-). But then if failure to build allmodconfig/allyesconfig is a criteria, arm would be a prime target as well ... Might be a discussion point for the kernel summit, though: What are criteria for an architecture to be accepted, and for it to remain in the kernel ? Availability of a pre-built tool set (score drops out)? defconfig build failure (unicore32 be gone) ? Something else ? Guenter -- 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/HACK] x86: Fast return to kernel
On Sun, May 4, 2014 at 12:59 PM, H. Peter Anvin wrote:
>
> Maybe let userspace sit in a tight loop doing RDTSC, and look for data
> points too far apart to have been uninterrupted?
That won't work, since Andy's patch improves on the "interrupt
happened in kernel space", not on the user-space interrupt case.
But some variation on that with a kernel module that does something like
- take over one CPU and force tons of timer interrupts on that CPU
using the local APIC
- for (say) ten billion cycles, do something like this in that kernel module:
#define TEN_BILLION (100)
unsigned long prev = 0, sum = 0, end = rdtsc() + TEN_BILLION;
for (;;) {
unsigned long tsc = rdtsc();
if (tsc > end)
break;
if (tsc < prev + 500) {
sum += tsc - prev;
}
prev = tsc;
}
and see how big a fraction of the 10 billion cycles you capture in
'sum'. The bigger the fraction, the less time the timer interrupts
stole from your CPU.
That "500" is just a random cut-off. Any interrupt will take more than
that many TSC cycles. So the above basically counts how much
uninterrupted time that thread gets.
Hmm?
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 net] bridge: Add port flap detection
There has been a number incidents recently where customers running KVM have
reported that VM hosts on different Hypervisors are unreachable. Based on pcap
traces we found that the bridge was broadcasting the ARP request out onto the
network. However some NICs have an inbuilt switch which on occasions were
broadcasting the VMs ARP request back through the physical NIC on the
Hypervisor. This resulted in the bridge flapping ports and incorrectly learning
that the VMs mac address was external. As a result the ARP reply was directed
back onto the external network and VM never updated it's ARP cache. This patch
will detect port flapping and log a message so that this condition can be
detected earlier.
Signed-off-by: Jon Maxwell
---
net/bridge/br_fdb.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 9203d5a..c08607b 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -507,6 +507,13 @@ void br_fdb_update(struct net_bridge *br, struct
net_bridge_port *source,
source->dev->name);
} else {
/* fastpath: update of existing entry */
+ if (source->port_no != fdb->dst->port_no &&
+ net_ratelimit())
+ br_warn(br, "Port flapping detected source
entry dev = %s mac = %pM, port_no = %d\n existing entry dev = %s mac = %pM,
port_no = %d\n",
+ source->dev->name,
+ addr, source->port_no,
+ fdb->dst->dev->name, addr,
+ fdb->dst->port_no);
fdb->dst = source;
fdb->updated = jiffies;
if (unlikely(added_by_user))
--
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] staging: vt6655: correct coding style issue
On Sun, May 04, 2014 at 09:52:09PM +0200, Clément Calmels wrote: > Remove C99 comment and rewrite lines over 80 characters. > Warnings and error found by checkpatch.pl script. > > Signed-off-by: Clément Calmels > --- > drivers/staging/vt6655/tmacro.h | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/vt6655/tmacro.h b/drivers/staging/vt6655/tmacro.h > index 59c6e72..264c6ed 100644 > --- a/drivers/staging/vt6655/tmacro.h > +++ b/drivers/staging/vt6655/tmacro.h > @@ -44,17 +44,22 @@ > #define LOWORD(d) ((unsigned short)(d)) > #endif > #if !defined(HIWORD) > -#define HIWORD(d) ((unsigned short)unsigned long)(d)) >> 16) & > 0x)) > +#define HIWORD(d)\ > + ((unsigned short)unsigned long)(d)) >> 16) & 0x)) > #endif > > #define LODWORD(q) ((q).u.dwLowDword) > #define HIDWORD(q) ((q).u.dwHighDword) > > #if !defined(MAKEWORD) > -#define MAKEWORD(lb, hb)((unsigned short)(((unsigned char)(lb)) | > (((unsigned short)((unsigned char)(hb))) << 8))) > +#define MAKEWORD(lb, hb)\ > + ((unsigned short)(((unsigned char)(lb)) \ > + | (((unsigned short)((unsigned char)(hb))) << 8))) > #endif > #if !defined(MAKEDWORD) > -#define MAKEDWORD(lw, hw) ((unsigned long)(((unsigned short)(lw)) | > (((unsigned long)((unsigned short)(hw))) << 16))) > +#define MAKEDWORD(lw, hw)\ > + ((unsigned long)(((unsigned short)(lw)) \ > + | (((unsigned long)((unsigned short)(hw))) << 16))) > #endif > > -#endif // __TMACRO_H__ > +#endif /* __TMACRO_H__ */ Why not just switch to use the built-in macros the kernel provides for this? greg k-h -- 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] mm: Fix force_flush behavior in zap_pte_range()
On Sun, May 4, 2014 at 1:42 PM, Richard Weinberger wrote: > > I cannot tell why UML has it's own tlb gather logic, I suspect nobody > cared so far to clean up the code. > That said, I've converted it today to the generic gather logic and it works. > Sadly I'm still facing the same issues (sigh!). Ok, so it's not the gathering. I'm guessing it's because the tlb flush patterns change (we now flush partial areas for shared mappings with dirty pages - it used to be that you'd only ever see full ranges before), and that shows some issue with the whole "fix_range()" thing. So then the kill(9) results in stopping the page table zapping in the middle, and then you end up with that "Bad rss-counter" for the file mapping. Can you try to debug it to see where that "ret" gets set in fix_range_common() (well, likely deeper, I presume it comes from update_pte_range() or whatever), to see exactly _what_ it is that starts failing? 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/
Re: [PATCH v5 1/1] Driver for Beckhoff CX5020 EtherCAT master module.
Darek Marcinkiewicz : > On Sun, May 04, 2014 at 08:43:51PM +0200, Francois Romieu wrote: [...] > > Regarding tx_dnext updates, you may add a short notice in ec_bhf_start_xmit > > and ec_bhf_process_tx explaining that the periodic poller will somehow end > > working with the right value, whence no (smp_)barrier at all. > > > Hmm, good point. I am not really sure that it is not a race. So, I've added > memory barriers for the case when the tx ring becomes full. Without memory barrier, the hrtimer poller may be wrong but 1) it will always be pessimistic and 2) it won't last. It would be sloppy though. Did you have some time to test the latest version ? -- Ueimor -- 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: [3.15rc1] BUG at mm/filemap.c:202!
Am 04.05.2014 22:37, schrieb Hugh Dickins: > On Sat, 3 May 2014, Richard Weinberger wrote: >> On Thu, May 1, 2014 at 6:20 PM, Richard Weinberger >> wrote: >>> On Wed, Apr 16, 2014 at 10:40 PM, Hugh Dickins wrote: Help! >>> >>> Using a trinity as of today I'm able to trigger this bug on UML within >>> seconds. >>> If you want me to test patch, I can help. >>> >>> I'm also observing one strange fact, I can trigger this on any kernel >>> version. >>> So far I've managed UML to crash on 3.0 to 3.15-rc... >> >> After digging deeper into UML's mmu and tlb code I've found issues and >> fixed them. >> >> But I'm still facing this issue. Although triggering the BUG_ON() is >> not so easy as before >> I can trigger "BUG: Bad rss-counter ..." very easily. >> Now the interesting fact, with my UML mmu and flb fixes applied it >> happens only on kernels >= 3.14. >> If it helps I can try to bisect it. > > Thanks a lot for trying, but from other mail it looks like your > bisection got blown off course ;( Yeah, looks like the issue I'm facing on UML is a completely different story. Although the symptoms are identical. :-( > I expect for the moment you'll want to concentrate on getting UML's > TLB flushing back on track with 3.15-rc. This is what I'm currently doing. But it might take some time as I'm a mm novice. > Once you have that sorted out, I wouldn't be surprised if the same > changes turn out to fix your "Bad rss-counter"s on 3.14 also. > > If not, and if you do still have time to bisect back between 3.13 and > 3.14 to find where things went wrong, it will be a bit tedious in that > you would probably have to apply > > 887843961c4b "mm: fix bad rss-counter if remap_file_pages raced migration" > 7e09e738afd2 "mm: fix swapops.h:131 bug if remap_file_pages raced migration" > > at each stage, to avoid those now-known bugs which trinity became rather > good at triggering. Perhaps other fixes needed, those the two I remember. > > Please don't worry if you don't have time for this, that's understandable. > > Or is UML so contrary that one of those commits actually brings on the > problem for you? Hehe, no. I gave it a quick try, both 887843961c4b and 7e09e738afd2 seem to be unrelated to the issues I see. Thanks, //richard -- 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] mm: Fix force_flush behavior in zap_pte_range()
Am 04.05.2014 20:31, schrieb Linus Torvalds: >> With your patch applied I see lots of BUG: Bad rss-counter state messages on >> UML (x86_32) >> when fuzzing with trinity the mremap syscall. >> And sometimes I face BUG at mm/filemap.c:202. > > I'm suspecting that it's some UML bug that is triggered by the > changes. UML has its own tlb gather logic (I'm not quite sure why), I > wonder what's up. I cannot tell why UML has it's own tlb gather logic, I suspect nobody cared so far to clean up the code. That said, I've converted it today to the generic gather logic and it works. Sadly I'm still facing the same issues (sigh!). > Also, are the messages coming from UML or from the host kernel? I'm > assuming they are UML. >From UML directly. >> After killing a trinity child I start observing the said issues. >> >> e.g. >> fix_range_common: failed, killing current process: 841 >> fix_range_common: failed, killing current process: 842 >> fix_range_common: failed, killing current process: 843 >> BUG: Bad rss-counter state mm:28e69600 idx:0 val:2 > > That "idx=0" means that it's MM_FILEPAGES. Apparently the killing > ended up resulting in not freeing all the file mapping pte's. > > So I'm assuming the real issue is that fix_range_common failure that > triggers this. > > Exactly why the new tlb flushing triggers this is not entirely clear, > but I'd take a look at how UML reacts to the whole fact that a forced > flush (which never happened before, because your __tlb_remove_page() > doesn't batch anything up and always returns 1) updates the tlb > start/end fields as it does the tlb_flush_mmu_tlbonly(). Thanks for the pointer, I'll dig deeper into the issue. Thanks, //richard -- 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: [3.15rc1] BUG at mm/filemap.c:202!
On Sat, 3 May 2014, Richard Weinberger wrote: > On Thu, May 1, 2014 at 6:20 PM, Richard Weinberger > wrote: > > On Wed, Apr 16, 2014 at 10:40 PM, Hugh Dickins wrote: > >> > >> Help! > > > > Using a trinity as of today I'm able to trigger this bug on UML within > > seconds. > > If you want me to test patch, I can help. > > > > I'm also observing one strange fact, I can trigger this on any kernel > > version. > > So far I've managed UML to crash on 3.0 to 3.15-rc... > > After digging deeper into UML's mmu and tlb code I've found issues and > fixed them. > > But I'm still facing this issue. Although triggering the BUG_ON() is > not so easy as before > I can trigger "BUG: Bad rss-counter ..." very easily. > Now the interesting fact, with my UML mmu and flb fixes applied it > happens only on kernels >= 3.14. > If it helps I can try to bisect it. Thanks a lot for trying, but from other mail it looks like your bisection got blown off course ;( I expect for the moment you'll want to concentrate on getting UML's TLB flushing back on track with 3.15-rc. Once you have that sorted out, I wouldn't be surprised if the same changes turn out to fix your "Bad rss-counter"s on 3.14 also. If not, and if you do still have time to bisect back between 3.13 and 3.14 to find where things went wrong, it will be a bit tedious in that you would probably have to apply 887843961c4b "mm: fix bad rss-counter if remap_file_pages raced migration" 7e09e738afd2 "mm: fix swapops.h:131 bug if remap_file_pages raced migration" at each stage, to avoid those now-known bugs which trinity became rather good at triggering. Perhaps other fixes needed, those the two I remember. Please don't worry if you don't have time for this, that's understandable. Or is UML so contrary that one of those commits actually brings on the problem for you? As to the BUG_ON(page_mapped(page)), I still have nothing to suggest. Hugh -- 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/4] mm: zpool: implement zsmalloc shrinking
On Fri, May 2, 2014 at 4:01 PM, Seth Jennings wrote: > On Sat, Apr 26, 2014 at 04:37:31PM +0800, Weijie Yang wrote: >> On Sat, Apr 19, 2014 at 11:52 PM, Dan Streetman wrote: >> > Add zs_shrink() and helper functions to zsmalloc. Update zsmalloc >> > zs_create_pool() creation function to include ops param that provides >> > an evict() function for use during shrinking. Update helper function >> > fix_fullness_group() to always reinsert changed zspages even if the >> > fullness group did not change, so they are updated in the fullness >> > group lru. Also update zram to use the new zsmalloc pool creation >> > function but pass NULL as the ops param, since zram does not use >> > pool shrinking. >> > >> >> I only review the code without test, however, I think this patch is >> not acceptable. >> >> The biggest problem is it will call zswap_writeback_entry() under lock, >> zswap_writeback_entry() may sleep, so it is a bug. see below >> >> The 3/4 patch has a lot of #ifdef, I don't think it's a good kind of >> abstract way. >> >> What about just disable zswap reclaim when using zsmalloc? > > I agree here. Making a generic allocator layer and zsmalloc reclaim > support should be two different efforts, since zsmalloc reclaim is > fraught with peril. fair enough - I'm fairly sure it's doable with only minimal changes to the current patch, but it's certainly true that there's no reason it has to be done in the same patchset as the generic layer. I'll remove it from the v2 patchset. > The generic layer can be done though, as long as you provide a way for > the backend to indicate that it doesn't support reclaim, which just > results in lru-inverse overflow to the swap device at the zswap layer. > Hopefully, if the user overrides the default to use zsmalloc, they > understand the implications and have sized their workload properly. > > Also, the fallback logic shouldn't be in this generic layer. It should > not be transparent to the user. The user (in this case zswap) should > implement the fallback if they care to have it. The generic allocator > layer makes it trivial for the user to implement. ok, makes sense, certainly when there's currently only 1 user and 2 backends ;-) > > Thanks, > Seth -- 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 3.14 000/158] 3.14.3-stable review
On Sun, May 04, 2014 at 10:19:25AM -0700, Guenter Roeck wrote: > On 05/04/2014 08:38 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.14.3 release. > > There are 158 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Tue May 6 15:38:47 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 127 pass: 121 skipped: 4 fail: 2 > > Qemu tests all passed. > > Additional failure is from new build target unicore32:defconfig, which fails > in all releases. The second failure is powerpc:allmodconfig which, together > with powerpc:allyesconfig, fails to build in 3.14 and later kernels. > Results are therefore as expected. > > Details are available at http://server.roeck-us.net:8010/builders. > If unicore32 doesn't build on any kernel version, should we just drop the whole arch? I'd suggest the same for powerpc, but odds are, there are still users :) thanks, greg k-h -- 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/
