twitter: linux.kernel - 26 new messages in 17 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* ARM: NUC900: add RTC driver support for nuc910 and nuc920 - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/e42ffeab69ba69f3?hl=en
* What are the goals for the architecture of an in-kernel IR system? - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/344640f275ed964e?hl=en
* change PCI nomenclature according to PCI-SIG - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d3dcc3e136af839d?hl=en
* linux-next: manual merge of the osd tree with the scsi tree - 4 messages, 3
authors
http://groups.google.com/group/linux.kernel/t/ea261026d7d3cccc?hl=en
* Documentation: Fix a stale reference in Documentation/DMA-API.txt - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/babcd28e1f502f70?hl=en
* f83f9ac causes tasks running at MAX_PRIO - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0eff970fb6e1b0a8?hl=en
* 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f
07' - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/ada9fa2d2574a8af?hl=en
* core: fix user return notifier on fork() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f9483907bf475210?hl=en
* kernel bug in kvm_intel - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/84fd49ee3f662811?hl=en
* intermittent suspend problem again - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/35666d4e4ef5d9a0?hl=en
* NET: smc91x: convert to dev_pm_ops - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5325dfb677ab5327?hl=en
* warn about shared irqs requesting IRQF_DISABLED registered with setup_irq -
2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d11d78e6a54aeec1?hl=en
* cfq: Disable low_latency by default for 2.6.32 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3456128c4e0f9e69?hl=en
* [RFC] tracepoint: signal coredump (Re: [PATCH v2] mm: Introduce coredump
parameter structure) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4fb1a5685ed26a12?hl=en
* sched: Optimize branch hint in context_switch() - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/dbe47e70d4842c64?hl=en
* PROBLEM: BUG: Constant freezes and kernel panics on a quad core (with dumps)
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2531c6491232a3e1?hl=en
* [PATCH 3/12] PCI / PM: Propagate wake-up enable for PCIe devices too - 2
messages, 1 author
http://groups.google.com/group/linux.kernel/t/f8580ff2ef7e84b8?hl=en

==============================================================================
TOPIC: ARM: NUC900: add RTC driver support for nuc910 and nuc920
http://groups.google.com/group/linux.kernel/t/e42ffeab69ba69f3?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Nov 29 2009 4:40 am
From: Wan ZongShun

Dear Alessandro,

I fixed this patch and submitted it again.

thanks!

signed-off-by: Wan ZongShun <mcuos.com@gmail.com>

---
drivers/rtc/Kconfig | 6 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-nuc900.c | 331 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 338 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-nuc900.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 3c20dae..266ce62 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -573,6 +573,12 @@ config RTC_DRV_AB3100
Select this to enable the ST-Ericsson AB3100 Mixed Signal IC RTC
support. This chip contains a battery- and capacitor-backed RTC.

+config RTC_DRV_NUC900
+ tristate "NUC910/NUC920 RTC driver"
+ depends on RTC_CLASS && ARCH_W90X900
+ help
+ If you say yes here you get support for the RTC subsystem of the
+ NUC910/NUC920 used in embedded systems.

comment "on-CPU RTC drivers"

diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index aa3fbd5..d511774 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_RTC_MXC) += rtc-mxc.o
obj-$(CONFIG_RTC_DRV_MAX6900) += rtc-max6900.o
obj-$(CONFIG_RTC_DRV_MAX6902) += rtc-max6902.o
obj-$(CONFIG_RTC_DRV_MV) += rtc-mv.o
+obj-$(CONFIG_RTC_DRV_NUC900) += rtc-nuc900.o
obj-$(CONFIG_RTC_DRV_OMAP) += rtc-omap.o
obj-$(CONFIG_RTC_DRV_PCAP) += rtc-pcap.o
obj-$(CONFIG_RTC_DRV_PCF8563) += rtc-pcf8563.o
diff --git a/drivers/rtc/rtc-nuc900.c b/drivers/rtc/rtc-nuc900.c
new file mode 100644
index 0000000..6002309
--- /dev/null
+++ b/drivers/rtc/rtc-nuc900.c
@@ -0,0 +1,331 @@
+/*
+ * Copyright (c) 2008-2009 Nuvoton technology corporation.
+ *
+ * Wan ZongShun <mcuos.com@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation;version 2 of the License.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/bcd.h>
+
+/* RTC Control Registers */
+#define REG_RTC_INIR 0x00
+#define REG_RTC_AER 0x04
+#define REG_RTC_FCR 0x08
+#define REG_RTC_TLR 0x0C
+#define REG_RTC_CLR 0x10
+#define REG_RTC_TSSR 0x14
+#define REG_RTC_DWR 0x18
+#define REG_RTC_TAR 0x1C
+#define REG_RTC_CAR 0x20
+#define REG_RTC_LIR 0x24
+#define REG_RTC_RIER 0x28
+#define REG_RTC_RIIR 0x2C
+#define REG_RTC_TTR 0x30
+
+#define RTCSET 0x01
+#define AERRWENB 0x10000
+#define INIRRESET 0xa5eb1357
+#define AERPOWERON 0xA965
+#define AERPOWEROFF 0x0000
+#define LEAPYEAR 0x0001
+#define TICKENB 0x80
+#define TICKINTENB 0x0002
+#define ALARMINTENB 0x0001
+#define MODE24 0x0001
+
+struct nuc900_rtc {
+ int irq_num;
+ void __iomem *rtc_reg;
+ struct rtc_device *rtcdev;
+};
+
+struct nuc900_bcd_time {
+ int bcd_sec;
+ int bcd_min;
+ int bcd_hour;
+ int bcd_mday;
+ int bcd_mon;
+ int bcd_year;
+};
+
+static irqreturn_t nuc900_rtc_interrupt(int irq, void *_rtc)
+{
+ struct nuc900_rtc *rtc = _rtc;
+ unsigned long events = 0, rtc_irq;
+
+ rtc_irq = __raw_readl(rtc->rtc_reg + REG_RTC_RIIR);
+
+ if (rtc_irq & ALARMINTENB) {
+ rtc_irq &= ~ALARMINTENB;
+ __raw_writel(rtc_irq, rtc->rtc_reg + REG_RTC_RIIR);
+ events |= RTC_AF | RTC_IRQF;
+ }
+
+ if (rtc_irq & TICKINTENB) {
+ rtc_irq &= ~TICKINTENB;
+ __raw_writel(rtc_irq, rtc->rtc_reg + REG_RTC_RIIR);
+ events |= RTC_UF | RTC_IRQF;
+ }
+
+ rtc_update_irq(rtc->rtcdev, 1, events);
+
+ return IRQ_HANDLED;
+}
+
+static void check_rtc_power(struct nuc900_rtc *nuc900_rtc)
+{
+ unsigned int i;
+ __raw_writel(INIRRESET, nuc900_rtc->rtc_reg + REG_RTC_INIR);
+
+ mdelay(10);
+
+ __raw_writel(AERPOWERON, nuc900_rtc->rtc_reg + REG_RTC_AER);
+
+ for (i = 0; i < 1000000; i++) {
+ if (__raw_readl(nuc900_rtc->rtc_reg + REG_RTC_AER) & AERRWENB)
+ break;
+ }
+}
+
+static void nuc900_rtc_bcd2bin(unsigned int timereg,
+ unsigned int calreg, struct rtc_time *tm)
+{
+ tm->tm_mday = bcd2bin(calreg >> 0);
+ tm->tm_mon = bcd2bin(calreg >> 8);
+ tm->tm_year = bcd2bin(calreg >> 16) + 100;
+
+ tm->tm_sec = bcd2bin(timereg >> 0);
+ tm->tm_min = bcd2bin(timereg >> 8);
+ tm->tm_hour = bcd2bin(timereg >> 16);
+
+ rtc_valid_tm(tm);
+}
+
+static void nuc900_rtc_bin2bcd(struct rtc_time *settm,
+ struct nuc900_bcd_time *gettm)
+{
+ gettm->bcd_mday = bin2bcd(settm->tm_mday) << 0;
+ gettm->bcd_mon = bin2bcd(settm->tm_mon) << 8;
+ gettm->bcd_year = bin2bcd(settm->tm_year - 100) << 16;
+
+ gettm->bcd_sec = bin2bcd(settm->tm_sec) << 0;
+ gettm->bcd_min = bin2bcd(settm->tm_min) << 8;
+ gettm->bcd_hour = bin2bcd(settm->tm_hour) << 16;
+}
+
+static int nuc900_update_irq_enable(struct device *dev, unsigned int enabled)
+{
+ struct nuc900_rtc *rtc = dev_get_drvdata(dev);
+
+ if (enabled)
+ __raw_writel(__raw_readl(rtc->rtc_reg + REG_RTC_RIER)|
+ (TICKINTENB), rtc->rtc_reg + REG_RTC_RIER);
+ else
+ __raw_writel(__raw_readl(rtc->rtc_reg + REG_RTC_RIER)&
+ (~TICKINTENB), rtc->rtc_reg + REG_RTC_RIER);
+
+ return 0;
+}
+
+static int nuc900_alarm_irq_enable(struct device *dev, unsigned int enabled)
+{
+ struct nuc900_rtc *rtc = dev_get_drvdata(dev);
+
+ if (enabled)
+ __raw_writel(__raw_readl(rtc->rtc_reg + REG_RTC_RIER)|
+ (ALARMINTENB), rtc->rtc_reg + REG_RTC_RIER);
+ else
+ __raw_writel(__raw_readl(rtc->rtc_reg + REG_RTC_RIER)&
+ (~ALARMINTENB), rtc->rtc_reg + REG_RTC_RIER);
+
+ return 0;
+}
+
+static int nuc900_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct nuc900_rtc *rtc = dev_get_drvdata(dev);
+ unsigned int timeval, clrval;
+
+ timeval = __raw_readl(rtc->rtc_reg + REG_RTC_TLR);
+ clrval = __raw_readl(rtc->rtc_reg + REG_RTC_CLR);
+
+ nuc900_rtc_bcd2bin(timeval, clrval, tm);
+
+ return 0;
+}
+
+static int nuc900_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct nuc900_rtc *rtc = dev_get_drvdata(dev);
+ struct nuc900_bcd_time gettm;
+ unsigned long val;
+
+ nuc900_rtc_bin2bcd(tm, &gettm);
+
+ check_rtc_power(rtc);
+
+ val = gettm.bcd_mday | gettm.bcd_mon | gettm.bcd_year;
+ __raw_writel(val, rtc->rtc_reg + REG_RTC_CLR);
+
+ val = gettm.bcd_sec | gettm.bcd_min | gettm.bcd_hour;
+ __raw_writel(val, rtc->rtc_reg + REG_RTC_TLR);
+
+ return 0;
+}
+
+static int nuc900_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+ struct nuc900_rtc *rtc = dev_get_drvdata(dev);
+ unsigned int timeval, carval;
+
+ timeval = __raw_readl(rtc->rtc_reg + REG_RTC_TAR);
+ carval = __raw_readl(rtc->rtc_reg + REG_RTC_CAR);
+
+ nuc900_rtc_bcd2bin(timeval, carval, &alrm->time);
+
+ return 0;
+}
+
+static int nuc900_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+ struct nuc900_rtc *rtc = dev_get_drvdata(dev);
+ struct nuc900_bcd_time tm;
+ unsigned long val;
+
+ nuc900_rtc_bin2bcd(&alrm->time, &tm);
+
+ check_rtc_power(rtc);
+
+ val = tm.bcd_mday | tm.bcd_mon | tm.bcd_year;
+ __raw_writel(val, rtc->rtc_reg + REG_RTC_CAR);
+
+ val = tm.bcd_sec | tm.bcd_min | tm.bcd_hour;
+ __raw_writel(val, rtc->rtc_reg + REG_RTC_TAR);
+
+ return 0;
+}
+
+static struct rtc_class_ops nuc900_rtc_ops = {
+ .read_time = nuc900_rtc_read_time,
+ .set_time = nuc900_rtc_set_time,
+ .read_alarm = nuc900_rtc_read_alarm,
+ .set_alarm = nuc900_rtc_set_alarm,
+ .alarm_irq_enable = nuc900_alarm_irq_enable,
+ .update_irq_enable = nuc900_update_irq_enable,
+};
+
+static int __devinit nuc900_rtc_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct nuc900_rtc *nuc900_rtc;
+ int err = 0;
+
+ nuc900_rtc = kzalloc(sizeof(struct nuc900_rtc), GFP_KERNEL);
+ if (!nuc900_rtc) {
+ dev_err(&pdev->dev, "kzalloc nuc900_rtc failed\n");
+ return -ENOMEM;
+ }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "platform_get_resource failed\n");
+ err = -ENXIO;
+ goto fail1;
+ }
+
+ if (!request_mem_region(res->start, resource_size(res),
+ pdev->name)) {
+ dev_err(&pdev->dev, "request_mem_region failed\n");
+ err = -EBUSY;
+ goto fail1;
+ }
+
+ nuc900_rtc->rtc_reg = ioremap(res->start, resource_size(res));
+ if (!nuc900_rtc->rtc_reg) {
+ dev_err(&pdev->dev, "ioremap rtc_reg failed\n");
+ err = -ENOMEM;
+ goto fail2;
+ }
+
+ nuc900_rtc->irq_num = platform_get_irq(pdev, 0);
+ if (request_irq(nuc900_rtc->irq_num, nuc900_rtc_interrupt,
+ IRQF_DISABLED, "nuc900rtc", nuc900_rtc)) {
+ dev_err(&pdev->dev, "NUC900 RTC request irq failed\n");
+ err = -EBUSY;
+ goto fail3;
+ }
+
+ nuc900_rtc->rtcdev = rtc_device_register(pdev->name, &pdev->dev,
+ &nuc900_rtc_ops, THIS_MODULE);
+ if (IS_ERR(nuc900_rtc->rtcdev)) {
+ dev_err(&pdev->dev, "rtc device register faild\n");
+ err = PTR_ERR(nuc900_rtc->rtcdev);
+ goto fail4;
+ }
+
+ platform_set_drvdata(pdev, nuc900_rtc);
+ __raw_writel(__raw_readl(nuc900_rtc->rtc_reg + REG_RTC_TSSR) | MODE24,
+ nuc900_rtc->rtc_reg + REG_RTC_TSSR);
+
+ return 0;
+
+fail4: free_irq(nuc900_rtc->irq_num, nuc900_rtc);
+fail3: iounmap(nuc900_rtc->rtc_reg);
+fail2: release_mem_region(res->start, resource_size(res));
+fail1: kfree(nuc900_rtc);
+ return err;
+}
+
+static int __devexit nuc900_rtc_remove(struct platform_device *pdev)
+{
+ struct nuc900_rtc *nuc900_rtc = platform_get_drvdata(pdev);
+ struct resource *res;
+
+ rtc_device_unregister(nuc900_rtc->rtcdev);
+ free_irq(nuc900_rtc->irq_num, nuc900_rtc);
+ iounmap(nuc900_rtc->rtc_reg);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ release_mem_region(res->start, resource_size(res));
+
+ kfree(nuc900_rtc);
+
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+static struct platform_driver nuc900_rtc_driver = {
+ .remove = __devexit_p(nuc900_rtc_remove),
+ .driver = {
+ .name = "nuc900-rtc",
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init nuc900_rtc_init(void)
+{
+ return platform_driver_probe(&nuc900_rtc_driver, nuc900_rtc_probe);
+}
+
+static void __exit nuc900_rtc_exit(void)
+{
+ platform_driver_unregister(&nuc900_rtc_driver);
+}
+
+module_init(nuc900_rtc_init);
+module_exit(nuc900_rtc_exit);
+
+MODULE_AUTHOR("Wan ZongShun <mcuos.com@gmail.com>");
+MODULE_DESCRIPTION("nuc910/nuc920 RTC driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:nuc900-rtc");
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: What are the goals for the architecture of an in-kernel IR system?
http://groups.google.com/group/linux.kernel/t/344640f275ed964e?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Nov 29 2009 4:40 am
From: Alan Cox

> BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around

Correct X11 just talked to the serial ports. In fact that is still the
way to configure it if you want any sanity in life.

> and serial connected IRs. It's also too convenient to access USB IR
> hardware from existing userspace drivers to bother porting into the
> kernel.

Userspace needs a way to identify IR hardware and to interface with it
using the right protocol. It's not clear the kernel needs to provide
anything more than minimal hardware interfaces in most case - be that
serial, libusb, ...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: change PCI nomenclature according to PCI-SIG
http://groups.google.com/group/linux.kernel/t/d3dcc3e136af839d?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Nov 29 2009 5:00 am
From: Jeff Garzik

On 11/29/2009 04:09 AM, Stefan Assmann wrote:
> On 28.11.2009 13:43, Jeff Garzik wrote:
>> On 11/28/2009 06:54 AM, Stefan Assmann wrote:
>>> From: Stefan Assmann<sassmann@redhat.com>
>>>
>>> Changing occurrences of variants of PCI-X and PCIe to the PCI-SIG
>>> terms listed in the "Trademark and Logo Usage Guidelines".
>>> http://www.pcisig.com/developers/procedures/logos/Trademark_and_Logo_Usage_Guidelines_updated_112206.pdf
>>>
>>> Additionally some renames of Gb/s to GT/s where appropriate, concerns
>>> PCIe.
>>>
>>> This is a followup to the discussion at:
>>> http://lkml.org/lkml/2009/10/14/107
>>> Patch is based on 2.6.32-rc8.
>>>
>>> Signed-off-by: Stefan Assmann<sassmann@redhat.com>
>>
>> NAK, this clearly introduces bugs and changes sysfs output (ABI).
>>
>> Typically this type of change is pointless churn that creates far more
>> problems than it "solves."
>
> Hi Jeff,
>
> I see you point in not liking this kind of change. What kind of cleanup
> would be ok in your opinion?

Think about this from an engineering perspective. This patch is driven
not by any real technical need, but more by marketing and trademark folks.

The absolute best case scenario for this patch is that nothing changes,
from an implementation and behavior standpoint. The worst case, of
course, is that it introduces bugs (which it does).

You also incur the standard costs of any kernel change: you've just
made the diff between, for example, a vendor kernel's foo_driver.c and
upstream's foo_driver.c a lot larger, and more difficult to discern
real, technical changes to the code.

Of course, we change the kernel every day -- but we also know that
change itself has cost, and a lot of code changes for cosmetic reasons
have the potential for greater negative costs, and fewer positive benefits.

Next, IMO, you don't have any idea how maintainers will react to this
patch, because you CC'd so few of them. People who perform tree-wide
changes should take the time to CC __every__ relevant maintainer. If
you are changing somebody's code, you should always let them know about
it, and give them an opportunity to review the change.
scripts/get_maintainer.pl can help with this.

So, while the PCI maintainer might agree with the nomenclature change,
he is not the most qualified person to state that your changes have no
effect on drivers/edac/ppc4xx_edac.c, for example.

Finally, split your patch up. I would suggest starting with 100%
comment changes that are guaranteed with mathematical certainty to not
change the compiler-generated code at all. That will make the remaining
changes much easier to review, if they are in separate patches from the
comment-only changes.

Jeff

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Sun, Nov 29 2009 7:20 am
From: "Rafael J. Wysocki"

On Sunday 29 November 2009, Jeff Garzik wrote:
> On 11/29/2009 04:09 AM, Stefan Assmann wrote:
> > On 28.11.2009 13:43, Jeff Garzik wrote:
> >> On 11/28/2009 06:54 AM, Stefan Assmann wrote:
> >>> From: Stefan Assmann<sassmann@redhat.com>
> >>>
> >>> Changing occurrences of variants of PCI-X and PCIe to the PCI-SIG
> >>> terms listed in the "Trademark and Logo Usage Guidelines".
> >>> http://www.pcisig.com/developers/procedures/logos/Trademark_and_Logo_Usage_Guidelines_updated_112206.pdf
> >>>
> >>> Additionally some renames of Gb/s to GT/s where appropriate, concerns
> >>> PCIe.
> >>>
> >>> This is a followup to the discussion at:
> >>> http://lkml.org/lkml/2009/10/14/107
> >>> Patch is based on 2.6.32-rc8.
> >>>
> >>> Signed-off-by: Stefan Assmann<sassmann@redhat.com>
> >>
> >> NAK, this clearly introduces bugs and changes sysfs output (ABI).
> >>
> >> Typically this type of change is pointless churn that creates far more
> >> problems than it "solves."
> >
> > Hi Jeff,
> >
> > I see you point in not liking this kind of change. What kind of cleanup
> > would be ok in your opinion?
>
> Think about this from an engineering perspective. This patch is driven
> not by any real technical need, but more by marketing and trademark folks.
>
> The absolute best case scenario for this patch is that nothing changes,
> from an implementation and behavior standpoint. The worst case, of
> course, is that it introduces bugs (which it does).
>
> You also incur the standard costs of any kernel change: you've just
> made the diff between, for example, a vendor kernel's foo_driver.c and
> upstream's foo_driver.c a lot larger, and more difficult to discern
> real, technical changes to the code.
>
> Of course, we change the kernel every day -- but we also know that
> change itself has cost, and a lot of code changes for cosmetic reasons
> have the potential for greater negative costs, and fewer positive benefits.
>
> Next, IMO, you don't have any idea how maintainers will react to this
> patch, because you CC'd so few of them. People who perform tree-wide
> changes should take the time to CC __every__ relevant maintainer. If
> you are changing somebody's code, you should always let them know about
> it, and give them an opportunity to review the change.
> scripts/get_maintainer.pl can help with this.
>
> So, while the PCI maintainer might agree with the nomenclature change,
> he is not the most qualified person to state that your changes have no
> effect on drivers/edac/ppc4xx_edac.c, for example.
>
> Finally, split your patch up. I would suggest starting with 100%
> comment changes that are guaranteed with mathematical certainty to not
> change the compiler-generated code at all. That will make the remaining
> changes much easier to review, if they are in separate patches from the
> comment-only changes.

FWIW, I agree with everything said and I think it might be a good idea to
put something like this into Documentation/ for people wanting to make similar
changes in future.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: linux-next: manual merge of the osd tree with the scsi tree
http://groups.google.com/group/linux.kernel/t/ea261026d7d3cccc?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Nov 29 2009 5:10 am
From: Boaz Harrosh

On 11/29/2009 11:10 AM, Boaz Harrosh wrote:
> On 11/27/2009 05:32 AM, Stephen Rothwell wrote:
>> Hi Boaz,
>>
>> Today's linux-next merge of the osd tree got a conflict in
>> drivers/scsi/osd/osd_uld.c between commit
>> f89b9ee4a722721ed205b8c29555ac75fbe8c2cc ("[SCSI] osduld: Use
>> device->release instead of internal kref") from the scsi tree and commit
>> 9b579fe8588b861dcf0c9b620757729643db4557 ("osduld: Use device->release
>> instead of internal kref") from the osd tree.
>>
>> These are slightly different versions of the same patch ...
>>
>> And commit 01e4c32c668251e74eb179ee1207c075466c4ef8 ("osduld: No need to
>> use dev_set_drvdata on embedded devices") from the osd also contributes
>> to the conflict.
>>
>
> James has squashed these two patches together. Which do belong together
> I should say. In my tree they are separate. I will change my tree to
> match James's.
>
> Thanks James, I prefer it much better this way.
>

James hi.

In your merge of the patch:
[SCSI] osduld: Use device->release instead of internal kref
at:
[jejb: fold in use of container_of]

You have made a mistake, which renders the driver unusable.
At osd_remove() you changed the use of dev_get_drvdata to an, container_of()
but it is the *wrong* dev at this point this dev here is the grand-parent of
the embedded dev in question.

Also at the next patch:
[SCSI] libosd: osd_dev_info: Unique Identification of an OSD device

a new use of dev_get_drvdata() is not converted to a container_of(), which by
now will return NULL.

Should I repost the correct two patches (my preference)? should I send in a fix to
current scsi-misc tree? or should I send two SQUASH-ME patches to the two bad commits
in your tree?

How do you want to proceed?

>> I fixed it up (the obvious way) and can carry the fix for a while.
>

Stephan, I have not yet fixed up the conflict in -next, please carry that
fix you have for a little while, until we resolve it.

> Thanks
> Boaz

Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 4 ==
Date: Sun, Nov 29 2009 5:50 am
From: James Bottomley

On Sun, 2009-11-29 at 15:07 +0200, Boaz Harrosh wrote:
> On 11/29/2009 11:10 AM, Boaz Harrosh wrote:
> > On 11/27/2009 05:32 AM, Stephen Rothwell wrote:
> >> Hi Boaz,
> >>
> >> Today's linux-next merge of the osd tree got a conflict in
> >> drivers/scsi/osd/osd_uld.c between commit
> >> f89b9ee4a722721ed205b8c29555ac75fbe8c2cc ("[SCSI] osduld: Use
> >> device->release instead of internal kref") from the scsi tree and commit
> >> 9b579fe8588b861dcf0c9b620757729643db4557 ("osduld: Use device->release
> >> instead of internal kref") from the osd tree.
> >>
> >> These are slightly different versions of the same patch ...
> >>
> >> And commit 01e4c32c668251e74eb179ee1207c075466c4ef8 ("osduld: No need to
> >> use dev_set_drvdata on embedded devices") from the osd also contributes
> >> to the conflict.
> >>
> >
> > James has squashed these two patches together. Which do belong together
> > I should say. In my tree they are separate. I will change my tree to
> > match James's.
> >
> > Thanks James, I prefer it much better this way.
> >
>
> James hi.
>
> In your merge of the patch:
> [SCSI] osduld: Use device->release instead of internal kref
> at:
> [jejb: fold in use of container_of]
>
> You have made a mistake, which renders the driver unusable.
> At osd_remove() you changed the use of dev_get_drvdata to an, container_of()
> but it is the *wrong* dev at this point this dev here is the grand-parent of
> the embedded dev in question.
>
> Also at the next patch:
> [SCSI] libosd: osd_dev_info: Unique Identification of an OSD device
>
> a new use of dev_get_drvdata() is not converted to a container_of(), which by
> now will return NULL.
>
> Should I repost the correct two patches (my preference)? should I send in a fix to
> current scsi-misc tree? or should I send two SQUASH-ME patches to the two bad commits
> in your tree?
>
> How do you want to proceed?

Send me the replacement patch (and tell me which commit id in my tree
it's replacing).

Thanks,

James

== 3 of 4 ==
Date: Sun, Nov 29 2009 6:30 am
From: Boaz Harrosh

On 11/29/2009 03:46 PM, James Bottomley wrote:
>>
>> Should I repost the correct two patches (my preference)? should I send in a fix to
>> current scsi-misc tree? or should I send two SQUASH-ME patches to the two bad commits
>> in your tree?
>>
>> How do you want to proceed?
>
> Send me the replacement patch (and tell me which commit id in my tree
> it's replacing).
>

Thank you James.

I'm posting two patches as reply to this mail.

[PATCH 1/2] osduld: Use device->release instead of internal kref
which replaces:
f89b9ee [SCSI] osduld: Use device->release instead of internal kref

and

[PATCH 2/2] libosd: osd_dev_info: Unique Identification of an OSD device
which replaces:
3b616d4 [SCSI] libosd: osd_dev_info: Unique Identification of an OSD device

> Thanks,
>
> James
>
>

== 4 of 4 ==
Date: Sun, Nov 29 2009 7:30 am
From: James Bottomley

On Sun, 2009-11-29 at 16:23 +0200, Boaz Harrosh wrote:
> On 11/29/2009 03:46 PM, James Bottomley wrote:
> >>
> >> Should I repost the correct two patches (my preference)? should I send in a fix to
> >> current scsi-misc tree? or should I send two SQUASH-ME patches to the two bad commits
> >> in your tree?
> >>
> >> How do you want to proceed?
> >
> > Send me the replacement patch (and tell me which commit id in my tree
> > it's replacing).
> >
>
> Thank you James.
>
> I'm posting two patches as reply to this mail.
>
> [PATCH 1/2] osduld: Use device->release instead of internal kref
> which replaces:
> f89b9ee [SCSI] osduld: Use device->release instead of internal kref
>
> and
>
> [PATCH 2/2] libosd: osd_dev_info: Unique Identification of an OSD device
> which replaces:
> 3b616d4 [SCSI] libosd: osd_dev_info: Unique Identification of an OSD device

OK, replacement should be done in scsi-misc (give an hour or two for
mirror updates).

James

==============================================================================
TOPIC: Documentation: Fix a stale reference in Documentation/DMA-API.txt
http://groups.google.com/group/linux.kernel/t/babcd28e1f502f70?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Nov 29 2009 5:20 am
From: Bart Van Assche

Fixes a stale reference in Documentation/DMA-API.txt.

Signed-off-by: Bart Van Assche <bart.vanassche@gmail.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 5aceb88..51b4ca1 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -5,7 +5,7 @@

This document describes the DMA API. For a more gentle introduction
phrased in terms of the pci_ equivalents (and actual examples) see
-Documentation/PCI/PCI-DMA-mapping.txt.
+Documentation/DMA-mapping.txt.

This API is split into two pieces. Part I describes the API and the
corresponding pci_ API. Part II describes the extensions to the API
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: f83f9ac causes tasks running at MAX_PRIO
http://groups.google.com/group/linux.kernel/t/0eff970fb6e1b0a8?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Nov 29 2009 5:30 am
From: Mike Galbraith

top - 11:33:19 up 1 min, 21 users, load average: 4.47, 1.44, 0.51
Tasks: 288 total, 1 running, 287 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.5%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
568 root 20 0 0 0 0 S 1 0.0 0:00.02 3 scsi_eh_1
4724 root 40 0 358m 22m 4008 S 1 0.7 0:01.69 0 Xorg
6064 root 40 0 8872 1316 852 R 1 0.0 0:00.07 3 top
1 root 40 0 1064 388 324 S 0 0.0 0:01.30 2 init
2 root 40 0 0 0 0 S 0 0.0 0:00.00 1 kthreadd
3 root RT 0 0 0 0 S 0 0.0 0:00.00 0 migration/0

WARN_ON(current->normal_prio == MAX_PRIO);

[ 0.092016] ------------[ cut here ]------------
[ 0.096008] WARNING: at kernel/sched.c:2591 sched_fork+0xe4/0x1ae()
[ 0.100002] Hardware name: MS-7502
[ 0.104002] Modules linked in:
[ 0.108191] Pid: 0, comm: swapper Not tainted 2.6.32-tip-smpx #956
[ 0.112002] Call Trace:
[ 0.116004] [<ffffffff810365ab>] ? sched_fork+0xe4/0x1ae
[ 0.120004] [<ffffffff81038eb8>] warn_slowpath_common+0x77/0xa4
[ 0.124004] [<ffffffff81038ef4>] warn_slowpath_null+0xf/0x11
[ 0.128003] [<ffffffff810365ab>] sched_fork+0xe4/0x1ae
[ 0.132005] [<ffffffff81059a9f>] ? monotonic_to_bootbased+0x26/0x34
[ 0.136004] [<ffffffff8103783b>] copy_process+0x4b9/0x10e4
[ 0.140006] [<ffffffff810bd38b>] ? __get_vm_area_node+0x175/0x1bf
[ 0.144004] [<ffffffff810385b2>] do_fork+0x14c/0x304
[ 0.148005] [<ffffffff810200dd>] ? __ioremap_caller+0x292/0x2fb
[ 0.152005] [<ffffffff812838b0>] ? acpi_os_map_memory+0x12/0x1b
[ 0.156006] [<ffffffff810038d2>] kernel_thread+0x82/0xe0
[ 0.160006] [<ffffffff8146c510>] ? kernel_init+0x0/0x1af
[ 0.164004] [<ffffffff81003930>] ? child_rip+0x0/0x20
[ 0.168004] [<ffffffff81281a48>] ? rest_init+0x1c/0x76
[ 0.172003] [<ffffffff8146cc54>] start_kernel+0x351/0x35c
[ 0.176004] [<ffffffff8146c29a>] x86_64_start_reservations+0xaa/0xae
[ 0.180004] [<ffffffff8146c37f>] x86_64_start_kernel+0xe1/0xe8
[ 0.184007] ---[ end trace 4eaa2a86a8e2da22 ]---

sched: fix task priority bug.

f83f9ac removed a call to effective_prio() in wake_up_new_task(), which
leads to tasks running at MAX_PRIO. That call set both the child's prio
and normal_prio fields to normal_prio(child). Do the same fork time by
setting both to normal_prio(parent).

Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Peter Williams <pwil3058@bigpond.net.au>
LKML-Reference: <new-submission>

---
kernel/sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -2609,7 +2609,7 @@ void sched_fork(struct task_struct *p, i
/*
* Make sure we do not leak PI boosting priority to the child.
*/
- p->prio = current->normal_prio;
+ p->prio = p->normal_prio = normal_prio(current);

if (!rt_prio(p->prio))
p->sched_class = &fair_sched_class;

==============================================================================
TOPIC: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66
0f 7f 07'
http://groups.google.com/group/linux.kernel/t/ada9fa2d2574a8af?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Nov 29 2009 5:50 am
From: Nix

On 29 Nov 2009, Avi Kivity uttered the following:
> 66 0f 7f 07 movdqa %xmm0,(%rdi)
>
> which we don't emulate.

x86-64 glibc 2.10 memset(), perhaps? On SSE-capable platforms that does
a whole bunch of

L(SSE0QB): movdqa %xmm0,-0xb0(%rdi)
L(SSE0QA): movdqa %xmm0,-0xa0(%rdi)
L(SSE0Q9): movdqa %xmm0,-0x90(%rdi)
L(SSE0Q8): movdqa %xmm0,-0x80(%rdi)
L(SSE0Q7): movdqa %xmm0,-0x70(%rdi)
L(SSE0Q6): movdqa %xmm0,-0x60(%rdi)
L(SSE0Q5): movdqa %xmm0,-0x50(%rdi)
L(SSE0Q4): movdqa %xmm0,-0x40(%rdi)
L(SSE0Q3): movdqa %xmm0,-0x30(%rdi)
L(SSE0Q2): movdqa %xmm0,-0x20(%rdi)
L(SSE0Q1): movdqa %xmm0,-0x10(%rdi)
L(SSE0Q0): retq

(multiple blocks of this, catering for alignment, I guess)

and x86-64 is always SSE-capable.

> Can you, using the qemu monitor, see where the guest is trying to write?
>
> (qemu) info registers
> (qemu) x/30i $eip - 20

looks like a leaveq, consistently (big flow-of-control change): want a
dump of some higher stack frames?

(qemu) info registers
RAX=0000000000000000 RBX=ffffffff81813a28 RCX=0000000000000000 RDX=0000000000000000
RSI=0000000000000001 RDI=ffffffff818f4fa8 RBP=ffffffff81769eb8 RSP=ffffffff81769eb8
R8 =0000000000000000 R9 =ffffffff81925418 R10=000000000000000e R11=0000000000ffff0e
R12=6db6db6db6db6db7 R13=ffffffff818f2000 R14=ffffffff81769fa8 R15=000000000008c000
RIP=ffffffff810316f6 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=1
ES =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA]
SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
FS =0000 0000000000000000 ffffffff 00000000
GS =0000 ffff8800019c5000 ffffffff 00000000
LDT=0000 0000000000000000 ffffffff 00000000
TR =0040 ffff8800019d8140 00002087 00008b00 DPL=0 TSS64-busy
GDT= ffff8800019c9000 0000007f
IDT= ffffffff818f2000 00000fff
CR0=8005003b CR2=0000000000f57000 CR3=000000003dc13000 CR4=000006b0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
FPR0=0000000000000025 ffff FPR1=000000000000001b ffff
FPR2=12a05f24a8000000 ffff FPR3=00000002540be495 ffff
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 ffff
XMM00=0000ff0000000000000000000000ff00 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=000000000000000000000000000000ff
XMM04=0000000000000000406e000000000000 XMM05=00000000000000003fd8234618ab9d47
XMM06=00000000000000003fd8234618ab9d47 XMM07=00000000000000003fec5c5c5c5c5c5c
XMM08=00000000000000004032000000000000 XMM09=0000000000000000404e000000000000
XMM10=0000000000000000405e000000000000 XMM11=00000000000000000000000000000000
XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000

(qemu) x/30i $eip - 20
0xffffffff810316e2: mov %esp,%ebp
0xffffffff810316e4: sti
0xffffffff810316e5: leaveq
0xffffffff810316e6: retq
0xffffffff810316e7: nopw 0x0(%rax,%rax,1)
0xffffffff810316f0: push %rbp
0xffffffff810316f1: mov %rsp,%rbp
0xffffffff810316f4: sti
0xffffffff810316f5: hlt
0xffffffff810316f6: leaveq
0xffffffff810316f7: retq
0xffffffff810316f8: nopl 0x0(%rax,%rax,1)
0xffffffff81031700: push %rbp
0xffffffff81031701: mov %rsp,%rbp
0xffffffff81031704: hlt
0xffffffff81031705: leaveq
0xffffffff81031706: retq
0xffffffff81031707: nopw 0x0(%rax,%rax,1)
0xffffffff81031710: push %rbp
0xffffffff81031711: mov %rsp,%rbp
0xffffffff81031714: clts
0xffffffff81031716: leaveq
0xffffffff81031717: retq
0xffffffff81031718: nopl 0x0(%rax,%rax,1)
0xffffffff81031720: push %rbp
0xffffffff81031721: mov %rsp,%rbp
0xffffffff81031724: mov %cr0,%rax
0xffffffff81031727: leaveq
0xffffffff81031728: retq
0xffffffff81031729: nopl 0x0(%rax)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Sun, Nov 29 2009 6:30 am
From: Avi Kivity

On 11/29/2009 03:48 PM, Nix wrote:
> On 29 Nov 2009, Avi Kivity uttered the following:
>
>> 66 0f 7f 07 movdqa %xmm0,(%rdi)
>>
>> which we don't emulate.
>>
> x86-64 glibc 2.10 memset(), perhaps? On SSE-capable platforms that does
> a whole bunch of
>
> L(SSE0QB): movdqa %xmm0,-0xb0(%rdi)
> L(SSE0QA): movdqa %xmm0,-0xa0(%rdi)
> L(SSE0Q9): movdqa %xmm0,-0x90(%rdi)
> L(SSE0Q8): movdqa %xmm0,-0x80(%rdi)
> L(SSE0Q7): movdqa %xmm0,-0x70(%rdi)
> L(SSE0Q6): movdqa %xmm0,-0x60(%rdi)
> L(SSE0Q5): movdqa %xmm0,-0x50(%rdi)
> L(SSE0Q4): movdqa %xmm0,-0x40(%rdi)
> L(SSE0Q3): movdqa %xmm0,-0x30(%rdi)
> L(SSE0Q2): movdqa %xmm0,-0x20(%rdi)
> L(SSE0Q1): movdqa %xmm0,-0x10(%rdi)
> L(SSE0Q0): retq
>
> (multiple blocks of this, catering for alignment, I guess)
>
> and x86-64 is always SSE-capable.
>

Most likely, either this or something similar is called on a userspace
device driver. Can you check if this is triggered by starting X?

If so, we'll have to emulate this instruction, which will be a bitch.

--
error compiling committee.c: too many arguments to function

==============================================================================
TOPIC: core: fix user return notifier on fork()
http://groups.google.com/group/linux.kernel/t/f9483907bf475210?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Nov 29 2009 6:40 am
From: Avi Kivity

fork() clones all thread_info flags, including TIF_USER_RETURN_NOTIFY; if the
new task is first scheduled on a cpu which doesn't have user return notifiers
set, this causes user return notifiers to trigger without any way of clearing
itself.

This is easy to trigger with a forky workload on the host in parallel with
kvm, resulting in a cpu in an endless loop on the verge of returning to
userspace.

Fix by dropping the TIF_USER_RETURN_NOTIFY immediately after fork.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
include/linux/user-return-notifier.h | 7 +++++++
kernel/fork.c | 2 ++
2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/include/linux/user-return-notifier.h b/include/linux/user-return-notifier.h
index b6ac056..9c4a445 100644
--- a/include/linux/user-return-notifier.h
+++ b/include/linux/user-return-notifier.h
@@ -26,6 +26,11 @@ static inline void propagate_user_return_notify(struct task_struct *prev,

void fire_user_return_notifiers(void);

+static inline void clear_user_return_notifier(struct task_struct *p)
+{
+ clear_tsk_thread_flag(p, TIF_USER_RETURN_NOTIFY);
+}
+
#else

struct user_return_notifier {};
@@ -37,6 +42,8 @@ static inline void propagate_user_return_notify(struct task_struct *prev,

static inline void fire_user_return_notifiers(void) {}

+static inline void clear_user_return_notifier(struct task_struct *p) {}
+

twitter

Sunday, November 29, 2009

linux.kernel - 26 new messages in 17 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts