* [U-Boot] [PATCH 1/3] iMX28: Add USB and USB PHY register definitions
From: Marek Vasut @ 2011-10-24 11:21 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319455296-15996-1-git-send-email-marek.vasut@gmail.com>
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
Cc: Remy Bohmer <linux@bohmer.net>
---
arch/arm/include/asm/arch-mx28/regs-usb.h | 178 ++++++++++++++++++++++++++
arch/arm/include/asm/arch-mx28/regs-usbphy.h | 151 ++++++++++++++++++++++
2 files changed, 329 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-mx28/regs-usb.h
create mode 100644 arch/arm/include/asm/arch-mx28/regs-usbphy.h
diff --git a/arch/arm/include/asm/arch-mx28/regs-usb.h b/arch/arm/include/asm/arch-mx28/regs-usb.h
new file mode 100644
index 0000000..ea61de8
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx28/regs-usb.h
@@ -0,0 +1,178 @@
+/*
+ * Freescale i.MX28 USB OTG Register Definitions
+ *
+ * Copyright (C) 2011 Marek Vasut <marek.vasut@gmail.com>
+ * on behalf of DENX Software Engineering GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef __REGS_USB_H__
+#define __REGS_USB_H__
+
+struct mx28_usb_regs {
+ uint32_t hw_usbctrl_id; /* 0x000 */
+ uint32_t hw_usbctrl_hwgeneral; /* 0x004 */
+ uint32_t hw_usbctrl_hwhost; /* 0x008 */
+ uint32_t hw_usbctrl_hwdevice; /* 0x00c */
+ uint32_t hw_usbctrl_hwtxbuf; /* 0x010 */
+ uint32_t hw_usbctrl_hwrxbuf; /* 0x014 */
+
+ uint32_t reserved1[26];
+
+ uint32_t hw_usbctrl_gptimer0ld; /* 0x080 */
+ uint32_t hw_usbctrl_gptimer0ctrl; /* 0x084 */
+ uint32_t hw_usbctrl_gptimer1ld; /* 0x088 */
+ uint32_t hw_usbctrl_gptimer1ctrl; /* 0x08c */
+ uint32_t hw_usbctrl_sbuscfg; /* 0x090 */
+
+ uint32_t reserved2[27];
+
+ uint32_t hw_usbctrl_caplength; /* 0x100 */
+ uint32_t hw_usbctrl_hcsparams; /* 0x104 */
+ uint32_t hw_usbctrl_hccparams; /* 0x108 */
+
+ uint32_t reserved3[5];
+
+ uint32_t hw_usbctrl_dciversion; /* 0x120 */
+ uint32_t hw_usbctrl_dccparams; /* 0x124 */
+
+ uint32_t reserved4[6];
+
+ uint32_t hw_usbctrl_usbcmd; /* 0x140 */
+ uint32_t hw_usbctrl_usbsts; /* 0x144 */
+ uint32_t hw_usbctrl_usbintr; /* 0x148 */
+ uint32_t hw_usbctrl_frindex; /* 0x14c */
+
+ uint32_t reserved5;
+
+ union {
+ uint32_t hw_usbctrl_periodiclistbase; /* 0x154 */
+ uint32_t hw_usbctrl_deviceaddr; /* 0x154 */
+ };
+ union {
+ uint32_t hw_usbctrl_asynclistaddr; /* 0x158 */
+ uint32_t hw_usbctrl_endpointlistaddr; /* 0x158 */
+ };
+
+ uint32_t hw_usbctrl_ttctrl; /* 0x15c */
+ uint32_t hw_usbctrl_burstsize; /* 0x160 */
+ uint32_t hw_usbctrl_txfilltuning; /* 0x164 */
+
+ uint32_t reserved6;
+
+ uint32_t hw_usbctrl_ic_usb; /* 0x16c */
+ uint32_t hw_usbctrl_ulpi; /* 0x170 */
+
+ uint32_t reserved7;
+
+ uint32_t hw_usbctrl_endptnak; /* 0x178 */
+ uint32_t hw_usbctrl_endptnaken; /* 0x17c */
+
+ uint32_t reserved8;
+
+ uint32_t hw_usbctrl_portsc1; /* 0x184 */
+
+ uint32_t reserved9[7];
+
+ uint32_t hw_usbctrl_otgsc; /* 0x1a4 */
+ uint32_t hw_usbctrl_usbmode; /* 0x1a8 */
+ uint32_t hw_usbctrl_endptsetupstat; /* 0x1ac */
+ uint32_t hw_usbctrl_endptprime; /* 0x1b0 */
+ uint32_t hw_usbctrl_endptflush; /* 0x1b4 */
+ uint32_t hw_usbctrl_endptstat; /* 0x1b8 */
+ uint32_t hw_usbctrl_endptcomplete; /* 0x1bc */
+ uint32_t hw_usbctrl_endptctrl0; /* 0x1c0 */
+ uint32_t hw_usbctrl_endptctrl1; /* 0x1c4 */
+ uint32_t hw_usbctrl_endptctrl2; /* 0x1c8 */
+ uint32_t hw_usbctrl_endptctrl3; /* 0x1cc */
+ uint32_t hw_usbctrl_endptctrl4; /* 0x1d0 */
+ uint32_t hw_usbctrl_endptctrl5; /* 0x1d4 */
+ uint32_t hw_usbctrl_endptctrl6; /* 0x1d8 */
+ uint32_t hw_usbctrl_endptctrl7; /* 0x1dc */
+};
+
+#define CLKCTRL_PLL0CTRL0_LFR_SEL_MASK (0x3 << 28)
+
+#define HW_USBCTRL_ID_CIVERSION_OFFSET 29
+#define HW_USBCTRL_ID_CIVERSION_MASK (0x7 << 29)
+#define HW_USBCTRL_ID_VERSION_OFFSET 25
+#define HW_USBCTRL_ID_VERSION_MASK (0xf << 25)
+#define HW_USBCTRL_ID_REVISION_OFFSET 21
+#define HW_USBCTRL_ID_REVISION_MASK (0xf << 21)
+#define HW_USBCTRL_ID_TAG_OFFSET 16
+#define HW_USBCTRL_ID_TAG_MASK (0x1f << 16)
+#define HW_USBCTRL_ID_NID_OFFSET 8
+#define HW_USBCTRL_ID_NID_MASK (0x3f << 8)
+#define HW_USBCTRL_ID_ID_OFFSET 0
+#define HW_USBCTRL_ID_ID_MASK (0x3f << 0)
+
+#define HW_USBCTRL_HWGENERAL_SM_OFFSET 9
+#define HW_USBCTRL_HWGENERAL_SM_MASK (0x3 << 9)
+#define HW_USBCTRL_HWGENERAL_PHYM_OFFSET 6
+#define HW_USBCTRL_HWGENERAL_PHYM_MASK (0x7 << 6)
+#define HW_USBCTRL_HWGENERAL_PHYW_OFFSET 4
+#define HW_USBCTRL_HWGENERAL_PHYW_MASK (0x3 << 4)
+#define HW_USBCTRL_HWGENERAL_BWT (1 << 3)
+#define HW_USBCTRL_HWGENERAL_CLKC_OFFSET 1
+#define HW_USBCTRL_HWGENERAL_CLKC_MASK (0x3 << 1)
+#define HW_USBCTRL_HWGENERAL_RT (1 << 0)
+
+#define HW_USBCTRL_HWHOST_TTPER_OFFSET 24
+#define HW_USBCTRL_HWHOST_TTPER_MASK (0xff << 24)
+#define HW_USBCTRL_HWHOST_TTASY_OFFSET 16
+#define HW_USBCTRL_HWHOST_TTASY_MASK (0xff << 19)
+#define HW_USBCTRL_HWHOST_NPORT_OFFSET 1
+#define HW_USBCTRL_HWHOST_NPORT_MASK (0x7 << 1)
+#define HW_USBCTRL_HWHOST_HC (1 << 0)
+
+#define HW_USBCTRL_HWDEVICE_DEVEP_OFFSET 1
+#define HW_USBCTRL_HWDEVICE_DEVEP_MASK (0x1f << 1)
+#define HW_USBCTRL_HWDEVICE_DC (1 << 0)
+
+#define HW_USBCTRL_HWTXBUF_TXLCR (1 << 31)
+#define HW_USBCTRL_HWTXBUF_TXCHANADD_OFFSET 16
+#define HW_USBCTRL_HWTXBUF_TXCHANADD_MASK (0xff << 16)
+#define HW_USBCTRL_HWTXBUF_TXADD_OFFSET 8
+#define HW_USBCTRL_HWTXBUF_TXADD_MASK (0xff << 8)
+#define HW_USBCTRL_HWTXBUF_TXBURST_OFFSET 0
+#define HW_USBCTRL_HWTXBUF_TXBURST_MASK 0xff
+
+#define HW_USBCTRL_HWRXBUF_RXADD_OFFSET 8
+#define HW_USBCTRL_HWRXBUF_RXADD_MASK (0xff << 8)
+#define HW_USBCTRL_HWRXBUF_RXBURST_OFFSET 0
+#define HW_USBCTRL_HWRXBUF_RXBURST_MASK 0xff
+
+#define HW_USBCTRL_GPTIMERLD_GPTLD_OFFSET 0
+#define HW_USBCTRL_GPTIMERLD_GPTLD_MASK 0xffffff
+
+#define HW_USBCTRL_GPTIMERCTRL_GPTRUN (1 << 31)
+#define HW_USBCTRL_GPTIMERCTRL_GPTRST (1 << 30)
+#define HW_USBCTRL_GPTIMERCTRL_GPTMODE (1 << 24)
+#define HW_USBCTRL_GPTIMERCTRL_GPTCNT_OFFSET 0
+#define HW_USBCTRL_GPTIMERCTRL_GPTCNT_MASK 0xffffff
+
+#define HW_USBCTRL_SBUSCFG_AHBBURST_OFFSET 0
+#define HW_USBCTRL_SBUSCFG_AHBBURST_MASK 0x7
+#define HW_USBCTRL_SBUSCFG_AHBBURST_U_INCR 0x0
+#define HW_USBCTRL_SBUSCFG_AHBBURST_S_INCR4 0x1
+#define HW_USBCTRL_SBUSCFG_AHBBURST_S_INCR8 0x2
+#define HW_USBCTRL_SBUSCFG_AHBBURST_S_INCR16 0x3
+#define HW_USBCTRL_SBUSCFG_AHBBURST_U_INCR4 0x5
+#define HW_USBCTRL_SBUSCFG_AHBBURST_U_INCR8 0x6
+#define HW_USBCTRL_SBUSCFG_AHBBURST_U_INCR16 0x7
+
+#endif /* __REGS_USB_H__ */
diff --git a/arch/arm/include/asm/arch-mx28/regs-usbphy.h b/arch/arm/include/asm/arch-mx28/regs-usbphy.h
new file mode 100644
index 0000000..e823e19
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx28/regs-usbphy.h
@@ -0,0 +1,151 @@
+/*
+ * Freescale i.MX28 USB PHY Register Definitions
+ *
+ * Copyright (C) 2011 Marek Vasut <marek.vasut@gmail.com>
+ * on behalf of DENX Software Engineering GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef __REGS_USBPHY_H__
+#define __REGS_USBPHY_H__
+
+struct mx28_usbphy_regs {
+ mx28_reg(hw_usbphy_pwd)
+ mx28_reg(hw_usbphy_tx)
+ mx28_reg(hw_usbphy_rx)
+ mx28_reg(hw_usbphy_ctrl)
+ mx28_reg(hw_usbphy_status)
+ mx28_reg(hw_usbphy_debug)
+ mx28_reg(hw_usbphy_debug0_status)
+ mx28_reg(hw_usbphy_debug1)
+ mx28_reg(hw_usbphy_version)
+ mx28_reg(hw_usbphy_ip)
+};
+
+#define USBPHY_PWD_RXPWDRX (1 << 20)
+#define USBPHY_PWD_RXPWDDIFF (1 << 19)
+#define USBPHY_PWD_RXPWD1PT1 (1 << 18)
+#define USBPHY_PWD_RXPWDENV (1 << 17)
+#define USBPHY_PWD_TXPWDV2I (1 << 12)
+#define USBPHY_PWD_TXPWDIBIAS (1 << 11)
+#define USBPHY_PWD_TXPWDFS (1 << 10)
+
+#define USBPHY_TX_USBPHY_TX_EDGECTRL_OFFSET 26
+#define USBPHY_TX_USBPHY_TX_EDGECTRL_MASK (0x7 << 26)
+#define USBPHY_TX_USBPHY_TX_SYNC_INVERT (1 << 25)
+#define USBPHY_TX_USBPHY_TX_SYNC_MUX (1 << 24)
+#define USBPHY_TX_TXENCAL45DP (1 << 21)
+#define USBPHY_TX_TXCAL45DP_OFFSET 16
+#define USBPHY_TX_TXCAL45DP_MASK (0xf << 16)
+#define USBPHY_TX_TXENCAL45DM (1 << 13)
+#define USBPHY_TX_TXCAL45DM_OFFSET 8
+#define USBPHY_TX_TXCAL45DM_MASK (0xf << 8)
+#define USBPHY_TX_D_CAL_OFFSET 0
+#define USBPHY_TX_D_CAL_MASK 0xf
+
+#define USBPHY_RX_RXDBYPASS (1 << 22)
+#define USBPHY_RX_DISCONADJ_OFFSET 4
+#define USBPHY_RX_DISCONADJ_MASK (0x7 << 4)
+#define USBPHY_RX_ENVADJ_OFFSET 0
+#define USBPHY_RX_ENVADJ_MASK 0x7
+
+#define USBPHY_CTRL_SFTRST (1 << 31)
+#define USBPHY_CTRL_CLKGATE (1 << 30)
+#define USBPHY_CTRL_UTMI_SUSPENDM (1 << 29)
+#define USBPHY_CTRL_HOST_FORCE_LS_SE0 (1 << 28)
+#define USBPHY_CTRL_ENAUTOSET_USBCLKS (1 << 26)
+#define USBPHY_CTRL_ENAUTOCLR_USBCLKGATE (1 << 25)
+#define USBPHY_CTRL_FSDLL_RST_EN (1 << 24)
+#define USBPHY_CTRL_ENVBUSCHG_WKUP (1 << 23)
+#define USBPHY_CTRL_ENIDCHG_WKUP (1 << 22)
+#define USBPHY_CTRL_ENDPDMCHG_WKUP (1 << 21)
+#define USBPHY_CTRL_ENAUTOCLR_PHY_PWD (1 << 20)
+#define USBPHY_CTRL_ENAUTOCLR_CLKGATE (1 << 19)
+#define USBPHY_CTRL_ENAUTO_PWRON_PLL (1 << 18)
+#define USBPHY_CTRL_WAKEUP_IRQ (1 << 17)
+#define USBPHY_CTRL_ENIRQWAKEUP (1 << 16)
+#define USBPHY_CTRL_ENUTMILEVEL3 (1 << 15)
+#define USBPHY_CTRL_ENUTMILEVEL2 (1 << 14)
+#define USBPHY_CTRL_DATA_ON_LRADC (1 << 13)
+#define USBPHY_CTRL_DEVPLUGIN_IRQ (1 << 12)
+#define USBPHY_CTRL_ENIRQDEVPLUGIN (1 << 11)
+#define USBPHY_CTRL_RESUME_IRQ (1 << 10)
+#define USBPHY_CTRL_ENIRQRESUMEDETECT (1 << 9)
+#define USBPHY_CTRL_RESUMEIRQSTICKY (1 << 8)
+#define USBPHY_CTRL_ENOTGIDDETECT (1 << 7)
+#define USBPHY_CTRL_DEVPLUGIN_POLARITY (1 << 5)
+#define USBPHY_CTRL_ENDEVPLUGINDETECT (1 << 4)
+#define USBPHY_CTRL_HOSTDISCONDETECT_IRQ (1 << 3)
+#define USBPHY_CTRL_ENIRQHOSTDISCON (1 << 2)
+#define USBPHY_CTRL_ENHOSTDISCONDETECT (1 << 1)
+
+#define USBPHY_STATUS_RESUME_STATUS (1 << 10)
+#define USBPHY_STATUS_OTGID_STATUS (1 << 8)
+#define USBPHY_STATUS_DEVPLUGIN_STATUS (1 << 6)
+#define USBPHY_STATUS_HOSTDISCONDETECT_STATUS (1 << 3)
+
+#define USBPHY_DEBUG_CLKGATE (1 << 30)
+#define USBPHY_DEBUG_HOST_RESUME_DEBUG (1 << 29)
+#define USBPHY_DEBUG_SQUELCHRESETLENGTH_OFFSET 25
+#define USBPHY_DEBUG_SQUELCHRESETLENGTH_MASK (0xf << 25)
+#define USBPHY_DEBUG_ENSQUELCHRESET (1 << 24)
+#define USBPHY_DEBUG_SQUELCHRESETCOUNT_OFFSET 16
+#define USBPHY_DEBUG_SQUELCHRESETCOUNT_MASK (0x1f << 16)
+#define USBPHY_DEBUG_ENTX2RXCOUNT (1 << 12)
+#define USBPHY_DEBUG_TX2RXCOUNT_OFFSET 8
+#define USBPHY_DEBUG_TX2RXCOUNT_MASK (0xf << 8)
+#define USBPHY_DEBUG_ENHSTPULLDOWN_OFFSET 4
+#define USBPHY_DEBUG_ENHSTPULLDOWN_MASK (0x3 << 4)
+#define USBPHY_DEBUG_HSTPULLDOWN_OFFSET 2
+#define USBPHY_DEBUG_HSTPULLDOWN_MASK (0x3 << 2)
+#define USBPHY_DEBUG_DEBUG_INTERFACE_HOLD (1 << 1)
+#define USBPHY_DEBUG_OTGIDPIDLOCK (1 << 0)
+
+#define USBPHY_DEBUG0_STATUS_SQUELCH_COUNT_OFFSET 26
+#define USBPHY_DEBUG0_STATUS_SQUELCH_COUNT_MASK (0x3f << 26)
+#define USBPHY_DEBUG0_STATUS_UTMI_RXERROR_OFFSET 16
+#define USBPHY_DEBUG0_STATUS_UTMI_RXERROR_MASK (0x3ff << 16)
+#define USBPHY_DEBUG0_STATUS_LOOP_BACK_OFFSET 0
+#define USBPHY_DEBUG0_STATUS_LOOP_BACK_MASK 0xffff
+
+#define USBPHY_DEBUG1_ENTAILADJVD_OFFSET 13
+#define USBPHY_DEBUG1_ENTAILADJVD_MASK (0x3 << 13)
+#define USBPHY_DEBUG1_ENTX2TX (1 << 12)
+#define USBPHY_DEBUG1_DBG_ADDRESS_OFFSET 0
+#define USBPHY_DEBUG1_DBG_ADDRESS_MASK 0xf
+
+#define USBPHY_VERSION_MAJOR_MASK (0xff << 24)
+#define USBPHY_VERSION_MAJOR_OFFSET 24
+#define USBPHY_VERSION_MINOR_MASK (0xff << 16)
+#define USBPHY_VERSION_MINOR_OFFSET 16
+#define USBPHY_VERSION_STEP_MASK 0xffff
+#define USBPHY_VERSION_STEP_OFFSET 0
+
+#define USBPHY_IP_DIV_SEL_OFFSET 23
+#define USBPHY_IP_DIV_SEL_MASK (0x3 << 23)
+#define USBPHY_IP_LFR_SEL_OFFSET 21
+#define USBPHY_IP_LFR_SEL_MASK (0x3 << 21)
+#define USBPHY_IP_CP_SEL_OFFSET 19
+#define USBPHY_IP_CP_SEL_MASK (0x3 << 19)
+#define USBPHY_IP_TSTI_TX_DP (1 << 18)
+#define USBPHY_IP_TSTI_TX_DM (1 << 17)
+#define USBPHY_IP_ANALOG_TESTMODE (1 << 16)
+#define USBPHY_IP_EN_USB_CLKS (1 << 2)
+#define USBPHY_IP_PLL_LOCKED (1 << 1)
+#define USBPHY_IP_PLL_POWER (1 << 0)
+
+#endif /* __REGS_USBPHY_H__ */
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 0/3] M28 USB Support
From: Marek Vasut @ 2011-10-24 11:21 UTC (permalink / raw)
To: u-boot
This set of patches enables the EHCI USB host support in the iMX28 CPU and
enables the port on the M28EVK board.
Marek Vasut (3):
iMX28: Add USB and USB PHY register definitions
iMX28: Add USB HOST driver
M28EVK: Enable USB HOST support
arch/arm/include/asm/arch-mx28/regs-usb.h | 178 ++++++++++++++++++++++++++
arch/arm/include/asm/arch-mx28/regs-usbphy.h | 151 ++++++++++++++++++++++
board/denx/m28evk/m28evk.c | 7 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-mxs.c | 154 ++++++++++++++++++++++
include/configs/m28evk.h | 12 ++
6 files changed, 503 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-mx28/regs-usb.h
create mode 100644 arch/arm/include/asm/arch-mx28/regs-usbphy.h
create mode 100644 drivers/usb/host/ehci-mxs.c
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
Cc: Remy Bohmer <linux@bohmer.net>
--
1.7.6.3
^ permalink raw reply
* [PATCH 3/3] NFSD: Added fault injection documentation
From: bjschuma @ 2011-10-24 11:20 UTC (permalink / raw)
To: bfields; +Cc: linux-nfs, Bryan Schumaker
In-Reply-To: <1319455259-3136-1-git-send-email-bjschuma@netapp.com>
From: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
---
Documentation/filesystems/nfs/00-INDEX | 2 +
Documentation/filesystems/nfs/fault_injection.txt | 69 +++++++++++++++++++++
2 files changed, 71 insertions(+), 0 deletions(-)
create mode 100644 Documentation/filesystems/nfs/fault_injection.txt
diff --git a/Documentation/filesystems/nfs/00-INDEX b/Documentation/filesystems/nfs/00-INDEX
index a57e124..1716874 100644
--- a/Documentation/filesystems/nfs/00-INDEX
+++ b/Documentation/filesystems/nfs/00-INDEX
@@ -2,6 +2,8 @@
- this file (nfs-related documentation).
Exporting
- explanation of how to make filesystems exportable.
+fault_injection.txt
+ - information for using fault injection on the server
knfsd-stats.txt
- statistics which the NFS server makes available to user space.
nfs.txt
diff --git a/Documentation/filesystems/nfs/fault_injection.txt b/Documentation/filesystems/nfs/fault_injection.txt
new file mode 100644
index 0000000..426d166
--- /dev/null
+++ b/Documentation/filesystems/nfs/fault_injection.txt
@@ -0,0 +1,69 @@
+
+Fault Injection
+===============
+Fault injection is a method for forcing errors that may not normally occur, or
+may be difficult to reproduce. Forcing these errors in a controlled environment
+can help the developer find and fix bugs before their code is shipped in a
+production system. Injecting an error on the Linux NFS server will allow us to
+observe how the client reacts and if it manages to recover its state correctly.
+
+NFSD_FAULT_INJECTION must be selected when configuring the kernel to use this
+feature.
+
+
+Using Fault Injection
+=====================
+On the client, mount the fault injection server through NFS v4.0+ and do some
+work over NFS (open files, take locks, ...).
+
+On the server, mount the debugfs filesystem to <debug_dir> and ls
+<debug_dir>/nfsd. This will show a list of files that will be used for
+injecting faults on the NFS server. As root, write a number n to the file
+corresponding to the action you want the server to take. The server will then
+process the first n items it finds. So if you want to forget 5 locks, echo '5'
+to <debug_dir>/nfsd/forget_locks. A value of 0 will tell the server to forget
+all corresponding items. A log message will be created containing the number
+of items forgotten (check dmesg).
+
+Go back to work on the client and check if the client recovered from the error
+correctly.
+
+
+Available Faults
+================
+forget_clients:
+ The NFS server keeps a list of clients that have placed a mount call. If
+ this list is cleared, the server will have no knowledge of who the client
+ is, forcing the client to reauthenticate with the server.
+
+forget_openowners:
+ The NFS server keeps a list of what files are currently opened and who
+ they were opened by. Clearing this list will force the client to reopen
+ its files.
+
+forget_locks:
+ The NFS server keeps a list of what files are currently locked in the VFS.
+ Clearing this list will force the client to reclaim its locks (files are
+ unlocked through the VFS as they are cleared from this list).
+
+forget_delegations:
+ A delegation is used to assure the client that a file, or part of a file,
+ has not changed since the delegation was awarded. Clearing this list will
+ force the client to reaquire its delegation before accessing the file
+ again.
+
+recall_delegations:
+ Delegations can be recalled by the server when another client attempts to
+ access a file. This test will notify the client that its delegation has
+ been revoked, forcing the client to reaquire the delegation before using
+ the file again.
+
+
+tools/nfs/inject_faults.sh script
+=================================
+This script has been created to ease the fault injection process. This script
+will detect the mounted debugfs directory and write to the files located there
+based on the arguments passed by the user. For example, running
+`inject_faults.sh forget_locks 1` as root will instruct the server to forget
+one lock. Running `inject_faults forget_locks` will instruct the server to
+forgetall locks.
--
1.7.7
^ permalink raw reply related
* [PATCH 2/3] NFSD: Added fault injection script
From: bjschuma @ 2011-10-24 11:20 UTC (permalink / raw)
To: bfields; +Cc: linux-nfs, Bryan Schumaker
In-Reply-To: <1319455259-3136-1-git-send-email-bjschuma@netapp.com>
From: Bryan Schumaker <bjschuma@netapp.com>
This script provides a convenient way to use the NFSD fault injection
framework. Fault injection writes to dmesg using the KERN_INFO flag, so
this script will compare the before and after output of `dmesg` to show
the user what happened
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
---
tools/nfsd/inject_fault.sh | 49 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 49 insertions(+), 0 deletions(-)
create mode 100755 tools/nfsd/inject_fault.sh
diff --git a/tools/nfsd/inject_fault.sh b/tools/nfsd/inject_fault.sh
new file mode 100755
index 0000000..06a399a
--- /dev/null
+++ b/tools/nfsd/inject_fault.sh
@@ -0,0 +1,49 @@
+#!/bin/bash
+#
+# Copyright (c) 2011 Bryan Schumaker <bjschuma@netapp.com>
+#
+# Script for easier NFSD fault injection
+
+# Check that debugfs has been mounted
+DEBUGFS=`cat /proc/mounts | grep debugfs`
+if [ "$DEBUGFS" == "" ]; then
+ echo "debugfs does not appear to be mounted!"
+ echo "Please mount debugfs and try again"
+ exit 1
+fi
+
+# Check that the fault injection directory exists
+DEBUGDIR=`echo $DEBUGFS | awk '{print $2}'`/nfsd
+if [ ! -d "$DEBUGDIR" ]; then
+ echo "$DEBUGDIR does not exist"
+ echo "Check that your .config selects CONFIG_NFSD_FAULT_INJECTION"
+ exit 1
+fi
+
+function help()
+{
+ echo "Usage $0 injection_type [count]"
+ echo ""
+ echo "Injection types are:"
+ ls $DEBUGDIR
+ exit 1
+}
+
+if [ $# == 0 ]; then
+ help
+elif [ ! -f $DEBUGDIR/$1 ]; then
+ help
+elif [ $# != 2 ]; then
+ COUNT=0
+else
+ COUNT=$2
+fi
+
+BEFORE=`mktemp`
+AFTER=`mktemp`
+dmesg > $BEFORE
+echo $COUNT > $DEBUGDIR/$1
+dmesg > $AFTER
+# Capture lines that only exist in the $AFTER file
+diff $BEFORE $AFTER | grep ">"
+rm -f $BEFORE $AFTER
--
1.7.7
^ permalink raw reply related
* [PATCH 1/3] NFSD: Added fault injection
From: bjschuma @ 2011-10-24 11:20 UTC (permalink / raw)
To: bfields; +Cc: linux-nfs, Bryan Schumaker
From: Bryan Schumaker <bjschuma@netapp.com>
Fault injection on the NFS server makes it easier to test the client's
state manager and recovery threads. Simulating errors on the server is
easier than finding the right conditions that cause them naturally.
This patch uses debugfs to add a simple framework for fault injection to
the server. This framework is a config option, and can be enabled
through CONFIG_NFSD_FAULT_INJECTION. Assuming you have debugfs mounted
to /sys/debug, a set of files will be created in /sys/debug/nfsd/.
Writing to any of these files will cause the corresponding action and
write a log entry to dmesg.
Changes in v5:
- Fill out inject_ops[] array without a macro
- Simplify debug messages and file creation
Changes in v4:
- Move fault injection function declarations to a new .h file
- Use the Makefile to selectively compile fault_injection.c
- Add copyright notices to top of files
Changes in v3:
- Code cleanup and better use of generic functions
- Allow the user to input the number of state objects to delete
- Remove "forget_everything()" since forgetting a client is basically
the same thing
Changes in v2:
- Replaced "forget all state owners" with "forget all open owners"
- Include fs/nfsd/fault_inject.c in the patch
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
---
fs/nfsd/Kconfig | 10 ++++
fs/nfsd/Makefile | 1 +
fs/nfsd/fault_inject.c | 90 +++++++++++++++++++++++++++++++++++++
fs/nfsd/fault_inject.h | 28 ++++++++++++
fs/nfsd/nfs4state.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++
fs/nfsd/nfsctl.c | 7 +++
6 files changed, 251 insertions(+), 0 deletions(-)
create mode 100644 fs/nfsd/fault_inject.c
create mode 100644 fs/nfsd/fault_inject.h
diff --git a/fs/nfsd/Kconfig b/fs/nfsd/Kconfig
index 10e6366..8df1ea4 100644
--- a/fs/nfsd/Kconfig
+++ b/fs/nfsd/Kconfig
@@ -80,3 +80,13 @@ config NFSD_V4
available from http://linux-nfs.org/.
If unsure, say N.
+
+config NFSD_FAULT_INJECTION
+ bool "NFS server manual fault injection"
+ depends on NFSD_V4 && DEBUG_KERNEL
+ help
+ This option enables support for manually injecting faults
+ into the NFS server. This is intended to be used for
+ testing error recovery on the NFS client.
+
+ If unsure, say N.
diff --git a/fs/nfsd/Makefile b/fs/nfsd/Makefile
index 9b118ee..af32ef0 100644
--- a/fs/nfsd/Makefile
+++ b/fs/nfsd/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_NFSD) += nfsd.o
nfsd-y := nfssvc.o nfsctl.o nfsproc.o nfsfh.o vfs.o \
export.o auth.o lockd.o nfscache.o nfsxdr.o stats.o
+nfsd-$(CONFIG_NFSD_FAULT_INJECTION) += fault_inject.o
nfsd-$(CONFIG_NFSD_V2_ACL) += nfs2acl.o
nfsd-$(CONFIG_NFSD_V3) += nfs3proc.o nfs3xdr.o
nfsd-$(CONFIG_NFSD_V3_ACL) += nfs3acl.o
diff --git a/fs/nfsd/fault_inject.c b/fs/nfsd/fault_inject.c
new file mode 100644
index 0000000..1ac4134
--- /dev/null
+++ b/fs/nfsd/fault_inject.c
@@ -0,0 +1,90 @@
+/*
+ * Copyright (c) 2011 Bryan Schumaker <bjschuma@netapp.com>
+ *
+ * Uses debugfs to create fault injection points for client testing
+ */
+
+#include <linux/types.h>
+#include <linux/fs.h>
+#include <linux/debugfs.h>
+#include <linux/module.h>
+
+#include "state.h"
+#include "fault_inject.h"
+
+struct nfsd_fault_inject_op {
+ char *file;
+ void (*func)(u64);
+};
+
+static struct nfsd_fault_inject_op inject_ops[] = {
+ {
+ .file = "forget_clients",
+ .func = nfsd_forget_clients,
+ },
+ {
+ .file = "forget_locks",
+ .func = nfsd_forget_locks,
+ },
+ {
+ .file = "forget_openowners",
+ .func = nfsd_forget_openowners,
+ },
+ {
+ .file = "forget_delegations",
+ .func = nfsd_forget_delegations,
+ },
+ {
+ .file = "recall_delegations",
+ .func = nfsd_recall_delegations,
+ },
+};
+
+static long int NUM_INJECT_OPS = sizeof(inject_ops) / sizeof(struct nfsd_fault_inject_op);
+static struct dentry *debug_dir;
+
+static int nfsd_inject_set(void *op_ptr, u64 val)
+{
+ struct nfsd_fault_inject_op *op = op_ptr;
+
+ if (val == 0)
+ printk(KERN_INFO "NFSD Fault Injection: %s (all)", op->file);
+ else
+ printk(KERN_INFO "NFSD Fault Injection: %s (n = %llu)", op->file, val);
+
+ op->func(val);
+ return 0;
+}
+
+static int nfsd_inject_get(void *data, u64 *val)
+{
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(fops_nfsd, nfsd_inject_get, nfsd_inject_set, "%llu\n");
+
+void nfsd_fault_inject_cleanup(void)
+{
+ debugfs_remove_recursive(debug_dir);
+}
+
+int nfsd_fault_inject_init(void)
+{
+ unsigned int i;
+ struct nfsd_fault_inject_op *op;
+ mode_t mode = S_IFREG | S_IRUSR | S_IWUSR;
+
+ debug_dir = debugfs_create_dir("nfsd", NULL);
+ if (!debug_dir)
+ goto fail;
+
+ for (i = 0; i < NUM_INJECT_OPS; i++) {
+ op = &inject_ops[i];
+ debugfs_create_file(op->file, mode, debug_dir, op, &fops_nfsd);
+ }
+ return 0;
+
+fail:
+ nfsd_fault_inject_cleanup();
+ return -ENOMEM;
+}
diff --git a/fs/nfsd/fault_inject.h b/fs/nfsd/fault_inject.h
new file mode 100644
index 0000000..90bd057
--- /dev/null
+++ b/fs/nfsd/fault_inject.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright (c) 2011 Bryan Schumaker <bjschuma@netapp.com>
+ *
+ * Function definitions for fault injection
+ */
+
+#ifndef LINUX_NFSD_FAULT_INJECT_H
+#define LINUX_NFSD_FAULT_INJECT_H
+
+#ifdef CONFIG_NFSD_FAULT_INJECTION
+int nfsd_fault_inject_init(void);
+void nfsd_fault_inject_cleanup(void);
+void nfsd_forget_clients(u64);
+void nfsd_forget_locks(u64);
+void nfsd_forget_openowners(u64);
+void nfsd_forget_delegations(u64);
+void nfsd_recall_delegations(u64);
+#else /* CONFIG_NFSD_FAULT_INJECTION */
+static inline int nfsd_fault_inject_init(void) { return 0; }
+static inline void nfsd_fault_inject_cleanup(void) {}
+static inline void nfsd_forget_clients(u64 num) {}
+static inline void nfsd_forget_locks(u64 num) {}
+static inline void nfsd_forget_openowners(u64 num) {}
+static inline void nfsd_forget_delegations(u64 num) {}
+static inline void nfsd_recall_delegations(u64 num) {}
+#endif /* CONFIG_NFSD_FAULT_INJECTION */
+
+#endif /* LINUX_NFSD_FAULT_INJECT_H */
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 05f4c69..64fa6b0 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -4358,6 +4358,121 @@ nfs4_check_open_reclaim(clientid_t *clid)
return nfs4_find_reclaim_client(clid) ? nfs_ok : nfserr_reclaim_bad;
}
+#ifdef CONFIG_NFSD_FAULT_INJECTION
+
+void nfsd_forget_clients(u64 num)
+{
+ struct nfs4_client *clp, *next;
+ int count = 0;
+
+ nfs4_lock_state();
+ list_for_each_entry_safe(clp, next, &client_lru, cl_lru) {
+ nfsd4_remove_clid_dir(clp);
+ expire_client(clp);
+ if (++count == num)
+ break;
+ }
+ nfs4_unlock_state();
+
+ printk(KERN_INFO "NFSD: Forgot %d clients", count);
+}
+
+static void release_lockowner_sop(struct nfs4_stateowner *sop)
+{
+ release_lockowner(lockowner(sop));
+}
+
+static void release_openowner_sop(struct nfs4_stateowner *sop)
+{
+ release_openowner(openowner(sop));
+}
+
+static int nfsd_release_n_owners(u64 num,
+ struct list_head hashtbl[],
+ unsigned int hashtbl_size,
+ void (*release_sop)(struct nfs4_stateowner *))
+{
+ int i, count = 0;
+ struct nfs4_stateowner *sop, *next;
+
+ for (i = 0; i < hashtbl_size; i++) {
+ list_for_each_entry_safe(sop, next, &hashtbl[i], so_strhash) {
+ release_sop(sop);
+ if (++count == num)
+ return count;
+ }
+ }
+ return count;
+}
+
+void nfsd_forget_locks(u64 num)
+{
+ int count;
+
+ nfs4_lock_state();
+ count = nfsd_release_n_owners(num, lock_ownerstr_hashtbl,
+ LOCK_HASH_SIZE, release_lockowner_sop);
+ nfs4_unlock_state();
+
+ printk(KERN_INFO "NFSD: Forgot %d locks", count);
+}
+
+void nfsd_forget_openowners(u64 num)
+{
+ int count;
+
+ nfs4_lock_state();
+ count = nfsd_release_n_owners(num, open_ownerstr_hashtbl,
+ OPEN_OWNER_HASH_SIZE, release_openowner_sop);
+ nfs4_unlock_state();
+
+ printk(KERN_INFO "NFSD: Forgot %d open owners", count);
+}
+
+int nfsd_process_n_delegations(u64 num, void (*deleg_func)(struct nfs4_delegation *))
+{
+ int i, count = 0;
+ struct nfs4_file *fp;
+ struct nfs4_delegation *dp, *next;
+
+ for (i = 0; i < FILE_HASH_SIZE; i++) {
+ list_for_each_entry(fp, &file_hashtbl[i], fi_hash) {
+ list_for_each_entry_safe(dp, next, &fp->fi_delegations, dl_perfile) {
+ deleg_func(dp);
+ if (++count == num)
+ return count;
+ }
+ }
+ }
+ return count;
+}
+
+void nfsd_forget_delegations(u64 num)
+{
+ unsigned int count;
+
+ nfs4_lock_state();
+ count = nfsd_process_n_delegations(num, unhash_delegation);
+ nfs4_unlock_state();
+
+ printk(KERN_INFO "NFSD: Forgot %d delegations", count);
+}
+
+void nfsd_recall_delegations(u64 num)
+{
+ unsigned int count;
+
+ nfs4_lock_state();
+ spin_lock(&recall_lock);
+ count = nfsd_process_n_delegations(num, nfsd_break_one_deleg);
+ spin_unlock(&recall_lock);
+ nfs4_unlock_state();
+
+ printk(KERN_INFO "NFSD: Recalled %d delegations", count);
+}
+
+#endif /* CONFIG_NFSD_FAULT_INJECTION */
+
/* initialization to perform at module load time: */
int
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index db34a58..e67f30c 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -17,6 +17,7 @@
#include "idmap.h"
#include "nfsd.h"
#include "cache.h"
+#include "fault_inject.h"
/*
* We have a single directory with several nodes in it.
@@ -1130,6 +1131,9 @@ static int __init init_nfsd(void)
retval = nfs4_state_init(); /* nfs4 locking state */
if (retval)
return retval;
+ retval = nfsd_fault_inject_init(); /* nfsd fault injection controls */
+ if (retval)
+ goto out_cleanup_fault_injection;
nfsd_stat_init(); /* Statistics */
retval = nfsd_reply_cache_init();
if (retval)
@@ -1161,6 +1165,8 @@ out_free_cache:
out_free_stat:
nfsd_stat_shutdown();
nfsd4_free_slabs();
+out_cleanup_fault_injection:
+ nfsd_fault_inject_cleanup();
return retval;
}
@@ -1174,6 +1180,7 @@ static void __exit exit_nfsd(void)
nfsd_lockd_shutdown();
nfsd_idmap_shutdown();
nfsd4_free_slabs();
+ nfsd_fault_inject_cleanup();
unregister_filesystem(&nfsd_fs_type);
}
--
1.7.7
^ permalink raw reply related
* Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support pv-ticketlock
From: Raghavendra K T @ 2011-10-24 11:20 UTC (permalink / raw)
To: Avi Kivity
Cc: Raghavendra K T, Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov,
Virtualization, Jeremy Fitzhardinge, x86, KVM, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Xen, Sedat Dilek, Yinghai Lu,
Marcelo Tosatti, Ingo Molnar, Rik van Riel, Konrad Rzeszutek Wilk,
LKML, Suzuki Poulose, Srivatsa Vaddagiri, Peter Zijlstra
In-Reply-To: <4EA53A7D.300@redhat.com>
On 10/24/2011 03:44 PM, Avi Kivity wrote:
> On 10/23/2011 09:05 PM, Raghavendra K T wrote:
>> Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
>> +
>> +end_wait:
>> + finish_wait(&vcpu->wq,&wait);
>> +}
>
> This hypercall can be replaced by a HLT instruction, no?
>
> I'm pretty sure this misses a lot of stuff from kvm_vcpu_block().
Yes.. agree. HLT sounds better idea. 'll try this out.
>
>> + if (vcpu) {
>> + vcpu->kicked = 1;
>
> Need to use smp memory barriers here.
Agree.
>
>> + wake_up_interruptible(&vcpu->wq);
>> + }
>> +}
>> +
>> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>> {
>> unsigned long nr, a0, a1, a2, a3, ret;
>>
>
^ permalink raw reply
* [Buildroot] x86_64 and grub
From: Rickard Lind @ 2011-10-24 11:18 UTC (permalink / raw)
To: buildroot
Hi,
I'm using buildroot-2011.08 with a x86_64 target to build an ext2 image and I would like to include grub, but building grub fails when linking for not finding libgcc. I think this is because grub wants to be built 32 bit (presumably something to do with booting) and gcc is only built with a 64 bit libgcc due to the --disable-multilib configure option. I tried to remove the --disable-multilib option but then the gcc build dies with "cannot find -lc" while building libgcc. I switched from the default gcc to the latest (4.6.1) but that made no difference. I could not find anything in the bugzilla; is there some workaround or should I file a bug? Or am I doing something wrong?
Regards, Rickard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1243 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111024/a3a51aec/attachment.p7s>
^ permalink raw reply
* Re: [Xenomai-help] installing xenomai on pandaboard
From: Gilles Chanteperdrix @ 2011-10-24 11:18 UTC (permalink / raw)
To: Robert
In-Reply-To: <e966a6c.7f7f5548.4ea547f5.6fa69@domain.hid>
On 10/24/2011 01:11 PM, Robert wrote:
>
>
>
> Dnia 24 października 2011 13:07 Gilles Chanteperdrix <gilles.chanteperdrix@domain.hid> napisał(a):
>
>> On 10/24/2011 12:59 PM, Robert wrote:
>>> Dnia 24 października 2011 12:37 Gilles Chanteperdrix <gilles.chanteperdrix@domain.hid> napisał(a):
>>
>>>> Ok. Try calling /usr/xenomai/bin/xeno-test instead of cding to the
>>>> directory and runing ./xeno-test.
>>>
>>> No difference.
>>
>> I am unable to reproduce this issue, but I am using ash, not bash. last
>> attempt: could you try adding /usr/xenomai/bin to the PATH variable?
>
> The same.
Ok, that is strange, I will test with bash asap.
>
>>>> I have not received the config file.
>>
>>> CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
>>> # CONFIG_ARCH_OMAP2 is not set
>>> CONFIG_ARCH_OMAP3=y
>>> CONFIG_ARCH_OMAP4=y
>>> # CONFIG_ARCH_OMAP3430 is not set
>>> CONFIG_OMAP_PACKAGE_CBL=y
>>> CONFIG_OMAP_PACKAGE_CBS=y
>>
>> Could you try disabling CONFIG_OMAP3?
>
> No. While running "make oldconfig" CONFIG_OMAP3 automatically set to yes, so i didn't touch it.
> Ok, so now I will try to recompile kernel with new config.
>
It will probably not work if you do not disable CONFIG_OMAP3. Multi-omap
kernels are bad for latencies anyway, the next version of the patch will
probably forbid it.
--
Gilles.
^ permalink raw reply
* Re: [PATCH 1/1] mmc: core: Use delayed work in clock gating framework
From: Sujit Reddy Thumma @ 2011-10-24 11:16 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-mmc, linux-arm-msm, cjb
In-Reply-To: <CACRpkdY1WE8KrFW1qjLJk_sMivicqwDtBVzNDVN6H-3utw0isw@mail.gmail.com>
On 10/24/2011 12:53 PM, Linus Walleij wrote:
> On Wed, Oct 19, 2011 at 4:48 PM, Sujit Reddy Thumma
> <sthumma@codeaurora.org> wrote:
>
>> Current clock gating framework disables the MCI clock as soon as the
>> request is completed and enables it when a request arrives. This aggressive
>> clock gating framework when enabled cause following issues:
>>
>> When there are back-to-back requests from the Queue layer, we unnecessarily
>> end up disabling and enabling the clocks between these requests since 8 MCLK
>> clock cycles is a very short duration compared to the time delay between
>> back to back requests reaching the MMC layer. This overhead can effect the
>> overall performance depending on how long the clock enable and disable
>> calls take which is platform dependent. For example on some platforms we
>> can have clock control not on the local processor, but on a different
>> subsystem and the time taken to perform the clock enable/disable can add
>> significant overhead.
>
> OK I see the problem. At one point it was suggested to use the delayed
> disable facilities in runtime PM for avoiding this, but it never materialized.
>
>> Fix this by delaying turning off the clocks by posting request on
>> delayed workqueue. Also cancel the unscheduled pending work, if any,
>> when there is access to card.
>
> (...)
>> @@ -252,10 +252,11 @@ struct mmc_host {
>> int clk_requests; /* internal reference counter */
>> unsigned int clk_delay; /* number of MCI clk hold cycles */
>> bool clk_gated; /* clock gated */
>> - struct work_struct clk_gate_work; /* delayed clock gate */
>> + struct delayed_work clk_gate_work; /* delayed clock gate */
>> unsigned int clk_old; /* old clock value cache */
>> spinlock_t clk_lock; /* lock for clk fields */
>> struct mutex clk_gate_mutex; /* mutex for clock gating */
>> +#define MMC_CLK_GATE_DELAY 50 /* in milliseconds*/
>> #endif
>
> What's the rationale of having this in the middle of the struct
> in the .h-file?
>
> Move it inside the #ifdef in host.c instead, and also provide
> some rationale about the choice of 50 ms.
With my testing on a MSM platform, round-trip delay of 10ms to turn off
and on the clocks is seen. So I thought 50ms is a reasonable tradeoff.
There is no specific calculation behind this delay. We just relied on
the empirical data which again may vary with different platforms.
If you have any suggestions I would be happy to consider that. I am
planning to increase this to 200ms, any comments on that?
>
> Maybe we should even provide a sysfs or debugfs entry for
> tweaking that value, as has been suggested in the past.
> However that's no big deal for me...
Adding an entry in sysfs seems to be a good solution to tune the
required delay. I will add this.
>
> Do you have a patch to your msm_sdcc.c that enables the
> gating to take effect as well? Does it solve the problems
> pointed out by Russell when I tried the same type of patch
> to mmci.c?
> http://marc.info/?l=linux-mmc&m=129146545916794&w=2
Looking at the patch that you pointed out, I don't think it is required
for msm_sdcc.c to enable clock gating. The current code inherently takes
care of logic that is needed to ensure that MCLK is not turned off until
any pending register write in the host driver is completed. You might
want to have a look at set_ios function in
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=drivers/mmc/host/msm_sdcc.c;h=b5a08d2b58e0cd6d18a8f1041139b6866c0cdc09;hb=refs/heads/msm-3.0
Please let me know if I am still missing anything.
--
Thanks & Regards,
Sujit Reddy Thumma
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] target-arm: Tidy up ARM1136 CPUID naming
From: Peter Maydell @ 2011-10-24 11:15 UTC (permalink / raw)
To: Andreas Färber; +Cc: Andrzej Zaborowski, qemu-devel
In-Reply-To: <4EA29BE0.8050307@web.de>
On 22 October 2011 11:33, Andreas Färber <andreas.faerber@web.de> wrote:
> Am 22.10.2011 12:20, schrieb Peter Maydell:
>> On 3 October 2011 11:32, Andreas Färber <andreas.faerber@web.de> wrote:
>>> -#define ARM_CPUID_ARM1136 0x4117b363
>>> -#define ARM_CPUID_ARM1136_R2 0x4107b362
>>> +#define ARM_CPUID_ARM1136_R1P3 0x4117b363
>>> +#define ARM_CPUID_ARM1136_R0P2 0x4107b362
>>
>> I don't think the patchlevels are important enough to
>> memorialise in the constant names. The important
>> distinction in behaviour is between the r0 and r1, so
>> I think that ARM1136_R0 vs _R1 would be better.
>
> Would you be okay if we do the following?
>
> #define ARM_CPUID_ARM1136_R0 ARM_CPUID_ARM1136_R0P2
> #define ARM_CPUID_ARM1136_R1 ARM_CPUID_ARM1136_R1P3
Not sure that makes it any better.
> My point is that the number is actually hardcoded in there, whatever we
> name the constant.
I think that's really the problem...
-- PMM
^ permalink raw reply
* Re: [Qemu-devel] qemu-kvm guest which won't 'cont' (emulation failure?)
From: Kevin Wolf @ 2011-10-24 11:18 UTC (permalink / raw)
To: Chris Webb; +Cc: qemu-devel, kvm
In-Reply-To: <20111024105826.GT9917@arachsys.com>
Am 24.10.2011 12:58, schrieb Chris Webb:
> Kevin Wolf <kwolf@redhat.com> writes:
>
>> Am 24.10.2011 12:00, schrieb Chris Webb:
>>> I have qemu monitor access and can even strace the relevant qemu process if
>>> necessary: is it possible to use this to diagnose what's caused this guest
>>> to stop, e.g. the unsupported instruction if it's an emulation failure?
>>
>> Another common cause for stopped VMs are I/O errors, for example writes
>> to a sparse image when the disk is full.
>
> This guest are backed by LVM LVs so I don't think they can return EFULL, but I
> could imagine read errors, so I've just done a trivial test to make sure I can
> read them end-to-end:
>
> 0015# dd if=/dev/mapper/guest\:e549f8e1-4c0e-4dea-826a-e4b877282c07\:ide\:0\:0 of=/dev/null bs=1M
> 3136+0 records in
> 3136+0 records out
> 3288334336 bytes (3.3 GB) copied, 20.898 s, 157 MB/s
>
> 0015# dd if=/dev/mapper/guest\:e549f8e1-4c0e-4dea-826a-e4b877282c07\:ide\:0\:1 of=/dev/null bs=1M
> 276+0 records in
> 276+0 records out
> 289406976 bytes (289 MB) copied, 1.85218 s, 156 MB/s
>
> Is there any way to ask qemu why a guest has stopped, so I can distinguish IO
> problems from emulation problems from anything else?
In qemu 1.0 we'll have an extended 'info status' that includes the stop
reason, but 0.14 doesn't have this yet (was committed to git master only
recently).
If you attach a QMP monitor (see QMP/README, don't forget to send the
capabilities command, it's part of creating the connection) you will
receive messages for I/O errors, though.
Kevin
^ permalink raw reply
* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Štěpán Němec @ 2011-10-24 11:09 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, git, Jeff King, Ævar Arnfjörð
In-Reply-To: <CACsJy8AsfQnS3L1fabzB-z7BdH=jvB=XNnmP2RZu0qp7C1uGYQ@mail.gmail.com>
On Mon, 24 Oct 2011 07:10:08 +0200
Nguyen Thai Ngoc Duy wrote:
> This is argument for the sake of argument because I don't use utf-16
> and do not care much. UTF-16 can have more code points and some may
> prefer utf-16 to utf-8.
I suspect this is really tangential to this thread, but I can't make
much sense of that last sentence -- if you meant that UTF-16 is somehow
more apt at encoding Unicode code points than UTF-8, then that's not the
case. Both can represent all Unicode characters. If anything, things are
_more_, not less complicated in UTF-16, which apart from the NUL and
endianness complications has to jump through the "surrogate pairs" hoop
for code points bigger than U+FFFF (so you'll actually find many apps
with buggy UTF-16 implementation which break for those code points,
unlike when using UTF-8).
--
Štěpán
^ permalink raw reply
* Re: Nested Virtualization Of Hyper-V 2K8R2
From: Jim @ 2011-10-24 11:13 UTC (permalink / raw)
To: kvm@vger.kernel.org
In-Reply-To: <4E9EE7C3.70407@suresafe.co.uk>
Hi
Anyone got any further ideas on how I get the Hyper-V guest to work ?
My kvm is 0.14 (Ubuntu 11.04 Server) - is this just too old ?
Jim
On 19/10/2011 16:07, Jim wrote:
>
>
> On 19/10/2011 16:06, Jim wrote:
>> Hi Joerg,
>>
>> I added the -cpu phenom,-hv but it made no difference. I then tried
>> to call it from the command line (rather then via virsh) and get this :
>>
>> # /usr/bin/kvm -cpu phenom,-hv
>> *CPU feature hv not found*
>>
>>
>> I played around a little and found 'svm' seemed to be a supported cpu
>> flag but both +svm and -svm made no difference either. Alas kvm -cpu
>> ? only listed CPUs and not the options the various ones support.
>>
>> Am I on too low a version of kvm perhaps ? This is an Ubuntu 11.04
>> server system and I've just used the Ubuntu packages - I did not
>> build kvm myself.
>>
>> Thanks
>> Jim
>>
>> My CPU reports as :
>>
>> *processor : 0-3 i.e. 4 cores*
>> vendor_id : AuthenticAMD
>> cpu family : 16
>> model : 2
>> model name : Quad-Core AMD Opteron(tm) Processor 1354
>> stepping : 3
>> cpu MHz : 1100.000
>> cache size : 512 KB
>> physical id : 0
>> siblings : 4
>> core id : 3
>> cpu cores : 4
>> apicid : 3
>> initial apicid : 3
>> fpu : yes
>> fpu_exception : yes
>> cpuid level : 5
>> wp : yes
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
>> fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl
>> nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy
>> svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
>> npt lbrv svm_lock
>> bogomips : 4400.04
>> TLB size : 1024 4K pages
>> clflush size : 64
>> cache_alignment : 64
>> address sizes : 48 bits physical, 48 bits virtual
>> power management: ts ttp tm stc 100mhzsteps hwpstate
>>
>>
>>
>> On 19/10/2011 15:19, Joerg Roedel wrote:
>>> Hi Jim,
>>>
>>> On Tue, Oct 18, 2011 at 07:28:52PM +0100, Jim wrote:
>>>> Sure, the KVM command is :
>>>>
>>>> /usr/bin/kvm -enable-nesting -no-kvm-irqchip -S -M pc-0.14 -enable-kvm
>>>> -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name hyperv1 -uuid
>>>> 8c5d8f1f-5767-b388-d408-1b53a1b66e72 -nodefconfig -nodefaults -chardev
>>>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/hyperv1.monitor,server,nowait
>>>>
>>>> -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=localtime
>>>> -no-reboot -boot d -drive
>>>> file=/srv/hyperv/hyperv1.vmimg,if=none,id=drive-ide0-0-0,format=raw
>>>> -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0
>>>> -drive
>>>> file=/srv/virtual-machines/fromiscsi/iso/W2K8ENTR2SP1.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw
>>>>
>>>> -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0
>>>> -drive
>>>> file=/srv/virtual-machines/fromiscsi/iso/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-1,readonly=on,format=raw
>>>>
>>>> -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1
>>>> -netdev tap,fd=17,id=hostnet0 -device
>>>> rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:2a:be:2f,bus=pci.0,addr=0x3
>>>>
>>>> -chardev pty,id=charserial0 -device
>>>> isa-serial,chardev=charserial0,id=serial0 -usb -device
>>>> usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga std -device
>>>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
>>> This is missing a -cpu parameter. Please try again with adding
>>> '-cpu phenom,-hv'. This is the combination I used during testing and
>>> development.
>>>
>>>
>>> Joerg
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message tomajordomo@vger.kernel.org
>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>>>
----------------------------------------------------------------------
All e-mail and telephone communications are subject to Suresafe Terms
And Conditions and may be monitored, recorded and processed for the
purposes contained therein and adherence to regulatory and legal
requirements.
Your further communication or reply to this e-mail indicates your
acceptance of this.
Any views or opinions expressed are the responsibility of the author
and may not reflect those of Suresafe Protection Limited.
Suresafe Protection Limited is registered in Scotland, number SC132827
The registered office is at 8 Kelvin Road, Cumbernauld, G67 2BA.
Telephone: 01236 727792 Fax: 01236 723301 VAT Number: 556 6950 02
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* [Buildroot] GnuPG
From: ilranzani @ 2011-10-24 11:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <0D753D10438DA54287A00B02708426976450C42C46@AUSP01VMBX24.collaborationhost.net>
Nobody?
(in buildroot there's already libgcrypt)
UP UP UP ! :)
--------------
H Hartley Sweeten wrote:
>
> Hello all,
>
> Does anyone had a Buildroot package for GnuPG?
>
> Thanks,
> Hartley
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
--
View this message in context: http://old.nabble.com/GnuPG-tp29967586p32709446.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Ofono use
From: Pekka Pessi @ 2011-10-24 11:11 UTC (permalink / raw)
To: ofono
In-Reply-To: <1319449442.32429.141.camel@talinn.home>
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
Hi Jean,
2011/10/24 Jean Parpaillon <jean.parpaillon@free.fr>
> The point is setting Online property usually end with a timeout. It is
> the right workflow ? Must I look for other property ?
>
The registration might take some time (usually, however, much less than 25
seconds). Perhaps you have to adjust the SetProperty method timeout?
> In a few words, what is the right workflow to get a UMTS modem
> registered to its default network from the moment you plug it in ?
>
>
Sounds right to me. I would not wait for operator name, however.
--
Pekka.Pessi mail at nokia.com
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1064 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Avi Kivity @ 2011-10-24 11:09 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Marcelo Tosatti, kvm, Michael S. Tsirkin
In-Reply-To: <4EA53BBF.2010704@siemens.com>
On 10/24/2011 12:19 PM, Jan Kiszka wrote:
> >
> > With the new feature it may be worthwhile, but I'd like to see the whole
> > thing, with numbers attached.
>
> It's not a performance issue, it's a resource limitation issue: With the
> new API we can stop worrying about user space device models consuming
> limited IRQ routes of the KVM subsystem.
>
Only if those devices are in the same process (or have access to the
vmfd). Interrupt routing together with irqfd allows you to disaggregate
the device model. Instead of providing a competing implementation with
new limitations, we need to remove the limitations of the old
implementation.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [PATCH] mmc: core: Assemble the codes of related to eMMC4.5
From: Chris Ball @ 2011-10-24 11:09 UTC (permalink / raw)
To: Seungwon Jeon; +Cc: linux-mmc, linux-samsung-soc, kgene.kim, dh.han
In-Reply-To: <001b01cc9238$156a65a0$403f30e0$%jun@samsung.com>
Hi Seungwon,
On Mon, Oct 24 2011, Seungwon Jeon wrote:
> Code cleanup. The codes of related to eMMC4.5 are scattered.
> This patch removes a duplicate if-statement and assembles all.
>
> Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
> ---
> drivers/mmc/core/mmc.c | 20 +++++++++-----------
> 1 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index fb5bf01..3627044 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -467,29 +467,27 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
> card->ext_csd.rst_n_function = ext_csd[EXT_CSD_RST_N_FUNCTION];
> }
>
> - /* eMMC v4.5 or later */
> - if (card->ext_csd.rev >= 6)
> - card->ext_csd.feature_support |= MMC_DISCARD_FEATURE;
> -
> card->ext_csd.raw_erased_mem_count = ext_csd[EXT_CSD_ERASED_MEM_CONT];
> if (ext_csd[EXT_CSD_ERASED_MEM_CONT])
> card->erased_byte = 0xFF;
> else
> card->erased_byte = 0x0;
>
> + /* eMMC v4.5 or later */
> if (card->ext_csd.rev >= 6) {
> + card->ext_csd.feature_support |= MMC_DISCARD_FEATURE;
> +
> card->ext_csd.generic_cmd6_time = 10 *
> ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
> card->ext_csd.power_off_longtime = 10 *
> ext_csd[EXT_CSD_POWER_OFF_LONG_TIME];
> - } else
> - card->ext_csd.generic_cmd6_time = 0;
Your patch removes this line completely. Why is that? You should
explain it in the commit message.
>
> - card->ext_csd.cache_size =
> - ext_csd[EXT_CSD_CACHE_SIZE + 0] << 0 |
> - ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
> - ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
> - ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
> + card->ext_csd.cache_size =
> + ext_csd[EXT_CSD_CACHE_SIZE + 0] << 0 |
> + ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
> + ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
> + ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
> + }
>
> out:
> return err;
The rest looks good, thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: [PATCH V2] i2c-designware: Change readl to readw and writel to writew
From: Rajeev kumar @ 2011-10-24 11:08 UTC (permalink / raw)
To: Baruch Siach
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shiraz HASHIM,
Viresh KUMAR, Bhupesh SHARMA, Pratyush ANAND, Vipin KUMAR,
Deepak SIKRI, Amit VIRDI, Vipul Kumar SAMAR, Armando VISCONTI
In-Reply-To: <20111024103316.GC26649-MwjkAAnuF3khR1HGirfZ1z4kX+cae0hd@public.gmane.org>
Hi Baruch
On 10/24/2011 4:03 PM, Baruch Siach wrote:
> Hi Rajeev,
>
> On Mon, Oct 24, 2011 at 03:28:02PM +0530, Rajeev Kumar wrote:
>> Since I2C designware registers are 16 bit wide and so we should use
>> readw/writew.
>>
>> Signed-off-by: Rajeev Kumar<rajeev-dlh.kumar-qxv4g6HH51o@public.gmane.org>
>> ---
>> drivers/i2c/busses/i2c-designware.c | 104 +++++++++++++++++-----------------
>> 1 files changed, 52 insertions(+), 52 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-designware.c b/drivers/i2c/busses/i2c-designware.c
>> index 6eaa681..5149a10 100644
>> --- a/drivers/i2c/busses/i2c-designware.c
>> +++ b/drivers/i2c/busses/i2c-designware.c
>> @@ -216,11 +216,11 @@ struct dw_i2c_dev {
>> u32 abort_source;
>> int irq;
>> struct i2c_adapter adapter;
>> - unsigned int tx_fifo_depth;
>> - unsigned int rx_fifo_depth;
>> + u16 tx_fifo_depth;
>> + u16 rx_fifo_depth;
>> };
>
> This looks wrong. The {tx,rx}_fifo_depth fields do not represent bit fields,
> but numbers. So unsigned int should be better here.
Yes, I agree with you, but I do not see any possibility of value of
{tx,rx}_fifo_depth fields greater than 2^^16 - 1. So, would not it be
better to keep them as u16 and save just 4 bytes.
~Rajeev
>
> baruch
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] fw_cfg: Use g_file_get_contents instead of multiple fread() calls
From: Peter Maydell @ 2011-10-24 11:08 UTC (permalink / raw)
To: Pavel Borzenkov; +Cc: qemu-devel
In-Reply-To: <1319196934-17740-1-git-send-email-pavel.borzenkov@gmail.com>
On 21 October 2011 12:35, Pavel Borzenkov <pavel.borzenkov@gmail.com> wrote:
> Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
Thanks; I think this looks a lot nicer than the raw file ops code did.
I think we could probably make the error messages slightly more user
friendly while we're here.
> + res = g_file_get_contents(filename, &content, (gsize *)file_sizep, &err);
> + if (res == FALSE) {
> + error_report("falied to read file '%s'", filename);
You've made a typo here ("failed"); also I think all the error messages
in this function should say "splash file" rather than just "file",
and include the filename.
> + if (*file_sizep < 30) {
> + error_report("file size is less than 30 bytes '%s'", filename);
> + g_free(content);
> + return NULL;
Rather than saying exactly what check failed (the user won't care)
we should just say "splash file '%s' format not recognized; must be JPEG
or 24 bit BMP".
> + error_report("'%s' not jpg/bmp file, head:0x%x.", filename, filehead);
and here also.
> if (bmp_bpp != 24) {
> error_report("only 24bpp bmp file is supported.");
and here I think.
-- PMM
^ permalink raw reply
* Re: [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability
From: J. Bruce Fields @ 2011-10-24 11:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Aneesh Kumar K.V, agruen, akpm, viro, dhowells, linux-fsdevel,
linux-nfs, linux-kernel
In-Reply-To: <20111024094910.GA28693@infradead.org>
On Mon, Oct 24, 2011 at 05:49:10AM -0400, Christoph Hellwig wrote:
> On Mon, Oct 24, 2011 at 05:17:16AM -0400, J. Bruce Fields wrote:
> > > How do we push these changes to Linus tree ? Andrew, Viro, any comment
> > > on how we can get this merged upstream ?
> >
> > Andrew, it sounds like you might be willing to shepherd these through?
> > Let us know what you'd need.
>
> It really has to through the VFS tree.
Do we have a VFS tree right now?
> And to be honest despite the repostings there's been exactly zero
> progress on getting there.
Apparently some review was missed--do you have pointers to it, if
there's anything that isn't covered below?
> Please as a first thing submit the various small cleanups indepent
> of the other changes. If you can't even those in there's no point
> in trying. Second do not repeat the mistakes of the old ACL code,
> that is don't do too much work inside the filesystems. Al, Linus
> and me spent a lot of working on pushing it into common code and
> it's not done. For any new ACL model I really want to see zero
> per-fs code except for callouts in chmod & co and actually
> setting the xattr vector to a genericly provided one. And please
> wire up all common filesystems to actually prove that point.
Sounds reasonable.
> I also really hate all the duplication - I want to see a really good
> reason why all this code needs to be duplicated. Just look at
> the mess done to check_acl and the ACL caching in the inode and
> any normal person would throw up. There is absolutely no reason
> to not implement Posix ACLs as a subset of the NFSv4 ACL (not actually
> a subset in the strict mathematical sense, but close enough).
Just to make sure I understand: you're just talking about the
implementation here--you want as much as possible to be done by routines
shared by NFSv4 and Posix ACLs--right? (You're not suggesting that e.g.
a user should be able to treat NFSv4 ACLs as if they were Posix ACLs.)
> After all this techical work (which was brought up before) has been
> done you can resubmit it. And that point you'd better have very
> good and very lengthy rationale for why adding an utterly stupid
> ACL model is supposed to be a good idea.
It's the ACL model that Samba and NFSv4 clients use, and we want to do a
better job of exporting linux filesystems to those clients.
I don't know how to make the justification much longer than that.
--b.
^ permalink raw reply
* Re: [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability
From: J. Bruce Fields @ 2011-10-24 11:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Aneesh Kumar K.V, agruen-DgEjT+Ai2ygdnm+yROfE0A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
dhowells-H+wXaHxf7aLQT0dZR+AlfA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20111024094910.GA28693-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Mon, Oct 24, 2011 at 05:49:10AM -0400, Christoph Hellwig wrote:
> On Mon, Oct 24, 2011 at 05:17:16AM -0400, J. Bruce Fields wrote:
> > > How do we push these changes to Linus tree ? Andrew, Viro, any comment
> > > on how we can get this merged upstream ?
> >
> > Andrew, it sounds like you might be willing to shepherd these through?
> > Let us know what you'd need.
>
> It really has to through the VFS tree.
Do we have a VFS tree right now?
> And to be honest despite the repostings there's been exactly zero
> progress on getting there.
Apparently some review was missed--do you have pointers to it, if
there's anything that isn't covered below?
> Please as a first thing submit the various small cleanups indepent
> of the other changes. If you can't even those in there's no point
> in trying. Second do not repeat the mistakes of the old ACL code,
> that is don't do too much work inside the filesystems. Al, Linus
> and me spent a lot of working on pushing it into common code and
> it's not done. For any new ACL model I really want to see zero
> per-fs code except for callouts in chmod & co and actually
> setting the xattr vector to a genericly provided one. And please
> wire up all common filesystems to actually prove that point.
Sounds reasonable.
> I also really hate all the duplication - I want to see a really good
> reason why all this code needs to be duplicated. Just look at
> the mess done to check_acl and the ACL caching in the inode and
> any normal person would throw up. There is absolutely no reason
> to not implement Posix ACLs as a subset of the NFSv4 ACL (not actually
> a subset in the strict mathematical sense, but close enough).
Just to make sure I understand: you're just talking about the
implementation here--you want as much as possible to be done by routines
shared by NFSv4 and Posix ACLs--right? (You're not suggesting that e.g.
a user should be able to treat NFSv4 ACLs as if they were Posix ACLs.)
> After all this techical work (which was brought up before) has been
> done you can resubmit it. And that point you'd better have very
> good and very lengthy rationale for why adding an utterly stupid
> ACL model is supposed to be a good idea.
It's the ACL model that Samba and NFSv4 clients use, and we want to do a
better job of exporting linux filesystems to those clients.
I don't know how to make the justification much longer than that.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Xenomai-help] installing xenomai on pandaboard
From: Gilles Chanteperdrix @ 2011-10-24 11:07 UTC (permalink / raw)
To: Robert; +Cc: xenomai
In-Reply-To: <f8287c0.5ee210fc.4ea544fe.30636@domain.hid>
On 10/24/2011 12:59 PM, Robert wrote:
> Dnia 24 października 2011 12:37 Gilles Chanteperdrix <gilles.chanteperdrix@domain.hid> napisał(a):
>> Ok. Try calling /usr/xenomai/bin/xeno-test instead of cding to the
>> directory and runing ./xeno-test.
>
> No difference.
I am unable to reproduce this issue, but I am using ash, not bash. last
attempt: could you try adding /usr/xenomai/bin to the PATH variable?
>> I have not received the config file.
> CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
> # CONFIG_ARCH_OMAP2 is not set
> CONFIG_ARCH_OMAP3=y
> CONFIG_ARCH_OMAP4=y
> # CONFIG_ARCH_OMAP3430 is not set
> CONFIG_OMAP_PACKAGE_CBL=y
> CONFIG_OMAP_PACKAGE_CBS=y
Could you try disabling CONFIG_OMAP3?
--
Gilles.
^ permalink raw reply
* Re: [PATCH 2/3] kvm: use this_cpu_xxx replace percpu_xxx funcs
From: Avi Kivity @ 2011-10-24 11:05 UTC (permalink / raw)
To: Alex,Shi
Cc: Christoph Lameter, tj@kernel.org, linux-kernel@vger.kernel.org,
eric.dumazet@gmail.com, Huang, Ying, tglx@linutronix.de,
mingo@redhat.com, akpm@linux-foundation.org, davem@davemloft.net,
kaber@trash.net, a.p.zijlstra@chello.nl, kvm@vger.kernel.org,
jeremy@xensource.com
In-Reply-To: <1319424608.5061.25.camel@debian>
On 10/24/2011 04:50 AM, Alex,Shi wrote:
> On Thu, 2011-10-20 at 15:34 +0800, Alex,Shi wrote:
> > percpu_xxx funcs are duplicated with this_cpu_xxx funcs, so replace them
> > for further code clean up.
> >
> > And in preempt safe scenario, __this_cpu_xxx funcs has a bit better
> > performance since __this_cpu_xxx has no redundant preempt_disable()
> >
>
> Avi:
> Would you like to give some comments of this?
>
Sorry, was travelling:
Acked-by: Avi Kivity <avi@redhat.com>
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [PATCH] drivers: create a pin control subsystem v8
From: Grant Likely @ 2011-10-24 11:05 UTC (permalink / raw)
To: Linus Walleij
Cc: Mike Frysinger, Linus Walleij, Stephen Warren, Sascha Hauer,
Barry Song, linux-kernel, Joe Perches, Russell King, Linaro Dev,
Lee Jones, David Brown, linux-arm-kernel, Stijn Devriendt
In-Reply-To: <CACRpkdZ6DCeELLhiXF=oOMKB-DxeMuvbd_c6n4H1UDMhpHKZbA@mail.gmail.com>
On Mon, Oct 24, 2011 at 09:48:19AM +0200, Linus Walleij wrote:
> On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
> (...)
> >> I was more thinking along the lines of one device per GPIO controller,
> >> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
> >
> > And there is also the question of whether it is even a good idea to
> > export pinctrl manipulation to userspace.
>
> The application I've seen is in automatic control.
>
> I think people do things like connect they GPIO pins to electrical
> relays, plus on top of that they use all the stuff in drivers/staging/iio.
>
> All that from userspace. Controlling entire factories and industrial
> robots, weapon systems too, I'm afraid.
>
> The control of these dangerous things runs on a realtime-patched
> kernel, in a single userspace app with a few threads and they have
> done some realtime-tetris scheduling the beast more or less
> manually with SCHED_FIFO. Basically that app is all that runs on
> the board, and its threads take precedence over everything else
> on the system.
>
> That is the typical beast that is poking around on the GPIO sysfs
> interfaces...
... which maybe should be encouraged to use some form of uio driver. :-)
g.
^ permalink raw reply
* [Qemu-devel] KVM call agenda for October 25
From: Juan Quintela @ 2011-10-24 11:04 UTC (permalink / raw)
To: qemu-devel, KVM devel mailing list
Hi
Please send in any agenda items you are interested in covering.
Thanks, Juan.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.