Re: [PATCH 1/1] [media] uvcvideo: Add 10,12bit and alternate 8bit greyscale
Hi Stefan,
Thanks for the patch.
On Saturday 28 July 2012 18:49:14 Stefan Muenzel wrote:
> Some cameras support 10bit and 12bit greyscale, or use the alternate "Y8
> " FOURCC for 8bit greyscale. Add support for these.
Could you please tell me which camera(s) use those formats ?
> Tested on a 12bit camera.
>
> Signed-off-by: Stefan Muenzel
> ---
> drivers/media/video/uvc/uvc_driver.c | 19 +--
> drivers/media/video/uvc/uvcvideo.h |9 +
> 2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/video/uvc/uvc_driver.c
> b/drivers/media/video/uvc/uvc_driver.c index 1d13172..11db262 100644
> --- a/drivers/media/video/uvc/uvc_driver.c
> +++ b/drivers/media/video/uvc/uvc_driver.c
> @@ -95,12 +95,27 @@ static struct uvc_format_desc uvc_fmts[] = {
> .fcc= V4L2_PIX_FMT_UYVY,
> },
> {
> - .name = "Greyscale (8-bit)",
> + .name = "Greyscale 8-bit (Y800)",
> .guid = UVC_GUID_FORMAT_Y800,
> .fcc= V4L2_PIX_FMT_GREY,
> },
> {
> - .name = "Greyscale (16-bit)",
> + .name = "Greyscale 8-bit (Y8 )",
> + .guid = UVC_GUID_FORMAT_Y8,
> + .fcc= V4L2_PIX_FMT_GREY,
> + },
> + {
> + .name = "Greyscale 10-bit (Y10 )",
> + .guid = UVC_GUID_FORMAT_Y10,
> + .fcc= V4L2_PIX_FMT_Y10,
> + },
> + {
> + .name = "Greyscale 12-bit (Y12 )",
> + .guid = UVC_GUID_FORMAT_Y12,
> + .fcc= V4L2_PIX_FMT_Y12,
> + },
> + {
> + .name = "Greyscale 16-bit (Y16 )",
> .guid = UVC_GUID_FORMAT_Y16,
> .fcc= V4L2_PIX_FMT_Y16,
> },
> diff --git a/drivers/media/video/uvc/uvcvideo.h
> b/drivers/media/video/uvc/uvcvideo.h index 7c3d082..3764040 100644
> --- a/drivers/media/video/uvc/uvcvideo.h
> +++ b/drivers/media/video/uvc/uvcvideo.h
> @@ -79,6 +79,15 @@
> #define UVC_GUID_FORMAT_Y800 \
> { 'Y', '8', '0', '0', 0x00, 0x00, 0x10, 0x00, \
>0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
> +#define UVC_GUID_FORMAT_Y8 \
> + { 'Y', '8', ' ', ' ', 0x00, 0x00, 0x10, 0x00, \
> + 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
> +#define UVC_GUID_FORMAT_Y10 \
> + { 'Y', '1', '0', ' ', 0x00, 0x00, 0x10, 0x00, \
> + 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
> +#define UVC_GUID_FORMAT_Y12 \
> + { 'Y', '1', '2', ' ', 0x00, 0x00, 0x10, 0x00, \
> + 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
> #define UVC_GUID_FORMAT_Y16 \
> { 'Y', '1', '6', ' ', 0x00, 0x00, 0x10, 0x00, \
>0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [dm-devel] [PATCH 2/3] Introduce percpu rw semaphores
On Sat, 28 Jul 2012, Eric Dumazet wrote: > On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote: > > Introduce percpu rw semaphores > > > > When many CPUs are locking a rw semaphore for read concurrently, cache > > line bouncing occurs. When a CPU acquires rw semaphore for read, the > > CPU writes to the cache line holding the semaphore. Consequently, the > > cache line is being moved between CPUs and this slows down semaphore > > acquisition. > > > > This patch introduces new percpu rw semaphores. They are functionally > > identical to existing rw semaphores, but locking the percpu rw semaphore > > for read is faster and locking for write is slower. > > > > The percpu rw semaphore is implemented as a percpu array of rw > > semaphores, each semaphore for one CPU. When some thread needs to lock > > the semaphore for read, only semaphore on the current CPU is locked for > > read. When some thread needs to lock the semaphore for write, semaphores > > for all CPUs are locked for write. This avoids cache line bouncing. > > > > Note that the thread that is locking percpu rw semaphore may be > > rescheduled, it doesn't cause bug, but cache line bouncing occurs in > > this case. > > > > Signed-off-by: Mikulas Patocka > > I am curious to see how this performs with 4096 cpus ? Each cpu should have its own rw semaphore in its cache, so I don't see a problem there. When you change block size, all 4096 rw semaphores are locked for write, but changing block size is not a performance sensitive operation. > Really you shouldnt use rwlock in a path if this might hurt performance. > > RCU is probably a better answer. RCU is meaningless here. RCU allows lockless dereference of a pointer. Here the problem is not pointer dereference, the problem is that integer bd_block_size may change. > (bdev->bd_block_size should be read exactly once ) Rewrite all direct and non-direct io code so that it reads block size just once ... Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] power_supply: Add new power supply VALID property
It is possible that users can use non-standard chargers
or use invalid batteries especially with mobile devices.
This patch adds a new power supply property called 'VALID' to
indicate this to the user(user space).
Signed-off-by: Ramakrishna Pallala
---
Documentation/power/power_supply_class.txt |2 ++
drivers/power/power_supply_sysfs.c |1 +
include/linux/power_supply.h |1 +
3 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/power/power_supply_class.txt
b/Documentation/power/power_supply_class.txt
index 2f0ddc1..272b122 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -81,6 +81,8 @@ This defines trickle and fast charges. For batteries that
are already charged or discharging, 'n/a' can be displayed (or
'unknown', if the status is not known).
+VALID - indicates the power supply connected is valid(1) or invalid(0)
+
HEALTH - represents health of the battery, values corresponds to
POWER_SUPPLY_HEALTH_*, defined in battery.h.
diff --git a/drivers/power/power_supply_sysfs.c
b/drivers/power/power_supply_sysfs.c
index 1d96614..797639e 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -138,6 +138,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(health),
POWER_SUPPLY_ATTR(present),
POWER_SUPPLY_ATTR(online),
+ POWER_SUPPLY_ATTR(valid),
POWER_SUPPLY_ATTR(technology),
POWER_SUPPLY_ATTR(cycle_count),
POWER_SUPPLY_ATTR(voltage_max),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 3cfee0c..e7edcb3 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -88,6 +88,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_VALID,
POWER_SUPPLY_PROP_TECHNOLOGY,
POWER_SUPPLY_PROP_CYCLE_COUNT,
POWER_SUPPLY_PROP_VOLTAGE_MAX,
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFT 2/2] gpio: gpio-pch: Use spinlock for register access protection
gpio_chip.can_sleep is 0, but current code uses mutex in pch_gpio_set
pch_gpio_get and pch_gpio_direction_input functions.
Thus those functions are not callable from interrupt context.
This patch converts mutex into spinlock.
Signed-off-by: Axel Lin
---
drivers/gpio/gpio-pch.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c
index 139ad3e..4ad0c4f 100644
--- a/drivers/gpio/gpio-pch.c
+++ b/drivers/gpio/gpio-pch.c
@@ -92,9 +92,7 @@ struct pch_gpio_reg_data {
* @lock: Used for register access protection
* @irq_base: Save base of IRQ number for interrupt
* @ioh: IOH ID
- * @spinlock: Used for register access protection in
- * interrupt context pch_irq_mask,
- * pch_irq_unmask and pch_irq_type;
+ * @spinlock: Used for register access protection
*/
struct pch_gpio {
void __iomem *base;
@@ -102,7 +100,6 @@ struct pch_gpio {
struct device *dev;
struct gpio_chip gpio;
struct pch_gpio_reg_data pch_gpio_reg;
- struct mutex lock;
int irq_base;
enum pch_type_t ioh;
spinlock_t spinlock;
@@ -112,8 +109,9 @@ static void pch_gpio_set(struct gpio_chip *gpio, unsigned
nr, int val)
{
u32 reg_val;
struct pch_gpio *chip = container_of(gpio, struct pch_gpio, gpio);
+ unsigned long flags;
- mutex_lock(>lock);
+ spin_lock_irqsave(>spinlock, flags);
reg_val = ioread32(>reg->po);
if (val)
reg_val |= (1 << nr);
@@ -121,7 +119,7 @@ static void pch_gpio_set(struct gpio_chip *gpio, unsigned
nr, int val)
reg_val &= ~(1 << nr);
iowrite32(reg_val, >reg->po);
- mutex_unlock(>lock);
+ spin_unlock_irqrestore(>spinlock, flags);
}
static int pch_gpio_get(struct gpio_chip *gpio, unsigned nr)
@@ -137,8 +135,9 @@ static int pch_gpio_direction_output(struct gpio_chip
*gpio, unsigned nr,
struct pch_gpio *chip = container_of(gpio, struct pch_gpio, gpio);
u32 pm;
u32 reg_val;
+ unsigned long flags;
- mutex_lock(>lock);
+ spin_lock_irqsave(>spinlock, flags);
pm = ioread32(>reg->pm) & ((1 << gpio_pins[chip->ioh]) - 1);
pm |= (1 << nr);
iowrite32(pm, >reg->pm);
@@ -149,8 +148,7 @@ static int pch_gpio_direction_output(struct gpio_chip
*gpio, unsigned nr,
else
reg_val &= ~(1 << nr);
iowrite32(reg_val, >reg->po);
-
- mutex_unlock(>lock);
+ spin_unlock_irqrestore(>spinlock, flags);
return 0;
}
@@ -159,12 +157,13 @@ static int pch_gpio_direction_input(struct gpio_chip
*gpio, unsigned nr)
{
struct pch_gpio *chip = container_of(gpio, struct pch_gpio, gpio);
u32 pm;
+ unsigned long flags;
- mutex_lock(>lock);
+ spin_lock_irqsave(>spinlock, flags);
pm = ioread32(>reg->pm) & ((1 << gpio_pins[chip->ioh]) - 1);
pm &= ~(1 << nr);
iowrite32(pm, >reg->pm);
- mutex_unlock(>lock);
+ spin_unlock_irqrestore(>spinlock, flags);
return 0;
}
@@ -387,7 +386,6 @@ static int __devinit pch_gpio_probe(struct pci_dev *pdev,
chip->reg = chip->base;
pci_set_drvdata(pdev, chip);
- mutex_init(>lock);
spin_lock_init(>spinlock);
pch_gpio_setup(chip);
ret = gpiochip_add(>gpio);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFT 1/2] gpio: gpio-ml-ioh: Use spinlock for register access protection
gpio_chip.can_sleep is 0, but current code uses mutex in ioh_gpio_set,
ioh_gpio_get and ioh_gpio_direction_input functions.
Thus those functions are not callable from interrupt context.
This patch converts mutex into spinlock.
Signed-off-by: Axel Lin
---
drivers/gpio/gpio-ml-ioh.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-ml-ioh.c b/drivers/gpio/gpio-ml-ioh.c
index db01f15..6a29ee1 100644
--- a/drivers/gpio/gpio-ml-ioh.c
+++ b/drivers/gpio/gpio-ml-ioh.c
@@ -87,8 +87,7 @@ struct ioh_gpio_reg_data {
* @gpio_use_sel: Save GPIO_USE_SEL1~4 register for PM
* @ch:Indicate GPIO channel
* @irq_base: Save base of IRQ number for interrupt
- * @spinlock: Used for register access protection in
- * interrupt context ioh_irq_type and PM;
+ * @spinlock: Used for register access protection
*/
struct ioh_gpio {
void __iomem *base;
@@ -97,7 +96,6 @@ struct ioh_gpio {
struct gpio_chip gpio;
struct ioh_gpio_reg_data ioh_gpio_reg;
u32 gpio_use_sel;
- struct mutex lock;
int ch;
int irq_base;
spinlock_t spinlock;
@@ -109,8 +107,9 @@ static void ioh_gpio_set(struct gpio_chip *gpio, unsigned
nr, int val)
{
u32 reg_val;
struct ioh_gpio *chip = container_of(gpio, struct ioh_gpio, gpio);
+ unsigned long flags;
- mutex_lock(>lock);
+ spin_lock_irqsave(>spinlock, flags);
reg_val = ioread32(>reg->regs[chip->ch].po);
if (val)
reg_val |= (1 << nr);
@@ -118,7 +117,7 @@ static void ioh_gpio_set(struct gpio_chip *gpio, unsigned
nr, int val)
reg_val &= ~(1 << nr);
iowrite32(reg_val, >reg->regs[chip->ch].po);
- mutex_unlock(>lock);
+ spin_unlock_irqrestore(>spinlock, flags);
}
static int ioh_gpio_get(struct gpio_chip *gpio, unsigned nr)
@@ -134,8 +133,9 @@ static int ioh_gpio_direction_output(struct gpio_chip
*gpio, unsigned nr,
struct ioh_gpio *chip = container_of(gpio, struct ioh_gpio, gpio);
u32 pm;
u32 reg_val;
+ unsigned long flags;
- mutex_lock(>lock);
+ spin_lock_irqsave(>spinlock, flags);
pm = ioread32(>reg->regs[chip->ch].pm) &
((1 << num_ports[chip->ch]) - 1);
pm |= (1 << nr);
@@ -148,7 +148,7 @@ static int ioh_gpio_direction_output(struct gpio_chip
*gpio, unsigned nr,
reg_val &= ~(1 << nr);
iowrite32(reg_val, >reg->regs[chip->ch].po);
- mutex_unlock(>lock);
+ spin_unlock_irqrestore(>spinlock, flags);
return 0;
}
@@ -157,13 +157,14 @@ static int ioh_gpio_direction_input(struct gpio_chip
*gpio, unsigned nr)
{
struct ioh_gpio *chip = container_of(gpio, struct ioh_gpio, gpio);
u32 pm;
+ unsigned long flags;
- mutex_lock(>lock);
+ spin_lock_irqsave(>spinlock, flags);
pm = ioread32(>reg->regs[chip->ch].pm) &
((1 << num_ports[chip->ch]) - 1);
pm &= ~(1 << nr);
iowrite32(pm, >reg->regs[chip->ch].pm);
- mutex_unlock(>lock);
+ spin_unlock_irqrestore(>spinlock, flags);
return 0;
}
@@ -447,7 +448,6 @@ static int __devinit ioh_gpio_probe(struct pci_dev *pdev,
chip->base = base;
chip->reg = chip->base;
chip->ch = i;
- mutex_init(>lock);
spin_lock_init(>spinlock);
ioh_gpio_setup(chip, num_ports[i]);
ret = gpiochip_add(>gpio);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 00/32] provide interfaces to access PCIe capabilities registers
On 07/25/2012 05:09 AM, Don Dutile wrote: > On 07/24/2012 12:31 PM, Jiang Liu wrote: >> From: Jiang Liu >> >> As suggested by Bjorn Helgaas and Don Dutile in threads >> http://www.spinics.net/lists/linux-pci/msg15663.html, we could improve access >> to PCIe capabilities register in to way: >> 1) cache content of PCIe Capabilities Register into struct pce_dev to avoid >> repeatedly reading this register because it's read only. >> 2) provide access functions for PCIe Capabilities registers to hide >> differences >> among PCIe base specifications, so the caller don't need to handle those >> differences. >> >> This patch set applies to >> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci-next >> >> And you could pull the change set from >> https://github.com/jiangliu/linux.git topic/pcie-cap >> >> These patch set is still RFC. It provides the new interfaces and has made the >> major changes to adopt those new interfaces. But there are still several >> device >> drivers left untouched. Any comments about the new interfaces are welcomed, >> especially about function names:). Once we reach an agreement, I will send >> out >> a formal version with all needed work done. >> >> v2: 1) change return value to 0 when the register is not implemented by >> V1 PCIe devices. >> 2) Change all driver in the source tree to use the new interfaces. >> >> Jiang Liu (29): >>PCI: add PCIe capabilities access functions to hide differences among >> PCIe specs >>PCI/core: use PCIe capabilities access functions to simplify >> implementation >>PCI/hotplug: use PCIe capabilities access functions to simplify >> implementation >>PCI/portdrv: use PCIe capabilities access functions to simplify >> implementation >>PCI/pciehp: use PCIe capabilities access functions to simplify >> implementation >>PCI/PME: use PCIe capabilities access functions to simplify >> implementation >>PCI/AER: use PCIe capabilities access functions to simplify >> implementation >>PCI/ASPM: use PCIe capabilities access functions to simplify >> implementation >>PCI/ARM: use PCIe capabilities access functions to simplify >> implementation >>PCI/MIPS: use PCIe capabilities access functions to simplify >> implementation >>PCI/tile: use PCIe capabilities access functions to simplify >> implementation >>PCI/r8169: use PCIe capabilities access functions to simplify >> implementation >>PCI/broadcom: use PCIe capabilities access functions to simplify >> implementation >>PCI/igb: use PCIe capabilities access functions to simplify >> implementation >>PCI/vxge: use PCIe capabilities access functions to simplify >> implementation >>PCI/mlx4: use PCIe capabilities access functions to simplify >> implementation >>PCI/niu: use PCIe capabilities access functions to simplify >> implementation >>PCI/myri10ge: use PCIe capabilities access functions to simplify >> implementation >>PCI/chelsio: use PCIe capabilities access functions to simplify >> implementation >>PCI/atl1c: use PCIe capabilities access functions to simplify >> implementation >>PCI/ath9k: use PCIe capabilities access functions to simplify >> implementation >>PCI/iwl: use PCIe capabilities access functions to simplify >> implementation >>PCI/mthca: use PCIe capabilities access functions to simplify >> implementation >>PCI/qib: use PCIe capabilities access functions to simplify >> implementation >>PCI/qla: use PCIe capabilities access functions to simplify >> implementation >>PCI/radeon: use PCIe capabilities access functions to simplify >> implementation >>PCI/tsi721: use PCIe capabilities access functions to simplify >> implementation >>PCI/et131x: use PCIe capabilities access functions to simplify >> implementation >>PCI/rtl8192e: use PCIe capabilities access functions to simplify >> implementation >> >> Yijing Wang (3): >>PCI: add pcie_flags_reg into struct pci_dev to cache PCIe >> capabilities register >>PCI: introduce pci_pcie_type(dev) to replace pci_dev->pcie_type >>PCI: remove unused field pcie_type from struct pci_dev >> >> arch/arm/mach-tegra/pcie.c |7 +- >> arch/mips/pci/pci-octeon.c |7 +- >> arch/powerpc/platforms/powernv/pci-ioda.c |2 +- >> arch/tile/kernel/pci.c | 17 +- >> drivers/gpu/drm/radeon/evergreen.c |9 +- >> drivers/infiniband/hw/mthca/mthca_reset.c |8 +- >> drivers/infiniband/hw/qib/qib_pcie.c | 40 ++- >> drivers/iommu/intel-iommu.c|6 +- >> drivers/net/ethernet/atheros/atl1c/atl1c_main.c|2 +- >> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 24 +- >>
Re: [PATCH 2/4] x86 idle APM: delete apm_cpu_idle()
On 07/28/2012 06:11 AM, Alan Cox wrote: > On Fri, 27 Jul 2012 18:42:53 -0400 > Len Brown wrote: > >> From: Len Brown >> >> The APM idle feature to call into the BIOS >> is known to break some machines, and it has dubious benefit >> on the (decades old) machines it doesn't break. > > You mean "doesn't fit my current plan" I think. I see almost no bugzilla > APM reports. It's been solid for years. Hm, I thought it was actually you that mentioned that this particular feature of APM caused some systems to fail... Unfortunately quiet bugzilla doesn't tell us the difference between "solid as a rock and used by millions of users every day" and "nobody anywhere running new software on this old hardware". > It makes a big difference on older systems as it drops the clock. If we > are going to drop this we should probaly also drop APM support entirely > and 386/486 support. Do you have an APM system that boots a 2012 kernel? Are you willing to test new kernels on it? > If not IMHO it should stay. Various embedded platforms are still using > ancient hardware setups. > > This is a small stable piece of code that has required no maintainance in > years > > Furthermore we have a feature removal process. Mark it down to be removed > in July 2013 if there are no objections, and then wait as per proper > process. > > NAK At your request 16 months ago, we did exactly that. Further, we added build-time and run-time warnings and all they did was cause distro mis-merges and requests to remove the warnings. 16 months ago we came within inches of dropping APM entirely, as Stephen said he hadn't maintained it for a long time. Jiri volunteered to look after it, and Pavel offered that he had 1 surviving machine someplace that actually supports APM, though I don't know if boots. I don't dispute that there may be some APM systems running someplace, but if nobody is going to test a 2012 kernel on such hardware, then we are kidding ourselves if we say we "support" today's kernel on it. Also, the whole idea was even if we do support such HW, this patch is supposed to make that HW more stable, not less stable. -Len -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
Hi Seth,
zcache out of staging is rather controversial as you see this thread.
But I believe zram is very mature and code/comment is clean. In addition,
it has lots of real customers in embedded side so IMHO, it would be easy to
promote it firstly. Of course, it will promote zsmalloc which is half on
what you want. What do you think about? If you agree, could you do that firstly?
If you don't want and promoting zcache continue to be controversial,
I will do that after my vacation.
Thanks.
On Fri, Jul 27, 2012 at 01:18:33PM -0500, Seth Jennings wrote:
> zcache is the remaining piece of code required to support in-kernel
> memory compression. The other two features, cleancache and frontswap,
> have been promoted to mainline in 3.0 and 3.5. This patchset
> promotes zcache from the staging tree to mainline.
>
> Based on the level of activity and contributions we're seeing from a
> diverse set of people and interests, I think zcache has matured to the
> point where it makes sense to promote this out of staging.
>
> Overview
>
> zcache is a backend to frontswap and cleancache that accepts pages from
> those mechanisms and compresses them, leading to reduced I/O caused by
> swap and file re-reads. This is very valuable in shared storage situations
> to reduce load on things like SANs. Also, in the case of slow backing/swap
> devices, zcache can also yield a performance gain.
>
> In-Kernel Memory Compression Overview:
>
> swap subsystempage cache
> + +
> frontswap cleancache
> + +
> zcache frontswap glue zcache cleancache glue
> + +
> +-++
> +
> zcache/tmem core
> +
> +-++
> + +
> zsmalloc zbud
>
> Everything below the frontswap/cleancache layer is current inside the
> zcache driver expect for zsmalloc which is a shared between zcache and
> another memory compression driver, zram.
>
> Since zcache is dependent on zsmalloc, it is also being promoted by this
> patchset.
>
> For information on zsmalloc and the rationale behind it's design and use
> cases verses already existing allocators in the kernel:
>
> https://lkml.org/lkml/2012/1/9/386
>
> zsmalloc is the allocator used by zcache to store persistent pages that
> comes from frontswap, as opposed to zbud which is the (internal) allocator
> used for ephemeral pages from cleancache.
>
> zsmalloc uses many fields of the page struct to create it's conceptual
> high-order page called a zspage. Exactly which fields are used and for
> what purpose is documented at the top of the zsmalloc .c file. Because
> zsmalloc uses struct page extensively, Andrew advised that the
> promotion location be mm/:
>
> https://lkml.org/lkml/2012/1/20/308
>
> Some benchmarking numbers demonstrating the I/O saving that can be had
> with zcache:
>
> https://lkml.org/lkml/2012/3/22/383
>
> Dan's presentation at LSF/MM this year on zcache:
>
> http://oss.oracle.com/projects/tmem/dist/documentation/presentations/LSFMM12-zcache-final.pdf
>
> This patchset is based on next-20120727 + 3-part zsmalloc patchset below
>
> https://lkml.org/lkml/2012/7/18/353
>
> The zsmalloc patchset is already acked and will be integrated by Greg after
> 3.6-rc1 is out.
>
> Seth Jennings (4):
> zsmalloc: collapse internal .h into .c
> zsmalloc: promote to mm/
> drivers: add memory management driver class
> zcache: promote to drivers/mm/
>
> drivers/Kconfig|2 +
> drivers/Makefile |1 +
> drivers/mm/Kconfig | 13 ++
> drivers/mm/Makefile|1 +
> drivers/{staging => mm}/zcache/Makefile|0
> drivers/{staging => mm}/zcache/tmem.c |0
> drivers/{staging => mm}/zcache/tmem.h |0
> drivers/{staging => mm}/zcache/zcache-main.c |4 +-
> drivers/staging/Kconfig|4 -
> drivers/staging/Makefile |2 -
> drivers/staging/zcache/Kconfig | 11 --
> drivers/staging/zram/zram_drv.h|3 +-
> drivers/staging/zsmalloc/Kconfig | 10 --
> drivers/staging/zsmalloc/Makefile |3 -
> drivers/staging/zsmalloc/zsmalloc_int.h| 149
>
> .../staging/zsmalloc => include/linux}/zsmalloc.h |0
> mm/Kconfig | 18 +++
> mm/Makefile|1 +
> .../zsmalloc/zsmalloc-main.c => mm/zsmalloc.c | 133 -
> 19 files changed, 170 insertions(+), 185 deletions(-)
> create mode 100644 drivers/mm/Kconfig
> create mode 100644 drivers/mm/Makefile
> rename
Re: [RFC PATCH v2 05/32] PCI/core: use PCIe capabilities access functions to simplify implementation
Hi Dan,
Sorry for slow response, was busy with a patch for a new PCI hotplug
framework patch set last week.
Thanks for your comments, and seems I need to be more aggressive to
reduce redundant pci_is_pcie() checks:) Will send out V3 to simplify code
further.
Thanks!
Gerry
On 07/26/2012 05:12 AM, Don Dutile wrote:
> sorry for delay... i thought i had sent it out yesterday,
> but found it today when cleaning up/out the multiple of
> windows/xterms on my desktop.
>
>
> On 07/24/2012 12:31 PM, Jiang Liu wrote:
>> From: Jiang Liu
>>
>> Use PCIe capabilities access functions to simplify PCI core implementation.
>>
>> Signed-off-by: Jiang Liu
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/pci/pci.c| 260
>> +++---
>> drivers/pci/probe.c | 18 +---
>> drivers/pci/quirks.c |9 +-
>> 3 files changed, 66 insertions(+), 221 deletions(-)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 28eb55b..fd83647 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -254,38 +254,6 @@ int pci_bus_find_capability(struct pci_bus *bus,
>> unsigned int devfn, int cap)
>> }
>>
>> /**
>> - * pci_pcie_cap2 - query for devices' PCI_CAP_ID_EXP v2 capability structure
>> - * @dev: PCI device to check
>> - *
>> - * Like pci_pcie_cap() but also checks that the PCIe capability version is
>> - *>= 2. Note that v1 capability structures could be sparse in that not
>> - * all register fields were required. v2 requires the entire structure to
>> - * be present size wise, while still allowing for non-implemented registers
>> - * to exist but they must be hardwired to 0.
>> - *
>> - * Due to the differences in the versions of capability structures, one
>> - * must be careful not to try and access non-existant registers that may
>> - * exist in early versions - v1 - of Express devices.
>> - *
>> - * Returns the offset of the PCIe capability structure as long as the
>> - * capability version is>= 2; otherwise 0 is returned.
>> - */
>> -static int pci_pcie_cap2(struct pci_dev *dev)
>> -{
>> -u16 flags;
>> -int pos;
>> -
>> -pos = pci_pcie_cap(dev);
>> -if (pos) {
>> -pci_read_config_word(dev, pos + PCI_EXP_FLAGS,);
>> -if ((flags& PCI_EXP_FLAGS_VERS)< 2)
>> -pos = 0;
>> -}
>> -
>> -return pos;
>> -}
>> -
>> -/**
>>* pci_find_ext_capability - Find an extended capability
>>* @dev: PCI device to query
>>* @cap: capability code
>> @@ -854,21 +822,6 @@ EXPORT_SYMBOL(pci_choose_state);
>>
>> #define PCI_EXP_SAVE_REGS7
>>
>> -#define pcie_cap_has_devctl(type, flags)1
>> -#define pcie_cap_has_lnkctl(type, flags)\
>> -((flags& PCI_EXP_FLAGS_VERS)> 1 ||\
>> - (type == PCI_EXP_TYPE_ROOT_PORT ||\
>> - type == PCI_EXP_TYPE_ENDPOINT ||\
>> - type == PCI_EXP_TYPE_LEG_END))
>> -#define pcie_cap_has_sltctl(type, flags)\
>> -((flags& PCI_EXP_FLAGS_VERS)> 1 ||\
>> - ((type == PCI_EXP_TYPE_ROOT_PORT) ||\
>> - (type == PCI_EXP_TYPE_DOWNSTREAM&&\
>> - (flags& PCI_EXP_FLAGS_SLOT
>> -#define pcie_cap_has_rtctl(type, flags)\
>> -((flags& PCI_EXP_FLAGS_VERS)> 1 ||\
>> - (type == PCI_EXP_TYPE_ROOT_PORT ||\
>> - type == PCI_EXP_TYPE_RC_EC))
>>
>> static struct pci_cap_saved_state *pci_find_saved_cap(
>> struct pci_dev *pci_dev, char cap)
>> @@ -885,13 +838,11 @@ static struct pci_cap_saved_state *pci_find_saved_cap(
>>
>> static int pci_save_pcie_state(struct pci_dev *dev)
>> {
>> -int type, pos, i = 0;
>> +int i = 0;
>> struct pci_cap_saved_state *save_state;
>> u16 *cap;
>> -u16 flags;
>>
>> -pos = pci_pcie_cap(dev);
>> -if (!pos)
>> +if (!pci_is_pcie(dev))
>> return 0;
>>
> Why not put the above check in all the pci_pcie_capability_read_*() functions
> ?
> Myron did some good cleanup to get rid of these pci_is_pcie() throughout
> these functions, and put them in base functions, so it'd be good if that
> effort could remain intact.
>
>> save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
>> @@ -901,60 +852,35 @@ static int pci_save_pcie_state(struct pci_dev *dev)
>> }
>> cap = (u16 *)_state->cap.data[0];
>>
>> -pci_read_config_word(dev, pos + PCI_EXP_FLAGS,);
>> -
>> -type = pci_pcie_type(dev);
>> -if (pcie_cap_has_devctl(type, flags))
>> -pci_read_config_word(dev, pos + PCI_EXP_DEVCTL,[i++]);
>> -if (pcie_cap_has_lnkctl(type, flags))
>> -pci_read_config_word(dev, pos + PCI_EXP_LNKCTL,[i++]);
>> -if (pcie_cap_has_sltctl(type, flags))
>> -pci_read_config_word(dev, pos + PCI_EXP_SLTCTL,[i++]);
>> -if (pcie_cap_has_rtctl(type, flags))
>> -pci_read_config_word(dev, pos + PCI_EXP_RTCTL,[i++]);
>> +pci_pcie_capability_read_word(dev, PCI_EXP_DEVCTL,[i++]);
>> +
Re: [PATCH 0/4] promote zcache from staging
On Fri, Jul 27, 2012 at 02:42:14PM -0700, Dan Magenheimer wrote: > > From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org] > > Sent: Friday, July 27, 2012 3:00 PM > > Subject: Re: [PATCH 0/4] promote zcache from staging > > > > On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: > > > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > > > > Subject: [PATCH 0/4] promote zcache from staging > > > > > > > > zcache is the remaining piece of code required to support in-kernel > > > > memory compression. The other two features, cleancache and frontswap, > > > > have been promoted to mainline in 3.0 and 3.5. This patchset > > > > promotes zcache from the staging tree to mainline. > > > > > > > > Based on the level of activity and contributions we're seeing from a > > > > diverse set of people and interests, I think zcache has matured to the > > > > point where it makes sense to promote this out of staging. > > > > > > Hi Seth -- > > > > > > Per offline communication, I'd like to see this delayed for three > > > reasons: > > > > > > 1) I've completely rewritten zcache and will post the rewrite soon. > > >The redesigned code fixes many of the weaknesses in zcache that > > >makes it (IMHO) unsuitable for an enterprise distro. (Some of > > >these previously discussed in linux-mm [1].) > > > 2) zcache is truly mm (memory management) code and the fact that > > >it is in drivers at all was purely for logistical reasons > > >(e.g. the only in-tree "staging" is in the drivers directory). > > >My rewrite promotes it to (a subdirectory of) mm where IMHO it > > >belongs. > > > 3) Ramster heavily duplicates code from zcache. My rewrite resolves > > >this. My soon-to-be-post also places the re-factored ramster > > >in mm, though with some minor work zcache could go in mm and > > >ramster could stay in staging. > > > > > > Let's have this discussion, but unless the community decides > > > otherwise, please consider this a NACK. > > Hi Konrad -- > > > Hold on, that is rather unfair. The zcache has been in staging > > for quite some time - your code has not been posted. Part of > > "unstaging" a driver is for folks to review the code - and you > > just said "No, mine is better" without showing your goods. > > Sorry, I'm not trying to be unfair. However, I don't see the point > of promoting zcache out of staging unless it is intended to be used > by real users in a real distro. There's been a lot of discussion, > onlist and offlist, about what needs to be fixed in zcache and not > much visible progress on fixing it. But fixing it is where I've spent > most of my time over the last couple of months. > > If IBM or some other company or distro is eager to ship and support > zcache in its current form, I agree that "promote now, improve later" > is a fine approach. But promoting zcache out of staging simply because > there is urgency to promote zsmalloc+zram out of staging doesn't > seem wise. At a minimum, it distracts reviewers/effort from what IMHO > is required to turn zcache into an enterprise-ready kernel feature. > > I can post my "goods" anytime. In its current form it is better > than the zcache in staging (and, please remember, I wrote both so > I think I am in a good position to compare the two). > I have been waiting until I think the new zcache is feature complete > before asking for review, especially since the newest features > should demonstrate clearly why the rewrite is necessary and > beneficial. But I can post* my current bits if people don't > believe they exist and/or don't mind reviewing non-final code. > (* Or I can put them in a publicly available git tree.) > > > There is a third option - which is to continue the promotion > > of zcache from staging, get reviews, work on them ,etc, and > > alongside of that you can work on fixing up (or ripping out) > > zcache1 with zcache2 components as they make sense. Or even > > having two of them - an enterprise and an embedded version > > that will eventually get merged together. There is nothing > > wrong with modifying a driver once it has left staging. > > Minchan and Seth can correct me if I am wrong, but I believe > zram+zsmalloc, not zcache, is the target solution for embedded. NOT ture. Some embedded devices use zcache but it's not original zcache but modificated one. Anyway, although embedded people use modified zcache, I am biased to Dan. I admit I don't spend lots of time to look zcache but as looking the code, it wasn't good shape and even had a bug found during code review and I felt strongly we should clean up it for promoting it to mm/. So I would like to wait Dan's posting if you guys are not urgent. (And I am not sure akpm allow it with current shape of zcache code.) But the concern is about adding new feature. I guess there might be some debate for long time and it can prevent promoting again. I think It's not what Seth want. I hope Dan doesn't mix clean up series and
Re: [PATCHv5 2/2] ARM: dma-mapping: remove custom consistent dma region
Hi Marek,
I looked at patch and have minor points and a question.
I should have said in early patch. Sorry about that.
Anyway, except below points, It's good to me.
On Fri, Jul 27, 2012 at 02:03:39PM +0200, Marek Szyprowski wrote:
> This patch changes dma-mapping subsystem to use generic vmalloc areas
> for all consistent dma allocations. This increases the total size limit
> of the consistent allocations and removes platform hacks and a lot of
> duplicated code.
>
> Atomic allocations are served from special pool preallocated on boot,
> becasue vmalloc areas cannot be reliably created in atomic context.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-by: Kyungmin Park
> ---
> Documentation/kernel-parameters.txt |2 +-
> arch/arm/include/asm/dma-mapping.h |2 +-
> arch/arm/mm/dma-mapping.c | 511
> +--
> arch/arm/mm/mm.h|3 +
> include/linux/vmalloc.h |1 +
> mm/vmalloc.c| 10 +-
> 6 files changed, 197 insertions(+), 332 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index a92c5eb..4ee28f3 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -526,7 +526,7 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
>
> coherent_pool=nn[KMG] [ARM,KNL]
> Sets the size of memory pool for coherent, atomic dma
> - allocations if Contiguous Memory Allocator (CMA) is
> used.
> + allocations, by default set to 256K.
>
> code_bytes [X86] How many bytes of object code to print
> in an oops report.
> diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> index bbef15d..80777d87 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -226,7 +226,7 @@ static inline int dma_mmap_writecombine(struct device
> *dev, struct vm_area_struc
> * DMA region above it's default value of 2MB. It must be called before the
> * memory allocator is initialised, i.e. before any core_initcall.
> */
> -extern void __init init_consistent_dma_size(unsigned long size);
> +static inline void init_consistent_dma_size(unsigned long size) { }
>
> /*
> * For SA-, IXP425, and ADI systems the dma-mapping functions are
> "magic"
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 655878b..4d750a6 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -217,115 +218,70 @@ static void __dma_free_buffer(struct page *page,
> size_t size)
> }
>
> #ifdef CONFIG_MMU
> -
> -#define CONSISTENT_OFFSET(x) (((unsigned long)(x) - consistent_base) >>
> PAGE_SHIFT)
> -#define CONSISTENT_PTE_INDEX(x) (((unsigned long)(x) - consistent_base) >>
> PMD_SHIFT)
> -
> -/*
> - * These are the page tables (2MB each) covering uncached, DMA consistent
> allocations
> - */
> -static pte_t **consistent_pte;
> -
> -#define DEFAULT_CONSISTENT_DMA_SIZE SZ_2M
> -
> -static unsigned long consistent_base = CONSISTENT_END -
> DEFAULT_CONSISTENT_DMA_SIZE;
> -
> -void __init init_consistent_dma_size(unsigned long size)
> -{
> - unsigned long base = CONSISTENT_END - ALIGN(size, SZ_2M);
> -
> - BUG_ON(consistent_pte); /* Check we're called before DMA region init */
> - BUG_ON(base < VMALLOC_END);
> -
> - /* Grow region to accommodate specified size */
> - if (base < consistent_base)
> - consistent_base = base;
> -}
> -
> -#include "vmregion.h"
> -
> -static struct arm_vmregion_head consistent_head = {
> - .vm_lock= __SPIN_LOCK_UNLOCKED(_head.vm_lock),
> - .vm_list= LIST_HEAD_INIT(consistent_head.vm_list),
> - .vm_end = CONSISTENT_END,
> -};
> -
> #ifdef CONFIG_HUGETLB_PAGE
> #error ARM Coherent DMA allocator does not (yet) support huge TLB
> #endif
>
> -/*
> - * Initialise the consistent memory allocation.
> - */
> -static int __init consistent_init(void)
> -{
> - int ret = 0;
> - pgd_t *pgd;
> - pud_t *pud;
> - pmd_t *pmd;
> - pte_t *pte;
> - int i = 0;
> - unsigned long base = consistent_base;
> - unsigned long num_ptes = (CONSISTENT_END - base) >> PMD_SHIFT;
> -
> - if (IS_ENABLED(CONFIG_CMA) && !IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU))
> - return 0;
> -
> - consistent_pte = kmalloc(num_ptes * sizeof(pte_t), GFP_KERNEL);
> - if (!consistent_pte) {
> - pr_err("%s: no memory\n", __func__);
> - return -ENOMEM;
> - }
> -
> - pr_debug("DMA memory: 0x%08lx - 0x%08lx:\n", base, CONSISTENT_END);
> - consistent_head.vm_start = base;
> -
> - do {
> - pgd = pgd_offset(_mm, base);
> -
> - pud =
Re: [PATCH] MIPS: fix tc_id calculation
On Sat, Jul 28, 2012 at 5:08 PM, RongQing Li wrote: > Any advice > > 2012/7/2 : >> From: RongQing.Li >> >> Now the tc_id is: >> (read_c0_tcbind() >> TCBIND_CURTC_SHIFT) & TCBIND_CURTC; >> After substitute macro: >> (read_c0_tcbind() >> 21) & ((0xff) << 21) >> It should be: >> (read_c0_tcbind() & ((0xff)<< 21)) >>21 >> >> Signed-off-by: RongQing.Li >> --- Good catch ;) Thanks, Hillf >> arch/mips/kernel/smp-cmp.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/mips/kernel/smp-cmp.c b/arch/mips/kernel/smp-cmp.c >> index e7e03ec..afc379c 100644 >> --- a/arch/mips/kernel/smp-cmp.c >> +++ b/arch/mips/kernel/smp-cmp.c >> @@ -102,7 +102,7 @@ static void cmp_init_secondary(void) >> c->vpe_id = (read_c0_tcbind() >> TCBIND_CURVPE_SHIFT) & >> TCBIND_CURVPE; >> #endif >> #ifdef CONFIG_MIPS_MT_SMTC >> - c->tc_id = (read_c0_tcbind() >> TCBIND_CURTC_SHIFT) & TCBIND_CURTC; >> + c->tc_id = (read_c0_tcbind() & TCBIND_CURTC) >> TCBIND_CURTC_SHIFT; >> #endif >> } >> >> -- >> 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/ > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] apple-gmux: Restore switch registers on suspend/resume
On Sun, 2012-07-29 at 01:42 +0100, David Woodhouse wrote: > If I don't hack it to switch the mux to IGD at boot time, I never manage > to get a sane picture out of the Intel device after switching to it. > It's late now, but I'll try to get a proper debug log of the working and > failing cases tomorrow. From the hacked kernel (after fixing vga_switcheroo_enable() not to do: event.info = client->fb_info; fb_notifier_call_chain(FB_EVENT_REMAP_ALL_CONSOLE, ); if client->fb_info is NULL)... http://david.woodhou.se/dmesg-boot-to-IGD (blank screen) http://david.woodhou.se/dmesg-boot-to-IGD-and-switch-to-DIS (works) http://david.woodhou.se/dmesg-boot-to-IGD-and-switch-to-DIS-and-back-to-IGD (works) Without switching to IGD at startup... http://david.woodhou.se/dmesg-boot-to-DIS (works) http://david.woodhou.se/dmesg-boot-to-DIS-then-switch-to-IGD (blank) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
[PATCH] netfilter: PTR_RET can be used
This quiets the coccinelle warnings:
net/bridge/netfilter/ebtable_filter.c:107:1-3: WARNING: PTR_RET can be used
net/bridge/netfilter/ebtable_nat.c:107:1-3: WARNING: PTR_RET can be used
net/ipv6/netfilter/ip6table_filter.c:65:1-3: WARNING: PTR_RET can be used
net/ipv6/netfilter/ip6table_mangle.c:100:1-3: WARNING: PTR_RET can be used
net/ipv6/netfilter/ip6table_raw.c:44:1-3: WARNING: PTR_RET can be used
net/ipv6/netfilter/ip6table_security.c:62:1-3: WARNING: PTR_RET can be used
net/ipv4/netfilter/iptable_filter.c:72:1-3: WARNING: PTR_RET can be used
net/ipv4/netfilter/iptable_mangle.c:107:1-3: WARNING: PTR_RET can be used
net/ipv4/netfilter/iptable_raw.c:51:1-3: WARNING: PTR_RET can be used
net/ipv4/netfilter/iptable_security.c:70:1-3: WARNING: PTR_RET can be used
Signed-off-by: Fengguang Wu
---
net/bridge/netfilter/ebtable_filter.c |4 +---
net/bridge/netfilter/ebtable_nat.c |4 +---
net/ipv4/netfilter/iptable_filter.c|4 +---
net/ipv4/netfilter/iptable_mangle.c|4 +---
net/ipv4/netfilter/iptable_raw.c |4 +---
net/ipv4/netfilter/iptable_security.c |5 +
net/ipv6/netfilter/ip6table_filter.c |4 +---
net/ipv6/netfilter/ip6table_mangle.c |4 +---
net/ipv6/netfilter/ip6table_raw.c |4 +---
net/ipv6/netfilter/ip6table_security.c |5 +
10 files changed, 10 insertions(+), 32 deletions(-)
--- linux.orig/net/bridge/netfilter/ebtable_filter.c2012-07-29
08:41:09.703759534 +0800
+++ linux/net/bridge/netfilter/ebtable_filter.c 2012-07-29 08:41:14.255759643
+0800
@@ -100,9 +100,7 @@ static struct nf_hook_ops ebt_ops_filter
static int __net_init frame_filter_net_init(struct net *net)
{
net->xt.frame_filter = ebt_register_table(net, _filter);
- if (IS_ERR(net->xt.frame_filter))
- return PTR_ERR(net->xt.frame_filter);
- return 0;
+ return PTR_RET(net->xt.frame_filter);
}
static void __net_exit frame_filter_net_exit(struct net *net)
--- linux.orig/net/bridge/netfilter/ebtable_nat.c 2012-07-29
08:41:09.671759534 +0800
+++ linux/net/bridge/netfilter/ebtable_nat.c2012-07-29 08:41:14.255759643
+0800
@@ -100,9 +100,7 @@ static struct nf_hook_ops ebt_ops_nat[]
static int __net_init frame_nat_net_init(struct net *net)
{
net->xt.frame_nat = ebt_register_table(net, _nat);
- if (IS_ERR(net->xt.frame_nat))
- return PTR_ERR(net->xt.frame_nat);
- return 0;
+ return PTR_RET(net->xt.frame_nat);
}
static void __net_exit frame_nat_net_exit(struct net *net)
--- linux.orig/net/ipv4/netfilter/iptable_filter.c 2012-07-29
08:41:09.523759531 +0800
+++ linux/net/ipv4/netfilter/iptable_filter.c 2012-07-29 08:41:14.259759643
+0800
@@ -69,9 +69,7 @@ static int __net_init iptable_filter_net
net->ipv4.iptable_filter =
ipt_register_table(net, _filter, repl);
kfree(repl);
- if (IS_ERR(net->ipv4.iptable_filter))
- return PTR_ERR(net->ipv4.iptable_filter);
- return 0;
+ return PTR_RET(net->ipv4.iptable_filter);
}
static void __net_exit iptable_filter_net_exit(struct net *net)
--- linux.orig/net/ipv4/netfilter/iptable_mangle.c 2012-07-29
08:41:09.495759530 +0800
+++ linux/net/ipv4/netfilter/iptable_mangle.c 2012-07-29 08:41:14.259759643
+0800
@@ -104,9 +104,7 @@ static int __net_init iptable_mangle_net
net->ipv4.iptable_mangle =
ipt_register_table(net, _mangler, repl);
kfree(repl);
- if (IS_ERR(net->ipv4.iptable_mangle))
- return PTR_ERR(net->ipv4.iptable_mangle);
- return 0;
+ return PTR_RET(net->ipv4.iptable_mangle);
}
static void __net_exit iptable_mangle_net_exit(struct net *net)
--- linux.orig/net/ipv4/netfilter/iptable_raw.c 2012-07-29 08:41:09.467759529
+0800
+++ linux/net/ipv4/netfilter/iptable_raw.c 2012-07-29 08:41:14.259759643
+0800
@@ -48,9 +48,7 @@ static int __net_init iptable_raw_net_in
net->ipv4.iptable_raw =
ipt_register_table(net, _raw, repl);
kfree(repl);
- if (IS_ERR(net->ipv4.iptable_raw))
- return PTR_ERR(net->ipv4.iptable_raw);
- return 0;
+ return PTR_RET(net->ipv4.iptable_raw);
}
static void __net_exit iptable_raw_net_exit(struct net *net)
--- linux.orig/net/ipv4/netfilter/iptable_security.c2012-07-29
08:41:09.439759529 +0800
+++ linux/net/ipv4/netfilter/iptable_security.c 2012-07-29 08:41:14.259759643
+0800
@@ -66,10 +66,7 @@ static int __net_init iptable_security_n
net->ipv4.iptable_security =
ipt_register_table(net, _table, repl);
kfree(repl);
- if (IS_ERR(net->ipv4.iptable_security))
- return PTR_ERR(net->ipv4.iptable_security);
-
- return 0;
+ return PTR_RET(net->ipv4.iptable_security);
}
static void __net_exit iptable_security_net_exit(struct net *net)
--- linux.orig/net/ipv6/netfilter/ip6table_filter.c 2012-07-29
08:41:09.643759533
Re: [PATCH] apple-gmux: Restore switch registers on suspend/resume
On Wed, 2012-07-11 at 02:25 +0200, Andreas Heider wrote:
> Thanks for adding me, seeing the gmux driver progress is always great.
>
> Regarding the original patch: This is probably only useful when the gmux
> was switched in GRUB and there's already a solution for the resume
> problem in userspace
> (http://ubuntuforums.org/showpost.php?p=10695119=261). Maybe
> the same could be achieved a bit cleaner by simply using a few parts of
> the switching patch?
>
> Regarding the gmux switching patch: The patch itself should work and
> hopefully doesn't break stuff that wasn't broken before. But without
> additional fixes to i915/nouveau/etc. It won't be too useful either,
> although it should fix the resume issue.
>
> I'll look into how well it works with the current kernel on the weekend,
> but I don't want to promise too much since time is still a bit of an
> issue for me.
Using the patches from http://www.codon.org.uk/~mjg59/tmp/radeon_efi/
and http://www.codon.org.uk/~mjg59/tmp/gmux_switcheroo.diff I can almost
get this working on my MBP8,3, chainloading the kernel from grub1-efi.
I have to fix pci_map_rom() to return pdev->rom even if the resource has
the IORESOURCE_ROM_SHADOW flag (Matthew's patch still returned 0xC),
and I have to fix a bug in vga_switcheroo_enable() where it uses
client->id before actually setting it.
And then, if I hack head64.c to switch the mux over to IGD but leave the
Radeon powered up: ("outb(1, 0x728); outb(2, 0x710); outb(2, 0x740);")
... and on the occasions that it doesn't crash in fbcon_event_notify()
as shown at http://david.woodhou.se/vga-switcheroo-oops.txt
... it boots with a blank screen but I can log in over the network and I
*can* actually switch between displays. After switching to 'DIS' and
back to 'IGD' it does actually start working, and I seem to have both X
and fbcon working sanely on both. Although on an earlier boot I don't
think fbcon was working on the Radeon but X *did* work on both. So maybe
that's not 100% repeatable. Hard to say... I've only managed to get it
to boot twice; mostly it oopses as shown above.
If I don't hack it to switch the mux to IGD at boot time, I never manage
to get a sane picture out of the Intel device after switching to it.
It's late now, but I'll try to get a proper debug log of the working and
failing cases tomorrow.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] Documentation: fix DOCBOOKS=... building
On 07/28/2012 10:05 AM, Randy Dunlap wrote: > On 07/28/2012 04:26 AM, Johannes Berg wrote: > >> On Fri, 2012-07-27 at 15:29 -0700, Randy Dunlap wrote: >>> On 06/13/2012 01:43 AM, Johannes Berg wrote: >>> From: Johannes Berg Prior to commit 4266129964b8238526936d723de65b419d8069c6 Author: Mauro Carvalho Chehab Date: Tue May 31 16:27:44 2011 -0300 [media] DocBook: Move all media docbook stuff into its own directory it was possible to build only a single (or more) book(s) by calling, for example make htmldocs DOCBOOKS=80211.xml This now fails: cp: target `.../Documentation/DocBook//media_api' is not a directory Ignore errors from that copy to make this possible again. Cc: Mauro Carvalho Chehab Signed-off-by: Johannes Berg --- I complained about this a long time ago, but now it finally bothered me enough to fix it ... :-) >>> >>> >>> Thanks. >>> >>> Acked-by: Randy Dunlap >> >> Can you apply it somewhere, or should I send it to Andrew, or do you >> have any other ideas? > > > I'm no longer the Documentation maintainer, but Rob Landley > could merge it. You probably will need to resend it to him. Acked-by: Rob landley I'll forward it. Thanks, Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: An Andre To Remember
On Fri, 2012-07-27 at 13:56 -0400, Jeff Garzik wrote: > An Andre To Remember > July 2012 > > Linux lost a friend and advocate this month. Though never a household > name, Andre Hedrick had a positive impact on everyone today running > Linux, or using a website, with any form of IDE (ATA) or SCSI storage > -- that means millions upon millions of users today. > > For a time, Andre interacted with practically every relevant IDE > drive and controller manufacturer, as well as the T13 standards > committee through which IDE changes were made. He helped ensure > Linux had near-universal IDE support in a hardware era when Linux > support was a second thought if at all. As the Register article[1] > noted, with CPRM and other efforts, Andre worked to keep storage a > more open platform than it might otherwise have been. > > [1] http://www.theregister.co.uk/2012/07/26/andre_hedrick/ > > Andre also played a role in IDE technology coalescing around the idea > of a "taskfile", which is IDE-speak for an RPC command issued to a > disk drive, and the RPC response returned from the drive. It was > very important to Andre that the kernel have a "taskfile ioctl", > an API enabling full programmable access to the disk drive. At the > time, a more limited "cmd ioctl" API was the best option available, > but Linux's cmd ioctl did not give users full and complete access to > their own disk drive. > > Andre's taskfile concept was a central component of the current, > rewritten-from-scratch Linux IDE driver "libata." libata uses an > "ata_taskfile" to communicate with all IDE drives, whether from a > decade ago or built yesterday. The taskfile concept modernized > IDE software, by forcing the industry to move away from a slow, > signals-originated register API to a modern, packetized RPC messaging > API, similar to where SCSI storage had already been moving. > > I spent many hours on the phone with Andre, circa 2003, learning all > there was to know about ATA storage, while writing libata. Andre could > be considered one of the grandfathers of libata, along with Alan Cox. > I became friends with Andre during this time, and we talked a lot. > > Andre was unquestionably smart, driven and an advocate for Linux user > freedom. > Hi Jeff, Thank you for sharing your thoughts + memories of Andre. As we grieve this extreme loss, I'd like to try to share some of my own experiences with Andre that will hopefully help others to begin to understand the kind + generous type of person that Andre really was, and just some of his staggering technical feats + accomplishments that can be talked about publicly today. Along with Andre being involved in the history of libata and IDE/ATA development, those of us in the Linux kernel storage development community also know, he was also instrumental in creation of the original out-of-tree PyX iSCSI target code that's now in mainline. In summer 2002, I sitting next to Andre when he coined the term 'IBLOCK' after drawing a rough sketch on a notebook after an idea in Walnut Creek, California, and the name ending up sticking.. The interesting development bits really started to unfold in the spring of 2004 when we finally managed to get drivers/ide/ export working with iscsi-target on x86 using 2.4.x code. That quickly unfolded into a Sony Playstation-2 (MIPS EE) port using IDE disk DMA mode + network PIO on 2.2.x era kernel code capable of streaming multiple DVD quality streams to hungry iSCSI clients.. Left to my own devices for hardware hacking, I managed to turn our first disassembled PS2 into a broken parts machine (whoops) but Andre was going to made sure that it was not going to happen again.. I bought another PS2, and he was the person who soldered wires to the handful of tiny via pin-outs to access the one-way serial output for EE boot information last at night, while I worked on the necessary kernel bits needed for bring-up of the PS2 specific IDE backend target driver. (The PS2 IDE driver required contiguous memory for IDE DMA ops to function via a single struct buffer_head (TCQ=1) on the non-cache coherent MIPS based platform.) He carefully made physical space in the machine's cramped chassis, using sticky pads where necessary to hold the small PCB containing a simple ASIC doing the conversion of the signal into PC RS-232 serial output. He made it look completely flush, like exactly how it was supposed to come from the factory. Or you know, from the magical place near the old Bell Labs R center where new development kits for cutting edge tech are born. CBS Sunday Morning even did a story on Andre and his family in the summer of 2004 while all of this was going on.. Not for the PS2 iscsi-target or any other code of course, but for the fact that he was chosen by EBay to represent California small business as part of a group that lobbied in Washington DC. The reason that E-bay chose Andre is because he built PyX using recycled server + storage hardware
[PATCH 1/1] [media] uvcvideo: Add 10,12bit and alternate 8bit greyscale
Some cameras support 10bit and 12bit greyscale, or use the alternate "Y8
" FOURCC for 8bit greyscale. Add support for these.
Tested on a 12bit camera.
Signed-off-by: Stefan Muenzel
---
drivers/media/video/uvc/uvc_driver.c | 19 +--
drivers/media/video/uvc/uvcvideo.h |9 +
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index 1d13172..11db262 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -95,12 +95,27 @@ static struct uvc_format_desc uvc_fmts[] = {
.fcc= V4L2_PIX_FMT_UYVY,
},
{
- .name = "Greyscale (8-bit)",
+ .name = "Greyscale 8-bit (Y800)",
.guid = UVC_GUID_FORMAT_Y800,
.fcc= V4L2_PIX_FMT_GREY,
},
{
- .name = "Greyscale (16-bit)",
+ .name = "Greyscale 8-bit (Y8 )",
+ .guid = UVC_GUID_FORMAT_Y8,
+ .fcc= V4L2_PIX_FMT_GREY,
+ },
+ {
+ .name = "Greyscale 10-bit (Y10 )",
+ .guid = UVC_GUID_FORMAT_Y10,
+ .fcc= V4L2_PIX_FMT_Y10,
+ },
+ {
+ .name = "Greyscale 12-bit (Y12 )",
+ .guid = UVC_GUID_FORMAT_Y12,
+ .fcc= V4L2_PIX_FMT_Y12,
+ },
+ {
+ .name = "Greyscale 16-bit (Y16 )",
.guid = UVC_GUID_FORMAT_Y16,
.fcc= V4L2_PIX_FMT_Y16,
},
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 7c3d082..3764040 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -79,6 +79,15 @@
#define UVC_GUID_FORMAT_Y800 \
{ 'Y', '8', '0', '0', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_Y8 \
+ { 'Y', '8', ' ', ' ', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_Y10 \
+ { 'Y', '1', '0', ' ', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_Y12 \
+ { 'Y', '1', '2', ' ', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
#define UVC_GUID_FORMAT_Y16 \
{ 'Y', '1', '6', ' ', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
problem with baycom driver
Hi, It seems the baycom driver (for ham radio) needs some attention. The problems: - the baycom_ser_hdx driver does not work at all: very occasionally it switches the radio to send and transmit the data, but that's only one in thousand - the baycom_ser_fdx does seem to send, but only 1 or 2 packets, then something odd happens: the radio does transmit something but it is not recognizable as data. it sounds like a couple of ticks, not the recognizable modem sound. Important: if I do a sethdlc command, it again does send 1 or 2 valid packets! The system on which I try it, is a 3.2GHz p4 (with HT) so I don't think it is a problem with the system not keeping up. The pc is a: Manufacturer: IBM Product Name: 8215F7G Version: ThinkCentre M52 Things are setup like this: /bin/setserial /dev/ttyS0 uart none /sbin/modprobe baycom_ser_fdx 'mode=ser12*' iobase=0x3f8 irq=4 /usr/bin/sethdlc -i bcsf0 -a txd 200 slot 100 ppersist 40 half /sbin/ifconfig bcsf0 hw ax25 FH1GOU-1 up I played a little with the txd and does not help. Using full or half does not make a difference so far that it looks as if the first part of the packet is missing if I full duplex mode but I'm not entirely sure of that (no second modem setup). I verified the problem by listening with a second radio. Folkert van Heusden -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] debug: Do not permit CONFIG_DEBUG_STACK_USAGE=y on IA64 or PARISC
> I agree with this. Most of it looks easily fixable, but how would I
> enable the fix for ia64? For PA it's simple: I'll just use
> CONFIG_STACK_GROWSUP, but that won't work for you.
ia64 has an ugly chicken vs. egg build dependency. When trying to build our
asm-offsets.h
file (to get #define constants for various structure sizes and offsets in a
format that is
usable in assembly code) we get:
include/linux/sched.h:2539: error: 'IA64_TASK_SIZE' undeclared (first use in
this function)
Which is sad because IA64_TASK_SIZE is one of the #defines that asm-offsets.h
is trying
to produce.
Which is why I just threw up my hands in despair and said "!IA64" for this
option.
-Tony
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [Pv-drivers] [vmw_vmci 11/11] Apply the header code to make VMCI build
On Sat, Jul 28, 2012 at 12:55:35PM -0700, Greg KH wrote: > On Fri, Jul 27, 2012 at 01:29:27PM -0700, Dmitry Torokhov wrote: > > On Fri, Jul 27, 2012 at 11:16:39AM -0700, Greg KH wrote: > > > On Fri, Jul 27, 2012 at 10:20:43AM -0700, Andrew Stiegmann wrote: > > > > > The kernel style is to use lower_case for everything. > > > > > So this would become: > > > > > > > > > > vmci_device_get() > > > > > > > > > > This is obviously a very general comment and applies everywhere. > > > > > > > > I wish I could lower case these symbols but VMCI has already existed > > > > outside the mainline Linux tree for some time now and changing these > > > > exported symbols would mean that other drivers that depend on VMCI > > > > (vSock, vmhgfs) would need to change as well. One thought that did > > > > come to mind was exporting both VMCI_Device_Get and vmci_device_get > > > > but that would likely just confuse people. So in short I have made > > > > function names lower case where possible, but exported symbols could > > > > not be changed. > > > > > > Not true at all. You want those drivers to be merged as well, right? > > > So they will need to have their functions changed, and their code as > > > well. > > > > > > Just wait until we get to the "change your functionality around" > > > requests, those will require those drivers to change. Right now we are > > > at the "silly and obvious things you did wrong" stage of the review > > > process :) > > > > > > So please fix these, and also, post these drivers as well, so we can see > > > how they interact with the core code. > > > > > > Actually, if you are going to need lots of refactoring for these > > > drivers, and the core, I would recommend putting this all in the staging > > > tree, to allow that to happen over time. That would ensure that your > > > users keep having working systems, and let you modify the interfaces > > > better and easier, than having to keep it all out-of-tree. > > > > > > What do you think? > > > > Actually I think that we'd prefer to keep this in a patch-based form, at > > least for now, because majority of our users get these drivers with > > VMware Tools and will continue doing so until ditsributions start > > enabling VMCI in their kernels. Which they probably won't until VMCI > > moves form staging. We'd also have to constantly adjust drivers that we > > are not working on getting upstream at this time to work with the > > rapidly changing version of VMCI in staging, which will just add work > > for us. > > That wouldn't be an issue if you just include all of the drivers in the > tree at the same time, right? Maybe it wouldn't, however at this time we have not scheduled any resources for upstreaming vmhgfs driver. We however do seek feedback on vmci driver (and later vsock) for which we did schedule resources. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Introduce percpu rw semaphores
On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote: > Introduce percpu rw semaphores > > When many CPUs are locking a rw semaphore for read concurrently, cache > line bouncing occurs. When a CPU acquires rw semaphore for read, the > CPU writes to the cache line holding the semaphore. Consequently, the > cache line is being moved between CPUs and this slows down semaphore > acquisition. > > This patch introduces new percpu rw semaphores. They are functionally > identical to existing rw semaphores, but locking the percpu rw semaphore > for read is faster and locking for write is slower. > > The percpu rw semaphore is implemented as a percpu array of rw > semaphores, each semaphore for one CPU. When some thread needs to lock > the semaphore for read, only semaphore on the current CPU is locked for > read. When some thread needs to lock the semaphore for write, semaphores > for all CPUs are locked for write. This avoids cache line bouncing. > > Note that the thread that is locking percpu rw semaphore may be > rescheduled, it doesn't cause bug, but cache line bouncing occurs in > this case. > > Signed-off-by: Mikulas Patocka I am curious to see how this performs with 4096 cpus ? Really you shouldnt use rwlock in a path if this might hurt performance. RCU is probably a better answer. (bdev->bd_block_size should be read exactly once ) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Pv-drivers] [vmw_vmci 11/11] Apply the header code to make VMCI build
On Fri, Jul 27, 2012 at 01:29:27PM -0700, Dmitry Torokhov wrote: > On Fri, Jul 27, 2012 at 11:16:39AM -0700, Greg KH wrote: > > On Fri, Jul 27, 2012 at 10:20:43AM -0700, Andrew Stiegmann wrote: > > > > The kernel style is to use lower_case for everything. > > > > So this would become: > > > > > > > > vmci_device_get() > > > > > > > > This is obviously a very general comment and applies everywhere. > > > > > > I wish I could lower case these symbols but VMCI has already existed > > > outside the mainline Linux tree for some time now and changing these > > > exported symbols would mean that other drivers that depend on VMCI > > > (vSock, vmhgfs) would need to change as well. One thought that did > > > come to mind was exporting both VMCI_Device_Get and vmci_device_get > > > but that would likely just confuse people. So in short I have made > > > function names lower case where possible, but exported symbols could > > > not be changed. > > > > Not true at all. You want those drivers to be merged as well, right? > > So they will need to have their functions changed, and their code as > > well. > > > > Just wait until we get to the "change your functionality around" > > requests, those will require those drivers to change. Right now we are > > at the "silly and obvious things you did wrong" stage of the review > > process :) > > > > So please fix these, and also, post these drivers as well, so we can see > > how they interact with the core code. > > > > Actually, if you are going to need lots of refactoring for these > > drivers, and the core, I would recommend putting this all in the staging > > tree, to allow that to happen over time. That would ensure that your > > users keep having working systems, and let you modify the interfaces > > better and easier, than having to keep it all out-of-tree. > > > > What do you think? > > Actually I think that we'd prefer to keep this in a patch-based form, at > least for now, because majority of our users get these drivers with > VMware Tools and will continue doing so until ditsributions start > enabling VMCI in their kernels. Which they probably won't until VMCI > moves form staging. We'd also have to constantly adjust drivers that we > are not working on getting upstream at this time to work with the > rapidly changing version of VMCI in staging, which will just add work > for us. That wouldn't be an issue if you just include all of the drivers in the tree at the same time, right? Just like what the hyper-v developers did. greg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PULL REQUEST] i2c-embedded for 3.6
Linus, please pull the changes for the "embedded" part of the I2C subsystem: * lots of devicetree conversions of drivers (and preparations for that) * big cleanups for drivers for OMAP, Tegra, Nomadik, Blackfin * Rafael's struct dev_pm_ops conversion patches for I2C * usual driver cleanups and fixes All patches have been in linux-next for an apropriate time and all patches touching files outside of i2c-folders should have proper acks from the maintainers. Thanks, Wolfram The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://git.pengutronix.de/git/wsa/linux.git i2c-embedded/for-next for you to fetch changes up to 5db20c49e2d6581797c17057e068d89d6677aa24: Revert "i2c: tegra: convert normal suspend/resume to *_noirq" (2012-07-24 17:32:45 +0200) Alessandro Rubini (3): i2c-nomadik: move header to i2c-nomadik: turn the platform driver to an amba driver i2c-nomadik: depend on ARM_AMBA, not PLAT_NOMADIK Andrew Lunn (1): I2C: MV64XYZ: Add Device Tree support Fabio Estevam (1): i2c: i2c-imx: Adapt the clock name to the new clock framework Florian Fainelli (1): i2c-mv64: allow more than one driver instance Ganesan Ramalingam (2): i2c: i2c-ocores: Use reg-shift property i2c: i2c-ocores: support for 16bit and 32bit IO Jayachandran C (2): i2c: i2c-ocores: DT bindings and minor fixes. V4L/DVB: mfd: use reg_shift instead of regstep Jon Hunter (1): i2c: omap: Correct I2C revision for OMAP3 Karol Lewandowski (1): i2c: s3c2410: Fix pointer type passed to of_match_node() Laxman Dewangan (8): i2c: tegra: make sure register writes completes i2c: tegra: add PROTOCOL_MANGLING as supported functionality. i2c: tegra: support for I2C_M_NOSTART functionality i2c: tegra: make all resource allocation through devm_* i2c: tegra: remove unused member variable i2c: tegra: use clk_disable_unprepare in place of clk_disable i2c: tegra: use of_match_ptr() for match_table initialization i2c: tegra: convert normal suspend/resume to *_noirq Linus Walleij (2): i2c: stu300: use clk_prepare/unprepare i2c: stu300: use devm managed resources Marc Kleine-Budde (1): i2c: mxs: mxs_i2c_finish_read: mute flase positive uninitialized var Marek Vasut (1): i2c: mxs: Set I2C timing registers for mxs-i2c Mark Brown (1): i2c-s3c2410: Use plain pm_runtime_put() Michael Hennerich (1): i2c: i2c-bfin-twi: Illegal i2c bus lock upon certain transfer scenarios. Neil Brown (1): I2C: OMAP: Fix timeout problem during suspend. Rafael J. Wysocki (7): i2c-at91: Use struct dev_pm_ops for power management i2c-bfin-twi: Use struct dev_pm_ops for power management i2c-ocores: Use struct dev_pm_ops for power management i2c-pnx: Use struct dev_pm_ops for power management i2c-puv3: Use struct dev_pm_ops for power management i2c-stu300: Use struct dev_pm_ops for power management i2c-tegra: Use struct dev_pm_ops for power management Richard Zhao (1): i2c: imx: convert to use managed functions Shubhrajyoti D (12): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Prevent the register access after pm_runtime_put in probe I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Do not set the XUDF(Transmit underflow) if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 i2c: omap: Annotate the remove code i2c: omap: Use SET_RUNTIME_PM_OPS i2c: omap: Do not initialise the completion everytime Sonic Zhang (7): i2c: i2c-bfin-twi: Improve the patch for bug "Illegal i2c bus lock upon certain transfer scenarios". i2c: i2c-bfin-twi: Break dead waiting loop if i2c device misbehaves. i2c: i2c-bfin-twi: Tighten condition when failing I2C transfer if MEN bit is reset unexpectedly. i2c:i2c-bfin-twi: TWI fails to restart next transfer in high system load. i2c:i2c-bfin-twi: include twi head file i2c: i2c-bfin-twi: Move TWI peripheral pin request array to platform data. i2c: i2c-bfin-twi: Move blackfin TWI register access Macro to head file. Tasslehoff Kjappfot (1): I2C: OMAP: prevent the overwrite of the errata flags Virupax Sadashivpetimath (1): i2c-nomadik: Add 10-bit addressing support Wolfram Sang (4): devicetree: bindings: gpio-i2c belongs to i2c not gpio i2c: imx: make bitrate an u32 type i2c: mv64: remove EXPERIMENTAL tag Revert
Re: [PATCH 2/4] x86 idle APM: delete apm_cpu_idle()
On Fri, 27 Jul 2012 18:42:53 -0400 Len Brown wrote: > From: Len Brown > > The APM idle feature to call into the BIOS > is known to break some machines, and it has dubious benefit > on the (decades old) machines it doesn't break. You mean "doesn't fit my current plan" I think. I see almost no bugzilla APM reports. It's been solid for years. It makes a big difference on older systems as it drops the clock. If we are going to drop this we should probaly also drop APM support entirely and 386/486 support. If not IMHO it should stay. Various embedded platforms are still using ancient hardware setups. This is a small stable piece of code that has required no maintainance in years Furthermore we have a feature removal process. Mark it down to be removed in July 2013 if there are no objections, and then wait as per proper process. NAK Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: move "IPv6: sending pkt_too_big to self" to NETDEBUG
On Sat, 2012-07-28 at 17:06 +0200, Philipp Kern wrote:
> ip6_xmit checks if the outgoing packet is larger than the path MTU and
> emits ICMPv6 packet too big locally if this is the case. Logging this,
> even at KERN_DEBUG, confuses users. It is also not actually helpful for
> debugging, given that there is no reference to the connection that
> triggered this event.
[]
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
[]
> @@ -241,7 +241,7 @@ int ip6_xmit(struct sock *sk, struct sk_buff *skb, struct
> flowi6 *fl6,
> dst->dev, dst_output);
> }
>
> - net_dbg_ratelimited("IPv6: sending pkt_too_big to self\n");
> + LIMIT_NETDEBUG("IPv6: sending pkt_too_big to self\n");
LIMIT_NETDEBUG doesn't include a logging level.
Add a KERN_DEBUG prefix or another KERN_.
Maybe it'd be better to add the context too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cx18: Declare MODULE_FIRMWARE usage
On Fri, 2012-07-27 at 10:45 -0600, Tim Gardner wrote:
> Cc: Andy Walls
Acked-by: Andy Walls
Regards,
Andy
> Cc: Mauro Carvalho Chehab
> Cc: ivtv-de...@ivtvdriver.org
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Tim Gardner
> ---
> drivers/media/video/cx18/cx18-av-firmware.c |2 ++
> drivers/media/video/cx18/cx18-driver.c |1 +
> drivers/media/video/cx18/cx18-dvb.c |6 +-
> drivers/media/video/cx18/cx18-firmware.c| 10 --
> 4 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/video/cx18/cx18-av-firmware.c
> b/drivers/media/video/cx18/cx18-av-firmware.c
> index 280aa4d..a34fd08 100644
> --- a/drivers/media/video/cx18/cx18-av-firmware.c
> +++ b/drivers/media/video/cx18/cx18-av-firmware.c
> @@ -221,3 +221,5 @@ int cx18_av_loadfw(struct cx18 *cx)
> release_firmware(fw);
> return 0;
> }
> +
> +MODULE_FIRMWARE(FWFILE);
> diff --git a/drivers/media/video/cx18/cx18-driver.c
> b/drivers/media/video/cx18/cx18-driver.c
> index 7e5ffd6..c67733d 100644
> --- a/drivers/media/video/cx18/cx18-driver.c
> +++ b/drivers/media/video/cx18/cx18-driver.c
> @@ -1357,3 +1357,4 @@ static void __exit module_cleanup(void)
>
> module_init(module_start);
> module_exit(module_cleanup);
> +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
> diff --git a/drivers/media/video/cx18/cx18-dvb.c
> b/drivers/media/video/cx18/cx18-dvb.c
> index f41922b..3eac59c 100644
> --- a/drivers/media/video/cx18/cx18-dvb.c
> +++ b/drivers/media/video/cx18/cx18-dvb.c
> @@ -40,6 +40,8 @@
>
> DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
> +#define FWFILE "dvb-cx18-mpc718-mt352.fw"
> +
> #define CX18_REG_DMUX_NUM_PORT_0_CONTROL 0xd5a000
> #define CX18_CLOCK_ENABLE20xc71024
> #define CX18_DMUX_CLK_MASK0x0080
> @@ -135,7 +137,7 @@ static int yuan_mpc718_mt352_reqfw(struct cx18_stream
> *stream,
> const struct firmware **fw)
> {
> struct cx18 *cx = stream->cx;
> - const char *fn = "dvb-cx18-mpc718-mt352.fw";
> + const char *fn = FWFILE;
> int ret;
>
> ret = request_firmware(fw, fn, >pci_dev->dev);
> @@ -603,3 +605,5 @@ static int dvb_register(struct cx18_stream *stream)
>
> return ret;
> }
> +
> +MODULE_FIRMWARE(FWFILE);
> diff --git a/drivers/media/video/cx18/cx18-firmware.c
> b/drivers/media/video/cx18/cx18-firmware.c
> index b85c292..a1c1cec 100644
> --- a/drivers/media/video/cx18/cx18-firmware.c
> +++ b/drivers/media/video/cx18/cx18-firmware.c
> @@ -376,6 +376,9 @@ void cx18_init_memory(struct cx18 *cx)
> cx18_write_reg(cx, 0x0101, CX18_WMB_CLIENT14); /* AVO */
> }
>
> +#define CX18_CPU_FIRMWARE "v4l-cx23418-cpu.fw"
> +#define CX18_APU_FIRMWARE "v4l-cx23418-apu.fw"
> +
> int cx18_firmware_init(struct cx18 *cx)
> {
> u32 fw_entry_addr;
> @@ -400,7 +403,7 @@ int cx18_firmware_init(struct cx18 *cx)
> cx18_sw1_irq_enable(cx, IRQ_CPU_TO_EPU | IRQ_APU_TO_EPU);
> cx18_sw2_irq_enable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
>
> - sz = load_cpu_fw_direct("v4l-cx23418-cpu.fw", cx->enc_mem, cx);
> + sz = load_cpu_fw_direct(CX18_CPU_FIRMWARE, cx->enc_mem, cx);
> if (sz <= 0)
> return sz;
>
> @@ -408,7 +411,7 @@ int cx18_firmware_init(struct cx18 *cx)
> cx18_init_scb(cx);
>
> fw_entry_addr = 0;
> - sz = load_apu_fw_direct("v4l-cx23418-apu.fw", cx->enc_mem, cx,
> + sz = load_apu_fw_direct(CX18_APU_FIRMWARE, cx->enc_mem, cx,
> _entry_addr);
> if (sz <= 0)
> return sz;
> @@ -451,3 +454,6 @@ int cx18_firmware_init(struct cx18 *cx)
> cx18_write_reg_expect(cx, 0x14001400, 0xc78110, 0x1400, 0x14001400);
> return 0;
> }
> +
> +MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
> +MODULE_FIRMWARE(CX18_APU_FIRMWARE);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ivtv: Declare MODULE_FIRMWARE usage
On Fri, 2012-07-27 at 09:45 -0600, Tim Gardner wrote: > On 07/26/2012 04:21 PM, Andy Walls wrote: > > On Thu, 2012-07-26 at 12:26 -0600, Tim Gardner wrote: > >> Cc: Andy Walls > >> Cc: Mauro Carvalho Chehab > >> Cc: ivtv-de...@ivtvdriver.org > >> Cc: linux-me...@vger.kernel.org > >> Signed-off-by: Tim Gardner > >> --- > >> drivers/media/video/ivtv/ivtv-firmware.c |4 > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/drivers/media/video/ivtv/ivtv-firmware.c > >> b/drivers/media/video/ivtv/ivtv-firmware.c > >> index 02c5ade..6ec7705 100644 > >> --- a/drivers/media/video/ivtv/ivtv-firmware.c > >> +++ b/drivers/media/video/ivtv/ivtv-firmware.c > >> @@ -396,3 +396,7 @@ int ivtv_firmware_check(struct ivtv *itv, char *where) > >> > >>return res; > >> } > >> + > >> +MODULE_FIRMWARE(CX2341X_FIRM_ENC_FILENAME); > >> +MODULE_FIRMWARE(CX2341X_FIRM_DEC_FILENAME); > >> +MODULE_FIRMWARE(IVTV_DECODE_INIT_MPEG_FILENAME); > > > > Only the PVR-350, based on the iTVC-15/CX23415 chip, needs the > > CX2341X_FIRM_DEC_FILENAME and IVTV_DECODE_INIT_MPEG_FILENAME. (And even > > in the case of that card, not having the IVTV_DECODE_INIT_MPEG_FILENAME > > file is non-fatal.) > > > > I would not want anything in user-space or kernel space preventing the > > ivtv module from loading, if some of those files don't exist. > > > > Regards, > > Andy > > > > MODULE_FIRMWARE is informational only and has no runtime impact. OK. Acked-by: Andy Walls Regards, Andy > > rtg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cx25840: Declare MODULE_FIRMWARE usage
On Fri, 2012-07-27 at 06:06 -0600, Tim Gardner wrote:
> On 07/26/2012 03:59 PM, Andy Walls wrote:
> > On Thu, 2012-07-26 at 10:44 -0600, Tim Gardner wrote:
> >> Cc: Mauro Carvalho Chehab
> >> Cc: linux-me...@vger.kernel.org
> >> Signed-off-by: Tim Gardner
> >> ---
> >> drivers/media/video/cx25840/cx25840-firmware.c | 15 ---
> >> 1 file changed, 12 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/media/video/cx25840/cx25840-firmware.c
> >> b/drivers/media/video/cx25840/cx25840-firmware.c
> >> index 8150200..b3169f9 100644
> >> --- a/drivers/media/video/cx25840/cx25840-firmware.c
> >> +++ b/drivers/media/video/cx25840/cx25840-firmware.c
> >> @@ -61,6 +61,10 @@ static void end_fw_load(struct i2c_client *client)
> >>cx25840_write(client, 0x803, 0x03);
> >> }
> >>
> >> +#define CX2388x_FIRMWARE "v4l-cx23885-avcore-01.fw"
> >> +#define CX231xx_FIRMWARE "v4l-cx231xx-avcore-01.fw"
> >> +#define CX25840_FIRMWARE "v4l-cx25840.fw"
> >> +
> >> static const char *get_fw_name(struct i2c_client *client)
> >> {
> >>struct cx25840_state *state = to_state(i2c_get_clientdata(client));
> >> @@ -68,10 +72,10 @@ static const char *get_fw_name(struct i2c_client
> >> *client)
> >>if (firmware[0])
> >>return firmware;
> >>if (is_cx2388x(state))
> >> - return "v4l-cx23885-avcore-01.fw";
> >> + return CX2388x_FIRMWARE;
> >>if (is_cx231xx(state))
> >> - return "v4l-cx231xx-avcore-01.fw";
> >> - return "v4l-cx25840.fw";
> >> + return CX231xx_FIRMWARE;
> >> + return CX25840_FIRMWARE;
> >> }
> >>
> >> static int check_fw_load(struct i2c_client *client, int size)
> >> @@ -164,3 +168,8 @@ int cx25840_loadfw(struct i2c_client *client)
> >>
> >>return check_fw_load(client, size);
> >> }
> >> +
> >> +MODULE_FIRMWARE(CX2388x_FIRMWARE);
> >> +MODULE_FIRMWARE(CX231xx_FIRMWARE);
> >> +MODULE_FIRMWARE(CX25840_FIRMWARE);
> >> +
> >
> > How will the firmware attribute in the .module_info section be used?
> >
> > For any one model of TV capture device, the cx25840 only needs one of
> > the above firmware files. The others need not exist.
> >
> > I would not want anything in user or kernel space to refuse to load the
> > module just because all 3 firmware files are not present.
> >
> > Regards,
> > Andy
> >
>
> The MODULE_FIRMWARE macro is purely informational. Declaring the
> firmware files that the driver _might_ use helps me pare down the
> external firmware package to just those files that I know it must have.
Would it help if the MODULE_FIRMWARE text was more descriptive, e.g.:
MODULE_FIRMWARE(CX25840_FIRMWARE " CX25840/1/2/3 chips only");
MODULE_FIRMWARE(CX231xx_FIRMWARE " CX23100/1/2 chips only");
MODULE_FIRMWARE(CX2388x_FIRMWARE " CX23885/7/8 chips only");
Similarly for ivtv:
MODULE_FIRMWARE(CX2341X_FIRM_ENC_FILENAME);
MODULE_FIRMWARE(CX2341X_FIRM_DEC_FILENAME " PVR-350 only");
MODULE_FIRMWARE(IVTV_DECODE_INIT_MPEG_FILENAME " PVR-350 only");
and cx18:
MODULE_FIRMWARE(FWFILE); /* v4l-cx23418-dig.fw */
MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
MODULE_FIRMWARE(CX18_APU_FIRMWARE);
MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE " Non-HVR-1600 cards");
MODULE_FIRMWARE(FWFILE " Yuan MPC-718 only");
or would that confuse some userspace tools?
>
> This patch will have no runtime impact.
OK. For the original patch:
Acked-by: Andy Walls
Regards,
Andy
> Note that there are plenty of uses of the MODULE_FIRMWARE macro within
> the kernel.
>
> rtg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: fix DOCBOOKS=... building
From: Johannes Berg Prior to commit 4266129964b8238526936d723de65b419d8069c6 Author: Mauro Carvalho Chehab Date: Tue May 31 16:27:44 2011 -0300 [media] DocBook: Move all media docbook stuff into its own directory it was possible to build only a single (or more) book(s) by calling, for example make htmldocs DOCBOOKS=80211.xml This now fails: cp: target `.../Documentation/DocBook//media_api' is not a directory Ignore errors from that copy to make this possible again. Cc: Mauro Carvalho Chehab Acked-by: Randy Dunlap Signed-off-by: Johannes Berg --- > I'm no longer the Documentation maintainer, but Rob Landley > could merge it. You probably will need to resend it to him. Documentation/DocBook/media/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Documentation/DocBook/media/Makefile 2012-06-13 10:39:58.0 +0200 +++ b/Documentation/DocBook/media/Makefile 2012-06-13 10:40:05.0 +0200 @@ -195,7 +195,7 @@ DVB_DOCUMENTED = \ # install_media_images = \ - $(Q)cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api + $(Q)-cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api $(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64 $(Q)base64 -d $< >$@ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] blockdev: turn a rw semaphore into a percpu rw semaphore
blockdev: turn a rw semaphore into a percpu rw semaphore
This avoids cache line bouncing when many processes lock the semaphore
for read.
Partially based on a patch by Jeff Moyer .
Signed-off-by: Mikulas Patocka
---
fs/block_dev.c | 30 --
include/linux/fs.h |3 ++-
2 files changed, 22 insertions(+), 11 deletions(-)
Index: linux-3.5-fast/fs/block_dev.c
===
--- linux-3.5-fast.orig/fs/block_dev.c 2012-07-28 18:32:10.0 +0200
+++ linux-3.5-fast/fs/block_dev.c 2012-07-28 18:32:12.0 +0200
@@ -127,7 +127,7 @@ int set_blocksize(struct block_device *b
return -EINVAL;
/* Prevent starting I/O or mapping the device */
- down_write(>bd_block_size_semaphore);
+ percpu_down_write(>bd_block_size_semaphore);
/* Check that the block device is not memory mapped */
mapping = bdev->bd_inode->i_mapping;
@@ -135,7 +135,7 @@ int set_blocksize(struct block_device *b
if (!prio_tree_empty(>i_mmap) ||
!list_empty(>i_mmap_nonlinear)) {
mutex_unlock(>i_mmap_mutex);
- up_write(>bd_block_size_semaphore);
+ percpu_up_write(>bd_block_size_semaphore);
return -EBUSY;
}
mutex_unlock(>i_mmap_mutex);
@@ -148,7 +148,7 @@ int set_blocksize(struct block_device *b
kill_bdev(bdev);
}
- up_write(>bd_block_size_semaphore);
+ percpu_up_write(>bd_block_size_semaphore);
return 0;
}
@@ -460,6 +460,12 @@ static struct inode *bdev_alloc_inode(st
struct bdev_inode *ei = kmem_cache_alloc(bdev_cachep, GFP_KERNEL);
if (!ei)
return NULL;
+
+ if (unlikely(percpu_init_rwsem(>bdev.bd_block_size_semaphore))) {
+ kmem_cache_free(bdev_cachep, ei);
+ return NULL;
+ }
+
return >vfs_inode;
}
@@ -468,6 +474,8 @@ static void bdev_i_callback(struct rcu_h
struct inode *inode = container_of(head, struct inode, i_rcu);
struct bdev_inode *bdi = BDEV_I(inode);
+ percpu_free_rwsem(>bdev.bd_block_size_semaphore);
+
kmem_cache_free(bdev_cachep, bdi);
}
@@ -491,7 +499,6 @@ static void init_once(void *foo)
inode_init_once(>vfs_inode);
/* Initialize mutex for freeze. */
mutex_init(>bd_fsfreeze_mutex);
- init_rwsem(>bd_block_size_semaphore);
}
static inline void __bd_forget(struct inode *inode)
@@ -1592,12 +1599,13 @@ ssize_t blkdev_aio_read(struct kiocb *io
{
ssize_t ret;
struct block_device *bdev = I_BDEV(iocb->ki_filp->f_mapping->host);
+ percpu_rwsem_ptr p;
- down_read(>bd_block_size_semaphore);
+ p = percpu_down_read(>bd_block_size_semaphore);
ret = generic_file_aio_read(iocb, iov, nr_segs, pos);
- up_read(>bd_block_size_semaphore);
+ percpu_up_read(>bd_block_size_semaphore, p);
return ret;
}
@@ -1616,10 +1624,11 @@ ssize_t blkdev_aio_write(struct kiocb *i
struct file *file = iocb->ki_filp;
struct block_device *bdev = I_BDEV(file->f_mapping->host);
ssize_t ret;
+ percpu_rwsem_ptr p;
BUG_ON(iocb->ki_pos != pos);
- down_read(>bd_block_size_semaphore);
+ p = percpu_down_read(>bd_block_size_semaphore);
ret = __generic_file_aio_write(iocb, iov, nr_segs, >ki_pos);
if (ret > 0 || ret == -EIOCBQUEUED) {
@@ -1630,7 +1639,7 @@ ssize_t blkdev_aio_write(struct kiocb *i
ret = err;
}
- up_read(>bd_block_size_semaphore);
+ percpu_up_read(>bd_block_size_semaphore, p);
return ret;
}
@@ -1640,12 +1649,13 @@ int blkdev_mmap(struct file *file, struc
{
int ret;
struct block_device *bdev = I_BDEV(file->f_mapping->host);
+ percpu_rwsem_ptr p;
- down_read(>bd_block_size_semaphore);
+ p = percpu_down_read(>bd_block_size_semaphore);
ret = generic_file_mmap(file, vma);
- up_read(>bd_block_size_semaphore);
+ percpu_up_read(>bd_block_size_semaphore, p);
return ret;
}
Index: linux-3.5-fast/include/linux/fs.h
===
--- linux-3.5-fast.orig/include/linux/fs.h 2012-07-28 18:32:10.0
+0200
+++ linux-3.5-fast/include/linux/fs.h 2012-07-28 18:32:12.0 +0200
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/*
* It's silly to have NR_OPEN bigger than NR_FILE, but you can change
@@ -714,7 +715,7 @@ struct block_device {
/* Mutex for freeze */
struct mutexbd_fsfreeze_mutex;
/* A semaphore that prevents I/O while block size is being changed */
- struct rw_semaphore bd_block_size_semaphore;
+ struct percpu_rw_semaphore bd_block_size_semaphore;
};
/*
--
To unsubscribe from this list: send the line "unsubscribe
[PATCH 2/3] Introduce percpu rw semaphores
Introduce percpu rw semaphores
When many CPUs are locking a rw semaphore for read concurrently, cache
line bouncing occurs. When a CPU acquires rw semaphore for read, the
CPU writes to the cache line holding the semaphore. Consequently, the
cache line is being moved between CPUs and this slows down semaphore
acquisition.
This patch introduces new percpu rw semaphores. They are functionally
identical to existing rw semaphores, but locking the percpu rw semaphore
for read is faster and locking for write is slower.
The percpu rw semaphore is implemented as a percpu array of rw
semaphores, each semaphore for one CPU. When some thread needs to lock
the semaphore for read, only semaphore on the current CPU is locked for
read. When some thread needs to lock the semaphore for write, semaphores
for all CPUs are locked for write. This avoids cache line bouncing.
Note that the thread that is locking percpu rw semaphore may be
rescheduled, it doesn't cause bug, but cache line bouncing occurs in
this case.
Signed-off-by: Mikulas Patocka
---
include/linux/percpu-rwsem.h | 77 +++
1 file changed, 77 insertions(+)
Index: linux-3.5-fast/include/linux/percpu-rwsem.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-3.5-fast/include/linux/percpu-rwsem.h 2012-07-28 18:41:05.0
+0200
@@ -0,0 +1,77 @@
+#ifndef _LINUX_PERCPU_RWSEM_H
+#define _LINUX_PERCPU_RWSEM_H
+
+#include
+#include
+
+#ifndef CONFIG_SMP
+
+#define percpu_rw_semaphorerw_semaphore
+#define percpu_rwsem_ptr int
+#define percpu_down_read(x)(down_read(x), 0)
+#define percpu_up_read(x, y) up_read(x)
+#define percpu_down_write down_write
+#define percpu_up_writeup_write
+#define percpu_init_rwsem(x) (({init_rwsem(x);}), 0)
+#define percpu_free_rwsem(x) do { } while (0)
+
+#else
+
+struct percpu_rw_semaphore {
+ struct rw_semaphore __percpu *s;
+};
+
+typedef struct rw_semaphore *percpu_rwsem_ptr;
+
+static inline percpu_rwsem_ptr percpu_down_read(struct percpu_rw_semaphore
*sem)
+{
+ struct rw_semaphore *s = __this_cpu_ptr(sem->s);
+ down_read(s);
+ return s;
+}
+
+static inline void percpu_up_read(struct percpu_rw_semaphore *sem,
percpu_rwsem_ptr s)
+{
+ up_read(s);
+}
+
+static inline void percpu_down_write(struct percpu_rw_semaphore *sem)
+{
+ int cpu;
+ for_each_possible_cpu(cpu) {
+ struct rw_semaphore *s = per_cpu_ptr(sem->s, cpu);
+ down_write(s);
+ }
+}
+
+static inline void percpu_up_write(struct percpu_rw_semaphore *sem)
+{
+ int cpu;
+ for_each_possible_cpu(cpu) {
+ struct rw_semaphore *s = per_cpu_ptr(sem->s, cpu);
+ up_write(s);
+ }
+}
+
+static inline int percpu_init_rwsem(struct percpu_rw_semaphore *sem)
+{
+ int cpu;
+ sem->s = alloc_percpu(struct rw_semaphore);
+ if (unlikely(!sem->s))
+ return -ENOMEM;
+ for_each_possible_cpu(cpu) {
+ struct rw_semaphore *s = per_cpu_ptr(sem->s, cpu);
+ init_rwsem(s);
+ }
+ return 0;
+}
+
+static inline void percpu_free_rwsem(struct percpu_rw_semaphore *sem)
+{
+ free_percpu(sem->s);
+ sem->s = NULL; /* catch use after free bugs */
+}
+
+#endif
+
+#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Fix Crash when IO is being submitted and block size is changed
On Thu, 19 Jul 2012, Jeff Moyer wrote:
> Mikulas Patocka writes:
>
> > On Tue, 17 Jul 2012, Jeff Moyer wrote:
> >
>
> >> > This is the patch that fixes this crash: it takes a rw-semaphore around
> >> > all direct-IO path.
> >> >
> >> > (note that if someone is concerned about performance, the rw-semaphore
> >> > could be made per-cpu --- take it for read on the current CPU and take
> >> > it
> >> > for write on all CPUs).
> >>
> >> Here we go again. :-) I believe we had at one point tried taking a rw
> >> semaphore around GUP inside of the direct I/O code path to fix the fork
> >> vs. GUP race (that still exists today). When testing that, the overhead
> >> of the semaphore was *way* too high to be considered an acceptable
> >> solution. I've CC'd Larry Woodman, Andrea, and Kosaki Motohiro who all
> >> worked on that particular bug. Hopefully they can give better
> >> quantification of the slowdown than my poor memory.
> >>
> >> Cheers,
> >> Jeff
> >
> > Both down_read and up_read together take 82 ticks on Core2, 69 ticks on
> > AMD K10, 62 ticks on UltraSparc2 if the target is in L1 cache. So, if
> > percpu rw_semaphores were used, it would slow down only by this amount.
>
> Sorry, I'm not familiar with per-cpu rw semaphores. Where are they
> implemented?
Here I'm resending the upstream patches with per rw-semaphores - percpu
rw-semaphores are implemented in the next patch.
(For Jeff: you can use your patch for RHEL-6 that you did for perfocmance
testing, with the change that I proposed).
Mikulas
---
blockdev: fix a crash when block size is changed and I/O is issued
simultaneously
The kernel may crash when block size is changed and I/O is issued
simultaneously.
Because some subsystems (udev or lvm) may read any block device anytime,
the bug actually puts any code that changes a block device size in
jeopardy.
The crash can be reproduced if you place "msleep(1000)" to
blkdev_get_blocks just before "bh->b_size = max_blocks <<
inode->i_blkbits;".
Then, run "dd if=/dev/ram0 of=/dev/null bs=4k count=1 iflag=direct"
While it is waiting in msleep, run "blockdev --setbsz 2048 /dev/ram0"
You get a BUG.
The direct and non-direct I/O is written with the assumption that block
size does not change. It doesn't seem practical to fix these crashes
one-by-one there may be many crash possibilities when block size changes
at a certain place and it is impossible to find them all and verify the
code.
This patch introduces a new rw-lock bd_block_size_semaphore. The lock is
taken for read during I/O. It is taken for write when changing block
size. Consequently, block size can't be changed while I/O is being
submitted.
For asynchronous I/O, the patch only prevents block size change while
the I/O is being submitted. The block size can change when the I/O is in
progress or when the I/O is being finished. This is acceptable because
there are no accesses to block size when asynchronous I/O is being
finished.
The patch prevents block size changing while the device is mapped with
mmap.
Signed-off-by: Mikulas Patocka
---
drivers/char/raw.c |2 -
fs/block_dev.c | 60 +++--
include/linux/fs.h |4 +++
3 files changed, 63 insertions(+), 3 deletions(-)
Index: linux-3.5-rc6-devel/include/linux/fs.h
===
--- linux-3.5-rc6-devel.orig/include/linux/fs.h 2012-07-16 20:20:12.0
+0200
+++ linux-3.5-rc6-devel/include/linux/fs.h 2012-07-16 01:29:21.0
+0200
@@ -713,6 +713,8 @@ struct block_device {
int bd_fsfreeze_count;
/* Mutex for freeze */
struct mutexbd_fsfreeze_mutex;
+ /* A semaphore that prevents I/O while block size is being changed */
+ struct rw_semaphore bd_block_size_semaphore;
};
/*
@@ -2414,6 +2416,8 @@ extern int generic_segment_checks(const
unsigned long *nr_segs, size_t *count, int access_flags);
/* fs/block_dev.c */
+extern ssize_t blkdev_aio_read(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos);
extern ssize_t blkdev_aio_write(struct kiocb *iocb, const struct iovec *iov,
unsigned long nr_segs, loff_t pos);
extern int blkdev_fsync(struct file *filp, loff_t start, loff_t end,
Index: linux-3.5-rc6-devel/fs/block_dev.c
===
--- linux-3.5-rc6-devel.orig/fs/block_dev.c 2012-07-16 20:20:12.0
+0200
+++ linux-3.5-rc6-devel/fs/block_dev.c 2012-07-16 21:47:30.0 +0200
@@ -116,6 +116,8 @@ EXPORT_SYMBOL(invalidate_bdev);
int set_blocksize(struct block_device *bdev, int size)
{
+ struct address_space *mapping;
+
/* Size must be a power of two, and between 512 and PAGE_SIZE */
if (size > PAGE_SIZE || size < 512 || !is_power_of_2(size))
return
Re: [PATCH] uprobes: mmap_region() corrupts mm->mm_rb if uprobe_mmap() fails
On 07/28, Oleg Nesterov wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=843640 > > If mmap_region()->uprobe_mmap() fails, unmap_and_free_vma path > does unmap_region() but does not remove the soon-to-be-freed vma > from rb tree (actually there are more problems). Just in case... Ingo, this is orthogonal to other pending changes I sent. I think 3.6 (and 3.5-stable) needs this fix. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] uprobes: mmap_region() corrupts mm->mm_rb if uprobe_mmap() fails
https://bugzilla.redhat.com/show_bug.cgi?id=843640 If mmap_region()->uprobe_mmap() fails, unmap_and_free_vma path does unmap_region() but does not remove the soon-to-be-freed vma from rb tree (actually there are more problems). Perhaps we could do do_munmap() + return in this case, but in fact it is simply wrong to abort if uprobe_mmap() fails. Until at least we move the !UPROBE_COPY_INSN code from install_breakpoint() to uprobe_register(). For example, uprobe_mmap()->install_breakpoint() can fail if the probed insn is not supported (remember, uprobe_register() succeeds if nobody mmaps inode/offset), mmap() should not fail in this case. dup_mmap()->uprobe_mmap() is wrong too by the same reason, fork() can race with uprobe_register() and fail for no reason if it wins the race and does install_breakpoint() first. Change mmap_region() and dup_mmap() to ignore the error code from uprobe_mmap(). Reported-by: William Cohen Signed-off-by: Oleg Nesterov Cc: # v3.5 --- kernel/fork.c |4 ++-- mm/mmap.c |5 ++--- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index ab5211b..54bb88a 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -454,8 +454,8 @@ static int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm) if (retval) goto out; - if (file && uprobe_mmap(tmp)) - goto out; + if (file) + uprobe_mmap(tmp); } /* a new mm has just been created */ arch_dup_mmap(oldmm, mm); diff --git a/mm/mmap.c b/mm/mmap.c index 4fe2697..f25fd3f 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1355,9 +1355,8 @@ out: } else if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK)) make_pages_present(addr, addr + len); - if (file && uprobe_mmap(vma)) - /* matching probes but cannot insert */ - goto unmap_and_free_vma; + if (file) + uprobe_mmap(vma); return addr; -- 1.5.5.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: Kernel Oops while disconnecting USB peripheral (always)
On Sat, 28 Jul 2012, Daniel Mack wrote:
> Hmm, interesting. Thanks for sharing this. I personally never saw this
> bug kicking in, but if I understand your findings correctly, we would
> need something like the following patch for snd-usb and the storage driver?
>
> Sarbojit, could you give this a test and see whether your kernel still
> crashes in any of the two drivers?
> --- a/drivers/usb/storage/usb.c
> +++ b/drivers/usb/storage/usb.c
> @@ -1025,9 +1025,14 @@ void usb_stor_disconnect(struct usb_interface *intf)
> {
> struct us_data *us = usb_get_intfdata(intf);
>
> + if (!us)
> + return;
This can never happen. The disconnect routine gets called only once,
so us will not be NULL.
> +
> US_DEBUGP("storage_disconnect() called\n");
> quiesce_and_remove_host(us);
> release_everything(us);
> +
> + usb_set_intfdata(intf, NULL);
> }
> EXPORT_SYMBOL_GPL(usb_stor_disconnect);
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] GPIO changes for v3.6
On Sat, Jul 28, 2012 at 12:37:05AM +0200, Linus Walleij wrote: > Better page the MXC people so they can scream if something > goes wild. > Just tested the driver a little bit, and it still works for me. -- Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma: mxs_dma: Add the missing entries for mx6
On Wed, Jul 25, 2012 at 08:54:02AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Add the missing entries for mx6.
>
> Signed-off-by: Fabio Estevam
> ---
> Build tested only, as I currently do not have mx6 board handy.
>
> drivers/dma/mxs-dma.c |9 -
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
> index 7f41b25..6e8509b 100644
> --- a/drivers/dma/mxs-dma.c
> +++ b/drivers/dma/mxs-dma.c
> @@ -128,6 +128,7 @@ enum mxs_dma_devtype {
> enum mxs_dma_id {
> IMX23_DMA,
> IMX28_DMA,
> + IMX6Q_DMA,
> };
>
> struct mxs_dma_engine {
> @@ -158,7 +159,10 @@ static struct mxs_dma_type mxs_dma_types[] = {
> }, {
> .id = IMX28_DMA,
> .type = MXS_DMA_APBX,
> - }
> + }, {
> + .id = IMX6Q_DMA,
> + .type = MXS_DMA_APBH,
> + },
> };
>
> static struct platform_device_id mxs_dma_ids[] = {
> @@ -175,6 +179,8 @@ static struct platform_device_id mxs_dma_ids[] = {
> .name = "imx28-dma-apbx",
> .driver_data = (kernel_ulong_t) _dma_types[3],
> }, {
> + .name = "imx6q-dma-apbh",
> + .driver_data = (kernel_ulong_t) _dma_types[4],
> /* end of list */
> }
> };
> @@ -184,6 +190,7 @@ static const struct of_device_id mxs_dma_dt_ids[] = {
> { .compatible = "fsl,imx23-dma-apbx", .data = _dma_ids[1], },
> { .compatible = "fsl,imx28-dma-apbh", .data = _dma_ids[2], },
> { .compatible = "fsl,imx28-dma-apbx", .data = _dma_ids[3], },
> + { .compatible = "fsl,imx6q-dma-apbh", .data = _dma_ids[4], },
We do not need it. "fsl,imx28-dma-apbh" should just work for imx6q.
Regards,
Shawn
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, mxs_dma_dt_ids);
> --
> 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 1/3] sysfs: introduce a sysfs_create_file_uevent new API
On Fri, Jul 27, 2012 at 11:52 PM, Greg KH wrote: > On Fri, Jul 27, 2012 at 12:02:41PM +0800, Bryan Wu wrote: >> Send a uevent notification whenever a new sysfs file is created to allow >> userspace processes such as udev to modify permissions on the new files. > > This makes no sense, why not just call kobject_uevent after creating the > file when needed? Wrapping it up in a single function call doesn't add > any benefit that I can see, can you? > I actually just want to make it benefit for further similar issue in other subsystem, although I got this point from the email started by Colin Cross. I agree if it is just specific to LED subsystem, we'd better add this fixing in LED trigger core code. Maybe I worried about too much and if you guys all ack Colin's patch, I'm going to apply it. Thanks, -Bryan >> >> This new API function helps to do this. >> >> Signed-off-by: Bryan Wu >> --- >> fs/sysfs/file.c | 28 >> include/linux/sysfs.h | 13 + >> 2 files changed, 41 insertions(+) >> >> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c >> index 00012e3..5a22d13 100644 >> --- a/fs/sysfs/file.c >> +++ b/fs/sysfs/file.c >> @@ -576,6 +576,34 @@ int sysfs_create_file(struct kobject * kobj, const >> struct attribute * attr) >> >> } >> >> +/** >> + * sysfs_create_file_uevent - create an attribute file for an object >> + and send a uevent to userspace. > > kerneldoc needs to be on one line for function names, right? > > greg k-h -- Bryan Wu Kernel Developer+86.186-168-78255 Mobile Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: move "IPv6: sending pkt_too_big to self" to NETDEBUG
ip6_xmit checks if the outgoing packet is larger than the path MTU and
emits ICMPv6 packet too big locally if this is the case. Logging this,
even at KERN_DEBUG, confuses users. It is also not actually helpful for
debugging, given that there is no reference to the connection that
triggered this event.
Hence move this message to LIMIT_NETDEBUG, as suggested by Andi Kleen
back in 2001 (<20010215231715.26...@colin.muc.de>).
Signed-off-by: Philipp Kern
---
net/ipv6/ip6_output.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 5b2d63e..707002f 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -241,7 +241,7 @@ int ip6_xmit(struct sock *sk, struct sk_buff *skb, struct
flowi6 *fl6,
dst->dev, dst_output);
}
- net_dbg_ratelimited("IPv6: sending pkt_too_big to self\n");
+ LIMIT_NETDEBUG("IPv6: sending pkt_too_big to self\n");
skb->dev = dst->dev;
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_FRAGFAILS);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: genirq: Flags mismatch irq 5. 00000000 (ES1688) vs. 00000000
On 28.07.2012 15:20, Fengguang Wu wrote:
> (ES1688)
> Reply-To:
>
> Hi all,
>
> snd_es1688_create() seems not doing things right. It never frees the
> previously allocated resources on error return.. Anyone cares about
> this driver now?
Could you try the (not even compile-tested) patch attached?
Daniel
diff --git a/sound/isa/es1688/es1688_lib.c b/sound/isa/es1688/es1688_lib.c
index 1d47be8..7cb309a 100644
--- a/sound/isa/es1688/es1688_lib.c
+++ b/sound/isa/es1688/es1688_lib.c
@@ -658,18 +658,25 @@ int snd_es1688_create(struct snd_card *card,
chip->irq = -1;
chip->dma8 = -1;
- if ((chip->res_port = request_region(port + 4, 12, "ES1688")) == NULL) {
+ chip->res_port = request_region(port + 4, 12, "ES1688");
+ if (chip->res_port == NULL) {
snd_printk(KERN_ERR "es1688: can't grab port 0x%lx\n", port + 4);
- return -EBUSY;
+ err = -EBUSY;
+ goto exit;
}
- if (request_irq(irq, snd_es1688_interrupt, 0, "ES1688", (void *) chip)) {
+
+ err = request_irq(irq, snd_es1688_interrupt, 0, "ES1688", (void *) chip);
+ if (err < 0) {
snd_printk(KERN_ERR "es1688: can't grab IRQ %d\n", irq);
- return -EBUSY;
+ goto exit_release_region;
}
+
chip->irq = irq;
- if (request_dma(dma8, "ES1688")) {
+ err = request_dma(dma8, "ES1688");
+
+ if (err < 0) {
snd_printk(KERN_ERR "es1688: can't grab DMA8 %d\n", dma8);
- return -EBUSY;
+ goto exit_release_irq;
}
chip->dma8 = dma8;
@@ -685,14 +692,23 @@ int snd_es1688_create(struct snd_card *card,
err = snd_es1688_probe(chip);
if (err < 0)
- return err;
+ goto exit_release_dma;
err = snd_es1688_init(chip, 1);
if (err < 0)
- return err;
+ goto exit_release_dma;
/* Register device */
return snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, );
+
+exit_release_dma:
+ free_dma(chip->dma8);
+exit_release_irq:
+ free_irq(chip->irq, chip);
+exit_release_region:
+ release_and_free_resource(chip->res_port);
+exit:
+ return err;
}
static struct snd_pcm_ops snd_es1688_playback_ops = {
Re: [PATCH] Documentation: fix DOCBOOKS=... building
On 07/28/2012 04:26 AM, Johannes Berg wrote: > On Fri, 2012-07-27 at 15:29 -0700, Randy Dunlap wrote: >> On 06/13/2012 01:43 AM, Johannes Berg wrote: >> >>> From: Johannes Berg >>> >>> Prior to >>> commit 4266129964b8238526936d723de65b419d8069c6 >>> Author: Mauro Carvalho Chehab >>> Date: Tue May 31 16:27:44 2011 -0300 >>> >>> [media] DocBook: Move all media docbook stuff into its own directory >>> >>> it was possible to build only a single (or more) >>> book(s) by calling, for example >>> make htmldocs DOCBOOKS=80211.xml >>> >>> This now fails: >>> cp: target `.../Documentation/DocBook//media_api' is not a directory >>> >>> Ignore errors from that copy to make this possible again. >>> >>> Cc: Mauro Carvalho Chehab >>> Signed-off-by: Johannes Berg >>> --- >>> I complained about this a long time ago, but now it finally bothered me >>> enough to fix it ... :-) >> >> >> Thanks. >> >> Acked-by: Randy Dunlap > > Can you apply it somewhere, or should I send it to Andrew, or do you > have any other ideas? I'm no longer the Documentation maintainer, but Rob Landley could merge it. You probably will need to resend it to him. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] floppy: remove duplicated flag FD_RAW_NEED_DISK
On Sat, 2012-07-28 at 19:45 +0800, Fengguang Wu wrote: > FD_RAW_NEED_DISK | FD_RAW_NEED_DISK That's a pretty old defect from kernel 1.1 days. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net:appletalk:ddp:fixed some codystyle issues in
On Sat, 2012-07-28 at 16:15 +0530, Jeffrin Jose wrote:
> Fixed coding style issues relating to indentation found in
> net/appletalkddp.c."git diff -w" is empty and the compiled objects
> are the same too.
Hello Jeffrin.
Your commit message is OK but your patch not.
The switch/case that could use modification is at
line 1790, not at line 685.
> diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
[]
> @@ -337,7 +337,7 @@ static int atif_proxy_probe_device(struct atalk_iface
> *atif,
>
> return -EADDRINUSE; /* Network is full... */
> }
> -
> +
Adding whitespace
> struct atalk_addr *atalk_find_dev_addr(struct net_device *dev)
> {
> @@ -685,26 +685,26 @@ static int atif_ioctl(int cmd, void __user *arg)
>
> switch (cmd) {
> case SIOCSIFADDR:
> - if (!capable(CAP_NET_ADMIN))
> + if (!capable(CAP_NET_ADMIN))
There's nothing wrong here to fix and you are
adding incorrect indentation.
Please try again and make sure you verify your
proposed patches by using scripts/checkpatch.pl
before submitting them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/13] driver core: firmware loader: fix device lifetime
On Fri, Jul 27, 2012 at 6:32 PM, Borislav Petkov wrote: > > I still don't like too much the "not possible to sleep for long time" > expression. > > Maybe change it to "should sleep for as small periods as possible since > it increases boot time of device drivers requesting firmware in their > ->probe() methods." Fairly enough, will add this kind of description in -v1, and I will introduce one extra patch to fix this comment since it is nothing related with the device lifetime fix and its comments. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc/smp: Do not disable IPI interrupts during suspend
On Jul 27, 2012, at 5:20 PM, Benjamin Herrenschmidt wrote: > On Fri, 2012-07-27 at 16:58 -0500, Kumar Gala wrote: >> On Jul 20, 2012, at 7:47 AM, Zhao Chenhui wrote: >> >>> During suspend, all interrupts including IPI will be disabled. In this case, >>> the suspend process will hang in SMP. To prevent this, pass the flag >>> IRQF_NO_SUSPEND when requesting IPI irq. >>> >>> Signed-off-by: Zhao Chenhui >>> Signed-off-by: Li Yang >>> --- >>> arch/powerpc/kernel/smp.c |2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> BenH, >> >> Can you ack? > > No I'll merge it but not until it's been in next for a bit unless you > have some strong emergency there, it's on my mental list of things to > shovel into next after rc1. I wasn't clear, I was meaning for my 'next' tree, not 3.6. Trying to get these FSL PM patches into my 'next' for 3.7. - k > Curiosity: didn't we use to disable all non-boot CPUs on suspend ? > > Cheers, > Ben. > >> - k >> >>> >>> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c >>> index fecb038..d26bbf8 100644 >>> --- a/arch/powerpc/kernel/smp.c >>> +++ b/arch/powerpc/kernel/smp.c >>> @@ -171,7 +171,7 @@ int smp_request_message_ipi(int virq, int msg) >>> } >>> #endif >>> err = request_irq(virq, smp_ipi_action[msg], >>> - IRQF_PERCPU | IRQF_NO_THREAD, >>> + IRQF_PERCPU | IRQF_NO_THREAD | IRQF_NO_SUSPEND, >>> smp_ipi_name[msg], 0); >>> WARN(err < 0, "unable to request_irq %d for %s (rc %d)\n", >>> virq, smp_ipi_name[msg], err); >>> -- >>> 1.6.4.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: [RFC PATCH 12/13] driver core: firmware loader: use small timeout for cache device firmware
On Fri, Jul 27, 2012 at 6:35 PM, Borislav Petkov wrote: > On Fri, Jul 27, 2012 at 09:54:25AM +0800, Ming Lei wrote: >> On Fri, Jul 27, 2012 at 1:54 AM, Borislav Petkov wrote: >> >> >> No, it is not what I was saying. >> >> I just mean the point is not mentioned in my commit log, but I admit it >> should >> be a appropriate cause. >> >> > >> > Ok, maybe I'm not understanding this then. So explain to me this: why >> > do you need that timeout value of 10, how did we decide it to be 10 >> >> If one firmware image was loaded successfully before, the probability of >> loading it successfully at this time should be much higher than the 1st time >> because something crazy(for example, the firmware is deleted) happens >> with low probability. > > Believe it or not, I'm addressing exactly the possibility of the > firmware disappearing from under us in the AMD microcode driver > currently :) (and some other annoyances, of course). Of course, it is possible since user can delete it anytime, but with very low probability. > >> Choosing 10 secs is just a estimation for loading time because the maximum >> size of firmware in current distributions is about 2M bytes, since we know >> it has been loaded successfully before. > > This is exactly the comment we want over the code to explain to others > why we're choosing 10 secs. Simply add that sentence above the 10s > assignment and we're perfect! :-) OK, will add the comments in -v1. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] slub: remove one code path and reduce lock contention in __slab_free()
2012/7/28 Christoph Lameter :
> On Sat, 28 Jul 2012, Joonsoo Kim wrote:
>
>> Subject and commit log are changed from v1.
>
> That looks a bit better. But the changelog could use more cleanup and
> clearer expression.
>
>> @@ -2490,25 +2492,17 @@ static void __slab_free(struct kmem_cache *s, struct
>> page *page,
>> return;
>> }
>>
>> + if (unlikely(!new.inuse && n->nr_partial > s->min_partial))
>> + goto slab_empty;
>> +
>
> So we can never encounter a empty slab that was frozen before? Really?
In my suggestion, 'was_frozen = 1' is "always" handled without taking a lock.
Then, never hit following code.
+ if (unlikely(!new.inuse && n->nr_partial > s->min_partial))
+ goto slab_empty;
+
Instead, hit following code.
if (likely(!n)) {
/*
* If we just froze the page then put it onto the
* per cpu partial list.
*/
if (new.frozen && !was_frozen) {
put_cpu_partial(s, page, 1);
stat(s, CPU_PARTIAL_FREE);
}
/*
* The list lock was not taken therefore no list
* activity can be necessary.
*/
if (was_frozen)
stat(s, FREE_FROZEN);
return;
}
So, even if we encounter a empty slab that was frozen before, we just
do "stat(s, FREE_FROZEN)".
Please let me know my answer is sufficient.
Thanks!!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops while disconnecting USB peripheral (always)
On 28.07.2012 15:25, Bjørn Mork wrote: > Daniel Mack writes: >> On 28.07.2012 14:27, Bjørn Mork wrote: >> >>> The reason is this change: >>> >>> 0998d0631 device-core: Ensure drvdata = NULL when no driver is bound >>> >>> >>> It will make bugs like this suddenly 100% reproducible. But the bugs >>> *are* in the drivers, and may have been there for a long time. The >>> drivers have been accessing drvdata after unbinding. They just didn't >>> crash prior to that commit. > > I just realized that I might have been concluding too quickly here, as > usual.. > > The crashes referred to in this thread were not NULL pointer > dereferences, which makes it less likely that this change is the > cause. Could of course still be related somehow, but not directly. > > >>> But the commit is correct, and a very much needed improvement if my >>> assumptions are correct. The drivers need fixing and this just makes it >>> evident. >> >> Hmm, interesting. Thanks for sharing this. I personally never saw this >> bug kicking in, but if I understand your findings correctly, we would >> need something like the following patch for snd-usb and the storage driver? >> >> Sarbojit, could you give this a test and see whether your kernel still >> crashes in any of the two drivers? >> >> >> Thanks, >> Daniel >> >> >> >> diff --git a/sound/usb/card.c b/sound/usb/card.c >> index d5b5c33..0e8caaa 100644 >> --- a/sound/usb/card.c >> +++ b/sound/usb/card.c >> @@ -555,7 +555,7 @@ static void snd_usb_audio_disconnect(struct >> usb_device *dev, >> struct snd_card *card; >> struct list_head *p; >> >> - if (chip == (void *)-1L) >> + if (chip == (void *)-1L || chip == NULL) >> return; > > I may be wrong, but I don't think you need this is disconnect. The > driver will not be unbound until after disconnect returns. I thought so too, yes. Still, as I don't fully understand the call trace that is involved across all the driver layers, I thought it might we worth a try if that fixes it. > But IMHO, the usage of (void *)-1L as invalid drvdata marker in that > driver should be replaced with NULL. suspend/resume may also be unsafe > for example. Could be, but Sarbojit reported crashes on disconnect, not on suspend. > I don't really think you need those changes for the same reasons I gave > above. > > Sorry if my comment just confused the search for this bug. bisecting it > is probably the easiest way to locate it after all. Yes, definitely. Thanks, anyway, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops while disconnecting USB peripheral (always)
Daniel Mack writes:
> On 28.07.2012 14:27, Bjørn Mork wrote:
>
>> The reason is this change:
>>
>> 0998d0631 device-core: Ensure drvdata = NULL when no driver is bound
>>
>>
>> It will make bugs like this suddenly 100% reproducible. But the bugs
>> *are* in the drivers, and may have been there for a long time. The
>> drivers have been accessing drvdata after unbinding. They just didn't
>> crash prior to that commit.
I just realized that I might have been concluding too quickly here, as
usual..
The crashes referred to in this thread were not NULL pointer
dereferences, which makes it less likely that this change is the
cause. Could of course still be related somehow, but not directly.
>> But the commit is correct, and a very much needed improvement if my
>> assumptions are correct. The drivers need fixing and this just makes it
>> evident.
>
> Hmm, interesting. Thanks for sharing this. I personally never saw this
> bug kicking in, but if I understand your findings correctly, we would
> need something like the following patch for snd-usb and the storage driver?
>
> Sarbojit, could you give this a test and see whether your kernel still
> crashes in any of the two drivers?
>
>
> Thanks,
> Daniel
>
>
>
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index d5b5c33..0e8caaa 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -555,7 +555,7 @@ static void snd_usb_audio_disconnect(struct
> usb_device *dev,
> struct snd_card *card;
> struct list_head *p;
>
> - if (chip == (void *)-1L)
> + if (chip == (void *)-1L || chip == NULL)
> return;
I may be wrong, but I don't think you need this is disconnect. The
driver will not be unbound until after disconnect returns.
But IMHO, the usage of (void *)-1L as invalid drvdata marker in that
driver should be replaced with NULL. suspend/resume may also be unsafe
for example.
> card = chip->card;
> @@ -610,6 +610,7 @@ static void usb_audio_disconnect(struct
> usb_interface *intf)
> {
> snd_usb_audio_disconnect(interface_to_usbdev(intf),
> usb_get_intfdata(intf));
> + usb_set_intfdata(intf, NULL);
This can't harm, but is not necessary given that it now will be taken
care of by the driver core.
> }
>
> #ifdef CONFIG_PM
> diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
> index d012fe4..36862ee 100644
> --- a/drivers/usb/storage/usb.c
> +++ b/drivers/usb/storage/usb.c
> @@ -1025,9 +1025,14 @@ void usb_stor_disconnect(struct usb_interface *intf)
> {
> struct us_data *us = usb_get_intfdata(intf);
>
> + if (!us)
> + return;
> +
> US_DEBUGP("storage_disconnect() called\n");
> quiesce_and_remove_host(us);
> release_everything(us);
> +
> + usb_set_intfdata(intf, NULL);
> }
> EXPORT_SYMBOL_GPL(usb_stor_disconnect);
I don't really think you need those changes for the same reasons I gave
above.
Sorry if my comment just confused the search for this bug. bisecting it
is probably the easiest way to locate it after all.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sh: pfc: Fix build issues in pinctrl.c
On Saturday, July 28, 2012, Paul Mundt wrote: > On Sat, Jul 28, 2012 at 12:07:04AM +0200, Rafael J. Wysocki wrote: > > > > First off, drivers/sh/pfc/pinctrl.c doesn't build after commit > > 5d589b0 (pinctrl: remove pinctrl_remove_gpio_range), because > > sh_pfc_pinctrl_remove() uses the function that has been removed by > > that commit. Fix this by removing the pinctrl_remove_gpio_range() > > call, which is not necessary any more, from sh_pfc_pinctrl_remove(). > > > > Second, the compiler complains correctly that there's an unused > > local variable in sh_pfc_pinconf_set(). Fix this by removing the > > definition of that variable. > > > > Signed-off-by: Rafael J. Wysocki > > Already fixed in my tree, as pointed out when Iwamatsu-san sent the same > patch. I must have overlooked that one. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops while disconnecting USB peripheral (always)
On 28.07.2012 14:27, Bjørn Mork wrote:
> Daniel Mack writes:
>> On 23.07.2012 16:47, Alan Stern wrote:
>>> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote:
That is why I provided two stacks,
1st one is when I tried to remove the USB hub (which connects a webcam
+ microphone)
2nd one is when I tried to remove an USB powered external HDD.
Just to make sure whether the problem is with USB sound or the USB
subsystem.
>>>
>>> Do you stop all the programs that are using the USB devices before
>>> unplugging the hub? Do you unmount the USB HDD first?
>>>
>>> The first crash shows a problem in the snd-usb-audio driver.
>>>
>>> The second crash shows a problem in the VFS layer or in ext3, not in
>>> the USB stack.
>>
>> I dare to doubt there are two severe bugs of that kind that are 100%
>> reproducible. I haven't had a hotplug crash in any of the two drivers
>> for a long time, and I use both of them extensively.
>
> Actually, based on the recent usb_wwan experience, I'd say that two such
> bugs isn't as unlikely as it may seem at first. Even three if we add
> the now fixed usb_wwan (or six, if we count the three drivers affected
> by the usb_wwan bug). There are probably even more.
>
> The reason is this change:
>
> 0998d0631 device-core: Ensure drvdata = NULL when no driver is bound
>
>
> It will make bugs like this suddenly 100% reproducible. But the bugs
> *are* in the drivers, and may have been there for a long time. The
> drivers have been accessing drvdata after unbinding. They just didn't
> crash prior to that commit.
>
> But the commit is correct, and a very much needed improvement if my
> assumptions are correct. The drivers need fixing and this just makes it
> evident.
Hmm, interesting. Thanks for sharing this. I personally never saw this
bug kicking in, but if I understand your findings correctly, we would
need something like the following patch for snd-usb and the storage driver?
Sarbojit, could you give this a test and see whether your kernel still
crashes in any of the two drivers?
Thanks,
Daniel
diff --git a/sound/usb/card.c b/sound/usb/card.c
index d5b5c33..0e8caaa 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -555,7 +555,7 @@ static void snd_usb_audio_disconnect(struct
usb_device *dev,
struct snd_card *card;
struct list_head *p;
- if (chip == (void *)-1L)
+ if (chip == (void *)-1L || chip == NULL)
return;
card = chip->card;
@@ -610,6 +610,7 @@ static void usb_audio_disconnect(struct
usb_interface *intf)
{
snd_usb_audio_disconnect(interface_to_usbdev(intf),
usb_get_intfdata(intf));
+ usb_set_intfdata(intf, NULL);
}
#ifdef CONFIG_PM
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index d012fe4..36862ee 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -1025,9 +1025,14 @@ void usb_stor_disconnect(struct usb_interface *intf)
{
struct us_data *us = usb_get_intfdata(intf);
+ if (!us)
+ return;
+
US_DEBUGP("storage_disconnect() called\n");
quiesce_and_remove_host(us);
release_everything(us);
+
+ usb_set_intfdata(intf, NULL);
}
EXPORT_SYMBOL_GPL(usb_stor_disconnect);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pch_uart: check kzalloc result in dma_handle_tx()
Reported by coccinelle:
drivers/tty/serial/pch_uart.c:979:1-14: alloc with no test, possible model on
line 994
Signed-off-by: Fengguang Wu
---
drivers/tty/serial/pch_uart.c |4
1 file changed, 4 insertions(+)
WARNING: this may be a superficial fix!
--- linux.orig/drivers/tty/serial/pch_uart.c2012-06-07 05:39:57.550846385
+0800
+++ linux/drivers/tty/serial/pch_uart.c 2012-07-28 20:37:27.803145392 +0800
@@ -974,6 +974,10 @@ static unsigned int dma_handle_tx(struct
priv->tx_dma_use = 1;
priv->sg_tx_p = kzalloc(sizeof(struct scatterlist)*num, GFP_ATOMIC);
+ if (!priv->sg_tx_p) {
+ dev_err(priv->port.dev, "%s:kzalloc Failed\n", __func__);
+ return 0;
+ }
sg_init_table(priv->sg_tx_p, num); /* Initialize SG table */
sg = priv->sg_tx_p;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
drivers/mfd/tps65090.c: duplicated TPS65090_INT_STS tests
Hi Venu,
Is this coccinelle warning a trivial one, or indicates some copy
error? It's introduced by commit 3c33be06 ("mfd: Add support for
TPS65090").
drivers/mfd/tps65090.c:239:5-30: duplicated argument to && or ||
vim +239 drivers/mfd/tps65090.c
236
237 static bool is_volatile_reg(struct device *dev, unsigned int reg)
238 {
> 239 if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS))
240 return true;
241 else
242 return false;
---
0-DAY kernel build testing backend Open Source Technology Centre
Fengguang Wu Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops while disconnecting USB peripheral (always)
Daniel Mack writes: > On 23.07.2012 16:47, Alan Stern wrote: >> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote: >>> That is why I provided two stacks, >>> >>> 1st one is when I tried to remove the USB hub (which connects a webcam >>> + microphone) >>> 2nd one is when I tried to remove an USB powered external HDD. >>> >>> Just to make sure whether the problem is with USB sound or the USB >>> subsystem. >> >> Do you stop all the programs that are using the USB devices before >> unplugging the hub? Do you unmount the USB HDD first? >> >> The first crash shows a problem in the snd-usb-audio driver. >> >> The second crash shows a problem in the VFS layer or in ext3, not in >> the USB stack. > > I dare to doubt there are two severe bugs of that kind that are 100% > reproducible. I haven't had a hotplug crash in any of the two drivers > for a long time, and I use both of them extensively. Actually, based on the recent usb_wwan experience, I'd say that two such bugs isn't as unlikely as it may seem at first. Even three if we add the now fixed usb_wwan (or six, if we count the three drivers affected by the usb_wwan bug). There are probably even more. The reason is this change: 0998d0631 device-core: Ensure drvdata = NULL when no driver is bound It will make bugs like this suddenly 100% reproducible. But the bugs *are* in the drivers, and may have been there for a long time. The drivers have been accessing drvdata after unbinding. They just didn't crash prior to that commit. But the commit is correct, and a very much needed improvement if my assumptions are correct. The drivers need fixing and this just makes it evident. > I rather assume there's something else failing, probably some host > controller issue that corrupts mempory? Can anyone else reproduce this > maybe? You could of course do like me and bisect, but if you end up with commit 0998d0631 then you haven't really learned more than confirming my guess. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] floppy: remove duplicated flag FD_RAW_NEED_DISK
Fix coccinelle warning (without behavior change):
drivers/block/floppy.c:2518:32-48: duplicated argument to & or |
Signed-off-by: Fengguang Wu
---
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 553f43a..0fcbe14 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -2516,8 +2516,7 @@ static int make_raw_rw_request(void)
set_fdc((long)current_req->rq_disk->private_data);
raw_cmd = _raw_cmd;
- raw_cmd->flags = FD_RAW_SPIN | FD_RAW_NEED_DISK | FD_RAW_NEED_DISK |
- FD_RAW_NEED_SEEK;
+ raw_cmd->flags = FD_RAW_SPIN | FD_RAW_NEED_DISK | FD_RAW_NEED_SEEK;
raw_cmd->cmd_count = NR_RW;
if (rq_data_dir(current_req) == READ) {
raw_cmd->flags |= FD_RAW_READ;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/3] ACPI based system device hotplug framework
From: Jiang Liu The patchset is based on v3.5-rc6 and you may pull them from: git://github.com/jiangliu/linux.git acpihp Modern high-end server may support advanced hotplug features for system devices, including physical processor, memory board, IO extension board and/or computer node. The ACPI specifications have provided standard interfaces between firmware and OS to support device hotplug at runtime. This patch series provide an ACPI based hotplug framework to support system device hotplug at runtime, which will replace current existing ACPI device driver based CPU/memory/CONTAINER hotplug mechanism. The new ACPI based hotplug framework is modelled after PCI hotplug architecture and target to achieve following goals: 1) Provide a mechanism to detect hotplug slots by checking ACPI _EJ0 method, ACPI PRCT (platform RAS capabilities table) and other platform specific mechanisms. 2) Unify the way to enumerate ACPI based hotplug slots. All hotplug slots will be enumerated by the enumeration driver, instead of by ACPI device drivers. 3) Dynamically create/destroy ACPI hotplug slots. For example, new ACPI hotplug slots may be created when hot-adding a computer node if the node contains some memory hotplug slots. 4) Unify the way to handle ACPI hotplug events. All ACPI hotplug events for system devices will be handled by a generic ACPI hotplug driver, instead of handled by ACPI device drivers. 5) Solve dependencies among hotplug slots. You need first to remove the memory device before removing a physical processor if a hotpluggable memory device is connected to a hotpluggable physical processor. 6) Provide better error handling and recover. 7) Provide interface to cancel ongoing hotplug operations. It may take a very long time to remove a memory device, so provide interface to cancel the operation. 8) Support new RAS features, such as socket/memory migration. 9) Provide better user interfaces to the hotplug functionalities. The new hotplug framework includes four logical components. The first is an ACPI hotplug slot enumerator, which enumerates ACPI hotplug slots on load and provides callbacks to manage those hotplug slots. An ACPI hotplug slot is an abstraction of receptacles, where a group of system devices could be connected to. The second is a device class for ACPI hotplug slots, named acpihp_slot_class. All ACPI hotplug slot devices will be associated with acpihp_slot_class. The third is a platform independent class driver for ACPI hotplug slots, which registers itself onto acpihp_slot_class and manages all ACPI hotplug slots in system. This hotplug driver handles ACPI hotplug events, processes user requests and manages slot state machine accoring to user requests. The fourth is a series of ACPI device drivers, for CPU, memory, PCI host bridge, IOAPIC and ACPI CONTAINER. These ACPI device drivers provide device specific callbacks for the hotplug driver to add/remove system devices at runtime. This patch set implements the first and second parts, which enumerates hotplug slots and creates sysfs entries for each slot as below. linux-drf:/sys/devices/LNXSYSTM:00/acpihp # ll drwxr-xr-x 4 root root 0 Jul 28 16:00 NODE00 drwxr-xr-x 3 root root 0 Jul 28 16:00 NODE01 drwxr-xr-x 3 root root 0 Jul 28 16:00 NODE02 linux-drf:/sys/devices/LNXSYSTM:00/acpihp/NODE00 # ll drwxr-xr-x 3 root root 0 Jul 28 16:00 IOX01 -r--r--r-- 1 root root 65536 Jul 28 16:01 capabilities lrwxrwxrwx 1 root root 0 Jul 28 16:00 device -> ../../../LNXSYSTM:00 -r--r--r-- 1 root root 65536 Jul 28 16:01 object drwxr-xr-x 2 root root 0 Jul 28 16:01 power -r--r--r-- 1 root root 65536 Jul 28 16:01 state -r--r--r-- 1 root root 65536 Jul 28 16:01 status lrwxrwxrwx 1 root root 0 Jul 28 16:00 subsystem -> ../../../../class/acpihp -r--r--r-- 1 root root 65536 Jul 28 16:01 type -rw-r--r-- 1 root root 65536 Jul 28 16:01 uevent linux-drf:/sys/bus/acpi/acpihp # ls NODE00 NODE00.IOX01 NODE01 NODE02 linux-drf:/sys/bus/acpi/acpihp # ll lrwxrwxrwx 1 root root 0 Jul 28 16:03 NODE00 -> ../../../devices/LNXSYSTM:00/acpihp/NODE00 lrwxrwxrwx 1 root root 0 Jul 28 16:03 NODE00.IOX01 -> ../../../devices/LNXSYSTM:00/acpihp/NODE00/IOX01 lrwxrwxrwx 1 root root 0 Jul 28 16:03 NODE01 -> ../../../devices/LNXSYSTM:00/acpihp/NODE01 lrwxrwxrwx 1 root root 0 Jul 28 16:03 NODE02 -> ../../../devices/LNXSYSTM:00/acpihp/NODE02 Jiang Liu (3): ACPIHP: introduce a framework for ACPI based system device hotplug ACPIHP: ACPI system device hotplug slot enumerator ACPIHP: detect ACPI hotplug slots by checking ACPI _EJ0 method drivers/acpi/Kconfig | 33 ++ drivers/acpi/Makefile|2 + drivers/acpi/hotplug/Makefile| 10 + drivers/acpi/hotplug/core.c | 590 ++ drivers/acpi/hotplug/slot_enum.c | 469 +++ drivers/acpi/hotplug/slot_enum_ej0.c | 113 +++
Re: [PATCH] Documentation: fix DOCBOOKS=... building
On Fri, 2012-07-27 at 15:29 -0700, Randy Dunlap wrote: > On 06/13/2012 01:43 AM, Johannes Berg wrote: > > > From: Johannes Berg > > > > Prior to > > commit 4266129964b8238526936d723de65b419d8069c6 > > Author: Mauro Carvalho Chehab > > Date: Tue May 31 16:27:44 2011 -0300 > > > > [media] DocBook: Move all media docbook stuff into its own directory > > > > it was possible to build only a single (or more) > > book(s) by calling, for example > > make htmldocs DOCBOOKS=80211.xml > > > > This now fails: > > cp: target `.../Documentation/DocBook//media_api' is not a directory > > > > Ignore errors from that copy to make this possible again. > > > > Cc: Mauro Carvalho Chehab > > Signed-off-by: Johannes Berg > > --- > > I complained about this a long time ago, but now it finally bothered me > > enough to fix it ... :-) > > > Thanks. > > Acked-by: Randy Dunlap Can you apply it somewhere, or should I send it to Andrew, or do you have any other ideas? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ixp4xx: Declare MODULE_FIRMWARE usage
Tim Gardner writes:
> +++ b/arch/arm/mach-ixp4xx/ixp4xx_npe.c
> @@ -116,7 +116,11 @@
> /* NPE mailbox_status value for reset */
> #define RESET_MBOX_STAT 0xF0F0
>
> -const char *npe_names[] = { "NPE-A", "NPE-B", "NPE-C" };
> +#define NPE_A_FIRMWARE "NPE-A"
> +#define NPE_B_FIRMWARE "NPE-B"
> +#define NPE_C_FIRMWARE "NPE-C"
> +
> +const char *npe_names[] = { NPE_A_FIRMWARE, NPE_B_FIRMWARE, NPE_C_FIRMWARE };
>
> #define print_npe(pri, npe, fmt, ...)
> \
> printk(pri "%s: " fmt, npe_name(npe), ## __VA_ARGS__)
> @@ -724,6 +728,9 @@ module_exit(npe_cleanup_module);
>
> MODULE_AUTHOR("Krzysztof Halasa");
> MODULE_LICENSE("GPL v2");
> +MODULE_FIRMWARE(NPE_A_FIRMWARE);
> +MODULE_FIRMWARE(NPE_B_FIRMWARE);
> +MODULE_FIRMWARE(NPE_C_FIRMWARE);
>
> EXPORT_SYMBOL(npe_names);
> EXPORT_SYMBOL(npe_running);
This looks like a good idea, thanks.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops while disconnecting USB peripheral (always)
On 23.07.2012 17:04, Sarbojit Ganguly wrote: > On 23 July 2012 20:17, Alan Stern wrote: >> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote: >> >>> Hello Daniel, >>> >>> That is why I provided two stacks, >>> >>> 1st one is when I tried to remove the USB hub (which connects a webcam >>> + microphone) >>> 2nd one is when I tried to remove an USB powered external HDD. >>> >>> Just to make sure whether the problem is with USB sound or the USB >>> subsystem. >> >> Do you stop all the programs that are using the USB devices before >> unplugging the hub? Do you unmount the USB HDD first? > > Yes Alan, I did unmount the HDD > >> >> The first crash shows a problem in the snd-usb-audio driver. >> >> The second crash shows a problem in the VFS layer or in ext3, not in >> the USB stack. > > Yes the issue is in evict() api which gets called when USB disconnect > is triggered. >> >> Alan Stern >> > > Even I was confused in the beginning but after thorough check I > confirmed its presence. I reverted back to my distro's stock kernel > (3.2.0-26-generic) where the issue does not recur. > > I could not analysed further (due to my limited knowledge of USB). > Did you succeed in bisecting this problem down? From what I can tell, there hasn't been any similar report on LKML yet. That makes traking the problem on your machine even more important as you can reproduce it reliably. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] netconsole.txt: "nc" needs "-p" to specify the listening port
Borislav Petkov writes: > On Fri, Jul 27, 2012 at 11:24:53AM +0200, Dirk Gouders wrote: >> Cong Wang writes: >> >> > On Fri, Jul 27, 2012 at 2:35 PM, Dirk Gouders >> > wrote: >> >> Hi Jesse, >> >> >> >> I would like to ask you to check if the documentation of "nc" in >> >> netconsole.txt is still correct. I tried two different netcat packages >> >> and both require "-p" to specify the listening port. I am wondering if >> >> that changed after the use of "nc" has been documented. >> > >> > On Fedora 16, `nc -u -l ` works fine. >> >> Thanks for checking that. >> >> If the information I found is correct, Fedora uses OpenBSD's nc >> codebase. The two netcat packages I tested on a Gentoo system differ in >> requiring the -p switch for the port specification. > > So say exactly that in the doc: that the *BSD's version of nc doesn't > need the port number specified with '-p' and you're covered. OK, I tried that in the attached patch. I'm not sure if every exeption needs to/should be documented, though. Dirk >From 3cdeac3e814471053129145c5fa8391acb365fd8 Mon Sep 17 00:00:00 2001 From: Dirk Gouders Date: Sat, 28 Jul 2012 12:32:49 +0200 Subject: [PATCH] netconsole.txt: non-BSD versions of nc(1) require '-p' switch Gentoo for example uses non-BSD versions of nc(1) which require the '-p' switch to specify the listening port. --- Documentation/networking/netconsole.txt |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt index 8d02207..9a362f8 100644 --- a/Documentation/networking/netconsole.txt +++ b/Documentation/networking/netconsole.txt @@ -52,7 +52,8 @@ initialized and attempts to bring up the supplied dev at the supplied address. The remote host can run either 'netcat -u -l -p ', -'nc -l -u ' or syslogd. +'nc -l -u ' (BSD version of nc(1) e.g. Fedora), +'nc -l -u -p ' or syslogd. Dynamic reconfiguration: -- 1.7.8.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs/jfs: TRIM support for JFS Filesystem
* Tino Reichardt wrote:
> This patch adds support for the two linux interfaces of the discard/TRIM
> command for SSD devices and sparse/thinly-provisioned LUNs.
Fixed a problem when setting minlen in jfs_ioc_trim().
Signed-off-by: Tino Reichardt
--
regards, TR
diff -X exclude -urpN linux-git/Documentation/filesystems/jfs.txt
linux_jfs-trim/Documentation/filesystems/jfs.txt
--- linux-git/Documentation/filesystems/jfs.txt 2011-03-01 10:22:59.0
+0100
+++ linux_jfs-trim/Documentation/filesystems/jfs.txt2012-07-26
22:52:33.244721671 +0200
@@ -3,6 +3,7 @@ IBM's Journaled File System (JFS) for Li
JFS Homepage: http://jfs.sourceforge.net/
The following mount options are supported:
+(*) == default
iocharset=name Character set to use for converting from Unicode to
ASCII. The default is to do no conversion. Use
@@ -21,12 +22,12 @@ nointegrity Do not write to the journal.
from backup media. The integrity of the volume is not
guaranteed if the system abnormally abends.
-integrity Default. Commit metadata changes to the journal. Use this
+integrity(*) Default. Commit metadata changes to the journal. Use this
option to remount a volume where the nointegrity option was
previously specified in order to restore normal behavior.
errors=continueKeep going on a filesystem error.
-errors=remount-ro Default. Remount the filesystem read-only on an error.
+errors=remount-ro(*) Default. Remount the filesystem read-only on an error.
errors=panic Panic and halt the machine if an error occurs.
uid=value Override on-disk uid with specified value
@@ -35,6 +36,18 @@ umask=value Override on-disk umask with
directories, the execute bit will be set if the corresponding
read bit is set.
+discard=minlen This enables/disables the use of discard/TRIM commands.
+discardThe discard/TRIM commands are sent to the underlying
+nodiscard(*) block device when blocks are freed. This is useful for SSD
+ devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl
+ command is also available together with the nodiscard option.
+ The value of minlen specifies the minimum blockcount, when
+ a TRIM command to the block device is considered usefull.
+ When no value is given to the discard option, it defaults to
+ 64 blocks, which means 256KiB in JFS.
+ The minlen value of discard overrides the minlen value given
+ on an FITRIM ioctl().
+
Please send bugs, comments, cards and letters to sha...@linux.vnet.ibm.com.
The JFS mailing list can be subscribed to by using the link labeled
diff -X exclude -urpN linux-git/fs/jfs/Makefile linux_jfs-trim/fs/jfs/Makefile
--- linux-git/fs/jfs/Makefile 2011-08-17 07:31:10.0 +0200
+++ linux_jfs-trim/fs/jfs/Makefile 2012-07-26 22:53:48.640979880 +0200
@@ -6,7 +6,7 @@ obj-$(CONFIG_JFS_FS) += jfs.o
jfs-y:= super.o file.o inode.o namei.o jfs_mount.o jfs_umount.o \
jfs_xtree.o jfs_imap.o jfs_debug.o jfs_dmap.o \
- jfs_unicode.o jfs_dtree.o jfs_inode.o \
+ jfs_unicode.o jfs_dtree.o jfs_inode.o jfs_discard.o \
jfs_extent.o symlink.o jfs_metapage.o \
jfs_logmgr.o jfs_txnmgr.o jfs_uniupr.o \
resize.o xattr.o ioctl.o
diff -X exclude -urpN linux-git/fs/jfs/ioctl.c linux_jfs-trim/fs/jfs/ioctl.c
--- linux-git/fs/jfs/ioctl.c2012-01-10 19:31:59.0 +0100
+++ linux_jfs-trim/fs/jfs/ioctl.c 2012-07-26 22:53:48.640979880 +0200
@@ -11,13 +11,17 @@
#include
#include
#include
+#include
#include
#include
+#include "jfs_filsys.h"
+#include "jfs_debug.h"
#include "jfs_incore.h"
#include "jfs_dinode.h"
#include "jfs_inode.h"
-
+#include "jfs_dmap.h"
+#include "jfs_discard.h"
static struct {
long jfs_flag;
@@ -123,6 +127,40 @@ setflags_out:
mnt_drop_write_file(filp);
return err;
}
+
+ case FITRIM:
+ {
+ struct super_block *sb = inode->i_sb;
+ struct request_queue *q = bdev_get_queue(sb->s_bdev);
+ struct fstrim_range range;
+ s64 ret = 0;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ if (!blk_queue_discard(q)) {
+ jfs_warn("FITRIM not supported on device");
+ return -EOPNOTSUPP;
+ }
+
+ if (copy_from_user(, (struct fstrim_range __user *)arg,
+ sizeof(range)))
+ return -EFAULT;
+
+ range.minlen = max((unsigned int)range.minlen,
+ q->limits.discard_granularity);
+
+ ret = jfs_ioc_trim(inode, );
+ if (ret < 0)
+ return
[PATCH] net:appletalk:ddp:fixed some codystyle issues in
Fixed coding style issues relating to indentation found in
net/appletalkddp.c."git diff -w" is empty and the compiled objects
are the same too.
Signed-off-by: Jeffrin Jose
---
net/appletalk/ddp.c | 212 +--
1 file changed, 106 insertions(+), 106 deletions(-)
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index c8bbcd2..19b7058 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -337,7 +337,7 @@ static int atif_proxy_probe_device(struct atalk_iface *atif,
return -EADDRINUSE; /* Network is full... */
}
-
+
struct atalk_addr *atalk_find_dev_addr(struct net_device *dev)
{
@@ -685,26 +685,26 @@ static int atif_ioctl(int cmd, void __user *arg)
switch (cmd) {
case SIOCSIFADDR:
- if (!capable(CAP_NET_ADMIN))
+ if (!capable(CAP_NET_ADMIN))
return -EPERM;
- if (sa->sat_family != AF_APPLETALK)
+ if (sa->sat_family != AF_APPLETALK)
return -EINVAL;
- if (dev->type != ARPHRD_ETHER &&
- dev->type != ARPHRD_LOOPBACK &&
- dev->type != ARPHRD_LOCALTLK &&
- dev->type != ARPHRD_PPP)
+ if (dev->type != ARPHRD_ETHER &&
+ dev->type != ARPHRD_LOOPBACK &&
+ dev->type != ARPHRD_LOCALTLK &&
+ dev->type != ARPHRD_PPP)
return -EPROTONOSUPPORT;
- nr = (struct atalk_netrange *)>sat_zero[0];
- add_route = 1;
+ nr = (struct atalk_netrange *)>sat_zero[0];
+ add_route = 1;
- /*
-* if this is a point-to-point iface, and we already
-* have an iface for this AppleTalk address, then we
-* should not add a route
-*/
- if ((dev->flags & IFF_POINTOPOINT) &&
- atalk_find_interface(sa->sat_addr.s_net,
+ /*
+* if this is a point-to-point iface, and we already
+* have an iface for this AppleTalk address, then we
+* should not add a route
+*/
+ if ((dev->flags & IFF_POINTOPOINT) &&
+ atalk_find_interface(sa->sat_addr.s_net,
sa->sat_addr.s_node)) {
printk(KERN_DEBUG "AppleTalk: point-to-point "
"interface added with "
@@ -712,16 +712,16 @@ static int atif_ioctl(int cmd, void __user *arg)
add_route = 0;
}
- /*
-* Phase 1 is fine on LocalTalk but we don't do
-* EtherTalk phase 1. Anyone wanting to add it go ahead.
-*/
- if (dev->type == ARPHRD_ETHER && nr->nr_phase != 2)
+ /*
+* Phase 1 is fine on LocalTalk but we don't do
+* EtherTalk phase 1. Anyone wanting to add it go ahead.
+*/
+ if (dev->type == ARPHRD_ETHER && nr->nr_phase != 2)
return -EPROTONOSUPPORT;
- if (sa->sat_addr.s_node == ATADDR_BCAST ||
- sa->sat_addr.s_node == 254)
+ if (sa->sat_addr.s_node == ATADDR_BCAST ||
+sa->sat_addr.s_node == 254)
return -EINVAL;
- if (atif) {
+ if (atif) {
/* Already setting address */
if (atif->status & ATIF_PROBE)
return -EBUSY;
@@ -734,36 +734,36 @@ static int atif_ioctl(int cmd, void __user *arg)
if (!atif)
return -ENOMEM;
}
- atif->nets = *nr;
+ atif->nets = *nr;
- /*
-* Check if the chosen address is used. If so we
-* error and atalkd will try another.
-*/
+ /*
+* Check if the chosen address is used. If so we
+* error and atalkd will try another.
+*/
- if (!(dev->flags & IFF_LOOPBACK) &&
- !(dev->flags & IFF_POINTOPOINT) &&
- atif_probe_device(atif) < 0) {
- atif_drop_device(dev);
+ if (!(dev->flags & IFF_LOOPBACK) &&
+ !(dev->flags & IFF_POINTOPOINT) &&
+atif_probe_device(atif) < 0) {
+ atif_drop_device(dev);
return -EADDRINUSE;
}
- /* Hey it worked - add
[Bisected] commit 71574865 (vfs: do_last(): common slow lookup) breaks CUPS printing
Printing with CUPS is broken on the current git tree. Whenever I print a page the job just sits in the CUPS queue showing "processing". But it never reaches the printer. (My CUPS version is 1.5.2. Filesystem is xfs.) I've bisected this issue to: commit 7157486541bffc0dfec912e21ae639b029dae3d3 Author: Miklos Szeredi Date: Tue Jun 5 15:10:14 2012 +0200 vfs: do_last(): common slow lookup Make the slow lookup part of O_CREAT and non-O_CREAT opens common. This allows atomic_open to be hooked into the slow lookup part. Signed-off-by: Miklos Szeredi Signed-off-by: Al Viro ` -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 39/40] cpuset: mm: reduce large amounts of memory barrier related damage v3
On Sat, Jul 28, 2012 at 02:02:31AM -0300, Herton Ronaldo Krzesinski wrote:
> > Thanks, I've merged this with the "original" in the tree, so all should
> > be good now.
>
> Thanks. I saw what seems another issue now on the patch too, sorry for
> not noticing earlier: this backport is lacking the
> write_seqcount_{begin,end} on set_mems_allowed for the case with
> CONFIG_CPUSETS, like in the original patch:
>
Not my finest moment :(
Thanks
---8<---
cpuset: mm: reduce large amounts of memory barrier related damage v3 fix
Missing hunk from backport.
Reported-by: Herton Ronaldo Krzesinski
Signed-off-by: Mel Gorman
diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index 8f15695..7a7e5fd 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -113,7 +113,9 @@ static inline bool put_mems_allowed(unsigned int seq)
static inline void set_mems_allowed(nodemask_t nodemask)
{
task_lock(current);
+ write_seqcount_begin(>mems_allowed_seq);
current->mems_allowed = nodemask;
+ write_seqcount_end(>mems_allowed_seq);
task_unlock(current);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MIPS: fix tc_id calculation
Any advice 2012/7/2 : > From: RongQing.Li > > Now the tc_id is: > (read_c0_tcbind() >> TCBIND_CURTC_SHIFT) & TCBIND_CURTC; > After substitute macro: > (read_c0_tcbind() >> 21) & ((0xff) << 21) > It should be: > (read_c0_tcbind() & ((0xff)<< 21)) >>21 > > Signed-off-by: RongQing.Li > --- > arch/mips/kernel/smp-cmp.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/mips/kernel/smp-cmp.c b/arch/mips/kernel/smp-cmp.c > index e7e03ec..afc379c 100644 > --- a/arch/mips/kernel/smp-cmp.c > +++ b/arch/mips/kernel/smp-cmp.c > @@ -102,7 +102,7 @@ static void cmp_init_secondary(void) > c->vpe_id = (read_c0_tcbind() >> TCBIND_CURVPE_SHIFT) & TCBIND_CURVPE; > #endif > #ifdef CONFIG_MIPS_MT_SMTC > - c->tc_id = (read_c0_tcbind() >> TCBIND_CURTC_SHIFT) & TCBIND_CURTC; > + c->tc_id = (read_c0_tcbind() & TCBIND_CURTC) >> TCBIND_CURTC_SHIFT; > #endif > } > > -- > 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: [RFC ebeam PATCH 3/3] input: misc: New USB eBeam input driver.
Hi Dmitry, >> +config INPUT_EBEAM_USB_CLASSIC >> +bool "eBeam Classic Projection support" >> +depends on INPUT_EBEAM_USB >> +default y > > Will there be support for other eBean devices (are there any)? If there > will how soon? How different are they? If not the we probably do not > need this INPUT_EBEAM_USB_CLASSIC selector. I know at least one re-branded same hardware by 3M, i will be able to borrow one in a month or so. According to the wikipedia article, there's probably more. There's also newer models and embeded ones in some video projector setup, also re-branded, based on the same technology and that might use the same type of protocol, but i can't be sure until someone can inspect them. These pieces of hardware are quite expensive, and mostly used in educational or corporate, they are not easy to grab. The code structure (device selector + functions indirection) also seems overkill to me for now, but permit to anticipate device's variations. If it appears that they all works in the same way, it'll be easy (and more comfortable to me) to step down, the opposite seems more difficult. >> +#define DEBUG > I do not think leaving DEBUG on is good idea for production code. Cinder, cleaned. >> +/* until KConfig */ >> +#define CONFIG_INPUT_EBEAM_USB_CLASSIC > > Huh? I test the module against my running kernel, building out of tree, and don't know how to define that in the makefile. This will be cleaned in final step. >> +bool irq_always; > > Does you device need this? Part of "overkill" foresight. >> +/* optional, model-specific */ >> +int (*alloc) (struct ebeam_device *ebeam); >> +int (*init)(struct ebeam_device *ebeam); >> +void (*exit)(struct ebeam_device *ebeam); > > Again, do you expect to see multitude of sufficiently different > devices or are they going to follow roughly the same protocol? ditto. -- Yann Cantin A4FEB47F -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ueagle-atm: Declare MODULE_FIRMWARE usage
Ack-by: matthieu castet
Le Wed, 25 Jul 2012 14:32:50 -0600,
Tim Gardner a écrit :
> Cc: Matthieu CASTET
> Cc: Stanislaw Gruszka
> Cc: Greg Kroah-Hartman
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Tim Gardner
> ---
> drivers/usb/atm/ueagle-atm.c | 79
> +++--- 1 file changed, 66
> insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/atm/ueagle-atm.c
> b/drivers/usb/atm/ueagle-atm.c index d7e422d..e1f8b2c 100644
> --- a/drivers/usb/atm/ueagle-atm.c
> +++ b/drivers/usb/atm/ueagle-atm.c
> @@ -307,6 +307,34 @@ enum {
> #define FW_GET_BYTE(p) (*((__u8 *) (p)))
>
> #define FW_DIR "ueagle-atm/"
> +#define EAGLE_FIRMWARE FW_DIR "eagle.fw"
> +#define ADI930_FIRMWARE FW_DIR "adi930.fw"
> +#define EAGLE_I_FIRMWARE FW_DIR "eagleI.fw"
> +#define EAGLE_II_FIRMWARE FW_DIR "eagleII.fw"
> +#define EAGLE_III_FIRMWARE FW_DIR "eagleIII.fw"
> +#define EAGLE_IV_FIRMWARE FW_DIR "eagleIV.fw"
> +
> +#define DSP4I_FIRMWARE FW_DIR "DSP4i.bin"
> +#define DSP4P_FIRMWARE FW_DIR "DSP4p.bin"
> +#define DSP9I_FIRMWARE FW_DIR "DSP9i.bin"
> +#define DSP9P_FIRMWARE FW_DIR "DSP9p.bin"
> +#define DSPEI_FIRMWARE FW_DIR "DSPei.bin"
> +#define DSPEP_FIRMWARE FW_DIR "DSPep.bin"
> +#define FPGA930_FIRMWARE FW_DIR "930-fpga.bin"
> +
> +#define CMV4P_FIRMWARE FW_DIR "CMV4p.bin"
> +#define CMV4PV2_FIRMWARE FW_DIR "CMV4p.bin.v2"
> +#define CMV4I_FIRMWARE FW_DIR "CMV4i.bin"
> +#define CMV4IV2_FIRMWARE FW_DIR "CMV4i.bin.v2"
> +#define CMV9P_FIRMWARE FW_DIR "CMV9p.bin"
> +#define CMV9PV2_FIRMWARE FW_DIR "CMV9p.bin.v2"
> +#define CMV9I_FIRMWARE FW_DIR "CMV9i.bin"
> +#define CMV9IV2_FIRMWARE FW_DIR "CMV9i.bin.v2"
> +#define CMVEP_FIRMWARE FW_DIR "CMVep.bin"
> +#define CMVEPV2_FIRMWARE FW_DIR "CMVep.bin.v2"
> +#define CMVEI_FIRMWARE FW_DIR "CMVei.bin"
> +#define CMVEIV2_FIRMWARE FW_DIR "CMVei.bin.v2"
> +
> #define UEA_FW_NAME_MAX 30
> #define NB_MODEM 4
>
> @@ -694,26 +722,26 @@ err:
> static int uea_load_firmware(struct usb_device *usb, unsigned int
> ver) {
> int ret;
> - char *fw_name = FW_DIR "eagle.fw";
> + char *fw_name = EAGLE_FIRMWARE;
>
> uea_enters(usb);
> uea_info(usb, "pre-firmware device, uploading firmware\n");
>
> switch (ver) {
> case ADI930:
> - fw_name = FW_DIR "adi930.fw";
> + fw_name = ADI930_FIRMWARE;
> break;
> case EAGLE_I:
> - fw_name = FW_DIR "eagleI.fw";
> + fw_name = EAGLE_I_FIRMWARE;
> break;
> case EAGLE_II:
> - fw_name = FW_DIR "eagleII.fw";
> + fw_name = EAGLE_II_FIRMWARE;
> break;
> case EAGLE_III:
> - fw_name = FW_DIR "eagleIII.fw";
> + fw_name = EAGLE_III_FIRMWARE;
> break;
> case EAGLE_IV:
> - fw_name = FW_DIR "eagleIV.fw";
> + fw_name = EAGLE_IV_FIRMWARE;
> break;
> }
>
> @@ -869,19 +897,19 @@ static int request_dsp(struct uea_softc *sc)
>
> if (UEA_CHIP_VERSION(sc) == EAGLE_IV) {
> if (IS_ISDN(sc))
> - dsp_name = FW_DIR "DSP4i.bin";
> + dsp_name = DSP4I_FIRMWARE;
> else
> - dsp_name = FW_DIR "DSP4p.bin";
> + dsp_name = DSP4P_FIRMWARE;
> } else if (UEA_CHIP_VERSION(sc) == ADI930) {
> if (IS_ISDN(sc))
> - dsp_name = FW_DIR "DSP9i.bin";
> + dsp_name = DSP9I_FIRMWARE;
> else
> - dsp_name = FW_DIR "DSP9p.bin";
> + dsp_name = DSP9P_FIRMWARE;
> } else {
> if (IS_ISDN(sc))
> - dsp_name = FW_DIR "DSPei.bin";
> + dsp_name = DSPEI_FIRMWARE;
> else
> - dsp_name = FW_DIR "DSPep.bin";
> + dsp_name = DSPEP_FIRMWARE;
> }
>
> ret = request_firmware(>dsp_firm, dsp_name,
> >usb_dev->dev); @@ -1925,7 +1953,7 @@ static int
> load_XILINX_firmware(struct uea_softc *sc) int ret, size, u, ln;
> const u8 *pfw;
> u8 value;
> - char *fw_name = FW_DIR "930-fpga.bin";
> + char *fw_name = FPGA930_FIRMWARE;
>
> uea_enters(INS_TO_USBDEV(sc));
>
> @@ -2753,3 +2781,28 @@ module_usb_driver(uea_driver);
> MODULE_AUTHOR("Damien Bergamini/Matthieu Castet/Stanislaw W.
> Gruszka"); MODULE_DESCRIPTION("ADI 930/Eagle USB ADSL Modem driver");
> MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_FIRMWARE(EAGLE_FIRMWARE);
> +MODULE_FIRMWARE(ADI930_FIRMWARE);
> +MODULE_FIRMWARE(EAGLE_I_FIRMWARE);
> +MODULE_FIRMWARE(EAGLE_II_FIRMWARE);
> +MODULE_FIRMWARE(EAGLE_III_FIRMWARE);
> +MODULE_FIRMWARE(EAGLE_IV_FIRMWARE);
> +MODULE_FIRMWARE(DSP4I_FIRMWARE);
> +MODULE_FIRMWARE(DSP4P_FIRMWARE);
> +MODULE_FIRMWARE(DSP9I_FIRMWARE);
> +MODULE_FIRMWARE(DSP9P_FIRMWARE);
> +MODULE_FIRMWARE(DSPEI_FIRMWARE);
> +MODULE_FIRMWARE(DSPEP_FIRMWARE);
> +MODULE_FIRMWARE(FPGA930_FIRMWARE);
>
Re: RAID extremely slow
On 07/27/2012 09:45 PM, Grant Coady wrote:
On Fri, 27 Jul 2012 14:45:18 -0700, you wrote:
On 07/27/2012 12:08 PM, Bill Davidsen wrote:
Have you set the io scheduler to deadline on all members of the array?
That's kind of "job one" on older kernels.
I have not, thanks for the tip, I'll look into that now.
Plus I disable the on-drive queuing (NCQ) during startup, right now
I don't have benchmarks to show the difference. This on a six by 1TB
drive RAID6 array I built over a year ago on Slackware64-13.37:
# cat /etc/rc.d/rc.local
...
# turn off NCQ on the RAID drives by adjusting queue depth to 1
n=1
echo "rc.local: Disable RAID drives' NCQ"
for d in a b c d e f
do
echo " set NCQ depth to $n on sd${d}"
echo $n> /sys/block/sd${d}/device/queue_depth
done
...
Maybe you could try that? See if it makes a difference. My drives
are Seagate.
Grant.
Does disabling NCQ improve performance?
The suggestion to use kernel 3.4.6 has been working quite well so far,
hopefully that fixes the problem. I'll know for sure in a few more days...
Thanks!
-- Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] debug: Do not permit CONFIG_DEBUG_STACK_USAGE=y on IA64 or PARISC
On Wed, 2012-07-18 at 10:35 -0700, Tony Luck wrote: > The stack_not_used() function in assumes that stacks > grow downwards. This is not true on IA64 or PARISC, so this function > would walk off in the wrong direction and into the weeds. OK, so looking at all of this, that statement's not quite true ... at least for parisc, we begin the stack where end_of_stack() says the end should be and so the walker will likely find the next word after the canary skip occupied and terminate there, so we think the stack is larger than it really is. It gets the wrong value, but it will never even walk out of the stack area. > Found on IA64 because of a compilation failure with recursive dependencies > on IA64_TASKSIZE and IA64_THREAD_INFO_SIZE. > > Fixing the code is possible, but should be combined with other > infrastructure additions to set up the "canary" at the end of the stack. I agree with this. Most of it looks easily fixable, but how would I enable the fix for ia64? For PA it's simple: I'll just use CONFIG_STACK_GROWSUP, but that won't work for you. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dynamic_debug: Restore dev_dbg functionality, optimize stack
commit c4e00daaa9 ("driver-core: extend dev_printk() to pass structured data")
changed __dev_printk and broke dynamic-debug's ability to control the
dynamic prefix of dev_dbg(dev,..).
dynamic_emit_prefix() adds "[tid] module:func:line:" to the output and
those additions got lost.
In addition, the current dynamic debug code uses up to 3 recursion
levels via %pV. This can consume quite a bit of stack. Directly
call printk_emit to reduce the recursion depth.
These changes include:
o Remove KERN_DEBUG from dynamic_emit_prefix
o Create and use function create_syslog_header to format the syslog
header for printk_emit uses.
o Call create_syslog_header and neaten __dev_printk
o Call create_syslog_header and printk_emit from dynamic_dev_dbg
o Call create_syslog_header and printk_emit from dynamic_netdev_dbg
o Make __dev_printk and __netdev_printk static not global
o Remove include header declarations of __dev_printk and __netdev_printk
o Remove now unused EXPORT_SYMBOL()s of __dev_printk and __netdev_printk
o Whitespace neatening
Changes in v2:
o Fix dynamic_emit_prefix to always initialize output
o Call create_syslog_header and emit_printk from__netdev_printk and
eliminate call to dev_printk to remove another recursion via %pV
Signed-off-by: Joe Perches
---
drivers/base/core.c | 57 +++
include/linux/device.h| 11 +++-
include/linux/netdevice.h |3 --
lib/dynamic_debug.c | 65 -
net/core/dev.c| 24 -
5 files changed, 106 insertions(+), 54 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index f338037..d46b635 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1861,25 +1861,19 @@ void device_shutdown(void)
*/
#ifdef CONFIG_PRINTK
-int __dev_printk(const char *level, const struct device *dev,
-struct va_format *vaf)
+int create_syslog_header(const struct device *dev, char *hdr, size_t hdrlen)
{
- char dict[128];
- size_t dictlen = 0;
const char *subsys;
-
- if (!dev)
- return printk("%s(NULL device *): %pV", level, vaf);
+ size_t pos = 0;
if (dev->class)
subsys = dev->class->name;
else if (dev->bus)
subsys = dev->bus->name;
else
- goto skip;
+ return 0;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- "SUBSYSTEM=%s", subsys);
+ pos += snprintf(hdr + pos, hdrlen - pos, "SUBSYSTEM=%s", subsys);
/*
* Add device identifier DEVICE=:
@@ -1895,28 +1889,41 @@ int __dev_printk(const char *level, const struct device
*dev,
c = 'b';
else
c = 'c';
- dictlen++;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- "DEVICE=%c%u:%u",
- c, MAJOR(dev->devt), MINOR(dev->devt));
+ pos++;
+ pos += snprintf(hdr + pos, hdrlen - pos,
+ "DEVICE=%c%u:%u",
+ c, MAJOR(dev->devt), MINOR(dev->devt));
} else if (strcmp(subsys, "net") == 0) {
struct net_device *net = to_net_dev(dev);
- dictlen++;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- "DEVICE=n%u", net->ifindex);
+ pos++;
+ pos += snprintf(hdr + pos, hdrlen - pos,
+ "DEVICE=n%u", net->ifindex);
} else {
- dictlen++;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- "DEVICE=+%s:%s", subsys, dev_name(dev));
+ pos++;
+ pos += snprintf(hdr + pos, hdrlen - pos,
+ "DEVICE=+%s:%s", subsys, dev_name(dev));
}
-skip:
- return printk_emit(0, level[1] - '0',
- dictlen ? dict : NULL, dictlen,
+
+ return pos;
+}
+EXPORT_SYMBOL(create_syslog_header);
+
+static int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf)
+{
+ char hdr[128];
+ size_t hdrlen;
+
+ if (!dev)
+ return printk("%s(NULL device *): %pV", level, vaf);
+
+ hdrlen = create_syslog_header(dev, hdr, sizeof(hdr));
+
+ return printk_emit(0, level[1] - '0', hdrlen ? hdr : NULL, hdrlen,
"%s %s: %pV",
dev_driver_string(dev), dev_name(dev), vaf);
}
-EXPORT_SYMBOL(__dev_printk);
int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
@@ -1931,6 +1938,7 @@ int dev_printk(const char *level, const struct device
*dev,
vaf.va =
r =
[GIT] Networking
Several bug fixes, some to new features appearing in this merge window, some that have been around for a while. I have a short list of known problems that need to be sorted out, but all of them can be solved easily during the run up to 3.6-final. I'll be offline until Sunday afternoon, but nothing need hold up 3.6-rc1 and the close of the merge window, networking wise, at this point. 1) Fix interface check in ipv4 TCP early demux, from Eric Dumazet. 2) Fix a long standing bug in TCP DMA to userspace offload that can hang applications using MSG_TRUNC, from Jiri Kosina. 3) Don't allow TCP_USER_TIMEOUT to be negative, from Hangbin Liu. 4) Don't use GFP_KERNEL under spinlock in kaweth driver, from Dan Carpenter Please pull, thanks a lot. The following changes since commit b387e41e523c1aa347cff055455d0dd129357df4: Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-07-27 08:35:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to 7b9b04fb728ec0b94464ed902f3395aa592c5bcf: Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2012-07-27 14:25:40 -0700) Dan Carpenter (1): USB: kaweth.c: use GFP_ATOMIC under spin_lock David S. Miller (1): Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless Eric Dumazet (1): ipv4: fix TCP early demux Hangbin Liu (1): tcp: Add TCP_USER_TIMEOUT negative value check Hauke Mehrtens (2): bcma: fix regression in interrupt assignment on mips bcma: add missing iounmap on error path Jesse Gross (1): Revert "openvswitch: potential NULL deref in sample()" Jiri Benc (1): net: fix rtnetlink IFF_PROMISC and IFF_ALLMULTI handling Jiri Kosina (1): tcp: perform DMA to userspace only if there is a task waiting for it John W. Linville (1): Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem Thomas Huehn (1): mac80211_hwsim: fix possible race condition in usage of info->control.sta & control.vif drivers/bcma/driver_mips.c| 6 +++--- drivers/bcma/scan.c | 15 ++- drivers/net/usb/kaweth.c | 2 +- drivers/net/wireless/mac80211_hwsim.c | 5 - net/core/rtnetlink.c | 8 +++- net/ipv4/tcp.c| 5 - net/ipv4/tcp_input.c | 5 - net/ipv4/tcp_ipv4.c | 14 ++ net/ipv4/tcp_minisocks.c | 1 + net/openvswitch/actions.c | 3 --- 10 files changed, 36 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in kernel ( 3.4.x -> 3.5rc )
hello again, bisect git gives ( after 13 steps) : 58bca4a8fa90fcf9069379653b396b2cec642f7f is the first bad commit Regards, Nicolas Prochazka 2012/7/24 Thadeu Lima de Souza Cascardo : > On Mon, Jul 23, 2012 at 11:15:09PM +0200, nicolas prochazka wrote: >> Hello, >> I 'm trying differents versions with differents results >> >> - commit f044db4cb4bf16893812d35b5fbeaaf3e30c9215 : bug is not reproductible >> - 3.5rc7 : bug is reproductible(cf new dump ) >> - master branch : bug is reproductible >> >> >> >> Regards, >> Nicolas Prochazka >> >> > > Hi, Nicolas. > > Can you try a bisect? I am also copying David Howells and Bobby Powers, > even though their set of patches don't seem to be the culprit. > > Regards. > Cascardo. > >> Jul 23 21:10:05 positronic18696 BUG: unable to handle kernel paging >> request at 0001002f >> Jul 23 21:10:05 positronic18696 IP: [] dup_fd+0x160/0x2e0 >> Jul 23 21:10:05 positronic18696 PGD 6627ea067 PUD 0 >> Jul 23 21:10:05 positronic18696 Oops: 0002 [#1] SMP >> Jul 23 21:10:05 positronic18696 CPU 1 >> Jul 23 21:10:05 positronic18696 Modules linked in: kvm_intel kvm >> Jul 23 21:10:05 positronic18696 >> Jul 23 21:10:05 positronic18696 Pid: 17596, comm: queue.sh Not tainted >> 3.5.0-rc7-dirty #6 Dell Inc. PowerEdge M600/0MY736 >> Jul 23 21:10:05 positronic18696 RIP: 0010:[] >> [] dup_fd+0x160/0x2e0 >> Jul 23 21:10:05 positronic18696 RSP: 0018:880669ebdd90 EFLAGS: 00010206 >> Jul 23 21:10:05 positronic18696 RAX: 0038 RBX: >> 8807ed95eec0 RCX: 0007 >> Jul 23 21:10:05 positronic18696 RDX: RSI: >> 0800 RDI: 8805a4d01d40 >> Jul 23 21:10:05 positronic18696 RBP: 880669ebddf0 R08: >> 0020 R09: 81156694 >> Jul 23 21:10:05 positronic18696 R10: 0001 R11: >> R12: 8807ecf25000 >> Jul 23 21:10:05 positronic18696 R13: 8805a4d01d80 R14: >> 0100 R15: 8807d3a61800 >> Jul 23 21:10:05 positronic18696 FS: 7f1a8e719700() >> GS:88083fc4() knlGS: >> Jul 23 21:10:05 positronic18696 CS: 0010 DS: ES: CR0: >> 8005003b >> Jul 23 21:10:05 positronic18696 CR2: 0001002f CR3: >> 00066ef9 CR4: 27e0 >> Jul 23 21:10:05 positronic18696 DR0: 0001 DR1: >> 0002 DR2: 0001 >> Jul 23 21:10:05 positronic18696 DR3: 000a DR6: >> 0ff0 DR7: 0400 >> Jul 23 21:10:05 positronic18696 Process queue.sh (pid: 17596, >> threadinfo 880669ebc000, task 8806625ab000) >> Jul 23 21:10:05 positronic18696 Stack: >> Jul 23 21:10:05 positronic18696 880669ebdda0 00018102db49 >> 0020 8806627ee8c0 >> Jul 23 21:10:05 positronic18696 8807eefc1608 8807eefc1680 >> 7f1a8e7199d0 8807bf41d000 >> Jul 23 21:10:05 positronic18696 01200011 >> 7f1a8e7199d0 >> Jul 23 21:10:05 positronic18696 Call Trace: >> Jul 23 21:10:05 positronic18696 [] >> copy_process+0x931/0x13c0 >> Jul 23 21:10:05 positronic18696 [] do_fork+0x54/0x360 >> Jul 23 21:10:05 positronic18696 [] ? >> _raw_spin_lock+0xe/0x20 >> Jul 23 21:10:05 positronic18696 [] ? >> __set_task_blocked+0x37/0x80 >> Jul 23 21:10:05 positronic18696 [] ? >> __set_current_blocked+0x53/0x70 >> Jul 23 21:10:05 positronic18696 [] sys_clone+0x28/0x30 >> Jul 23 21:10:05 positronic18696 [] stub_clone+0x13/0x20 >> Jul 23 21:10:05 positronic18696 [] ? >> system_call_fastpath+0x16/0x1b >> Jul 23 21:10:05 positronic18696 Code: 8b 45 b0 49 8b 7d 10 48 8b 71 10 >> 4c 89 c2 e8 08 82 23 00 45 85 f6 74 54 41 8d 46 ff 31 c9 48 8d 34 c5 >> 08 00 00 00 31 c0 eb 15 90 48 ff 42 30 49 89 14 04 ff c1 48 83 c0 >> 08 48 39 f0 74 24 49 >> Jul 23 21:10:05 positronic18696 RIP [] dup_fd+0x160/0x2e0 >> Jul 23 21:10:05 positronic18696 RSP >> Jul 23 21:10:05 positronic18696 CR2: 0001002f >> Jul 23 21:10:05 positronic18696 ---[ end trace ccf5b66c39d92756 ]--- >> Jul 23 21:10:05 positronic18696 device vmtap35 left promiscuous mode >> Jul 23 21:10:05 positronic18696 device vmEtap35 left promiscuous mode >> Jul 23 21:10:05 positronic18696 device vmtap36 left promiscuous mode >> Jul 23 21:10:05 positronic18696 device vmEtap36 left promiscuous mode >> Jul 23 21:10:05 positronic18696 device vmtap37 left promiscuous mode >> Jul 23 21:10:05 positronic18696 device vmEtap37 left promiscuous mode >> Jul 23 21:10:05 positronic18696 device vmtap38 left promiscuous mode >> Jul 23 21:10:05 positronic18696 device vmEtap38 left promiscuous mode >> Jul 23 21:10:05 positronic18696 BUG: unable to handle kernel paging >> request at 0001003b >> Jul 23 21:10:05 positronic18696 IP: [] >> tid_fd_revalidate+0x84/0x1a0 >> Jul 23 21:10:05 positronic18696 PGD 598c9e067 PUD 0 >> Jul 23 21:10:05 positronic18696 Oops: [#2] SMP >> Jul 23 21:10:05 positronic18696 CPU 0 >> Jul 23 21:10:05 positronic18696 Modules linked in: kvm_intel kvm >> Jul 23 21:10:05
Re: [PATCH V3 3/3] virtio-blk: Add bio-based IO path for virtio-blk
> > I'm not sure what the correct behavior for bio & cacheflush is, if > > any. > > REQ_FLUSH is not supported in the bio path. Ouch, that's correct: @@ -414,7 +529,7 @@ static void virtblk_update_cache_mode(struct virtio_device *vdev) u8 writeback = virtblk_get_cache_mode(vdev); struct virtio_blk *vblk = vdev->priv; - if (writeback) + if (writeback && !use_bio) blk_queue_flush(vblk->disk->queue, REQ_FLUSH); else blk_queue_flush(vblk->disk->queue, 0); then it is not safe against power losses. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 3/3] virtio-blk: Add bio-based IO path for virtio-blk
On 07/28/2012 04:21 AM, Asias He wrote: > This patch introduces bio-based IO path for virtio-blk. > > Compared to request-based IO path, bio-based IO path uses driver > provided ->make_request_fn() method to bypasses the IO scheduler. It > handles the bio to device directly without allocating a request in block > layer. This reduces the IO path in guest kernel to achieve high IOPS > and lower latency. The downside is that guest can not use the IO > scheduler to merge and sort requests. However, this is not a big problem > if the backend disk in host side uses faster disk device. > > When the bio-based IO path is not enabled, virtio-blk still uses the > original request-based IO path, no performance difference is observed. > > Performance evaluation: > - > 1) Fio test is performed in a 8 vcpu guest with ramdisk based guest using > kvm tool. > > Short version: > With bio-based IO path, sequential read/write, random read/write > IOPS boost : 28%, 24%, 21%, 16% > Latency improvement: 32%, 17%, 21%, 16% > > Long version: > With bio-based IO path: > seq-read : io=2048.0MB, bw=116996KB/s, iops=233991 , runt= 17925msec > seq-write : io=2048.0MB, bw=100829KB/s, iops=201658 , runt= 20799msec > rand-read : io=3095.7MB, bw=112134KB/s, iops=224268 , runt= 28269msec > rand-write: io=3095.7MB, bw=96198KB/s, iops=192396 , runt= 32952msec > clat (usec): min=0 , max=2631.6K, avg=58716.99, stdev=191377.30 > clat (usec): min=0 , max=1753.2K, avg=66423.25, stdev=81774.35 > clat (usec): min=0 , max=2915.5K, avg=61685.70, stdev=120598.39 > clat (usec): min=0 , max=1933.4K, avg=76935.12, stdev=96603.45 > cpu : usr=74.08%, sys=703.84%, ctx=29661403, majf=21354, minf=22460954 > cpu : usr=70.92%, sys=702.81%, ctx=77219828, majf=13980, minf=27713137 > cpu : usr=72.23%, sys=695.37%, ctx=88081059, majf=18475, minf=28177648 > cpu : usr=69.69%, sys=654.13%, ctx=145476035, majf=15867, minf=26176375 > With request-based IO path: > seq-read : io=2048.0MB, bw=91074KB/s, iops=182147 , runt= 23027msec > seq-write : io=2048.0MB, bw=80725KB/s, iops=161449 , runt= 25979msec > rand-read : io=3095.7MB, bw=92106KB/s, iops=184211 , runt= 34416msec > rand-write: io=3095.7MB, bw=82815KB/s, iops=165630 , runt= 38277msec > clat (usec): min=0 , max=1932.4K, avg=77824.17, stdev=170339.49 > clat (usec): min=0 , max=2510.2K, avg=78023.96, stdev=146949.15 > clat (usec): min=0 , max=3037.2K, avg=74746.53, stdev=128498.27 > clat (usec): min=0 , max=1363.4K, avg=89830.75, stdev=114279.68 > cpu : usr=53.28%, sys=724.19%, ctx=37988895, majf=17531, minf=23577622 > cpu : usr=49.03%, sys=633.20%, ctx=205935380, majf=18197, minf=27288959 > cpu : usr=55.78%, sys=722.40%, ctx=101525058, majf=19273, minf=28067082 > cpu : usr=56.55%, sys=690.83%, ctx=228205022, majf=18039, minf=26551985 > > 2) Fio test is performed in a 8 vcpu guest with Fusion-IO based guest using > kvm tool. > > Short version: > With bio-based IO path, sequential read/write, random read/write > IOPS boost : 11%, 11%, 13%, 10% > Latency improvement: 10%, 10%, 12%, 10% > Long Version: > With bio-based IO path: > read : io=2048.0MB, bw=58920KB/s, iops=117840 , runt= 35593msec > write: io=2048.0MB, bw=64308KB/s, iops=128616 , runt= 32611msec > read : io=3095.7MB, bw=59633KB/s, iops=119266 , runt= 53157msec > write: io=3095.7MB, bw=62993KB/s, iops=125985 , runt= 50322msec > clat (usec): min=0 , max=1284.3K, avg=128109.01, stdev=71513.29 > clat (usec): min=94 , max=962339 , avg=116832.95, stdev=65836.80 > clat (usec): min=0 , max=1846.6K, avg=128509.99, stdev=89575.07 > clat (usec): min=0 , max=2256.4K, avg=121361.84, stdev=82747.25 > cpu : usr=56.79%, sys=421.70%, ctx=147335118, majf=21080, minf=19852517 > cpu : usr=61.81%, sys=455.53%, ctx=143269950, majf=16027, minf=24800604 > cpu : usr=63.10%, sys=455.38%, ctx=178373538, majf=16958, minf=24822612 > cpu : usr=62.04%, sys=453.58%, ctx=226902362, majf=16089, minf=23278105 > With request-based IO path: > read : io=2048.0MB, bw=52896KB/s, iops=105791 , runt= 39647msec > write: io=2048.0MB, bw=57856KB/s, iops=115711 , runt= 36248msec > read : io=3095.7MB, bw=52387KB/s, iops=104773 , runt= 60510msec > write: io=3095.7MB, bw=57310KB/s, iops=114619 , runt= 55312msec > clat (usec): min=0 , max=1532.6K, avg=142085.62, stdev=109196.84 > clat (usec): min=0 , max=1487.4K, avg=129110.71, stdev=114973.64 > clat (usec): min=0 , max=1388.6K, avg=145049.22, stdev=107232.55 > clat (usec): min=0 , max=1465.9K, avg=133585.67, stdev=110322.95 > cpu : usr=44.08%, sys=590.71%, ctx=451812322, majf=14841, minf=17648641 > cpu : usr=48.73%, sys=610.78%, ctx=418953997, majf=22164, minf=26850689 > cpu : usr=45.58%, sys=581.16%, ctx=714079216, majf=21497, minf=22558223 > cpu : usr=48.40%, sys=599.65%, ctx=656089423, majf=16393, minf=23824409 What are the cases where we'll see a performance
Re: [RESEND PATCH 2/4 v3] mm: fix possible incorrect return value of migrate_pages() syscall
2012/7/28 Christoph Lameter : > On Sat, 28 Jul 2012, Joonsoo Kim wrote: > >> do_migrate_pages() can return the number of pages not migrated. >> Because migrate_pages() syscall return this value directly, >> migrate_pages() syscall may return the number of pages not migrated. >> In fail case in migrate_pages() syscall, we should return error value. >> So change err to -EBUSY > > Lets leave this alone. This would change the migrate_pages semantics > because a successful move of N out of M pages would be marked as a > total failure although pages were in fact moved. > Okay. Then, do we need to fix man-page of migrate_pages() syscall? According to man-page, only returning 0 or -1 is valid. Without this patch, it can return positive value. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V1 3/3] OMAP: Define TCA6424 max number of possible IRQs
From: Leed Aguilar TCA6424 being a 24 bit I2C and SMBus I/O expander has 24 available GPIO lines that can be used as IRQs lines. So, the support for 24 more IRQ lines has been added to the kernel. Signed-off-by: Leed Aguilar Signed-off-by: Chandrabhanu Mahapatra --- arch/arm/plat-omap/include/plat/irqs.h | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h index 37b..97c71ba 100644 --- a/arch/arm/plat-omap/include/plat/irqs.h +++ b/arch/arm/plat-omap/include/plat/irqs.h @@ -378,8 +378,17 @@ #endif #define OMAP_FPGA_IRQ_END (OMAP_FPGA_IRQ_BASE + OMAP_FPGA_NR_IRQS) +/* TCA6424A I2C and SMBus I/O expander */ +#define OMAP_TCA6424_IRQ_BASE (OMAP_FPGA_IRQ_END) +#ifdef CONFIG_GPIO_PCA953X +#define OMAP_TCA6424_NR_IRQS 24 +#else +#define OMAP_TCA6424_NR_IRQS 0 +#endif +#define OMAP_TCA6424_IRQ_END (OMAP_TCA6424_IRQ_BASE + OMAP_TCA6424_NR_IRQS) + /* External TWL4030 can handle interrupts on 2430 and 34xx boards */ -#defineTWL4030_IRQ_BASE(OMAP_FPGA_IRQ_END) +#defineTWL4030_IRQ_BASE(OMAP_TCA6424_IRQ_END) #ifdef CONFIG_TWL4030_CORE #defineTWL4030_BASE_NR_IRQS8 #defineTWL4030_PWR_NR_IRQS 8 -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V1 2/3] gpio/pca953x: increase variables size to support 24 bit of data
From: Leed Aguilar
Increase variable size from u16 to u32 to allocate 24 bit of data required for
the TCA6424 I/O expander device type.
Signed-off-by: Leed Aguilar
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/gpio/gpio-pca953x.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index af7024f..c3ca7d8 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -78,10 +78,10 @@ struct pca953x_chip {
#ifdef CONFIG_GPIO_PCA953X_IRQ
struct mutex irq_lock;
- uint16_t irq_mask;
- uint16_t irq_stat;
- uint16_t irq_trig_raise;
- uint16_t irq_trig_fall;
+ u32 irq_mask;
+ u32 irq_stat;
+ u32 irq_trig_raise;
+ u32 irq_trig_fall;
int irq_base;
#endif
@@ -349,8 +349,8 @@ static void pca953x_irq_bus_lock(struct irq_data *d)
static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
{
struct pca953x_chip *chip = irq_data_get_irq_chip_data(d);
- uint16_t new_irqs;
- uint16_t level;
+ u32 new_irqs;
+ u32 level;
/* Look for any newly setup interrupt */
new_irqs = chip->irq_trig_fall | chip->irq_trig_raise;
@@ -368,8 +368,8 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
static int pca953x_irq_set_type(struct irq_data *d, unsigned int type)
{
struct pca953x_chip *chip = irq_data_get_irq_chip_data(d);
- uint16_t level = d->irq - chip->irq_base;
- uint16_t mask = 1 << level;
+ u32 level = d->irq - chip->irq_base;
+ u32 mask = 1 << level;
if (!(type & IRQ_TYPE_EDGE_BOTH)) {
dev_err(>client->dev, "irq %d: unsupported type %d\n",
@@ -399,12 +399,12 @@ static struct irq_chip pca953x_irq_chip = {
.irq_set_type = pca953x_irq_set_type,
};
-static uint16_t pca953x_irq_pending(struct pca953x_chip *chip)
+static u32 pca953x_irq_pending(struct pca953x_chip *chip)
{
u32 cur_stat;
- uint16_t old_stat;
- uint16_t pending;
- uint16_t trigger;
+ u32 old_stat;
+ u32 pending;
+ u32 trigger;
int ret, offset = 0;
switch (chip->chip_type) {
@@ -440,8 +440,8 @@ static uint16_t pca953x_irq_pending(struct pca953x_chip
*chip)
static irqreturn_t pca953x_irq_handler(int irq, void *devid)
{
struct pca953x_chip *chip = devid;
- uint16_t pending;
- uint16_t level;
+ u32 pending;
+ u32 level;
pending = pca953x_irq_pending(chip);
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V1 1/3] GPIO: PCA953X: Increase size of invert variable to support 24 bit
TCA6424 is a low voltage 24 bit I2C and SMBus I/O expander of pca953x family
similar to its 16 bit predecessor TCA6416. It comes with three 8-bit active
Input, Output, Polarity Inversion and Configuration registers each. The polarity
of Input ports can be reversed by setting the appropiate bit in Polarity
Inversion registers.
The variables corresponding to Input, Output and Configuration registers have
already been updated to support 24 bit values. This patch thus updates the
invert variable of PCA953X platform data to support 24 bit.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/gpio/gpio-pca953x.c | 11 ++-
include/linux/i2c/pca953x.h |2 +-
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 1c313c7..af7024f 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -564,7 +564,7 @@ static void pca953x_irq_teardown(struct pca953x_chip *chip)
* WARNING: This is DEPRECATED and will be removed eventually!
*/
static void
-pca953x_get_alt_pdata(struct i2c_client *client, int *gpio_base, int *invert)
+pca953x_get_alt_pdata(struct i2c_client *client, int *gpio_base, u32 *invert)
{
struct device_node *node;
const __be32 *val;
@@ -592,13 +592,13 @@ pca953x_get_alt_pdata(struct i2c_client *client, int
*gpio_base, int *invert)
}
#else
static void
-pca953x_get_alt_pdata(struct i2c_client *client, int *gpio_base, int *invert)
+pca953x_get_alt_pdata(struct i2c_client *client, int *gpio_base, u32 *invert)
{
*gpio_base = -1;
}
#endif
-static int __devinit device_pca953x_init(struct pca953x_chip *chip, int invert)
+static int __devinit device_pca953x_init(struct pca953x_chip *chip, u32 invert)
{
int ret;
@@ -617,7 +617,7 @@ out:
return ret;
}
-static int __devinit device_pca957x_init(struct pca953x_chip *chip, int invert)
+static int __devinit device_pca957x_init(struct pca953x_chip *chip, u32 invert)
{
int ret;
u32 val = 0;
@@ -653,8 +653,9 @@ static int __devinit pca953x_probe(struct i2c_client
*client,
{
struct pca953x_platform_data *pdata;
struct pca953x_chip *chip;
- int irq_base=0, invert=0;
+ int irq_base = 0;
int ret;
+ u32 invert = 0;
chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
if (chip == NULL)
diff --git a/include/linux/i2c/pca953x.h b/include/linux/i2c/pca953x.h
index 139ba52..3c98dd4 100644
--- a/include/linux/i2c/pca953x.h
+++ b/include/linux/i2c/pca953x.h
@@ -11,7 +11,7 @@ struct pca953x_platform_data {
unsignedgpio_base;
/* initial polarity inversion setting */
- uint16_tinvert;
+ u32 invert;
/* interrupt base */
int irq_base;
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 4/4 v3] mm: fix possible incorrect return value of move_pages() syscall
2012/7/28 Christoph Lameter : > On Sat, 28 Jul 2012, Joonsoo Kim wrote: > >> move_pages() syscall may return success in case that >> do_move_page_to_node_array return positive value which means migration >> failed. > > Nope. It only means that the migration for some pages has failed. This may > still be considered successful for the app if it moves 1 pages and one > failed. > > This patch would break the move_pages() syscall because an error code > return from do_move_pages_to_node_array() will cause the status byte for > each page move to not be updated anymore. Application will not be able to > tell anymore which pages were successfully moved and which are not. In case of returning non-zero, valid status is not required according to man page. So, this patch would not break the move_pages() syscall. But, I agree that returning positive value only means that the migration for some pages has failed. This is my mistake, so please drop this patch. Thanks for review. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V1 0/3] Extend TCA6424 support
Hi everyone! This following patch series extends support capabilities of TCA6424 through following patches. The 1st patch adds 24 bit support for polarity inversion registers by providing 24 bit support for invert variable. The 2nd patch adds 24 bit support of the variables such as irq_mask, irq_stat, etc. The 3rd patch extends 24 lines irq support for TCA6424. The 4th patch for the previous patch series has been removed. These patches were based on mainline kernel v3.5rc7. All your comments and suggestions are welcome. Regards, Chandrabhanu Chandrabhanu Mahapatra (1): GPIO: PCA953X: Increase size of invert variable to support 24 bit Leed Aguilar (2): gpio/pca953x: increase variables size to support 24 bit of data OMAP: Define TCA6424 max number of possible IRQs arch/arm/plat-omap/include/plat/irqs.h | 11 - drivers/gpio/gpio-pca953x.c| 39 include/linux/i2c/pca953x.h|2 +- 3 files changed, 31 insertions(+), 21 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V1 0/3] Extend TCA6424 support
Hi everyone! This following patch series extends support capabilities of TCA6424 through following patches. The 1st patch adds 24 bit support for polarity inversion registers by providing 24 bit support for invert variable. The 2nd patch adds 24 bit support of the variables such as irq_mask, irq_stat, etc. The 3rd patch extends 24 lines irq support for TCA6424. The 4th patch for the previous patch series has been removed. These patches were based on mainline kernel v3.5rc7. All your comments and suggestions are welcome. Regards, Chandrabhanu Chandrabhanu Mahapatra (1): GPIO: PCA953X: Increase size of invert variable to support 24 bit Leed Aguilar (2): gpio/pca953x: increase variables size to support 24 bit of data OMAP: Define TCA6424 max number of possible IRQs arch/arm/plat-omap/include/plat/irqs.h | 11 - drivers/gpio/gpio-pca953x.c| 39 include/linux/i2c/pca953x.h|2 +- 3 files changed, 31 insertions(+), 21 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 4/4 v3] mm: fix possible incorrect return value of move_pages() syscall
2012/7/28 Christoph Lameter c...@linux.com: On Sat, 28 Jul 2012, Joonsoo Kim wrote: move_pages() syscall may return success in case that do_move_page_to_node_array return positive value which means migration failed. Nope. It only means that the migration for some pages has failed. This may still be considered successful for the app if it moves 1 pages and one failed. This patch would break the move_pages() syscall because an error code return from do_move_pages_to_node_array() will cause the status byte for each page move to not be updated anymore. Application will not be able to tell anymore which pages were successfully moved and which are not. In case of returning non-zero, valid status is not required according to man page. So, this patch would not break the move_pages() syscall. But, I agree that returning positive value only means that the migration for some pages has failed. This is my mistake, so please drop this patch. Thanks for review. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 V1 1/3] GPIO: PCA953X: Increase size of invert variable to support 24 bit
TCA6424 is a low voltage 24 bit I2C and SMBus I/O expander of pca953x family
similar to its 16 bit predecessor TCA6416. It comes with three 8-bit active
Input, Output, Polarity Inversion and Configuration registers each. The polarity
of Input ports can be reversed by setting the appropiate bit in Polarity
Inversion registers.
The variables corresponding to Input, Output and Configuration registers have
already been updated to support 24 bit values. This patch thus updates the
invert variable of PCA953X platform data to support 24 bit.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/gpio/gpio-pca953x.c | 11 ++-
include/linux/i2c/pca953x.h |2 +-
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 1c313c7..af7024f 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -564,7 +564,7 @@ static void pca953x_irq_teardown(struct pca953x_chip *chip)
* WARNING: This is DEPRECATED and will be removed eventually!
*/
static void
-pca953x_get_alt_pdata(struct i2c_client *client, int *gpio_base, int *invert)
+pca953x_get_alt_pdata(struct i2c_client *client, int *gpio_base, u32 *invert)
{
struct device_node *node;
const __be32 *val;
@@ -592,13 +592,13 @@ pca953x_get_alt_pdata(struct i2c_client *client, int
*gpio_base, int *invert)
}
#else
static void
-pca953x_get_alt_pdata(struct i2c_client *client, int *gpio_base, int *invert)
+pca953x_get_alt_pdata(struct i2c_client *client, int *gpio_base, u32 *invert)
{
*gpio_base = -1;
}
#endif
-static int __devinit device_pca953x_init(struct pca953x_chip *chip, int invert)
+static int __devinit device_pca953x_init(struct pca953x_chip *chip, u32 invert)
{
int ret;
@@ -617,7 +617,7 @@ out:
return ret;
}
-static int __devinit device_pca957x_init(struct pca953x_chip *chip, int invert)
+static int __devinit device_pca957x_init(struct pca953x_chip *chip, u32 invert)
{
int ret;
u32 val = 0;
@@ -653,8 +653,9 @@ static int __devinit pca953x_probe(struct i2c_client
*client,
{
struct pca953x_platform_data *pdata;
struct pca953x_chip *chip;
- int irq_base=0, invert=0;
+ int irq_base = 0;
int ret;
+ u32 invert = 0;
chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
if (chip == NULL)
diff --git a/include/linux/i2c/pca953x.h b/include/linux/i2c/pca953x.h
index 139ba52..3c98dd4 100644
--- a/include/linux/i2c/pca953x.h
+++ b/include/linux/i2c/pca953x.h
@@ -11,7 +11,7 @@ struct pca953x_platform_data {
unsignedgpio_base;
/* initial polarity inversion setting */
- uint16_tinvert;
+ u32 invert;
/* interrupt base */
int irq_base;
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V1 2/3] gpio/pca953x: increase variables size to support 24 bit of data
From: Leed Aguilar leed.agui...@ti.com
Increase variable size from u16 to u32 to allocate 24 bit of data required for
the TCA6424 I/O expander device type.
Signed-off-by: Leed Aguilar leed.agui...@ti.com
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/gpio/gpio-pca953x.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index af7024f..c3ca7d8 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -78,10 +78,10 @@ struct pca953x_chip {
#ifdef CONFIG_GPIO_PCA953X_IRQ
struct mutex irq_lock;
- uint16_t irq_mask;
- uint16_t irq_stat;
- uint16_t irq_trig_raise;
- uint16_t irq_trig_fall;
+ u32 irq_mask;
+ u32 irq_stat;
+ u32 irq_trig_raise;
+ u32 irq_trig_fall;
int irq_base;
#endif
@@ -349,8 +349,8 @@ static void pca953x_irq_bus_lock(struct irq_data *d)
static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
{
struct pca953x_chip *chip = irq_data_get_irq_chip_data(d);
- uint16_t new_irqs;
- uint16_t level;
+ u32 new_irqs;
+ u32 level;
/* Look for any newly setup interrupt */
new_irqs = chip-irq_trig_fall | chip-irq_trig_raise;
@@ -368,8 +368,8 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
static int pca953x_irq_set_type(struct irq_data *d, unsigned int type)
{
struct pca953x_chip *chip = irq_data_get_irq_chip_data(d);
- uint16_t level = d-irq - chip-irq_base;
- uint16_t mask = 1 level;
+ u32 level = d-irq - chip-irq_base;
+ u32 mask = 1 level;
if (!(type IRQ_TYPE_EDGE_BOTH)) {
dev_err(chip-client-dev, irq %d: unsupported type %d\n,
@@ -399,12 +399,12 @@ static struct irq_chip pca953x_irq_chip = {
.irq_set_type = pca953x_irq_set_type,
};
-static uint16_t pca953x_irq_pending(struct pca953x_chip *chip)
+static u32 pca953x_irq_pending(struct pca953x_chip *chip)
{
u32 cur_stat;
- uint16_t old_stat;
- uint16_t pending;
- uint16_t trigger;
+ u32 old_stat;
+ u32 pending;
+ u32 trigger;
int ret, offset = 0;
switch (chip-chip_type) {
@@ -440,8 +440,8 @@ static uint16_t pca953x_irq_pending(struct pca953x_chip
*chip)
static irqreturn_t pca953x_irq_handler(int irq, void *devid)
{
struct pca953x_chip *chip = devid;
- uint16_t pending;
- uint16_t level;
+ u32 pending;
+ u32 level;
pending = pca953x_irq_pending(chip);
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V1 3/3] OMAP: Define TCA6424 max number of possible IRQs
From: Leed Aguilar leed.agui...@ti.com TCA6424 being a 24 bit I2C and SMBus I/O expander has 24 available GPIO lines that can be used as IRQs lines. So, the support for 24 more IRQ lines has been added to the kernel. Signed-off-by: Leed Aguilar leed.agui...@ti.com Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com --- arch/arm/plat-omap/include/plat/irqs.h | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h index 37b..97c71ba 100644 --- a/arch/arm/plat-omap/include/plat/irqs.h +++ b/arch/arm/plat-omap/include/plat/irqs.h @@ -378,8 +378,17 @@ #endif #define OMAP_FPGA_IRQ_END (OMAP_FPGA_IRQ_BASE + OMAP_FPGA_NR_IRQS) +/* TCA6424A I2C and SMBus I/O expander */ +#define OMAP_TCA6424_IRQ_BASE (OMAP_FPGA_IRQ_END) +#ifdef CONFIG_GPIO_PCA953X +#define OMAP_TCA6424_NR_IRQS 24 +#else +#define OMAP_TCA6424_NR_IRQS 0 +#endif +#define OMAP_TCA6424_IRQ_END (OMAP_TCA6424_IRQ_BASE + OMAP_TCA6424_NR_IRQS) + /* External TWL4030 can handle interrupts on 2430 and 34xx boards */ -#defineTWL4030_IRQ_BASE(OMAP_FPGA_IRQ_END) +#defineTWL4030_IRQ_BASE(OMAP_TCA6424_IRQ_END) #ifdef CONFIG_TWL4030_CORE #defineTWL4030_BASE_NR_IRQS8 #defineTWL4030_PWR_NR_IRQS 8 -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 2/4 v3] mm: fix possible incorrect return value of migrate_pages() syscall
2012/7/28 Christoph Lameter c...@linux.com: On Sat, 28 Jul 2012, Joonsoo Kim wrote: do_migrate_pages() can return the number of pages not migrated. Because migrate_pages() syscall return this value directly, migrate_pages() syscall may return the number of pages not migrated. In fail case in migrate_pages() syscall, we should return error value. So change err to -EBUSY Lets leave this alone. This would change the migrate_pages semantics because a successful move of N out of M pages would be marked as a total failure although pages were in fact moved. Okay. Then, do we need to fix man-page of migrate_pages() syscall? According to man-page, only returning 0 or -1 is valid. Without this patch, it can return positive value. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 3/3] virtio-blk: Add bio-based IO path for virtio-blk
On 07/28/2012 04:21 AM, Asias He wrote: This patch introduces bio-based IO path for virtio-blk. Compared to request-based IO path, bio-based IO path uses driver provided -make_request_fn() method to bypasses the IO scheduler. It handles the bio to device directly without allocating a request in block layer. This reduces the IO path in guest kernel to achieve high IOPS and lower latency. The downside is that guest can not use the IO scheduler to merge and sort requests. However, this is not a big problem if the backend disk in host side uses faster disk device. When the bio-based IO path is not enabled, virtio-blk still uses the original request-based IO path, no performance difference is observed. Performance evaluation: - 1) Fio test is performed in a 8 vcpu guest with ramdisk based guest using kvm tool. Short version: With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%, 17%, 21%, 16% Long version: With bio-based IO path: seq-read : io=2048.0MB, bw=116996KB/s, iops=233991 , runt= 17925msec seq-write : io=2048.0MB, bw=100829KB/s, iops=201658 , runt= 20799msec rand-read : io=3095.7MB, bw=112134KB/s, iops=224268 , runt= 28269msec rand-write: io=3095.7MB, bw=96198KB/s, iops=192396 , runt= 32952msec clat (usec): min=0 , max=2631.6K, avg=58716.99, stdev=191377.30 clat (usec): min=0 , max=1753.2K, avg=66423.25, stdev=81774.35 clat (usec): min=0 , max=2915.5K, avg=61685.70, stdev=120598.39 clat (usec): min=0 , max=1933.4K, avg=76935.12, stdev=96603.45 cpu : usr=74.08%, sys=703.84%, ctx=29661403, majf=21354, minf=22460954 cpu : usr=70.92%, sys=702.81%, ctx=77219828, majf=13980, minf=27713137 cpu : usr=72.23%, sys=695.37%, ctx=88081059, majf=18475, minf=28177648 cpu : usr=69.69%, sys=654.13%, ctx=145476035, majf=15867, minf=26176375 With request-based IO path: seq-read : io=2048.0MB, bw=91074KB/s, iops=182147 , runt= 23027msec seq-write : io=2048.0MB, bw=80725KB/s, iops=161449 , runt= 25979msec rand-read : io=3095.7MB, bw=92106KB/s, iops=184211 , runt= 34416msec rand-write: io=3095.7MB, bw=82815KB/s, iops=165630 , runt= 38277msec clat (usec): min=0 , max=1932.4K, avg=77824.17, stdev=170339.49 clat (usec): min=0 , max=2510.2K, avg=78023.96, stdev=146949.15 clat (usec): min=0 , max=3037.2K, avg=74746.53, stdev=128498.27 clat (usec): min=0 , max=1363.4K, avg=89830.75, stdev=114279.68 cpu : usr=53.28%, sys=724.19%, ctx=37988895, majf=17531, minf=23577622 cpu : usr=49.03%, sys=633.20%, ctx=205935380, majf=18197, minf=27288959 cpu : usr=55.78%, sys=722.40%, ctx=101525058, majf=19273, minf=28067082 cpu : usr=56.55%, sys=690.83%, ctx=228205022, majf=18039, minf=26551985 2) Fio test is performed in a 8 vcpu guest with Fusion-IO based guest using kvm tool. Short version: With bio-based IO path, sequential read/write, random read/write IOPS boost : 11%, 11%, 13%, 10% Latency improvement: 10%, 10%, 12%, 10% Long Version: With bio-based IO path: read : io=2048.0MB, bw=58920KB/s, iops=117840 , runt= 35593msec write: io=2048.0MB, bw=64308KB/s, iops=128616 , runt= 32611msec read : io=3095.7MB, bw=59633KB/s, iops=119266 , runt= 53157msec write: io=3095.7MB, bw=62993KB/s, iops=125985 , runt= 50322msec clat (usec): min=0 , max=1284.3K, avg=128109.01, stdev=71513.29 clat (usec): min=94 , max=962339 , avg=116832.95, stdev=65836.80 clat (usec): min=0 , max=1846.6K, avg=128509.99, stdev=89575.07 clat (usec): min=0 , max=2256.4K, avg=121361.84, stdev=82747.25 cpu : usr=56.79%, sys=421.70%, ctx=147335118, majf=21080, minf=19852517 cpu : usr=61.81%, sys=455.53%, ctx=143269950, majf=16027, minf=24800604 cpu : usr=63.10%, sys=455.38%, ctx=178373538, majf=16958, minf=24822612 cpu : usr=62.04%, sys=453.58%, ctx=226902362, majf=16089, minf=23278105 With request-based IO path: read : io=2048.0MB, bw=52896KB/s, iops=105791 , runt= 39647msec write: io=2048.0MB, bw=57856KB/s, iops=115711 , runt= 36248msec read : io=3095.7MB, bw=52387KB/s, iops=104773 , runt= 60510msec write: io=3095.7MB, bw=57310KB/s, iops=114619 , runt= 55312msec clat (usec): min=0 , max=1532.6K, avg=142085.62, stdev=109196.84 clat (usec): min=0 , max=1487.4K, avg=129110.71, stdev=114973.64 clat (usec): min=0 , max=1388.6K, avg=145049.22, stdev=107232.55 clat (usec): min=0 , max=1465.9K, avg=133585.67, stdev=110322.95 cpu : usr=44.08%, sys=590.71%, ctx=451812322, majf=14841, minf=17648641 cpu : usr=48.73%, sys=610.78%, ctx=418953997, majf=22164, minf=26850689 cpu : usr=45.58%, sys=581.16%, ctx=714079216, majf=21497, minf=22558223 cpu : usr=48.40%, sys=599.65%, ctx=656089423, majf=16393, minf=23824409 What are the cases where we'll see a performance degradation with using the bio path? Could we measure performance for those as well? How
Re: [PATCH V3 3/3] virtio-blk: Add bio-based IO path for virtio-blk
I'm not sure what the correct behavior for bio cacheflush is, if any. REQ_FLUSH is not supported in the bio path. Ouch, that's correct: @@ -414,7 +529,7 @@ static void virtblk_update_cache_mode(struct virtio_device *vdev) u8 writeback = virtblk_get_cache_mode(vdev); struct virtio_blk *vblk = vdev-priv; - if (writeback) + if (writeback !use_bio) blk_queue_flush(vblk-disk-queue, REQ_FLUSH); else blk_queue_flush(vblk-disk-queue, 0); then it is not safe against power losses. Paolo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in kernel ( 3.4.x - 3.5rc )
hello again, bisect git gives ( after 13 steps) : 58bca4a8fa90fcf9069379653b396b2cec642f7f is the first bad commit Regards, Nicolas Prochazka 2012/7/24 Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com: On Mon, Jul 23, 2012 at 11:15:09PM +0200, nicolas prochazka wrote: Hello, I 'm trying differents versions with differents results - commit f044db4cb4bf16893812d35b5fbeaaf3e30c9215 : bug is not reproductible - 3.5rc7 : bug is reproductible(cf new dump ) - master branch : bug is reproductible Regards, Nicolas Prochazka Hi, Nicolas. Can you try a bisect? I am also copying David Howells and Bobby Powers, even though their set of patches don't seem to be the culprit. Regards. Cascardo. Jul 23 21:10:05 positronic18696 BUG: unable to handle kernel paging request at 0001002f Jul 23 21:10:05 positronic18696 IP: [81156900] dup_fd+0x160/0x2e0 Jul 23 21:10:05 positronic18696 PGD 6627ea067 PUD 0 Jul 23 21:10:05 positronic18696 Oops: 0002 [#1] SMP Jul 23 21:10:05 positronic18696 CPU 1 Jul 23 21:10:05 positronic18696 Modules linked in: kvm_intel kvm Jul 23 21:10:05 positronic18696 Jul 23 21:10:05 positronic18696 Pid: 17596, comm: queue.sh Not tainted 3.5.0-rc7-dirty #6 Dell Inc. PowerEdge M600/0MY736 Jul 23 21:10:05 positronic18696 RIP: 0010:[81156900] [81156900] dup_fd+0x160/0x2e0 Jul 23 21:10:05 positronic18696 RSP: 0018:880669ebdd90 EFLAGS: 00010206 Jul 23 21:10:05 positronic18696 RAX: 0038 RBX: 8807ed95eec0 RCX: 0007 Jul 23 21:10:05 positronic18696 RDX: RSI: 0800 RDI: 8805a4d01d40 Jul 23 21:10:05 positronic18696 RBP: 880669ebddf0 R08: 0020 R09: 81156694 Jul 23 21:10:05 positronic18696 R10: 0001 R11: R12: 8807ecf25000 Jul 23 21:10:05 positronic18696 R13: 8805a4d01d80 R14: 0100 R15: 8807d3a61800 Jul 23 21:10:05 positronic18696 FS: 7f1a8e719700() GS:88083fc4() knlGS: Jul 23 21:10:05 positronic18696 CS: 0010 DS: ES: CR0: 8005003b Jul 23 21:10:05 positronic18696 CR2: 0001002f CR3: 00066ef9 CR4: 27e0 Jul 23 21:10:05 positronic18696 DR0: 0001 DR1: 0002 DR2: 0001 Jul 23 21:10:05 positronic18696 DR3: 000a DR6: 0ff0 DR7: 0400 Jul 23 21:10:05 positronic18696 Process queue.sh (pid: 17596, threadinfo 880669ebc000, task 8806625ab000) Jul 23 21:10:05 positronic18696 Stack: Jul 23 21:10:05 positronic18696 880669ebdda0 00018102db49 0020 8806627ee8c0 Jul 23 21:10:05 positronic18696 8807eefc1608 8807eefc1680 7f1a8e7199d0 8807bf41d000 Jul 23 21:10:05 positronic18696 01200011 7f1a8e7199d0 Jul 23 21:10:05 positronic18696 Call Trace: Jul 23 21:10:05 positronic18696 [81040441] copy_process+0x931/0x13c0 Jul 23 21:10:05 positronic18696 [81041024] do_fork+0x54/0x360 Jul 23 21:10:05 positronic18696 [81ac3b7e] ? _raw_spin_lock+0xe/0x20 Jul 23 21:10:05 positronic18696 [810559e7] ? __set_task_blocked+0x37/0x80 Jul 23 21:10:05 positronic18696 [81055a83] ? __set_current_blocked+0x53/0x70 Jul 23 21:10:05 positronic18696 [8100c098] sys_clone+0x28/0x30 Jul 23 21:10:05 positronic18696 [81ac4bb3] stub_clone+0x13/0x20 Jul 23 21:10:05 positronic18696 [81ac4929] ? system_call_fastpath+0x16/0x1b Jul 23 21:10:05 positronic18696 Code: 8b 45 b0 49 8b 7d 10 48 8b 71 10 4c 89 c2 e8 08 82 23 00 45 85 f6 74 54 41 8d 46 ff 31 c9 48 8d 34 c5 08 00 00 00 31 c0 eb 15 90 f0 48 ff 42 30 49 89 14 04 ff c1 48 83 c0 08 48 39 f0 74 24 49 Jul 23 21:10:05 positronic18696 RIP [81156900] dup_fd+0x160/0x2e0 Jul 23 21:10:05 positronic18696 RSP 880669ebdd90 Jul 23 21:10:05 positronic18696 CR2: 0001002f Jul 23 21:10:05 positronic18696 ---[ end trace ccf5b66c39d92756 ]--- Jul 23 21:10:05 positronic18696 device vmtap35 left promiscuous mode Jul 23 21:10:05 positronic18696 device vmEtap35 left promiscuous mode Jul 23 21:10:05 positronic18696 device vmtap36 left promiscuous mode Jul 23 21:10:05 positronic18696 device vmEtap36 left promiscuous mode Jul 23 21:10:05 positronic18696 device vmtap37 left promiscuous mode Jul 23 21:10:05 positronic18696 device vmEtap37 left promiscuous mode Jul 23 21:10:05 positronic18696 device vmtap38 left promiscuous mode Jul 23 21:10:05 positronic18696 device vmEtap38 left promiscuous mode Jul 23 21:10:05 positronic18696 BUG: unable to handle kernel paging request at 0001003b Jul 23 21:10:05 positronic18696 IP: [8119f684] tid_fd_revalidate+0x84/0x1a0 Jul 23 21:10:05 positronic18696 PGD 598c9e067 PUD 0 Jul 23 21:10:05 positronic18696 Oops: [#2] SMP Jul 23 21:10:05 positronic18696 CPU 0 Jul 23 21:10:05 positronic18696
[GIT] Networking
Several bug fixes, some to new features appearing in this merge window, some that have been around for a while. I have a short list of known problems that need to be sorted out, but all of them can be solved easily during the run up to 3.6-final. I'll be offline until Sunday afternoon, but nothing need hold up 3.6-rc1 and the close of the merge window, networking wise, at this point. 1) Fix interface check in ipv4 TCP early demux, from Eric Dumazet. 2) Fix a long standing bug in TCP DMA to userspace offload that can hang applications using MSG_TRUNC, from Jiri Kosina. 3) Don't allow TCP_USER_TIMEOUT to be negative, from Hangbin Liu. 4) Don't use GFP_KERNEL under spinlock in kaweth driver, from Dan Carpenter Please pull, thanks a lot. The following changes since commit b387e41e523c1aa347cff055455d0dd129357df4: Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-07-27 08:35:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to 7b9b04fb728ec0b94464ed902f3395aa592c5bcf: Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2012-07-27 14:25:40 -0700) Dan Carpenter (1): USB: kaweth.c: use GFP_ATOMIC under spin_lock David S. Miller (1): Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless Eric Dumazet (1): ipv4: fix TCP early demux Hangbin Liu (1): tcp: Add TCP_USER_TIMEOUT negative value check Hauke Mehrtens (2): bcma: fix regression in interrupt assignment on mips bcma: add missing iounmap on error path Jesse Gross (1): Revert openvswitch: potential NULL deref in sample() Jiri Benc (1): net: fix rtnetlink IFF_PROMISC and IFF_ALLMULTI handling Jiri Kosina (1): tcp: perform DMA to userspace only if there is a task waiting for it John W. Linville (1): Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem Thomas Huehn (1): mac80211_hwsim: fix possible race condition in usage of info-control.sta control.vif drivers/bcma/driver_mips.c| 6 +++--- drivers/bcma/scan.c | 15 ++- drivers/net/usb/kaweth.c | 2 +- drivers/net/wireless/mac80211_hwsim.c | 5 - net/core/rtnetlink.c | 8 +++- net/ipv4/tcp.c| 5 - net/ipv4/tcp_input.c | 5 - net/ipv4/tcp_ipv4.c | 14 ++ net/ipv4/tcp_minisocks.c | 1 + net/openvswitch/actions.c | 3 --- 10 files changed, 36 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] dynamic_debug: Restore dev_dbg functionality, optimize stack
commit c4e00daaa9 (driver-core: extend dev_printk() to pass structured data)
changed __dev_printk and broke dynamic-debug's ability to control the
dynamic prefix of dev_dbg(dev,..).
dynamic_emit_prefix() adds [tid] module:func:line: to the output and
those additions got lost.
In addition, the current dynamic debug code uses up to 3 recursion
levels via %pV. This can consume quite a bit of stack. Directly
call printk_emit to reduce the recursion depth.
These changes include:
o Remove KERN_DEBUG from dynamic_emit_prefix
o Create and use function create_syslog_header to format the syslog
header for printk_emit uses.
o Call create_syslog_header and neaten __dev_printk
o Call create_syslog_header and printk_emit from dynamic_dev_dbg
o Call create_syslog_header and printk_emit from dynamic_netdev_dbg
o Make __dev_printk and __netdev_printk static not global
o Remove include header declarations of __dev_printk and __netdev_printk
o Remove now unused EXPORT_SYMBOL()s of __dev_printk and __netdev_printk
o Whitespace neatening
Changes in v2:
o Fix dynamic_emit_prefix to always initialize output
o Call create_syslog_header and emit_printk from__netdev_printk and
eliminate call to dev_printk to remove another recursion via %pV
Signed-off-by: Joe Perches j...@perches.com
---
drivers/base/core.c | 57 +++
include/linux/device.h| 11 +++-
include/linux/netdevice.h |3 --
lib/dynamic_debug.c | 65 -
net/core/dev.c| 24 -
5 files changed, 106 insertions(+), 54 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index f338037..d46b635 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1861,25 +1861,19 @@ void device_shutdown(void)
*/
#ifdef CONFIG_PRINTK
-int __dev_printk(const char *level, const struct device *dev,
-struct va_format *vaf)
+int create_syslog_header(const struct device *dev, char *hdr, size_t hdrlen)
{
- char dict[128];
- size_t dictlen = 0;
const char *subsys;
-
- if (!dev)
- return printk(%s(NULL device *): %pV, level, vaf);
+ size_t pos = 0;
if (dev-class)
subsys = dev-class-name;
else if (dev-bus)
subsys = dev-bus-name;
else
- goto skip;
+ return 0;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- SUBSYSTEM=%s, subsys);
+ pos += snprintf(hdr + pos, hdrlen - pos, SUBSYSTEM=%s, subsys);
/*
* Add device identifier DEVICE=:
@@ -1895,28 +1889,41 @@ int __dev_printk(const char *level, const struct device
*dev,
c = 'b';
else
c = 'c';
- dictlen++;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- DEVICE=%c%u:%u,
- c, MAJOR(dev-devt), MINOR(dev-devt));
+ pos++;
+ pos += snprintf(hdr + pos, hdrlen - pos,
+ DEVICE=%c%u:%u,
+ c, MAJOR(dev-devt), MINOR(dev-devt));
} else if (strcmp(subsys, net) == 0) {
struct net_device *net = to_net_dev(dev);
- dictlen++;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- DEVICE=n%u, net-ifindex);
+ pos++;
+ pos += snprintf(hdr + pos, hdrlen - pos,
+ DEVICE=n%u, net-ifindex);
} else {
- dictlen++;
- dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
- DEVICE=+%s:%s, subsys, dev_name(dev));
+ pos++;
+ pos += snprintf(hdr + pos, hdrlen - pos,
+ DEVICE=+%s:%s, subsys, dev_name(dev));
}
-skip:
- return printk_emit(0, level[1] - '0',
- dictlen ? dict : NULL, dictlen,
+
+ return pos;
+}
+EXPORT_SYMBOL(create_syslog_header);
+
+static int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf)
+{
+ char hdr[128];
+ size_t hdrlen;
+
+ if (!dev)
+ return printk(%s(NULL device *): %pV, level, vaf);
+
+ hdrlen = create_syslog_header(dev, hdr, sizeof(hdr));
+
+ return printk_emit(0, level[1] - '0', hdrlen ? hdr : NULL, hdrlen,
%s %s: %pV,
dev_driver_string(dev), dev_name(dev), vaf);
}
-EXPORT_SYMBOL(__dev_printk);
int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
@@ -1931,6 +1938,7 @@ int dev_printk(const char *level, const struct device
*dev,
vaf.va = args;
r = __dev_printk(level, dev,
Re: [PATCH] debug: Do not permit CONFIG_DEBUG_STACK_USAGE=y on IA64 or PARISC
On Wed, 2012-07-18 at 10:35 -0700, Tony Luck wrote: The stack_not_used() function in linux/sched.h assumes that stacks grow downwards. This is not true on IA64 or PARISC, so this function would walk off in the wrong direction and into the weeds. OK, so looking at all of this, that statement's not quite true ... at least for parisc, we begin the stack where end_of_stack() says the end should be and so the walker will likely find the next word after the canary skip occupied and terminate there, so we think the stack is larger than it really is. It gets the wrong value, but it will never even walk out of the stack area. Found on IA64 because of a compilation failure with recursive dependencies on IA64_TASKSIZE and IA64_THREAD_INFO_SIZE. Fixing the code is possible, but should be combined with other infrastructure additions to set up the canary at the end of the stack. I agree with this. Most of it looks easily fixable, but how would I enable the fix for ia64? For PA it's simple: I'll just use CONFIG_STACK_GROWSUP, but that won't work for you. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: RAID extremely slow
On 07/27/2012 09:45 PM, Grant Coady wrote:
On Fri, 27 Jul 2012 14:45:18 -0700, you wrote:
On 07/27/2012 12:08 PM, Bill Davidsen wrote:
Have you set the io scheduler to deadline on all members of the array?
That's kind of job one on older kernels.
I have not, thanks for the tip, I'll look into that now.
Plus I disable the on-drive queuing (NCQ) during startup, right now
I don't have benchmarks to show the difference. This on a six by 1TB
drive RAID6 array I built over a year ago on Slackware64-13.37:
# cat /etc/rc.d/rc.local
...
# turn off NCQ on the RAID drives by adjusting queue depth to 1
n=1
echo rc.local: Disable RAID drives' NCQ
for d in a b c d e f
do
echo set NCQ depth to $n on sd${d}
echo $n /sys/block/sd${d}/device/queue_depth
done
...
Maybe you could try that? See if it makes a difference. My drives
are Seagate.
Grant.
Does disabling NCQ improve performance?
The suggestion to use kernel 3.4.6 has been working quite well so far,
hopefully that fixes the problem. I'll know for sure in a few more days...
Thanks!
-- Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] ueagle-atm: Declare MODULE_FIRMWARE usage
Ack-by: matthieu castet castet.matth...@free.fr
Le Wed, 25 Jul 2012 14:32:50 -0600,
Tim Gardner tim.gard...@canonical.com a écrit :
Cc: Matthieu CASTET castet.matth...@free.fr
Cc: Stanislaw Gruszka stf...@wp.pl
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/usb/atm/ueagle-atm.c | 79
+++--- 1 file changed, 66
insertions(+), 13 deletions(-)
diff --git a/drivers/usb/atm/ueagle-atm.c
b/drivers/usb/atm/ueagle-atm.c index d7e422d..e1f8b2c 100644
--- a/drivers/usb/atm/ueagle-atm.c
+++ b/drivers/usb/atm/ueagle-atm.c
@@ -307,6 +307,34 @@ enum {
#define FW_GET_BYTE(p) (*((__u8 *) (p)))
#define FW_DIR ueagle-atm/
+#define EAGLE_FIRMWARE FW_DIR eagle.fw
+#define ADI930_FIRMWARE FW_DIR adi930.fw
+#define EAGLE_I_FIRMWARE FW_DIR eagleI.fw
+#define EAGLE_II_FIRMWARE FW_DIR eagleII.fw
+#define EAGLE_III_FIRMWARE FW_DIR eagleIII.fw
+#define EAGLE_IV_FIRMWARE FW_DIR eagleIV.fw
+
+#define DSP4I_FIRMWARE FW_DIR DSP4i.bin
+#define DSP4P_FIRMWARE FW_DIR DSP4p.bin
+#define DSP9I_FIRMWARE FW_DIR DSP9i.bin
+#define DSP9P_FIRMWARE FW_DIR DSP9p.bin
+#define DSPEI_FIRMWARE FW_DIR DSPei.bin
+#define DSPEP_FIRMWARE FW_DIR DSPep.bin
+#define FPGA930_FIRMWARE FW_DIR 930-fpga.bin
+
+#define CMV4P_FIRMWARE FW_DIR CMV4p.bin
+#define CMV4PV2_FIRMWARE FW_DIR CMV4p.bin.v2
+#define CMV4I_FIRMWARE FW_DIR CMV4i.bin
+#define CMV4IV2_FIRMWARE FW_DIR CMV4i.bin.v2
+#define CMV9P_FIRMWARE FW_DIR CMV9p.bin
+#define CMV9PV2_FIRMWARE FW_DIR CMV9p.bin.v2
+#define CMV9I_FIRMWARE FW_DIR CMV9i.bin
+#define CMV9IV2_FIRMWARE FW_DIR CMV9i.bin.v2
+#define CMVEP_FIRMWARE FW_DIR CMVep.bin
+#define CMVEPV2_FIRMWARE FW_DIR CMVep.bin.v2
+#define CMVEI_FIRMWARE FW_DIR CMVei.bin
+#define CMVEIV2_FIRMWARE FW_DIR CMVei.bin.v2
+
#define UEA_FW_NAME_MAX 30
#define NB_MODEM 4
@@ -694,26 +722,26 @@ err:
static int uea_load_firmware(struct usb_device *usb, unsigned int
ver) {
int ret;
- char *fw_name = FW_DIR eagle.fw;
+ char *fw_name = EAGLE_FIRMWARE;
uea_enters(usb);
uea_info(usb, pre-firmware device, uploading firmware\n);
switch (ver) {
case ADI930:
- fw_name = FW_DIR adi930.fw;
+ fw_name = ADI930_FIRMWARE;
break;
case EAGLE_I:
- fw_name = FW_DIR eagleI.fw;
+ fw_name = EAGLE_I_FIRMWARE;
break;
case EAGLE_II:
- fw_name = FW_DIR eagleII.fw;
+ fw_name = EAGLE_II_FIRMWARE;
break;
case EAGLE_III:
- fw_name = FW_DIR eagleIII.fw;
+ fw_name = EAGLE_III_FIRMWARE;
break;
case EAGLE_IV:
- fw_name = FW_DIR eagleIV.fw;
+ fw_name = EAGLE_IV_FIRMWARE;
break;
}
@@ -869,19 +897,19 @@ static int request_dsp(struct uea_softc *sc)
if (UEA_CHIP_VERSION(sc) == EAGLE_IV) {
if (IS_ISDN(sc))
- dsp_name = FW_DIR DSP4i.bin;
+ dsp_name = DSP4I_FIRMWARE;
else
- dsp_name = FW_DIR DSP4p.bin;
+ dsp_name = DSP4P_FIRMWARE;
} else if (UEA_CHIP_VERSION(sc) == ADI930) {
if (IS_ISDN(sc))
- dsp_name = FW_DIR DSP9i.bin;
+ dsp_name = DSP9I_FIRMWARE;
else
- dsp_name = FW_DIR DSP9p.bin;
+ dsp_name = DSP9P_FIRMWARE;
} else {
if (IS_ISDN(sc))
- dsp_name = FW_DIR DSPei.bin;
+ dsp_name = DSPEI_FIRMWARE;
else
- dsp_name = FW_DIR DSPep.bin;
+ dsp_name = DSPEP_FIRMWARE;
}
ret = request_firmware(sc-dsp_firm, dsp_name,
sc-usb_dev-dev); @@ -1925,7 +1953,7 @@ static int
load_XILINX_firmware(struct uea_softc *sc) int ret, size, u, ln;
const u8 *pfw;
u8 value;
- char *fw_name = FW_DIR 930-fpga.bin;
+ char *fw_name = FPGA930_FIRMWARE;
uea_enters(INS_TO_USBDEV(sc));
@@ -2753,3 +2781,28 @@ module_usb_driver(uea_driver);
MODULE_AUTHOR(Damien Bergamini/Matthieu Castet/Stanislaw W.
Gruszka); MODULE_DESCRIPTION(ADI 930/Eagle USB ADSL Modem driver);
MODULE_LICENSE(Dual BSD/GPL);
+MODULE_FIRMWARE(EAGLE_FIRMWARE);
+MODULE_FIRMWARE(ADI930_FIRMWARE);
+MODULE_FIRMWARE(EAGLE_I_FIRMWARE);
+MODULE_FIRMWARE(EAGLE_II_FIRMWARE);
+MODULE_FIRMWARE(EAGLE_III_FIRMWARE);
+MODULE_FIRMWARE(EAGLE_IV_FIRMWARE);
+MODULE_FIRMWARE(DSP4I_FIRMWARE);
+MODULE_FIRMWARE(DSP4P_FIRMWARE);
+MODULE_FIRMWARE(DSP9I_FIRMWARE);
+MODULE_FIRMWARE(DSP9P_FIRMWARE);
+MODULE_FIRMWARE(DSPEI_FIRMWARE);
+MODULE_FIRMWARE(DSPEP_FIRMWARE);
+MODULE_FIRMWARE(FPGA930_FIRMWARE);
+MODULE_FIRMWARE(CMV4P_FIRMWARE);
+MODULE_FIRMWARE(CMV4PV2_FIRMWARE);
Re: [RFC ebeam PATCH 3/3] input: misc: New USB eBeam input driver.
Hi Dmitry, +config INPUT_EBEAM_USB_CLASSIC +bool eBeam Classic Projection support +depends on INPUT_EBEAM_USB +default y Will there be support for other eBean devices (are there any)? If there will how soon? How different are they? If not the we probably do not need this INPUT_EBEAM_USB_CLASSIC selector. I know at least one re-branded same hardware by 3M, i will be able to borrow one in a month or so. According to the wikipedia article, there's probably more. There's also newer models and embeded ones in some video projector setup, also re-branded, based on the same technology and that might use the same type of protocol, but i can't be sure until someone can inspect them. These pieces of hardware are quite expensive, and mostly used in educational or corporate, they are not easy to grab. The code structure (device selector + functions indirection) also seems overkill to me for now, but permit to anticipate device's variations. If it appears that they all works in the same way, it'll be easy (and more comfortable to me) to step down, the opposite seems more difficult. +#define DEBUG I do not think leaving DEBUG on is good idea for production code. Cinder, cleaned. +/* until KConfig */ +#define CONFIG_INPUT_EBEAM_USB_CLASSIC Huh? I test the module against my running kernel, building out of tree, and don't know how to define that in the makefile. This will be cleaned in final step. +bool irq_always; Does you device need this? Part of overkill foresight. +/* optional, model-specific */ +int (*alloc) (struct ebeam_device *ebeam); +int (*init)(struct ebeam_device *ebeam); +void (*exit)(struct ebeam_device *ebeam); Again, do you expect to see multitude of sufficiently different devices or are they going to follow roughly the same protocol? ditto. -- Yann Cantin A4FEB47F -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] MIPS: fix tc_id calculation
Any advice 2012/7/2 roy.qing...@gmail.com: From: RongQing.Li roy.qing...@gmail.com Now the tc_id is: (read_c0_tcbind() TCBIND_CURTC_SHIFT) TCBIND_CURTC; After substitute macro: (read_c0_tcbind() 21) ((0xff) 21) It should be: (read_c0_tcbind() ((0xff) 21)) 21 Signed-off-by: RongQing.Li roy.qing...@gmail.com --- arch/mips/kernel/smp-cmp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/mips/kernel/smp-cmp.c b/arch/mips/kernel/smp-cmp.c index e7e03ec..afc379c 100644 --- a/arch/mips/kernel/smp-cmp.c +++ b/arch/mips/kernel/smp-cmp.c @@ -102,7 +102,7 @@ static void cmp_init_secondary(void) c-vpe_id = (read_c0_tcbind() TCBIND_CURVPE_SHIFT) TCBIND_CURVPE; #endif #ifdef CONFIG_MIPS_MT_SMTC - c-tc_id = (read_c0_tcbind() TCBIND_CURTC_SHIFT) TCBIND_CURTC; + c-tc_id = (read_c0_tcbind() TCBIND_CURTC) TCBIND_CURTC_SHIFT; #endif } -- 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: [ 39/40] cpuset: mm: reduce large amounts of memory barrier related damage v3
On Sat, Jul 28, 2012 at 02:02:31AM -0300, Herton Ronaldo Krzesinski wrote:
Thanks, I've merged this with the original in the tree, so all should
be good now.
Thanks. I saw what seems another issue now on the patch too, sorry for
not noticing earlier: this backport is lacking the
write_seqcount_{begin,end} on set_mems_allowed for the case with
CONFIG_CPUSETS, like in the original patch:
Not my finest moment :(
Thanks
---8---
cpuset: mm: reduce large amounts of memory barrier related damage v3 fix
Missing hunk from backport.
Reported-by: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com
Signed-off-by: Mel Gorman mgor...@suse.de
diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index 8f15695..7a7e5fd 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -113,7 +113,9 @@ static inline bool put_mems_allowed(unsigned int seq)
static inline void set_mems_allowed(nodemask_t nodemask)
{
task_lock(current);
+ write_seqcount_begin(current-mems_allowed_seq);
current-mems_allowed = nodemask;
+ write_seqcount_end(current-mems_allowed_seq);
task_unlock(current);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Bisected] commit 71574865 (vfs: do_last(): common slow lookup) breaks CUPS printing
Printing with CUPS is broken on the current git tree. Whenever I print a page the job just sits in the CUPS queue showing processing. But it never reaches the printer. (My CUPS version is 1.5.2. Filesystem is xfs.) I've bisected this issue to: commit 7157486541bffc0dfec912e21ae639b029dae3d3 Author: Miklos Szeredi mszer...@suse.cz Date: Tue Jun 5 15:10:14 2012 +0200 vfs: do_last(): common slow lookup Make the slow lookup part of O_CREAT and non-O_CREAT opens common. This allows atomic_open to be hooked into the slow lookup part. Signed-off-by: Miklos Szeredi mszer...@suse.cz Signed-off-by: Al Viro v...@zeniv.linux.org.uk ` -- Markus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net:appletalk:ddp:fixed some codystyle issues in
Fixed coding style issues relating to indentation found in
net/appletalkddp.c.git diff -w is empty and the compiled objects
are the same too.
Signed-off-by: Jeffrin Jose ahiliat...@yahoo.co.in
---
net/appletalk/ddp.c | 212 +--
1 file changed, 106 insertions(+), 106 deletions(-)
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index c8bbcd2..19b7058 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -337,7 +337,7 @@ static int atif_proxy_probe_device(struct atalk_iface *atif,
return -EADDRINUSE; /* Network is full... */
}
-
+
struct atalk_addr *atalk_find_dev_addr(struct net_device *dev)
{
@@ -685,26 +685,26 @@ static int atif_ioctl(int cmd, void __user *arg)
switch (cmd) {
case SIOCSIFADDR:
- if (!capable(CAP_NET_ADMIN))
+ if (!capable(CAP_NET_ADMIN))
return -EPERM;
- if (sa-sat_family != AF_APPLETALK)
+ if (sa-sat_family != AF_APPLETALK)
return -EINVAL;
- if (dev-type != ARPHRD_ETHER
- dev-type != ARPHRD_LOOPBACK
- dev-type != ARPHRD_LOCALTLK
- dev-type != ARPHRD_PPP)
+ if (dev-type != ARPHRD_ETHER
+ dev-type != ARPHRD_LOOPBACK
+ dev-type != ARPHRD_LOCALTLK
+ dev-type != ARPHRD_PPP)
return -EPROTONOSUPPORT;
- nr = (struct atalk_netrange *)sa-sat_zero[0];
- add_route = 1;
+ nr = (struct atalk_netrange *)sa-sat_zero[0];
+ add_route = 1;
- /*
-* if this is a point-to-point iface, and we already
-* have an iface for this AppleTalk address, then we
-* should not add a route
-*/
- if ((dev-flags IFF_POINTOPOINT)
- atalk_find_interface(sa-sat_addr.s_net,
+ /*
+* if this is a point-to-point iface, and we already
+* have an iface for this AppleTalk address, then we
+* should not add a route
+*/
+ if ((dev-flags IFF_POINTOPOINT)
+ atalk_find_interface(sa-sat_addr.s_net,
sa-sat_addr.s_node)) {
printk(KERN_DEBUG AppleTalk: point-to-point
interface added with
@@ -712,16 +712,16 @@ static int atif_ioctl(int cmd, void __user *arg)
add_route = 0;
}
- /*
-* Phase 1 is fine on LocalTalk but we don't do
-* EtherTalk phase 1. Anyone wanting to add it go ahead.
-*/
- if (dev-type == ARPHRD_ETHER nr-nr_phase != 2)
+ /*
+* Phase 1 is fine on LocalTalk but we don't do
+* EtherTalk phase 1. Anyone wanting to add it go ahead.
+*/
+ if (dev-type == ARPHRD_ETHER nr-nr_phase != 2)
return -EPROTONOSUPPORT;
- if (sa-sat_addr.s_node == ATADDR_BCAST ||
- sa-sat_addr.s_node == 254)
+ if (sa-sat_addr.s_node == ATADDR_BCAST ||
+sa-sat_addr.s_node == 254)
return -EINVAL;
- if (atif) {
+ if (atif) {
/* Already setting address */
if (atif-status ATIF_PROBE)
return -EBUSY;
@@ -734,36 +734,36 @@ static int atif_ioctl(int cmd, void __user *arg)
if (!atif)
return -ENOMEM;
}
- atif-nets = *nr;
+ atif-nets = *nr;
- /*
-* Check if the chosen address is used. If so we
-* error and atalkd will try another.
-*/
+ /*
+* Check if the chosen address is used. If so we
+* error and atalkd will try another.
+*/
- if (!(dev-flags IFF_LOOPBACK)
- !(dev-flags IFF_POINTOPOINT)
- atif_probe_device(atif) 0) {
- atif_drop_device(dev);
+ if (!(dev-flags IFF_LOOPBACK)
+ !(dev-flags IFF_POINTOPOINT)
+atif_probe_device(atif) 0) {
+ atif_drop_device(dev);
return -EADDRINUSE;
}
- /* Hey it worked - add the direct routes */
- sa =
