[PATCH] watchdog: Add Broadcom BCM2708 watchdog timer driver
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Wim Van Sebroeck w...@iguana.be
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-watch...@vger.kernel.org
---
arch/arm/configs/bcm2835_defconfig |4 +
drivers/watchdog/Kconfig | 11 +++
drivers/watchdog/Makefile |1 +
drivers/watchdog/bcm2835_wdt.c | 158
4 files changed, 174 insertions(+), 0 deletions(-)
create mode 100644 drivers/watchdog/bcm2835_wdt.c
diff --git a/arch/arm/configs/bcm2835_defconfig
b/arch/arm/configs/bcm2835_defconfig
index 611bda2..8f1547a 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -67,6 +67,10 @@ CONFIG_I2C_BCM2835=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HWMON is not set
# CONFIG_USB_SUPPORT is not set
+CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_BCM2835_WDT=y
+
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9fcc70c..f4e4a8e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1098,6 +1098,17 @@ config BCM63XX_WDT
To compile this driver as a loadable module, choose M here.
The module will be called bcm63xx_wdt.
+config BCM2835_WDT
+ tristate Broadcom BCM2835 hardware watchdog
+ depends on ARCH_BCM2835
+ select WATCHDOG_CORE
+ help
+ Watchdog driver for the built in watchdog hardware in Broadcom
+ BCM2835 SoC.
+
+ To compile this driver as a loadable module, choose M here.
+ The module will be called bcm2835_wdt.
+
config LANTIQ_WDT
tristate Lantiq SoC watchdog
depends on LANTIQ
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a300b94..1bf5675 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
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
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 000..834f201
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,158 @@
+/*
+ * Watchdog driver for Broadcom BCM2835
+ *
+ * Copyright (C) 2013 Lubomir Rintel lkund...@v3.sk
+ *
+ * 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.
+ */
+
+#include linux/types.h
+#include linux/module.h
+#include linux/io.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+#include linux/of_address.h
+#include linux/miscdevice.h
+
+#define PM_RSTC0x1c
+#define PM_RSTS0x20
+#define PM_WDOG0x24
+
+#define PM_PASSWORD0x5a00
+#define PM_RSTC_WRCFG_MASK 0x0030
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTS_HADWRH_SET 0x0040
+
+#define PM_WDOG_TIME_SET 0x000f
+#define PM_RSTC_WRCFG_CLR 0xffcf
+#define PM_RSTC_WRCFG_SET 0x0030
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTC_RESET 0x0102
+
+#define SECS_TO_WDOG_TICKS(x) ((x) 16)
+#define WDOG_TICKS_TO_SECS(x) ((x) 16)
+
+static int heartbeat = -1;
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static void __iomem *wdt_regs;
+static DEFINE_SPINLOCK(wdog_lock);
+
+static int bcm2835_wdt_start(struct watchdog_device *wdog)
+{
+ uint32_t cur;
+ unsigned long flags;
+
+ spin_lock_irqsave(wdog_lock, flags);
+
+ writel_relaxed(PM_PASSWORD | (SECS_TO_WDOG_TICKS(wdog-timeout)
+ PM_WDOG_TIME_SET), wdt_regs + PM_WDOG);
+ cur = readl_relaxed(wdt_regs + PM_RSTC);
+ writel_relaxed(PM_PASSWORD | (cur PM_RSTC_WRCFG_CLR) |
+ PM_RSTC_WRCFG_FULL_RESET, wdt_regs + PM_RSTC);
+
+ spin_unlock_irqrestore(wdog_lock, flags);
+
+ return 0;
+}
+
+static int bcm2835_wdt_stop(struct watchdog_device *wdog)
+{
+ writel_relaxed(PM_PASSWORD | PM_RSTC_RESET, wdt_regs + PM_RSTC);
+ dev_info(wdog-dev, Watchdog timer stopped);
+ return 0;
+}
+
+static int bcm2835_wdt_set_timeout(struct watchdog_device *wdog, unsigned int
t)
+{
+ wdog-timeout = t;
+ return 0;
+}
+
+static unsigned int bcm2835_wdt_get_timeleft(struct watchdog_device *wdog)
+{
+ uint32_t ret = readl_relaxed(wdt_regs + PM_WDOG);
+ return WDOG_TICKS_TO_SECS(ret PM_WDOG_TIME_SET);
+}
+
+static struct watchdog_ops bcm2835_wdt_ops = {
+ .owner
[PATCH] hw_random: Add Broadcom BCM2835 RNG Driver
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Matt Mackall m...@selenic.com
Cc: linux-rpi-ker...@lists.infradead.org
---
arch/arm/boot/dts/bcm2835.dtsi |5 +
arch/arm/configs/bcm2835_defconfig |3 +-
drivers/char/hw_random/Kconfig | 12 +++
drivers/char/hw_random/Makefile |1 +
drivers/char/hw_random/bcm2835-rng.c | 137 ++
5 files changed, 157 insertions(+), 1 deletions(-)
create mode 100644 drivers/char/hw_random/bcm2835-rng.c
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 7e0481e..dc22336 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -34,6 +34,11 @@
reg = 0x7e10 0x28;
};
+ rng {
+ compatible = brcm,bcm2835-rng;
+ reg = 0x7e104000 0x10;
+ };
+
uart@20201000 {
compatible = brcm,bcm2835-pl011, arm,pl011,
arm,primecell;
reg = 0x7e201000 0x1000;
diff --git a/arch/arm/configs/bcm2835_defconfig
b/arch/arm/configs/bcm2835_defconfig
index af472e4..611bda2 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -59,7 +59,8 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_TTY_PRINTK=y
-# CONFIG_HW_RANDOM is not set
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_BCM2835=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_BCM2835=y
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index c5a0262..2f9dbf7 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -86,6 +86,18 @@ config HW_RANDOM_BCM63XX
If unusure, say Y.
+config HW_RANDOM_BCM2835
+ tristate Broadcom BCM2835 Random Number Generator support
+ depends on HW_RANDOM ARCH_BCM2835
+ default HW_RANDOM
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on the Broadcom BCM2835 SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bcm2835-rng
+
+ If unsure, say Y.
config HW_RANDOM_GEODE
tristate AMD Geode HW Random Number Generator support
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 1fd7eec..bed467c 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -26,3 +26,4 @@ obj-$(CONFIG_HW_RANDOM_PPC4XX) += ppc4xx-rng.o
obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-rng.o
obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
+obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
diff --git a/drivers/char/hw_random/bcm2835-rng.c
b/drivers/char/hw_random/bcm2835-rng.c
new file mode 100644
index 000..66adc7f
--- /dev/null
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -0,0 +1,137 @@
+/**
+ * Copyright (c) 2010-2012 Broadcom. All rights reserved.
+ * Copyright (c) 2013 Lubomir Rintel
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) version 2, as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS
+ * IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include linux/hw_random.h
+#include linux/init.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include
[PATCH] of: add managed version of of_iomap()
This introduces a routine devm_of_iomap(), which acts exactly like of_iomap()
apart from that managed deivce resource subsystem takes care of reclaiming the
resources wherever appropriate.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: Guenter Roeck li...@roeck-us.net
Reference:
http://lists.infradead.org/pipermail/linux-rpi-kernel/2013-March/000461.html
---
Documentation/driver-model/devres.txt |1 +
drivers/of/address.c | 21 -
include/linux/of_address.h| 11 +++
3 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index b467145..e9f8bc3 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -268,6 +268,7 @@ IOMAP
devm_iounmap()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
devm_request_and_ioremap() : obsoleted by devm_ioremap_resource()
+ devm_of_iomap()
pcim_iomap()
pcim_iounmap()
pcim_iomap_table() : array of mapped addresses indexed by BAR
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..b52d7f6 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -629,7 +629,6 @@ struct device_node *of_find_matching_node_by_address(struct
device_node *from,
return NULL;
}
-
/**
* of_iomap - Maps the memory mapped IO for a given device_node
* @device:the device whose io range will be mapped
@@ -647,3 +646,23 @@ void __iomem *of_iomap(struct device_node *np, int index)
return ioremap(res.start, resource_size(res));
}
EXPORT_SYMBOL(of_iomap);
+
+/**
+ * devm_of_iomap - Managed of_iomap()
+ * @dev: generic device to map range for
+ * @np:the device node whose io range will be mapped
+ * @index: index of the io range
+ *
+ * Returns a pointer to the mapped memory
+ */
+void __iomem *devm_of_iomap(struct device *dev, struct device_node *np,
+ int index)
+{
+ struct resource res;
+
+ if (of_address_to_resource(np, index, res))
+ return NULL;
+
+ return devm_ioremap(dev, res.start, resource_size(res));
+}
+EXPORT_SYMBOL(devm_of_iomap);
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..6c6f71f 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -14,6 +14,9 @@ extern struct device_node *of_find_matching_node_by_address(
const struct of_device_id *matches,
u64 base_address);
extern void __iomem *of_iomap(struct device_node *device, int index);
+extern void __iomem *devm_of_iomap(struct device *dev,
+ struct device_node *device,
+ int index);
/* Extract an address from a device, returns the region size and
* the address space flags too. The PCI version uses a BAR number
@@ -48,6 +51,14 @@ static inline void __iomem *of_iomap(struct device_node
*device, int index)
return NULL;
}
#endif
+#ifndef devm_of_iomap
+static inline void __iomem *devm_of_iomap(struct device *dev,
+ struct device_node *device,
+ int index);
+{
+ return NULL;
+}
+#endif
static inline const __be32 *of_get_address(struct device_node *dev, int index,
u64 *size, unsigned int *flags)
{
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: watchdog: Add Broadcom BCM2708 watchdog timer driver
On Fri, 2013-03-22 at 06:56 -0700, Guenter Roeck wrote:
Thank you for your response!
On Fri Mar 22 09:56:01 EDT 2013, Guenter Roeck wrote:
On Fri, Mar 22, 2013 at 12:55:07PM -, Lubomir Rintel wrote:
...
+ writel_relaxed(PM_PASSWORD | (cur PM_RSTC_WRCFG_CLR) |
+ PM_RSTC_WRCFG_FULL_RESET, wdt_regs + PM_RSTC);
+
Nitpick - I prefer people to use the recommended continuation line style,
but that is really up to the maintainer to decide.
Well, I intended to comply with Documentation/CodingStyle, are you referring to
it? I fail to understand what to do to be more compliant and could not really
identify a style that would be consistently used across the kernel source.
Should I cut then second line into two smaller parts that would be aligned with
right line end?
...
+static int bcm2835_wdt_set_timeout(struct watchdog_device *wdog, unsigned
int t)
+{
+ wdog-timeout = t;
No need to update the actual chip timeout ?
No need to, watchdog core applies the new timeout by pinging the device (see
below for what happens when this driver is pinged).
See: WDIOC_SETTIMEOUT in drivers/watchdog/watchdog_dev.c
...
+static struct watchdog_ops bcm2835_wdt_ops = {
+ .owner =THIS_MODULE,
+ .start =bcm2835_wdt_start,
+ .stop = bcm2835_wdt_stop,
+ .set_timeout = bcm2835_wdt_set_timeout,
+ .get_timeleft = bcm2835_wdt_get_timeleft,
No separate ping function ?
The watchdog documentation core states:
Most hardware that does not support this as a separate function uses the
start function to restart the watchdog timer hardware. And that's also what
the watchdog timer driver core does.
This indeed applies to this driver.
...
+ if (WARN(!wdt_regs, failed to remap watchdog regs))
+ return -ENODEV;
WARN seems to be a bit extreme. Is this necessary ?
Probably not. I'll replace it with dev_err() instead.
+ dev_info(dev, Broadcom BCM2835 watchdog timer);
+
+ watchdog_init_timeout(bcm2835_wdt_wdd, heartbeat, dev);
Since heartbeat is by default set to -1, which is interpreted as unsigned
int, I would expect this call to return -EINVAL, leaving the default timeout
undefined. Is this really what you want ?
Well, I looked into orion-wdt for an example how to initialize the default
timeout, but failed to understand it correctly. I thought that watchdog core
picks a sensible value upon getting -1, which is incorrect. They in fact use
initialize timeout with maximal value, and use a fall-through vi EINVAL to
leave
it untouched if it was not overridden. I'll do the same thing now.
+ watchdog_set_nowayout(bcm2835_wdt_wdd, nowayout);
+ return watchdog_register_device(bcm2835_wdt_wdd);
Leaking iomap if this fails.
Oops. Fixing.
Would be nice to have something like devm_of_iomap ...
That sounds sound to me. Sent out a separate patch implementing it, and I'll
modify this if it gets merged.
--
Lubomir Rintel lkund...@v3.sk
--
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] watchdog: Add Broadcom BCM2708 watchdog timer driver
On Fri, 2013-03-22 at 19:46 +0100, Arend van Spriel wrote: Thanks for your response! On 03/22/2013 01:55 PM, Lubomir Rintel wrote: Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Stephen Warren swar...@wwwdotorg.org Cc: Wim Van Sebroeck w...@iguana.be Cc: linux-rpi-ker...@lists.infradead.org Cc: linux-watch...@vger.kernel.org --- arch/arm/configs/bcm2835_defconfig |4 + drivers/watchdog/Kconfig | 11 +++ drivers/watchdog/Makefile |1 + drivers/watchdog/bcm2835_wdt.c | 158 4 files changed, 174 insertions(+), 0 deletions(-) create mode 100644 drivers/watchdog/bcm2835_wdt.c Seems like the subject line of the patch is wrong. Otherwise the commit message should be a little, tiny bit longer explainer how bcm2708 is related to bcm2835. Good catch -- it indeed is wrong. It's probably still a good idea to have a more descriptive commit message. I'll fix that up in next revision. -- Lubomir Rintel lkund...@v3.sk -- 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] watchdog: Add Broadcom BCM2708 watchdog timer driver
On Fri, 2013-03-22 at 20:24 -0600, Stephen Warren wrote:
Thank you for your response!
On 03/22/2013 06:55 AM, Lubomir Rintel wrote:
Signed-off-by: Lubomir Rintel lkundrak at v3.sk
A commit description would be useful.
I'll add a more descriptive one in next patch revision.
arch/arm/configs/bcm2835_defconfig |4 +
drivers/watchdog/Kconfig | 11 +++
drivers/watchdog/Makefile |1 +
drivers/watchdog/bcm2835_wdt.c | 158
The changes to bcm2835_defconfig should be a separate patch, since they
would be applied in the BCM2835 ARM sub-arch tree, whereas the driver
patch would be applied to the watchdog driver tree.
Okay, makes sense to me.
diff --git a/arch/arm/configs/bcm2835_defconfig
b/arch/arm/configs/bcm2835_defconfig
+CONFIG_BCM2835_WDT=y
+
CONFIG_MMC=y
That blank line is a little odd; was this defconfig change created using
make savedefconfig?
No, I did not notice that the savedefconfig exists and modified the defconfig
by hand. I'll use it for next patch revision.
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
+static int heartbeat = -1;
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static void __iomem *wdt_regs;
+static DEFINE_SPINLOCK(wdog_lock);
Can these be stored in a dynamically-allocated structure, stored in the
device's drvdata?
Well, not hearbeat and nowayout, those are module parameters.
The other ones make perfect sense, I've attempted to use a per-device
dynamically-allocated structure for those.
+static struct platform_driver bcm2835_wdt_driver = {
...
+};
+
+module_platform_driver(bcm2835_wdt_driver);
I believe it's typical not to leave a blank line before
module_platform_driver();
Okay.
A couple of general comments:
1)
This driver touches the same registers that
arch/arm/mach-bcm2835/bcm2835.c uses to implement reboot and power
off. Some co-ordination might be necessary.
The implementation of bcm2835_power_off() could easily be moved into
this driver, to avoid some of the need for co-ordination.
Moving bcm2835_restart() would be more tricky, since the ARM machine
descriptor needs a pointer to that function. I guess the kernel probably
ensures that none of the code in this watchdog driver is running by the
time bcm2835_restart() is called, although perhaps it'd be better to
have mach-bcm2835/bcm2835.c and this driver share a lock?
I need help here, I'm not sure what's the proper way to address this
(whether to include the actual reboot code in the wdt driver or the
platform driver).
Is it okay to have the platform driver depend on watchdog timer?
Is it okay for the platform driver not to reboot properly if the kernel
is running without the wdt driver loaded?
(For now, I'll send a revised patch addressing the other issues so that
it can be reviewed without addressing this yet.)
2)
I'm curious where you got the documentation to write this driver; this
HW module isn't described in BCM2835-ARM-Peripherals.pdf. I assume this
is based on the downstream kernel driver? If so, at least some credit in
the commit description might be appropriate. At least the relevant
commit downstream already has an appropriate Signed-off-by line:-)
Your guess is right, used bcm2708_wdog driver from rpi-3.6.y as a reference.
I'll add that information to the commit message.
The Signed-off-by line is indeed present, but unfortunately does not seem to be
particularly appropriate:
Signed-off-by: popcornmix popcorn...@gmail.com
I'm wondering if it's actually relevant, since the useful bits of the
downstream driver boil down to macro defines.
Have a nice day!
--
Lubomir Rintel lkund...@v3.sk
--
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] watchdog: Add Broadcom BCM2835 watchdog timer driver
This adds a driver for watchdog timer hardware present on Broadcom BCM2835 SoC,
used in Raspberry Pi and Roku 2 devices.
Interface to the Broadcom BCM2835 watchdog timer hardware is based on
bcm2708_wdog driver written by Luke Diamand that was obtained from branch
rpi-3.6.y of git://github.com/raspberrypi/linux.git
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Wim Van Sebroeck w...@iguana.be
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-watch...@vger.kernel.org
---
Changes for v2:
- Use per-device structure instead of global variables for lock and memory
base
- Fix default timeout setting
- Do not leak memory if probe fails
- Style fixes
- Split out defconfig into a separate commit
- Meaningful commit message with credit
.../bindings/watchdog/brcm,bcm2835-pm-wdog.txt |5 +
drivers/watchdog/Kconfig | 11 ++
drivers/watchdog/Makefile |1 +
drivers/watchdog/bcm2835_wdt.c | 189
4 files changed, 206 insertions(+), 0 deletions(-)
create mode 100644 drivers/watchdog/bcm2835_wdt.c
diff --git
a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
index d209366..f801d71 100644
--- a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
@@ -5,9 +5,14 @@ Required properties:
- compatible : should be brcm,bcm2835-pm-wdt
- reg : Specifies base physical address and size of the registers.
+Optional properties:
+
+- timeout-sec : Contains the watchdog timeout in seconds
+
Example:
watchdog {
compatible = brcm,bcm2835-pm-wdt;
reg = 0x7e10 0x28;
+ timeout-sec = 10;
};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9fcc70c..f4e4a8e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1098,6 +1098,17 @@ config BCM63XX_WDT
To compile this driver as a loadable module, choose M here.
The module will be called bcm63xx_wdt.
+config BCM2835_WDT
+ tristate Broadcom BCM2835 hardware watchdog
+ depends on ARCH_BCM2835
+ select WATCHDOG_CORE
+ help
+ Watchdog driver for the built in watchdog hardware in Broadcom
+ BCM2835 SoC.
+
+ To compile this driver as a loadable module, choose M here.
+ The module will be called bcm2835_wdt.
+
config LANTIQ_WDT
tristate Lantiq SoC watchdog
depends on LANTIQ
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a300b94..1bf5675 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
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
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 000..3899638
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,189 @@
+/*
+ * Watchdog driver for Broadcom BCM2835
+ *
+ * Copyright (C) 2013 Lubomir Rintel lkund...@v3.sk
+ *
+ * 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.
+ */
+
+#include linux/types.h
+#include linux/module.h
+#include linux/io.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+#include linux/of_address.h
+#include linux/miscdevice.h
+
+#define PM_RSTC0x1c
+#define PM_RSTS0x20
+#define PM_WDOG0x24
+
+#define PM_PASSWORD0x5a00
+#define PM_RSTC_WRCFG_MASK 0x0030
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTS_HADWRH_SET 0x0040
+
+#define PM_WDOG_TIME_SET 0x000f
+#define PM_RSTC_WRCFG_CLR 0xffcf
+#define PM_RSTC_WRCFG_SET 0x0030
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTC_RESET 0x0102
+
+#define SECS_TO_WDOG_TICKS(x) ((x) 16)
+#define WDOG_TICKS_TO_SECS(x) ((x) 16)
+
+struct bcm2835_wdt {
+ void __iomem*base;
+ spinlock_t lock;
+};
+
+static int heartbeat = -1;
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+static int bcm2835_wdt_start(struct watchdog_device *wdog)
+{
+ struct bcm2835_wdt *wdt = watchdog_get_drvdata(wdog);
+ uint32_t cur;
+ unsigned long flags;
+
+ spin_lock_irqsave(wdt-lock, flags);
+
+ writel_relaxed
[PATCH v2] arm: Add Broadcom BCM2835 watchdog timer driver to bcm2835_defconfig
This enables a driver for watchdog timer hardware present on Broadcom BCM2835 SoC, used in Raspberry Pi and Roku 2 devices. Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Stephen Warren swar...@wwwdotorg.org Cc: linux-rpi-ker...@lists.infradead.org --- Changes for v2: - Split out from the driver changeset - Regenerated with savedefconfig arch/arm/configs/bcm2835_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig index 611bda2..729adf2 100644 --- a/arch/arm/configs/bcm2835_defconfig +++ b/arch/arm/configs/bcm2835_defconfig @@ -66,6 +66,8 @@ CONFIG_I2C_CHARDEV=y CONFIG_I2C_BCM2835=y CONFIG_GPIO_SYSFS=y # CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +CONFIG_BCM2835_WDT=y # CONFIG_USB_SUPPORT is not set CONFIG_MMC=y CONFIG_MMC_SDHCI=y -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] bcm2835: Add Broadcom BCM2835 RNG to the device tree
This adds a device tree binding for random number generator present on Broadcom
BCM2835 SoC, used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: linux-rpi-ker...@lists.infradead.org
---
Changes for v2:
- Split out from the driver changeset
- Added documentation
.../devicetree/bindings/rng/brcm,bcm2835.txt | 13 +
arch/arm/boot/dts/bcm2835.dtsi |5 +
2 files changed, 18 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
new file mode 100644
index 000..07ccdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
@@ -0,0 +1,13 @@
+BCM2835 Random number generator
+
+Required properties:
+
+- compatible : should be brcm,bcm2835-rng
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+rng {
+compatible = brcm,bcm2835-rng;
+reg = 0x7e104000 0x10;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 7e0481e..dc22336 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -34,6 +34,11 @@
reg = 0x7e10 0x28;
};
+ rng {
+ compatible = brcm,bcm2835-rng;
+ reg = 0x7e104000 0x10;
+ };
+
uart@20201000 {
compatible = brcm,bcm2835-pl011, arm,pl011,
arm,primecell;
reg = 0x7e201000 0x1000;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hw_random: Add Broadcom BCM2835 RNG Driver
On Fri, 2013-03-22 at 20:44 -0600, Stephen Warren wrote:
Thank you for your response!
On 03/22/2013 06:55 AM, Lubomir Rintel wrote:
Signed-off-by: Lubomir Rintel lkundrak at v3.sk
A commit description would be useful.
arch/arm/boot/dts/bcm2835.dtsi |5 +
arch/arm/configs/bcm2835_defconfig |3 +-
drivers/char/hw_random/Kconfig | 12 +++
drivers/char/hw_random/Makefile |1 +
drivers/char/hw_random/bcm2835-rng.c | 137
++
This should be split into 3 separate patches: (1) The driver itself, (2)
the change to bcm2835.dtsi, and (3) the change to bcm2835_defconfig.
Since you're adding a new device to device tree for the first time, you
should write a binding document for it; most likely
Documentation/devicetree/bindings/rng/brcm,bcm2835.txt (or perhaps
/random/ rather than /rng/?)
Okay. I'm tempted to stick to rng instead of random as it seems more
consistent to me, but I don't have a strong reason to back it with. What would
be a good reason for using random?
Is this driver based on the downstream Raspberry Pi kernel's driver? If
so, some mention of that fact would be appropriate in the commit
description, or even the git author field. I note that in the downstream
kernel, the commit which adds the RNG driver isn't signed off at all.
This probably means you need to get Dom to add his signed-off-by line
for that commit before basing your work on it. See
Documentation/SubmittingPatches for more details.
Ok, will try to.
I'll still follow up with an updated patch, so that it can be reviewed.
diff --git a/drivers/char/hw_random/bcm2835-rng.c
b/drivers/char/hw_random/bcm2835-rng.c
+ * Redistribution and use in source and binary forms, with or without
...
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) version 2, as published by the Free
+ * Software Foundation.
I am not a lawyer, but I'd be tempted to exercise that right, and
distribute this patch solely under the terms of the GPLv2, and hence
remove the other license. It's not a big deal, but it'd simplify the
licensing in the upstream kernel.
Will do.
+static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+ while ((__raw_readl(rng_base + RNG_STATUS)24) == 0) {
You'd usually put spaces around the .
Will be fixed.
+static int bcm2835_rng_probe(struct platform_device *op)
pdev is a more typical name than op.
Will be adjusted.
+{
+ struct device *dev = op-dev;
+ struct device_node *np = dev-of_node;
+ void __iomem *rng_base;
+ int err;
+
+ /* map peripheral */
+ rng_base = of_iomap(np, 0);
+ if (WARN(!rng_base, failed to remap rng regs))
+ return -ENODEV;
The WARN() doesn't seem necessary. dev_err() inside the if{} would be
more appropriate,
Makes sense, will be adjusted.
+static struct platform_driver bcm2835_rng_driver = {
...
+};
+
+module_platform_driver(bcm2835_rng_driver);
Typically, no blank line there.
Ok
+MODULE_AUTHOR(Lubomir Rintel lkundrak at v3.sk);
+MODULE_DESCRIPTION(BCM2835 Random Number Generator (RNG) driver);
+MODULE_LICENSE(GPL and additional rights);
I think that should be GPLv2 and
Ok
--
Lubomir Rintel lkund...@v3.sk
--
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] hw_random: Add Broadcom BCM2835 RNG driver
This adds a driver for random number generator present on Broadcom BCM2835 SoC,
used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Matt Mackall m...@selenic.com
Cc: linux-rpi-ker...@lists.infradead.org
---
Changes for v2:
- Device tree and defconfig changes split out
- Licence changed from GPLv2+BSD to GPLv2 only
- Style fixes
drivers/char/hw_random/Kconfig | 12
drivers/char/hw_random/Makefile |1 +
drivers/char/hw_random/bcm2835-rng.c | 113 ++
3 files changed, 126 insertions(+), 0 deletions(-)
create mode 100644 drivers/char/hw_random/bcm2835-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index c5a0262..2f9dbf7 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -86,6 +86,18 @@ config HW_RANDOM_BCM63XX
If unusure, say Y.
+config HW_RANDOM_BCM2835
+ tristate Broadcom BCM2835 Random Number Generator support
+ depends on HW_RANDOM ARCH_BCM2835
+ default HW_RANDOM
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on the Broadcom BCM2835 SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bcm2835-rng
+
+ If unsure, say Y.
config HW_RANDOM_GEODE
tristate AMD Geode HW Random Number Generator support
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 1fd7eec..bed467c 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -26,3 +26,4 @@ obj-$(CONFIG_HW_RANDOM_PPC4XX) += ppc4xx-rng.o
obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-rng.o
obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
+obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
diff --git a/drivers/char/hw_random/bcm2835-rng.c
b/drivers/char/hw_random/bcm2835-rng.c
new file mode 100644
index 000..eb7f147
--- /dev/null
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -0,0 +1,113 @@
+/**
+ * Copyright (c) 2010-2012 Broadcom. All rights reserved.
+ * Copyright (c) 2013 Lubomir Rintel
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License (GPL)
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include linux/hw_random.h
+#include linux/init.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/printk.h
+
+#define RNG_CTRL 0x0
+#define RNG_STATUS 0x4
+#define RNG_DATA 0x8
+
+/* enable rng */
+#define RNG_RBGEN 0x1
+
+/* the initial numbers generated are less random so will be discarded */
+#define RNG_WARMUP_COUNT 0x4
+
+static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+{
+ void __iomem *rng_base = (void __iomem *)rng-priv;
+
+ while ((__raw_readl(rng_base + RNG_STATUS) 24) == 0) {
+ if (!wait)
+ return 0;
+ cpu_relax();
+ }
+
+ *(u32 *)buf = __raw_readl(rng_base + RNG_DATA);
+ return sizeof(u32);
+}
+
+static struct hwrng bcm2835_rng_ops = {
+ .name = bcm2835,
+ .read = bcm2835_rng_read,
+};
+
+static int bcm2835_rng_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct device_node *np = dev-of_node;
+ void __iomem *rng_base;
+ int err;
+
+ /* map peripheral */
+ rng_base = of_iomap(np, 0);
+ if (!rng_base) {
+ dev_err(dev, failed to remap rng regs);
+ return -ENODEV;
+ }
+ bcm2835_rng_ops.priv = (unsigned long)rng_base;
+
+ /* register driver */
+ err = hwrng_register(bcm2835_rng_ops);
+ if (err) {
+ dev_err(dev, hwrng registration failed\n);
+ iounmap(rng_base);
+ } else {
+ dev_info(dev, hwrng registered\n);
+
+ /* set warm-up count enable */
+ __raw_writel(RNG_WARMUP_COUNT, rng_base + RNG_STATUS);
+ __raw_writel(RNG_RBGEN, rng_base + RNG_CTRL);
+ }
+ return err;
+}
+
+static int bcm2835_rng_remove(struct platform_device *pdev)
+{
+ void __iomem *rng_base = (void __iomem *)bcm2835_rng_ops.priv;
+
+ /* disable rng hardware */
+ __raw_writel(0, rng_base + RNG_CTRL);
+
+ /* unregister driver */
+ hwrng_unregister(bcm2835_rng_ops);
+ iounmap(rng_base);
+
+ return 0;
+}
+
+static const struct of_device_id bcm2835_rng_of_match[] = {
+ { .compatible = brcm,bcm2835-rng, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, bcm2835_rng_of_match);
+
+static struct platform_driver bcm2835_rng_driver
[PATCH v2] arm: Add Broadcom BCM2835 RNG driver to bcm2835_defconfig
This enables a driver for random number generator present on Broadcom BCM2835 SoC, used in Raspberry Pi and Roku 2 devices. Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Stephen Warren swar...@wwwdotorg.org Cc: linux-rpi-ker...@lists.infradead.org --- Changes for v2: - Split out from the driver changeset arch/arm/configs/bcm2835_defconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig index af472e4..611bda2 100644 --- a/arch/arm/configs/bcm2835_defconfig +++ b/arch/arm/configs/bcm2835_defconfig @@ -59,7 +59,8 @@ CONFIG_DEVTMPFS_MOUNT=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_TTY_PRINTK=y -# CONFIG_HW_RANDOM is not set +CONFIG_HW_RANDOM=y +CONFIG_HW_RANDOM_BCM2835=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_BCM2835=y -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] watchdog: Add Broadcom BCM2835 watchdog timer driver
On Sun, 2013-03-24 at 09:12 -0700, Guenter Roeck wrote:
On Sun, Mar 24, 2013 at 03:22:53PM +0100, Lubomir Rintel wrote:
This adds a driver for watchdog timer hardware present on Broadcom BCM2835
SoC,
used in Raspberry Pi and Roku 2 devices.
Interface to the Broadcom BCM2835 watchdog timer hardware is based on
bcm2708_wdog driver written by Luke Diamand that was obtained from branch
rpi-3.6.y of git://github.com/raspberrypi/linux.git
I would suggest to put that into the coments at the top of the driver.
Also, if the original code has a copyright statement, you might want
to copy that.
Okay.
+#include linux/miscdevice.h
Just noticed - you should not need that include.
Well, I think the bottommost line of the driver uses that and it's a
good practice to provide a device number alias. Is that one completely
useless?
MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
+#define PM_RSTS0x20
Not used
Dropped.
+#define PM_RSTC_WRCFG_MASK 0x0030
Not used
Dropped.
+#define PM_RSTS_HADWRH_SET 0x0040
Not used
Dropped.
+#define PM_RSTC_WRCFG_SET 0x0030
Not used
Dropped.
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
Defined twice
Extra occurrence dropped.
+#define PM_RSTC_RESET 0x0102
+
+#define SECS_TO_WDOG_TICKS(x) ((x) 16)
+#define WDOG_TICKS_TO_SECS(x) ((x) 16)
+
+struct bcm2835_wdt {
+ void __iomem*base;
+ spinlock_t lock;
+};
+
+static int heartbeat = -1;
The parameter passed to watchdog_init_timeout is an unsigned int, so you
should
really use an unsigned int here. Depending on -1 being converted to maxuint
is a
bit of side effect programming. Easier to just set it to 0, which the watchdog
core interprets as invalid as well.
Done.
+ dev_info(dev, Broadcom BCM2835 watchdog timer);
+
I think this should come later, after you are sure that there will be
no failure.
Moved.
+ platform_set_drvdata(pdev, NULL);
It is unnecessary to set this to NULL (the infrastructure does it for you).
Okay.
I've seen this being done on way too many places. I've really should
have checked that though.
Thank you for your response, I'll submit an updated revision shortly.
--
Lubomir Rintel lkund...@v3.sk
--
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] bcm2835: Add Broadcom BCM2835 RNG to the device tree
This adds a device tree binding for random number generator present on Broadcom
BCM2835 SoC, used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: linux-rpi-ker...@lists.infradead.org
---
Changes for v2:
- Split out from the driver changeset
- Added documentation
.../devicetree/bindings/rng/brcm,bcm2835.txt | 13 +
arch/arm/boot/dts/bcm2835.dtsi |5 +
2 files changed, 18 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
new file mode 100644
index 000..07ccdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
@@ -0,0 +1,13 @@
+BCM2835 Random number generator
+
+Required properties:
+
+- compatible : should be brcm,bcm2835-rng
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+rng {
+compatible = brcm,bcm2835-rng;
+reg = 0x7e104000 0x10;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 7e0481e..dc22336 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -34,6 +34,11 @@
reg = 0x7e10 0x28;
};
+ rng {
+ compatible = brcm,bcm2835-rng;
+ reg = 0x7e104000 0x10;
+ };
+
uart@20201000 {
compatible = brcm,bcm2835-pl011, arm,pl011,
arm,primecell;
reg = 0x7e201000 0x1000;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] watchdog: Add Broadcom BCM2835 watchdog timer driver
This adds a driver for watchdog timer hardware present on Broadcom BCM2835 SoC,
used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Wim Van Sebroeck w...@iguana.be
Cc: Guenter Roeck li...@roeck-us.net
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-watch...@vger.kernel.org
---
Changes for v2:
- Use per-device structure instead of global variables for lock and memory
base
- Fix default timeout setting
- Do not leak memory if probe fails
- Style fixes
- Split out defconfig into a separate commit
- Meaningful commit message with credit
Changes for v3:
- Add proper copyright notice to header
- Drop status constants, we don't use them
- Fix heartbeat parameter's type
- Log driver initialization message once the device is probed
.../bindings/watchdog/brcm,bcm2835-pm-wdog.txt |5 +
drivers/watchdog/Kconfig | 11 ++
drivers/watchdog/Makefile |1 +
drivers/watchdog/bcm2835_wdt.c | 190
4 files changed, 207 insertions(+), 0 deletions(-)
create mode 100644 drivers/watchdog/bcm2835_wdt.c
diff --git
a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
index d209366..f801d71 100644
--- a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
@@ -5,9 +5,14 @@ Required properties:
- compatible : should be brcm,bcm2835-pm-wdt
- reg : Specifies base physical address and size of the registers.
+Optional properties:
+
+- timeout-sec : Contains the watchdog timeout in seconds
+
Example:
watchdog {
compatible = brcm,bcm2835-pm-wdt;
reg = 0x7e10 0x28;
+ timeout-sec = 10;
};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9fcc70c..f4e4a8e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1098,6 +1098,17 @@ config BCM63XX_WDT
To compile this driver as a loadable module, choose M here.
The module will be called bcm63xx_wdt.
+config BCM2835_WDT
+ tristate Broadcom BCM2835 hardware watchdog
+ depends on ARCH_BCM2835
+ select WATCHDOG_CORE
+ help
+ Watchdog driver for the built in watchdog hardware in Broadcom
+ BCM2835 SoC.
+
+ To compile this driver as a loadable module, choose M here.
+ The module will be called bcm2835_wdt.
+
config LANTIQ_WDT
tristate Lantiq SoC watchdog
depends on LANTIQ
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a300b94..1bf5675 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
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
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 000..13a8c00
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,190 @@
+/*
+ * Watchdog driver for Broadcom BCM2835
+ *
+ * Interface to the Broadcom BCM2835 watchdog timer hardware is based on
+ * bcm2708_wdog driver written by Luke Diamand that was obtained from branch
+ * rpi-3.6.y of git://github.com/raspberrypi/linux.git
+ *
+ * (c) Copyright 2010 Broadcom Europe Ltd
+ * Copyright (C) 2013 Lubomir Rintel lkund...@v3.sk
+ *
+ * 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.
+ */
+
+#include linux/types.h
+#include linux/module.h
+#include linux/io.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+#include linux/of_address.h
+#include linux/miscdevice.h
+
+#define PM_RSTC0x1c
+#define PM_WDOG0x24
+
+#define PM_PASSWORD0x5a00
+
+#define PM_WDOG_TIME_SET 0x000f
+#define PM_RSTC_WRCFG_CLR 0xffcf
+#define PM_RSTC_WRCFG_SET 0x0030
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTC_RESET 0x0102
+
+#define SECS_TO_WDOG_TICKS(x) ((x) 16)
+#define WDOG_TICKS_TO_SECS(x) ((x) 16)
+
+struct bcm2835_wdt {
+ void __iomem*base;
+ spinlock_t lock;
+};
+
+static unsigned int heartbeat = 0;
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+static int bcm2835_wdt_start(struct watchdog_device *wdog)
+{
+ struct bcm2835_wdt *wdt = watchdog_get_drvdata(wdog);
+ uint32_t
Re: [PATCH v2] bcm2835: Add Broadcom BCM2835 RNG to the device tree
On Tue, 2013-03-26 at 18:48 +0100, Lubomir Rintel wrote: This adds a device tree binding for random number generator present on Broadcom BCM2835 SoC, used in Raspberry Pi and Roku 2 devices. Please ignore this one; it has been re-sent here by accident. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] watchdog: Add Broadcom BCM2835 watchdog timer driver
On Tue, 2013-03-26 at 21:40 -0600, Stephen Warren wrote: On 03/26/2013 11:50 AM, Lubomir Rintel wrote: This adds a driver for watchdog timer hardware present on Broadcom BCM2835 SoC, used in Raspberry Pi and Roku 2 devices. Since this patch defines a new DT binding, you should send it to devicetree-disc...@lists.ozlabs.org too. Okay. ... + * Interface to the Broadcom BCM2835 watchdog timer hardware is based on + * bcm2708_wdog driver written by Luke Diamand that was obtained from branch + * rpi-3.6.y of git://github.com/raspberrypi/linux.git I see that the patch isn't S-o-b Luke in the downstream kernel. However, it is S-o-b Dom Cobley (popcornmix), and they both work for Broadcom, so I think that's OK. Okay, I'll add it. ... + platform_set_drvdata(pdev, wdt); + watchdog_set_drvdata(bcm2835_wdt_wdd, wdt); Do you really need both of those? I would have thought just one would have been enough. I think so; I would like to get rid of the platform_*() one, but we need that in remove hook. All of the existing drivers in drivers/watchdog/ tree either use global data to represent a single device or use two of the *_set_drvdata() functions -- the watchdog_*() one and dev_*(), platform_*(), amba_*() or the like. I'd be tempted to put the platform_set_drvdata() call right after the devm_kzalloc() of wdt, but it's not a big deal either way. Done. I'm actually rather thankful for style fixes such as this, since I'm only getting familiar with what's customary to do there. Updated patch will follow shortly. -- Lubomir Rintel lkund...@v3.sk -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] watchdog: Add Broadcom BCM2835 watchdog timer driver
On Tue, 2013-03-26 at 14:03 -0700, Guenter Roeck wrote: On Tue, Mar 26, 2013 at 06:50:00PM +0100, Lubomir Rintel wrote: This adds a driver for watchdog timer hardware present on Broadcom BCM2835 SoC, used in Raspberry Pi and Roku 2 devices. ... +static unsigned int heartbeat = 0; checkpatch.pl says: ERROR: do not initialise statics to 0 or NULL #178: FILE: drivers/watchdog/bcm2835_wdt.c:44: +static unsigned int heartbeat = 0; Whoops. Will remove. + dev_info(dev, Broadcom BCM2835 watchdog timer); + Hmm .. that means you'll get the info message even in the error case. Is that intentional ? It is inconsistent with the remap error message above, which does not result in the info message. That was unintentional -- will change that. + platform_set_drvdata(pdev, NULL); Still unnecessary. Oops -- I'll actually remove it this time. -- Lubomir Rintel lkund...@v3.sk -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] watchdog: Add Broadcom BCM2835 watchdog timer driver
This adds a driver for watchdog timer hardware present on Broadcom BCM2835 SoC,
used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Signed-off-by: Dom Cobley popcorn...@gmail.com
Tested-by: Stephen Warren swar...@wwwdotorg.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Wim Van Sebroeck w...@iguana.be
Cc: Guenter Roeck li...@roeck-us.net
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-watch...@vger.kernel.org
---
Changes for v2:
- Use per-device structure instead of global variables for lock and memory
base
- Fix default timeout setting
- Do not leak memory if probe fails
- Style fixes
- Split out defconfig into a separate commit
- Meaningful commit message with credit
Changes for v3:
- Add proper copyright notice to header
- Drop status constants, we don't use them
- Fix heartbeat parameter's type
- Log driver initialization message once the device is probed
Changes for v4:
- Drop an useless initializer
- Add a signoff from downstream
- Do not announce the driver to the log if we failed to probe
- Set platform data earlier and do not explicitly unset it
.../bindings/watchdog/brcm,bcm2835-pm-wdog.txt |5 +
drivers/watchdog/Kconfig | 11 ++
drivers/watchdog/Makefile |1 +
drivers/watchdog/bcm2835_wdt.c | 190
4 files changed, 207 insertions(+), 0 deletions(-)
create mode 100644 drivers/watchdog/bcm2835_wdt.c
diff --git
a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
index d209366..f801d71 100644
--- a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
@@ -5,9 +5,14 @@ Required properties:
- compatible : should be brcm,bcm2835-pm-wdt
- reg : Specifies base physical address and size of the registers.
+Optional properties:
+
+- timeout-sec : Contains the watchdog timeout in seconds
+
Example:
watchdog {
compatible = brcm,bcm2835-pm-wdt;
reg = 0x7e10 0x28;
+ timeout-sec = 10;
};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9fcc70c..f4e4a8e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1098,6 +1098,17 @@ config BCM63XX_WDT
To compile this driver as a loadable module, choose M here.
The module will be called bcm63xx_wdt.
+config BCM2835_WDT
+ tristate Broadcom BCM2835 hardware watchdog
+ depends on ARCH_BCM2835
+ select WATCHDOG_CORE
+ help
+ Watchdog driver for the built in watchdog hardware in Broadcom
+ BCM2835 SoC.
+
+ To compile this driver as a loadable module, choose M here.
+ The module will be called bcm2835_wdt.
+
config LANTIQ_WDT
tristate Lantiq SoC watchdog
depends on LANTIQ
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a300b94..1bf5675 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
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
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 000..d47c842
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,190 @@
+/*
+ * Watchdog driver for Broadcom BCM2835
+ *
+ * Interface to the Broadcom BCM2835 watchdog timer hardware is based on
+ * bcm2708_wdog driver written by Luke Diamand that was obtained from branch
+ * rpi-3.6.y of git://github.com/raspberrypi/linux.git
+ *
+ * (c) Copyright 2010 Broadcom Europe Ltd
+ * Copyright (C) 2013 Lubomir Rintel lkund...@v3.sk
+ *
+ * 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.
+ */
+
+#include linux/types.h
+#include linux/module.h
+#include linux/io.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+#include linux/of_address.h
+#include linux/miscdevice.h
+
+#define PM_RSTC0x1c
+#define PM_WDOG0x24
+
+#define PM_PASSWORD0x5a00
+
+#define PM_WDOG_TIME_SET 0x000f
+#define PM_RSTC_WRCFG_CLR 0xffcf
+#define PM_RSTC_WRCFG_SET 0x0030
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTC_RESET 0x0102
+
+#define SECS_TO_WDOG_TICKS(x) ((x) 16)
+#define WDOG_TICKS_TO_SECS(x) ((x) 16)
+
+struct bcm2835_wdt
[PATCH] bcm2835: Add Broadcom BCM2835 RNG to the device tree
This adds a device tree binding for random number generator present on Broadcom
BCM2835 SoC, used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Tested-by: Stephen Warren swar...@wwwdotorg.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
Changes for v2:
- Split out from the driver changeset
- Added documentation
Changes for v3:
- Moved documentation away to the driver commit
arch/arm/boot/dts/bcm2835.dtsi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 7e0481e..dc22336 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -34,6 +34,11 @@
reg = 0x7e10 0x28;
};
+ rng {
+ compatible = brcm,bcm2835-rng;
+ reg = 0x7e104000 0x10;
+ };
+
uart@20201000 {
compatible = brcm,bcm2835-pl011, arm,pl011,
arm,primecell;
reg = 0x7e201000 0x1000;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hw_random: Add Broadcom BCM2835 RNG Driver
On Fri, 2013-03-22 at 20:44 -0600, Stephen Warren wrote: On 03/22/2013 06:55 AM, Lubomir Rintel wrote: Signed-off-by: Lubomir Rintel lkund...@v3.sk A commit description would be useful. arch/arm/boot/dts/bcm2835.dtsi |5 + arch/arm/configs/bcm2835_defconfig |3 +- drivers/char/hw_random/Kconfig | 12 +++ drivers/char/hw_random/Makefile |1 + drivers/char/hw_random/bcm2835-rng.c | 137 ++ This should be split into 3 separate patches: (1) The driver itself, (2) the change to bcm2835.dtsi, and (3) the change to bcm2835_defconfig. Since you're adding a new device to device tree for the first time, you should write a binding document for it; most likely Documentation/devicetree/bindings/rng/brcm,bcm2835.txt (or perhaps /random/ rather than /rng/?) Is this driver based on the downstream Raspberry Pi kernel's driver? If so, some mention of that fact would be appropriate in the commit description, or even the git author field. I note that in the downstream kernel, the commit which adds the RNG driver isn't signed off at all. This probably means you need to get Dom to add his signed-off-by line for that commit before basing your work on it. See Documentation/SubmittingPatches for more details. Got this message, will follow up with updated patch: On Wed, 2013-03-27 at 18:22 +, popcornmix wrote: On Wed, Mar 27, 2013 at 4:55 PM, Lubomir Rintel lkund...@v3.sk wrote: Hi! I'm currently in the process of mainlining the drivers from Raspberry Pi tree. I was asked for a signoff for the random number generator. It seems to have been commit by you in the downstream tree, I'm wondering if you could help me, and respond with a Signed-off-by tag if the code comes from you, or point me to someone else? commit e95a8204d7f8fc4f38900c99080103254c3cef11 Author: popcornmix popcorn...@gmail.com Date: Wed Jan 30 11:44:26 2013 + Add hwrng (hardware random number generator) driver Thank you! -- Lubomir Rintel lkund...@v3.sk Sorry, I'm not up to speed with exactly what constitutes a sign off. I did write the original hw-rng driver, and give my permission for it to be upstreamed. Is this sufficient? Signed-off-by: Dom Cobley d...@broadcom.com Signed-off-by: Dom Cobley popcorn...@gmail.com Signed-off-by: popcornmix popcorn...@gmail.com (not sure which is more suitable - they are all me). -- Lubomir Rintel (ext. #7715) GoodData Code Feng Shui Critic -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] hw_random: Add Broadcom BCM2835 RNG driver
This adds a driver for random number generator present on Broadcom BCM2835 SoC,
used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Dom Cobley popcorn...@gmail.com
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Tested-by: Stephen Warren swar...@wwwdotorg.org
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Matt Mackall m...@selenic.com
Cc: linux-rpi-ker...@lists.infradead.org
---
Changes for v2:
- Device tree and defconfig changes split out
- Licence changed from GPLv2+BSD to GPLv2 only
- Style fixes
Changes for v3:
- Device tree binding documentation added
.../devicetree/bindings/rng/brcm,bcm2835.txt | 13 +++
drivers/char/hw_random/Kconfig | 12 ++
drivers/char/hw_random/Makefile|1 +
drivers/char/hw_random/bcm2835-rng.c | 113
4 files changed, 139 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
create mode 100644 drivers/char/hw_random/bcm2835-rng.c
diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
new file mode 100644
index 000..07ccdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
@@ -0,0 +1,13 @@
+BCM2835 Random number generator
+
+Required properties:
+
+- compatible : should be brcm,bcm2835-rng
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+rng {
+compatible = brcm,bcm2835-rng;
+reg = 0x7e104000 0x10;
+};
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index c5a0262..2f9dbf7 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -86,6 +86,18 @@ config HW_RANDOM_BCM63XX
If unusure, say Y.
+config HW_RANDOM_BCM2835
+ tristate Broadcom BCM2835 Random Number Generator support
+ depends on HW_RANDOM ARCH_BCM2835
+ default HW_RANDOM
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on the Broadcom BCM2835 SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bcm2835-rng
+
+ If unsure, say Y.
config HW_RANDOM_GEODE
tristate AMD Geode HW Random Number Generator support
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 1fd7eec..bed467c 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -26,3 +26,4 @@ obj-$(CONFIG_HW_RANDOM_PPC4XX) += ppc4xx-rng.o
obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-rng.o
obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
+obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
diff --git a/drivers/char/hw_random/bcm2835-rng.c
b/drivers/char/hw_random/bcm2835-rng.c
new file mode 100644
index 000..eb7f147
--- /dev/null
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -0,0 +1,113 @@
+/**
+ * Copyright (c) 2010-2012 Broadcom. All rights reserved.
+ * Copyright (c) 2013 Lubomir Rintel
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License (GPL)
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include linux/hw_random.h
+#include linux/init.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/printk.h
+
+#define RNG_CTRL 0x0
+#define RNG_STATUS 0x4
+#define RNG_DATA 0x8
+
+/* enable rng */
+#define RNG_RBGEN 0x1
+
+/* the initial numbers generated are less random so will be discarded */
+#define RNG_WARMUP_COUNT 0x4
+
+static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+{
+ void __iomem *rng_base = (void __iomem *)rng-priv;
+
+ while ((__raw_readl(rng_base + RNG_STATUS) 24) == 0) {
+ if (!wait)
+ return 0;
+ cpu_relax();
+ }
+
+ *(u32 *)buf = __raw_readl(rng_base + RNG_DATA);
+ return sizeof(u32);
+}
+
+static struct hwrng bcm2835_rng_ops = {
+ .name = bcm2835,
+ .read = bcm2835_rng_read,
+};
+
+static int bcm2835_rng_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct device_node *np = dev-of_node;
+ void __iomem *rng_base;
+ int err;
+
+ /* map peripheral */
+ rng_base = of_iomap(np, 0);
+ if (!rng_base) {
+ dev_err(dev, failed to remap rng regs);
+ return -ENODEV;
+ }
+ bcm2835_rng_ops.priv = (unsigned long)rng_base;
+
+ /* register driver */
+ err = hwrng_register(bcm2835_rng_ops);
+ if (err) {
+ dev_err(dev, hwrng registration failed\n
[PATCH RESEND] bluetooth: btmrvl_sdio: look for sd8688 firmware in proper location
The firmware images are shared with libertas_sdio WiFi chip and used to be in
libertas/ subtree in linux-firmware. As btmrvl_sdio used to look into the
linux-firmware root, it ended up being unsuccessful. Since the firmware files
are not specific to the libertas hardware, they're being moved into mrvl/ now.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Acked-by: Marcel Holtmann mar...@holtmann.org
---
Now that the relevant changes are in linux-firmware it makes sense to merge
this to make the driver look for correct firmware files.
drivers/bluetooth/btmrvl_sdio.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 9959d4c..1cb5183 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -83,8 +83,8 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_87xx = {
};
static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
- .helper = sd8688_helper.bin,
- .firmware = sd8688.bin,
+ .helper = mrvl/sd8688_helper.bin,
+ .firmware = mrvl/sd8688.bin,
.reg= btmrvl_reg_8688,
.sd_blksz_fw_dl = 64,
};
@@ -1185,7 +1185,7 @@ MODULE_AUTHOR(Marvell International Ltd.);
MODULE_DESCRIPTION(Marvell BT-over-SDIO driver ver VERSION);
MODULE_VERSION(VERSION);
MODULE_LICENSE(GPL v2);
-MODULE_FIRMWARE(sd8688_helper.bin);
-MODULE_FIRMWARE(sd8688.bin);
+MODULE_FIRMWARE(mrvl/sd8688_helper.bin);
+MODULE_FIRMWARE(mrvl/sd8688.bin);
MODULE_FIRMWARE(mrvl/sd8787_uapsta.bin);
MODULE_FIRMWARE(mrvl/sd8797_uapsta.bin);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btmrvl_sdio: look for sd8688 firmware in alternate place
On Mon, 2013-01-21 at 01:12 +, Ben Hutchings wrote: On Fri, 2013-01-18 at 08:33 +0100, Lubomir Rintel wrote: On Tue, 2013-01-08 at 22:35 -0800, Marcel Holtmann wrote: Hi Lubomir, linux-firmware ships the sd8688* firmware images that are shared with libertas_sdio WiFi driver under libertas/. libertas_sdio looks in both places and so should we. Signed-off-by: Lubomir Rintel lkund...@v3.sk --- drivers/bluetooth/btmrvl_sdio.c | 24 ++-- drivers/bluetooth/btmrvl_sdio.h |6 -- 2 files changed, 26 insertions(+), 4 deletions(-) NAK from me on this one. I do not want the driver to check two locations. That is what userspace can work around. If we want to unify the location between the WiFi driver and the Bluetooth driver, I am fine with that, but seriously, just pick one over the other. I do not care which one. The unified location is mrvl/ directory. We can probably move SD8688 firmware helper binaries to mrvl/ and have both drivers grab the images there? That would break existing setups, wouldn't it? I was under impression (commit 3d32a58b) that we care about compatibility here. Do we? that is what symlinks are for. David, Ben: please pull the following branch then: git pull git://github.com/lkundrak/linux-firmware.git sd8688-move Thank you! The symlinks are broken, and you didn't update WHENCE. Oops, sorry for that. Fixed now, please pull: git pull git://github.com/lkundrak/linux-firmware.git sd8688-move Thank you! -- 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] mtd: cmdlinepart: Make it into a module
All other partitioning schemes can be compiled as modules
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/mtd/Kconfig |4 ++--
drivers/mtd/cmdlinepart.c |8 +++-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 73fcbbe..4dd3b38 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -74,8 +74,8 @@ config MTD_REDBOOT_PARTS_READONLY
endif # MTD_REDBOOT_PARTS
config MTD_CMDLINE_PARTS
- bool Command line partition table parsing
- depends on MTD = y
+ tristate Command line partition table parsing
+ depends on MTD
---help---
Allow generic configuration of the MTD partition tables via the kernel
command line. Multiple flash resources are supported for hardware
where
diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
index aed1b8a..a2bb2ea 100644
--- a/drivers/mtd/cmdlinepart.c
+++ b/drivers/mtd/cmdlinepart.c
@@ -70,6 +70,7 @@ struct cmdline_mtd_partition {
static struct cmdline_mtd_partition *partitions;
/* the command line passed to mtdpart_setup() */
+static char *mtdparts;
static char *cmdline;
static int cmdline_parsed;
@@ -360,7 +361,7 @@ static int parse_cmdline_partitions(struct mtd_info *master,
*
* This function needs to be visible for bootloaders.
*/
-static int mtdpart_setup(char *s)
+static int __init mtdpart_setup(char *s)
{
cmdline = s;
return 1;
@@ -376,11 +377,16 @@ static struct mtd_part_parser cmdline_parser = {
static int __init cmdline_parser_init(void)
{
+ if (mtdparts)
+ mtdpart_setup(mtdparts);
return register_mtd_parser(cmdline_parser);
}
module_init(cmdline_parser_init);
+MODULE_PARM_DESC(mtdparts, Partitioning specification);
+module_param(mtdparts, charp, 0);
+
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Marius Groeger m...@sysgo.de);
MODULE_DESCRIPTION(Command line configuration of MTD partitions);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] mtd: Allow removal of partitioning modules
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/mtd/ar7part.c |6 ++
drivers/mtd/cmdlinepart.c |6 ++
drivers/mtd/ofpart.c |7 +++
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/ar7part.c b/drivers/mtd/ar7part.c
index 9453931..a98899f 100644
--- a/drivers/mtd/ar7part.c
+++ b/drivers/mtd/ar7part.c
@@ -145,7 +145,13 @@ static int __init ar7_parser_init(void)
return register_mtd_parser(ar7_parser);
}
+static void __exit ar7_parser_exit(void)
+{
+ deregister_mtd_parser(ar7_parser);
+}
+
module_init(ar7_parser_init);
+module_exit(ar7_parser_exit);
MODULE_LICENSE(GPL);
MODULE_AUTHOR( Felix Fietkau n...@openwrt.org,
diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c
index a2bb2ea..8689a77 100644
--- a/drivers/mtd/cmdlinepart.c
+++ b/drivers/mtd/cmdlinepart.c
@@ -382,7 +382,13 @@ static int __init cmdline_parser_init(void)
return register_mtd_parser(cmdline_parser);
}
+static void __exit cmdline_parser_exit(void)
+{
+ deregister_mtd_parser(cmdline_parser);
+}
+
module_init(cmdline_parser_init);
+module_exit(cmdline_parser_exit);
MODULE_PARM_DESC(mtdparts, Partitioning specification);
module_param(mtdparts, charp, 0);
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index d9127e2..d407e0b 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -171,7 +171,14 @@ out:
return rc;
}
+static void __exit ofpart_parser_exit(void)
+{
+ deregister_mtd_parser(ofpart_parser);
+ deregister_mtd_parser(ofoldpart_parser);
+}
+
module_init(ofpart_parser_init);
+module_exit(ofpart_parser_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(Parser for MTD partitioning information in device tree);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] libertas sdio: remove CMD_FUNC_INIT call
It actually times out on a 8688 present in GuruPlug with sd8688.bin
(md5=7233401e9687f8c880da547beed4324e) firmware (that's present in
linux-firmware tree), but the adapter works fine.
For that firmware times out with libertas_uap [1] as well, though it succeeds
with sd8688_ap.bin (md5=52cd8f8296b9a7e1d3835d57416256b2) that was originally
shipped with GuruPlug. That firmware is not in linux-firmware tree and btmrvl
driver might win the race programming the 8688 with sd8688.bin anyway.
[1] https://github.com/lkundrak/linux/tree/libertas_uap
---
drivers/net/wireless/libertas/if_sdio.c | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/libertas/if_sdio.c
b/drivers/net/wireless/libertas/if_sdio.c
index 2ecab49..3c4c555 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -825,20 +825,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card
*card)
sdio_release_host(func);
- /*
-* FUNC_INIT is required for SD8688 WLAN/BT multiple functions
-*/
- if (card-model == MODEL_8688) {
- struct cmd_header cmd;
-
- memset(cmd, 0, sizeof(cmd));
-
- lbs_deb_sdio(send function INIT command\n);
- if (__lbs_cmd(priv, CMD_FUNC_INIT, cmd, sizeof(cmd),
- lbs_cmd_copyback, (unsigned long) cmd))
- netdev_alert(priv-dev, CMD_FUNC_INIT cmd failed\n);
- }
-
priv-fw_ready = 1;
wake_up(card-pwron_waitq);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btmrvl_sdio: look for sd8688 firmware in alternate place
On Tue, 2013-01-08 at 22:35 -0800, Marcel Holtmann wrote: Hi Lubomir, linux-firmware ships the sd8688* firmware images that are shared with libertas_sdio WiFi driver under libertas/. libertas_sdio looks in both places and so should we. Signed-off-by: Lubomir Rintel lkund...@v3.sk --- drivers/bluetooth/btmrvl_sdio.c | 24 ++-- drivers/bluetooth/btmrvl_sdio.h |6 -- 2 files changed, 26 insertions(+), 4 deletions(-) NAK from me on this one. I do not want the driver to check two locations. That is what userspace can work around. If we want to unify the location between the WiFi driver and the Bluetooth driver, I am fine with that, but seriously, just pick one over the other. I do not care which one. The unified location is mrvl/ directory. We can probably move SD8688 firmware helper binaries to mrvl/ and have both drivers grab the images there? That would break existing setups, wouldn't it? I was under impression (commit 3d32a58b) that we care about compatibility here. Do we? that is what symlinks are for. David, Ben: please pull the following branch then: git pull git://github.com/lkundrak/linux-firmware.git sd8688-move Thank you! -- 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] bluetooth: btmrvl_sdio: look for sd8688 firmware in proper location
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/bluetooth/btmrvl_sdio.c |8
drivers/bluetooth/btmrvl_sdio.h |6 --
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 3f4bfc8..bc27d01 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -83,8 +83,8 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_87xx = {
};
static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
- .helper = sd8688_helper.bin,
- .firmware = sd8688.bin,
+ .helper = mrvl/sd8688_helper.bin,
+ .firmware = mrvl/sd8688.bin,
.reg= btmrvl_reg_8688,
.sd_blksz_fw_dl = 64,
};
@@ -1179,7 +1179,7 @@ MODULE_AUTHOR(Marvell International Ltd.);
MODULE_DESCRIPTION(Marvell BT-over-SDIO driver ver VERSION);
MODULE_VERSION(VERSION);
MODULE_LICENSE(GPL v2);
-MODULE_FIRMWARE(sd8688_helper.bin);
-MODULE_FIRMWARE(sd8688.bin);
+MODULE_FIRMWARE(mrvl/sd8688_helper.bin);
+MODULE_FIRMWARE(mrvl/sd8688.bin);
MODULE_FIRMWARE(mrvl/sd8787_uapsta.bin);
MODULE_FIRMWARE(mrvl/sd8797_uapsta.bin);
diff --git a/drivers/bluetooth/btmrvl_sdio.h b/drivers/bluetooth/btmrvl_sdio.h
index 43d35a6..4a5a019 100644
--- a/drivers/bluetooth/btmrvl_sdio.h
+++ b/drivers/bluetooth/btmrvl_sdio.h
@@ -84,7 +84,9 @@ struct btmrvl_sdio_card {
struct sdio_func *func;
u32 ioport;
const char *helper;
+ const char *helper2;
const char *firmware;
+ const char *firmware2;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
u8 rx_unit;
@@ -92,8 +94,8 @@ struct btmrvl_sdio_card {
};
struct btmrvl_sdio_device {
- const char *helper;
- const char *firmware;
+ const char *helper, *helper2;
+ const char *firmware, *firmware2;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] libertas sdio: look for 8688 firmware in common location
sd8688 is not only used by libertas WiFi, but shared with btmrvl bluetooth as
well.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/net/wireless/libertas/if_sdio.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/libertas/if_sdio.c
b/drivers/net/wireless/libertas/if_sdio.c
index 739309e..be16a76 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -85,6 +85,7 @@ static const struct lbs_fw_table fw_table[] = {
{ MODEL_8686, libertas/sd8686_v9_helper.bin, libertas/sd8686_v9.bin
},
{ MODEL_8686, libertas/sd8686_v8_helper.bin, libertas/sd8686_v8.bin
},
{ MODEL_8686, sd8686_helper.bin, sd8686.bin },
+ { MODEL_8688, mrvl/sd8688_helper.bin, mrvl/sd8688.bin },
{ MODEL_8688, libertas/sd8688_helper.bin, libertas/sd8688.bin },
{ MODEL_8688, sd8688_helper.bin, sd8688.bin },
{ 0, NULL, NULL }
@@ -99,6 +100,8 @@ MODULE_FIRMWARE(libertas/sd8686_v8_helper.bin);
MODULE_FIRMWARE(libertas/sd8686_v8.bin);
MODULE_FIRMWARE(sd8686_helper.bin);
MODULE_FIRMWARE(sd8686.bin);
+MODULE_FIRMWARE(mrvl/sd8688_helper.bin);
+MODULE_FIRMWARE(mrvl/sd8688.bin);
MODULE_FIRMWARE(libertas/sd8688_helper.bin);
MODULE_FIRMWARE(libertas/sd8688.bin);
MODULE_FIRMWARE(sd8688_helper.bin);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] dma: mv_xor: do not sync the DMA buffer after being deallocated
On Sun, 2013-01-13 at 14:18 +0100, Lubomir Rintel wrote: On Fri, 2013-01-04 at 17:10 +0100, Thomas Petazzoni wrote: Dear Lubomir Rintel, On Thu, 27 Dec 2012 20:23:48 +0100, Lubomir Rintel wrote: dma_sync_single_for_cpu(dma_chan-device-dev, dest_dma, MV_XOR_TEST_SIZE, DMA_FROM_DEVICE); + dma_unmap_single(dma_chan-device-dev, dest_dma, MV_XOR_TEST_SIZE, + DMA_FROM_DEVICE); I would assume that dma_unmap_single() implies a dma_sync_single_for_cpu() since you're unmapping the DMA buffer. So if you use dma_unmap_single(), I think you can remove the call to dma_sync_single_for_cpu(). Yes, it indeed seems to be the case (comment for arm_dma_unmap_page(): After this call, reads by the CPU to the buffer are guaranteed to see whatever the device wrote there.. dma_sync_single_for_cpu(dma_chan-device-dev, dest_dma, PAGE_SIZE, DMA_FROM_DEVICE); + dma_unmap_page(dma_chan-device-dev, dest_dma, PAGE_SIZE, +DMA_FROM_DEVICE); Ditto. Also, the mv_xor_memcpy_self_test() function not only dma_map_single() the destination buffer, but also the source buffer. So presumably, the source buffer should also be dma_unmap_single()'d. And for the mv_xor_xor_self_test() function, multiple source buffers are dma_map_page()'d, so they should all be dma_unmap_page()'d I guess, not only the destination buffer. Those get released by the mv_xor_run_tx_complete_actions() callback. I will follow up with an updated patch. Actually, after cleaning up the sync a couple more selfcheck warnings popped up. I'd be very thankful if you could take a look (patches chained to this message). -- 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/3] dma: mv_xor: do not sync the DMA buffer after being deallocated
DMA_CHECK was unhappy:
mv_xor mv_xor.0: DMA-API: device driver tries to sync DMA memory it has not
allocated [device address=0x1f3a1a40] [size=2000 bytes]
Deallocation, which involves a sync, happens automatically by
mv_xor_slot_cleanup() once the transfer is finished.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/dma/mv_xor.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index e666983..8b81a04 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -960,8 +960,6 @@ static int mv_xor_memcpy_self_test(struct mv_xor_chan
*mv_chan)
goto free_resources;
}
- dma_sync_single_for_cpu(dma_chan-device-dev, dest_dma,
- MV_XOR_TEST_SIZE, DMA_FROM_DEVICE);
if (memcmp(src, dest, MV_XOR_TEST_SIZE)) {
dev_err(dma_chan-device-dev,
Self-test copy failed compare, disabling\n);
@@ -1054,8 +1052,6 @@ mv_xor_xor_self_test(struct mv_xor_chan *mv_chan)
goto free_resources;
}
- dma_sync_single_for_cpu(dma_chan-device-dev, dest_dma,
- PAGE_SIZE, DMA_FROM_DEVICE);
for (i = 0; i (PAGE_SIZE / sizeof(u32)); i++) {
u32 *ptr = page_address(dest);
if (ptr[i] != cmp_word) {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] dma: mv_xor: get rid of a DMA-API sanity check warning
mv_xor mv_xor.0: DMA-API: device driver frees DMA memory with different
direction [device address=0x1dea4000] [size=4096 bytes] [mapped with
DMA_FROM_DEVICE] [unmapped with DMA_BIDIRECTIONAL]
Change xor self test destination buffer allocation direction to bidirectional,
as it's what mv_xor_run_tx_complete_actions() frees for multiple sources.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/dma/mv_xor.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index d00a834..1e90f5d 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -1042,7 +1042,7 @@ mv_xor_xor_self_test(struct mv_xor_chan *mv_chan)
/* test xor */
dest_dma = dma_map_page(dma_chan-device-dev, dest, 0, PAGE_SIZE,
- DMA_FROM_DEVICE);
+ DMA_BIDIRECTIONAL);
if (dma_mapping_error(dma_chan-device-dev, dest_dma)) {
dev_err(dma_chan-device-dev,
Could not map destination page, disabling\n);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] dma: mv_xor: fix DMA-API error handling sanity check
Add error checking.
---
drivers/dma/mv_xor.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index 8b81a04..d00a834 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -939,9 +939,21 @@ static int mv_xor_memcpy_self_test(struct mv_xor_chan
*mv_chan)
dest_dma = dma_map_single(dma_chan-device-dev, dest,
MV_XOR_TEST_SIZE, DMA_FROM_DEVICE);
+ if (dma_mapping_error(dma_chan-device-dev, dest_dma)) {
+ dev_err(dma_chan-device-dev,
+ Could not map destination buffer, disabling\n);
+ err = -ENODEV;
+ goto free_resources;
+ }
src_dma = dma_map_single(dma_chan-device-dev, src,
MV_XOR_TEST_SIZE, DMA_TO_DEVICE);
+ if (dma_mapping_error(dma_chan-device-dev, src_dma)) {
+ dev_err(dma_chan-device-dev,
+ Could not map source buffer, disabling\n);
+ err = -ENODEV;
+ goto free_resources;
+ }
tx = mv_xor_prep_dma_memcpy(dma_chan, dest_dma, src_dma,
MV_XOR_TEST_SIZE,
@@ -1031,10 +1043,23 @@ mv_xor_xor_self_test(struct mv_xor_chan *mv_chan)
/* test xor */
dest_dma = dma_map_page(dma_chan-device-dev, dest, 0, PAGE_SIZE,
DMA_FROM_DEVICE);
+ if (dma_mapping_error(dma_chan-device-dev, dest_dma)) {
+ dev_err(dma_chan-device-dev,
+ Could not map destination page, disabling\n);
+ err = -ENODEV;
+ goto free_resources;
+ }
- for (i = 0; i MV_XOR_NUM_SRC_TEST; i++)
+ for (i = 0; i MV_XOR_NUM_SRC_TEST; i++) {
dma_srcs[i] = dma_map_page(dma_chan-device-dev, xor_srcs[i],
0, PAGE_SIZE, DMA_TO_DEVICE);
+ if (dma_mapping_error(dma_chan-device-dev, dma_srcs[i])) {
+ dev_err(dma_chan-device-dev,
+ Could not map source page, disabling\n);
+ err = -ENODEV;
+ goto free_resources;
+ }
+ }
tx = mv_xor_prep_dma_xor(dma_chan, dest_dma, dma_srcs,
MV_XOR_NUM_SRC_TEST, PAGE_SIZE, 0);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] bluetooth: btmrvl_sdio: look for sd8688 firmware in proper location
The firmware images are shared with libertas_sdio WiFi chip and used to be in
libertas/ subtree in linux-firmware. As btmrvl_sdio used to look into the
linux-firmware root, it ended up being unsuccessful. Since the firmware files
are not specific to the libertas hardware, they're being moved into mrvl/ now.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/bluetooth/btmrvl_sdio.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 9959d4c..1cb5183 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -83,8 +83,8 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_87xx = {
};
static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
- .helper = sd8688_helper.bin,
- .firmware = sd8688.bin,
+ .helper = mrvl/sd8688_helper.bin,
+ .firmware = mrvl/sd8688.bin,
.reg= btmrvl_reg_8688,
.sd_blksz_fw_dl = 64,
};
@@ -1185,7 +1185,7 @@ MODULE_AUTHOR(Marvell International Ltd.);
MODULE_DESCRIPTION(Marvell BT-over-SDIO driver ver VERSION);
MODULE_VERSION(VERSION);
MODULE_LICENSE(GPL v2);
-MODULE_FIRMWARE(sd8688_helper.bin);
-MODULE_FIRMWARE(sd8688.bin);
+MODULE_FIRMWARE(mrvl/sd8688_helper.bin);
+MODULE_FIRMWARE(mrvl/sd8688.bin);
MODULE_FIRMWARE(mrvl/sd8787_uapsta.bin);
MODULE_FIRMWARE(mrvl/sd8797_uapsta.bin);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
On Fri, 2013-01-18 at 12:28 -0800, Bing Zhao wrote:
Hi Lubomir,
It actually times out on a 8688 present in GuruPlug with sd8688.bin
(md5=7233401e9687f8c880da547beed4324e) firmware (that's present in
linux-firmware tree), but the adapter works fine.
For that firmware times out with libertas_uap [1] as well, though it
succeeds
with sd8688_ap.bin (md5=52cd8f8296b9a7e1d3835d57416256b2) that was
originally
shipped with GuruPlug. That firmware is not in linux-firmware tree and
btmrvl
driver might win the race programming the 8688 with sd8688.bin anyway.
[1] https://github.com/lkundrak/linux/tree/libertas_uap
---
drivers/net/wireless/libertas/if_sdio.c | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/libertas/if_sdio.c
b/drivers/net/wireless/libertas/if_sdio.c
index 2ecab49..3c4c555 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -825,20 +825,6 @@ static void if_sdio_finish_power_on(struct
if_sdio_card *card)
sdio_release_host(func);
- /*
-* FUNC_INIT is required for SD8688 WLAN/BT multiple functions
-*/
- if (card-model == MODEL_8688) {
- struct cmd_header cmd;
-
- memset(cmd, 0, sizeof(cmd));
-
- lbs_deb_sdio(send function INIT command\n);
- if (__lbs_cmd(priv, CMD_FUNC_INIT, cmd, sizeof(cmd),
- lbs_cmd_copyback, (unsigned long) cmd))
- netdev_alert(priv-dev, CMD_FUNC_INIT cmd failed\n);
- }
-
Removing FUNC_INIT could break things in some scenarios.
Could you please test the following case?
1. insmod liberates - download firmware, send FUNC_INIT, ...
2. rmmod libertas - send FUNC_SHUTDOWN command to firmware; BT is still
working.
3. insmod libertas - skip firmware downloading, send FUNC_INIT, ...
If FUNC_INIT is removed, I don't expect step 3 to work.
In case btmrvl_sdio is loaded, the driver always locks up in FUNC_INIT
upon probe time, thus I'm not able to proceed to further steps.
[ 209.338953] [c0502248] (__schedule+0x610/0x764) from [bf20ae24]
(__lbs_cmd+0xb8/0x130 [libertas])
[ 209.348340] [bf20ae24] (__lbs_cmd+0xb8/0x130 [libertas]) from [bf222474]
(if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
[ 209.360136] [bf222474] (if_sdio_finish_power_on+0xec/0x1b0
[libertas_sdio]) from [bf2226c4] (if_sdio_power_on+0x18c/0x20c
[libertas_sdio])
[ 209.373052] [bf2226c4] (if_sdio_power_on+0x18c/0x20c [libertas_sdio]) from
[bf222944] (if_sdio_probe+0x200/0x31c [libertas_sdio])
[ 209.385316] [bf222944] (if_sdio_probe+0x200/0x31c [libertas_sdio]) from
[bf01d820] (sdio_bus_probe+0x94/0xfc [mmc_core])
[ 209.396748] [bf01d820] (sdio_bus_probe+0x94/0xfc [mmc_core]) from
[c02e729c] (driver_probe_device+0x12c/0x348)
[ 209.407214] [c02e729c] (driver_probe_device+0x12c/0x348) from [c02e7530]
(__driver_attach+0x78/0x9c)
[ 209.416798] [c02e7530] (__driver_attach+0x78/0x9c) from [c02e5658]
(bus_for_each_dev+0x50/0x88)
[ 209.425946] [c02e5658] (bus_for_each_dev+0x50/0x88) from [c02e6810]
(bus_add_driver+0x108/0x268)
[ 209.435180] [c02e6810] (bus_add_driver+0x108/0x268) from [c02e782c]
(driver_register+0xa4/0x134)
[ 209.26] [c02e782c] (driver_register+0xa4/0x134) from [bf22601c]
(if_sdio_init_module+0x1c/0x3c [libertas_sdio])
[ 209.455339] [bf22601c] (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
from [c00085b8] (do_one_initcall+0x98/0x174)
[ 209.466236] [c00085b8] (do_one_initcall+0x98/0x174) from [c0076504]
(load_module+0x1c5c/0x1f80)
[ 209.475390] [c0076504] (load_module+0x1c5c/0x1f80) from [c007692c]
(sys_init_module+0x104/0x128)
[ 209.484632] [c007692c] (sys_init_module+0x104/0x128) from [c0008c40]
(ret_fast_syscall+0x0/0x38)
In case btmrvl_sdio is _not_ loaded, insmod returns, but driver locks up
waiting for FUNC_INIT to finish:
[ 300.538859] [c0502248] (__schedule+0x610/0x764) from [bf1fae24]
(__lbs_cmd+0xb8/0x130 [libertas])
[ 300.548600] [bf1fae24] (__lbs_cmd+0xb8/0x130 [libertas]) from [bf212474]
(if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
[ 300.560398] [bf212474] (if_sdio_finish_power_on+0xec/0x1b0
[libertas_sdio]) from [bf213230] (if_sdio_do_prog_firmware+0x414/0x454
[libertas_sdio])
[ 300.574052] [bf213230] (if_sdio_do_prog_firmware+0x414/0x454
[libertas_sdio]) from [bf1fffbc] (lbs_fw_loaded+0x24/0x58 [libertas])
[ 300.586907] [bf1fffbc] (lbs_fw_loaded+0x24/0x58 [libertas]) from
[c02f02c0] (request_firmware_work_func+0xb0/0xf4)
[ 300.597746] [c02f02c0] (request_firmware_work_func+0xb0/0xf4) from
[c003ae0c] (process_one_work+0x348/0x6a8)
[ 300.608288] [c003ae0c] (process_one_work+0x348/0x6a8) from [c003b408]
(worker_thread+0x268/0x390)
[ 300.617630] [c003b408] (worker_thread+0x268/0x390) from [c00414b0]
(kthread+0xc0/0xd4)
[ 300.625947] [c00414b0] (kthread+0xc0/0xd4) from [c0008ce8]
(ret_from_fork+0x14/0x20)
[ 300.634135] 2 locks
RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
On Wed, 2013-02-20 at 17:59 -0800, Bing Zhao wrote:
Hi Lubomir,
@@ -825,20 +825,6 @@ static void if_sdio_finish_power_on(struct
if_sdio_card *card)
sdio_release_host(func);
- /*
-* FUNC_INIT is required for SD8688 WLAN/BT multiple functions
-*/
- if (card-model == MODEL_8688) {
- struct cmd_header cmd;
-
- memset(cmd, 0, sizeof(cmd));
-
- lbs_deb_sdio(send function INIT command\n);
- if (__lbs_cmd(priv, CMD_FUNC_INIT, cmd, sizeof(cmd),
- lbs_cmd_copyback, (unsigned long) cmd))
- netdev_alert(priv-dev, CMD_FUNC_INIT cmd
failed\n);
- }
-
Removing FUNC_INIT could break things in some scenarios.
Could you please test the following case?
1. insmod liberates - download firmware, send FUNC_INIT, ...
2. rmmod libertas - send FUNC_SHUTDOWN command to firmware; BT is still
working.
3. insmod libertas - skip firmware downloading, send FUNC_INIT, ...
If FUNC_INIT is removed, I don't expect step 3 to work.
In case btmrvl_sdio is loaded, the driver always locks up in FUNC_INIT
upon probe time, thus I'm not able to proceed to further steps.
[ 209.338953] [c0502248] (__schedule+0x610/0x764) from [bf20ae24]
(__lbs_cmd+0xb8/0x130
[libertas])
[ 209.348340] [bf20ae24] (__lbs_cmd+0xb8/0x130 [libertas]) from
[bf222474]
(if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
[ 209.360136] [bf222474] (if_sdio_finish_power_on+0xec/0x1b0
[libertas_sdio]) from [bf2226c4]
(if_sdio_power_on+0x18c/0x20c [libertas_sdio])
[ 209.373052] [bf2226c4] (if_sdio_power_on+0x18c/0x20c [libertas_sdio])
from [bf222944]
(if_sdio_probe+0x200/0x31c [libertas_sdio])
[ 209.385316] [bf222944] (if_sdio_probe+0x200/0x31c [libertas_sdio])
from [bf01d820]
(sdio_bus_probe+0x94/0xfc [mmc_core])
[ 209.396748] [bf01d820] (sdio_bus_probe+0x94/0xfc [mmc_core]) from
[c02e729c]
(driver_probe_device+0x12c/0x348)
[ 209.407214] [c02e729c] (driver_probe_device+0x12c/0x348) from
[c02e7530]
(__driver_attach+0x78/0x9c)
[ 209.416798] [c02e7530] (__driver_attach+0x78/0x9c) from [c02e5658]
(bus_for_each_dev+0x50/0x88)
[ 209.425946] [c02e5658] (bus_for_each_dev+0x50/0x88) from [c02e6810]
(bus_add_driver+0x108/0x268)
[ 209.435180] [c02e6810] (bus_add_driver+0x108/0x268) from [c02e782c]
(driver_register+0xa4/0x134)
[ 209.26] [c02e782c] (driver_register+0xa4/0x134) from [bf22601c]
(if_sdio_init_module+0x1c/0x3c [libertas_sdio])
[ 209.455339] [bf22601c] (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
from [c00085b8]
(do_one_initcall+0x98/0x174)
[ 209.466236] [c00085b8] (do_one_initcall+0x98/0x174) from [c0076504]
(load_module+0x1c5c/0x1f80)
[ 209.475390] [c0076504] (load_module+0x1c5c/0x1f80) from [c007692c]
(sys_init_module+0x104/0x128)
[ 209.484632] [c007692c] (sys_init_module+0x104/0x128) from [c0008c40]
(ret_fast_syscall+0x0/0x38)
In case btmrvl_sdio is _not_ loaded, insmod returns, but driver locks up
waiting for FUNC_INIT to finish:
[ 300.538859] [c0502248] (__schedule+0x610/0x764) from [bf1fae24]
(__lbs_cmd+0xb8/0x130
[libertas])
[ 300.548600] [bf1fae24] (__lbs_cmd+0xb8/0x130 [libertas]) from
[bf212474]
(if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
[ 300.560398] [bf212474] (if_sdio_finish_power_on+0xec/0x1b0
[libertas_sdio]) from [bf213230]
(if_sdio_do_prog_firmware+0x414/0x454 [libertas_sdio])
[ 300.574052] [bf213230] (if_sdio_do_prog_firmware+0x414/0x454
[libertas_sdio]) from [bf1fffbc]
(lbs_fw_loaded+0x24/0x58 [libertas])
[ 300.586907] [bf1fffbc] (lbs_fw_loaded+0x24/0x58 [libertas]) from
[c02f02c0]
(request_firmware_work_func+0xb0/0xf4)
[ 300.597746] [c02f02c0] (request_firmware_work_func+0xb0/0xf4) from
[c003ae0c]
(process_one_work+0x348/0x6a8)
[ 300.608288] [c003ae0c] (process_one_work+0x348/0x6a8) from [c003b408]
(worker_thread+0x268/0x390)
[ 300.617630] [c003b408] (worker_thread+0x268/0x390) from [c00414b0]
(kthread+0xc0/0xd4)
[ 300.625947] [c00414b0] (kthread+0xc0/0xd4) from [c0008ce8]
(ret_from_fork+0x14/0x20)
[ 300.634135] 2 locks held by kworker/0:1/19:
[ 300.638383] #0: (events){.+.+.+}, at: [c003accc]
process_one_work+0x208/0x6a8
[ 300.646512] #1: ((fw_work-work)){+.+.+.}, at: [c003accc]
process_one_work+0x208/0x6a8
There seems to be a race condition in lbs_thread().
At line 582:
582 if (!priv-fw_ready)
583 continue;
The fw_ready is 0, so you never get the chance to execute the FUNC_INIT
command.
617 /* Execute the next command */
618 if (!priv-dnld_sent !priv-cur_cmd)
619 lbs_execute_next_command(priv);
Could you try the following change?
diff --git
[PATCH 1/2] dma: mv_xor: use proper dma memory management functions
Caught by self-check with DMA_API_DEBUG:
WARNING: at lib/dma-debug.c:878 check_unmap+0x37c/0x748()
mv_xor mv_xor.0: DMA-API: device driver frees DMA memory with wrong function
[device address=0x1f3a1a40] [size=2000 bytes] [mapped as single]
[unmapped as page]
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/dma/mv_xor.c | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index ac71f55..39387df 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -306,9 +306,7 @@ mv_xor_run_tx_complete_actions(struct mv_xor_desc_slot
*desc,
desc-async_tx.callback(
desc-async_tx.callback_param);
- /* unmap dma addresses
-* (unmap_single vs unmap_page?)
-*/
+ /* unmap dma addresses */
if (desc-group_head desc-unmap_len) {
struct mv_xor_desc_slot *unmap = desc-group_head;
struct device *dev = mv_chan_to_devp(mv_chan);
@@ -327,7 +325,11 @@ mv_xor_run_tx_complete_actions(struct mv_xor_desc_slot
*desc,
dir = DMA_BIDIRECTIONAL;
else
dir = DMA_FROM_DEVICE;
- dma_unmap_page(dev, dest, len, dir);
+
+ if (flags DMA_COMPL_DEST_UNMAP_SINGLE)
+ dma_unmap_single(dev, dest, len, dir);
+ else
+ dma_unmap_page(dev, dest, len, dir);
}
if (!(flags DMA_COMPL_SKIP_SRC_UNMAP)) {
@@ -336,8 +338,12 @@ mv_xor_run_tx_complete_actions(struct mv_xor_desc_slot
*desc,
src_cnt);
if (addr == dest)
continue;
- dma_unmap_page(dev, addr, len,
- DMA_TO_DEVICE);
+ if (flags DMA_COMPL_SRC_UNMAP_SINGLE)
+ dma_unmap_single(dev, addr, len,
+ DMA_TO_DEVICE);
+ else
+ dma_unmap_page(dev, addr, len,
+ DMA_TO_DEVICE);
}
}
desc-group_head = NULL;
@@ -938,7 +944,9 @@ static int mv_xor_memcpy_self_test(struct mv_xor_chan
*mv_chan)
MV_XOR_TEST_SIZE, DMA_TO_DEVICE);
tx = mv_xor_prep_dma_memcpy(dma_chan, dest_dma, src_dma,
- MV_XOR_TEST_SIZE, 0);
+ MV_XOR_TEST_SIZE,
+ DMA_COMPL_SRC_UNMAP_SINGLE |
+ DMA_COMPL_DEST_UNMAP_SINGLE);
cookie = mv_xor_tx_submit(tx);
mv_xor_issue_pending(dma_chan);
async_tx_ack(tx);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] dma: mv_xor: do not sync the DMA buffer after being deallocated
DMA_CHECK was unhappy:
mv_xor mv_xor.0: DMA-API: device driver tries to sync DMA memory it has not
Also, the xor test was causing the mv_xor_slot_cleanup() to incorrectly
dealocate the destination buffer. This is fixed as well, since the deallocation
is done in mv_xor_probe() (with correct flags) now:
mv_xor mv_xor.0: DMA-API: device driver frees DMA memory with different
direction [device address=0x1dea4000] [size=4096 bytes] [mapped with
DMA_FROM_DEVICE] [unmapped with DMA_BIDIRECTIONAL]
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/dma/mv_xor.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index 39387df..f642d8b 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -946,7 +946,7 @@ static int mv_xor_memcpy_self_test(struct mv_xor_chan
*mv_chan)
tx = mv_xor_prep_dma_memcpy(dma_chan, dest_dma, src_dma,
MV_XOR_TEST_SIZE,
DMA_COMPL_SRC_UNMAP_SINGLE |
- DMA_COMPL_DEST_UNMAP_SINGLE);
+ DMA_COMPL_SKIP_DEST_UNMAP);
cookie = mv_xor_tx_submit(tx);
mv_xor_issue_pending(dma_chan);
async_tx_ack(tx);
@@ -962,6 +962,8 @@ static int mv_xor_memcpy_self_test(struct mv_xor_chan
*mv_chan)
dma_sync_single_for_cpu(dma_chan-device-dev, dest_dma,
MV_XOR_TEST_SIZE, DMA_FROM_DEVICE);
+ dma_unmap_single(dma_chan-device-dev, dest_dma, MV_XOR_TEST_SIZE,
+DMA_FROM_DEVICE);
if (memcmp(src, dest, MV_XOR_TEST_SIZE)) {
dev_err(dma_chan-device-dev,
Self-test copy failed compare, disabling\n);
@@ -1039,7 +1041,8 @@ mv_xor_xor_self_test(struct mv_xor_chan *mv_chan)
0, PAGE_SIZE, DMA_TO_DEVICE);
tx = mv_xor_prep_dma_xor(dma_chan, dest_dma, dma_srcs,
-MV_XOR_NUM_SRC_TEST, PAGE_SIZE, 0);
+MV_XOR_NUM_SRC_TEST, PAGE_SIZE,
+DMA_COMPL_SKIP_DEST_UNMAP);
cookie = mv_xor_tx_submit(tx);
mv_xor_issue_pending(dma_chan);
@@ -1056,6 +1059,8 @@ mv_xor_xor_self_test(struct mv_xor_chan *mv_chan)
dma_sync_single_for_cpu(dma_chan-device-dev, dest_dma,
PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_unmap_page(dma_chan-device-dev, dest_dma, PAGE_SIZE,
+ DMA_FROM_DEVICE);
for (i = 0; i (PAGE_SIZE / sizeof(u32)); i++) {
u32 *ptr = page_address(dest);
if (ptr[i] != cmp_word) {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] orion_wdt: Add platform alias
...so that it's automatically picked up on relevant platforms. Tested on Kirkwood-based GuruPlug. Signed-off-by: Lubomir Rintel lkund...@v3.sk --- drivers/watchdog/orion_wdt.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c index c20f96b..c9dd66f 100644 --- a/drivers/watchdog/orion_wdt.c +++ b/drivers/watchdog/orion_wdt.c @@ -223,4 +223,5 @@ MODULE_PARM_DESC(nowayout, Watchdog cannot be stopped once started (default= __MODULE_STRING(WATCHDOG_NOWAYOUT) )); MODULE_LICENSE(GPL); +MODULE_ALIAS(platform:orion_wdt); MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mv643xx_eth: Fix a possible deadlock upon ifdown
From: Lubomir Rintel lubo.rin...@gooddata.com
=
[ INFO: inconsistent lock state ]
3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: GW
-
inconsistent {IN-SOFTIRQ-W} - {SOFTIRQ-ON-W} usage.
NetworkManager/337 [HC0[0]:SC0[0]:HE1:SE1] takes:
(_xmit_ETHER#2){+.?...}, at: [bf07adfc] txq_reclaim+0x54/0x264 [mv643xx_eth]
{IN-SOFTIRQ-W} state was registered at:
[c0068480] __lock_acquire+0x5b4/0x17d0
[c0069d7c] lock_acquire+0x160/0x1e0
[c04f41a0] _raw_spin_lock+0x50/0x88
[c0407178] sch_direct_xmit+0x4c/0x2d4
[c03ec978] dev_queue_xmit+0x4b8/0x8d8
[c0492dc8] ip6_finish_output2+0x350/0x42c
[c04b7fd8] mld_sendpack+0x2d0/0x514
[c04b8834] mld_ifc_timer_expire+0x228/0x278
[c002afe8] call_timer_fn+0x140/0x33c
[c002bbf0] run_timer_softirq+0x278/0x32c
[c0024288] __do_softirq+0x16c/0x398
[c002488c] irq_exit+0x5c/0xc0
[c0009c64] handle_IRQ+0x6c/0x8c
[c04f5218] __irq_svc+0x38/0x80
[c0065684] lock_is_held+0x4/0x54
[c004d5a0] __might_sleep+0x44/0x228
[c04f25a4] down_read+0x28/0x88
[c0263c94] __copy_to_user_memcpy+0xa8/0x140
[c01374d0] seq_read+0x3ac/0x474
[c011623c] vfs_read+0xac/0x184
[c0116354] sys_read+0x40/0x6c
[c0008cc0] ret_fast_syscall+0x0/0x38
irq event stamp: 115119
hardirqs last enabled at (115119): [c04f4cf0]
_raw_spin_unlock_irqrestore+0x44/0x64
hardirqs last disabled at (115118): [c04f430c]
_raw_spin_lock_irqsave+0x28/0xa0
softirqs last enabled at (114880): [c00243d4] __do_softirq+0x2b8/0x398
softirqs last disabled at (114873): [c002488c] irq_exit+0x5c/0xc0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_xmit_ETHER#2);
Interrupt
lock(_xmit_ETHER#2);
*** DEADLOCK ***
1 lock held by NetworkManager/337:
#0: (rtnl_mutex){+.+.+.}, at: [c03fad04] rtnetlink_rcv+0x14/0x2c
stack backtrace:
[c000f5a8] (unwind_backtrace+0x0/0x124) from [c04ebea8]
(print_usage_bug.part.29+0x20c/0x26c)
[c04ebea8] (print_usage_bug.part.29+0x20c/0x26c) from [c0067cc4]
(mark_lock+0x404/0x60c)
[c0067cc4] (mark_lock+0x404/0x60c) from [c0068504]
(__lock_acquire+0x638/0x17d0)
[c0068504] (__lock_acquire+0x638/0x17d0) from [c0069d7c]
(lock_acquire+0x160/0x1e0)
[c0069d7c] (lock_acquire+0x160/0x1e0) from [c04f41a0]
(_raw_spin_lock+0x50/0x88)
[c04f41a0] (_raw_spin_lock+0x50/0x88) from [bf07adfc]
(txq_reclaim+0x54/0x264 [mv643xx_eth])
[bf07adfc] (txq_reclaim+0x54/0x264 [mv643xx_eth]) from [bf07b03c]
(txq_deinit+0x30/0xec [mv643xx_eth])
[bf07b03c] (txq_deinit+0x30/0xec [mv643xx_eth]) from [bf07b21c]
(mv643xx_eth_stop+0x124/0x140 [mv643xx_eth])
[bf07b21c] (mv643xx_eth_stop+0x124/0x140 [mv643xx_eth]) from [c03e8bbc]
(__dev_close_many+0xb0/0xec)
[c03e8bbc] (__dev_close_many+0xb0/0xec) from [c03e8c28]
(__dev_close+0x30/0x44)
[c03e8c28] (__dev_close+0x30/0x44) from [c03ed154]
(__dev_change_flags+0x94/0x120)
[c03ed154] (__dev_change_flags+0x94/0x120) from [c03ed260]
(dev_change_flags+0x18/0x4c)
[c03ed260] (dev_change_flags+0x18/0x4c) from [c03fb174]
(do_setlink+0x2cc/0x7ac)
[c03fb174] (do_setlink+0x2cc/0x7ac) from [c03fc5ec]
(rtnl_newlink+0x26c/0x4a8)
[c03fc5ec] (rtnl_newlink+0x26c/0x4a8) from [c03fc104]
(rtnetlink_rcv_msg+0x280/0x29c)
[c03fc104] (rtnetlink_rcv_msg+0x280/0x29c) from [c041245c]
(netlink_rcv_skb+0x58/0xb4)
[c041245c] (netlink_rcv_skb+0x58/0xb4) from [c03fad10]
(rtnetlink_rcv+0x20/0x2c)
[c03fad10] (rtnetlink_rcv+0x20/0x2c) from [c0411dec]
(netlink_unicast+0x158/0x208)
[c0411dec] (netlink_unicast+0x158/0x208) from [c0412254]
(netlink_sendmsg+0x310/0x3c0)
[c0412254] (netlink_sendmsg+0x310/0x3c0) from [c03d209c]
(sock_sendmsg+0xa8/0xd0)
[c03d209c] (sock_sendmsg+0xa8/0xd0) from [c03d2314]
(__sys_sendmsg+0x1d8/0x280)
[c03d2314] (__sys_sendmsg+0x1d8/0x280) from [c03d4054]
(sys_sendmsg+0x44/0x68)
[c03d4054] (sys_sendmsg+0x44/0x68) from [c0008cc0]
(ret_fast_syscall+0x0/0x38)
---
drivers/net/ethernet/marvell/mv643xx_eth.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 84c1326..67a3e78 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -943,7 +943,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget,
int force)
struct netdev_queue *nq = netdev_get_tx_queue(mp-dev, txq-index);
int reclaimed;
- __netif_tx_lock(nq, smp_processor_id());
+ __netif_tx_lock_bh(nq);
reclaimed = 0;
while (reclaimed budget txq-tx_desc_count 0) {
@@ -989,7 +989,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget,
int force)
dev_kfree_skb(skb);
}
- __netif_tx_unlock(nq);
+ __netif_tx_unlock_bh(nq);
if (reclaimed budget)
mp-work_tx = ~(1 txq-index);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
[PATCH] mv643xx_eth: Fix a possible deadlock upon ifdown
=
[ INFO: inconsistent lock state ]
3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: GW
-
inconsistent {IN-SOFTIRQ-W} - {SOFTIRQ-ON-W} usage.
NetworkManager/337 [HC0[0]:SC0[0]:HE1:SE1] takes:
(_xmit_ETHER#2){+.?...}, at: [bf07adfc] txq_reclaim+0x54/0x264 [mv643xx_eth]
{IN-SOFTIRQ-W} state was registered at:
[c0068480] __lock_acquire+0x5b4/0x17d0
[c0069d7c] lock_acquire+0x160/0x1e0
[c04f41a0] _raw_spin_lock+0x50/0x88
[c0407178] sch_direct_xmit+0x4c/0x2d4
[c03ec978] dev_queue_xmit+0x4b8/0x8d8
[c0492dc8] ip6_finish_output2+0x350/0x42c
[c04b7fd8] mld_sendpack+0x2d0/0x514
[c04b8834] mld_ifc_timer_expire+0x228/0x278
[c002afe8] call_timer_fn+0x140/0x33c
[c002bbf0] run_timer_softirq+0x278/0x32c
[c0024288] __do_softirq+0x16c/0x398
[c002488c] irq_exit+0x5c/0xc0
[c0009c64] handle_IRQ+0x6c/0x8c
[c04f5218] __irq_svc+0x38/0x80
[c0065684] lock_is_held+0x4/0x54
[c004d5a0] __might_sleep+0x44/0x228
[c04f25a4] down_read+0x28/0x88
[c0263c94] __copy_to_user_memcpy+0xa8/0x140
[c01374d0] seq_read+0x3ac/0x474
[c011623c] vfs_read+0xac/0x184
[c0116354] sys_read+0x40/0x6c
[c0008cc0] ret_fast_syscall+0x0/0x38
irq event stamp: 115119
hardirqs last enabled at (115119): [c04f4cf0]
_raw_spin_unlock_irqrestore+0x44/0x64
hardirqs last disabled at (115118): [c04f430c]
_raw_spin_lock_irqsave+0x28/0xa0
softirqs last enabled at (114880): [c00243d4] __do_softirq+0x2b8/0x398
softirqs last disabled at (114873): [c002488c] irq_exit+0x5c/0xc0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_xmit_ETHER#2);
Interrupt
lock(_xmit_ETHER#2);
*** DEADLOCK ***
1 lock held by NetworkManager/337:
#0: (rtnl_mutex){+.+.+.}, at: [c03fad04] rtnetlink_rcv+0x14/0x2c
stack backtrace:
[c000f5a8] (unwind_backtrace+0x0/0x124) from [c04ebea8]
(print_usage_bug.part.29+0x20c/0x26c)
[c04ebea8] (print_usage_bug.part.29+0x20c/0x26c) from [c0067cc4]
(mark_lock+0x404/0x60c)
[c0067cc4] (mark_lock+0x404/0x60c) from [c0068504]
(__lock_acquire+0x638/0x17d0)
[c0068504] (__lock_acquire+0x638/0x17d0) from [c0069d7c]
(lock_acquire+0x160/0x1e0)
[c0069d7c] (lock_acquire+0x160/0x1e0) from [c04f41a0]
(_raw_spin_lock+0x50/0x88)
[c04f41a0] (_raw_spin_lock+0x50/0x88) from [bf07adfc]
(txq_reclaim+0x54/0x264 [mv643xx_eth])
[bf07adfc] (txq_reclaim+0x54/0x264 [mv643xx_eth]) from [bf07b03c]
(txq_deinit+0x30/0xec [mv643xx_eth])
[bf07b03c] (txq_deinit+0x30/0xec [mv643xx_eth]) from [bf07b21c]
(mv643xx_eth_stop+0x124/0x140 [mv643xx_eth])
[bf07b21c] (mv643xx_eth_stop+0x124/0x140 [mv643xx_eth]) from [c03e8bbc]
(__dev_close_many+0xb0/0xec)
[c03e8bbc] (__dev_close_many+0xb0/0xec) from [c03e8c28]
(__dev_close+0x30/0x44)
[c03e8c28] (__dev_close+0x30/0x44) from [c03ed154]
(__dev_change_flags+0x94/0x120)
[c03ed154] (__dev_change_flags+0x94/0x120) from [c03ed260]
(dev_change_flags+0x18/0x4c)
[c03ed260] (dev_change_flags+0x18/0x4c) from [c03fb174]
(do_setlink+0x2cc/0x7ac)
[c03fb174] (do_setlink+0x2cc/0x7ac) from [c03fc5ec]
(rtnl_newlink+0x26c/0x4a8)
[c03fc5ec] (rtnl_newlink+0x26c/0x4a8) from [c03fc104]
(rtnetlink_rcv_msg+0x280/0x29c)
[c03fc104] (rtnetlink_rcv_msg+0x280/0x29c) from [c041245c]
(netlink_rcv_skb+0x58/0xb4)
[c041245c] (netlink_rcv_skb+0x58/0xb4) from [c03fad10]
(rtnetlink_rcv+0x20/0x2c)
[c03fad10] (rtnetlink_rcv+0x20/0x2c) from [c0411dec]
(netlink_unicast+0x158/0x208)
[c0411dec] (netlink_unicast+0x158/0x208) from [c0412254]
(netlink_sendmsg+0x310/0x3c0)
[c0412254] (netlink_sendmsg+0x310/0x3c0) from [c03d209c]
(sock_sendmsg+0xa8/0xd0)
[c03d209c] (sock_sendmsg+0xa8/0xd0) from [c03d2314]
(__sys_sendmsg+0x1d8/0x280)
[c03d2314] (__sys_sendmsg+0x1d8/0x280) from [c03d4054]
(sys_sendmsg+0x44/0x68)
[c03d4054] (sys_sendmsg+0x44/0x68) from [c0008cc0]
(ret_fast_syscall+0x0/0x38)
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
I've sent an incorrect version; resending with a proper signoff and headers
this time; sorry about that.
drivers/net/ethernet/marvell/mv643xx_eth.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 84c1326..67a3e78 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -943,7 +943,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget,
int force)
struct netdev_queue *nq = netdev_get_tx_queue(mp-dev, txq-index);
int reclaimed;
- __netif_tx_lock(nq, smp_processor_id());
+ __netif_tx_lock_bh(nq);
reclaimed = 0;
while (reclaimed budget txq-tx_desc_count 0) {
@@ -989,7 +989,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget,
int force)
dev_kfree_skb(skb);
}
- __netif_tx_unlock(nq);
+ __netif_tx_unlock_bh(nq);
if (reclaimed budget)
mp-work_tx = ~(1 txq-index
Re: [PATCH 2/2] dma: mv_xor: do not sync the DMA buffer after being deallocated
On Fri, 2013-01-04 at 17:10 +0100, Thomas Petazzoni wrote: Dear Lubomir Rintel, On Thu, 27 Dec 2012 20:23:48 +0100, Lubomir Rintel wrote: dma_sync_single_for_cpu(dma_chan-device-dev, dest_dma, MV_XOR_TEST_SIZE, DMA_FROM_DEVICE); + dma_unmap_single(dma_chan-device-dev, dest_dma, MV_XOR_TEST_SIZE, +DMA_FROM_DEVICE); I would assume that dma_unmap_single() implies a dma_sync_single_for_cpu() since you're unmapping the DMA buffer. So if you use dma_unmap_single(), I think you can remove the call to dma_sync_single_for_cpu(). Yes, it indeed seems to be the case (comment for arm_dma_unmap_page(): After this call, reads by the CPU to the buffer are guaranteed to see whatever the device wrote there.. dma_sync_single_for_cpu(dma_chan-device-dev, dest_dma, PAGE_SIZE, DMA_FROM_DEVICE); + dma_unmap_page(dma_chan-device-dev, dest_dma, PAGE_SIZE, + DMA_FROM_DEVICE); Ditto. Also, the mv_xor_memcpy_self_test() function not only dma_map_single() the destination buffer, but also the source buffer. So presumably, the source buffer should also be dma_unmap_single()'d. And for the mv_xor_xor_self_test() function, multiple source buffers are dma_map_page()'d, so they should all be dma_unmap_page()'d I guess, not only the destination buffer. Those get released by the mv_xor_run_tx_complete_actions() callback. I will follow up with an updated patch. Regards, Lubo -- 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/
sd8688 firmware location
Hi! btmrvl_sdio and libertas_sdio both use firmware files sd8688.bin and sd8688_helper.bin. In linux-firmware, they're present in libertas/ tree and (since 3d32a58b) libertas_sdio perfers loading it from there, while it is able to fallback to load it from linux-firmware root. btmrvl_sdio, on the other hand only looks in the root and ends up not being successful. Obviously, there are two solutions to the problem -- either teach btmrvl_sdio to look into libertas/, or move the files in linux-firmware tree. I don't really have a strong preference, though it probably makes less sense to keep in in libertas/, since the bluetooth hardware is not really marketed as Libertas. I'm following up with patches to linux and linux-firmware and I'd be very thankful if you could pick one (not both of them). Have a nice day! -- Lubomir Rintel o (\) -- 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] Bluetooth: btmrvl_sdio: look for sd8688 firmware in alternate place
linux-firmware ships the sd8688* firmware images that are shared with
libertas_sdio WiFi driver under libertas/. libertas_sdio looks in both places
and so should we.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/bluetooth/btmrvl_sdio.c | 24 ++--
drivers/bluetooth/btmrvl_sdio.h |6 --
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 9959d4c..494f921 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -83,22 +83,28 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_87xx = {
};
static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
- .helper = sd8688_helper.bin,
- .firmware = sd8688.bin,
+ .helper = libertas/sd8688_helper.bin,
+ .helper2= sd8688_helper.bin,
+ .firmware = libertas/sd8688.bin,
+ .firmware2 = sd8688.bin,
.reg= btmrvl_reg_8688,
.sd_blksz_fw_dl = 64,
};
static const struct btmrvl_sdio_device btmrvl_sdio_sd8787 = {
.helper = NULL,
+ .helper2= NULL,
.firmware = mrvl/sd8787_uapsta.bin,
+ .firmware2 = NULL,
.reg= btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
static const struct btmrvl_sdio_device btmrvl_sdio_sd8797 = {
.helper = NULL,
+ .helper2= NULL,
.firmware = mrvl/sd8797_uapsta.bin,
+ .firmware2 = NULL,
.reg= btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
@@ -260,6 +266,11 @@ static int btmrvl_sdio_download_helper(struct
btmrvl_sdio_card *card)
ret = request_firmware(fw_helper, card-helper,
card-func-dev);
+ if (ret 0 card-helper2) {
+ release_firmware(fw_helper);
+ ret = request_firmware(fw_helper, card-helper2,
+ card-func-dev);
+ }
if ((ret 0) || !fw_helper) {
BT_ERR(request_firmware(helper) failed, error code = %d,
ret);
@@ -360,6 +371,11 @@ static int btmrvl_sdio_download_fw_w_helper(struct
btmrvl_sdio_card *card)
ret = request_firmware(fw_firmware, card-firmware,
card-func-dev);
+ if (ret 0 card-firmware2) {
+ release_firmware(fw_firmware);
+ ret = request_firmware(fw_firmware, card-firmware2,
+ card-func-dev);
+ }
if ((ret 0) || !fw_firmware) {
BT_ERR(request_firmware(firmware) failed, error code = %d,
ret);
@@ -970,7 +986,9 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
if (id-driver_data) {
struct btmrvl_sdio_device *data = (void *) id-driver_data;
card-helper = data-helper;
+ card-helper2 = data-helper2;
card-firmware = data-firmware;
+ card-firmware2 = data-firmware2;
card-reg = data-reg;
card-sd_blksz_fw_dl = data-sd_blksz_fw_dl;
}
@@ -1186,6 +1204,8 @@ MODULE_DESCRIPTION(Marvell BT-over-SDIO driver ver
VERSION);
MODULE_VERSION(VERSION);
MODULE_LICENSE(GPL v2);
MODULE_FIRMWARE(sd8688_helper.bin);
+MODULE_FIRMWARE(libertas/sd8688_helper.bin);
MODULE_FIRMWARE(sd8688.bin);
+MODULE_FIRMWARE(libertas/sd8688.bin);
MODULE_FIRMWARE(mrvl/sd8787_uapsta.bin);
MODULE_FIRMWARE(mrvl/sd8797_uapsta.bin);
diff --git a/drivers/bluetooth/btmrvl_sdio.h b/drivers/bluetooth/btmrvl_sdio.h
index 43d35a6..4a5a019 100644
--- a/drivers/bluetooth/btmrvl_sdio.h
+++ b/drivers/bluetooth/btmrvl_sdio.h
@@ -84,7 +84,9 @@ struct btmrvl_sdio_card {
struct sdio_func *func;
u32 ioport;
const char *helper;
+ const char *helper2;
const char *firmware;
+ const char *firmware2;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
u8 rx_unit;
@@ -92,8 +94,8 @@ struct btmrvl_sdio_card {
};
struct btmrvl_sdio_device {
- const char *helper;
- const char *firmware;
+ const char *helper, *helper2;
+ const char *firmware, *firmware2;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Move sd8688*.bin images away from libertas tree
They are (unlike rest of sd8xxx images from libertas/ and mrvl/) not Libertas WiFi specific and are used for the bluetooth controller (btmrvl) which does not look for them in libertas/. This is fine for the WiFi driver that utilizes those, since it has always been looking in this place as well. Signed-off-by: Lubomir Rintel lkund...@v3.sk --- libertas/sd8688.bin = sd8688.bin | Bin 259172 - 259172 bytes libertas/sd8688_helper.bin = sd8688_helper.bin | Bin 2616 - 2616 bytes 2 files changed, 0 insertions(+), 0 deletions(-) rename libertas/sd8688.bin = sd8688.bin (100%) rename libertas/sd8688_helper.bin = sd8688_helper.bin (100%) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Bluetooth: btmrvl_sdio: look for sd8688 firmware in alternate place
On Tue, 2013-01-08 at 18:43 -0800, Bing Zhao wrote: linux-firmware ships the sd8688* firmware images that are shared with libertas_sdio WiFi driver under libertas/. libertas_sdio looks in both places and so should we. Signed-off-by: Lubomir Rintel lkund...@v3.sk --- drivers/bluetooth/btmrvl_sdio.c | 24 ++-- drivers/bluetooth/btmrvl_sdio.h |6 -- 2 files changed, 26 insertions(+), 4 deletions(-) NAK from me on this one. I do not want the driver to check two locations. That is what userspace can work around. If we want to unify the location between the WiFi driver and the Bluetooth driver, I am fine with that, but seriously, just pick one over the other. I do not care which one. The unified location is mrvl/ directory. We can probably move SD8688 firmware helper binaries to mrvl/ and have both drivers grab the images there? That would break existing setups, wouldn't it? I was under impression (commit 3d32a58b) that we care about compatibility here. Do we? -- Lubomir Rintel -- 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] [media] usbtv: Add S-Video input support
Alongside already existing Composite input.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
drivers/media/usb/usbtv/usbtv.c | 99 ---
1 files changed, 82 insertions(+), 17 deletions(-)
diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c
index 9165017..9b250a7 100644
--- a/drivers/media/usb/usbtv/usbtv.c
+++ b/drivers/media/usb/usbtv/usbtv.c
@@ -91,17 +91,78 @@ struct usbtv {
u32 frame_id;
int chunks_done;
+ enum {
+ USBTV_COMPOSITE_INPUT,
+ USBTV_SVIDEO_INPUT,
+ } input;
int iso_size;
unsigned int sequence;
struct urb *isoc_urbs[USBTV_ISOC_TRANSFERS];
};
-static int usbtv_setup_capture(struct usbtv *usbtv)
+static int usbtv_set_regs(struct usbtv *usbtv, const u16 regs[][2], int size)
{
int ret;
int pipe = usb_rcvctrlpipe(usbtv-udev, 0);
int i;
- static const u16 protoregs[][2] = {
+
+ for (i = 0; i size; i++) {
+ u16 index = regs[i][0];
+ u16 value = regs[i][1];
+
+ ret = usb_control_msg(usbtv-udev, pipe, USBTV_REQUEST_REG,
+ USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ value, index, NULL, 0, 0);
+ if (ret 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int usbtv_select_input(struct usbtv *usbtv, int input)
+{
+ int ret;
+
+ static const u16 composite[][2] = {
+ { USBTV_BASE + 0x0105, 0x0060 },
+ { USBTV_BASE + 0x011f, 0x00f2 },
+ { USBTV_BASE + 0x0127, 0x0060 },
+ { USBTV_BASE + 0x00ae, 0x0010 },
+ { USBTV_BASE + 0x0284, 0x00aa },
+ { USBTV_BASE + 0x0239, 0x0060 },
+ };
+
+ static const u16 svideo[][2] = {
+ { USBTV_BASE + 0x0105, 0x0010 },
+ { USBTV_BASE + 0x011f, 0x00ff },
+ { USBTV_BASE + 0x0127, 0x0060 },
+ { USBTV_BASE + 0x00ae, 0x0030 },
+ { USBTV_BASE + 0x0284, 0x0088 },
+ { USBTV_BASE + 0x0239, 0x0060 },
+ };
+
+ switch (input) {
+ case USBTV_COMPOSITE_INPUT:
+ ret = usbtv_set_regs(usbtv, composite, ARRAY_SIZE(composite));
+ break;
+ case USBTV_SVIDEO_INPUT:
+ ret = usbtv_set_regs(usbtv, svideo, ARRAY_SIZE(svideo));
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ if (!ret)
+ usbtv-input = input;
+
+ return ret;
+}
+
+static int usbtv_setup_capture(struct usbtv *usbtv)
+{
+ int ret;
+ static const u16 setup[][2] = {
/* These seem to enable the device. */
{ USBTV_BASE + 0x0008, 0x0001 },
{ USBTV_BASE + 0x01d0, 0x00ff },
@@ -189,16 +250,13 @@ static int usbtv_setup_capture(struct usbtv *usbtv)
{ USBTV_BASE + 0x024f, 0x0002 },
};
- for (i = 0; i ARRAY_SIZE(protoregs); i++) {
- u16 index = protoregs[i][0];
- u16 value = protoregs[i][1];
+ ret = usbtv_set_regs(usbtv, setup, ARRAY_SIZE(setup));
+ if (ret)
+ return ret;
- ret = usb_control_msg(usbtv-udev, pipe, USBTV_REQUEST_REG,
- USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- value, index, NULL, 0, 0);
- if (ret 0)
- return ret;
- }
+ ret = usbtv_select_input(usbtv, usbtv-input);
+ if (ret)
+ return ret;
return 0;
}
@@ -443,10 +501,17 @@ static int usbtv_querycap(struct file *file, void *priv,
static int usbtv_enum_input(struct file *file, void *priv,
struct v4l2_input *i)
{
- if (i-index 0)
+ switch (i-index) {
+ case USBTV_COMPOSITE_INPUT:
+ strlcpy(i-name, Composite, sizeof(i-name));
+ break;
+ case USBTV_SVIDEO_INPUT:
+ strlcpy(i-name, S-Video, sizeof(i-name));
+ break;
+ default:
return -EINVAL;
+ }
- strlcpy(i-name, Composite, sizeof(i-name));
i-type = V4L2_INPUT_TYPE_CAMERA;
i-std = V4L2_STD_525_60;
return 0;
@@ -486,15 +551,15 @@ static int usbtv_g_std(struct file *file, void *priv,
v4l2_std_id *norm)
static int usbtv_g_input(struct file *file, void *priv, unsigned int *i)
{
- *i = 0;
+ struct usbtv *usbtv = video_drvdata(file);
+ *i = usbtv-input;
return 0;
}
static int usbtv_s_input(struct file *file, void *priv, unsigned int i)
{
- if (i 0)
- return -EINVAL;
- return 0;
+ struct usbtv *usbtv = video_drvdata(file
Re: [PATCH v4] watchdog: Add Broadcom BCM2835 watchdog timer driver
Hi Wim, On Sun, 2013-05-26 at 16:22 +0200, Wim Van Sebroeck wrote: Hi Lubomir, On 03/27/2013 10:40 AM, Lubomir Rintel wrote: This adds a driver for watchdog timer hardware present on Broadcom BCM2835 SoC, used in Raspberry Pi and Roku 2 devices. Signed-off-by: Lubomir Rintel lkund...@v3.sk Signed-off-by: Dom Cobley popcorn...@gmail.com Those two s-o-b lines should be swapped, since if Dom did sign off on any part of this patch, he did it before you did. That said... I wonder if it's actually appropriate to include Dom's s-o-b here, since I don't think he really wrote this patch itself. I think you mentioned that you hadn't use much of the downstream driver except for some defines? To be clear, I mentioned the existence of the S-o-b line downstream simply to demonstrate that the commits you were getting information from had correctly followed the process described in Documentation/SubmittingPatches, and so it was OK to use that information while creating a GPL'd driver. So there are a couple of ways that this patch could have been created: 1) You took the downstream commit itself, cherry-picked it into the upstream kernel, modified it to suit upstream, and then submitted that. The modifications might be extensive, such as renaming the file, removing parts of the code that the upstream watchdog core now handles, adding some new features, fixing bugs, cleanup, etc.; whatever is needed to upstream the patch. In this case, I believe it would be appropriate to maintain any S-o-b lines from the original downstream commit, and add yours. But, I believe you should also (a) maintain the git author field from the original downstream commit (b) include a list of the changes you made to the patch in the commit description, so you can be blamed for them rather than the original author:-) 2) You read the downstream commit for information, but created a completely new driver for the upstream kernel, using the downstream driver just as a reference. In this case, I believe it's fine for the git author field to be you, and for the only s-o-b line present to be yours, since you really did write the patch from scratch. However, you should credit the downstream work in the (c) header and/or commit description. This current patch sees to be a slight hybrid of both approaches (you're listed as the git author, but have included Dom's s-o-b line on a patch I don't think he created, and wasn't directly derived from one he created). I'm not sure if I'm being too picky. I guess I'll leave it up to Wim Van Sebroeck, since he's the watchdog maintainer and would be the person who applies this patch. Can you create a patch v5 with yourselve as author and add the necessary (c) and references in it so that I can do the final review? (That is if situation 2 is indeed the case. If however it is situation 1 then we should get the original code and have that as a patch and then add a second patch with your modifications.). I'm still not sure what to do. For most part, the driver is written from scratch, since the original one was not utilizing recent enough frameworks (such as watchdog-core or device tree bindings). Thus the patch against the original driver would not make any sense at all. On the other hand, I've referred to the original driver for hardware information and copied a couple of defines as they are (such as SECS_TO_WDOG_TICKS), thus I figured out it's a required to include the original driver's sign-off and copyright information. Thus neither 1) nor 2) is the case, and I can't figure out myself what needs to be changed at this point. I'm wondering if you could help me decide? Thank you, -- Lubomir Rintel lkund...@v3.sk -- 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] hwrng: bcm2835: fix MODULE_LICENSE tag
On Tue, 2013-04-23 at 17:54 +0200, Arnd Bergmann wrote: The MODULE_LICENSE macro invocation must use either GPL or GPL v2, but not GPLv2 in order to be detected by the module loader. This fixes the allmodconfig build error: FATAL: modpost: GPL-incompatible module bcm2835-rng.ko uses GPL-only symbol 'platform_driver_unregister' Thank you, obviously a typo of mine that slipped through. I'm wondering if this could get queued for 3.10; it definitely can't do any harm. Acked-by: Lubomir Rintel lkund...@v3.sk Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Dom Cobley popcorn...@gmail.com Cc: Lubomir Rintel lkund...@v3.sk Cc: Stephen Warren swar...@wwwdotorg.org Cc: Matt Mackall m...@selenic.com Cc: linux-rpi-ker...@lists.infradead.org Cc: Herbert Xu herb...@gondor.apana.org.au --- drivers/char/hw_random/bcm2835-rng.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c index eb7f147..43577ca 100644 --- a/drivers/char/hw_random/bcm2835-rng.c +++ b/drivers/char/hw_random/bcm2835-rng.c @@ -110,4 +110,4 @@ module_platform_driver(bcm2835_rng_driver); MODULE_AUTHOR(Lubomir Rintel lkund...@v3.sk); MODULE_DESCRIPTION(BCM2835 Random Number Generator (RNG) driver); -MODULE_LICENSE(GPLv2); +MODULE_LICENSE(GPL v2); -- 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/3] pxa168_eth: Allocate receive queue initialized to zero
Zero pointer in rx_skb or tx_skb is how respective *_deinit() functions find out that a skb slot is unallocated. If *_init() functions unsuccessfully return after the allocation (e.g. when subsequent dma_alloc_coherent() is not successful), this would result in attempt to kfree() invalid pointers. Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Kosta Zertsekel konsz...@marvell.com Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/net/ethernet/marvell/pxa168_eth.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c index 339bb32..1c8af8b 100644 --- a/drivers/net/ethernet/marvell/pxa168_eth.c +++ b/drivers/net/ethernet/marvell/pxa168_eth.c @@ -1015,7 +1015,7 @@ static int rxq_init(struct net_device *dev) int rx_desc_num = pep-rx_ring_size; /* Allocate RX skb rings */ - pep-rx_skb = kmalloc(sizeof(*pep-rx_skb) * pep-rx_ring_size, + pep-rx_skb = kzalloc(sizeof(*pep-rx_skb) * pep-rx_ring_size, GFP_KERNEL); if (!pep-rx_skb) return -ENOMEM; @@ -1076,7 +1076,7 @@ static int txq_init(struct net_device *dev) int size = 0, i = 0; int tx_desc_num = pep-tx_ring_size; - pep-tx_skb = kmalloc(sizeof(*pep-tx_skb) * pep-tx_ring_size, + pep-tx_skb = kzalloc(sizeof(*pep-tx_skb) * pep-tx_ring_size, GFP_KERNEL); if (!pep-tx_skb) return -ENOMEM; -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mv643xx_eth: Allocate receive queue initialized to zero
Zero pointer in rx_skb is how respective rxq_deinit() finds out out that a skb slot is unallocated. If rxq_refill() fails (e.g. on OOM condition), subsequent teardown would result in an attempt to kfree() invalid pointers. Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Lennert Buytenhek buyt...@wantstofly.org Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/net/ethernet/marvell/mv643xx_eth.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c index 2ad1494..d1cbfb1 100644 --- a/drivers/net/ethernet/marvell/mv643xx_eth.c +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c @@ -1757,7 +1757,7 @@ static int rxq_init(struct mv643xx_eth_private *mp, int index) memset(rxq-rx_desc_area, 0, size); rxq-rx_desc_area_size = size; - rxq-rx_skb = kmalloc_array(rxq-rx_ring_size, sizeof(*rxq-rx_skb), + rxq-rx_skb = kcalloc(rxq-rx_ring_size, sizeof(*rxq-rx_skb), GFP_KERNEL); if (rxq-rx_skb == NULL) goto out_free; -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mv643xx_eth: Fix a DMA-API error handling warning
We check the failure status just prior to unmap, since it would be too much of
a hassle to roll back commands we already started to enqueue if we handled it
just after the map.
This way we at least avoid a lockup on reclaim, the card presumably didn't
succeed DMA-ing to a bogus address anyway.
[ cut here ]
WARNING: at lib/dma-debug.c:933 check_unmap+0x75c/0x840()
mv643xx_eth_port mv643xx_eth_port.0: DMA-API: device driver failed to check map
error[device address=0x1cc3f1c2] [size=90 bytes] [mapped as single]
Modules linked in:
bnep bluetooth rfkill marvell mv643xx_eth mv_cesa leds_gpio uinput mmc_block
sata_mv mvsdio mmc_core usb_storage
[c000f838] (unwind_backtrace+0x0/0x124) from [c001bbec]
(warn_slowpath_common+0x54/0x6c)
[c001bbec] (warn_slowpath_common+0x54/0x6c) from [c001bc9c]
(warn_slowpath_fmt+0x34/0x44)
[c001bc9c] (warn_slowpath_fmt+0x34/0x44) from [c0281040]
(check_unmap+0x75c/0x840)
[c0281040] (check_unmap+0x75c/0x840) from [c02811f0]
(debug_dma_unmap_page+0x64/0x70)
[c02811f0] (debug_dma_unmap_page+0x64/0x70) from [bf068fc0]
(txq_reclaim+0x218/0x264 [mv643xx_eth])
[bf068fc0] (txq_reclaim+0x218/0x264 [mv643xx_eth]) from [bf069854]
(mv643xx_eth_poll+0x2a8/0x6b8 [mv643xx_eth])
[bf069854] (mv643xx_eth_poll+0x2a8/0x6b8 [mv643xx_eth]) from [c040e808]
(net_rx_action+0x9c/0x338)
[c040e808] (net_rx_action+0x9c/0x338) from [c002483c]
(__do_softirq+0x16c/0x398)
[c002483c] (__do_softirq+0x16c/0x398) from [c0024e40] (irq_exit+0x5c/0xc0)
[c0024e40] (irq_exit+0x5c/0xc0) from [c0009ba4] (handle_IRQ+0x6c/0x8c)
[c0009ba4] (handle_IRQ+0x6c/0x8c) from [c05167b8] (__irq_svc+0x38/0x80)
[c05167b8] (__irq_svc+0x38/0x80) from [c02629e4] (memcpy+0x24/0x3a4)
---[ end trace 0c94555a37c67b61 ]---
Mapped at:
[c0281818] debug_dma_map_page+0x48/0x11c
[bf068494] mv643xx_eth_xmit+0x41c/0x5a8 [mv643xx_eth]
[c0410a6c] dev_hard_start_xmit+0x308/0x6cc
[c042c720] sch_direct_xmit+0x74/0x2d4
[c041148c] dev_queue_xmit+0x4b8/0x8dc
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 26 +++---
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index d1cbfb1..7e14c83 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -519,8 +519,13 @@ static int rxq_process(struct rx_queue *rxq, int budget)
if (rxq-rx_curr_desc == rxq-rx_ring_size)
rxq-rx_curr_desc = 0;
- dma_unmap_single(mp-dev-dev.parent, rx_desc-buf_ptr,
-rx_desc-buf_size, DMA_FROM_DEVICE);
+ if (dma_mapping_error(mp-dev-dev.parent, rx_desc-buf_ptr)) {
+ dev_err(mp-dev-dev.parent,
+ Receive buffer could not be mapped, skipping
unmap.\n);
+ } else {
+ dma_unmap_single(mp-dev-dev.parent, rx_desc-buf_ptr,
+rx_desc-buf_size, DMA_FROM_DEVICE);
+ }
rxq-rx_desc_count--;
rx++;
@@ -902,12 +907,19 @@ static int txq_reclaim(struct tx_queue *txq, int budget,
int force)
mp-dev-stats.tx_errors++;
}
- if (cmd_sts TX_FIRST_DESC) {
- dma_unmap_single(mp-dev-dev.parent, desc-buf_ptr,
-desc-byte_cnt, DMA_TO_DEVICE);
+ if (dma_mapping_error(mp-dev-dev.parent, desc-buf_ptr)) {
+ dev_err(mp-dev-dev.parent,
+ Transmit buffer could not be mapped, skipping
unmap.\n);
} else {
- dma_unmap_page(mp-dev-dev.parent, desc-buf_ptr,
- desc-byte_cnt, DMA_TO_DEVICE);
+ if (cmd_sts TX_FIRST_DESC) {
+ dma_unmap_single(mp-dev-dev.parent,
+ desc-buf_ptr, desc-byte_cnt,
+ DMA_TO_DEVICE);
+ } else {
+ dma_unmap_page(mp-dev-dev.parent,
+ desc-buf_ptr, desc-byte_cnt,
+ DMA_TO_DEVICE);
+ }
}
dev_kfree_skb(skb);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] watchdog: Add Broadcom BCM2835 watchdog timer driver
This adds a driver for watchdog timer hardware present on Broadcom BCM2835 SoC,
used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Tested-by: Stephen Warren swar...@wwwdotorg.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Wim Van Sebroeck w...@iguana.be
Cc: Guenter Roeck li...@roeck-us.net
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-watch...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
---
Changes for v2:
- Use per-device structure instead of global variables for lock and memory
base
- Fix default timeout setting
- Do not leak memory if probe fails
- Style fixes
- Split out defconfig into a separate commit
- Meaningful commit message with credit
Changes for v3:
- Add proper copyright notice to header
- Drop status constants, we don't use them
- Fix heartbeat parameter's type
- Log driver initialization message once the device is probed
Changes for v4:
- Drop an useless initializer
- Add a signoff from downstream
- Do not announce the driver to the log if we failed to probe
- Set platform data earlier and do not explicitly unset it
Changes for v5:
- Copyright clarification
.../bindings/watchdog/brcm,bcm2835-pm-wdog.txt |5 +
drivers/watchdog/Kconfig | 11 ++
drivers/watchdog/Makefile |1 +
drivers/watchdog/bcm2835_wdt.c | 189
4 files changed, 206 insertions(+), 0 deletions(-)
create mode 100644 drivers/watchdog/bcm2835_wdt.c
diff --git
a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
index d209366..f801d71 100644
--- a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
@@ -5,9 +5,14 @@ Required properties:
- compatible : should be brcm,bcm2835-pm-wdt
- reg : Specifies base physical address and size of the registers.
+Optional properties:
+
+- timeout-sec : Contains the watchdog timeout in seconds
+
Example:
watchdog {
compatible = brcm,bcm2835-pm-wdt;
reg = 0x7e10 0x28;
+ timeout-sec = 10;
};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e89fc31..c3d3b16 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1098,6 +1098,17 @@ config BCM63XX_WDT
To compile this driver as a loadable module, choose M here.
The module will be called bcm63xx_wdt.
+config BCM2835_WDT
+ tristate Broadcom BCM2835 hardware watchdog
+ depends on ARCH_BCM2835
+ select WATCHDOG_CORE
+ help
+ Watchdog driver for the built in watchdog hardware in Broadcom
+ BCM2835 SoC.
+
+ To compile this driver as a loadable module, choose M here.
+ The module will be called bcm2835_wdt.
+
config LANTIQ_WDT
tristate Lantiq SoC watchdog
depends on LANTIQ
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a300b94..1bf5675 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
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
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 000..61566fc
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,189 @@
+/*
+ * Watchdog driver for Broadcom BCM2835
+ *
+ * bcm2708_wdog driver written by Luke Diamand that was obtained from
+ * branch rpi-3.6.y of git://github.com/raspberrypi/linux.git was used
+ * as a hardware reference for the Broadcom BCM2835 watchdog timer.
+ *
+ * Copyright (C) 2013 Lubomir Rintel lkund...@v3.sk
+ *
+ * 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.
+ */
+
+#include linux/types.h
+#include linux/module.h
+#include linux/io.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+#include linux/of_address.h
+#include linux/miscdevice.h
+
+#define PM_RSTC0x1c
+#define PM_WDOG0x24
+
+#define PM_PASSWORD0x5a00
+
+#define PM_WDOG_TIME_SET 0x000f
+#define PM_RSTC_WRCFG_CLR 0xffcf
+#define PM_RSTC_WRCFG_SET 0x0030
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTC_RESET 0x0102
+
+#define SECS_TO_WDOG_TICKS(x) ((x) 16)
+#define WDOG_TICKS_TO_SECS(x) ((x) 16)
+
+struct
[PATCH] sysv: Add forgotten superblock lock init for v7 fs
Superblock lock was replaced with (un)lock_super() removal, but left uninitialized for Seventh Edition UNIX filesystem in the following commit (3.7): c07cb01 sysv: drop lock/unlock super Signed-off-by: Lubomir Rintel lkund...@v3.sk --- fs/sysv/super.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/sysv/super.c b/fs/sysv/super.c index d0c6a00..eda1095 100644 --- a/fs/sysv/super.c +++ b/fs/sysv/super.c @@ -487,6 +487,7 @@ static int v7_fill_super(struct super_block *sb, void *data, int silent) sbi-s_sb = sb; sbi-s_block_base = 0; sbi-s_type = FSTYPE_V7; + mutex_init(sbi-s_lock); sb-s_fs_info = sbi; sb_set_blocksize(sb, 512); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] jbd: Lower severity of aborted journal from EMERG to CRIT
According to Documentation/kernel-parameters.txt, KERN_EMERG is reserved for
events that render system unusable.
This is hardly the case in case of flash memory stick hardware removal without
umounting. Syslog is often configured to forward messages with EMERG severity
to all logged-in terminals, often causing unnecessary noise.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
fs/jbd/journal.c |2 +-
fs/jbd2/journal.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
index 2d04f9a..9dbc1b6 100644
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -605,7 +605,7 @@ out_unlock:
spin_unlock(journal-j_state_lock);
if (unlikely(is_journal_aborted(journal))) {
- printk(KERN_EMERG journal commit I/O error\n);
+ printk(KERN_CRIT journal commit I/O error\n);
err = -EIO;
}
return err;
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 5203264..2d1f53c 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -719,7 +719,7 @@ int jbd2_log_wait_commit(journal_t *journal, tid_t tid)
read_unlock(journal-j_state_lock);
if (unlikely(is_journal_aborted(journal))) {
- printk(KERN_EMERG journal commit I/O error\n);
+ printk(KERN_CRIT journal commit I/O error\n);
err = -EIO;
}
return err;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] drm/radeon: Don't limit fb console on 32M cards to 8 bpp
The comment suggests that intention was to limit 16M cards to save memory while code did something a bit different. 32bpp is a lot more useful with today's apps, such as Weston's fbdev backend and 32M cards are probably hardly used in apps where dedicating a bit more to pinned console would matter. Signed-off-by: Lubomir Rintel lkund...@v3.sk --- drivers/gpu/drm/radeon/radeon_fb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 665ced3..cef3bc7 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -344,7 +344,7 @@ int radeon_fbdev_init(struct radeon_device *rdev) int ret; /* select 8 bpp console on RN50 or 16MB cards */ - if (ASIC_IS_RN50(rdev) || rdev-mc.real_vram_size = (32*1024*1024)) + if (ASIC_IS_RN50(rdev) || rdev-mc.real_vram_size = (16*1024*1024)) bpp_sel = 8; rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gadgetfs: Initialize CHIP to NULL before UDC probe
Otherwise the value from the last probe would be retained that possibly is freed since (the UDC is removed) and therefore no longer relevant. Reproducible with the dummy UDC: modprobe dummy_hcd mount -t gadgetfs gadgetfs /dev/gadget umount /dev/gadget rmmod dummy_hcd mount -t gadgetfs gadgetfs /dev/gadget BUG: unable to handle kernel paging request at a066fd9d Call Trace: [811d0cd2] ? d_alloc_name+0x22/0x50 [812b74dc] ? selinux_d_instantiate+0x1c/0x20 [a067d687] gadgetfs_create_file+0x27/0xa0 [gadgetfs] [a067da70] ? setup_req.isra.4+0x80/0x80 [gadgetfs] [a067dbac] gadgetfs_fill_super+0x13c/0x180 [gadgetfs] [811bc832] mount_single+0x92/0xc0 [a067d0f8] gadgetfs_mount+0x18/0x20 [gadgetfs] [811bc8f9] mount_fs+0x39/0x1b0 [8116b220] ? __alloc_percpu+0x10/0x20 [811d6da3] vfs_kern_mount+0x63/0xf0 [811d93be] do_mount+0x23e/0xac0 [811660eb] ? strndup_user+0x4b/0xf0 [811d9f63] SyS_mount+0x83/0xc0 [81695b69] system_call_fastpath+0x16/0x1b Signed-off-by: Lubomir Rintel lkund...@v3.sk --- drivers/usb/gadget/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/inode.c b/drivers/usb/gadget/inode.c index b94c049..ee15628 100644 --- a/drivers/usb/gadget/inode.c +++ b/drivers/usb/gadget/inode.c @@ -2046,6 +2046,7 @@ gadgetfs_fill_super (struct super_block *sb, void *opts, int silent) return -ESRCH; /* fake probe to determine $CHIP */ + CHIP = NULL; usb_gadget_probe_driver(probe_driver); if (!CHIP) return -ENODEV; -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [media] usbtv: Add driver for Fushicai USBTV007 video frame grabber
Reverse-engineered driver for cheapo video digitizer, made from observations of Windows XP driver. The protocol is not yet completely understood, so far we don't provide any controls, only support a single format out of three and don't support the audio device. Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-kernel@vger.kernel.org Cc: linux-me...@vger.kernel.org --- Hi everyone, this is my first experience with v4l2, videobuf2, usb and a video video hardware. Therefore, please be careful reviewing this as I could have made mistakes that are not likely to happen for more experienced people. I've not figured out the controls for the hardware yet, thus the huge set of unidentified register settings. I've been very unsuccessfully struggling with my Windows installation (the Windows driver for hardware was not usable enough with any other player than the cranky one shipped with it, crashing and deadlocking quite often). It seems quite possible to create a simpler directshow app that would just set the controls; and I plan to do that as time permits. Also, I the hardware uses V4L2_FIELD_ALTERNATE interlacing, but I couldn't make it work, so I'm doing deinterlacing in the driver, which is obviously not the right thing to do. Could anyone educate me on proper way of dealing with data interlaced this way? I could not find a decent example, and I'm not even sure what the sizes in format specification are (like, is the height after or before deinterlacing?). Thanks a lot! Lubo drivers/media/usb/Kconfig|1 + drivers/media/usb/Makefile |1 + drivers/media/usb/usbtv/Kconfig | 10 + drivers/media/usb/usbtv/Makefile |1 + drivers/media/usb/usbtv/usbtv.c | 723 ++ 5 files changed, 736 insertions(+), 0 deletions(-) create mode 100644 drivers/media/usb/usbtv/Kconfig create mode 100644 drivers/media/usb/usbtv/Makefile create mode 100644 drivers/media/usb/usbtv/usbtv.c diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig index 0a7d520..8e10267 100644 --- a/drivers/media/usb/Kconfig +++ b/drivers/media/usb/Kconfig @@ -17,6 +17,7 @@ source drivers/media/usb/zr364xx/Kconfig source drivers/media/usb/stkwebcam/Kconfig source drivers/media/usb/s2255/Kconfig source drivers/media/usb/sn9c102/Kconfig +source drivers/media/usb/usbtv/Kconfig endif if MEDIA_ANALOG_TV_SUPPORT diff --git a/drivers/media/usb/Makefile b/drivers/media/usb/Makefile index 7f51d7e..0935f47 100644 --- a/drivers/media/usb/Makefile +++ b/drivers/media/usb/Makefile @@ -20,3 +20,4 @@ obj-$(CONFIG_VIDEO_STK1160) += stk1160/ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/ obj-$(CONFIG_VIDEO_TM6000) += tm6000/ obj-$(CONFIG_VIDEO_EM28XX) += em28xx/ +obj-$(CONFIG_VIDEO_USBTV) += usbtv/ diff --git a/drivers/media/usb/usbtv/Kconfig b/drivers/media/usb/usbtv/Kconfig new file mode 100644 index 000..8864436 --- /dev/null +++ b/drivers/media/usb/usbtv/Kconfig @@ -0,0 +1,10 @@ +config VIDEO_USBTV +tristate USBTV007 video capture support +depends on VIDEO_DEV +select VIDEOBUF2_VMALLOC + +---help--- + This is a video4linux2 driver for USBTV007 based video capture devices. + + To compile this driver as a module, choose M here: the + module will be called usbtv diff --git a/drivers/media/usb/usbtv/Makefile b/drivers/media/usb/usbtv/Makefile new file mode 100644 index 000..28b872f --- /dev/null +++ b/drivers/media/usb/usbtv/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_USBTV) += usbtv.o diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c new file mode 100644 index 000..d165cb1 --- /dev/null +++ b/drivers/media/usb/usbtv/usbtv.c @@ -0,0 +1,723 @@ +/* + * Fushicai USBTV007 Video Grabber Driver + * + * Product web site: + * http://www.fushicai.com/products_detail/productId=d05449ee-b690-42f9-a661-aa7353894bed.html + * + * Following LWN articles were very useful in construction of this driver: + * Video4Linux2 API series: http://lwn.net/Articles/203924/ + * videobuf2 API explanation: http://lwn.net/Articles/447435/ + * Thanks go to Jonathan Corbet for providing this quality documentation. + * He is awesome. + * + * Copyright (c) 2013 Lubomir Rintel + * All rights reserved. + * No physical hadrware was harmed running Windows during the + * reverse-engineering activity + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions, and the following disclaimer, + *without modification. + * 2. The name of the author may not be used to endorse or promote products + *derived from this software without specific prior written permission. + * + * Alternatively, this software may be distributed under the terms of the + * GNU General Public License
Re: [PATCH] [media] usbtv: Add driver for Fushicai USBTV007 video frame grabber
On Mon, 2013-06-10 at 13:05 +0200, Hans Verkuil wrote:
Also, I the hardware uses V4L2_FIELD_ALTERNATE interlacing, but I couldn't
make
it work,
What didn't work exactly?
Both mplayer and gstream v4l2src displayed only half of an image. Not
sure which combinations of flags did I use anymore.
+static int usbtv_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *ctrl)
+{
+ return -EINVAL;
+}
Drop this ioctl. If it doesn't do anything, then don't specify it.
It actually does something; EINVAL here for any ctrl signals there's
zero controls.
When undefined, ENOTTY that is returned is considered invalid by
gstreamer source.
It doesn't look too bad :-) You're using all the latest frameworks which is
excellent.
Thanks for your time. I'll follow up with a new version that aims to
address all the concerns above (apart for the queryctl change, which
would break with gstreamer).
Can you run the v4l2-compliance tool and post the output of that tool?
Driver Info:
Driver name : usbtv
Card type : usbtv
Bus info : usb-:00:1d.7-5
Driver version: 3.10.0
Capabilities : 0x8501
Video Capture
Read/Write
Streaming
Device Capabilities
Device Caps : 0x0501
Video Capture
Read/Write
Streaming
Compliance test for device /dev/video1 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Control ioctls:
test VIDIOC_QUERYCTRL/MENU: OK
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
Total: 36, Succeeded: 36, Failed: 0, Warnings: 0
--
Lubomir Rintel lkund...@v3.sk
--
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] [media] usbtv: Add driver for Fushicai USBTV007 video frame grabber
Reverse-engineered driver for cheapo video digitizer, made from observations of Windows XP driver. The protocol is not yet completely understood, so far we don't provide any controls, only support a single format out of three and don't support the audio device. Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-kernel@vger.kernel.org Cc: linux-me...@vger.kernel.org --- Changes for v2: - Fix a typo in comment - Make prototype register settings static const - Solve parity calculation weirdness - Attempt to fix interlacing - Add timestamp to frames - [v4l2-compliance] Set pix format priv to 0 - Drop usbtv_*_fmt_vid_cap code duplication - [v4l2-compliance] Add vidioc_create_bufs - [v4l2-compliance] Use file handle priorities - Drop Driver from initial dev_info drivers/media/usb/Kconfig|1 + drivers/media/usb/Makefile |1 + drivers/media/usb/usbtv/Kconfig | 10 + drivers/media/usb/usbtv/Makefile |1 + drivers/media/usb/usbtv/usbtv.c | 715 ++ 5 files changed, 728 insertions(+), 0 deletions(-) create mode 100644 drivers/media/usb/usbtv/Kconfig create mode 100644 drivers/media/usb/usbtv/Makefile create mode 100644 drivers/media/usb/usbtv/usbtv.c diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig index 0a7d520..8e10267 100644 --- a/drivers/media/usb/Kconfig +++ b/drivers/media/usb/Kconfig @@ -17,6 +17,7 @@ source drivers/media/usb/zr364xx/Kconfig source drivers/media/usb/stkwebcam/Kconfig source drivers/media/usb/s2255/Kconfig source drivers/media/usb/sn9c102/Kconfig +source drivers/media/usb/usbtv/Kconfig endif if MEDIA_ANALOG_TV_SUPPORT diff --git a/drivers/media/usb/Makefile b/drivers/media/usb/Makefile index 7f51d7e..0935f47 100644 --- a/drivers/media/usb/Makefile +++ b/drivers/media/usb/Makefile @@ -20,3 +20,4 @@ obj-$(CONFIG_VIDEO_STK1160) += stk1160/ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/ obj-$(CONFIG_VIDEO_TM6000) += tm6000/ obj-$(CONFIG_VIDEO_EM28XX) += em28xx/ +obj-$(CONFIG_VIDEO_USBTV) += usbtv/ diff --git a/drivers/media/usb/usbtv/Kconfig b/drivers/media/usb/usbtv/Kconfig new file mode 100644 index 000..8864436 --- /dev/null +++ b/drivers/media/usb/usbtv/Kconfig @@ -0,0 +1,10 @@ +config VIDEO_USBTV +tristate USBTV007 video capture support +depends on VIDEO_DEV +select VIDEOBUF2_VMALLOC + +---help--- + This is a video4linux2 driver for USBTV007 based video capture devices. + + To compile this driver as a module, choose M here: the + module will be called usbtv diff --git a/drivers/media/usb/usbtv/Makefile b/drivers/media/usb/usbtv/Makefile new file mode 100644 index 000..28b872f --- /dev/null +++ b/drivers/media/usb/usbtv/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_USBTV) += usbtv.o diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c new file mode 100644 index 000..c2a02c2 --- /dev/null +++ b/drivers/media/usb/usbtv/usbtv.c @@ -0,0 +1,715 @@ +/* + * Fushicai USBTV007 Video Grabber Driver + * + * Product web site: + * http://www.fushicai.com/products_detail/productId=d05449ee-b690-42f9-a661-aa7353894bed.html + * + * Following LWN articles were very useful in construction of this driver: + * Video4Linux2 API series: http://lwn.net/Articles/203924/ + * videobuf2 API explanation: http://lwn.net/Articles/447435/ + * Thanks go to Jonathan Corbet for providing this quality documentation. + * He is awesome. + * + * Copyright (c) 2013 Lubomir Rintel + * All rights reserved. + * No physical hardware was harmed running Windows during the + * reverse-engineering activity + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions, and the following disclaimer, + *without modification. + * 2. The name of the author may not be used to endorse or promote products + *derived from this software without specific prior written permission. + * + * Alternatively, this software may be distributed under the terms of the + * GNU General Public License (GPL). + */ + +#include linux/init.h +#include linux/list.h +#include linux/module.h +#include linux/slab.h +#include linux/usb.h +#include linux/version.h +#include linux/videodev2.h + +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/videobuf2-core.h +#include media/videobuf2-vmalloc.h + +/* Hardware. */ +#define USBTV_VIDEO_ENDP 0x81 +#define USBTV_BASE 0xc000 +#define USBTV_REQUEST_REG 12 + +/* Number of concurrent isochronous urbs submitted. + * Higher numbers was seen to overly saturate the USB bus. */ +#define USBTV_ISOC_TRANSFERS 16 +#define USBTV_ISOC_PACKETS 8 + +#define USBTV_WIDTH720 +#define USBTV_HEIGHT
[PATCH v3] [media] usbtv: Add driver for Fushicai USBTV007 video frame grabber
Reverse-engineered driver for cheapo video digitizer, made from observations of Windows XP driver. The protocol is not yet completely understood, so far we don't provide any controls, only support a single format out of three and don't support the audio device. Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-kernel@vger.kernel.org Cc: linux-me...@vger.kernel.org --- Changes for v2: - Fix a typo in comment - Make prototype register settings static const - Solve parity calculation weirdness - Attempt to fix interlacing - Add timestamp to frames - [v4l2-compliance] Set pix format priv to 0 - Drop usbtv_*_fmt_vid_cap code duplication - [v4l2-compliance] Add vidioc_create_bufs - [v4l2-compliance] Use file handle priorities - Drop Driver from initial dev_info Changes for v3: - Utilize ARRAY_SIZE - Drop queryctrl ioctl - Reduce default number of buffers to two - Remove unnecessary locking - video_set_drvdata() before video_register_device() diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig index 0a7d520..8e10267 100644 --- a/drivers/media/usb/Kconfig +++ b/drivers/media/usb/Kconfig @@ -17,6 +17,7 @@ source drivers/media/usb/zr364xx/Kconfig source drivers/media/usb/stkwebcam/Kconfig source drivers/media/usb/s2255/Kconfig source drivers/media/usb/sn9c102/Kconfig +source drivers/media/usb/usbtv/Kconfig endif if MEDIA_ANALOG_TV_SUPPORT diff --git a/drivers/media/usb/Makefile b/drivers/media/usb/Makefile index 7f51d7e..0935f47 100644 --- a/drivers/media/usb/Makefile +++ b/drivers/media/usb/Makefile @@ -20,3 +20,4 @@ obj-$(CONFIG_VIDEO_STK1160) += stk1160/ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/ obj-$(CONFIG_VIDEO_TM6000) += tm6000/ obj-$(CONFIG_VIDEO_EM28XX) += em28xx/ +obj-$(CONFIG_VIDEO_USBTV) += usbtv/ diff --git a/drivers/media/usb/usbtv/Kconfig b/drivers/media/usb/usbtv/Kconfig new file mode 100644 index 000..8864436 --- /dev/null +++ b/drivers/media/usb/usbtv/Kconfig @@ -0,0 +1,10 @@ +config VIDEO_USBTV +tristate USBTV007 video capture support +depends on VIDEO_DEV +select VIDEOBUF2_VMALLOC + +---help--- + This is a video4linux2 driver for USBTV007 based video capture devices. + + To compile this driver as a module, choose M here: the + module will be called usbtv diff --git a/drivers/media/usb/usbtv/Makefile b/drivers/media/usb/usbtv/Makefile new file mode 100644 index 000..28b872f --- /dev/null +++ b/drivers/media/usb/usbtv/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_USBTV) += usbtv.o diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c new file mode 100644 index 000..d44fa63 --- /dev/null +++ b/drivers/media/usb/usbtv/usbtv.c @@ -0,0 +1,696 @@ +/* + * Fushicai USBTV007 Video Grabber Driver + * + * Product web site: + * http://www.fushicai.com/products_detail/productId=d05449ee-b690-42f9-a661-aa7353894bed.html + * + * Following LWN articles were very useful in construction of this driver: + * Video4Linux2 API series: http://lwn.net/Articles/203924/ + * videobuf2 API explanation: http://lwn.net/Articles/447435/ + * Thanks go to Jonathan Corbet for providing this quality documentation. + * He is awesome. + * + * Copyright (c) 2013 Lubomir Rintel + * All rights reserved. + * No physical hardware was harmed running Windows during the + * reverse-engineering activity + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions, and the following disclaimer, + *without modification. + * 2. The name of the author may not be used to endorse or promote products + *derived from this software without specific prior written permission. + * + * Alternatively, this software may be distributed under the terms of the + * GNU General Public License (GPL). + */ + +#include linux/init.h +#include linux/list.h +#include linux/module.h +#include linux/slab.h +#include linux/usb.h +#include linux/version.h +#include linux/videodev2.h + +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/videobuf2-core.h +#include media/videobuf2-vmalloc.h + +/* Hardware. */ +#define USBTV_VIDEO_ENDP 0x81 +#define USBTV_BASE 0xc000 +#define USBTV_REQUEST_REG 12 + +/* Number of concurrent isochronous urbs submitted. + * Higher numbers was seen to overly saturate the USB bus. */ +#define USBTV_ISOC_TRANSFERS 16 +#define USBTV_ISOC_PACKETS 8 + +#define USBTV_WIDTH720 +#define USBTV_HEIGHT 480 + +#define USBTV_CHUNK_SIZE 256 +#define USBTV_CHUNK240 +#define USBTV_CHUNKS (USBTV_WIDTH * USBTV_HEIGHT \ + / 2 / USBTV_CHUNK) + +/* Chunk header. */ +#define USBTV_MAGIC_OK
Re: [PATCH] [media] usbtv: Add driver for Fushicai USBTV007 video frame grabber
On Wed, 2013-06-12 at 09:49 +0200, Hans Verkuil wrote:
...
+static int usbtv_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *ctrl)
+{
+ return -EINVAL;
+}
Drop this ioctl. If it doesn't do anything, then don't specify it.
It actually does something; EINVAL here for any ctrl signals there's
zero controls.
When undefined, ENOTTY that is returned is considered invalid by
gstreamer source.
What version of gstreamer are you using? Looking at the gstreamer code it
seems that it can handle ENOTTY at least since September last year. Not
handling
ENOTTY is an application bug (there are other - rare - drivers that do not
have any controls) and as such I really don't like seeing a workaround like
this in a driver, especially since this seems like it should be working fine
with the latest gstreamer.
I was using GStreamer from RHEL6. I retried with Fedora 17 and it worked
fine.
Regards,
Lubo
--
Lubomir Rintel lkund...@v3.sk
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] [media] usbtv: Add driver for Fushicai USBTV007 video frame grabber
Reverse-engineered driver for cheapo video digitizer, made from observations of Windows XP driver. The protocol is not yet completely understood, so far we don't provide any controls, only support a single format out of three and don't support the audio device. Signed-off-by: Lubomir Rintel lkund...@v3.sk Acked-by: Hans Verkuil hans.verk...@cisco.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-kernel@vger.kernel.org Cc: linux-me...@vger.kernel.org --- Changes for v2: - Fix a typo in comment - Make prototype register settings static const - Solve parity calculation weirdness - Attempt to fix interlacing - Add timestamp to frames - [v4l2-compliance] Set pix format priv to 0 - Drop usbtv_*_fmt_vid_cap code duplication - [v4l2-compliance] Add vidioc_create_bufs - [v4l2-compliance] Use file handle priorities - Drop Driver from initial dev_info Changes for v3: - Utilize ARRAY_SIZE - Drop queryctrl ioctl - Reduce default number of buffers to two - Remove unnecessary locking - video_set_drvdata() before video_register_device() Changes for v4: - Fix default buffer count setting - Use strlcpy() instead of strncpy() drivers/media/usb/Kconfig|1 + drivers/media/usb/Makefile |1 + drivers/media/usb/usbtv/Kconfig | 10 + drivers/media/usb/usbtv/Makefile |1 + drivers/media/usb/usbtv/usbtv.c | 696 ++ 5 files changed, 709 insertions(+), 0 deletions(-) create mode 100644 drivers/media/usb/usbtv/Kconfig create mode 100644 drivers/media/usb/usbtv/Makefile create mode 100644 drivers/media/usb/usbtv/usbtv.c diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig index 0a7d520..8e10267 100644 --- a/drivers/media/usb/Kconfig +++ b/drivers/media/usb/Kconfig @@ -17,6 +17,7 @@ source drivers/media/usb/zr364xx/Kconfig source drivers/media/usb/stkwebcam/Kconfig source drivers/media/usb/s2255/Kconfig source drivers/media/usb/sn9c102/Kconfig +source drivers/media/usb/usbtv/Kconfig endif if MEDIA_ANALOG_TV_SUPPORT diff --git a/drivers/media/usb/Makefile b/drivers/media/usb/Makefile index 7f51d7e..0935f47 100644 --- a/drivers/media/usb/Makefile +++ b/drivers/media/usb/Makefile @@ -20,3 +20,4 @@ obj-$(CONFIG_VIDEO_STK1160) += stk1160/ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/ obj-$(CONFIG_VIDEO_TM6000) += tm6000/ obj-$(CONFIG_VIDEO_EM28XX) += em28xx/ +obj-$(CONFIG_VIDEO_USBTV) += usbtv/ diff --git a/drivers/media/usb/usbtv/Kconfig b/drivers/media/usb/usbtv/Kconfig new file mode 100644 index 000..8864436 --- /dev/null +++ b/drivers/media/usb/usbtv/Kconfig @@ -0,0 +1,10 @@ +config VIDEO_USBTV +tristate USBTV007 video capture support +depends on VIDEO_DEV +select VIDEOBUF2_VMALLOC + +---help--- + This is a video4linux2 driver for USBTV007 based video capture devices. + + To compile this driver as a module, choose M here: the + module will be called usbtv diff --git a/drivers/media/usb/usbtv/Makefile b/drivers/media/usb/usbtv/Makefile new file mode 100644 index 000..28b872f --- /dev/null +++ b/drivers/media/usb/usbtv/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_USBTV) += usbtv.o diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c new file mode 100644 index 000..bf43f87 --- /dev/null +++ b/drivers/media/usb/usbtv/usbtv.c @@ -0,0 +1,696 @@ +/* + * Fushicai USBTV007 Video Grabber Driver + * + * Product web site: + * http://www.fushicai.com/products_detail/productId=d05449ee-b690-42f9-a661-aa7353894bed.html + * + * Following LWN articles were very useful in construction of this driver: + * Video4Linux2 API series: http://lwn.net/Articles/203924/ + * videobuf2 API explanation: http://lwn.net/Articles/447435/ + * Thanks go to Jonathan Corbet for providing this quality documentation. + * He is awesome. + * + * Copyright (c) 2013 Lubomir Rintel + * All rights reserved. + * No physical hardware was harmed running Windows during the + * reverse-engineering activity + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions, and the following disclaimer, + *without modification. + * 2. The name of the author may not be used to endorse or promote products + *derived from this software without specific prior written permission. + * + * Alternatively, this software may be distributed under the terms of the + * GNU General Public License (GPL). + */ + +#include linux/init.h +#include linux/list.h +#include linux/module.h +#include linux/slab.h +#include linux/usb.h +#include linux/version.h +#include linux/videodev2.h + +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/videobuf2-core.h +#include media/videobuf2-vmalloc.h + +/* Hardware. */ +#define
[PATCH] [media] usbtv: Add support for PAL video source.
From: Georg Kaindl gkai...@mac.com
Signed-off-by: Georg Kaindl gkai...@mac.com
Tested-by: Lubomir Rintel lkund...@v3.sk
---
Hi,
this is a patch sent to me by Georg Kaindl, who uses it with ambi-tv [1]. It
looks fine to me and works well, please review and eventually pull it into the
media tree.
[1] https://github.com/gkaindl/ambi-tv
Thanks!
Lubo
drivers/media/usb/usbtv/usbtv.c | 174 ++-
1 files changed, 136 insertions(+), 38 deletions(-)
diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c
index 8a505a9..6222a4a 100644
--- a/drivers/media/usb/usbtv/usbtv.c
+++ b/drivers/media/usb/usbtv/usbtv.c
@@ -50,13 +50,8 @@
#define USBTV_ISOC_TRANSFERS 16
#define USBTV_ISOC_PACKETS 8
-#define USBTV_WIDTH720
-#define USBTV_HEIGHT 480
-
#define USBTV_CHUNK_SIZE 256
#define USBTV_CHUNK240
-#define USBTV_CHUNKS (USBTV_WIDTH * USBTV_HEIGHT \
- / 4 / USBTV_CHUNK)
/* Chunk header. */
#define USBTV_MAGIC_OK(chunk) ((be32_to_cpu(chunk[0]) 0xff00) \
@@ -65,6 +60,27 @@
#define USBTV_ODD(chunk) ((be32_to_cpu(chunk[0]) 0xf000) 15)
#define USBTV_CHUNK_NO(chunk) (be32_to_cpu(chunk[0]) 0x0fff)
+#define USBTV_TV_STD (V4L2_STD_525_60 | V4L2_STD_PAL)
+
+/* parameters for supported TV norms */
+struct usbtv_norm_params {
+ v4l2_std_id norm;
+ int cap_width, cap_height;
+};
+
+static struct usbtv_norm_params norm_params[] = {
+ {
+ .norm = V4L2_STD_525_60,
+ .cap_width = 720,
+ .cap_height = 480,
+ },
+ {
+ .norm = V4L2_STD_PAL,
+ .cap_width = 720,
+ .cap_height = 576,
+ }
+};
+
/* A single videobuf2 frame buffer. */
struct usbtv_buf {
struct vb2_buffer vb;
@@ -94,11 +110,38 @@ struct usbtv {
USBTV_COMPOSITE_INPUT,
USBTV_SVIDEO_INPUT,
} input;
+ v4l2_std_id norm;
+ int width, height;
+ int n_chunks;
int iso_size;
unsigned int sequence;
struct urb *isoc_urbs[USBTV_ISOC_TRANSFERS];
};
+static int usbtv_configure_for_norm(struct usbtv *usbtv, v4l2_std_id norm)
+{
+ int i, ret = 0;
+ struct usbtv_norm_params *params = NULL;
+
+ for (i = 0; i ARRAY_SIZE(norm_params); i++) {
+ if (norm_params[i].norm norm) {
+ params = norm_params[i];
+ break;
+ }
+ }
+
+ if (params) {
+ usbtv-width = params-cap_width;
+ usbtv-height = params-cap_height;
+ usbtv-n_chunks = usbtv-width * usbtv-height
+ / 4 / USBTV_CHUNK;
+ usbtv-norm = params-norm;
+ } else
+ ret = -EINVAL;
+
+ return ret;
+}
+
static int usbtv_set_regs(struct usbtv *usbtv, const u16 regs[][2], int size)
{
int ret;
@@ -158,6 +201,57 @@ static int usbtv_select_input(struct usbtv *usbtv, int
input)
return ret;
}
+static int usbtv_select_norm(struct usbtv *usbtv, v4l2_std_id norm)
+{
+ int ret;
+ static const u16 pal[][2] = {
+ { USBTV_BASE + 0x001a, 0x0068 },
+ { USBTV_BASE + 0x010e, 0x0072 },
+ { USBTV_BASE + 0x010f, 0x00a2 },
+ { USBTV_BASE + 0x0112, 0x00b0 },
+ { USBTV_BASE + 0x0117, 0x0001 },
+ { USBTV_BASE + 0x0118, 0x002c },
+ { USBTV_BASE + 0x012d, 0x0010 },
+ { USBTV_BASE + 0x012f, 0x0020 },
+ { USBTV_BASE + 0x024f, 0x0002 },
+ { USBTV_BASE + 0x0254, 0x0059 },
+ { USBTV_BASE + 0x025a, 0x0016 },
+ { USBTV_BASE + 0x025b, 0x0035 },
+ { USBTV_BASE + 0x0263, 0x0017 },
+ { USBTV_BASE + 0x0266, 0x0016 },
+ { USBTV_BASE + 0x0267, 0x0036 }
+ };
+
+ static const u16 ntsc[][2] = {
+ { USBTV_BASE + 0x001a, 0x0079 },
+ { USBTV_BASE + 0x010e, 0x0068 },
+ { USBTV_BASE + 0x010f, 0x009c },
+ { USBTV_BASE + 0x0112, 0x00f0 },
+ { USBTV_BASE + 0x0117, 0x },
+ { USBTV_BASE + 0x0118, 0x00fc },
+ { USBTV_BASE + 0x012d, 0x0004 },
+ { USBTV_BASE + 0x012f, 0x0008 },
+ { USBTV_BASE + 0x024f, 0x0001 },
+ { USBTV_BASE + 0x0254, 0x005f },
+ { USBTV_BASE + 0x025a, 0x0012 },
+ { USBTV_BASE + 0x025b, 0x0001 },
+ { USBTV_BASE + 0x0263, 0x001c },
+ { USBTV_BASE + 0x0266, 0x0011 },
+ { USBTV_BASE + 0x0267, 0x0005 }
+ };
+
+ ret = usbtv_configure_for_norm(usbtv, norm);
+
+ if (!ret) {
+ if (norm V4L2_STD_525_60)
+ ret = usbtv_set_regs(usbtv, ntsc, ARRAY_SIZE(ntsc
[PATCH] drm/radeon: Don't limit fb console on 32M cards to 8 bpp
The comment suggests that intention was to limit 16M cards to save memory while code did something a bit different. 32bpp is a lot more useful with today's apps, such as Weston's fbdev backend and 32M cards are probably hardly used in apps where dedicating a bit more to pinned console would matter. Signed-off-by: Lubomir Rintel lkund...@v3.sk --- drivers/gpu/drm/radeon/radeon_fb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 665ced3..cef3bc7 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -344,7 +344,7 @@ int radeon_fbdev_init(struct radeon_device *rdev) int ret; /* select 8 bpp console on RN50 or 16MB cards */ - if (ASIC_IS_RN50(rdev) || rdev-mc.real_vram_size = (32*1024*1024)) + if (ASIC_IS_RN50(rdev) || rdev-mc.real_vram_size = (16*1024*1024)) bpp_sel = 8; rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [media] usbtv: fix leak at failure path in usbtv_probe()
On Sat, 2014-05-24 at 00:47 +0400, Alexey Khoroshilov wrote: Error handling code in usbtv_probe() misses usb_put_dev(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru Acked-by: Lubomir Rintel lkund...@v3.sk Thank you! Lubo --- drivers/media/usb/usbtv/usbtv-core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/usb/usbtv/usbtv-core.c b/drivers/media/usb/usbtv/usbtv-core.c index 2f87ddfa469f..473fab81b602 100644 --- a/drivers/media/usb/usbtv/usbtv-core.c +++ b/drivers/media/usb/usbtv/usbtv-core.c @@ -91,6 +91,8 @@ static int usbtv_probe(struct usb_interface *intf, return 0; usbtv_video_fail: + usb_set_intfdata(intf, NULL); + usb_put_dev(usbtv-udev); kfree(usbtv); return ret; -- 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 RESEND] gadgetfs: Initialize CHIP to NULL before UDC probe
Otherwise the value from the last probe would be retained that possibly is freed since (the UDC is removed) and therefore no longer relevant. Reproducible with the dummy UDC: modprobe dummy_hcd mount -t gadgetfs gadgetfs /dev/gadget umount /dev/gadget rmmod dummy_hcd mount -t gadgetfs gadgetfs /dev/gadget BUG: unable to handle kernel paging request at a066fd9d Call Trace: [811d0cd2] ? d_alloc_name+0x22/0x50 [812b74dc] ? selinux_d_instantiate+0x1c/0x20 [a067d687] gadgetfs_create_file+0x27/0xa0 [gadgetfs] [a067da70] ? setup_req.isra.4+0x80/0x80 [gadgetfs] [a067dbac] gadgetfs_fill_super+0x13c/0x180 [gadgetfs] [811bc832] mount_single+0x92/0xc0 [a067d0f8] gadgetfs_mount+0x18/0x20 [gadgetfs] [811bc8f9] mount_fs+0x39/0x1b0 [8116b220] ? __alloc_percpu+0x10/0x20 [811d6da3] vfs_kern_mount+0x63/0xf0 [811d93be] do_mount+0x23e/0xac0 [811660eb] ? strndup_user+0x4b/0xf0 [811d9f63] SyS_mount+0x83/0xc0 [81695b69] system_call_fastpath+0x16/0x1b Signed-off-by: Lubomir Rintel lkund...@v3.sk --- drivers/usb/gadget/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/inode.c b/drivers/usb/gadget/inode.c index b94c049..ee15628 100644 --- a/drivers/usb/gadget/inode.c +++ b/drivers/usb/gadget/inode.c @@ -2046,6 +2046,7 @@ gadgetfs_fill_super (struct super_block *sb, void *opts, int silent) return -ESRCH; /* fake probe to determine $CHIP */ + CHIP = NULL; usb_gadget_probe_driver(probe_driver); if (!CHIP) return -ENODEV; -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] [media] usbtv: Fix deinterlacing
The image data is laid out a bit more weirdly and thus needs more work to
properly interlace. What we get from hardware is V4L2_FIELD_ALTERNATE, but
since userspace support for it is practically nonexistent, thus we make
V4L2_FIELD_INTERLACED from it so that it's more easily interpreted.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
drivers/media/usb/usbtv/usbtv.c | 36 +---
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c
index d44fa63..bdb87d7 100644
--- a/drivers/media/usb/usbtv/usbtv.c
+++ b/drivers/media/usb/usbtv/usbtv.c
@@ -57,7 +57,7 @@
#define USBTV_CHUNK_SIZE 256
#define USBTV_CHUNK240
#define USBTV_CHUNKS (USBTV_WIDTH * USBTV_HEIGHT \
- / 2 / USBTV_CHUNK)
+ / 4 / USBTV_CHUNK)
/* Chunk header. */
#define USBTV_MAGIC_OK(chunk) ((be32_to_cpu(chunk[0]) 0xff00) \
@@ -202,6 +202,26 @@ static int usbtv_setup_capture(struct usbtv *usbtv)
return 0;
}
+/* Copy data from chunk into a frame buffer, deinterlacing the data
+ * into every second line. Unfortunately, they don't align nicely into
+ * 720 pixel lines, as the chunk is 240 words long, which is 480 pixels.
+ * Therefore, we break down the chunk into two halves before copyting,
+ * so that we can interleave a line if needed. */
+static void usbtv_chunk_to_vbuf(u32 *frame, u32 *src, int chunk_no, int odd)
+{
+ int half;
+
+ for (half = 0; half 2; half++) {
+ int part_no = chunk_no * 2 + half;
+ int line = part_no / 3;
+ int part_index = (line * 2 + !odd) * 3 + (part_no % 3);
+
+ u32 *dst = frame[part_index * USBTV_CHUNK/2];
+ memcpy(dst, src, USBTV_CHUNK/2 * sizeof(*src));
+ src += USBTV_CHUNK/2;
+ }
+}
+
/* Called for each 256-byte image chunk.
* First word identifies the chunk, followed by 240 words of image
* data and padding. */
@@ -218,11 +238,6 @@ static void usbtv_image_chunk(struct usbtv *usbtv, u32
*chunk)
frame_id = USBTV_FRAME_ID(chunk);
odd = USBTV_ODD(chunk);
chunk_no = USBTV_CHUNK_NO(chunk);
-
- /* Deinterlace. TODO: Use interlaced frame format. */
- chunk_no = (chunk_no - chunk_no % 3) * 2 + chunk_no % 3;
- chunk_no += !odd * 3;
-
if (chunk_no = USBTV_CHUNKS)
return;
@@ -241,12 +256,11 @@ static void usbtv_image_chunk(struct usbtv *usbtv, u32
*chunk)
buf = list_first_entry(usbtv-bufs, struct usbtv_buf, list);
frame = vb2_plane_vaddr(buf-vb, 0);
- /* Copy the chunk. */
- memcpy(frame[chunk_no * USBTV_CHUNK], chunk[1],
- USBTV_CHUNK * sizeof(chunk[1]));
+ /* Copy the chunk data. */
+ usbtv_chunk_to_vbuf(frame, chunk[1], chunk_no, odd);
/* Last chunk in a frame, signalling an end */
- if (usbtv-frame_id chunk_no == USBTV_CHUNKS-1) {
+ if (odd chunk_no == USBTV_CHUNKS-1) {
int size = vb2_plane_size(buf-vb, 0);
buf-vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
@@ -518,7 +532,7 @@ static int usbtv_queue_setup(struct vb2_queue *vq,
if (*nbuffers == 0)
*nbuffers = 2;
*nplanes = 1;
- sizes[0] = USBTV_CHUNK * USBTV_CHUNKS * sizeof(u32);
+ sizes[0] = USBTV_WIDTH * USBTV_HEIGHT / 2 * sizeof(u32);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] [media] usbtv: Throw corrupted frames away
Ignore out of order data and mark incomplete buffers as errored.
This gets rid of annoying flicker due to occassional garbage from hardware.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
drivers/media/usb/usbtv/usbtv.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c
index bdb87d7..acd649c 100644
--- a/drivers/media/usb/usbtv/usbtv.c
+++ b/drivers/media/usb/usbtv/usbtv.c
@@ -89,6 +89,7 @@ struct usbtv {
/* Number of currently processed frame, useful find
* out when a new one begins. */
u32 frame_id;
+ int chunks_done;
int iso_size;
unsigned int sequence;
@@ -242,8 +243,13 @@ static void usbtv_image_chunk(struct usbtv *usbtv, u32
*chunk)
return;
/* Beginning of a frame. */
- if (chunk_no == 0)
+ if (chunk_no == 0) {
usbtv-frame_id = frame_id;
+ usbtv-chunks_done = 0;
+ }
+
+ if (usbtv-frame_id != frame_id)
+ return;
spin_lock_irqsave(usbtv-buflock, flags);
if (list_empty(usbtv-bufs)) {
@@ -258,16 +264,21 @@ static void usbtv_image_chunk(struct usbtv *usbtv, u32
*chunk)
/* Copy the chunk data. */
usbtv_chunk_to_vbuf(frame, chunk[1], chunk_no, odd);
+ usbtv-chunks_done++;
/* Last chunk in a frame, signalling an end */
if (odd chunk_no == USBTV_CHUNKS-1) {
int size = vb2_plane_size(buf-vb, 0);
+ enum vb2_buffer_state state = usbtv-chunks_done ==
+ USBTV_CHUNKS ?
+ VB2_BUF_STATE_DONE :
+ VB2_BUF_STATE_ERROR;
buf-vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
buf-vb.v4l2_buf.sequence = usbtv-sequence++;
v4l2_get_timestamp(buf-vb.v4l2_buf.timestamp);
vb2_set_plane_payload(buf-vb, 0, size);
- vb2_buffer_done(buf-vb, VB2_BUF_STATE_DONE);
+ vb2_buffer_done(buf-vb, state);
list_del(buf-list);
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: crystalhd: Do not mix integers and user pointers
Fixes the following sparse warnings:
crystalhd/crystalhd_lnx.c:227:61: warning: incorrect type in argument 3
(different base types)
crystalhd/crystalhd_lnx.c:227:61:expected unsigned long [unsigned] ua
crystalhd/crystalhd_lnx.c:227:61:got void [noderef] asn:1*ua
crystalhd/crystalhd_lnx.c:229:65: warning: incorrect type in argument 4
(different base types)
crystalhd/crystalhd_lnx.c:229:65:expected unsigned long [unsigned] ua
crystalhd/crystalhd_lnx.c:229:65:got void [noderef] asn:1*ua
Done for the Eudyptula challenge.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
drivers/staging/crystalhd/crystalhd_lnx.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/crystalhd/crystalhd_lnx.c
b/drivers/staging/crystalhd/crystalhd_lnx.c
index e6fb331..b2d3ec6 100644
--- a/drivers/staging/crystalhd/crystalhd_lnx.c
+++ b/drivers/staging/crystalhd/crystalhd_lnx.c
@@ -136,9 +136,9 @@ static inline int crystalhd_user_data(void __user *ud, void
*dr,
static int chd_dec_fetch_cdata(struct crystalhd_adp *adp,
struct crystalhd_ioctl_data *io, uint32_t m_sz,
- unsigned long ua)
+ void __user *ua)
{
- unsigned long ua_off;
+ void __user *ua_off;
int rc = 0;
if (!adp || !io || !ua || !m_sz) {
@@ -157,8 +157,8 @@ static int chd_dec_fetch_cdata(struct crystalhd_adp *adp,
rc = crystalhd_user_data((void __user *)ua_off, io-add_cdata,
io-add_cdata_sz, 0);
if (rc) {
- BCMLOG_ERR(failed to pull add_cdata sz:%x ua_off:%x\n,
- io-add_cdata_sz, (unsigned int)ua_off);
+ BCMLOG_ERR(failed to pull add_cdata sz:%x ua_off:%p\n,
+ io-add_cdata_sz, ua_off);
vfree(io-add_cdata);
io-add_cdata = NULL;
return -ENODATA;
@@ -169,9 +169,9 @@ static int chd_dec_fetch_cdata(struct crystalhd_adp *adp,
static int chd_dec_release_cdata(struct crystalhd_adp *adp,
struct crystalhd_ioctl_data *io,
-unsigned long ua)
+void __user *ua)
{
- unsigned long ua_off;
+ void __user *ua_off;
int rc;
if (!adp || !io || !ua) {
@@ -185,8 +185,8 @@ static int chd_dec_release_cdata(struct crystalhd_adp *adp,
io-add_cdata_sz, 1);
if (rc) {
BCMLOG_ERR(
- failed to push add_cdata sz:%x ua_off:%x\n,
-io-add_cdata_sz, (unsigned int)ua_off);
+ failed to push add_cdata sz:%x ua_off:%p\n,
+io-add_cdata_sz, ua_off);
return -ENODATA;
}
}
@@ -201,7 +201,7 @@ static int chd_dec_release_cdata(struct crystalhd_adp *adp,
static int chd_dec_proc_user_data(struct crystalhd_adp *adp,
struct crystalhd_ioctl_data *io,
- unsigned long ua, int set)
+ void __user *ua, int set)
{
int rc;
uint32_t m_sz = 0;
@@ -235,7 +235,7 @@ static int chd_dec_proc_user_data(struct crystalhd_adp *adp,
return rc;
}
-static int chd_dec_api_cmd(struct crystalhd_adp *adp, unsigned long ua,
+static int chd_dec_api_cmd(struct crystalhd_adp *adp, void __user *ua,
uint32_t uid, uint32_t cmd, crystalhd_cmd_proc func)
{
int rc;
@@ -266,12 +266,14 @@ static int chd_dec_api_cmd(struct crystalhd_adp *adp,
unsigned long ua,
}
/* API interfaces */
-static long chd_dec_ioctl(struct file *fd, unsigned int cmd, unsigned long ua)
+static long chd_dec_ioctl(struct file *fd, unsigned int cmd,
+ unsigned long __ua)
{
struct crystalhd_adp *adp = chd_get_adp();
crystalhd_cmd_proc cproc;
struct crystalhd_user *uc;
int ret;
+ void __user *ua = (void __user *)__ua;
if (!adp || !fd) {
BCMLOG_ERR(Invalid adp\n);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv7 2/5] mailbox: Introduce framework for mailbox
On Thu, 2014-06-12 at 22:31 +0530, Jassi Brar wrote:
Introduce common framework for client/protocol drivers and
controller drivers of Inter-Processor-Communication (IPC).
Client driver developers should have a look at
include/linux/mailbox_client.h to understand the part of
the API exposed to client drivers.
Similarly controller driver developers should have a look
at include/linux/mailbox_controller.h
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
+/**
+ * mbox_chan_received_data - A way for controller driver to push data
+ * received from remote to the upper layer.
+ * @chan: Pointer to the mailbox channel on which RX happened.
+ * @data: Client specific message typecasted as void *
It's mssg, not data.
+static struct mbox_chan *
+of_mbox_index_xlate(struct mbox_controller *mbox,
+ const struct of_phandle_args *sp)
The line break here is inconsistent with how the rest of the file is
formatted.
+/**
+ * struct mbox_controller - Controller of a class of communication chans
+ * @dev: Device backing this controller
+ * @controller_name: Literal name of the controller.
+ * @ops: Operators that work on each communication chan
+ * @chans: Null terminated array of chans.
This needs to be updated for current API. It's neither not NULL
terminated nor and array and num_chans documentation is missing.
+ * @txdone_irq: Indicates if the controller can report to API
when
+ * the last transmitted data was read by the remote.
+ * Eg, if it has some TX ACK irq.
+ * @txdone_poll: If the controller can read but not report the TX
+ * done. Ex, some register shows the TX status but
+ * no interrupt rises. Ignored if 'txdone_irq' is set.
+ * @txpoll_period: If 'txdone_poll' is in effect, the API polls for
+ * last TX's status after these many millisecs
+ */
+struct mbox_controller {
+ struct device *dev;
+ struct mbox_chan_ops *ops;
+ struct mbox_chan *chans;
+ int num_chans;
+ bool txdone_irq;
+ bool txdone_poll;
+ unsigned txpoll_period;
+ struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox,
+ const struct of_phandle_args *sp);
+ /*
+ * If the controller supports only TXDONE_BY_POLL,
+ * this timer polls all the links for txdone.
+ */
+ struct timer_list poll;
+ unsigned period;
+ /* Hook to add to the global controller list */
+ struct list_head node;
+};
Thank you,
Lubo
--
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: [PATCHv7 2/5] mailbox: Introduce framework for mailbox
On Thu, 2014-06-12 at 22:31 +0530, Jassi Brar wrote:
Introduce common framework for client/protocol drivers and
controller drivers of Inter-Processor-Communication (IPC).
Client driver developers should have a look at
include/linux/mailbox_client.h to understand the part of
the API exposed to client drivers.
Similarly controller driver developers should have a look
at include/linux/mailbox_controller.h
...
+struct mbox_chan *mbox_request_channel(const struct mbox_client *cl)
+{
...
+ chan-cl = cl;
drivers/mailbox/mailbox.c: In function ‘mbox_request_channel’:
drivers/mailbox/mailbox.c:361:11: warning: assignment discards ‘const’
qualifier from pointer target type [enabled by default]
chan-cl = cl;
--
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: [PATCHv7 0/5] Common Mailbox Framework
Hi Jassi, On Thu, 2014-06-12 at 22:28 +0530, Jassi Brar wrote: Hello, Here is the next revision of Mailbox framwork. I'm wondering whether you keep a Git tree with the framework we could keep the Raspberry Pi mailbox driver based on (bcm2835-mbox)? Also, from look at the API it does not seem to me that it's possible to synchronously (that is without a tx_done callback) collect a response when a message is sent with tx_block enabled. Equivalent to this: [1] bcm_mailbox_write(MBOX_CHAN_FB, vc4-mode_set_cmd_addr); bcm_mailbox_read(MBOX_CHAN_FB, val); [1] https://github.com/anholt/linux/commit/d6276826c1e94d942bd9f9dd4586b52197f13fb7#diff-fe03b88eaabd67668dcf9e116346793fR184 What's your opinion on that? Regards, Lubo -- 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] docs: Update FireWire debugging documentation
The old firewire stack is long dead now and a new version firescope has been released with support for current kernels. Cc: Rob Landley r...@landley.net Cc: Justin P. Mattock justinmatt...@gmail.com Cc: Bernhard Kaindl b...@suse.de Signed-off-by: Lubomir Rintel lkund...@v3.sk --- Documentation/debugging-via-ohci1394.txt | 24 +--- Documentation/power/basic-pm-debugging.txt | 2 +- 2 files changed, 10 insertions(+), 16 deletions(-) diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt index 611f5a5..14d1944 100644 --- a/Documentation/debugging-via-ohci1394.txt +++ b/Documentation/debugging-via-ohci1394.txt @@ -36,17 +36,13 @@ available (notebooks) or too slow for extensive debug information (like ACPI). Drivers --- -The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers -to a working state and enables physical DMA by default for all remote nodes. -This can be turned off by ohci1394's module parameter phys_dma=0. - -The alternative firewire-ohci driver in drivers/firewire uses filtered physical +The firewire-ohci driver in drivers/firewire uses filtered physical DMA by default, which is more secure but not suitable for remote debugging. Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu: Remote debugging over FireWire with firewire-ohci) to get unfiltered physical DMA. -Because ohci1394 and firewire-ohci depend on the PCI enumeration to be +Because the firewire-ohci driver depends on the PCI enumeration to be completed, an initialization routine which runs pretty early has been implemented for x86. This routine runs long before console_init() can be called, i.e. before the printk buffer appears on the console. @@ -64,7 +60,7 @@ be used to view the printk buffer of a remote machine, even with live update. Bernhard Kaindl enhanced firescope to support accessing 64-bit machines from 32-bit firescope and vice versa: -- http://halobates.de/firewire/firescope-0.2.2.tar.bz2 +- http://v3.sk/~lkundrak/firescope/ and he implemented fast system dump (alpha version - read README.txt): - http://halobates.de/firewire/firedump-0.1.tar.bz2 @@ -92,11 +88,11 @@ Step-by-step instructions for using firescope with early OHCI initialization: 1) Verify that your hardware is supported: - Load the ohci1394 or the fw-ohci module and check your kernel logs. + Load the firewire-ohci module and check your kernel logs. You should see a line similar to - ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[fe9ff800-fe9f] - ... Max Packet=[2048] IR/IT contexts=[4/8] + firewire_ohci :15:00.1: added OHCI v1.0 device as card 2, 4 IR + 4 IT + ... contexts, quirks 0x11 when loading the driver. If you have no supported controller, many PCI, CardBus and even some Express cards which are fully compliant to OHCI-1394 @@ -113,20 +109,18 @@ Step-by-step instructions for using firescope with early OHCI initialization: If an driver is running on both machines you should see a line like - ieee1394: Node added: ID:BUS[0-01:1023] GUID[0090270001b84bba] + firewire_core :15:00.1: created device fw1: GUID 00061b0020105917, S400 on both machines in the kernel log when the cable is plugged in and connects the two machines. 3) Test physical DMA using firescope: - On the debug host, - - load the raw1394 module, - - make sure that /dev/raw1394 is accessible, + On the debug host, make sure that /dev/fw* is accessible, then start firescope: $ firescope - Port 0 (ohci1394) opened, 2 nodes detected + Port 0 (/dev/fw1) opened, 2 nodes detected FireScope - diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt index e9b54de8..edeecd4 100644 --- a/Documentation/power/basic-pm-debugging.txt +++ b/Documentation/power/basic-pm-debugging.txt @@ -172,7 +172,7 @@ you can boot the kernel with the 'no_console_suspend' parameter and try to log kernel messages using the serial console. This may provide you with some information about the reasons of the suspend (resume) failure. Alternatively, it may be possible to use a FireWire port for debugging with firescope -(ftp://ftp.firstfloor.org/pub/ak/firescope/). On x86 it is also possible to +(http://v3.sk/~lkundrak/firescope/). On x86 it is also possible to use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt . 2. Testing suspend to RAM (STR) -- 1.8.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ohci: Turn remote DMA support into a module parameter
This makes it possible to debug kernel over FireWire without the need to
recompile it.
Cc: Stefan Richter stef...@s5r6.in-berlin.de
Cc: Dave Hansen dave.han...@linux.intel.com
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
Documentation/debugging-via-ohci1394.txt | 4 +---
drivers/firewire/ohci.c | 19 +++
lib/Kconfig.debug| 11 ---
3 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/Documentation/debugging-via-ohci1394.txt
b/Documentation/debugging-via-ohci1394.txt
index 14d1944..73473aa 100644
--- a/Documentation/debugging-via-ohci1394.txt
+++ b/Documentation/debugging-via-ohci1394.txt
@@ -38,9 +38,7 @@ Drivers
The firewire-ohci driver in drivers/firewire uses filtered physical
DMA by default, which is more secure but not suitable for remote debugging.
-Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
-Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
-DMA.
+Pass the remote_dma=1 parameter to the driver to get unfiltered physical DMA.
Because the firewire-ohci driver depends on the PCI enumeration to be
completed, an initialization routine which runs pretty early has been
diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index 6aa8a86..6313735 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -370,6 +370,10 @@ MODULE_PARM_DESC(debug, Verbose logging (default = 0
, busReset events = __stringify(OHCI_PARAM_DEBUG_BUSRESETS)
, or a combination, or all = -1));
+static bool param_remote_dma;
+module_param_named(remote_dma, param_remote_dma, bool, 0444);
+MODULE_PARM_DESC(remote_dma, Enable unfiltered remote DMA (default = 0));
+
static void log_irqs(struct fw_ohci *ohci, u32 evt)
{
if (likely(!(param_debug
@@ -2050,10 +2054,10 @@ static void bus_reset_work(struct work_struct *work)
be32_to_cpu(ohci-next_header));
}
-#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
- reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
- reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
-#endif
+ if (param_remote_dma) {
+ reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
+ reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
+ }
spin_unlock_irq(ohci-lock);
@@ -2587,13 +2591,13 @@ static int ohci_cancel_packet(struct fw_card *card,
struct fw_packet *packet)
static int ohci_enable_phys_dma(struct fw_card *card,
int node_id, int generation)
{
-#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
- return 0;
-#else
struct fw_ohci *ohci = fw_ohci(card);
unsigned long flags;
int n, ret = 0;
+ if (param_remote_dma)
+ return 0;
+
/*
* FIXME: Make sure this bitmask is cleared when we clear the busReset
* interrupt bit. Clear physReqResourceAllBuses on bus reset.
@@ -2622,7 +2626,6 @@ static int ohci_enable_phys_dma(struct fw_card *card,
spin_unlock_irqrestore(ohci-lock, flags);
return ret;
-#endif /* CONFIG_FIREWIRE_OHCI_REMOTE_DMA */
}
static u32 ohci_read_csr(struct fw_card *card, int csr_offset)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index db25707..dc30284 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1547,17 +1547,6 @@ config PROVIDE_OHCI1394_DMA_INIT
See Documentation/debugging-via-ohci1394.txt for more information.
-config FIREWIRE_OHCI_REMOTE_DMA
- bool Remote debugging over FireWire with firewire-ohci
- depends on FIREWIRE_OHCI
- help
- This option lets you use the FireWire bus for remote debugging
- with help of the firewire-ohci driver. It enables unfiltered
- remote DMA in firewire-ohci.
- See Documentation/debugging-via-ohci1394.txt for more information.
-
- If unsure, say N.
-
config BUILD_DOCSRC
bool Build targets in Documentation/ tree
depends on HEADERS_CHECK
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipv6: notify userspace when we added or changed an ipv6 token
On Mon, 2014-10-13 at 11:46 +0200, Daniel Borkmann wrote: On 10/10/2014 04:08 PM, Lubomir Rintel wrote: NetworkManager might want to know that it changed when the router advertisement arrives. Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Hannes Frederic Sowa han...@stressinduktion.org Cc: Daniel Borkmann dbork...@redhat.com --- net/ipv6/addrconf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 3e118df..3d11390 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -4528,6 +4528,7 @@ static int inet6_set_iftoken(struct inet6_dev *idev, struct in6_addr *token) } write_unlock_bh(idev-lock); + netdev_state_change(dev); I'm wondering why netdev_state_change()? You are probably only after the netlink notification that is being invoked, i.e. rtmsg_ifinfo(RTM_NEWLINK, ...), and don't strictly want to call the device notifier chain. Correct. I'll change it to just rtmsg_ifinfo(). Perhaps it might be better to define a new RTM_SETTOKEN, and just call inet6_ifinfo_notify(RTM_SETTOKEN, idev) as this is only idev specific anyway? I'm not really sure as that would require more userspace changes than necessary. addrconf_verify_rtnl(); return 0; } -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] saa7146: Create a device name before it's used
request_irq() uses it, tries to create a procfs file with an empty name otherwise. Link: https://bugzilla.kernel.org/show_bug.cgi?id=83771 Signed-off-by: Lubomir Rintel lkund...@v3.sk --- drivers/media/common/saa7146/saa7146_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/saa7146/saa7146_core.c b/drivers/media/common/saa7146/saa7146_core.c index 97afee6..4418119 100644 --- a/drivers/media/common/saa7146/saa7146_core.c +++ b/drivers/media/common/saa7146/saa7146_core.c @@ -364,6 +364,9 @@ static int saa7146_init_one(struct pci_dev *pci, const struct pci_device_id *ent goto out; } + /* create a nice device name */ + sprintf(dev-name, saa7146 (%d), saa7146_num); + DEB_EE(pci:%p\n, pci); err = pci_enable_device(pci); @@ -438,9 +441,6 @@ static int saa7146_init_one(struct pci_dev *pci, const struct pci_device_id *ent /* the rest + print status message */ - /* create a nice device name */ - sprintf(dev-name, saa7146 (%d), saa7146_num); - pr_info(found saa7146 @ mem %p (revision %d, irq %d) (0x%04x,0x%04x)\n, dev-mem, dev-revision, pci-irq, pci-subsystem_vendor, pci-subsystem_device); -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: bcm2835: Enable USB_DWC2_HOST in bcm2835_defconfig
It broke when host was moved into a separate module, in [47a1685f1]. Signed-off-by: Lubomir Rintel lkund...@v3.sk --- arch/arm/configs/bcm2835_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig index 0302d29..31cb073 100644 --- a/arch/arm/configs/bcm2835_defconfig +++ b/arch/arm/configs/bcm2835_defconfig @@ -98,6 +98,7 @@ CONFIG_LEDS_TRIGGER_TRANSIENT=y CONFIG_LEDS_TRIGGER_CAMERA=y CONFIG_STAGING=y CONFIG_USB_DWC2=y +CONFIG_USB_DWC2_HOST=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ipv6: notify userspace when we added or changed an ipv6 token
NetworkManager might want to know that it changed when the router advertisement arrives. Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Hannes Frederic Sowa han...@stressinduktion.org Cc: Daniel Borkmann dbork...@redhat.com --- net/ipv6/addrconf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 3e118df..3d11390 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -4528,6 +4528,7 @@ static int inet6_set_iftoken(struct inet6_dev *idev, struct in6_addr *token) } write_unlock_bh(idev-lock); + netdev_state_change(dev); addrconf_verify_rtnl(); return 0; } -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipv6: expose RFC4191 route preference via rtnetlink
On Tue, 2015-03-03 at 16:17 +0100, Jiri Pirko wrote:
Tue, Mar 03, 2015 at 11:01:52AM CET, lkund...@v3.sk wrote:
This makes it possible to retain the route preference when RAs are handled in
userspace.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
include/uapi/linux/rtnetlink.h | 1 +
net/ipv6/route.c | 16 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 5cc5d66..0671524 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -303,6 +303,7 @@ enum rtattr_type_t {
RTA_TABLE,
RTA_MARK,
RTA_MFC_STATS,
+RTA_PREF,
__RTA_MAX
};
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 47b5109..08f689e 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2401,6 +2401,7 @@ static const struct nla_policy
rtm_ipv6_policy[RTA_MAX+1] = {
[RTA_PRIORITY] = { .type = NLA_U32 },
[RTA_METRICS] = { .type = NLA_NESTED },
[RTA_MULTIPATH] = { .len = sizeof(struct rtnexthop) },
+[RTA_PREF] = { .type = NLA_U8 },
};
static int rtm_to_fib6_config(struct sk_buff *skb, struct nlmsghdr *nlh,
@@ -2408,6 +2409,7 @@ static int rtm_to_fib6_config(struct sk_buff *skb,
struct nlmsghdr *nlh,
{
struct rtmsg *rtm;
struct nlattr *tb[RTA_MAX+1];
+unsigned int pref;
int err;
err = nlmsg_parse(nlh, sizeof(*rtm), tb, RTA_MAX, rtm_ipv6_policy);
@@ -2483,6 +2485,14 @@ static int rtm_to_fib6_config(struct sk_buff *skb,
struct nlmsghdr *nlh,
cfg-fc_mp_len = nla_len(tb[RTA_MULTIPATH]);
}
+if (tb[RTA_PREF]) {
+pref = nla_get_u8(tb[RTA_PREF]);
+if (pref == ICMPV6_ROUTER_PREF_LOW ||
+pref == ICMPV6_ROUTER_PREF_MEDIUM ||
+pref == ICMPV6_ROUTER_PREF_HIGH)
+cfg-fc_flags |= RTF_PREF(pref);
Don't we want to do goto errout; in case pref is invalid ?
I'm not sure. If RFC 4191 suggests that the invalid value ought to be
ignored (treated as medium). It could be done in the userspace or the
userspace could just relay whatever it got in the NDP message to the
kernel.
What is your opinion on this?
Thank you,
Lubo
--
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] ipv6: expose RFC4191 route preference via rtnetlink
This makes it possible to retain the route preference when RAs are handled in
userspace.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
Changes since v1:
- In case an invalid value is specified treat it as ICMPV6_ROUTER_PREF_MEDIUM
include/uapi/linux/rtnetlink.h | 1 +
net/ipv6/route.c | 16 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 5cc5d66..0671524 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -303,6 +303,7 @@ enum rtattr_type_t {
RTA_TABLE,
RTA_MARK,
RTA_MFC_STATS,
+ RTA_PREF,
__RTA_MAX
};
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 47b5109..8b01d16 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2401,6 +2401,7 @@ static const struct nla_policy rtm_ipv6_policy[RTA_MAX+1]
= {
[RTA_PRIORITY] = { .type = NLA_U32 },
[RTA_METRICS] = { .type = NLA_NESTED },
[RTA_MULTIPATH] = { .len = sizeof(struct rtnexthop) },
+ [RTA_PREF] = { .type = NLA_U8 },
};
static int rtm_to_fib6_config(struct sk_buff *skb, struct nlmsghdr *nlh,
@@ -2408,6 +2409,7 @@ static int rtm_to_fib6_config(struct sk_buff *skb, struct
nlmsghdr *nlh,
{
struct rtmsg *rtm;
struct nlattr *tb[RTA_MAX+1];
+ unsigned int pref;
int err;
err = nlmsg_parse(nlh, sizeof(*rtm), tb, RTA_MAX, rtm_ipv6_policy);
@@ -2483,6 +2485,14 @@ static int rtm_to_fib6_config(struct sk_buff *skb,
struct nlmsghdr *nlh,
cfg-fc_mp_len = nla_len(tb[RTA_MULTIPATH]);
}
+ if (tb[RTA_PREF]) {
+ pref = nla_get_u8(tb[RTA_PREF]);
+ if (pref != ICMPV6_ROUTER_PREF_LOW
+ pref != ICMPV6_ROUTER_PREF_HIGH)
+ pref = ICMPV6_ROUTER_PREF_MEDIUM;
+ cfg-fc_flags |= RTF_PREF(pref);
+ }
+
err = 0;
errout:
return err;
@@ -2586,7 +2596,8 @@ static inline size_t rt6_nlmsg_size(void)
+ nla_total_size(4) /* RTA_PRIORITY */
+ RTAX_MAX * nla_total_size(4) /* RTA_METRICS */
+ nla_total_size(sizeof(struct rta_cacheinfo))
- + nla_total_size(TCP_CA_NAME_MAX); /* RTAX_CC_ALGO */
+ + nla_total_size(TCP_CA_NAME_MAX) /* RTAX_CC_ALGO */
+ + nla_total_size(1); /* RTA_PREF */
}
static int rt6_fill_node(struct net *net,
@@ -2727,6 +2738,9 @@ static int rt6_fill_node(struct net *net,
if (rtnl_put_cacheinfo(skb, rt-dst, 0, expires, rt-dst.error) 0)
goto nla_put_failure;
+ if (nla_put_u8(skb, RTA_PREF, IPV6_EXTRACT_PREF(rt-rt6i_flags)))
+ goto nla_put_failure;
+
nlmsg_end(skb, nlh);
return 0;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ipv6: expose RFC4191 route preference via rtnetlink
This makes it possible to retain the route preference when RAs are handled in
userspace.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
include/uapi/linux/rtnetlink.h | 1 +
net/ipv6/route.c | 16 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 5cc5d66..0671524 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -303,6 +303,7 @@ enum rtattr_type_t {
RTA_TABLE,
RTA_MARK,
RTA_MFC_STATS,
+ RTA_PREF,
__RTA_MAX
};
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 47b5109..08f689e 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2401,6 +2401,7 @@ static const struct nla_policy rtm_ipv6_policy[RTA_MAX+1]
= {
[RTA_PRIORITY] = { .type = NLA_U32 },
[RTA_METRICS] = { .type = NLA_NESTED },
[RTA_MULTIPATH] = { .len = sizeof(struct rtnexthop) },
+ [RTA_PREF] = { .type = NLA_U8 },
};
static int rtm_to_fib6_config(struct sk_buff *skb, struct nlmsghdr *nlh,
@@ -2408,6 +2409,7 @@ static int rtm_to_fib6_config(struct sk_buff *skb, struct
nlmsghdr *nlh,
{
struct rtmsg *rtm;
struct nlattr *tb[RTA_MAX+1];
+ unsigned int pref;
int err;
err = nlmsg_parse(nlh, sizeof(*rtm), tb, RTA_MAX, rtm_ipv6_policy);
@@ -2483,6 +2485,14 @@ static int rtm_to_fib6_config(struct sk_buff *skb,
struct nlmsghdr *nlh,
cfg-fc_mp_len = nla_len(tb[RTA_MULTIPATH]);
}
+ if (tb[RTA_PREF]) {
+ pref = nla_get_u8(tb[RTA_PREF]);
+ if (pref == ICMPV6_ROUTER_PREF_LOW ||
+ pref == ICMPV6_ROUTER_PREF_MEDIUM ||
+ pref == ICMPV6_ROUTER_PREF_HIGH)
+ cfg-fc_flags |= RTF_PREF(pref);
+ }
+
err = 0;
errout:
return err;
@@ -2586,7 +2596,8 @@ static inline size_t rt6_nlmsg_size(void)
+ nla_total_size(4) /* RTA_PRIORITY */
+ RTAX_MAX * nla_total_size(4) /* RTA_METRICS */
+ nla_total_size(sizeof(struct rta_cacheinfo))
- + nla_total_size(TCP_CA_NAME_MAX); /* RTAX_CC_ALGO */
+ + nla_total_size(TCP_CA_NAME_MAX) /* RTAX_CC_ALGO */
+ + nla_total_size(1); /* RTA_PREF */
}
static int rt6_fill_node(struct net *net,
@@ -2727,6 +2738,9 @@ static int rt6_fill_node(struct net *net,
if (rtnl_put_cacheinfo(skb, rt-dst, 0, expires, rt-dst.error) 0)
goto nla_put_failure;
+ if (nla_put_u8(skb, RTA_PREF, IPV6_EXTRACT_PREF(rt-rt6i_flags)))
+ goto nla_put_failure;
+
nlmsg_end(skb, nlh);
return 0;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kdbus: create /sys/fs/kdbus with sysfs_create_mount_point()
Since 0cbee99269 user-namespace pull, if a kdbusfs is mounted on a
location that's not created with sysfs_create_mount_point the user
namespaces are not allowed to mount their sysfs instances.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
---
Applies on top of char-misc/kdbus a36324913.
ipc/kdbus/main.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/ipc/kdbus/main.c b/ipc/kdbus/main.c
index 1ad4dc8..c2117ea 100644
--- a/ipc/kdbus/main.c
+++ b/ipc/kdbus/main.c
@@ -75,16 +75,13 @@
* '» struct kdbus_ep *ep (owned)
*/
-/* kdbus mount-point /sys/fs/kdbus */
-static struct kobject *kdbus_dir;
-
static int __init kdbus_init(void)
{
int ret;
- kdbus_dir = kobject_create_and_add(KBUILD_MODNAME, fs_kobj);
- if (!kdbus_dir)
- return -ENOMEM;
+ ret = sysfs_create_mount_point(fs_kobj, KBUILD_MODNAME);
+ if (ret)
+ return ret;
ret = kdbus_fs_init();
if (ret 0) {
@@ -96,14 +93,14 @@ static int __init kdbus_init(void)
return 0;
exit_dir:
- kobject_put(kdbus_dir);
+ sysfs_remove_mount_point(fs_kobj, KBUILD_MODNAME);
return ret;
}
static void __exit kdbus_exit(void)
{
kdbus_fs_exit();
- kobject_put(kdbus_dir);
+ sysfs_remove_mount_point(fs_kobj, KBUILD_MODNAME);
ida_destroy(kdbus_node_ida);
}
--
2.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/
Re: [PATCH 3/3] bonding: make device count build-time configurable
Hi Bjørn, On Tue, 2016-01-12 at 22:40 +0100, Bjørn Mork wrote: > David Miller <da...@davemloft.net> writes: > > From: Lubomir Rintel <lkund...@v3.sk> > > Date: Tue, 12 Jan 2016 18:19:49 +0100 > > > > > It's still an improvement to let the distributions decide if > > > they're > > > keeping "ip link add" broken or possibly affecting the scripts. > > > > That it is "broken" is your opinion. > > > > Document the behavior. It is not broken if the user is told to be > > mindful of what devices are created by default. > > > > There is way too much downside to changing this. > > Besides, distributions or admins can already change that behaviour if > they consider it "broken", using the existing module parameter: > > # echo "options bonding max_bonds=0" >/etc/modprobe.d/bonding.conf > # rmmod bonding > # ip link add bond0 type bond > (no error here) > > This method should be well known and understood by most users, > contrary > to some odd CONFIG_ build time setting. Yes, that's an alternative solution. We may end up shipping such configuration file, though it's not really clear what package should ship it (probably systemd?). I'd still prefer a kernel build-time option. It's more likely for distributions to do the decision they prefer when running make oldconfig. I'm assuming most distros would like to drop the legacy behavior; at this point noone probably relies on it anyway, given NetworkManager works around this by manually loading the module with the maxbonds=0 manually. Also, there's prior art to addressing this in kernel; the block loopback. > Bjørn Regards, Lubo
Re: [PATCH 2/3] dummy: make device count build-time configurable
Hi Stephen, On Tue, 2016-01-12 at 10:42 -0800, Stephen Hemminger wrote: > On Tue, 12 Jan 2016 12:57:33 +0100 > Lubomir Rintel <lkund...@v3.sk> wrote: > > > The devices can be created at run-time for quite some time already > > and the > > load-time device creation collides with attempts to create the > > device of > > the same name: > > > > # rmmod dummy > > # ip link add dummy0 type dummy > > RTNETLINK answers: File exists > > > > This is pretty much the same situation as was with the block loop > > devices > > which was solved by adding a build-time configuration that the > > distributions could use as they deem fit while keeping the default > > for > > compatibility. > > > > Let's do that here as well. > > > > Signed-off-by: Lubomir Rintel <lkund...@v3.sk> > > There is already a module parameter for this, so making it a compile > time option adds nothing. This option changes the defaults for the parameter. When the module gets autoloaded, the user doesn't get a chance to specify the module parameter and unwanted devices pop in. Worse even, the automatically created devices are likely to collide with what the user asked for. Lubo
Re: [PATCH v2 1/2] ARM: bcm2835: dt: Add the ethernet to the device trees
Hi Olivier,
On Fri, 2016-02-05 at 15:25 +0100, Olivier Blin wrote:
> Lubomir Rintel <lkund...@v3.sk> writes:
>
> > diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
> > b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
> [...]
> > @@ -33,3 +37,17 @@
> > brcm,function = ;
> > };
> > };
> > +
> > + {
> > + usb1@1 {
> > + compatible = "usb0424,9514";
> > + reg = <01>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ethernet: usbether@1 {
> > + compatible = "usb0424,ec00";
> > + reg = <01>;
> > + };
> > + };
> > +};
>
> Hi,
>
> This works for me, after making sure that your u-boot patch gets a
> chance to be run (unset usbethaddr from u-boot).
Thanks for that.
> Though, I am not really DT-literate, but shouldn't the ethernet block
> use the PID from the ethernet device?
> The usbether device is 9514 on RPi2, while ec00 is the hub.
Are you sure? I didn't check on RPi2, but I check the Models B and B+
and the ethernet device was 0xec00 on both. The driver attaches to that
product ID:
[lkundrak@odvarok linux]$ modinfo smsc95xx |grep EC
alias: usb:v0424pEC00d*dc*dsc*dp*ic*isc*ip*in*
[lkundrak@odvarok linux]$ modinfo smsc95xx |grep 9514
[lkundrak@odvarok linux]$
> Your patch works, but this works as well after swapping the PIDs.
>
> Thanks
Take care
Lubo
Re: [PATCH 1/3] ifb: make device count build-time configurable
On Tue, 2016-01-12 at 15:54 -0500, David Miller wrote: > From: Stephen Hemminger <step...@networkplumber.org> > Date: Tue, 12 Jan 2016 10:44:37 -0800 > > > On Tue, 12 Jan 2016 07:55:22 -0500 > > Jamal Hadi Salim <j...@mojatatu.com> wrote: > > > >> On 16-01-12 06:56 AM, Lubomir Rintel wrote: > >> > The devices can be created at run-time for quite some time > already and the > >> > load-time device creation collides with attempts to create the > device of > >> > the same name: > >> > > >> > # rmmod ifb > >> > # ip link add ifb0 type ifb > >> > RTNETLINK answers: File exists > >> > > >> > This is pretty much the same situation as was with the block > loop devices > >> > which was solved by adding a build-time configuration that the > >> > distributions could use as they deem fit while keeping the > default for > >> > compatibility. > >> > > >> > Let's do that here as well. > >> > > >> > Signed-off-by: Lubomir Rintel <lkund...@v3.sk> > >> > >> I guess module options are frowned upon. so: > > > > I would prefer that this were done with a module parameter, the > same as dummy. > > Only developers build their own configured kernels. Having the > value set later > > at module load time is preferable. > > I like this even less, it means tools behave significantly > differently > based upon what module options were passed to the kernel. > > Module options really should not change kernel behavior like this.. The module option is already there. It's defaults (creating the devices noone asked for and that potentially collide with what the user tried to create) are what we find bothersome. Lubo
[PATCH 0/2] Set the Raspberry Pi Ethernet MAC address
Hello, Looks like Peter Chen has submitted a patch that associates the USB device with the device-tree node. This is nice; we could use it to propagate the MAC address from firmware with minimal changes now, something that Arnd Bergmann suggested back in 2011 [2]. [1] USB: core: let USB device know device node https://patchwork.ozlabs.org/patch/572621/ [2] Re: RFC: Platform data for onboard USB assets https://lkml.org/lkml/2011/3/17/416 Tested to work fine on the B+ board with Peter's patch and a trivial change to u-boot so that the board code sets $ethaddr in addition to $usbethaddr for the dt fixup code. Lubo
[PATCH 2/2] ARM: bcm2835: dt: Add the ethernet to the device tree
The hub and the ethernet in its port 1 are hardwired on the board.
Compared to the adapters that can be plugged into the USB ports, this
one has no serial EEPROM to store its MAC. Nevertheless, the Raspberry Pi
has the MAC address for this adapter in its ROM, accessible from its
firmware.
U-Boot can read out the address and set the local-mac-address property of the
node with "ethernet" alias. Let's add the node so that U-Boot can do its
business.
Signed-off-by: Lubomir Rintel <lkund...@v3.sk>
---
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 18 ++
arch/arm/boot/dts/bcm283x.dtsi | 4 +++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index ef54050..32bbd2a 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -6,6 +6,10 @@
compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
model = "Raspberry Pi Model B+";
+ aliases {
+ ethernet =
+ }
+
leds {
act {
gpios = < 47 0>;
@@ -29,3 +33,17 @@
brcm,function = ;
};
};
+
+ {
+ usb1@01 {
+ compatible = "usb1d6b,0002";
+ reg = <01>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@01 {
+ compatible = "usb0424,9514";
+ reg = <01>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 971e741..bc5fde1 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -187,10 +187,12 @@
status = "disabled";
};
- usb@7e98 {
+ usb: usb@7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
interrupts = <1 9>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
};
--
2.5.0
[PATCH 1/2] net/smscx5xx: use the device tree for mac address
From: Arnd Bergmann <a...@arndb.de>
This takes the MAC address for smsc75xx/smsc95xx USB network devices
from a the device tree. This is required to get a usable persistent
address on the popular beagleboard, whose hardware designers
accidentally forgot that an ethernet device really requires an a
MAC address to be functional.
The smsc75xx and smsc95xx drivers are just two copies of the
same code, so better fix both.
Tested-by: Lubomir Rintel <lkund...@v3.sk>
Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
drivers/net/usb/smsc75xx.c | 10 ++
drivers/net/usb/smsc95xx.c | 10 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 30033db..b2e33e6 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "smsc75xx.h"
#define SMSC_CHIPNAME "smsc75xx"
@@ -761,6 +762,8 @@ static int smsc75xx_ioctl(struct net_device *netdev, struct
ifreq *rq, int cmd)
static void smsc75xx_init_mac_address(struct usbnet *dev)
{
+ const void *address;
+
/* try reading mac address from EEPROM */
if (smsc75xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev->net->dev_addr) == 0) {
@@ -772,6 +775,13 @@ static void smsc75xx_init_mac_address(struct usbnet *dev)
}
}
+ address = of_get_property(dev->udev->dev.of_node,
+ "local-mac-address", NULL);
+ if (address) {
+ memcpy(dev->net->dev_addr, address, ETH_ALEN);
+ return;
+ }
+
/* no eeprom, or eeprom values are invalid. generate random MAC */
eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to eth_random_addr\n");
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 66b3ab9..021b9ce 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "smsc95xx.h"
#define SMSC_CHIPNAME "smsc95xx"
@@ -765,6 +766,8 @@ static int smsc95xx_ioctl(struct net_device *netdev, struct
ifreq *rq, int cmd)
static void smsc95xx_init_mac_address(struct usbnet *dev)
{
+ const void *address;
+
/* try reading mac address from EEPROM */
if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev->net->dev_addr) == 0) {
@@ -775,6 +778,13 @@ static void smsc95xx_init_mac_address(struct usbnet *dev)
}
}
+ address = of_get_property(dev->udev->dev.of_node,
+ "local-mac-address", NULL);
+ if (address) {
+ memcpy(dev->net->dev_addr, address, ETH_ALEN);
+ return;
+ }
+
/* no eeprom, or eeprom values are invalid. generate random MAC */
eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to eth_random_addr\n");
--
2.5.0
Re: [PATCH 2/2] ARM: bcm2835: dt: Add the ethernet to the device tree
On Wed, 2016-02-03 at 16:02 +0100, Lubomir Rintel wrote:
> The hub and the ethernet in its port 1 are hardwired on the board.
>
> Compared to the adapters that can be plugged into the USB ports, this
> one has no serial EEPROM to store its MAC. Nevertheless, the
> Raspberry Pi
> has the MAC address for this adapter in its ROM, accessible from its
> firmware.
>
> U-Boot can read out the address and set the local-mac-address
> property of the
> node with "ethernet" alias. Let's add the node so that U-Boot can do
> its
> business.
>
> Signed-off-by: Lubomir Rintel <lkund...@v3.sk>
> ---
> arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 18 ++
> arch/arm/boot/dts/bcm283x.dtsi | 4 +++-
> 2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> index ef54050..32bbd2a 100644
> --- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> +++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> @@ -6,6 +6,10 @@
> compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
> model = "Raspberry Pi Model B+";
>
> + aliases {
> + ethernet =
> + }
I'm missing a semicolon here. I'll follow up with an updated version
once I get some feedback.
> +
> leds {
> act {
> gpios = < 47 0>;
> @@ -29,3 +33,17 @@
> brcm,function = ;
> };
> };
> +
> + {
> + usb1@01 {
> + compatible = "usb1d6b,0002";
> + reg = <01>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet: usbether@01 {
> + compatible = "usb0424,9514";
> + reg = <01>;
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/bcm283x.dtsi
> b/arch/arm/boot/dts/bcm283x.dtsi
> index 971e741..bc5fde1 100644
> --- a/arch/arm/boot/dts/bcm283x.dtsi
> +++ b/arch/arm/boot/dts/bcm283x.dtsi
> @@ -187,10 +187,12 @@
> status = "disabled";
> };
>
> - usb@7e98 {
> + usb: usb@7e98 {
> compatible = "brcm,bcm2835-usb";
> reg = <0x7e98 0x1>;
> interrupts = <1 9>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> };
> };
>
Re: [PATCH 2/2] ARM: bcm2835: dt: Add the ethernet to the device tree
On Wed, 2016-02-03 at 09:11 -0700, Stephen Warren wrote:
> On 02/03/2016 08:02 AM, Lubomir Rintel wrote:
> > The hub and the ethernet in its port 1 are hardwired on the board.
> >
> > Compared to the adapters that can be plugged into the USB ports,
> > this
> > one has no serial EEPROM to store its MAC. Nevertheless, the
> > Raspberry Pi
> > has the MAC address for this adapter in its ROM, accessible from
> > its
> > firmware.
> >
> > U-Boot can read out the address and set the local-mac-address
> > property of the
> > node with "ethernet" alias. Let's add the node so that U-Boot can
> > do its
> > business.
>
> Good to see we're getting a standard for this.
>
> Have you talked to the RPi Foundation about updating their binary
> bootloader to follow this protocol?
Not really. Adding Dom Cobley to the Cc list now.
They seem to be passing the MAC address on command line now and even
evaluating it before attempting a read out from the EEPROM. That sounds
like it would break if someone plugged another smsc95xx adapter into
one of the USB ports.
> I'll certainly ack changes to make
> this work for U-Boot, provided the USB core patch this relies upon
> is
> accepted.
Dom, if the changes mentioned in [1] get merged, you may want to add
the Ethernet device to your device trees too and drop the cmdline hack.
[1]
http://lists.infradead.org/pipermail/linux-rpi-kernel/2016-February/003207.html
>
> > diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> > b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
>
> > + {
> > + usb1@01 {
> > + compatible = "usb1d6b,0002";
> > + reg = <01>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ethernet: usbether@01 {
> > + compatible = "usb0424,9514";
> > + reg = <01>;
>
> Ib both unit addresses and both reg properties, I would expect "1"
> not
> "01" since there's usually no leading 0 fill for those.
Okay, will fix.
> I'm curious why the VID values for the hub and Ethernet device don't
> match since those are part of the same combo chip. Is there a typo
> there, or did SMSC really do something odd in HW?
Hm, I think I just did a sysfs walk to see how things are connected.
The ethernet USB id is certainly wrong though.
The 1d6d:2 id is of the root hub. There I either messed up the commit
message or the topology. I can't recheck now, but I'll give it another
look before I send and updated version.
Thanks,
Lubo
Re: [PATCH 2/2] ARM: bcm2835: dt: Add the ethernet to the device tree
On Thu, 2016-02-04 at 06:28 +, Peter Chen wrote:
>
> > Lubomir Rintel <lkund...@v3.sk> writes:
> >
> > > diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> > > b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> > > index ef54050..32bbd2a 100644
> > > --- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> > > +++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> >
> > Hi,
> >
> > Shouldn't this be common to all RPi1 B and RPi2 models, instead of
> > being
> > specific to just RPi B+?
> >
> > > + {
> > > + usb1@01 {
> > > + compatible = "usb1d6b,0002";
> > > + reg = <01>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + ethernet: usbether@01 {
> > > + compatible = "usb0424,9514";
> > > + reg = <01>;
> > > + };
> > > + };
> > > +};
> >
> > For reference, on RPi2:
>
> Using "lsusb -t" you may get bus topology.
>
> > Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
> > SMSC9512/9514 Fast Ethernet Adapter
>
> It is the ethernet device, you may need to change vid/pid in dts.
>
> > Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
> > SMC9514 Hub
>
> It is the hub device, you may need to change vid/pid in dts.
>
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> >
>
> It is root hub, it doesn't need to be described at dts.
Thank you; neither of the vid/pid pairs in the original submission is
okay. I'll follow up with an updated version.
I've also checked this on RPi B rev2; and I'll be including that one,
and the RPI2 too.
I can't find my rev1 RPi B; but maybe I can just do the same for the
same board. It would likely work, but I may get the vid/pid wrong if
it's different from rev2.
> Best regards,
> Peter
Thanks
Lubo
[PATCH 2/2] net/smscx5xx: use the device tree for mac address
From: Arnd Bergmann <a...@arndb.de>
This takes the MAC address for smsc75xx/smsc95xx USB network devices
from a the device tree. This is required to get a usable persistent
address on the popular beagleboard, whose hardware designers
accidentally forgot that an ethernet device really requires an a
MAC address to be functional.
The Raspberry Pi also ships smsc9514 without a serial EEPROM, stores the MAC
address in ROM accessible via VC4 firmware.
The smsc75xx and smsc95xx drivers are just two copies of the
same code, so better fix both.
[lkund...@v3.sk: updated to use of_get_property() as per suggestion from Arnd,
reworded the message and comments a bit]
Tested-by: Lubomir Rintel <lkund...@v3.sk>
Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
Changes since v1:
- Made use of_get_property()
- Amended comments/commit message a bit
drivers/net/usb/smsc75xx.c | 12 +++-
drivers/net/usb/smsc95xx.c | 12 +++-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 30033db..8266e27 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "smsc75xx.h"
#define SMSC_CHIPNAME "smsc75xx"
@@ -761,6 +762,8 @@ static int smsc75xx_ioctl(struct net_device *netdev, struct
ifreq *rq, int cmd)
static void smsc75xx_init_mac_address(struct usbnet *dev)
{
+ const u8 *mac_addr;
+
/* try reading mac address from EEPROM */
if (smsc75xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev->net->dev_addr) == 0) {
@@ -772,7 +775,14 @@ static void smsc75xx_init_mac_address(struct usbnet *dev)
}
}
- /* no eeprom, or eeprom values are invalid. generate random MAC */
+ /* maybe the boot loader passed the MAC address in devicetree */
+ mac_addr = of_get_mac_address (dev->udev->dev.of_node);
+ if (mac_addr) {
+ memcpy(dev->net->dev_addr, mac_addr, ETH_ALEN);
+ return;
+ }
+
+ /* no useful static MAC address found. generate a random one */
eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to eth_random_addr\n");
}
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 66b3ab9..623bb2e 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "smsc95xx.h"
#define SMSC_CHIPNAME "smsc95xx"
@@ -765,6 +766,8 @@ static int smsc95xx_ioctl(struct net_device *netdev, struct
ifreq *rq, int cmd)
static void smsc95xx_init_mac_address(struct usbnet *dev)
{
+ const u8 *mac_addr;
+
/* try reading mac address from EEPROM */
if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev->net->dev_addr) == 0) {
@@ -775,7 +778,14 @@ static void smsc95xx_init_mac_address(struct usbnet *dev)
}
}
- /* no eeprom, or eeprom values are invalid. generate random MAC */
+ /* maybe the boot loader passed the MAC address in devicetree */
+ mac_addr = of_get_mac_address (dev->udev->dev.of_node);
+ if (mac_addr) {
+ memcpy(dev->net->dev_addr, mac_addr, ETH_ALEN);
+ return;
+ }
+
+ /* no useful static MAC address found. generate a random one */
eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to eth_random_addr\n");
}
--
2.5.0
[PATCH v2 0/2] Set the Raspberry Pi Ethernet MAC address
Hi, an updated patch pair addressing the feedback. Originally submitted in [1]. Still not ready for merge as it needs the usb core [2] change and an U-Boot change [3] to work properly. [1] [PATCH 0/2] Set the Raspberry Pi Ethernet MAC address http://lists.infradead.org/pipermail/linux-rpi-kernel/2016-February/003207.html [2] USB: core: let USB device know device node https://patchwork.ozlabs.org/patch/572621/ [3] [U-Boot] [PATCH] rpi: set ethaddr as well http://lists.denx.de/pipermail/u-boot/2016-February/244663.html Regards, Lubo
[PATCH v2 1/2] ARM: bcm2835: dt: Add the ethernet to the device trees
The hub and the ethernet in its port 1 are hardwired on the board.
Compared to the adapters that can be plugged into the USB ports, this
one has no serial EEPROM to store its MAC. Nevertheless, the Raspberry Pi
has the MAC address for this adapter in its ROM, accessible from its
firmware.
U-Boot can read out the address and set the local-mac-address property of the
node with "ethernet" alias. Let's add the node so that U-Boot can do its
business.
Model B rev2 and Model B+ entries were verified by me, the hierarchy and
pid/vid pair for the Version 2 was provided by Olivier Blin. Original
Model B is a blind short, though very likely correct.
Signed-off-by: Lubomir Rintel <lkund...@v3.sk>
---
Changes since v1:
- s/@01/@1/ for ethernet and the hub
- Corrected the vid/pid pairs for hub and ethernet
- Added Model B rev2 and version 2 board changes
- Fixed a missing semicolon typo
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 18 ++
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 18 ++
arch/arm/boot/dts/bcm2835-rpi-b.dts | 18 ++
arch/arm/boot/dts/bcm2836-rpi-2-b.dts| 18 ++
arch/arm/boot/dts/bcm283x.dtsi | 4 +++-
5 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index ef54050..983353f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -6,6 +6,10 @@
compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
model = "Raspberry Pi Model B+";
+ aliases {
+ ethernet =
+ };
+
leds {
act {
gpios = < 47 0>;
@@ -29,3 +33,17 @@
brcm,function = ;
};
};
+
+ {
+ usb1@1 {
+ compatible = "usb0424,9514";
+ reg = <01>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb0424,ec00";
+ reg = <01>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index 86f1f2f..4b695a0 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -6,6 +6,10 @@
compatible = "raspberrypi,model-b-rev2", "brcm,bcm2835";
model = "Raspberry Pi Model B rev2";
+ aliases {
+ ethernet =
+ };
+
leds {
act {
gpios = < 16 1>;
@@ -22,3 +26,17 @@
brcm,function = ;
};
};
+
+ {
+ usb1@1 {
+ compatible = "usb0424,9512";
+ reg = <01>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb0424,ec00";
+ reg = <01>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts
b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 4859e9d..749648e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -6,6 +6,10 @@
compatible = "raspberrypi,model-b", "brcm,bcm2835";
model = "Raspberry Pi Model B";
+ aliases {
+ ethernet =
+ };
+
leds {
act {
gpios = < 16 1>;
@@ -16,3 +20,17 @@
{
pinctrl-0 = < >;
};
+
+ {
+ usb1@1 {
+ compatible = "usb0424,9512";
+ reg = <01>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb0424,ec00";
+ reg = <01>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index ff94666..2bc1a96 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -10,6 +10,10 @@
reg = <0 0x4000>;
};
+ aliases {
+ ethernet =
+ };
+
leds {
act {
gpios = < 47 0>;
@@ -33,3 +37,17 @@
brcm,function = ;
};
};
+
+ {
+ usb1@1 {
+ compatible = "usb0424,9514";
+ reg = <01>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb0424,ec00";
+ reg = <01>;
+
Re: [PATCH 1/2] net/smscx5xx: use the device tree for mac address
On Wed, 2016-02-03 at 16:23 +0100, Arnd Bergmann wrote:
> On Wednesday 03 February 2016 16:02:38 Lubomir Rintel wrote:
> > From: Arnd Bergmann <a...@arndb.de>
> >
> > This takes the MAC address for smsc75xx/smsc95xx USB network
> > devices
> > from a the device tree. This is required to get a usable persistent
> > address on the popular beagleboard, whose hardware designers
> > accidentally forgot that an ethernet device really requires an a
> > MAC address to be functional.
> >
> > The smsc75xx and smsc95xx drivers are just two copies of the
> > same code, so better fix both.
> >
> > Tested-by: Lubomir Rintel <lkund...@v3.sk>
> > Signed-off-by: Arnd Bergmann <a...@arndb.de>
> >
>
> I have no memory of writing this patch, where did you find it?
2011's discussion: https://lkml.org/lkml/2011/3/17/416
(Link also in the cover letter).
> The changelog sounds like I wrote it, so I assume it was me after
> all.
>
> > + address = of_get_property(dev->udev->dev.of_node,
> > + "local-mac-address", NULL);
> > + if (address) {
> > + memcpy(dev->net->dev_addr, address, ETH_ALEN);
> > + return;
> > + }
>
> This should use of_get_mac_address(), not an open-coded property
> lookup. The function was probably added after I wrote the
> the original patch.
Okay. Will fix that up once I get feedback for the devicetree part.
> Arnd
Thanks,
Lubo
[PATCH] net/smscx5xx: use the device tree for mac address
From: Arnd Bergmann <a...@arndb.de>
This takes the MAC address for smsc75xx/smsc95xx USB network devices
from a the device tree. This is required to get a usable persistent
address on the popular beagleboard, whose hardware designers
accidentally forgot that an ethernet device really requires an a
MAC address to be functional.
The Raspberry Pi also ships smsc9514 without a serial EEPROM, stores
the MAC address in ROM accessible via VC4 firmware.
The smsc75xx and smsc95xx drivers are just two copies of the
same code, so better fix both.
[lkund...@v3.sk: updated to use of_get_property() as per suggestion from
Arnd, reworded the message and comments a bit]
Tested-by: Lubomir Rintel <lkund...@v3.sk>
Signed-off-by: Arnd Bergmann <a...@arndb.de>
Signed-off-by: Lubomir Rintel <lkund...@v3.sk>
---
Changes since v2:
- Prefer DT address to EEPROM address. No practical difference since
the devices are not supposed to have both, but aligned with existing
practice (ixgbe, dm9000).
Changes since v1:
- Made use of_get_property()
- Amended comments/commit message a bit
drivers/net/usb/smsc75xx.c | 12 +++-
drivers/net/usb/smsc95xx.c | 12 +++-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 30033db..c369db9 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "smsc75xx.h"
#define SMSC_CHIPNAME "smsc75xx"
@@ -761,6 +762,15 @@ static int smsc75xx_ioctl(struct net_device *netdev,
struct ifreq *rq, int cmd)
static void smsc75xx_init_mac_address(struct usbnet *dev)
{
+ const u8 *mac_addr;
+
+ /* maybe the boot loader passed the MAC address in devicetree */
+ mac_addr = of_get_mac_address(dev->udev->dev.of_node);
+ if (mac_addr) {
+ memcpy(dev->net->dev_addr, mac_addr, ETH_ALEN);
+ return;
+ }
+
/* try reading mac address from EEPROM */
if (smsc75xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev->net->dev_addr) == 0) {
@@ -772,7 +782,7 @@ static void smsc75xx_init_mac_address(struct usbnet *dev)
}
}
- /* no eeprom, or eeprom values are invalid. generate random MAC */
+ /* no useful static MAC address found. generate a random one */
eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to eth_random_addr\n");
}
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 66b3ab9..2edc2bc 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "smsc95xx.h"
#define SMSC_CHIPNAME "smsc95xx"
@@ -765,6 +766,15 @@ static int smsc95xx_ioctl(struct net_device *netdev,
struct ifreq *rq, int cmd)
static void smsc95xx_init_mac_address(struct usbnet *dev)
{
+ const u8 *mac_addr;
+
+ /* maybe the boot loader passed the MAC address in devicetree */
+ mac_addr = of_get_mac_address(dev->udev->dev.of_node);
+ if (mac_addr) {
+ memcpy(dev->net->dev_addr, mac_addr, ETH_ALEN);
+ return;
+ }
+
/* try reading mac address from EEPROM */
if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev->net->dev_addr) == 0) {
@@ -775,7 +785,7 @@ static void smsc95xx_init_mac_address(struct usbnet *dev)
}
}
- /* no eeprom, or eeprom values are invalid. generate random MAC */
+ /* no useful static MAC address found. generate a random one */
eth_hw_addr_random(dev->net);
netif_dbg(dev, ifup, dev->net, "MAC address set to eth_random_addr\n");
}
--
2.7.4
Re: [PATCH v2 1/2] ARM: bcm2835: dt: Add the ethernet to the device trees
On Thu, 2016-04-28 at 18:26 +0200, Stefan Wahren wrote: > Hi Olivier > > Am 28.04.2016 um 14:52 schrieb Olivier Blin: > > > > Stephen Warren <swar...@wwwdotorg.org> writes: > > > > > > > > On 02/04/2016 12:36 AM, Lubomir Rintel wrote: > > > > > > > > The hub and the ethernet in its port 1 are hardwired on the > > > > board. > > > > > > > > Compared to the adapters that can be plugged into the USB > > > > ports, this > > > > one has no serial EEPROM to store its MAC. Nevertheless, the > > > > Raspberry Pi > > > > has the MAC address for this adapter in its ROM, accessible > > > > from its > > > > firmware. > > > > > > > > U-Boot can read out the address and set the local-mac-address > > > > property of the > > > > node with "ethernet" alias. Let's add the node so that U-Boot > > > > can do its > > > > business. > > > > > > > > Model B rev2 and Model B+ entries were verified by me, the > > > > hierarchy and > > > > pid/vid pair for the Version 2 was provided by Olivier Blin. > > > > Original > > > > Model B is a blind short, though very likely correct. > > > The series, > > > Tested-by: Stephen Warren <swar...@wwwdotorg.org> > > > > > > A few nits though... > > [...] > > > > Is this still being queued in some tree? > > Or does it need more fixes and a resubmit? > Yes, a V3 should address the comments from Peter and Stephen. I'll follow up with an updated patch set. Sorry for the delay. > > Regards > Stefan > > > > > > > Without this, Raspberry Pi devices boot with a random MAC address. > > >
