[PATCH 1/3] mtd: nand: davinci: reuse driver for Keystone arch
The Keystone arch has compatible nand device, so reuse it.
In case with Keystone it depends on TI_AEMIF because AEMIF
driver is responsible to set timings.
See http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
Signed-off-by: Ivan Khoronzhuk
---
.../devicetree/bindings/mtd/davinci-nand.txt |8 +---
drivers/mtd/nand/Kconfig |6 +++---
drivers/mtd/nand/davinci_nand.c|1 +
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
index befaa5b..cfb18ab 100644
--- a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
@@ -1,14 +1,16 @@
-Device tree bindings for Texas instruments Davinci NAND controller
+Device tree bindings for Texas instruments Davinci/Keystone NAND controller
-This file provides information, what the device node for the davinci NAND
-interface contains.
+This file provides information, what the device node for the davinci/keystone
+NAND interface contains.
Documentation:
Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
+Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
Required properties:
- compatible: "ti,davinci-nand"
+ "ti,keystone-nand"
- reg: Contains 2 offset/length values:
- offset and length for the access window.
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index d885298..8bf69c7 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -492,11 +492,11 @@ config MTD_NAND_SH_FLCTL
for NAND Flash using FLCTL.
config MTD_NAND_DAVINCI
-tristate "Support NAND on DaVinci SoC"
-depends on ARCH_DAVINCI
+tristate "Support NAND on DaVinci/Keystone SoC"
+depends on ARCH_DAVINCI || (ARCH_KEYSTONE && TI_AEMIF)
help
Enable the driver for NAND flash chips on Texas Instruments
- DaVinci processors.
+ DaVinci/Keystone processors.
config MTD_NAND_TXX9NDFMC
tristate "NAND Flash support for TXx9 SoC"
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index f7b21b8..8459720 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -523,6 +523,7 @@ static struct nand_ecclayout hwecc4_2048 __initconst = {
#if defined(CONFIG_OF)
static const struct of_device_id davinci_nand_of_match[] = {
{.compatible = "ti,davinci-nand", },
+ {.compatible = "ti,keystone-nand", },
{},
};
MODULE_DEVICE_TABLE(of, davinci_nand_of_match);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] mtd: nand: davinci: don't set timings if AEMIF is used
The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for Keystone only.
The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set timings and bus width.
It is done by AEMIF driver (drivers/memory/ti-aemfi.c).
The timings code has to be removed together with Davinci aemif
platform code (aemif.c), once Davinci will be converted to DT and use
ti-aemif.c driver.
Signed-off-by: Ivan Khoronzhuk
---
drivers/mtd/nand/davinci_nand.c | 48 +--
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 8459720..e904364 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -605,6 +605,7 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
int ret;
uint32_tval;
nand_ecc_modes_tecc_mode;
+ bool aemif = IS_ENABLED(CONFIG_TI_AEMIF);
pdata = nand_davinci_get_pdata(pdev);
if (IS_ERR(pdata))
@@ -741,25 +742,38 @@ static int __init nand_davinci_probe(struct
platform_device *pdev)
}
/*
-* Setup Async configuration register in case we did not boot from
-* NAND and so bootloader did not bother to set it up.
+* TODO:
+* This is temp solution to support Davinci platform and it has to be
+* removed once Davinci will be updated to use ti-aemif.c driver.
*/
- val = davinci_nand_readl(info, A1CR_OFFSET + info->core_chipsel * 4);
-
- /* Extended Wait is not valid and Select Strobe mode is not used */
- val &= ~(ACR_ASIZE_MASK | ACR_EW_MASK | ACR_SS_MASK);
- if (info->chip.options & NAND_BUSWIDTH_16)
- val |= 0x1;
-
- davinci_nand_writel(info, A1CR_OFFSET + info->core_chipsel * 4, val);
+ if (!aemif) {
+ /*
+* Setup Async configuration register in case we did not boot
+* from NAND and so bootloader did not bother to set it up.
+*/
+ val = davinci_nand_readl(info, A1CR_OFFSET +
+info->core_chipsel * 4);
- ret = 0;
- if (info->timing)
- ret = davinci_aemif_setup_timing(info->timing, info->base,
- info->core_chipsel);
- if (ret < 0) {
- dev_dbg(>dev, "NAND timing values setup fail\n");
- goto err;
+ /*
+* Extended Wait is not valid and Select Strobe mode is not
+* used
+*/
+ val &= ~(ACR_ASIZE_MASK | ACR_EW_MASK | ACR_SS_MASK);
+ if (info->chip.options & NAND_BUSWIDTH_16)
+ val |= 0x1;
+
+ davinci_nand_writel(info, A1CR_OFFSET +
+ info->core_chipsel * 4, val);
+
+ ret = 0;
+ if (info->timing)
+ ret = davinci_aemif_setup_timing(info->timing,
+info->base,
+info->core_chipsel);
+ if (ret < 0) {
+ dev_dbg(>dev, "NAND timing values setup fail\n");
+ goto err;
+ }
}
spin_lock_irq(_nand_lock);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: dwc2: add check on dwc2_core_reset return
If the GRSTCTL_CSFTRST self-clearing bit never comes
back to 0 for any reason, the controller is under reset
state and cannot be used. It's preferable to abort
initialization in such case.
Signed-off-by: Julien Delacou
---
drivers/staging/dwc2/core.c | 58 +--
1 file changed, 45 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/dwc2/core.c b/drivers/staging/dwc2/core.c
index 27e1964..ecce1ef 100644
--- a/drivers/staging/dwc2/core.c
+++ b/drivers/staging/dwc2/core.c
@@ -116,7 +116,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg
*hsotg)
* Do core a soft reset of the core. Be careful with this because it
* resets all the internal state machines of the core.
*/
-static void dwc2_core_reset(struct dwc2_hsotg *hsotg)
+static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
@@ -131,7 +131,7 @@ static void dwc2_core_reset(struct dwc2_hsotg *hsotg)
dev_warn(hsotg->dev,
"%s() HANG! AHB Idle GRSTCTL=%0x\n",
__func__, greset);
- return;
+ return -EBUSY;
}
} while (!(greset & GRSTCTL_AHBIDLE));
@@ -146,7 +146,7 @@ static void dwc2_core_reset(struct dwc2_hsotg *hsotg)
dev_warn(hsotg->dev,
"%s() HANG! Soft Reset GRSTCTL=%0x\n",
__func__, greset);
- break;
+ return -EBUSY;
}
} while (greset & GRSTCTL_CSFTRST);
@@ -155,11 +155,14 @@ static void dwc2_core_reset(struct dwc2_hsotg *hsotg)
* not stay in host mode after a connector ID change!
*/
usleep_range(15, 20);
+
+ return 0;
}
-static void dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
+static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
{
u32 usbcfg, i2cctl;
+ int retval = 0;
/*
* core_init() is now called on every switch so only call the
@@ -172,7 +175,12 @@ static void dwc2_fs_phy_init(struct dwc2_hsotg *hsotg,
bool select_phy)
writel(usbcfg, hsotg->regs + GUSBCFG);
/* Reset after a PHY select */
- dwc2_core_reset(hsotg);
+ retval = dwc2_core_reset(hsotg);
+ if (retval) {
+ dev_err(hsotg->dev, "%s() Reset failed, aborting",
+ __func__);
+ return retval;
+ }
}
/*
@@ -200,14 +208,17 @@ static void dwc2_fs_phy_init(struct dwc2_hsotg *hsotg,
bool select_phy)
i2cctl |= GI2CCTL_I2CEN;
writel(i2cctl, hsotg->regs + GI2CCTL);
}
+
+ return retval;
}
-static void dwc2_hs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
+static int dwc2_hs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
{
u32 usbcfg;
+ int retval = 0;
if (!select_phy)
- return;
+ return -ENODEV;
usbcfg = readl(hsotg->regs + GUSBCFG);
@@ -240,20 +251,32 @@ static void dwc2_hs_phy_init(struct dwc2_hsotg *hsotg,
bool select_phy)
writel(usbcfg, hsotg->regs + GUSBCFG);
/* Reset after setting the PHY parameters */
- dwc2_core_reset(hsotg);
+ retval = dwc2_core_reset(hsotg);
+ if (retval) {
+ dev_err(hsotg->dev, "%s() Reset failed, aborting",
+ __func__);
+ return retval;
+ }
+
+ return retval;
}
-static void dwc2_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
+static int dwc2_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
{
u32 usbcfg;
+ int retval = 0;
if (hsotg->core_params->speed == DWC2_SPEED_PARAM_FULL &&
hsotg->core_params->phy_type == DWC2_PHY_TYPE_PARAM_FS) {
/* If FS mode with FS PHY */
- dwc2_fs_phy_init(hsotg, select_phy);
+ retval = dwc2_fs_phy_init(hsotg, select_phy);
+ if (retval)
+ return retval;
} else {
/* High speed PHY */
- dwc2_hs_phy_init(hsotg, select_phy);
+ retval = dwc2_hs_phy_init(hsotg, select_phy);
+ if (retval)
+ return retval;
}
if (hsotg->hw_params.hs_phy_type == GHWCFG2_HS_PHY_TYPE_ULPI &&
@@ -270,6 +293,8 @@ static void dwc2_phy_init(struct dwc2_hsotg *hsotg, bool
select_phy)
usbcfg &= ~GUSBCFG_ULPI_CLK_SUSP_M;
writel(usbcfg, hsotg->regs + GUSBCFG);
}
+
+ return retval;
}
static int dwc2_gahbcfg_init(struct dwc2_hsotg *hsotg)
@@ -421,12 +446,19 @@ int dwc2_core_init(struct dwc2_hsotg *hsotg, bool
select_phy, int irq)
writel(usbcfg, hsotg->regs +
Re: [PATCH 3.4 00/12] 3.4.70-stable review
On Wed, Nov 20, 2013 at 08:28:34AM -0700, Shuah Khan wrote: > On 11/18/2013 11:41 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.70 release. > > There are 12 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 Wed Nov 20 18:41:11 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.70-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > 3.4.70: > > patches applied cleanly > Compile test - passed > Boot tests - passed > > dmesg regression tests - passed > [dmesgs look good. No regressions compared to the previous dmesgs for > this release. dmesg emerg, crit, alert, err are clean. No regressions in > warn.] > > Cross-compile testing - limited tests passed (alpha, arm, arm64, > blackfin, c6x, powerpc, sh, sparc, tile) > > Test systems: > Samsung Series 9 900X4C Intel Corei5 (3.4 and later) > HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics > HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile testing) Thanks for testing all 4 kernels and letting me know they work. 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 3.4 00/12] 3.4.70-stable review
On Wed, Nov 20, 2013 at 08:04:45PM +0900, Satoru Takeuchi wrote: > At Mon, 18 Nov 2013 10:41:33 -0800, > Greg Kroah-Hartman wrote: > > > > This is the start of the stable review cycle for the 3.4.70 release. > > There are 12 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 Wed Nov 20 18:41:11 UTC 2013. > > Anything received after that time might be too late. > > This kernel can be built and boot without any problem. > Building a kernel with this kernel also works fine. > > - Build Machine: debian jessy x86_64 >CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 >memory: 8GB > > - Test machine: debian jessy x86_64(KVM guest on the Build Machine) >vCPU: x2 >memory: 2GB Thanks for testing this one, and the 3 others and letting me know they all work. 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 v4 1/2] watchdog: bcm281xx: Watchdog Driver
On Wed, Nov 20, 2013 at 08:12:37AM -0800, Markus Mayer wrote: > On 19 November 2013 11:07, Markus Mayer wrote: > > This commit adds support for the watchdog timer used on the BCM281xx > > family of SoCs. > > > > Signed-off-by: Markus Mayer > > Reviewed-by: Matt Porter > > Reviewed-by: Guenter Roeck > > --- > > drivers/watchdog/Kconfig| 22 +++ > > drivers/watchdog/Makefile |1 + > > drivers/watchdog/bcm_kona_wdt.c | 365 > > +++ > > 3 files changed, 388 insertions(+) > > create mode 100644 drivers/watchdog/bcm_kona_wdt.c > > > > [...] > > > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > > index 6c5bb27..7c860ca 100644 > > --- a/drivers/watchdog/Makefile > > +++ b/drivers/watchdog/Makefile > > @@ -55,6 +55,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o > > obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o > > obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o > > obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o > > +obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o > > > > # AVR32 Architecture > > obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o > > Just to let everyone know, due to the watchdog -> mainline merge a few > days ago, there's a trivial merge conflict now in the makefile. I'll > send out a re-based v5 of this patch once 3.13-rc1 has been tagged > (unless you would like a rebased-to-tip version before then). > Hi Markus, Yes, I noticed when I merged it into my watchdog-next branch. Reminds me ... v3 had a whitespace problem. I don't recall if you fixed that in v4. If you didn't, that might be a better reason to send v5. Take your patch and apply it with "git am" to find out. Thanks, 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: [PATCH 4/9] staging/lustre/lnet: Fix assert on empty group in selftest module
On Wed, Nov 20, 2013 at 05:26:57PM +0800, Peng Tao wrote: > On Wed, Nov 20, 2013 at 2:37 AM, Greg Kroah-Hartman > wrote: > > On Tue, Nov 19, 2013 at 09:23:43PM +0800, Peng Tao wrote: > >> From: Amir Shehata > >> > >> The core of the issue is that the selftest module doesn't sanitize its > >> own API, but it depends on lst utility to do such checks. As a result > >> this issue manifests itself in this particular LU through an assert > >> on an empty group. If the NID is misspelled then an empty group is > >> added. An error output is provided, but if that's never checked in a > >> batch script, as is the case with this issue, then the script will try > >> to add an empty group to a test to run in a batch, and that will cause > >> an assert > >> > >> The fix is two fold. Ensure that lst utility checks that a group is > >> added with at least one node. If not the group is subsequently > >> deleted. And the add_test command would fail, since the group no > >> longer exists. > >> > >> The second fix is to ensure that the kernel module itself sanitizes > >> its own API in this particular case, so that if a different utility is > >> used other than lst to communicate with the selftest kernel module > >> then this error would be caught. This fix looks up the batch and the > >> groups, src and dst, in the ioctl handle and sanitizes that input at > >> this point. If the group looked up either doesn't exist or doesn't > >> have at least one ACTIVE node, then the command fails. > >> > >> NOTE:there are many other cases in the code where the selftest kernel > >> module doesn't check for sanity of the input, but depends totally on > >> the lst module to do such checks. Particularly around length of > >> strings passed in. Thus it is possible to crash the selftest module > >> if someone tries to create another userspace app to communicate with > >> the selftest kernel module without ensuring sanity of the params sent > >> to the kernel module. In effect, it's always assumed that lst is the > >> front end for selftest and no other front end is to be used. > > > > This patch adds build warnings to the kernel build process, so I can't > > apply it, sorry. Please fix that up before sending it again. > > > Hi Greg, > > Can you please be explicit about what build warning you saw? I don't remember what it was at the moment, sorry. > I tried to reproduce it with gcc version 4.1.2 and 4.6.3 on my > machine, but didn't see any build warnings with this patch applied. I have 4.7.3 here, and x86-64. Try that and see what happens. 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: Why is O_DSYNC on linux so slow / what's wrong with my SSD?
Theodore Ts'o wrote: Historically, Intel has been really good about avoiding this, but since they've moved to using 3rd party flash controllers, I now advise everyone who plans to use any flash storage, regardless of the manufacturer, to do their own explicit power fail testing (hitting the reset button is not good enough, you need to kick the power plug out of the wall, or better yet, use a network controlled power switch you so you can repeat the power fail test dozens or hundreds of times for your qualification run) before being using flash storage in a mission critical situation where you care about data integrity after a power fail event. Speaking of which, what would you use to automate this sort of test? I'm thinking an SSD connected by eSATA, with an external power supply, and the host running inside a VM. Drop power to the drive at the same time as doing a kill -9 on the VM, then you can resume the VM pretty quickly instead of waiting for a full reboot sequence. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 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 v2 06/29] PCI/MSI: Get rid of useless count of msi_desc leftovers
Hello, Alexander.
On Fri, Oct 18, 2013 at 07:12:06PM +0200, Alexander Gordeev wrote:
> @@ -744,23 +744,6 @@ static int msix_capability_init(struct pci_dev *dev,
>
> return 0;
>
> -out_avail:
> - if (ret < 0) {
> - /*
> - * If we had some success, report the number of irqs
> - * we succeeded in setting up.
> - */
> - struct msi_desc *entry;
> - int avail = 0;
> -
> - list_for_each_entry(entry, >msi_list, list) {
> - if (entry->irq != 0)
> - avail++;
> - }
> - if (avail != 0)
> - ret = avail;
> - }
Hmmm... so, before this, the function would have returned the partial
number of irqs that arch set up successfully. Is it okay to lose that
information? If so, can you please elaborate a bit more on why it's
okay in the description?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Reuse davinci-nand driver for Keystone arch
This series contains updates of Davinci nand driver, in order to be reused for Keystone platform. Depends on: - Davinci nand driver fixes and updates: https://lkml.org/lkml/2013/11/20/271 - Introduce AEMIF driver for Davinci/Keystone archs: http://lkml.org/lkml/2013/11/11/352 V1: https://lkml.org/lkml/2013/11/11/352 Ivan Khoronzhuk (3): mtd: nand: davinci: reuse driver for Keystone arch mtd: nand: davinci: don't set timings if AEMIF is used mtd: nand: davinci: don't request AEMIF address range .../devicetree/bindings/mtd/davinci-nand.txt |8 +-- drivers/mtd/nand/Kconfig |6 +-- drivers/mtd/nand/davinci_nand.c| 57 +--- 3 files changed, 45 insertions(+), 26 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] mtd: nand: davinci: don't request AEMIF address range
The TI AEMIF driver registers are used to setup timings for each chip
select. The same registers range is used to setup NAND settings.
The AEMIF and NAND drivers not use the same registers in this range.
In case with TI AEMIF driver, the memory address range is requested
already by AEMIF, so we cannot request it twice, just ioremap.
Signed-off-by: Ivan Khoronzhuk
Acked-by: Santosh Shilimkar
---
drivers/mtd/nand/davinci_nand.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index e904364..aa30708 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -638,9 +638,11 @@ static int __init nand_davinci_probe(struct
platform_device *pdev)
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
- base = devm_ioremap_resource(>dev, res2);
- if (IS_ERR(base))
- return PTR_ERR(base);
+ base = devm_ioremap(>dev, res2->start, resource_size(res2));
+ if (!base) {
+ dev_err(>dev, "ioremap failed for resource %pR\n", res2);
+ return -EADDRNOTAVAIL;
+ }
info->dev = >dev;
info->base = base;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, acpi, idle: Restructure the mwait idle routines
On 11/20/2013 2:58 AM, Peter Zijlstra wrote: On Wed, Nov 20, 2013 at 11:28:03AM +0100, Peter Zijlstra wrote: On Tue, Nov 19, 2013 at 01:06:30PM -0800, Jacob Pan wrote: I applied this patch on top of upstream kernel (801a760) and found out my machine completely failed to enter idle when nothing is running. turbostate shows 100% C0. ftrace shows kernel coming in and out of idle frequently. Both ACPI idle and intel_idle behaves the same way. I have to do the following change to allow entering C-states again. That doesn't make any sense; current_set_polling_and_test() returns the same thing need_resched() does. But you're right, intel_idle resides 100% in C0 and acpi_idle has 100% C1 residency... most weird. So pretty silly actually; you cannot do a store (any store) in between monitor and mwait. you can just not to the cacheline you are watching (or things that alias with that) -- 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 v2 11/29] PCI/MSI: Convert pci_msix_table_size() to a public interface
Hello, On Fri, Oct 18, 2013 at 07:12:11PM +0200, Alexander Gordeev wrote: > Make pci_msix_table_size() return error code if the device > does not support MSI-X. This update is needed to create a > consistent MSI-X counterpart for pci_get_msi_cap() MSI > interface. > > Device drivers can use this interface to obtain maximum number > of MSI-X interrupts the device supports and i.e. use that number > in a following call to pci_enable_msix() interface. Please mention that the return value of the function has been changed in the description. Also, do we want to rename it to pci_get_msix_cap() for consistency? > Signed-off-by: Alexander Gordeev Reviewed-by: Tejun Heo Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression x2, 3.13-git] virtio block mq hang, iostat busted on virtio devices
On 11/20/2013 01:07 AM, Christoph Hellwig wrote:
>> Just stumbled on that too. You need one more, btw, for the sg failure
>> case:
>>
>>
>> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
>> index 588479d58f52..6a680d4de7f1 100644
>> --- a/drivers/block/virtio_blk.c
>> +++ b/drivers/block/virtio_blk.c
>> @@ -199,15 +199,16 @@ static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx,
>> struct request *req)
>>
>> spin_lock_irqsave(>vq_lock, flags);
>> if (__virtblk_add_req(vblk->vq, vbr, vbr->sg, num) < 0) {
>> +virtqueue_kick(vblk->vq);
>> spin_unlock_irqrestore(>vq_lock, flags);
>> blk_mq_stop_hw_queue(hctx);
>> -virtqueue_kick(vblk->vq);
>> return BLK_MQ_RQ_QUEUE_BUSY;
>> }
>> -spin_unlock_irqrestore(>vq_lock, flags);
>>
>> if (last)
>> virtqueue_kick(vblk->vq);
>> +
>> +spin_unlock_irqrestore(>vq_lock, flags);
>
> Note that virtqueue_kick can be split into a virtqueue_prepare_split
> that needs the lock, and a virtqueue_notify that doesn't, but it might
> not be nessecary to do that optimization right now.
Right, that would be easily doable. Seems it's in the realm of micro
optimizations, but worth doing next time it's touched.
> Btw, how much do I need to bribe you to send mails where I don't have
> step over 500 lines of dead quotes to find the actual patch?
Sorry, the next one was trimmed :-)
--
Jens Axboe
--
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 00/10] AMD Cryptographic Coprocessor support
Hi Herbert, Is the crypto tree the right tree to go through for this support or would you prefer I go through another tree? Thanks, Tom On Tuesday, November 12, 2013 11:45:59 AM Tom Lendacky wrote: > Resending because of typo in mailing list address... > > The following series implements support for the AMD Cryptographic > Coprocessor (CCP). The AMD CCP provides hardware encryption, hashing > and other related operations. > > This patch series is based on the 3.12 kernel. > > --- > > Tom Lendacky (10): > crypto: authenc - Find proper IV address in ablkcipher callback > crypto: scatterwalk - Set the chain pointer indication bit > crypto: CCP device driver and interface support > crypto: crypto API interface to the CCP device driver > crypto: CCP AES crypto API support > crypto: CCP AES CMAC mode crypto API support > crypto: CCP XTS-AES crypto API support > crypto: CCP SHA crypto API support > crytpo: CCP device driver build files > crypto: CCP maintainer information > > > MAINTAINERS |7 > crypto/authenc.c |7 > drivers/crypto/Kconfig | 12 > drivers/crypto/Makefile |1 > drivers/crypto/ccp/Kconfig | 23 > drivers/crypto/ccp/Makefile | 10 > drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 355 + > drivers/crypto/ccp/ccp-crypto-aes-xts.c | 285 > drivers/crypto/ccp/ccp-crypto-aes.c | 375 ++ > drivers/crypto/ccp/ccp-crypto-main.c | 432 ++ > drivers/crypto/ccp/ccp-crypto-sha.c | 497 +++ > drivers/crypto/ccp/ccp-crypto.h | 191 +++ > drivers/crypto/ccp/ccp-dev.c | 582 + > drivers/crypto/ccp/ccp-dev.h | 272 > drivers/crypto/ccp/ccp-ops.c | 2020 > ++ drivers/crypto/ccp/ccp-pci.c | > 360 + > include/crypto/scatterwalk.h |1 > include/linux/ccp.h | 525 > 18 files changed, 5952 insertions(+), 3 deletions(-) > create mode 100644 drivers/crypto/ccp/Kconfig > create mode 100644 drivers/crypto/ccp/Makefile > create mode 100644 drivers/crypto/ccp/ccp-crypto-aes-cmac.c > create mode 100644 drivers/crypto/ccp/ccp-crypto-aes-xts.c > create mode 100644 drivers/crypto/ccp/ccp-crypto-aes.c > create mode 100644 drivers/crypto/ccp/ccp-crypto-main.c > create mode 100644 drivers/crypto/ccp/ccp-crypto-sha.c > create mode 100644 drivers/crypto/ccp/ccp-crypto.h > create mode 100644 drivers/crypto/ccp/ccp-dev.c > create mode 100644 drivers/crypto/ccp/ccp-dev.h > create mode 100644 drivers/crypto/ccp/ccp-ops.c > create mode 100644 drivers/crypto/ccp/ccp-pci.c > create mode 100644 include/linux/ccp.h -- Tom Thomas Lendacky Advanced Micro Devices, Inc. -- 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: [Regression x2, 3.13-git] virtio block mq hang, iostat busted on virtio devices
On 11/20/2013 01:04 AM, Christoph Hellwig wrote: > On Tue, Nov 19, 2013 at 02:43:51PM -0700, Jens Axboe wrote: >> No, the nr_requests isn't actually relevant in the blk-mq context, the >> driver sets its own depth. For the above, it's 64 normal commands, and 2 >> reserved. The reserved would be for a flush, for instance. If someone >> attempts to queue more than the allocated number of requests, it'll stop >> the blk-mq queue and kick things into gear on the virtio side. Then when >> requests complete, we start the queue again. > > Btw, any reason we lowerered the queue depth from 128 to 64 in > virtio-blk? No, we can easily bump it to 128 again, I think it was a leftover from where it had more queues and testing. -- Jens Axboe -- 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 v2 10/29] PCI/MSI: Get rid of pci_enable_msi_block_auto() interface
On Fri, Oct 18, 2013 at 07:12:10PM +0200, Alexander Gordeev wrote: > As result of introduction of pci_get_msi_cap() interface > pci_enable_msi_block_auto() function became superflous. > > To enable maximum possible number of MSIs drivers will > first obtain that number from pci_get_msi_cap() function > and then call pci_enable_msi_block() interface. It'd be nice to mention that _auto has been introduced recently and has only single user in ahci which is updated by this patch. > Signed-off-by: Alexander Gordeev Acked-by: Tejun Heo Bjorn, please feel free to route this through pci branch. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] parisc fixes for v3.13
Hi Linus, Please pull the latest fixes for the parisc architecture from git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-3.13 which has the following fixes: - revert an access_ok() patch which broke 32bit userspace on 64bit kernels - avoid a gcc miscompilation in two internal pa_memcpy() functions by not inlining those - do not export the definition of SOCK_NONBLOCK via uapi header (fixes build of audit package) - depending on the fault type we now correctly report either SIGBUS or SIGSEGV - a small fix to not compare a size_t variable for < 0 Thanks, Helge Helge Deller (5): Revert "parisc: implement full version of access_ok()" parisc: do not inline pa_memcpy() internal functions parisc: break out SOCK_NONBLOCK define to own asm header file parisc: improve SIGBUS/SIGSEGV error reporting parisc: size_t is unsigned, so comparison size < 0 doesn't make sense. arch/parisc/include/asm/socket.h | 11 + arch/parisc/include/asm/uaccess.h | 46 +++ arch/parisc/include/uapi/asm/socket.h | 11 +++-- arch/parisc/lib/memcpy.c | 6 ++--- arch/parisc/mm/fault.c| 22 +++-- 5 files changed, 41 insertions(+), 55 deletions(-) create mode 100644 arch/parisc/include/asm/socket.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] staging: imx-drm: Fix modular build of DRM_IMX_IPUV3
On Wed, Nov 20, 2013 at 08:16:32AM -0500, Josh Boyer wrote: > On Tue, Nov 19, 2013 at 09:39:19PM -0800, Greg KH wrote: > > On Tue, Nov 19, 2013 at 08:56:59PM -0500, Josh Boyer wrote: > > > On Mon, Nov 18, 2013 at 10:03:10AM +0100, Sascha Hauer wrote: > > > > On Tue, Nov 12, 2013 at 12:15:45PM -0500, Josh Boyer wrote: > > > > > commit b8d181e408af (staging: drm/imx: add drm plane support) added a > > > > > file > > > > > to the make target for DRM_IMX_IPUV3 but didn't adjust the objs > > > > > required > > > > > to actually build that as a module. Kbuild got confused and this > > > > > lead to > > > > > link errors like: > > > > > > > > > > ERROR: "ipu_plane_disable" [drivers/staging/imx-drm/ipuv3-crtc.ko] > > > > > undefined! > > > > > ERROR: "ipu_plane_enable" [drivers/staging/imx-drm/ipuv3-crtc.ko] > > > > > undefined! > > > > > > > > > > Additionally, it added a call to imx_drm_crtc_id which also fails > > > > > with a > > > > > link error as above. To fix this, we adjust the make target with the > > > > > proper > > > > > objs, which will change the name of the resulting .ko. We also add an > > > > > EXPORT_SYMBOL_GPL for imx_drm_crtc_id. > > > > > > > > > > Signed-off-by: Josh Boyer > > > > > > > > > > > > Acked-by: Sascha Hauer > > > > > > > > Sascha > > > > > > Thanks. So who picks this fix up? Greg, is that you? > > > > Yes, I will once 3.13-rc1 is out. > > OK. And send it to Linus for 3.13-rc2? I know you've been traveling > and are busy, so I'm just pointing out it's a fix for 3.13. Yes, it will be queued up for 3.13-final. -- 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 v2 09/29] PCI/MSI: Factor out pci_get_msi_cap() interface
Hello,
On Fri, Oct 18, 2013 at 07:12:09PM +0200, Alexander Gordeev wrote:
> +If this function returns a negative number, it indicates the device is
> +not capable of sending MSIs.
Wouldn't "errno" better describe the error return rather than
"negative number"?
> @@ -795,6 +795,21 @@ static int pci_msi_check_device(struct pci_dev *dev, int
> nvec, int type)
> return 0;
> }
We probably want a function comment here?
> +int pci_get_msi_cap(struct pci_dev *dev)
> +{
> + int ret;
> + u16 msgctl;
> +
> + if (!dev->msi_cap)
> + return -EINVAL;
> +
> + pci_read_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, );
> + ret = 1 << ((msgctl & PCI_MSI_FLAGS_QMASK) >> 1);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(pci_get_msi_cap);
Other than that,
Reviewed-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] ARM: at91/dt: add i2c devices connected to at91rm9200ek board
On 20/11/2013 16:01, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 13:08 Wed 28 Aug , Boris BREZILLON wrote:
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/at91rm9200ek.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/at91rm9200ek.dts
b/arch/arm/boot/dts/at91rm9200ek.dts
index b3e7425..fd2601a 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -147,6 +147,18 @@
};
};
+ i2c@0 {
+ status = "okay";
+
+ ics1523@26 {
+ reg = <0x26>;
+ };
+
+ dac3550@4d {
+ reg = <0x4d>;
missing compatible
I can't find any matching compatible for these devices.
Do you know what should be used ?
+ };
+ };
+
leds {
compatible = "gpio-leds";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board
On 20/11/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 13:06 Wed 28 Aug , Boris BREZILLON wrote:
Add slot0 of mmc0 pinctrl pins definitions:
- detect pin
- write protect pin
- enable slot0 pin: this pin is connected to an external switch which
enable mmc0 slot0 or spi dataflash connected to cs3
The mmc0 device is not enabled, as it depends on the choosen functionnality
(spi cs3 or mmc0 slot0).
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/at91rm9200ek.dts | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/at91rm9200ek.dts
b/arch/arm/boot/dts/at91rm9200ek.dts
index f2d6d79..2bad423 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -39,6 +39,23 @@
atmel,pins = ;
};
};
+
+ mmc0 {
+ pinctrl_mmc0_slot0_detect:
mmc0_slot0_detect-0 {
+ atmel,pins =
+ ;
+ };
+
+ pinctrl_mmc0_slot0_write_protect:
mmc0_slot0_write_protect-0 {
+ atmel,pins =
+ ;
+ };
+
+ pinctrl_mmc0_slot0_switch:
mmc0_slot0_switch-0 {
+ atmel,pins =
+ ;
+ };
nack this is a regulator the pinctrl API is not done for gpio default value
I know this can be represented as a regulator, but looking at the
datasheet, this looks more
like a switch than a regulator.
Anyway, why didn't you told me that when I proposed the OUTPUT support
for at91 pinctrl driver ?
And BTW pinctrl OUTPUT config is already supported by some pinctrl drivers
(
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt#L159).
+ };
};
dbgu: serial@f200 {
@@ -84,6 +101,24 @@
reg = <0>;
};
};
+
+ mmc0: mmc@fffb4000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-0 = <_mmc0_clk
+_mmc0_slot0_cmd_dat0
+_mmc0_slot0_dat1_3
+_mmc0_slot0_detect
+_mmc0_slot0_write_protect
+_mmc0_slot0_switch>;
+
+ slot0: slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = < 27 GPIO_ACTIVE_HIGH>;
+ wp-gpios = < 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
};
usb0: ohci@0030 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] virtio-net: fix page refcnt leaking when fail to allocate frag skb
On Wed, 2013-11-20 at 18:06 +0200, Michael S. Tsirkin wrote: > Hmm some kind of disconnect here. > I got you rmanagement about bufferbloat. > > What I am saying is that maybe we should drop packets more > aggressively: when we drop one packet of a flow, why not > drop everything that's queued and is for the same flow? I really hope your TCP flows use SACK ;) Please read the rfc 2018 introduction for details. If a packet is dropped, it doesn't mean following packets _have_ to be dropped. -- 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 v2 08/29] PCI/MSI: Make pci_enable_msix() 'nvec' argument unsigned int
Hello, On Fri, Oct 18, 2013 at 07:12:08PM +0200, Alexander Gordeev wrote: > Make pci_enable_msix() and pci_enable_msi_block() consistent > with regard to the type of 'nvec' argument. Indeed, a number > of vectors to allocate is a natural value, so make it unsigned. I'm personally not a big fan of using unsigneds where they're just used as numbers unless strictly necessary. They don't really provide any meaningful protection and we often end up in situations where we want to encode error conditions in the same type variable as return value or whatever and end up with silly situations like functions which take unsigned and returns integer or having a separate err variable when the high bit of the orignal variable would have worked just fine. Also, people have different thresholds for what should be unsigned and we end up with half things unsigned and the other signed. I'll defer the decision to Bjorn but I'd vote for converting things to int. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] watchdog: bcm281xx: Watchdog Driver
On 19 November 2013 11:07, Markus Mayer wrote: > This commit adds support for the watchdog timer used on the BCM281xx > family of SoCs. > > Signed-off-by: Markus Mayer > Reviewed-by: Matt Porter > Reviewed-by: Guenter Roeck > --- > drivers/watchdog/Kconfig| 22 +++ > drivers/watchdog/Makefile |1 + > drivers/watchdog/bcm_kona_wdt.c | 365 > +++ > 3 files changed, 388 insertions(+) > create mode 100644 drivers/watchdog/bcm_kona_wdt.c > [...] > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > index 6c5bb27..7c860ca 100644 > --- a/drivers/watchdog/Makefile > +++ b/drivers/watchdog/Makefile > @@ -55,6 +55,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o > obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o > obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o > obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o > +obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o > > # AVR32 Architecture > obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o Just to let everyone know, due to the watchdog -> mainline merge a few days ago, there's a trivial merge conflict now in the makefile. I'll send out a re-based v5 of this patch once 3.13-rc1 has been tagged (unless you would like a rebased-to-tip version before then). Regards, -Markus -- Markus Mayer Broadcom Landing Team -- 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 v2 07/29] PCI/MSI: Return -ENOSYS for unimplemented interfaces, not -1
On Fri, Oct 18, 2013 at 07:12:07PM +0200, Alexander Gordeev wrote: > Signed-off-by: Alexander Gordeev > Suggested-by: Ben Hutchings Yes, please. Reviewed-by: Tejun Heo Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] uprobes: uprobe_task/arch_uprobe/xol_area cleanups
Ingo, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc uprobes/core Another short series. No functional changes, everything was acked. Oleg Nesterov (5): uprobes: Add uprobe_task->dup_xol_work/dup_xol_addr uprobes: Don't assume that arch_uprobe->insn/ixol is u8[MAX_UINSN_BYTES] uprobes/powerpc: Kill arch_uprobe->ainsn uprobes: Cleanup !CONFIG_UPROBES decls, unexport xol_area uprobes: Document xol_area and arch_uprobe->insn/ixol arch/powerpc/include/asm/uprobes.h |5 +-- arch/powerpc/kernel/uprobes.c |2 +- include/linux/uprobes.h| 52 --- kernel/events/uprobes.c| 60 +-- 4 files changed, 66 insertions(+), 53 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mm, vmscan: abort futile reclaim if we've been oom killed
On Mon, Nov 18, 2013 at 05:17:31PM -0800, David Rientjes wrote: > On Mon, 18 Nov 2013, Johannes Weiner wrote: > > > > Um, no, those processes are going through a repeated loop of direct > > > reclaim, calling the oom killer, iterating the tasklist, finding an > > > existing oom killed process that has yet to exit, and looping. They > > > wouldn't loop for too long if we can reduce the amount of time that it > > > takes for that oom killed process to exit. > > > > I'm not talking about the big loop in the page allocator. The victim > > is going through the same loop. This patch is about the victim being > > in a pointless direct reclaim cycle when it could be exiting, all I'm > > saying is that the other tasks doing direct reclaim at that moment > > should also be quitting and retrying the allocation. > > > > "All other tasks" would be defined as though sharing the same mempolicy > context as the oom kill victim or the same set of cpuset mems, I'm not > sure what type of method for determining reclaim eligiblity you're > proposing to avoid pointlessly spinning without making progress. Until an > alternative exists, my patch avoids the needless spinning and expedites > the exit, so I'll ask that it be merged. I laid this out in the second half of my email, which you apparently did not read: "If we have multi-second stalls in direct reclaim then it should be fixed for all direct reclaimers. The problem is not only OOM kill victims getting stuck, it's every direct reclaimer being stuck trying to do way too much work before retrying the allocation. Kswapd checks the system state after every priority cycle. Direct reclaim should probably do the same and retry the allocation after every priority cycle or every X pages scanned, where X is something reasonable and not "up to every LRU page in the system"." NAK to this incomplete drive-by fix. -- 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] virtio-net: fix page refcnt leaking when fail to allocate frag skb
On Wed, Nov 20, 2013 at 07:16:33AM -0800, Eric Dumazet wrote: > On Wed, 2013-11-20 at 10:58 +0200, Michael S. Tsirkin wrote: > > On Tue, Nov 19, 2013 at 02:00:11PM -0800, Eric Dumazet wrote: > > > On Tue, 2013-11-19 at 23:53 +0200, Michael S. Tsirkin wrote: > > > > > > > Which NIC? Virtio? Prior to 2613af0ed18a11d5c566a81f9a6510b73180660a > > > > it didn't drop packets received from host as far as I can tell. > > > > virtio is more like a pipe than a real NIC in this respect. > > > > > > Prior/after to this patch, you were not posting buffers, so if packets > > > were received on a physical NIC, you were dropping the packets anyway. > > > > > > It makes no difference at all, adding a cushion might make you feel > > > better, but its really not worth it. > > > > > > Under memory stress, it makes better sense to drop a super big GRO > > > packet (The one needing frag_list extension ...) > > > > > > It gives a better signal to the sender to reduce its pressure, and gives > > > opportunity to free more of your memory. > > > > > > > OK, but in that case one wonders whether we should do more to free memory? > > > > E.g. imagine that we dropped a packet of a specific TCP flow > > because we couldn't allocate a new packet. > > > > What happens now is that the old packet is freed as well. > > > > So quite likely the next packet in queue will get processed > > since it will reuse the memory we have just freed. > > > > The next packet and the next after it etc all will have to go through > > the net stack until they get at the socket and are dropped then > > because we missed a segment. Even worse, GRO gets disabled so the load > > on receiver goes up instead of down. > > > > Sounds like a problem doesn't it? > > I see no problem at all. GRO is a hint for high rates (and obviously > when there is enough memory) > > > > > GRO actually detects it's the same flow and can see packet is > > out of sequence. Why doesn't it drop the packet then? > > Alternatively, we could (for example using the pre-allocated skb > > like I suggested) notify GRO that it should start dropping packets > > of this flow. > > > > What do you think? > > > > I think we disagree a lot on memory management on networking stacks. > > We did a lot of work in TCP stack and Qdisc layers to lower memory > pressure (and bufferbloat), an you seem to try hard to introduce yet > another layer of buffer bloat in virtio_net. > > So add whatever you want to proudly state to your management : > > "Look how smart we are : we drop no packets in our layer" > Hmm some kind of disconnect here. I got you rmanagement about bufferbloat. What I am saying is that maybe we should drop packets more aggressively: when we drop one packet of a flow, why not drop everything that's queued and is for the same flow? -- 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] IOMMU: Save pci device id instead of pci_dev* pointer for DMAR devices
On Fri, 2013-11-08 at 08:46 -0700, Bjorn Helgaas wrote: > > I don't know the IOMMU drivers well either, but it seems like they > rely on notifications of device addition and removal (see > iommu_bus_notifier()). It doesn't seem right for them to also use the > generic PCI interfaces like pci_get_domain_bus_and_slot() because the > IOMMU driver should already know what devices exist and their > lifetimes. It seems like confusion to mix the two. But I don't have > a concrete suggestion. The generic IOMMU code has a notifier, and calls through to an ->add_device() method in the specific IOMMU driver's iommu_ops. The Intel IOMMU driver predates that, and its scheme for mapping devices to the correct DMAR unit is different. It happens entirely within the get_domain_for_dev() function, which happens when we're first asked to set up a mapping for a given device (when we don't already have the answer stashed in dev->archdata). I think we should add an ->add_device() method to the Intel IOMMU driver, and make it do much of what's in get_domain_for_dev() right now — finding the "proxy" device (the upstream PCIe bridge or whatever), and then looking through the ACPI DMAR table to find which DMAR unit that's attached to. Then we stash that information (dmar, devfn) in dev->archdata, and get_domain_for_dev() still has *some* work to do, actually allocating a logical domain on the IOMMU in question, but not as much. And refcount the damn domain instead of playing the horrid tricks we currently do to hang it off the upstream proxy device *too*. My main concern here is that the DMAR table contains the PCI bus numbers at boot time. Doing the lookup later will only work if we don't renumber busses. Or if we have a way to look things up based on the *original* bus number. The Intel IOMMU also has a bus notifier of its own which it only uses to know when a driver is *detached*, so it can tear down the logical domain for the corresponding device. Would be nice to have the generic IOMMU notifier call a callback for us then too, perhaps. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
linux-kernel@vger.kernel.org
Re: [PATCH 1/9] ARM: at91/dt: add rm9200 spi0 chip select pins definitions
On 20/11/2013 15:56, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 13:02 Wed 28 Aug , Boris BREZILLON wrote:
Add spi0 cs pinctrl pins definitions.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/at91rm9200.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
b/arch/arm/boot/dts/at91rm9200.dtsi
index f770655..69b76c7 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -486,6 +486,26 @@
AT91_PIOA 1
AT91_PERIPH_A AT91_PINCTRL_NONE/* PA1 periph A SPI0_MOSI pin */
AT91_PIOA 2 AT91_PERIPH_A
AT91_PINCTRL_NONE>; /* PA2 periph A SPI0_SPCK pin */
};
+
+ pinctrl_spi0_cs0: spi0_cs0-0 {
+ atmel,pins =
+ ;/* PA3 periph A SPI0_NPCS0 pin */
+ };
+
+ pinctrl_spi0_cs1: spi0_cs1-0 {
+ atmel,pins =
+ ; /* PA4 GPIO SPI0_NPCS1 pin */
+ };
+
+ pinctrl_spi0_cs2: spi0_cs2-0 {
+ atmel,pins =
+ ; /* PA5 GPIO SPI0_NPCS2 pin */
+ };
+
+ pinctrl_spi0_cs3: spi0_cs3-0 {
+ atmel,pins =
+ ; /* PA6 GPIO SPI0_NPCS3 pin */
+ };
nack the pin are not multidrive there is only one master
Right, this is a mistake.
But the pins should be configured as OUTPUT with HIGH level
(see
http://lxr.free-electrons.com/source/arch/arm/mach-at91/at91rm9200_devices.c#L589).
Best Regards,
J.
};
pioA: gpio@f400 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-kernel@vger.kernel.org
Re: [PATCH 3/9] ARM: at91/dt: add usb1 vbus and pullup pins
On 20/11/2013 15:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 13:04 Wed 28 Aug , Boris BREZILLON wrote:
Add vbus and pullup pinctrl definitions.
Request the vbus and pullup pins in usb1 node.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/at91rm9200ek.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/at91rm9200ek.dts
b/arch/arm/boot/dts/at91rm9200ek.dts
index 37b0880..76f3e87 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -29,6 +29,18 @@
ahb {
apb {
+ pinctrl@f400 {
+ usb1 {
+ pinctrl_usb1_vbus: usb1_vbus-0 {
+ atmel,pins = ;
+ };
it's a gpio no-need
Okay, noted.
I thought I had to declare gpio configured pins in order to detect pin
conflicts.
But after taking a closer look at the pinctrl core and at91 pinctrl
driver, it seems this is automatically done
by means of the pinctrl_request_gpio function.
+
+ pinctrl_usb1_pullup: usb1_pullup-0 {
+ atmel,pins = ;
+ };
no-need multidrive
Then why is it configured with multi-drive option in the board file
(
http://lxr.free-electrons.com/source/arch/arm/mach-at91/board-rm9200ek.c#L166)
?
+ };
+ };
+
dbgu: serial@f200 {
status = "okay";
};
@@ -56,6 +68,9 @@
usb1: gadget@fffb {
atmel,vbus-gpio = < 4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_usb1_vbus
+_usb1_pullup>;
status = "okay";
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 05/29] PCI/MSI: Fix return value when populate_msi_sysfs() failed
On Fri, Oct 18, 2013 at 07:12:05PM +0200, Alexander Gordeev wrote: > If populate_msi_sysfs() function failed msix_capability_init() > must return the error code, but it returns the success instead. > This update fixes the described misbehaviour. > > Signed-off-by: Alexander Gordeev Reviewed-by: Tejun Heo Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?
On Wed, Nov 20, 2013 at 10:37:03AM -0500, Theodore Ts'o wrote: > On Wed, Nov 20, 2013 at 08:52:36PM +0530, Chinmay V S wrote: > > > > If you have confirmed the performance numbers, then it indicates that > > the Intel 530 controller is more advanced and makes better use of the > > internal disk-cache to achieve better performance (as compared to the > > Intel 520). Thus forcing CMD_FLUSH on each IOP (negating the benefits > > of the disk write-cache and not allowing any advanced disk controller > > optimisations) has a more pronouced effect of degrading the > > performance on Intel 530 SSDs. (Someone with some actual info on Intel > > SSDs kindly confirm this.) > > You might also want to do some power fail testing to make sure that > the SSD is actually flusing all of its internal Flash Translation > Layer (FTL) metadata to stable storage on every CMD_FLUSH command. Some SSD's are also claim the ability to flush the cache on power loss: http://www.intel.com/content/www/us/en/solid-state-drives/ssd-320-series-power-loss-data-protection-brief.html Which should in theory let them respond immediately to flush requests, right? Except they only seem to advertise it as a safety (rather than a performance) feature, so I probably misunderstand something. And the 520 doesn't claim this feature (look for "enhanced power loss protection" at http://ark.intel.com/products/66248), so that wouldn't explain these results anyway. --b. > > There are lots of flash media that don't do this, with the result that > I get lots of users whining at me when their file system stored on an > SD card has massive corruption after a power fail event. > > Historically, Intel has been really good about avoiding this, but > since they've moved to using 3rd party flash controllers, I now advise > everyone who plans to use any flash storage, regardless of the > manufacturer, to do their own explicit power fail testing (hitting the > reset button is not good enough, you need to kick the power plug out > of the wall, or better yet, use a network controlled power switch you > so you can repeat the power fail test dozens or hundreds of times for > your qualification run) before being using flash storage in a mission > critical situation where you care about data integrity after a power > fail event. > > IOW, make sure that the SSD isn't faster because it's playing fast and > loose with the FTL metadata > > Cheers, > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 6/7] mtd: nand: davinci: extend description of bindings
On 11/20/2013 05:46 PM, Arnd Bergmann wrote: On Wednesday 20 November 2013, Ivan Khoronzhuk wrote: Extend bindings for davinci_nand driver to be more clear. Signed-off-by: Ivan Khoronzhuk --- .../devicetree/bindings/mtd/davinci-nand.txt | 77 ++-- 1 file changed, 54 insertions(+), 23 deletions(-) Hi Ivan, The changes look good to me, but please clarify in the changeset description above whether this is a backwards-compatible change, a clarification without semantic changes, or an incompatible change (which should be avoided). Arnd This is a clarification only, without semantic changes. Thanks, I'll update. -- Regards, Ivan Khoronzhuk -- 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] ACPI / hotplug: Fix PCI host bridge hot removal
On Wed, 2013-11-20 at 12:56 +0100, Rafael J. Wysocki wrote: > On Tuesday, November 19, 2013 06:22:07 PM Toshi Kani wrote: > > On Wed, 2013-11-20 at 01:08 +0100, Rafael J. Wysocki wrote: > > > On Wednesday, November 20, 2013 12:42:28 AM Rafael J. Wysocki wrote: > > > > On Tuesday, November 19, 2013 02:58:40 PM Toshi Kani wrote: > > > > > On Tue, 2013-11-19 at 22:10 +0100, Rafael J. Wysocki wrote: > > > > > > > On Tuesday, November 19, 2013 10:48:51 AM Toshi Kani wrote: > > > > > > > > On Mon, 2013-11-18 at 22:39 +0100, Rafael J. Wysocki wrote: > > > > > > > > > On Monday, November 18, 2013 11:10:05 AM Toshi Kani wrote: > > > > > > > > > > On Thu, 2013-11-14 at 00:16 +0100, Rafael J. Wysocki wrote: > > > > > > > > > > > From: Rafael J. Wysocki > > > > > > > > > > > > > > > > > > > > > > Since the PCI host bridge scan handler does not set > > > > > > > > > > > hotplug.enabled, > > > > > > > > > > > the check of it in acpi_bus_device_eject() effectively > > > > > > > > > > > prevents the > > > > > > > > > > > root bridge hot removal from working after commit > > > > > > > > > > > a3b1b1ef78cd > > > > > > > > > > > (ACPI / hotplug: Merge device hot-removal routines). > > > > > > > > > > > However, that > > > > > > > > > > > check is not necessary, because the other > > > > > > > > > > > acpi_bus_device_eject() > > > > > > > > > > > users, acpi_hotplug_notify_cb and acpi_eject_store(), do > > > > > > > > > > > the same > > > > > > > > > > > check by themselves before executing that function. > > > > > > > > > > > > > > > > > > > > > > For this reason, remove the scan handler check from > > > > > > > > > > > acpi_bus_device_eject() to make PCI hot bridge hot > > > > > > > > > > > removal work > > > > > > > > > > > again. > > > > > > > > > > > > > > > > > > > > I am curious why the PCI host bridge scan handler does not > > > > > > > > > > set > > > > > > > > > > hotplug.enabled. Is this how it disables hotplug via sysfs > > > > > > > > > > eject but > > > > > > > > > > enables via ACPI notification? > > > > > > > > > > > > > > > > > > It just doesn't register for hotplug at all. I guess it > > > > > > > > > could set that > > > > > > > > > bit alone, but then it would be quite confusing and the check > > > > > > > > > is not > > > > > > > > > necessary anyway. > > > > > > > > > > > > > > > > I see. Given how the PCI host bridge scan handler is > > > > > > > > integrated today, > > > > > > > > the change looks reasonable to me. > > > > > > > > > > > > > > Looking further, I noticed that there is one more issue to > > > > > > > address. The > > > > > > > patch below applies on top of your patchset. > > > > > > > > > > > > > > From: Toshi Kani > > > > > > > Subject: [PATCH] ACPI / hotplug: Fix conflicted PCI bridge notify > > > > > > > handlers > > > > > > > > > > > > > > The PCI host bridge scan handler installs its own notify handler, > > > > > > > handle_hotplug_event_root(), by itself. Nevertheless, the ACPI > > > > > > > hotplug framework also installs the common notify handler, > > > > > > > acpi_hotplug_notify_cb(), for PCI root bridges. This causes > > > > > > > acpi_hotplug_notify_cb() to call _OST method with unsupported > > > > > > > error as hotplug.enabled is not set. > > > > > > > > > > > > > > To address this issue, introduce hotplug.self_install flag, which > > > > > > > indicates that the scan handler installs its own notify handler by > > > > > > > itself. The ACPI hotplug framework does not install the common > > > > > > > notify handler when this flag is set. > > > > > > > > > > > > Good catch! > > > > > > > > > > > > Still, I don't think we need a new flag, because we know that that > > > > > > scan handler doesn't support hotplug, because its hotplug profile > > > > > > hasn't been registered (that actually applies to all scan handlers > > > > > > without hotplug support, not only the root host bridge). > > > > > > > > > > When a scan handler does not support hotplug at all, the common notify > > > > > handler should be installed so that it can call _OST with an > > > > > appropriate > > > > > response. > > > > > > > > That creates an arbitrary difference between devices that have scan > > > > handlers > > > > and devices that don't have them (PCI, USB, SATA etc). So if we want > > > > _OST > > > > to be called for all devices for which hotplug is not supported, that > > > > should be implemented in a different way and not necessarily in 3.13. > > > > I do not think we have an immediate issue since it only matters when the > > firmware supports ACPI hotplug with _OST. Such device types are CPU, > > memory, container, and PCI bridge, which uses scan handlers. USB, SATA, > > etc. do not use ACPI hotplug. That said, ideally, we should be able to > > call _OST for any device types. > > > > > > > > Moreover, > > > > > > if it does support hotplug, but the hotplug profile hasn't been > > > > > > registered due to an error, we still should not install the
Re: [PATCH 8/9] ARM: at91/dt: add new at91rm9200ek_mmc board
On 14:37 Wed 28 Aug , Boris BREZILLON wrote:
> Add a new at91rm9200ek_mmc board (based on at91rm9200ek board) which enables
> mmc0/slot0.
no for multiple dts
this need to handle at user space level
Best Regards,
J.
>
> Signed-off-by: Boris BREZILLON
> ---
> arch/arm/boot/dts/at91rm9200ek_mmc.dts | 23 +++
> 1 file changed, 23 insertions(+)
> create mode 100644 arch/arm/boot/dts/at91rm9200ek_mmc.dts
>
> diff --git a/arch/arm/boot/dts/at91rm9200ek_mmc.dts
> b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
> new file mode 100644
> index 000..c87a861
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
> @@ -0,0 +1,23 @@
> +/*
> + * at91rm9200ek.dts - Device Tree file for Atmel AT91RM9200 evaluation kit
> with
> + *an MMC slot
> + *
> + * Copyright (C) 2013 Boris BREZILLON
> + *
> + * Licensed under GPLv2 only
> + */
> +/dts-v1/;
> +#include "at91rm9200ek.dts"
> +
> +/ {
> + model = "Atmel AT91RM9200 evaluation kit with MMC slot";
> + compatible = "atmel,at91rm9200ek-mmc", "atmel,at91rm9200ek",
> "atmel,at91rm9200";
> +
> + ahb {
> + apb {
> + mmc0: mmc@fffb4000 {
> + status = "okay";
> + };
> + };
> + };
> +};
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] memory: ti-aemif: introduce AEMIF driver
Add new AEMIF driver for EMIF16 Texas Instruments controller. The EMIF16 module is intended to provide a glue-less interface to a variety of asynchronous memory devices like ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories can be accessed at any given time via four chip selects with 64M byte access per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM and Mobile SDR are not supported. This controller is used on SoCs like Davinci, Keysone2 For more informations see documentation: Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf Signed-off-by: Ivan Khoronzhuk --- drivers/memory/Kconfig| 11 ++ drivers/memory/Makefile |1 + drivers/memory/ti-aemif.c | 415 + 3 files changed, 427 insertions(+) create mode 100644 drivers/memory/ti-aemif.c diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 29a11db..cc0e3c8 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -7,6 +7,17 @@ menuconfig MEMORY if MEMORY +config TI_AEMIF + bool "Texas Instruments AEMIF driver" + depends on (ARCH_DAVINCI || ARCH_KEYSTONE) && OF + help + This driver is for the AEMIF module available in Texas Instruments + SoCs. AEMIF stands for Asynchronous External Memory Interface and + is intended to provide a glue-less interface to a variety of + asynchronuous memory devices like ASRAM, NOR and NAND memory. A total + of 256M bytes of any of these memories can be accessed at a given + time via four chip selects with 64M byte access per chip select. + config TI_EMIF tristate "Texas Instruments EMIF driver" depends on ARCH_OMAP2PLUS diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index 969d923..d4e150c 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -5,6 +5,7 @@ ifeq ($(CONFIG_DDR),y) obj-$(CONFIG_OF) += of_memory.o endif +obj-$(CONFIG_TI_AEMIF) += ti-aemif.o obj-$(CONFIG_TI_EMIF) += emif.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c new file mode 100644 index 000..a4b479a --- /dev/null +++ b/drivers/memory/ti-aemif.c @@ -0,0 +1,415 @@ +/* + * TI AEMIF driver + * + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated. http://www.ti.com/ + * Copyright (C) Heiko Schocher + * Copyright (C) Ivan Khoronzhuk + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define TA_SHIFT 2 +#define RHOLD_SHIFT4 +#define RSTROBE_SHIFT 7 +#define RSETUP_SHIFT 13 +#define WHOLD_SHIFT17 +#define WSTROBE_SHIFT 20 +#define WSETUP_SHIFT 26 +#define EW_SHIFT 30 +#define SS_SHIFT 31 + +#define TA(x) ((x) << TA_SHIFT) +#define RHOLD(x) ((x) << RHOLD_SHIFT) +#define RSTROBE(x) ((x) << RSTROBE_SHIFT) +#define RSETUP(x) ((x) << RSETUP_SHIFT) +#define WHOLD(x) ((x) << WHOLD_SHIFT) +#define WSTROBE(x) ((x) << WSTROBE_SHIFT) +#define WSETUP(x) ((x) << WSETUP_SHIFT) +#define EW(x) ((x) << EW_SHIFT) +#define SS(x) ((x) << SS_SHIFT) + +#define ASIZE_MAX 0x1 +#define TA_MAX 0x3 +#define RHOLD_MAX 0x7 +#define RSTROBE_MAX0x3f +#define RSETUP_MAX 0xf +#define WHOLD_MAX 0x7 +#define WSTROBE_MAX0x3f +#define WSETUP_MAX 0xf +#define EW_MAX 0x1 +#define SS_MAX 0x1 +#define NUM_CS 4 + +#define TA_VAL(x) (((x) & TA(TA_MAX)) >> TA_SHIFT) +#define RHOLD_VAL(x) (((x) & RHOLD(RHOLD_MAX)) >> RHOLD_SHIFT) +#define RSTROBE_VAL(x) (((x) & RSTROBE(RSTROBE_MAX)) >> RSTROBE_SHIFT) +#define RSETUP_VAL(x) (((x) & RSETUP(RSETUP_MAX)) >> RSETUP_SHIFT) +#define WHOLD_VAL(x) (((x) & WHOLD(WHOLD_MAX)) >> WHOLD_SHIFT) +#define WSTROBE_VAL(x) (((x) & WSTROBE(WSTROBE_MAX)) >> WSTROBE_SHIFT) +#define WSETUP_VAL(x) (((x) & WSETUP(WSETUP_MAX)) >> WSETUP_SHIFT) +#define EW_VAL(x) (((x) & EW(EW_MAX)) >> EW_SHIFT) +#define SS_VAL(x) (((x) & SS(SS_MAX)) >> SS_SHIFT) + +#define NRCSR_OFFSET 0x00 +#define AWCCR_OFFSET 0x04 +#define A1CR_OFFSET0x10 + +#define ACR_ASIZE_MASK 0x3 +#define ACR_EW_MASKBIT(30) +#define ACR_SS_MASKBIT(31) +#define ASIZE_16BIT1 + +#define CONFIG_MASK(TA(TA_MAX) | \ + RHOLD(RHOLD_MAX) | \ + RSTROBE(RSTROBE_MAX) | \ + RSETUP(RSETUP_MAX) | \ + WHOLD(WHOLD_MAX) | \ +
[PATCH 2/2] memory: ti-aemif: add bindings for AEMIF driver
Add bindings for AEMIF controller drivers/memory/ti-aemif.c Signed-off-by: Ivan Khoronzhuk --- .../bindings/memory-controllers/ti-aemif.txt | 198 1 file changed, 198 insertions(+) create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt new file mode 100644 index 000..be0c0cb --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt @@ -0,0 +1,198 @@ +* Device tree bindings for Texas instruments AEMIF controller + +Th Async External Memory Interface (EMIF16/AEMIF) controller is intended to +provide a glue-less interface to a variety of asynchronous memory devices like +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories +can be accessed at any given time via four chip selects with 64M byte access +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM +and Mobile SDR are not supported. + +Documentation: +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf +OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf + +Required properties: + +- compatible: "ti,davinci-aemif" + "ti,keystone-aemif" + "ti,omap-L138-aemif" + +- #address-cells: Must be 2. The first cell is the memory partition + number. The 0 partition is for chip selects. And the + second cell is the offset into the partition, for the 0 + partition it corresponds to chip select offset. + +- #size-cells: Must be set to 1. + +- reg: contains offset/length value for AEMIF control registers + space. + +- ranges: Must be set up to reflect the memory layout for 4 + chipselects and for AEMIF control range. + +- clocks: phandle reference to the controller clock. Required only + if clock tree data present in device tree. + See clock-bindings.txt + +- clock-names: clock name. It has to be "aemif". Required only if clock + tree data present in device tree, in another case don't + use it. + See clock-bindings.txt + +- clock-ranges:Empty property indicating that child nodes can inherit + named clocks. Required only if clock tree data present + in device tree. + See clock-bindings.txt + + +Child chip-select (cs) nodes contain the memory devices nodes connected to +such as NOR (e.g. cfi-flash) and NAND (ti,davinci-nand, see davinci-nand.txt). +There might be board specific devices like FPGAs. + +Required child cs node properties: + +- compatible: "ti,aemif-cs" + +- #address-cells: Must be 2. The first cell is the memory partition + number. The 0 partition is for chip selects. And the + second cell is the offset into the partition, for the 0 + partition it corresponds to chip select offset. + +- #size-cells: Must be 1. + +- ranges: Empty property indicating that child nodes can inherit + memory layout. + +- clock-ranges:Empty property indicating that child nodes can inherit + named clocks. Required only if clock tree data present + in device tree. + +Optional child cs node properties: + + +- ti,bus-width:width of the asynchronous device's data bus + 8 or 16 if not preset 8 + +- ti,cs-ss:enable/disable select strobe mode + In select strobe mode chip select behaves as + the strobe and is active only during the strobe + period. If present then enable. + +- ti,cs-ew:enable/disable extended wait mode + if set, the controller monitors the EMIFWAIT pin + mapped to that chip select to determine if the + device wants to extend the strobe period. If + present then enable. + +- ti,cs-ta:minimum turn around time, ns + Time between the end of one asynchronous memory + access and the start of another asynchronous + memory access. This delay is not incurred + between a read followed by read or a write + followed by a write to same chip select. + +- ti,cs-rsetup:read setup width, ns
[PATCH 0/2] Introduce AEMIF driver for Davinci/Keystone archs
These patches introduce Async External Memory Interface (EMIF16/AEMIF) controller driver for Davinci/Keystone archs. V1: https://lkml.org/lkml/2013/11/11/352 Ivan Khoronzhuk (2): memory: ti-aemif: introduce AEMIF driver memory: ti-aemif: add bindings for AEMIF driver .../bindings/memory-controllers/ti-aemif.txt | 198 ++ drivers/memory/Kconfig | 11 + drivers/memory/Makefile|1 + drivers/memory/ti-aemif.c | 415 4 files changed, 625 insertions(+) create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt create mode 100644 drivers/memory/ti-aemif.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] mtd: nand: davinci: extend description of bindings
On Wednesday 20 November 2013, Ivan Khoronzhuk wrote: > Extend bindings for davinci_nand driver to be more clear. > > Signed-off-by: Ivan Khoronzhuk > --- > .../devicetree/bindings/mtd/davinci-nand.txt | 77 > ++-- > 1 file changed, 54 insertions(+), 23 deletions(-) Hi Ivan, The changes look good to me, but please clarify in the changeset description above whether this is a backwards-compatible change, a clarification without semantic changes, or an incompatible change (which should be avoided). Arnd -- 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: [Kernel Panic] 3.10.10-rt7
On 13-11-20 07:34 AM, Jan Kiszka wrote: > On 2013-11-20 13:26, Frederich, Jens wrote: >> Hello, >> >> I got a Kernel panic by some long time stress tests. Look here: >> http://dy.cx/pqP7M. > > Ah, that should be http://thread.gmane.org/gmane.linux.kernel/1564783 > > Paul, was there any follow-up patch on this topic? Yeah, from the rt-summit [ http://lwn.net/Articles/572740/ ] it is on me to get those simple wait queue patches mainlined (and then the local_bh stuff). Once I've got that done, I'll look at spending some time on 3.12-rt kvm patches -- in the meantime, you are right, the screenshot shows that his 3.10-rt needs the straightforward conversion of vpcu->wq to simple wait. Paul. -- > > Jan > >> >> Furthermore I got sporadic some BUG messages: >> >> [ 1128.358971] BUG: scheduling while atomic: swapper/0/0/0x00010002 >> [ 1128.358982] Preemption disabled at:[] >> cpu_startup_entry+0x17a/0x300 >> >> Hardware >> >> >> My system is a i7 with 4 GB RAM congatec evalboard. >> >> Setup >> - >> >> On the system runs Linux RT (text mode) 3.10.10-rt7 with 1 GB RAM and a >> Windows 7 KVM/QEMU (Qemu 1.6.1) guest with 3 GB RAM. Each system has it own >> ethernet card. The Win 7 guest uses it per pci pass-through. The Win 7 is >> pinned to core 2,3. >> >> Scenario >> >> >> We sending UDP packages every 1 msec on the Linux side. The UDP sender >> process >> has real time prio 80 and the ethernet driver 90. At the same time we are >> stressing Win 7. Memory stress - allocate as much as possible and do >> memset(), >> then CPU stress - high CPU load, then Kernel DPC stress - high load thread at >> DPC level and ethernet stress - send UDP packages every milliseconds. I got >> the >> panic after 45 minutes. It seems that is correlates with the ethernet stress. >> >> Can anybody help me? >> >> thanks >> Jens > -- 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 v2 04/29] PCI/MSI/pSeries: Make quota traversing and requesting race-safe
Hello, Sorry about the long delay. Was traveling quite a bit. On Fri, Oct 18, 2013 at 07:12:04PM +0200, Alexander Gordeev wrote: > Signed-off-by: Alexander Gordeev Please explain what the race condition in detail and how it gets fixed by the patch. This isn't a trivial change and non-trivial changes especially stuff like race condition fixes definitely require detailed explanation. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-kernel@vger.kernel.org
Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?
On Wed, Nov 20, 2013 at 08:52:36PM +0530, Chinmay V S wrote: > > If you have confirmed the performance numbers, then it indicates that > the Intel 530 controller is more advanced and makes better use of the > internal disk-cache to achieve better performance (as compared to the > Intel 520). Thus forcing CMD_FLUSH on each IOP (negating the benefits > of the disk write-cache and not allowing any advanced disk controller > optimisations) has a more pronouced effect of degrading the > performance on Intel 530 SSDs. (Someone with some actual info on Intel > SSDs kindly confirm this.) You might also want to do some power fail testing to make sure that the SSD is actually flusing all of its internal Flash Translation Layer (FTL) metadata to stable storage on every CMD_FLUSH command. There are lots of flash media that don't do this, with the result that I get lots of users whining at me when their file system stored on an SD card has massive corruption after a power fail event. Historically, Intel has been really good about avoiding this, but since they've moved to using 3rd party flash controllers, I now advise everyone who plans to use any flash storage, regardless of the manufacturer, to do their own explicit power fail testing (hitting the reset button is not good enough, you need to kick the power plug out of the wall, or better yet, use a network controlled power switch you so you can repeat the power fail test dozens or hundreds of times for your qualification run) before being using flash storage in a mission critical situation where you care about data integrity after a power fail event. IOW, make sure that the SSD isn't faster because it's playing fast and loose with the FTL metadata Cheers, - Ted -- 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-kernel@vger.kernel.org
Re: [PATCH v2 4/5] regulator: max14577: Add regulator driver for Maxim 14577
On Wed, Nov 20, 2013 at 03:12:11PM +0100, Krzysztof Kozlowski wrote:
> + size = sizeof(struct regulator_dev *) * pdata->num_regulators;
> + info->regulators = devm_kzalloc(>dev, size, GFP_KERNEL);
> + if (!info->regulators) {
> + dev_err(>dev, "Cannot allocate memory for regulators\n");
> + return -ENOMEM;
> + }
The set of regulators in the silicon doesn't vary - you should
unconditionally register all the regulators.
signature.asc
Description: Digital signature
Re: [PATCH v6 4/5] MCS Lock: Barrier corrections
On Tue, Nov 19, 2013 at 05:37:43PM -0800, Tim Chen wrote:
> This patch corrects the way memory barriers are used in the MCS lock
> with smp_load_acquire and smp_store_release fucnction.
> It removes ones that are not needed.
>
> It uses architecture specific load-acquire and store-release
> primitives for synchronization, if available. Generic implementations
> are provided in case they are not defined even though they may not
> be optimal. These generic implementation could be removed later on
> once changes are made in all the relevant header files.
>
> Suggested-by: Michel Lespinasse
> Signed-off-by: Waiman Long
> Signed-off-by: Jason Low
> Signed-off-by: Tim Chen
> ---
> kernel/locking/mcs_spinlock.c | 19 ++-
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/locking/mcs_spinlock.c b/kernel/locking/mcs_spinlock.c
> index 44fb092..6f2ce8e 100644
> --- a/kernel/locking/mcs_spinlock.c
> +++ b/kernel/locking/mcs_spinlock.c
> @@ -37,15 +37,19 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct
> mcs_spinlock *node)
> node->locked = 0;
> node->next = NULL;
>
> + /* xchg() provides a memory barrier */
> prev = xchg(lock, node);
> if (likely(prev == NULL)) {
> /* Lock acquired */
> return;
> }
> ACCESS_ONCE(prev->next) = node;
> - smp_wmb();
> - /* Wait until the lock holder passes the lock down */
> - while (!ACCESS_ONCE(node->locked))
> + /*
> + * Wait until the lock holder passes the lock down.
> + * Using smp_load_acquire() provides a memory barrier that
> + * ensures subsequent operations happen after the lock is acquired.
> + */
> + while (!(smp_load_acquire(>locked)))
> arch_mutex_cpu_relax();
> }
> EXPORT_SYMBOL_GPL(mcs_spin_lock);
> @@ -68,7 +72,12 @@ void mcs_spin_unlock(struct mcs_spinlock **lock, struct
> mcs_spinlock *node)
> while (!(next = ACCESS_ONCE(node->next)))
> arch_mutex_cpu_relax();
> }
> - ACCESS_ONCE(next->locked) = 1;
> - smp_wmb();
> + /*
> + * Pass lock to next waiter.
> + * smp_store_release() provides a memory barrier to ensure
> + * all operations in the critical section has been completed
> + * before unlocking.
> + */
> + smp_store_release(>locked, 1);
However, there is one problem with this that I missed yesterday.
Documentation/memory-barriers.txt requires that an unlock-lock pair
provide a full barrier, but this is not guaranteed if we use
smp_store_release() for unlock and smp_load_acquire() for lock.
At least one of these needs a full memory barrier.
Thanx, Paul
> }
> EXPORT_SYMBOL_GPL(mcs_spin_unlock);
> --
> 1.7.11.7
>
>
>
--
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 1/5] mfd: max14577: Add max14577 MFD driver core
On Wed, Nov 20, 2013 at 03:12:08PM +0100, Krzysztof Kozlowski wrote:
> +static irqreturn_t max14577_irq_thread(int irq, void *data)
> +{
> + struct max14577 *max14577 = data;
> + u8 irq_reg[MAX14577_IRQ_REGS_NUM] = {0};
> + u8 tmp_irq_reg[MAX14577_IRQ_REGS_NUM] = {};
> + int i, cur_irq;
> +
> + max14577_bulk_read(max14577->regmap, MAX14577_REG_INT1,
> + _irq_reg[MAX14577_IRQ_INT1],
> + MAX14577_IRQ_REGS_NUM);
All this interrupt handling looks like a straight copy of the regmap
code?
> +int max14577_irq_resume(struct max14577 *max14577)
> +{
> + int ret = 0;
> +
> + if (max14577->irq && max14577->irq_domain)
> + ret = max14577_irq_thread(0, max14577);
Are you sure that this is not going to race nastily if the interrupt
goes off during resume?
> +
> + return ret >= 0 ? 0 : ret;
This check isn't a triumph of legibility.
> + if (IS_ERR_OR_NULL(pdata)) {
> + dev_err(>dev, "No platform data found: %ld\n",
> + PTR_ERR(pdata));
> + return -EINVAL;
> + }
Why IS_ERR_OR_NULL().
> +#else
> +#define max14577_suspend NULL
> +#define max14577_resume NULL
> +#endif /* CONFIG_PM */
You don't need these since you use SIMPLE_DEV_PM_OPS().
> +#else
> +#define max14577_dt_matchNULL
> +#endif
Similarly here.
signature.asc
Description: Digital signature
Re: [PATCH 3.4 00/12] 3.4.70-stable review
On 11/18/2013 11:41 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.70 release. There are 12 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 Wed Nov 20 18:41:11 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.70-rc1.gz and the diffstat can be found below. thanks, greg k-h 3.4.70: patches applied cleanly Compile test - passed Boot tests - passed dmesg regression tests - passed [dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn.] Cross-compile testing - limited tests passed (alpha, arm, arm64, blackfin, c6x, powerpc, sh, sparc, tile) Test systems: Samsung Series 9 900X4C Intel Corei5 (3.4 and later) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile testing) -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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.10 00/24] 3.10.20-stable review
On 11/18/2013 11:42 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.20 release. There are 24 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 Wed Nov 20 18:42:04 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.20-rc1.gz and the diffstat can be found below. thanks, greg k-h 3.10.20: patches applied cleanly Compile test - passed Boot tests - passed dmesg regression tests - passed [dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn.] Cross-compile testing - limited tests passed (alpha, arm, arm64, blackfin, c6x, powerpc, sh, sparc, tile) Test systems: Samsung Series 9 900X4C Intel Corei5 (3.4 and later) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile testing) -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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.11 00/25] 3.11.9-stable review
On 11/18/2013 11:40 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.11.9 release. There are 25 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 Wed Nov 20 18:40:06 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.9-rc1.gz and the diffstat can be found below. thanks, greg k-h 3.11.9: patches applied cleanly Compile test - passed Boot tests - passed dmesg regression tests - passed [dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn.] Cross-compile testing - limited tests passed (alpha, arm, arm64, blackfin, c6x, powerpc, sh, sparc, tile) Test systems: Samsung Series 9 900X4C Intel Corei5 (3.4 and later) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile testing) -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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.12 00/19] 3.12.1-stable review
On 11/18/2013 11:37 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.12.1 release. There are 19 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 Wed Nov 20 18:36:14 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.1-rc1.gz and the diffstat can be found below. thanks, greg k-h 3.12.1: patches applied cleanly Compile test - passed Boot tests - passed dmesg regression tests - passed [dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn.] Cross-compile testing - limited tests passed (alpha, arm, arm64, blackfin, c6x, powerpc, sh, sparc, tile) Test systems: Samsung Series 9 900X4C Intel Corei5 (3.4 and later) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile testing) -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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/7] Davinci nand driver fixes and updates
This series contains fixes and updates of Davinci nand driver, in order to prepare it to be reused for Keystone platform. V1: https://lkml.org/lkml/2013/11/11/352 Ivan Khoronzhuk (7): mtd: nand: davinci: fix driver registration mtd: nand: davinci: return ENOMEM if memory allocation is failed mtd: nand: davinci: check required ti,davinci-chipselect property mtd: nand: davinci: simplify error handling mtd: nand: davinci: move bindings under mtd mtd: nand: davinci: extend description of bindings mtd: nand: davinci: adjust DT properties to MTD generic .../devicetree/bindings/arm/davinci/nand.txt | 46 -- .../devicetree/bindings/mtd/davinci-nand.txt | 92 drivers/mtd/nand/davinci_nand.c| 68 +++ 3 files changed, 126 insertions(+), 80 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt create mode 100644 Documentation/devicetree/bindings/mtd/davinci-nand.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] mtd: nand: davinci: simplify error handling
There is not needed to use a lot of names for err handling.
It complicates code support and reading.
Signed-off-by: Ivan Khoronzhuk
Acked-by: Santosh Shilimkar
---
drivers/mtd/nand/davinci_nand.c | 46 +++
1 file changed, 17 insertions(+), 29 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 9a96ac7..c0be223 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -615,8 +615,7 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
if (!info) {
dev_err(>dev, "unable to allocate memory\n");
- ret = -ENOMEM;
- goto err_nomem;
+ return -ENOMEM;
}
platform_set_drvdata(pdev, info);
@@ -625,20 +624,16 @@ static int __init nand_davinci_probe(struct
platform_device *pdev)
res2 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
if (!res1 || !res2) {
dev_err(>dev, "resource missing\n");
- ret = -EINVAL;
- goto err_nomem;
+ return -EINVAL;
}
vaddr = devm_ioremap_resource(>dev, res1);
- if (IS_ERR(vaddr)) {
- ret = PTR_ERR(vaddr);
- goto err_ioremap;
- }
+ if (IS_ERR(vaddr))
+ return PTR_ERR(vaddr);
+
base = devm_ioremap_resource(>dev, res2);
- if (IS_ERR(base)) {
- ret = PTR_ERR(base);
- goto err_ioremap;
- }
+ if (IS_ERR(base))
+ return PTR_ERR(base);
info->dev = >dev;
info->base = base;
@@ -705,7 +700,7 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
spin_unlock_irq(_nand_lock);
if (ret == -EBUSY)
- goto err_ecc;
+ return ret;
info->chip.ecc.calculate = nand_davinci_calculate_4bit;
info->chip.ecc.correct = nand_davinci_correct_4bit;
@@ -721,8 +716,7 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
info->chip.ecc.strength = pdata->ecc_bits;
break;
default:
- ret = -EINVAL;
- goto err_ecc;
+ return -EINVAL;
}
info->chip.ecc.mode = ecc_mode;
@@ -730,7 +724,7 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
if (IS_ERR(info->clk)) {
ret = PTR_ERR(info->clk);
dev_dbg(>dev, "unable to get AEMIF clock, err %d\n", ret);
- goto err_clk;
+ return ret;
}
ret = clk_prepare_enable(info->clk);
@@ -759,7 +753,7 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
info->core_chipsel);
if (ret < 0) {
dev_dbg(>dev, "NAND timing values setup fail\n");
- goto err_timing;
+ goto err;
}
spin_lock_irq(_nand_lock);
@@ -775,7 +769,7 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
ret = nand_scan_ident(>mtd, pdata->mask_chipsel ? 2 : 1, NULL);
if (ret < 0) {
dev_dbg(>dev, "no NAND chip(s) found\n");
- goto err_scan;
+ goto err;
}
/* Update ECC layout if needed ... for 1-bit HW ECC, the default
@@ -789,7 +783,7 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
if (!chunks || info->mtd.oobsize < 16) {
dev_dbg(>dev, "too small\n");
ret = -EINVAL;
- goto err_scan;
+ goto err;
}
/* For small page chips, preserve the manufacturer's
@@ -820,7 +814,7 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
dev_warn(>dev, "no 4-bit ECC support yet "
"for 4KiB-page NAND\n");
ret = -EIO;
- goto err_scan;
+ goto err;
syndrome_done:
info->chip.ecc.layout = >ecclayout;
@@ -828,7 +822,7 @@ syndrome_done:
ret = nand_scan_tail(>mtd);
if (ret < 0)
- goto err_scan;
+ goto err;
if (pdata->parts)
ret = mtd_device_parse_register(>mtd, NULL, NULL,
@@ -841,7 +835,7 @@ syndrome_done:
NULL, 0);
}
if (ret < 0)
- goto err_scan;
+ goto err;
val = davinci_nand_readl(info, NRCSR_OFFSET);
dev_info(>dev, "controller rev. %d.%d\n",
@@ -849,8 +843,7 @@ syndrome_done:
return 0;
-err_scan:
-err_timing:
+err:
[PATCH 6/7] mtd: nand: davinci: extend description of bindings
Extend bindings for davinci_nand driver to be more clear.
Signed-off-by: Ivan Khoronzhuk
---
.../devicetree/bindings/mtd/davinci-nand.txt | 77 ++--
1 file changed, 54 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
index 3545ea7..d2a3fc0 100644
--- a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
@@ -1,36 +1,67 @@
-* Texas Instruments Davinci NAND
+Device tree bindings for Texas instruments Davinci NAND controller
-This file provides information, what the device node for the
-davinci nand interface contain.
+This file provides information, what the device node for the davinci NAND
+interface contains.
+
+Documentation:
+Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
Required properties:
-- compatible: "ti,davinci-nand";
-- reg : contain 2 offset/length values:
-- offset and length for the access window
-- offset and length for accessing the aemif control registers
-- ti,davinci-chipselect: Indicates on the davinci_nand driver which
- chipselect is used for accessing the nand.
+
+- compatible: "ti,davinci-nand"
+
+- reg: Contains 2 offset/length values:
+ - offset and length for the access window.
+ - offset and length for accessing the AEMIF
+ control registers.
+
+- ti,davinci-chipselect: number of chipselect. Indicates on the
+ davinci_nand driver which chipselect is used
+ for accessing the nand.
+ Can be in the range [0-3].
Recommended properties :
-- ti,davinci-mask-ale: mask for ale
-- ti,davinci-mask-cle: mask for cle
-- ti,davinci-mask-chipsel: mask for chipselect
-- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
- - "none"
- - "soft"
- - "hw"
-- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
-- ti,davinci-nand-buswidth: buswidth 8 or 16
-- ti,davinci-nand-use-bbt: use flash based bad block table support.
-
-nand device bindings may contain additional sub-nodes describing
-partitions of the address space. See partition.txt for more detail.
+
+- ti,davinci-mask-ale: mask for ALE. Needed for executing address
+ phase. These offset will be added to the base
+ address for the chip select space the NAND Flash
+ device is connected to.
+ If not set equal to 0x08.
+
+- ti,davinci-mask-cle: mask for CLE. Needed for executing command
+ phase. These offset will be added to the base
+ address for the chip select space the NAND Flash
+ device is connected to.
+ If not set equal to 0x10.
+
+- ti,davinci-mask-chipsel: mask for chipselect address. Needed to mask
+ addresses for given chipselect.
+
+- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode
+ valid values for davinci driver:
+ - "none"
+ - "soft"
+ - "hw"
+
+- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
+
+- ti,davinci-nand-buswidth:buswidth 8 or 16.
+
+- ti,davinci-nand-use-bbt: use flash based bad block table support. OOB
+ identifier is saved in OOB area.
+
+Nand device bindings may contain additional sub-nodes describing partitions of
+the address space. See partition.txt for more detail. The NAND Flash timing
+values must be programmed in the chip select’s node of AEMIF
+memory-controller (see Documentation/devicetree/bindings/memory-controllers/
+davinci-aemif.txt).
Example(da850 EVM ):
+
nand_cs3@6200 {
compatible = "ti,davinci-nand";
reg = <0x6200 0x807ff
- 0x6800 0x8000>;
+ 0x6800 0x8000>;
ti,davinci-chipselect = <1>;
ti,davinci-mask-ale = <0>;
ti,davinci-mask-cle = <0>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] mtd: nand: davinci: adjust DT properties to MTD generic
The properties davinci-ecc-mode, davinci-nand-use-bbt, davinci-nand-buswidth
are MTD generic. Correct names for them are: nand-ecc-mode, nand-on-flash-bbt,
nand-bus-width accordingly. So rename them in dts and documentation.
Signed-off-by: Ivan Khoronzhuk
---
.../devicetree/bindings/mtd/davinci-nand.txt | 25
drivers/mtd/nand/davinci_nand.c| 11 ++---
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
index d2a3fc0..befaa5b 100644
--- a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
@@ -37,7 +37,7 @@ Recommended properties :
- ti,davinci-mask-chipsel: mask for chipselect address. Needed to mask
addresses for given chipselect.
-- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode
+- nand-ecc-mode: operation mode of the NAND ecc mode. ECC mode
valid values for davinci driver:
- "none"
- "soft"
@@ -45,10 +45,25 @@ Recommended properties :
- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
-- ti,davinci-nand-buswidth:buswidth 8 or 16.
+- nand-bus-width: buswidth 8 or 16. If not present 8.
+
+- nand-on-flash-bbt: use flash based bad block table support. OOB
+ identifier is saved in OOB area. If not present
+ false.
+
+Deprecated properties:
+
+- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode
+ valid values for davinci driver:
+ - "none"
+ - "soft"
+ - "hw"
+
+- ti,davinci-nand-buswidth:buswidth 8 or 16. If not present 8.
- ti,davinci-nand-use-bbt: use flash based bad block table support. OOB
- identifier is saved in OOB area.
+ identifier is saved in OOB area. If not present
+ false.
Nand device bindings may contain additional sub-nodes describing partitions of
the address space. See partition.txt for more detail. The NAND Flash timing
@@ -66,9 +81,9 @@ nand_cs3@6200 {
ti,davinci-mask-ale = <0>;
ti,davinci-mask-cle = <0>;
ti,davinci-mask-chipsel = <0>;
- ti,davinci-ecc-mode = "hw";
+ nand-ecc-mode = "hw";
ti,davinci-ecc-bits = <4>;
- ti,davinci-nand-use-bbt;
+ nand-on-flash-bbt;
partition@18 {
label = "ubifs";
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index c0be223..f7b21b8 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -534,7 +534,6 @@ static struct davinci_nand_pdata
struct davinci_nand_pdata *pdata;
const char *mode;
u32 prop;
- int len;
pdata = devm_kzalloc(>dev,
sizeof(struct davinci_nand_pdata),
@@ -558,6 +557,8 @@ static struct davinci_nand_pdata
"ti,davinci-mask-chipsel", ))
pdata->mask_chipsel = prop;
if (!of_property_read_string(pdev->dev.of_node,
+ "nand-ecc-mode", ) ||
+ !of_property_read_string(pdev->dev.of_node,
"ti,davinci-ecc-mode", )) {
if (!strncmp("none", mode, 4))
pdata->ecc_mode = NAND_ECC_NONE;
@@ -570,11 +571,15 @@ static struct davinci_nand_pdata
"ti,davinci-ecc-bits", ))
pdata->ecc_bits = prop;
if (!of_property_read_u32(pdev->dev.of_node,
+ "nand-bus-width", ) ||
+ !of_property_read_u32(pdev->dev.of_node,
"ti,davinci-nand-buswidth", ))
if (prop == 16)
pdata->options |= NAND_BUSWIDTH_16;
- if (of_find_property(pdev->dev.of_node,
- "ti,davinci-nand-use-bbt", ))
+ if (of_property_read_bool(pdev->dev.of_node,
+ "nand-on-flash-bbt") ||
+ of_property_read_bool(pdev->dev.of_node,
+ "ti,davinci-nand-use-bbt"))
pdata->bbt_options = NAND_BBT_USE_FLASH;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] mtd: nand: davinci: return ENOMEM if memory allocation is failed
In case when memory allocation is failed the driver should return ENOMEM instead of ENODEV. Signed-off-by: Ivan Khoronzhuk --- drivers/mtd/nand/davinci_nand.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index d87213f..ddcd7c8 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -541,7 +541,7 @@ static struct davinci_nand_pdata GFP_KERNEL); pdev->dev.platform_data = pdata; if (!pdata) - return NULL; + return ERR_PTR(-ENOMEM); if (!of_property_read_u32(pdev->dev.of_node, "ti,davinci-chipselect", )) pdev->id = prop; @@ -598,6 +598,9 @@ static int __init nand_davinci_probe(struct platform_device *pdev) nand_ecc_modes_tecc_mode; pdata = nand_davinci_get_pdata(pdev); + if (IS_ERR(pdata)) + return PTR_ERR(pdata); + /* insist on board-specific configuration */ if (!pdata) return -ENODEV; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] mtd: nand: davinci: fix driver registration
When kernel is booted using DT, there is no guarantee that Davinci
NAND device has been created already at the time when driver init
function is executed. Therefore, platform_driver_probe() can't be used
because this may result the Davinci NAND driver will never be probed.
The driver probing has to be made with core mechanism.
Signed-off-by: Ivan Khoronzhuk
Acked-by: Santosh Shilimkar
---
drivers/mtd/nand/davinci_nand.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index b77a01e..d87213f 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -877,6 +877,7 @@ static int __exit nand_davinci_remove(struct
platform_device *pdev)
}
static struct platform_driver nand_davinci_driver = {
+ .probe = nand_davinci_probe,
.remove = __exit_p(nand_davinci_remove),
.driver = {
.name = "davinci_nand",
@@ -886,7 +887,7 @@ static struct platform_driver nand_davinci_driver = {
};
MODULE_ALIAS("platform:davinci_nand");
-module_platform_driver_probe(nand_davinci_driver, nand_davinci_probe);
+module_platform_driver(nand_davinci_driver);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Texas Instruments");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] mtd: nand: davinci: move bindings under mtd
Move bindings under mtd. Do this in order to make davinci-nand
driver usable by keystone architecture.
Signed-off-by: Ivan Khoronzhuk
Acked-by: Santosh Shilimkar
---
.../devicetree/bindings/arm/davinci/nand.txt | 46
.../devicetree/bindings/mtd/davinci-nand.txt | 46
2 files changed, 46 insertions(+), 46 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
create mode 100644 Documentation/devicetree/bindings/mtd/davinci-nand.txt
diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt
b/Documentation/devicetree/bindings/arm/davinci/nand.txt
deleted file mode 100644
index 3545ea7..000
--- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-* Texas Instruments Davinci NAND
-
-This file provides information, what the device node for the
-davinci nand interface contain.
-
-Required properties:
-- compatible: "ti,davinci-nand";
-- reg : contain 2 offset/length values:
-- offset and length for the access window
-- offset and length for accessing the aemif control registers
-- ti,davinci-chipselect: Indicates on the davinci_nand driver which
- chipselect is used for accessing the nand.
-
-Recommended properties :
-- ti,davinci-mask-ale: mask for ale
-- ti,davinci-mask-cle: mask for cle
-- ti,davinci-mask-chipsel: mask for chipselect
-- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
- - "none"
- - "soft"
- - "hw"
-- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
-- ti,davinci-nand-buswidth: buswidth 8 or 16
-- ti,davinci-nand-use-bbt: use flash based bad block table support.
-
-nand device bindings may contain additional sub-nodes describing
-partitions of the address space. See partition.txt for more detail.
-
-Example(da850 EVM ):
-nand_cs3@6200 {
- compatible = "ti,davinci-nand";
- reg = <0x6200 0x807ff
- 0x6800 0x8000>;
- ti,davinci-chipselect = <1>;
- ti,davinci-mask-ale = <0>;
- ti,davinci-mask-cle = <0>;
- ti,davinci-mask-chipsel = <0>;
- ti,davinci-ecc-mode = "hw";
- ti,davinci-ecc-bits = <4>;
- ti,davinci-nand-use-bbt;
-
- partition@18 {
- label = "ubifs";
- reg = <0x18 0x7e8>;
- };
-};
diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
new file mode 100644
index 000..3545ea7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
@@ -0,0 +1,46 @@
+* Texas Instruments Davinci NAND
+
+This file provides information, what the device node for the
+davinci nand interface contain.
+
+Required properties:
+- compatible: "ti,davinci-nand";
+- reg : contain 2 offset/length values:
+- offset and length for the access window
+- offset and length for accessing the aemif control registers
+- ti,davinci-chipselect: Indicates on the davinci_nand driver which
+ chipselect is used for accessing the nand.
+
+Recommended properties :
+- ti,davinci-mask-ale: mask for ale
+- ti,davinci-mask-cle: mask for cle
+- ti,davinci-mask-chipsel: mask for chipselect
+- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
+ - "none"
+ - "soft"
+ - "hw"
+- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
+- ti,davinci-nand-buswidth: buswidth 8 or 16
+- ti,davinci-nand-use-bbt: use flash based bad block table support.
+
+nand device bindings may contain additional sub-nodes describing
+partitions of the address space. See partition.txt for more detail.
+
+Example(da850 EVM ):
+nand_cs3@6200 {
+ compatible = "ti,davinci-nand";
+ reg = <0x6200 0x807ff
+ 0x6800 0x8000>;
+ ti,davinci-chipselect = <1>;
+ ti,davinci-mask-ale = <0>;
+ ti,davinci-mask-cle = <0>;
+ ti,davinci-mask-chipsel = <0>;
+ ti,davinci-ecc-mode = "hw";
+ ti,davinci-ecc-bits = <4>;
+ ti,davinci-nand-use-bbt;
+
+ partition@18 {
+ label = "ubifs";
+ reg = <0x18 0x7e8>;
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] mtd: nand: davinci: check required ti,davinci-chipselect property
The property "ti,davinci-chipselect" is required. So we have to check if it is set. Signed-off-by: Ivan Khoronzhuk --- drivers/mtd/nand/davinci_nand.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index ddcd7c8..9a96ac7 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -545,6 +545,9 @@ static struct davinci_nand_pdata if (!of_property_read_u32(pdev->dev.of_node, "ti,davinci-chipselect", )) pdev->id = prop; + else + return ERR_PTR(-EINVAL); + if (!of_property_read_u32(pdev->dev.of_node, "ti,davinci-mask-ale", )) pdata->mask_ale = prop; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?
Hi Stefan, > thanks for your great and detailed reply. I'm just wondering why an > intel 520 ssd degrades the speed just by 2% in case of O_SYNC. intel 530 > the newer model and replacement for the 520 degrades speed by 75% like > the crucial m4. > > The Intel DC S3500 instead delivers also nearly 98% of it's performance > even under O_SYNC. If you have confirmed the performance numbers, then it indicates that the Intel 530 controller is more advanced and makes better use of the internal disk-cache to achieve better performance (as compared to the Intel 520). Thus forcing CMD_FLUSH on each IOP (negating the benefits of the disk write-cache and not allowing any advanced disk controller optimisations) has a more pronouced effect of degrading the performance on Intel 530 SSDs. (Someone with some actual info on Intel SSDs kindly confirm this.) >> To simply disable this behaviour and make the SYNC/DSYNC behaviour and >> performance on raw block-device I/O resemble the standard filesystem >> I/O you may want to apply the following patch to your kernel - >> https://gist.github.com/TheCodeArtist/93dddcd6a21dc81414ba >> >> The above patch simply disables the CMD_FLUSH command support even on >> disks that claim to support it. > > Is this the right one? By assing ahci_dummy_read_id we disable the > CMD_FLUSH? > > What is the risk of that one? Yes, https://gist.github.com/TheCodeArtist/93dddcd6a21dc81414ba is the right one. The dummy read_id() provides a hook into the initial disk-properties discovery process when the disk is plugged-in. By explicitly negating the bits that indicate cache and flush-cache(CMD_FLUSH) support, we can ensure that the block driver does NOT issue CMD_FLUSH commands to the disk. Note that this does NOT disable the write-cache on the disk itself i.e. performance improves due to the on-disk write-cache in the absence of any CMD_FLUSH commands from the host-PC. Theoretically, it increases the chances of data loss i.e. if power is removed while the write is in progress from the app. Personally though i have found that the impact of this is minimal because SYNC on a raw block device with CMD_FLUSH does NOT guarantee atomicity in case of a power-loss. Hence, in the event of a power loss, applications cannot rely on SYNC(with CMD_FLUSH) for data integrity. Rather they have to maintain other data-structures with redundant disk metadata (which is precisely what modern file-systems do). Thus, removing CMD_FLUSH doesn't really result in a downside as such. The main thing to consider when applying the above simple patch is that it is system-wide. The above patch prevents the host-PC from issuing CMD_FLUSH for ALL drives enumerated via SATA/SCSI on the system. If this patch works for you, then to restrict the change in behaviour to a specific disk, you will need to: 1. Identify the disk by its model number within the dummy read_id(). 2. Zero the bits ONLY for your particular disk. 3. Return without modifying anything for all other disks. Try out the above patch and let me know if you have any further issues. regards ChinmayVS -- 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: user defined OOM policies
On Wed 20-11-13 00:02:20, David Rientjes wrote: > On Tue, 19 Nov 2013, Michal Hocko wrote: > > > > We have basically ended up with 3 options AFAIR: > > > 1) allow memcg approach (memcg.oom_control) on the root level > > >for both OOM notification and blocking OOM killer and handle > > >the situation from the userspace same as we can for other > > > memcgs. > > > > This looks like a straightforward approach as the similar thing is done > > on the local (memcg) level. There are several problems though. > > Running userspace from within OOM context is terribly hard to do > > right. > > Not sure it's hard if you have per-memcg memory reserves which I've > brought up in the past with true and complete kmem accounting. Even if > you don't allocate slab, it guarantees that there will be at least a > little excess memory available so that the userspace oom handler isn't oom > itself. > This involves treating processes waiting on memory.oom_control to be > treated as a special class How do you identify such a process? > so that they are allowed to allocate an > additional pre-configured amount of memory. For non-root memcgs, this > would simply be a dummy usage that would be charged to the memcg when the > oom notification is registered and actually accessible only by the oom > handler itself while memcg->under_oom. For root memcgs, this would simply > be a PF_MEMALLOC type behavior that dips into per-zone memory reserves. > > > This is true even in the memcg case and we strongly discurage > > users from doing that. The global case has nothing like outside of OOM > > context though. So any hang would blocking the whole machine. > > Why would there be a hang if the userspace oom handlers aren't actually > oom themselves as described above? Because all the reserves might be depleted. > I'd suggest against the other two suggestions because hierarchical > per-memcg userspace oom handlers are very powerful and can be useful > without actually killing anything at all, and parent oom handlers can > signal child oom handlers to free memory in oom conditions (in other > words, defer a parent oom condition to a child's oom handler upon > notification). OK, but what about those who are not using memcg and need a similar functionality? Are there any, btw? > I was planning on writing a liboom library that would lay > the foundation for how this was supposed to work and some generic > functions that make use of the per-memcg memory reserves. > > So my plan for the complete solution was: > > - allow userspace notification from the root memcg on system oom >conditions, > > - implement a memory.oom_delay_millisecs timeout so that the kernel >eventually intervenes if userspace fails to respond, including for >system oom conditions, for whatever reason which would be set to 0 >if no userspace oom handler is registered for the notification, and One thing I really dislike about timeout is that there is no easy way to find out which value is safe. It might be easier for well controlled environments where you know what the load is and how it behaves. How an ordinary user knows which number to put there without risking a race where the userspace just doesn't respond in time? > - implement per-memcg reserves as described above so that userspace oom >handlers have access to memory even in oom conditions as an upfront >charge and have the ability to free memory as necessary. This has a similar issue as above. How to estimate the size of the reserve? How to make such a reserve stable over different kernel versions where the same query might consume more memory. As I've said in my previous email. The reserves can help but it is still easy to do wrong and looks rather fragile for general purposes. > We already have the ability to do the actual kill from userspace, both the > system oom killer and the memcg oom killer grants access to memory > reserves for any process needing to allocate memory if it has a pending > SIGKILL which we can send from userspace. Yes, the killing part is not a problem the selection is the hard one. -- Michal Hocko SUSE Labs -- 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] tracing/probes: Fix basic print type functions
On 11/18, Namhyung Kim wrote:
>
> -DEFINE_BASIC_PRINT_TYPE_FUNC(u8, "%x", unsigned int)
> -DEFINE_BASIC_PRINT_TYPE_FUNC(u16, "%x", unsigned int)
> -DEFINE_BASIC_PRINT_TYPE_FUNC(u32, "%lx", unsigned long)
> +DEFINE_BASIC_PRINT_TYPE_FUNC(u8 , "%x", unsigned char)
> +DEFINE_BASIC_PRINT_TYPE_FUNC(u16, "%x", unsigned short)
> +DEFINE_BASIC_PRINT_TYPE_FUNC(u32, "%x", unsigned int)
> +DEFINE_BASIC_PRINT_TYPE_FUNC(s8, "%d", signed char)
> +DEFINE_BASIC_PRINT_TYPE_FUNC(s16, "%d", short)
> +DEFINE_BASIC_PRINT_TYPE_FUNC(s32, "%d", int)
> +#if BITS_PER_LONG == 32
> DEFINE_BASIC_PRINT_TYPE_FUNC(u64, "%llx", unsigned long long)
> -DEFINE_BASIC_PRINT_TYPE_FUNC(s8, "%d", int)
> -DEFINE_BASIC_PRINT_TYPE_FUNC(s16, "%d", int)
> -DEFINE_BASIC_PRINT_TYPE_FUNC(s32, "%ld", long)
> DEFINE_BASIC_PRINT_TYPE_FUNC(s64, "%lld", long long)
> +#else /* BITS_PER_LONG == 64 */
> +DEFINE_BASIC_PRINT_TYPE_FUNC(u64, "%lx", unsigned long)
> +DEFINE_BASIC_PRINT_TYPE_FUNC(s64, "%ld", long)
> +#endif
I must have missed something... Not only I do not understand why
do we need "#if BITS_PER_LONG", I can't understand why
DEFINE_BASIC_PRINT_TYPE_FUNC() needs "cast" argument.
IOW, how about the patch below instead?
Oleg.
--- x/kernel/trace/trace_probe.c
+++ x/kernel/trace/trace_probe.c
@@ -40,23 +40,23 @@ const char *reserved_field_names[] = {
#define PRINT_TYPE_FMT_NAME(type) print_type_format_##type
/* Printing in basic type function template */
-#define DEFINE_BASIC_PRINT_TYPE_FUNC(type, fmt, cast) \
+#define DEFINE_BASIC_PRINT_TYPE_FUNC(type, fmt)
\
static __kprobes int PRINT_TYPE_FUNC_NAME(type)(struct trace_seq *s, \
const char *name, \
- void *data, void *ent)\
+ void *data, void *ent) \
{ \
- return trace_seq_printf(s, " %s=" fmt, name, (cast)*(type *)data);\
+ return trace_seq_printf(s, " %s=" fmt, name, *(type *)data);\
} \
static const char PRINT_TYPE_FMT_NAME(type)[] = fmt;
-DEFINE_BASIC_PRINT_TYPE_FUNC(u8, "%x", unsigned int)
-DEFINE_BASIC_PRINT_TYPE_FUNC(u16, "%x", unsigned int)
-DEFINE_BASIC_PRINT_TYPE_FUNC(u32, "%lx", unsigned long)
-DEFINE_BASIC_PRINT_TYPE_FUNC(u64, "%llx", unsigned long long)
-DEFINE_BASIC_PRINT_TYPE_FUNC(s8, "%d", int)
-DEFINE_BASIC_PRINT_TYPE_FUNC(s16, "%d", int)
-DEFINE_BASIC_PRINT_TYPE_FUNC(s32, "%ld", long)
-DEFINE_BASIC_PRINT_TYPE_FUNC(s64, "%lld", long long)
+DEFINE_BASIC_PRINT_TYPE_FUNC(u8, "%x")
+DEFINE_BASIC_PRINT_TYPE_FUNC(u16, "%x")
+DEFINE_BASIC_PRINT_TYPE_FUNC(u32, "%x")
+DEFINE_BASIC_PRINT_TYPE_FUNC(u64, "%Lx")
+DEFINE_BASIC_PRINT_TYPE_FUNC(s8, "%d")
+DEFINE_BASIC_PRINT_TYPE_FUNC(s16, "%d")
+DEFINE_BASIC_PRINT_TYPE_FUNC(s32, "%d")
+DEFINE_BASIC_PRINT_TYPE_FUNC(s64, "%Ld")
static inline void *get_rloc_data(u32 *dl)
{
--
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 1/1] ASoC: arizona: Set FLL to free-run before disabling
On Wed, Nov 20, 2013 at 02:37:09PM +, Richard Fitzgerald wrote: > The FLL must be placed into free-run mode before disabling > to allow it to entirely shut down. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 1/2] tracing/uprobes: Fix documentation of uprobe registration syntax
On 11/18, Namhyung Kim wrote: > > From: Namhyung Kim > > The uprobe syntax requires an offset after a file path not a symbol. > > Reviewed-by: Masami Hiramatsu > Cc: Srikar Dronamraju > Cc: Oleg Nesterov > Cc: zhangwei(Jovi) > Cc: Arnaldo Carvalho de Melo > Signed-off-by: Namhyung Kim Acked-by: Oleg Nesterov -- 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/9] ARM: at91/dt: add usb1 vbus and pullup pins
On 13:04 Wed 28 Aug , Boris BREZILLON wrote:
> Add vbus and pullup pinctrl definitions.
> Request the vbus and pullup pins in usb1 node.
>
> Signed-off-by: Boris BREZILLON
> ---
> arch/arm/boot/dts/at91rm9200ek.dts | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts
> b/arch/arm/boot/dts/at91rm9200ek.dts
> index 37b0880..76f3e87 100644
> --- a/arch/arm/boot/dts/at91rm9200ek.dts
> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
> @@ -29,6 +29,18 @@
>
> ahb {
> apb {
> + pinctrl@f400 {
> + usb1 {
> + pinctrl_usb1_vbus: usb1_vbus-0 {
> + atmel,pins = AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
> + };
it's a gpio no-need
> +
> + pinctrl_usb1_pullup: usb1_pullup-0 {
> + atmel,pins = AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;
> + };
no-need multidrive
> + };
> + };
> +
> dbgu: serial@f200 {
> status = "okay";
> };
> @@ -56,6 +68,9 @@
>
> usb1: gadget@fffb {
> atmel,vbus-gpio = < 4 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_usb1_vbus
> + _usb1_pullup>;
> status = "okay";
> };
>
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] virtio-net: fix page refcnt leaking when fail to allocate frag skb
On Wed, 2013-11-20 at 10:58 +0200, Michael S. Tsirkin wrote: > On Tue, Nov 19, 2013 at 02:00:11PM -0800, Eric Dumazet wrote: > > On Tue, 2013-11-19 at 23:53 +0200, Michael S. Tsirkin wrote: > > > > > Which NIC? Virtio? Prior to 2613af0ed18a11d5c566a81f9a6510b73180660a > > > it didn't drop packets received from host as far as I can tell. > > > virtio is more like a pipe than a real NIC in this respect. > > > > Prior/after to this patch, you were not posting buffers, so if packets > > were received on a physical NIC, you were dropping the packets anyway. > > > > It makes no difference at all, adding a cushion might make you feel > > better, but its really not worth it. > > > > Under memory stress, it makes better sense to drop a super big GRO > > packet (The one needing frag_list extension ...) > > > > It gives a better signal to the sender to reduce its pressure, and gives > > opportunity to free more of your memory. > > > > OK, but in that case one wonders whether we should do more to free memory? > > E.g. imagine that we dropped a packet of a specific TCP flow > because we couldn't allocate a new packet. > > What happens now is that the old packet is freed as well. > > So quite likely the next packet in queue will get processed > since it will reuse the memory we have just freed. > > The next packet and the next after it etc all will have to go through > the net stack until they get at the socket and are dropped then > because we missed a segment. Even worse, GRO gets disabled so the load > on receiver goes up instead of down. > > Sounds like a problem doesn't it? I see no problem at all. GRO is a hint for high rates (and obviously when there is enough memory) > > GRO actually detects it's the same flow and can see packet is > out of sequence. Why doesn't it drop the packet then? > Alternatively, we could (for example using the pre-allocated skb > like I suggested) notify GRO that it should start dropping packets > of this flow. > > What do you think? > I think we disagree a lot on memory management on networking stacks. We did a lot of work in TCP stack and Qdisc layers to lower memory pressure (and bufferbloat), an you seem to try hard to introduce yet another layer of buffer bloat in virtio_net. So add whatever you want to proudly state to your management : "Look how smart we are : we drop no packets in our layer" -- 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-kernel@vger.kernel.org
Re: perf/nmi : NMI Dazed and confused messages on core2
On Thu, Nov 14, 2013 at 04:32:28PM -0500, Vince Weaver wrote:
> Hello
>
> when running the perf_fuzzer on a core2 machine I often get the syslog
> spammed with messages like this:
>
> [ 7911.810186] Uhhuh. NMI received for unknown reason 3d on CPU 0.
> [ 7911.812756] Do you have a strange power saving mode enabled?
> [ 7911.812756] Dazed and confused, but trying to continue
> [ 7912.554225] Uhhuh. NMI received for unknown reason 2d on CPU 1.
> [ 7912.556758] Do you have a strange power saving mode enabled?
> [ 7912.556758] Dazed and confused, but trying to continue
> [ 7912.838169] Uhhuh. NMI received for unknown reason 2d on CPU 0.
> [ 7912.840726] Do you have a strange power saving mode enabled?
> [ 7912.840726] Dazed and confused, but trying to continue
>
> I've managed to narrow this down to a small program that will reproduce
> the issue (attached) although I can only get it to reproduce on a core2
> system (it doesn't work on recent atom or ivy bridge machines I have
> access to).
>
> So maybe it's just an obscure core2 problem and not worth fixing, but I
> thought I'd report it anyway.
>
> It looks like it might be related to setting up a cache event to trigger
> with high frequency while some other events are also triggering.
>
> Vince Weaver
> vincent.wea...@maine.edu
> http://www.eece.maine.edu/~vweaver/
Nice! Thanks. I'll try to reproduce and poke at this later in the week.
I actually have a core2 in my lab, hopefully this will work. I also have
another bug where someone complains that a pentium4 gets similar floods
with a 'perf record perf bench all' command. Perhaps the issues are
similar.
At least with your program I can narrow down the number of events that it
takes to cause this issue. :-) It should be more helpful to debug.
Thanks.
Cheers,
Don
> /* core2_nmi_flood.c */
> /* by Vince Weaver
> /* This code, when run in a tight loop, i.e. */
> /*while true; do ./core2_nmi_flood ; done */
> /* will lead to lots of NMI messages printed to the */
> /* syslog on a core2 machine running recent (3.12)*/
> /* Linux. */
>
> /*
> [ 7911.810186] Uhhuh. NMI received for unknown reason 3d on CPU 0.
> [ 7911.812756] Do you have a strange power saving mode enabled?
> [ 7911.812756] Dazed and confused, but trying to continue
> [ 7912.554225] Uhhuh. NMI received for unknown reason 2d on CPU 1.
> [ 7912.556758] Do you have a strange power saving mode enabled?
> [ 7912.556758] Dazed and confused, but trying to continue
> [ 7912.838169] Uhhuh. NMI received for unknown reason 2d on CPU 0.
> [ 7912.840726] Do you have a strange power saving mode enabled?
> [ 7912.840726] Dazed and confused, but trying to continue
> */
>
> #define _GNU_SOURCE 1
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int fd[1024];
> struct perf_event_attr pe[1024];
>
>
> long long id;
>
> struct sigaction sa;
> static int overflows=0;
>
> static void our_handler(int signum, siginfo_t *info, void *uc) {
> int fd = info->si_fd;
>
>
> ioctl(fd,PERF_EVENT_IOC_DISABLE,0);
> overflows++;
> ioctl(fd, PERF_EVENT_IOC_REFRESH,1);
> }
> int perf_event_open(struct perf_event_attr *hw_event_uptr,
> pid_t pid, int cpu, int group_fd, unsigned long flags) {
>
> return syscall(__NR_perf_event_open,hw_event_uptr, pid, cpu,
> group_fd, flags);
> }
>
> int main(int argc, char **argv) {
> /* 1 */
> /* 2 */
> /* 3 */
> /* fd = 15 */
>
> memset([15],0,sizeof(struct perf_event_attr));
> pe[15].type=PERF_TYPE_HARDWARE;
> pe[15].size=96;
> pe[15].config=PERF_COUNT_HW_CACHE_REFERENCES;
> pe[15].sample_period=0xf2;
>
> pe[15].sample_type=PERF_SAMPLE_TID|PERF_SAMPLE_ADDR|PERF_SAMPLE_READ|PERF_SAMPLE_CALLCHAIN|PERF_SAMPLE_RAW|PERF_SAMPLE_STACK_USER|PERF_SAMPLE_WEIGHT;//|PERF_SAMPLE_IDENTIFIER;
> /* 1643a */
>
> pe[15].read_format=PERF_FORMAT_TOTAL_TIME_ENABLED|PERF_FORMAT_TOTAL_TIME_RUNNING|PERF_FORMAT_ID;
> /* 7 */
> pe[15].disabled=1;
> pe[15].pinned=1;
> pe[15].exclude_idle=1;
> pe[15].mmap=1;
> pe[15].inherit_stat=1;
> pe[15].precise_ip=0; /* arbitrary skid */
> pe[15].exclude_guest=1;
> pe[15].exclude_callchain_kernel=1;
> pe[15].exclude_callchain_user=1;
> pe[15].wakeup_events=-1037221357;
> pe[15].bp_type=HW_BREAKPOINT_EMPTY;
> pe[15].config2=0xffb24240;
>
> pe[15].branch_sample_type=PERF_SAMPLE_BRANCH_USER|PERF_SAMPLE_BRANCH_KERNEL|PERF_SAMPLE_BRANCH_HV|PERF_SAMPLE_BRANCH_ANY;//|PERF_SAMPLE_BRANCH_ABORT_TX|0x8101ULL;
> pe[15].sample_regs_user=-2130706432;
> pe[15].sample_stack_user=176;
>
> fd[15]=perf_event_open([15],
> 0, /* current thread */
> -1, /*
linux-kernel@vger.kernel.org
Re: [PATCH 1/9] ARM: at91/dt: add rm9200 spi0 chip select pins definitions
On 13:02 Wed 28 Aug , Boris BREZILLON wrote:
> Add spi0 cs pinctrl pins definitions.
>
> Signed-off-by: Boris BREZILLON
> ---
> arch/arm/boot/dts/at91rm9200.dtsi | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
> b/arch/arm/boot/dts/at91rm9200.dtsi
> index f770655..69b76c7 100644
> --- a/arch/arm/boot/dts/at91rm9200.dtsi
> +++ b/arch/arm/boot/dts/at91rm9200.dtsi
> @@ -486,6 +486,26 @@
>AT91_PIOA 1
> AT91_PERIPH_A AT91_PINCTRL_NONE/* PA1 periph A SPI0_MOSI pin */
>AT91_PIOA 2
> AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PA2 periph A SPI0_SPCK pin */
> };
> +
> + pinctrl_spi0_cs0: spi0_cs0-0 {
> + atmel,pins =
> + AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PA3 periph A SPI0_NPCS0 pin */
> + };
> +
> + pinctrl_spi0_cs1: spi0_cs1-0 {
> + atmel,pins =
> + AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;/* PA4 GPIO SPI0_NPCS1 pin
> */
> + };
> +
> + pinctrl_spi0_cs2: spi0_cs2-0 {
> + atmel,pins =
> + AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;/* PA5 GPIO SPI0_NPCS2 pin
> */
> + };
> +
> + pinctrl_spi0_cs3: spi0_cs3-0 {
> + atmel,pins =
> + AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;/* PA6 GPIO SPI0_NPCS3 pin
> */
> + };
nack the pin are not multidrive there is only one master
Best Regards,
J.
> };
>
> pioA: gpio@f400 {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board
On 13:06 Wed 28 Aug , Boris BREZILLON wrote:
> Add slot0 of mmc0 pinctrl pins definitions:
> - detect pin
> - write protect pin
> - enable slot0 pin: this pin is connected to an external switch which
>enable mmc0 slot0 or spi dataflash connected to cs3
>
> The mmc0 device is not enabled, as it depends on the choosen functionnality
> (spi cs3 or mmc0 slot0).
>
> Signed-off-by: Boris BREZILLON
> ---
> arch/arm/boot/dts/at91rm9200ek.dts | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts
> b/arch/arm/boot/dts/at91rm9200ek.dts
> index f2d6d79..2bad423 100644
> --- a/arch/arm/boot/dts/at91rm9200ek.dts
> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
> @@ -39,6 +39,23 @@
> atmel,pins = AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;
> };
> };
> +
> + mmc0 {
> + pinctrl_mmc0_slot0_detect:
> mmc0_slot0_detect-0 {
> + atmel,pins =
> + AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
> + };
> +
> + pinctrl_mmc0_slot0_write_protect:
> mmc0_slot0_write_protect-0 {
> + atmel,pins =
> + AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> + };
> +
> + pinctrl_mmc0_slot0_switch:
> mmc0_slot0_switch-0 {
> + atmel,pins =
> + AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(1))>;
> + };
nack this is a regulator the pinctrl API is not done for gpio default value
> + };
> };
>
> dbgu: serial@f200 {
> @@ -84,6 +101,24 @@
> reg = <0>;
> };
> };
> +
> + mmc0: mmc@fffb4000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-0 = <_mmc0_clk
> + _mmc0_slot0_cmd_dat0
> + _mmc0_slot0_dat1_3
> + _mmc0_slot0_detect
> + _mmc0_slot0_write_protect
> + _mmc0_slot0_switch>;
> +
> + slot0: slot@0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = < 27 GPIO_ACTIVE_HIGH>;
> + wp-gpios = < 17 GPIO_ACTIVE_HIGH>;
> + };
> + };
> };
>
> usb0: ohci@0030 {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] ARM: at91/dt: add i2c devices connected to at91rm9200ek board
On 13:08 Wed 28 Aug , Boris BREZILLON wrote:
> Signed-off-by: Boris BREZILLON
> ---
> arch/arm/boot/dts/at91rm9200ek.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts
> b/arch/arm/boot/dts/at91rm9200ek.dts
> index b3e7425..fd2601a 100644
> --- a/arch/arm/boot/dts/at91rm9200ek.dts
> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
> @@ -147,6 +147,18 @@
> };
> };
>
> + i2c@0 {
> + status = "okay";
> +
> + ics1523@26 {
> + reg = <0x26>;
> + };
> +
> + dac3550@4d {
> + reg = <0x4d>;
missing compatible
> + };
> + };
> +
> leds {
> compatible = "gpio-leds";
>
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/vmcore mmap() failure issue
On Wed, Nov 20, 2013 at 05:29:16AM +, Atsushi Kumagai wrote: > On 2013/11/18 22:56:10, kexec wrote: > > On Mon, Nov 18, 2013 at 12:51:39AM +, Atsushi Kumagai wrote: > > > > [..] > > > > Is there any chance that you could look into fixing this. I have no > > > > experience writing code for makedumpfile. > > > > > > I'll send a patch to fix this soon. > > > > Thanks Atsushi. > > > > Vivek > > Vivek, could you test this patch ? > > Thanks > Atsushi Kumagai > > > From: Atsushi Kumagai > Date: Wed, 20 Nov 2013 10:05:03 +0900 > Subject: [PATCH] Disable mmap() for reading fractional pages. > > Since mmap() was introduced on /proc/vmcore, it fails > for fractional pages which don't start or end at page boundary > due to kernel issue. > This patch disables mmap() temporarily for fractional pages > to avoid this issue, so mmap() will be used only for aligned pages. > > Signed-off-by: Atsushi Kumagai Hi Atsushi, Even with this patch applied I see mmap() failure. mem_map (39) mem_map: ea0004e0 pfn_start : 138000 pfn_end: 14 read /proc/vmcore with mmap() Excluding unnecessary pages: [100.0 %] |STEP [Excluding unnecessary pages] : 0.035925 seconds Excluding unnecessary pages: [100.0 %] \STEP [Excluding unnecessary pages] : 0.035774 seconds Excluding unnecessary pages: [100.0 %] -STEP [Excluding unnecessary pages] : 0.035229 seconds Copying data : [ 40.9 %] -Can't map [b98fd000-b9cfd000] with mmap() read_from_vmcore: Can't read the dump memory(/proc/vmcore) with mmap(). readpage_elf: Can't read the dump memory(/proc/vmcore). readmem: type_addr: 1, addr:bffba000, size:4096 read_pfn: Can't get the page data. Resource temporarily unavailable makedumpfile Failed. kdump: saving vmcore failed Following is part of /proc/iomem on my system. 0010-bffc283f : System RAM 0100-018c551d : Kernel code 018c551e-01ef3f3f : Kernel data 0204a000-02984fff : Kernel bss 2e00-35ff : Crash kernel bffc2840-bfff : reserved This is a different system than what I used last time. So I am not sure if this is same error or something else. But one thing is clear that System RAM last page is partial and we should face mmap() failure. Thanks Vivek -- 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] cpufreq: cpufreq-cpu0: Use a sane boot frequency when booting with a mismatched bootloader configuration
On 11/19/2013 11:24 PM, viresh kumar wrote: > On Tuesday 19 November 2013 11:13 PM, Nishanth Menon wrote: >> we depend on the first transition to take us to a sane configuration - >> but we cannot predict when and if it will happen. > > I really believe that it happens fairly quickly, isn't it? We straight away > start the sampling of load and withing few milliseconds we must be fixing the > freq.. that heavily depends on the governor - and we all know the variants of ondemand governors that various distributions use. I cannot say (having not studied all governors out there) if this will take place in a few milliseconds or a few minutes or hours. > > We aren't going to stay for the unknown, might be unstable, freq for ever.. > With the current governors that we have in upstream, the only one of my concern has been userspace governor, but based on your comment earlier in the thread, this is considered an non-issue since userspace must trigger transition. However, this does put the SoC at risk depending on distro and custom governors used. If the opinion is that we dont care about these, well.. I can end my complaints and depend on the stats to tell me if an unknown frequency was ever attempted for debug (even though I might personally not be too excited about it). -- Regards, Nishanth Menon -- 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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Tuesday 19 of November 2013 10:59:39 Doug Anderson wrote: > On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren > wrote: > > On 11/19/2013 10:15 AM, Tomasz Figa wrote: > >> This patch extends the range of settings configurable via pinfunc API > >> to cover pin value as well. This allows configuration of default values > >> of pins. > > > > Shouldn't there be a driver that acquires the GPIO that's output to the > > pin, and configures the output value? IIRC there have been previous > > discussions re: having a list of e.g. initial GPIO output values in DT, > > and that was rejected, and this patch seems to be doing almost the exact > > same thing, just at the pinctrl level rather than GPIO level. > > > > That all said, I admit this could be a useful feature... > > I haven't followed all of the previous discussions, but I know I've > run into scenarios where something like this would be useful. The one > that comes to mind is: > > * We've got GPIOs that default at bootup to a pulled up input since > the default state of the pin should be "high". > > * These pins are really intended to be outputs, like an "enable", > "reset", or "power down" line for a peripheral. The pullup is strong > enough to give us a good default state but we really want outputs. > > * We'd like to provide this GPIO to a peripheral through device tree. > ...and we'd like all the pinmux to be setup automatically so we use > pinctrl-names = "default". > > * If we set the pinmux up as "output" then there's a chance that the > line will glitch at bootup since the pinmux happens (changing the pin > to output) before the driver has a chance to run. > > > Does that sound like the same scenario you're trying to solve Tomasz? Yes. That's one of the use cases I had in my mind. Best regards, Tomasz -- 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] clk: keystone: gate: fix error handling on init
On Wednesday 20 November 2013 07:09 AM, Grygorii Strashko wrote: > This patch fixes Keystone gate control clock driver initialization path: > 1) clk_register_psc() returns error code and not a pure pointer, hence > its return value need to be checked using IS_ERR(clk) macro. > > 2) Mapped IO memory isn't unmapped in case of errors, hence fix it. > > Signed-off-by: Grygorii Strashko > --- Looks good. Thanks !! Mike, If you are ok can you please consider it for fixes ? Regards, Santosh -- 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-kernel@vger.kernel.org
Re: OOPS: Bluetooth: Store RFCOMM address information in its own socket structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2013 2:53 AM, Marcel Holtmann wrote: > fix for this is already in John’s wireless tree. On a side note, > the bisect is correct, but it is not the patch that broke it. It is > just the patch that uncovered it. Great, thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSjMp0AAoJEJrBOlT6nu75SVcIAIdHUznWh7VjtCEebcF+LzGK DGPReiaaRqHJMtd02Oka/3ARxwv9F2y8V/eYK9RIrE+6Wbi3uSOueqgWlz6mZQoo cXNceyZngmwBmvQZJyDa3Eza/D/SBXclkkZu5F0J8umlY2y59FWNk2mBLJCYGJbB o+SQgP6lwgUsB92PWLUJ4khd/oqsWYb9t5d2TJO1uMKCy2Gzr4y5EjXfoe7xluIw UkzxW1TDO3bwBUlzB8u7bmJLt52D3+n2Tmc6YC819R67t/BqKDjbG+/kocEizrL5 w7QjsU0/HJw8b0E3jx3Y87z0fCdEAL2RibxUUuG5MIPjrFsh4QqDopqZ71+mbc4= =G8YC -END PGP SIGNATURE- -- 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-kernel@vger.kernel.org
linux-kernel@vger.kernel.org
linux-kernel@vger.kernel.org
Re: input question: ambient light sensor button
On Thu, Nov 14, 2013 at 01:02:31PM +0100, Pali Rohár wrote: > On Wednesday 13 November 2013 17:28:40 Dmitry Torokhov wrote: > > On Wed, Nov 13, 2013 at 11:47:18AM +0100, Jiri Kosina wrote: > > > On Sun, 15 Sep 2013, Pali Rohár wrote: > > > > I do not know where to ask this question, but I think that > > > > kernel developers could help me. > > > > > > > > I have notebook with one special button on keyboard which > > > > is designed for turning ambient light sensor on and off. > > > > By default pressing button do nothing (I can turn ambient > > > > light sensor on/off via sysfs platform wmi module). > > > > Button press is reported by kernel input device AT > > > > Translated Set 2 keyboard and reports it as button > > > > "touchpad off". > > > > > > > > Of course "touchpad off" is incorrect and I'd like to ask > > > > which kernel key or button from > > > > /usr/include/linux/input.h should be mapped for my > > > > ambient light sensor button? Is there already some? And > > > > what is strategy for allocating KEY_* and BTN_* numbers? > > > > > > This is maintained by Dmitry, so he's the one to answer > > > this. I am adding him to CC. > > > > I guess we need patch adding > > > > #define KEY_ALS_TOGGLE 0x230 > > > > Thanks. > > So there is no good key for als yet? No, but if you send me a patch adding it I will gladly apply it. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/1] ASoC: arizona: Set FLL to free-run before disabling
The FLL must be placed into free-run mode before disabling to allow it to entirely shut down. Signed-off-by: Richard Fitzgerald --- sound/soc/codecs/arizona.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index 6f05b17..fea9910 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -1529,6 +1529,8 @@ static void arizona_enable_fll(struct arizona_fll *fll, try_wait_for_completion(>ok); regmap_update_bits(arizona->regmap, fll->base + 1, + ARIZONA_FLL1_FREERUN, 0); + regmap_update_bits(arizona->regmap, fll->base + 1, ARIZONA_FLL1_ENA, ARIZONA_FLL1_ENA); if (use_sync) regmap_update_bits(arizona->regmap, fll->base + 0x11, @@ -1546,6 +1548,8 @@ static void arizona_disable_fll(struct arizona_fll *fll) struct arizona *arizona = fll->arizona; bool change; + regmap_update_bits(arizona->regmap, fll->base + 1, + ARIZONA_FLL1_FREERUN, ARIZONA_FLL1_FREERUN); regmap_update_bits_check(arizona->regmap, fll->base + 1, ARIZONA_FLL1_ENA, 0, ); regmap_update_bits(arizona->regmap, fll->base + 0x11, -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1.2] gpiolib: append SFI helpers for GPIO API
On Tue, 2013-11-19 at 09:32 -0800, David Cohen wrote: > On 11/19/2013 01:27 AM, Alex Courbot wrote: > > On 11/19/2013 06:24 PM, Linus Walleij wrote: > >> On Wed, Jun 5, 2013 at 3:58 PM, Andy Shevchenko > >> wrote: > >> > >>> To support some (legacy) firmwares and platforms let's make life > >>> easier for > >>> their customers. > >>> > >>> This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c. > >>> > >>> Signed-off-by: Andy Shevchenko > >> > >> So since this patch was ACKed the world has changed a bit and now > >> I want new changes (or maybe I was tired and not paying enough > >> attention at the time). > > Agreed. Even my e-mail was outdated :) > Updating from david.a.co...@intel.com to david.a.co...@linux.intel.com > to avoid M$ servers. Just sent a version, though, sorry, I forgot to update your email there. -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] sfi, intel_mid: introduce SFI GPIO API and use it
Here is a second [1] version of the SFI GPIO API. This series contains SFI GPIO API layer along with the update of intel-mid platform to use it instead of internal copy. It has been tested on Medfield device with linux-next 20131118. [1] https://lkml.org/lkml/2013/6/5/316 Andy Shevchenko (3): sfi: fix compiler warnings gpiolib: append SFI helpers for GPIO API intel_mid: switch to use SFI GPIO API arch/x86/include/asm/intel-mid.h | 1 - .../intel-mid/device_libs/platform_emc1403.c | 8 +-- .../intel-mid/device_libs/platform_gpio_keys.c | 10 +-- .../intel-mid/device_libs/platform_lis331.c| 8 +-- .../intel-mid/device_libs/platform_max3111.c | 6 +- .../intel-mid/device_libs/platform_max7315.c | 10 +-- .../intel-mid/device_libs/platform_mpu3050.c | 6 +- .../intel-mid/device_libs/platform_msic_gpio.c | 6 +- .../intel-mid/device_libs/platform_msic_ocd.c | 5 +- .../intel-mid/device_libs/platform_pmic_gpio.c | 7 +- .../intel-mid/device_libs/platform_tc35876x.c | 8 +-- .../intel-mid/device_libs/platform_tca6416.c | 10 +-- arch/x86/platform/intel-mid/sfi.c | 51 -- drivers/gpio/Kconfig | 4 ++ drivers/gpio/Makefile | 1 + drivers/gpio/gpiolib-sfi.c | 77 ++ drivers/sfi/sfi_acpi.c | 8 +-- drivers/sfi/sfi_core.c | 13 +++- include/linux/gpio/sfi.h | 37 +++ include/linux/sfi_acpi.h | 2 +- 20 files changed, 176 insertions(+), 102 deletions(-) create mode 100644 drivers/gpio/gpiolib-sfi.c create mode 100644 include/linux/gpio/sfi.h -- 1.8.4.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 v2 1/3] sfi: fix compiler warnings
This fixes the following compiler warnings when build is done by make W=1.
drivers/sfi/sfi_acpi.c:154:5: warning: no previous prototype for
‘sfi_acpi_table_parse’ [-Wmissing-prototypes]
drivers/sfi/sfi_core.c:164:26: warning: no previous prototype for
‘sfi_map_table’ [-Wmissing-prototypes]
drivers/sfi/sfi_core.c:192:6: warning: no previous prototype for
‘sfi_unmap_table’ [-Wmissing-prototypes]
Indentation fixes are also included.
Signed-off-by: Andy Shevchenko
---
drivers/sfi/sfi_acpi.c | 8
drivers/sfi/sfi_core.c | 4 ++--
include/linux/sfi_acpi.h | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/sfi/sfi_acpi.c b/drivers/sfi/sfi_acpi.c
index f5b4ca5..728a2e2 100644
--- a/drivers/sfi/sfi_acpi.c
+++ b/drivers/sfi/sfi_acpi.c
@@ -63,6 +63,7 @@
#include
#include
+#include
#include "sfi_core.h"
/*
@@ -152,7 +153,7 @@ static void sfi_acpi_put_table(struct acpi_table_header
*table)
* Find specified table in XSDT, run handler on it and return its return value
*/
int sfi_acpi_table_parse(char *signature, char *oem_id, char *oem_table_id,
- int(*handler)(struct acpi_table_header *))
+int(*handler)(struct acpi_table_header *))
{
struct acpi_table_header *table = NULL;
struct sfi_table_key key;
@@ -175,8 +176,8 @@ int sfi_acpi_table_parse(char *signature, char *oem_id,
char *oem_table_id,
}
static ssize_t sfi_acpi_table_show(struct file *filp, struct kobject *kobj,
- struct bin_attribute *bin_attr, char *buf,
- loff_t offset, size_t count)
+ struct bin_attribute *bin_attr, char *buf,
+ loff_t offset, size_t count)
{
struct sfi_table_attr *tbl_attr =
container_of(bin_attr, struct sfi_table_attr, attr);
@@ -199,7 +200,6 @@ static ssize_t sfi_acpi_table_show(struct file *filp,
struct kobject *kobj,
return cnt;
}
-
void __init sfi_acpi_sysfs_init(void)
{
u32 tbl_cnt, i;
diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 1e824fb..296db7a 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -161,7 +161,7 @@ static int sfi_verify_table(struct sfi_table_header *table)
* Check for common case that we can re-use mapping to SYST,
* which requires syst_pa, syst_va to be initialized.
*/
-struct sfi_table_header *sfi_map_table(u64 pa)
+static struct sfi_table_header *sfi_map_table(u64 pa)
{
struct sfi_table_header *th;
u32 length;
@@ -189,7 +189,7 @@ struct sfi_table_header *sfi_map_table(u64 pa)
* Undoes effect of sfi_map_table() by unmapping table
* if it did not completely fit on same page as SYST.
*/
-void sfi_unmap_table(struct sfi_table_header *th)
+static void sfi_unmap_table(struct sfi_table_header *th)
{
if (!TABLE_ON_PAGE(syst_va, th, th->len))
sfi_unmap_memory(th, TABLE_ON_PAGE(th, th, th->len) ?
diff --git a/include/linux/sfi_acpi.h b/include/linux/sfi_acpi.h
index 631af63..1a88ef6 100644
--- a/include/linux/sfi_acpi.h
+++ b/include/linux/sfi_acpi.h
@@ -60,7 +60,7 @@
#define _LINUX_SFI_ACPI_H
#ifdef CONFIG_SFI
-#include /* struct acpi_table_header */
+#include /* struct acpi_table_header */
extern int sfi_acpi_table_parse(char *signature, char *oem_id,
char *oem_table_id,
--
1.8.4.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 v2 2/3] gpiolib: append SFI helpers for GPIO API
To support some (legacy) firmwares and platforms let's make life easier for
their customers.
This patch extracts SFI GPIO API from arch/x86/platform/intel-mid/sfi.c and
moves it to GPIO descriptor API.
Signed-off-by: Andy Shevchenko
Cc: Len Brown
Cc: Grant Likely
Cc: Linus Walleij
---
drivers/gpio/Kconfig | 4 +++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpiolib-sfi.c | 77 ++
drivers/sfi/sfi_core.c | 9 +-
include/linux/gpio/sfi.h | 37 ++
5 files changed, 127 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpio/gpiolib-sfi.c
create mode 100644 include/linux/gpio/sfi.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0f0..9a4fe9f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -51,6 +51,10 @@ config OF_GPIO
def_bool y
depends on OF
+config GPIO_SFI
+ def_bool y
+ depends on SFI
+
config GPIO_ACPI
def_bool y
depends on ACPI
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 7971e36..b6820bc 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -5,6 +5,7 @@ ccflags-$(CONFIG_DEBUG_GPIO)+= -DDEBUG
obj-$(CONFIG_GPIO_DEVRES) += devres.o
obj-$(CONFIG_GPIOLIB) += gpiolib.o
obj-$(CONFIG_OF_GPIO) += gpiolib-of.o
+obj-$(CONFIG_GPIO_SFI) += gpiolib-sfi.o
obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
# Device drivers. Generally keep list sorted alphabetically
diff --git a/drivers/gpio/gpiolib-sfi.c b/drivers/gpio/gpiolib-sfi.c
new file mode 100644
index 000..5dc6314
--- /dev/null
+++ b/drivers/gpio/gpiolib-sfi.c
@@ -0,0 +1,77 @@
+/*
+ * Simple Firmware Interface (SFI) helpers for GPIO API
+ *
+ * Copyright (C) 2013, Intel Corporation
+ * Author: Andy Shevchenko
+ *
+ * Based on work done for Intel MID platform
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) "SFI: GPIO: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct sfi_gpio_table_entry *sfi_gpio_table;
+static int sfi_gpio_num_entry;
+
+struct gpio_desc *sfi_get_gpiod_by_name(const char *name)
+{
+ struct sfi_gpio_table_entry *pentry = sfi_gpio_table;
+ int i;
+
+ if (!pentry)
+ return ERR_PTR(-EINVAL);
+
+ for (i = 0; i < sfi_gpio_num_entry; i++, pentry++) {
+ if (!strncmp(name, pentry->pin_name, SFI_NAME_LEN))
+ return gpio_to_desc(pentry->pin_no);
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(sfi_get_gpiod_by_name);
+
+static int __init sfi_gpio_parse(struct sfi_table_header *table)
+{
+ struct sfi_table_simple *sb;
+ struct sfi_gpio_table_entry *pentry;
+ int num, i;
+
+ if (sfi_gpio_table)
+ return 0;
+
+ sb = container_of(table, struct sfi_table_simple, header);
+
+ num = SFI_GET_NUM_ENTRIES(sb, struct sfi_gpio_table_entry);
+ pentry = (struct sfi_gpio_table_entry *)sb->pentry;
+
+ sfi_gpio_table = kmemdup(pentry, num * sizeof(*pentry), GFP_KERNEL);
+ if (!sfi_gpio_table)
+ return -ENOMEM;
+
+ sfi_gpio_num_entry = num;
+
+ pr_debug("Pin info:\n");
+ for (i = 0; i < num; i++, pentry++)
+ pr_debug("[%2d] chip = %16.16s, name = %16.16s, pin=%d\n", i,
+pentry->controller_name, pentry->pin_name,
+pentry->pin_no);
+
+ return 0;
+}
+
+int __init sfi_gpio_init(void)
+{
+ return sfi_table_parse(SFI_SIG_GPIO, NULL, NULL, sfi_gpio_parse);
+}
diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 296db7a..1fab93d 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -66,8 +66,9 @@
#include
#include
#include
-#include
#include
+#include
+#include
#include "sfi_core.h"
@@ -512,6 +513,12 @@ void __init sfi_init_late(void)
syst_va = sfi_map_memory(syst_pa, length);
sfi_acpi_init();
+
+ /*
+* Parsing GPIO table first, since the DEVS table will need this table
+* to map the pin name to the actual pin.
+*/
+ sfi_gpio_init();
}
/*
diff --git a/include/linux/gpio/sfi.h b/include/linux/gpio/sfi.h
new file mode 100644
index 000..3e111ad
--- /dev/null
+++ b/include/linux/gpio/sfi.h
@@ -0,0 +1,37 @@
+#ifndef _LINUX_SFI_GPIO_H_
+#define _LINUX_SFI_GPIO_H_
+
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_GPIO_SFI
+
+struct gpio_desc *sfi_get_gpiod_by_name(const char *name);
+int sfi_gpio_init(void);
+
+#else /* CONFIG_GPIO_SFI */
+
+static inline struct gpio_desc *sfi_get_gpiod_by_name(const char *name);
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static inline int sfi_gpio_init(void)
+{
+ return
[PATCH v2 3/3] intel_mid: switch to use SFI GPIO API
Instead of custom implementation of the SFI GPIO API let's use one provided by
gpiolib.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/intel-mid.h | 1 -
.../intel-mid/device_libs/platform_emc1403.c | 8 ++--
.../intel-mid/device_libs/platform_gpio_keys.c | 10 ++---
.../intel-mid/device_libs/platform_lis331.c| 8 ++--
.../intel-mid/device_libs/platform_max3111.c | 6 +--
.../intel-mid/device_libs/platform_max7315.c | 10 ++---
.../intel-mid/device_libs/platform_mpu3050.c | 6 +--
.../intel-mid/device_libs/platform_msic_gpio.c | 6 +--
.../intel-mid/device_libs/platform_msic_ocd.c | 5 +--
.../intel-mid/device_libs/platform_pmic_gpio.c | 7 +--
.../intel-mid/device_libs/platform_tc35876x.c | 8 ++--
.../intel-mid/device_libs/platform_tca6416.c | 10 ++---
arch/x86/platform/intel-mid/sfi.c | 51 --
13 files changed, 42 insertions(+), 94 deletions(-)
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index 459769d..7e426b1 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -15,7 +15,6 @@
#include
extern int intel_mid_pci_init(void);
-extern int get_gpio_by_name(const char *name);
extern void intel_scu_device_register(struct platform_device *pdev);
extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
b/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
index 0d942c1..502f50f 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
@@ -11,7 +11,7 @@
*/
#include
-#include
+#include
#include
#include
@@ -19,10 +19,10 @@ static void __init *emc1403_platform_data(void *info)
{
static short intr2nd_pdata;
struct i2c_board_info *i2c_info = info;
- int intr = get_gpio_by_name("thermal_int");
- int intr2nd = get_gpio_by_name("thermal_alert");
+ int intr = sfi_get_gpio_by_name("thermal_int");
+ int intr2nd = sfi_get_gpio_by_name("thermal_alert");
- if (intr == -1 || intr2nd == -1)
+ if (intr < 0 || intr2nd < 0)
return NULL;
i2c_info->irq = intr + INTEL_MID_IRQ_OFFSET;
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
b/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
index a013a48..e3fb5be 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
@@ -13,7 +13,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -61,12 +61,12 @@ static int __init pb_keys_init(void)
struct gpio_keys_button *gb = gpio_button;
int i, num, good = 0;
- num = sizeof(gpio_button) / sizeof(struct gpio_keys_button);
+ num = ARRAY_SIZE(gpio_button);
for (i = 0; i < num; i++) {
- gb[i].gpio = get_gpio_by_name(gb[i].desc);
+ gb[i].gpio = sfi_get_gpio_by_name(gb[i].desc);
pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
- gb[i].gpio);
- if (gb[i].gpio == -1)
+gb[i].gpio);
+ if (gb[i].gpio < 0)
continue;
if (i != good)
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
b/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
index 15278c1..8cd0c33 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_lis331.c
@@ -11,17 +11,17 @@
*/
#include
-#include
+#include
#include
static void __init *lis331dl_platform_data(void *info)
{
static short intr2nd_pdata;
struct i2c_board_info *i2c_info = info;
- int intr = get_gpio_by_name("accel_int");
- int intr2nd = get_gpio_by_name("accel_2");
+ int intr = sfi_get_gpio_by_name("accel_int");
+ int intr2nd = sfi_get_gpio_by_name("accel_2");
- if (intr == -1 || intr2nd == -1)
+ if (intr < 0 || intr2nd < 0)
return NULL;
i2c_info->irq = intr + INTEL_MID_IRQ_OFFSET;
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_max3111.c
b/arch/x86/platform/intel-mid/device_libs/platform_max3111.c
index afd1df9..99d3832 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_max3111.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_max3111.c
@@ -10,17 +10,17 @@
* of the License.
*/
-#include
+#include
#include
#include
static void __init *max3111_platform_data(void *info)
{
struct spi_board_info *spi_info = info;
- int intr = get_gpio_by_name("max3111_int");
+ int
Re: [PATCH -tip v3 00/23] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
masami.hiramatsu.pt wrote: > [...] This series also includes a change which prohibits probing on > the address in .entry.text because the code is used for very > low-level sensitive interrupt/syscall entries. Probing such code may > cause unexpected result (actually most of that area is already in > the kprobe blacklist). So I've decide to prohibit probing all of > them. [...] Does this new blacklist cover enough that the kernel now survives a broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms? - FChE -- 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] Timer: Migrate running timers
On Wednesday 20 November 2013 05:12 PM, Thomas Gleixner wrote: > Viresh, > > On Wed, 20 Nov 2013, Viresh Kumar wrote: > >> Migration of timers from idle cores to non-idle ones for power saving is very >> well working and really saves a lot of power for us. What's currently not >> working is the migration of running timers Or timers which re-arms >> themselves. >> >> There are complications with migrating timers which schedules themselves >> again >> from their handler. del_timer_sync() can't detect that the timer's handler >> yet has not finished. > > Because you try to violate the semantics of the existing code. There > is a reason why we enforce that running timers must be requeued on the > base they are running on. > > Now you try to duct tape it into submission. That's not going to fly. > > The timer wheel code is not designed to allow that and it has lots of > other short comings and historic burdens. I'm not going to accept more > duct tape and fragile hackery into that code. > > I'm already working on a complete replacement infrastructure, which > avoids all the short comings of the current timer implementation > including this one. > > It's going to be a massive effort to convert everything over to the > new infrastructure so we can kill the timer wheel, but that's less > scary and less risky than trying to add more fragility to the existing > code. Thanks for the feedback. I Atleast know now that this patch doesn't have a future :) -- 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-kernel@vger.kernel.org
Re: [PATCH 04/12] KVM: MMU: log dirty page after marking spte writable
On Nov 20, 2013, at 8:29 AM, Marcelo Tosatti wrote:
> On Wed, Aug 07, 2013 at 12:06:49PM +0800, Xiao Guangrong wrote:
>> On 08/07/2013 09:48 AM, Marcelo Tosatti wrote:
>>> On Tue, Jul 30, 2013 at 09:02:02PM +0800, Xiao Guangrong wrote:
Make sure we can see the writable spte before the dirt bitmap is visible
We do this is for kvm_vm_ioctl_get_dirty_log() write-protects the spte
based
on the dirty bitmap, we should ensure the writable spte can be found in
rmap
before the dirty bitmap is visible. Otherwise, we cleared the dirty bitmap
and
failed to write-protect the page
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> Can you explain why this is safe, with regard to the rule
>>> at edde99ce05290e50 ?
>>
>> BTW, this log fixed this case:
>>
>>VCPU 0KVM migration control
>>
>> write-protects all pages
>> #Pf happen then the page
>> become writable, set dirty
>> bit on the bitmap
>>
>> swap the bitmap, current bitmap is empty
>>
>> write the page (no dirty log)
>>
>> stop the guest and push
>> the remaining dirty pages
>> Stopped
>> See current bitmap is empty that means
>> no page is dirty.
>>>
>>> "The rule is that all pages are either dirty in the current bitmap,
>>> or write-protected, which is violated here."
>>
>> Actually, this rule is not complete true, there's the 3th case:
>> the window between write guest page and set dirty bitmap is valid.
>> In that window, page is write-free and not dirty logged.
>>
>> This case is based on the fact that at the final step of live migration,
>> kvm should stop the guest and push the remaining dirty pages to the
>> destination.
>>
>> They're some examples in the current code:
>> example 1, in fast_pf_fix_direct_spte():
>> if (cmpxchg64(sptep, spte, spte | PT_WRITABLE_MASK) == spte)
>> /* The window in here... */
>> mark_page_dirty(vcpu->kvm, gfn);
>>
>> example 2, in kvm_write_guest_page():
>> r = __copy_to_user((void __user *)addr + offset, data, len);
>> if (r)
>> return -EFAULT;
>> /*
>> * The window is here, the page is dirty but not logged in
>>* The bitmap.
>> */
>> mark_page_dirty(kvm, gfn);
>> return 0;
>
Hi Marcelo,
> Why is this valid ? That is, the obviously correct rule is
>
> "that all pages are either dirty in the current bitmap,
> or write-protected, which is violated here."
>
> With the window above, GET_DIRTY_LOG can be called 100 times while the
> page is dirty, but the corresponding bit not set in the dirty bitmap.
>
> It violates the documentation:
>
> /* for KVM_GET_DIRTY_LOG */
> struct kvm_dirty_log {
> __u32 slot;
> __u32 padding;
> union {
> void __user *dirty_bitmap; /* one bit per page */
> __u64 padding;
> };
> };
>
> Given a memory slot, return a bitmap containing any pages dirtied
> since the last call to this ioctl. Bit 0 is the first page in the
> memory slot. Ensure the entire structure is cleared to avoid padding
> issues.
>
> The point about migration, is that GET_DIRTY_LOG is strictly correct
> because it stops vcpus.
>
> But what guarantee does userspace require, from GET_DIRTY_LOG, while vcpus are
> executing?
Aha. Single calling GET_DIRTY_LOG is useless since new dirty page can be
generated
when GET_DIRTY_LOG is being returned. If user wants to get exact dirty pages
the vcpus
should be stopped.
>
> With fast page fault:
>
> if (cmpxchg64(sptep, spte, spte | PT_WRITABLE_MASK) == spte)
> /* The window in here... */
> mark_page_dirty(vcpu->kvm, gfn);
>
> And the $SUBJECT set_spte reordering, the rule becomes
>
> A call to GET_DIRTY_LOG guarantees to return correct information about
> dirty pages before invocation of the previous GET_DIRTY_LOG call.
>
> (see example 1: the next GET_DIRTY_LOG will return the dirty information
> there).
>
It seems no.
The first GET_DIRTY_LOG can happen before fast-page-fault，
the second GET_DIRTY_LOG happens in the window between cmpxchg()
and mark_page_dirty(), for the second one, the information is still “incorrect”.
> The rule for sptes that is, because kvm_write_guest does not match the
> documentation at all.
You mean the case of “kvm_write_guest” is valid (I do not know why it is)?
Or anything else?
>
> So before example 1 and this patch, the rule (well for sptes at least) was
>
> "Given a memory slot, return a bitmap containing any pages dirtied
> since the last call to this ioctl. Bit 0 is the first page in the
> memory slot. Ensure the entire structure is cleared to avoid padding
> issues."
>
> Can you explain why it is OK to relax this rule?
It’s because:
1) it
Re: [PATCH RFC] virtio_net: fix error handling for mergeable buffers
On Wed, Nov 20, 2013 at 08:54:02AM -0500, Jason Wang wrote:
>
>
> - 原始邮件 -
> > On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote:
> > > When mergeable buffer were used, we only put the first page buf leave the
> > > rest
> > > of buffers in the virt queue. This will cause the driver could not get the
> > > correct head buffer any more. Fix this by dropping the rest of buffers for
> > > this
> > > packet.
> > >
> > > The bug was introduced by commit 9ab86bbcf8be755256f0a5e994e0b38af6b4d399
> > > (virtio_net: Defer skb allocation in receive path).
> > >
> > > Cc: Rusty Russell
> > > Cc: Michael S. Tsirkin
> > > Cc: Michael Dalton
> > > Cc: Eric Dumazet
> > > Cc: Shirley Ma
> > > Signed-off-by: Jason Wang
> >
> > Just to clarify my previous comment: it was not about the
> > idea of adding drop_mergeable_buffer - rather, I think that
> > adding knowledge about mergeable buffers into page_to_skb creates an
> > ugly internal API.
> >
> > Let's move the call to page_to_skb within receive_mergeable instead:
> > it's also nice that int offset = buf - page_address(page) logic
> > is not spread around like it was.
> >
> > Also, it's not nice that we ignore length errors when we drop
> > packets because of OOM.
> >
> > So I came up with the following - it seems to work but I didn't
> > stress test yet.
>
> I've no objection on this. But I've rather like my small and direct patch
> to be applied to -net first. It has lower risk and was much more easier to
> be backported to stable trees. Then we can do the re-factor like this in
> net-next.
It makes the interfaces too messy. We are not in code freeze in -net -
only feature freeze, so no reason to make code like spagetty,
and it's only 25 lines changed as compared to 40.
It's not a huge refactoring.
It's just as easy to backport my patch too.
You just drop the goto in the new code path we added.
Let me show you (untested) - your patch is not smaller.
Signed-off-by: Michael S. Tsirkin
commit 9b442fe970d5c71311d4314edef26ee2eb16e7fb
Author: Michael S. Tsirkin
Date: Wed Nov 20 12:44:14 2013 +0200
virtio_net: fix resource leak on alloc failure
virtio net got confused, started dropping packets.
Signed-off-by: Michael S. Tsirkin
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 9fbdfcd..df4b9d0 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -297,13 +297,22 @@ static struct sk_buff *page_to_skb(struct receive_queue
*rq,
return skb;
}
-static int receive_mergeable(struct receive_queue *rq, struct sk_buff *skb)
+static struct sk_buff *receive_mergeable(struct net_device *dev,
+struct receive_queue *rq,
+struct page *page,
+unsigned int len)
{
- struct skb_vnet_hdr *hdr = skb_vnet_hdr(skb);
- struct page *page;
- int num_buf, i, len;
+ struct skb_vnet_hdr *hdr = page_address(buf);
+ int num_buf = hdr->mhdr.num_buffers;
+ struct sk_buff *skb = page_to_skb(rq, page, len);
+ int i;
+
+ skb = page_to_skb(rq, page, len);
+
+ if (unlikely(!skb))
+ goto err_skb;
+
- num_buf = hdr->mhdr.num_buffers;
while (--num_buf) {
i = skb_shinfo(skb)->nr_frags;
if (i >= MAX_SKB_FRAGS) {
@@ -313,10 +322,10 @@ static int receive_mergeable(struct receive_queue *rq,
struct sk_buff *skb)
}
page = virtqueue_get_buf(rq->vq, );
if (!page) {
- pr_debug("%s: rx error: %d buffers missing\n",
-skb->dev->name, hdr->mhdr.num_buffers);
- skb->dev->stats.rx_length_errors++;
- return -EINVAL;
+ pr_debug("%s: rx error: %d buffers %d missing\n",
+dev->name, hdr->mhdr.num_buffers, num_buf);
+ dev->stats.rx_length_errors++;
+ goto err_buf;
}
if (len > PAGE_SIZE)
@@ -326,7 +335,25 @@ static int receive_mergeable(struct receive_queue *rq,
struct sk_buff *skb)
--rq->num;
}
- return 0;
+ return skb;
+err_skb:
+ put_page(page);
+err_buf:
+ dev->stats.rx_dropped++;
+ dev_kfree_skb(head_skb);
+ while (--num_buf) {
+ buf = virtqueue_get_buf(rq->vq, );
+ if (unlikely(!buf)) {
+ pr_debug("%s: rx error: %d buffers missing\n",
+dev->name, num_buf);
+ dev->stats.rx_length_errors++;
+ break;
+ }
+ page = buf;
+ give_pages(rq, page);
+ --rq->num;
+ }
+ return NULL;
}
static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
[PATCH] clk: propagate parent change up one level
This patch adds support for propagation of setup of clock's parent one level
up.
This feature is helpful when a driver changes topology of its clocks using
clk_set_parent(). The problem occurs when driver's clock is located at MUX
output on one platform/SoC but on the other platform/SoC there is a gated proxy
clock between the MUX and driver's clock. In such a case, driver's code has to
be modified to use one clock for enabling and the other clock for setup of a
parent.
The code updates are avoided by propagating setup of a parent up one level.
Additionally, this patch adds CLK_SET_PARENT_PARENT (sorry for naming) flag to
inform clk-core that clk_set_parent() should be propagated.
Signed-off-by: Tomasz Stanislawski
---
drivers/clk/clk.c|6 ++
include/linux/clk-provider.h |1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a004769..14eda80 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1595,6 +1595,12 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
/* try finding the new parent index */
if (parent) {
+ if ((clk->flags & CLK_SET_PARENT_PARENT)
+ && clk->num_parents == 1) {
+ ret = clk_set_parent(clk->parent, parent);
+ goto out;
+ }
+
p_index = clk_fetch_parent_index(clk, parent);
p_rate = parent->rate;
if (p_index == clk->num_parents) {
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 73bdb69..83c98d5 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -29,6 +29,7 @@
#define CLK_IS_BASIC BIT(5) /* Basic clk, can't do a to_clk_foo() */
#define CLK_GET_RATE_NOCACHE BIT(6) /* do not use the cached clk rate */
#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
+#define CLK_SET_PARENT_PARENT BIT(8) /* propagate parent change up one level
*/
struct clk_hw;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] charger: max14577: Add charger support for Maxim 14577
MAX14577 chip is a multi-function device which includes MUIC, charger
and voltage regulator. The driver is located in drivers/mfd.
This patch supports battery charging control of MAX14577 chip and
provides power supply class information to userspace.
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Kyungmin Park
---
drivers/power/Kconfig|7 +
drivers/power/Makefile |1 +
drivers/power/max14577_charger.c | 323 ++
3 files changed, 331 insertions(+)
create mode 100644 drivers/power/max14577_charger.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 5e2054a..9b6d466 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -316,6 +316,13 @@ config CHARGER_MANAGER
runtime and in suspend-to-RAM by waking up the system periodically
with help of suspend_again support.
+config CHARGER_MAX14577
+ tristate "Maxim MAX14577 MUIC battery charger driver"
+ depends on MFD_MAX14577
+ help
+ Say Y to enable support for the battery charger control sysfs and
+ platform data of MAX14577 MUICs.
+
config CHARGER_MAX8997
tristate "Maxim MAX8997/MAX8966 PMIC battery charger driver"
depends on MFD_MAX8997 && REGULATOR_MAX8997
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 372b4e8..ee54a3e 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_CHARGER_LP8727) += lp8727_charger.o
obj-$(CONFIG_CHARGER_LP8788) += lp8788-charger.o
obj-$(CONFIG_CHARGER_GPIO) += gpio-charger.o
obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o
+obj-$(CONFIG_CHARGER_MAX14577) += max14577_charger.o
obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o
obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o
obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o
diff --git a/drivers/power/max14577_charger.c b/drivers/power/max14577_charger.c
new file mode 100644
index 000..b364c6e
--- /dev/null
+++ b/drivers/power/max14577_charger.c
@@ -0,0 +1,323 @@
+/*
+ * max14577_charger.c - Battery charger driver for the Maxim 14577
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Krzysztof Kozlowski
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+
+struct max14577_charger {
+ struct device *dev;
+ struct max14577 *max14577;
+ struct power_supply charger;
+
+ unsigned intcharging_state;
+ unsigned intbattery_state;
+};
+
+static int max14577_get_charger_state(struct max14577_charger *chg)
+{
+ struct regmap *rmap = chg->max14577->regmap;
+ int state = POWER_SUPPLY_STATUS_DISCHARGING;
+ u8 reg_data;
+
+ /*
+* Charging occurs only if:
+* - CHGCTRL2/MBCHOSTEN == 1
+* - STATUS2/CGMBC == 1
+*
+* TODO:
+* - handle FULL after Top-off timer (EOC register may be off
+*and the charger won't be charging although MBCHOSTEN is on)
+* - handle properly dead-battery charging (respect timer)
+* - handle timers (fast-charge and prequal) /MBCCHGERR/
+*/
+ max14577_read_reg(rmap, MAX14577_CHG_REG_CHG_CTRL2, _data);
+ if ((reg_data & CHGCTRL2_MBCHOSTEN_MASK) == 0)
+ goto state_set;
+
+ max14577_read_reg(rmap, MAX14577_CHG_REG_STATUS3, _data);
+ if (reg_data & STATUS3_CGMBC_MASK) {
+ /* Charger or USB-cable is connected */
+ if (reg_data & STATUS3_EOC_MASK)
+ state = POWER_SUPPLY_STATUS_FULL;
+ else
+ state = POWER_SUPPLY_STATUS_CHARGING;
+ goto state_set;
+ }
+
+state_set:
+ chg->charging_state = state;
+ return state;
+}
+
+/*
+ * Supported charge types:
+ * - POWER_SUPPLY_CHARGE_TYPE_NONE
+ * - POWER_SUPPLY_CHARGE_TYPE_FAST
+ */
+static int max14577_get_charge_type(struct max14577_charger *chg)
+{
+ /*
+* TODO: CHARGE_TYPE_TRICKLE (VCHGR_RC or EOC)?
+* As spec says:
+* [after reaching EOC interrupt]
+* "When the battery is fully charged, the 30-minute (typ)
+* top-off timer starts. The device continues to trickle
+* charge the battery until the top-off timer runs out."
+*/
+ if (max14577_get_charger_state(chg) == POWER_SUPPLY_STATUS_CHARGING)
+ return POWER_SUPPLY_CHARGE_TYPE_FAST;
+ return POWER_SUPPLY_CHARGE_TYPE_NONE;
+}
+
+static int
Re: [PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio
On Monday 18 November 2013 04:18 PM, Linus Walleij wrote: > On Tue, Nov 12, 2013 at 7:18 AM, Sekhar Nori wrote: >> On Friday 08 November 2013 12:15 PM, Prabhakar Lad wrote: >>> From: "Lad, Prabhakar" >>> >>> This patch fixes a check for offset in gpio_to_irq_unbanked() >>> and also assigns gpio_irq, gpio_unbanked of chips[0] to >>> appropriate values which is used in gpio_to_irq_unbanked() >>> function. >>> >>> Reported-by: Grygorii Strashko >>> Signed-off-by: Lad, Prabhakar >> >> You should note explicitly that this patch fixes broken unbanked IRQ >> support. You mostly just described what you are doing. >> >> I will fixup while committing. > > So you're carrying this patch Sekhar? Yes, and I would have sent this for upstream already if not for I going under the weather a bit past couple of days. Thanks, Sekhar -- 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/
