[PATCH 4/13] incorrect use of init_completion fixup

[Nicholas Mc Guire]

The successive init_completion calls should be reinit_completion calls.

patch against 3.19.0-rc1 linux-next

Acked-by: Helge Deller 
Signed-off-by: Nicholas Mc Guire 
---
 drivers/input/keyboard/hil_kbd.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/input/keyboard/hil_kbd.c b/drivers/input/keyboard/hil_kbd.c
index 610a8af..5b152f2 100644
--- a/drivers/input/keyboard/hil_kbd.c
+++ b/drivers/input/keyboard/hil_kbd.c
@@ -473,7 +473,7 @@ static int hil_dev_connect(struct serio *serio, struct 
serio_driver *drv)
if (error)
goto bail1;

-   init_completion(&dev->cmd_done);
+   reinit_completion(&dev->cmd_done);
serio_write(serio, 0);
serio_write(serio, 0);
serio_write(serio, HIL_PKT_CMD >> 8);
@@ -482,7 +482,7 @@ static int hil_dev_connect(struct serio *serio, struct 
serio_driver *drv)
if (error)
goto bail1;

-   init_completion(&dev->cmd_done);
+   reinit_completion(&dev->cmd_done);
serio_write(serio, 0);
serio_write(serio, 0);
serio_write(serio, HIL_PKT_CMD >> 8);
@@ -491,7 +491,7 @@ static int hil_dev_connect(struct serio *serio, struct 
serio_driver *drv)
if (error)
goto bail1;

-   init_completion(&dev->cmd_done);
+   reinit_completion(&dev->cmd_done);
serio_write(serio, 0);
serio_write(serio, 0);
serio_write(serio, HIL_PKT_CMD >> 8);
--
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/

[PATCH] net: wireless: rt2x00: use helper to check capability/requirement

[Fred Chou]

From: Fred Chou 

Use rt2x00_has_cap_flag macro to check rt2x00dev->cap_flags. 

Signed-off-by: Fred Chou 
---
 drivers/net/wireless/rt2x00/rt2x00config.c   |  4 ++--
 drivers/net/wireless/rt2x00/rt2x00dev.c  | 18 +-
 drivers/net/wireless/rt2x00/rt2x00firmware.c |  2 +-
 drivers/net/wireless/rt2x00/rt2x00mac.c  |  2 +-
 drivers/net/wireless/rt2x00/rt2x00queue.c| 18 +-
 drivers/net/wireless/rt2x00/rt2x00usb.c  |  8 
 6 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c 
b/drivers/net/wireless/rt2x00/rt2x00config.c
index 1122dc4..48a2cad 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/rt2x00/rt2x00config.c
@@ -240,7 +240,7 @@ void rt2x00lib_config(struct rt2x00_dev *rt2x00dev,
rt2x00dev->rf_channel = libconf.rf.channel;
}
 
-   if (test_bit(REQUIRE_PS_AUTOWAKE, &rt2x00dev->cap_flags) &&
+   if (rt2x00_has_cap_flag(rt2x00dev, REQUIRE_PS_AUTOWAKE) &&
(ieee80211_flags & IEEE80211_CONF_CHANGE_PS))
cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
 
@@ -257,7 +257,7 @@ void rt2x00lib_config(struct rt2x00_dev *rt2x00dev,
rt2x00link_reset_tuner(rt2x00dev, false);
 
if (test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags) &&
-   test_bit(REQUIRE_PS_AUTOWAKE, &rt2x00dev->cap_flags) &&
+   rt2x00_has_cap_flag(rt2x00dev, REQUIRE_PS_AUTOWAKE) &&
(ieee80211_flags & IEEE80211_CONF_CHANGE_PS) &&
(conf->flags & IEEE80211_CONF_PS)) {
beacon_diff = (long)jiffies - (long)rt2x00dev->last_beacon;
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c 
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 9967a1d..5639ed8 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -351,7 +351,7 @@ void rt2x00lib_txdone(struct queue_entry *entry,
/*
 * Remove L2 padding which was added during
 */
-   if (test_bit(REQUIRE_L2PAD, &rt2x00dev->cap_flags))
+   if (rt2x00_has_cap_flag(rt2x00dev, REQUIRE_L2PAD))
rt2x00queue_remove_l2pad(entry->skb, header_length);
 
/*
@@ -460,7 +460,7 @@ void rt2x00lib_txdone(struct queue_entry *entry,
 * send the status report back.
 */
if (!(skbdesc_flags & SKBDESC_NOT_MAC80211)) {
-   if (test_bit(REQUIRE_TASKLET_CONTEXT, &rt2x00dev->cap_flags))
+   if (rt2x00_has_cap_flag(rt2x00dev, REQUIRE_TASKLET_CONTEXT))
ieee80211_tx_status(rt2x00dev->hw, entry->skb);
else
ieee80211_tx_status_ni(rt2x00dev->hw, entry->skb);
@@ -1056,9 +1056,9 @@ static int rt2x00lib_probe_hw(struct rt2x00_dev 
*rt2x00dev)
/*
 * Take TX headroom required for alignment into account.
 */
-   if (test_bit(REQUIRE_L2PAD, &rt2x00dev->cap_flags))
+   if (rt2x00_has_cap_flag(rt2x00dev, REQUIRE_L2PAD))
rt2x00dev->hw->extra_tx_headroom += RT2X00_L2PAD_SIZE;
-   else if (test_bit(REQUIRE_DMA, &rt2x00dev->cap_flags))
+   else if (rt2x00_has_cap_flag(rt2x00dev, REQUIRE_DMA))
rt2x00dev->hw->extra_tx_headroom += RT2X00_ALIGN_SIZE;
 
/*
@@ -1069,7 +1069,7 @@ static int rt2x00lib_probe_hw(struct rt2x00_dev 
*rt2x00dev)
/*
 * Allocate tx status FIFO for driver use.
 */
-   if (test_bit(REQUIRE_TXSTATUS_FIFO, &rt2x00dev->cap_flags)) {
+   if (rt2x00_has_cap_flag(rt2x00dev, REQUIRE_TXSTATUS_FIFO)) {
/*
 * Allocate the txstatus fifo. In the worst case the tx
 * status fifo has to hold the tx status of all entries
@@ -1131,7 +1131,7 @@ static void rt2x00lib_uninitialize(struct rt2x00_dev 
*rt2x00dev)
/*
 * Stop rfkill polling.
 */
-   if (test_bit(REQUIRE_DELAYED_RFKILL, &rt2x00dev->cap_flags))
+   if (rt2x00_has_cap_flag(rt2x00dev, REQUIRE_DELAYED_RFKILL))
rt2x00rfkill_unregister(rt2x00dev);
 
/*
@@ -1173,7 +1173,7 @@ static int rt2x00lib_initialize(struct rt2x00_dev 
*rt2x00dev)
/*
 * Start rfkill polling.
 */
-   if (test_bit(REQUIRE_DELAYED_RFKILL, &rt2x00dev->cap_flags))
+   if (rt2x00_has_cap_flag(rt2x00dev, REQUIRE_DELAYED_RFKILL))
rt2x00rfkill_register(rt2x00dev);
 
return 0;
@@ -1389,7 +1389,7 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
/*
 * Start rfkill polling.
 */
-   if (!test_bit(REQUIRE_DELAYED_RFKILL, &rt2x00dev->cap_flags))
+   if (!rt2x00_has_cap_flag(rt2x00dev, REQUIRE_DELAYED_RFKILL))
rt2x00rfkill_register(rt2x00dev);
 
return 0;
@@ -1408,7 +1408,7 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
/*
 * Stop rfkill polling.
 */
-   if (!test_bit(REQUIRE_DELAYED_RFKILL, &rt2x00dev

Re: [PATCH 4/4] PCI: quirk Atheros AR93xx to avoid bus reset

[Andreas Hartmann]

Hello Bjorn,

I'm running this patch and the corresponding "[PATCH 3/4] PCI: Allow
device quirks to exclude bus reset" patch meanwhile since a month w/
kernel 3.14.x and couldn't find any problem. Would it be possible to
apply these patches to main kernel? Or even to lt-kernel 3.14?


Thanks.
kind regards,
Andreas Hartmann


Alex Williamson wrote:
> Reports against the TL-WDN4800 card indicate that PCI bus reset of
> this Atheros device cause system lock-ups and resets.  I've also
> been able to confirm this behavior on multiple systems.  The device
> never returns from reset and attempts to access config space of the
> device after reset result in hangs.  Blacklist bus reset for the
> device to avoid this issue.
> 
> Reported-by: Andreas Hartmann 
> Signed-off-by: Alex Williamson 
> Tested-by: Andreas Hartmann 
> ---
> 
>  drivers/pci/quirks.c |   14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 561e10d..ebbd5b4 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3029,6 +3029,20 @@ static void quirk_no_pm_reset(struct pci_dev *dev)
>  DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
>  PCI_CLASS_DISPLAY_VGA, 8, quirk_no_pm_reset);
>  
> +static void quirk_no_bus_reset(struct pci_dev *dev)
> +{
> + dev->dev_flags |= PCI_DEV_FLAGS_NO_BUS_RESET;
> +}
> +
> +/*
> + * Atheros AR93xx chips do not behave after a bus reset.  The device will
> + * throw a Link Down error on AER capable system and regardless of AER,
> + * config space of the device is never accessible again and typically
> + * causes the system to hang or reset when access is attempted.
> + * http://www.spinics.net/lists/linux-pci/msg34797.html
> + */
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0030, quirk_no_bus_reset);
> +
>  #ifdef CONFIG_ACPI
>  /*
>   * Apple: Shutdown Cactus Ridge Thunderbolt controller.
> 

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

linux-next: Tree for Dec 26

[Stephen Rothwell]

Hi all,

There will only be intermittent releases of linux-next between now and
Jan 5.

Changes since 20141221:

New trees: omap, omap-pending and livepatching

The rcu tree regained a build failure for which I reverted a commit.

Non-merge commits (relative to Linus' tree): 835
 853 files changed, 24131 insertions(+), 13211 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 234 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (08b022a9655b Merge branch 'drm-fixes' of 
git://people.freedesktop.org/~airlied/linux)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (f114040e3ea6 Linux 3.18-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (3f4aa45ceea5 ARM: 8226/1: cacheflush: get rid of 
restarting block)
Merging m68k-current/for-linus (f0b99a643e96 m68k/mm: Eliminate memset after 
alloc_bootmem_pages)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused 
force_32bit_msi quirk)
Merging powerpc-merge-mpe/fixes (b2776bf7149b Linux 3.18)
Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() 
needs to disable interrupts.)
Merging net/master (4aa6118811c0 openvswitch: fix odd_ptr_err.cocci warnings)
Merging ipsec/master (f855691975bb xfrm6: Fix the nexthdr offset in 
_decode_session6.)
Merging sound-current/for-linus (d70a1b9893f8 ALSA: usb-audio: extend KEF X300A 
FU 10 tweak to Arcam rPAC)
Merging pci-current/for-linus (5106787a9e08 PCI: tegra: Use physical range for 
I/O mapping)
Merging wireless/master (97bf6af1f928 Linux 3.19-rc1)
Merging driver-core.current/driver-core-linus (97bf6af1f928 Linux 3.19-rc1)
Merging tty.current/tty-linus (97bf6af1f928 Linux 3.19-rc1)
Merging usb.current/usb-linus (b3ee8bdcd243 Merge tag 'fixes-for-v3.19-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (6785a1034461 usb: gadget: udc: atmel: fix 
possible IN hang issue)
Merging usb-serial-fixes/usb-linus (97bf6af1f928 Linux 3.19-rc1)
Merging staging.current/staging-linus (97bf6af1f928 Linux 3.19-rc1)
Merging char-misc.current/char-misc-linus (97bf6af1f928 Linux 3.19-rc1)
Merging input-current/for-linus (6d32af019a45 Merge branch 'next' into 
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (7e77bdebff5c crypto: af_alg - fix backlog 
handling)
Merging ide/master (f96fe225677b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (094cb98179f1 of/fdt: 
memblock_reserve /memreserve/ regions in the case of partial overlap)
Merging rr-fixes/fixes (3438cf549d2f param: fix crash on bad kernel arguments)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging kselftest-fixes/fixes (6898b627aab6 selftests/exec: Use %zu to format 
size_t)
Merging drm-intel-fixes/for-linux-next-fixes (b0616c5306b3 drm/i915: Unlock 
panel even when LVDS is disabled)
Merging asm-generic/master (cb61f6769b88 ARM64: use GENERIC_PCI_IOMAP)
Mergin

[PATCH v2 3/3] ARM: dts: berlin: correct BG2Q's SM GPIO location.

[Jisheng Zhang]

The gpio4 and gpio5 are in 0xf7fc apb which is located in the SM domain.
This patch moves gpio4 and gpio5 to the correct location. This patch also
renames them as the following to match the names we internally used in
marvell:
gpio4 -> sm_gpio1
gpio5 -> sm_gpio0
porte -> portf
portf -> porte

This also matches what we did for BG2 and BG2CD's SM GPIO.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/boot/dts/berlin2q.dtsi | 60 -
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 41a683f..f0ddbec 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -356,36 +356,6 @@
interrupt-parent = <&gic>;
interrupts = ;
};
-
-   gpio4: gpio@5000 {
-   compatible = "snps,dw-apb-gpio";
-   reg = <0x5000 0x400>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   porte: gpio-port@4 {
-   compatible = "snps,dw-apb-gpio-port";
-   gpio-controller;
-   #gpio-cells = <2>;
-   snps,nr-gpios = <32>;
-   reg = <0>;
-   };
-   };
-
-   gpio5: gpio@c000 {
-   compatible = "snps,dw-apb-gpio";
-   reg = <0xc000 0x400>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   portf: gpio-port@5 {
-   compatible = "snps,dw-apb-gpio-port";
-   gpio-controller;
-   #gpio-cells = <2>;
-   snps,nr-gpios = <32>;
-   reg = <0>;
-   };
-   };
};
 
chip: chip-control@ea {
@@ -474,6 +444,21 @@
ranges = <0 0xfc 0x1>;
interrupt-parent = <&sic>;
 
+   sm_gpio1: gpio@5000 {
+   compatible = "snps,dw-apb-gpio";
+   reg = <0x5000 0x400>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   portf: gpio-port@5 {
+   compatible = "snps,dw-apb-gpio-port";
+   gpio-controller;
+   #gpio-cells = <2>;
+   snps,nr-gpios = <32>;
+   reg = <0>;
+   };
+   };
+
i2c2: i2c@7000 {
compatible = "snps,designware-i2c";
#address-cells = <1>;
@@ -524,6 +509,21 @@
status = "disabled";
};
 
+   sm_gpio0: gpio@c000 {
+   compatible = "snps,dw-apb-gpio";
+   reg = <0xc000 0x400>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   porte: gpio-port@4 {
+   compatible = "snps,dw-apb-gpio-port";
+   gpio-controller;
+   #gpio-cells = <2>;
+   snps,nr-gpios = <32>;
+   reg = <0>;
+   };
+   };
+
sysctrl: pin-controller@d000 {
compatible = "marvell,berlin2q-system-ctrl";
reg = <0xd000 0x100>;
-- 
2.1.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 v2 1/3] ARM: dts: berlin: add pmu node for BG2Q and BG2CD

[Jisheng Zhang]

This patch adds the pmu node, enabling the PMU unit on Marvell BG2Q and
BG2CD SoCs.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/boot/dts/berlin2cd.dtsi | 5 +
 arch/arm/boot/dts/berlin2q.dtsi  | 8 
 2 files changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 230df3b..a318bc3 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -45,6 +45,11 @@
 
ranges = <0 0xf700 0x100>;
 
+   pmu {
+   compatible = "arm,cortex-a9-pmu";
+   interrupts = ;
+   };
+
sdhci0: sdhci@ab {
compatible = "mrvl,pxav3-mmc";
reg = <0xab 0x200>;
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 35253c9..933dcbb 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -63,6 +63,14 @@
ranges = <0 0xf700 0x100>;
interrupt-parent = <&gic>;
 
+   pmu {
+   compatible = "arm,cortex-a9-pmu";
+   interrupts = ,
+,
+,
+;
+   };
+
sdhci0: sdhci@ab {
compatible = "mrvl,pxav3-mmc";
reg = <0xab 0x200>;
-- 
2.1.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 v2 0/3] ARM: dts: berlin: add PMU and twd's cpu mask and fix GPIO locations

[Jisheng Zhang]

These patches try to improve dts for berlin. One of them enables PMU support
to BG2Q and BG2CD SoCs. One of them adds the missing PPI cpu mask to twd timer
interrupts. The last one corrects the SM GPIOs' location for BG2Q SoC.

Changes since v1:
 - Adds some text to the log of the second commit
 - Adds the patch to fix SM GPIO locations

Jisheng Zhang (3):
  ARM: dts: berlin: add pmu node for BG2Q and BG2CD
  ARM: dts: berlin: add PPI cpu mask to twd timer interrupts
  ARM: dts: berlin: correct BG2Q's SM GPIO location.

 arch/arm/boot/dts/berlin2.dtsi   |  2 +-
 arch/arm/boot/dts/berlin2cd.dtsi |  7 +++-
 arch/arm/boot/dts/berlin2q.dtsi  | 70 ++--
 3 files changed, 46 insertions(+), 33 deletions(-)

-- 
2.1.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 v2 2/3] ARM: dts: berlin: add PPI cpu mask to twd timer interrupts

[Jisheng Zhang]

According to the gic binding document, "bits[15:8] PPI interrupt cpu
mask.  Each bit corresponds to each of the 8 possible cpus attached to
the GIC.  A bit set to '1' indicated the interrupt is wired to that
CPU." This patch wants to add the PPI cpu mask for completeness.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/boot/dts/berlin2.dtsi   | 2 +-
 arch/arm/boot/dts/berlin2cd.dtsi | 2 +-
 arch/arm/boot/dts/berlin2q.dtsi  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 015a06c..63d00a6 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -104,7 +104,7 @@
local-timer@ad0600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0xad0600 0x20>;
-   interrupts = ;
+   interrupts = ;
clocks = <&chip CLKID_TWD>;
};
 
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index a318bc3..81b670a 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -76,7 +76,7 @@
local-timer@ad0600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0xad0600 0x20>;
-   interrupts = ;
+   interrupts = ;
clocks = <&chip CLKID_TWD>;
};
 
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 933dcbb..41a683f 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -112,7 +112,7 @@
compatible = "arm,cortex-a9-twd-timer";
reg = <0xad0600 0x20>;
clocks = <&chip CLKID_TWD>;
-   interrupts = ;
+   interrupts = ;
};
 
gic: interrupt-controller@ad1000 {
-- 
2.1.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 v4 0/3] Add Reset Controller for MediaTek SoC

[Flora Fu]

Hi,
This driver implements the reset controller for MediaTek SoC.
It adds support for MT8135 and MT8173 SoC in the patch set.
The reset controller uses syscon as its regmap and adopts syscon RFC in 
https://lkml.org/lkml/2014/11/3/134.

This driver is based on 3.19-rc1.

Changes since v3

1. Merge patch set by 3.19-rc1.
2. Add header file "mt8173-resets.h" for supported resets in MT8173.

Changes since v2

- Correct #size-cell to be 1.
- Add header file "mt8135-resets.h" for supported resets in MT8135.

Changes since v1

(1) Patch 1/3: Update reset controller driver's implementation. 
  - rename mt_ prefixes to the prefix mtk_
  - use module_platform_driver() macro for driver init.
  - clean up includes of header files.
  - reset controll is a child of syscon. Get regamp through its parent node.
  - rename data->size to data->num_regs. It is number of registers in syscon 
for reset usage. 
(2) Patch 2/3: update bindings document according to new dts layout of 
reset-controller. 
(3) Patch 3/3: change reset-controller device node as child of syscon. 

Flora Fu (3):
  reset: mediatek: Add Reset Controller for MediaTek SoC
  dt-bindings: Add Reset Controller for MediaTek SoC
  arm: dts: mt8135: Add Reset Controller for MediaTek SoC

 .../devicetree/bindings/reset/mediatek,reset.txt   |  52 +
 arch/arm/boot/dts/mt8135.dtsi  |  29 +
 drivers/reset/Makefile |   1 +
 drivers/reset/reset-mtk.c  | 130 +
 .../dt-bindings/reset-controller/mt8135-resets.h   |  64 ++
 .../dt-bindings/reset-controller/mt8173-resets.h   |  63 ++
 6 files changed, 339 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/mediatek,reset.txt
 create mode 100644 drivers/reset/reset-mtk.c
 create mode 100644 include/dt-bindings/reset-controller/mt8135-resets.h
 create mode 100644 include/dt-bindings/reset-controller/mt8173-resets.h

--
1.8.1.1.dirty


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

[PATCH v4 1/3] reset: mediatek: Add Reset Controller for MediaTek SoC

[Flora Fu]

Add a driver in reset controller.

Signed-off-by: Flora Fu 
---
 drivers/reset/Makefile |   1 +
 drivers/reset/reset-mtk.c  | 130 +
 .../dt-bindings/reset-controller/mt8135-resets.h   |  64 ++
 .../dt-bindings/reset-controller/mt8173-resets.h   |  63 ++
 4 files changed, 258 insertions(+)
 create mode 100644 drivers/reset/reset-mtk.c
 create mode 100644 include/dt-bindings/reset-controller/mt8135-resets.h
 create mode 100644 include/dt-bindings/reset-controller/mt8173-resets.h

diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 157d421..d81a60a 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_ARCH_MEDIATEK) += reset-mtk.o
diff --git a/drivers/reset/reset-mtk.c b/drivers/reset/reset-mtk.c
new file mode 100644
index 000..ccdd4bb
--- /dev/null
+++ b/drivers/reset/reset-mtk.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Flora Fu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct mtk_reset_data {
+   struct regmap *regmap;
+   u32 resetbase;
+   u32 num_regs;
+   struct reset_controller_dev rcdev;
+};
+
+static int mtk_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+   struct regmap *regmap;
+   u32 addr;
+   u32 mask;
+   struct mtk_reset_data *data = container_of(rcdev,
+struct mtk_reset_data,
+rcdev);
+   regmap = data->regmap;
+   addr = data->resetbase + ((id / 32) << 2);
+   mask = BIT(id % 32);
+
+   return regmap_update_bits(regmap, addr, mask, mask);
+}
+
+static int mtk_reset_deassert(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   struct regmap *regmap;
+   u32 addr;
+   u32 mask;
+   struct mtk_reset_data *data = container_of(rcdev,
+struct mtk_reset_data,
+rcdev);
+
+   regmap = data->regmap;
+   addr = data->resetbase + ((id / 32) << 2);
+   mask = BIT(id % 32);
+
+   return regmap_update_bits(regmap, addr, mask, ~mask);
+}
+
+static struct reset_control_ops mtk_reset_ops = {
+   .assert = mtk_reset_assert,
+   .deassert = mtk_reset_deassert,
+};
+
+static int mtk_reset_probe(struct platform_device *pdev)
+{
+   struct mtk_reset_data *data;
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *syscon_np;
+   u32 reg[2];
+   int ret;
+
+   data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
+
+   syscon_np = of_get_parent(np);
+   data->regmap = syscon_node_to_regmap(syscon_np);
+   of_node_put(syscon_np);
+   if (IS_ERR(data->regmap)) {
+   dev_err(&pdev->dev, "couldn't get syscon-reset regmap\n");
+   return PTR_ERR(data->regmap);
+   }
+   ret = of_property_read_u32_array(np, "reg", reg, 2);
+   if (ret) {
+   dev_err(&pdev->dev, "couldn't read reset base from syscon!\n");
+   return -EINVAL;
+   }
+
+   data->resetbase = reg[0];
+   data->num_regs = reg[1] >> 2;
+   data->rcdev.owner = THIS_MODULE;
+   data->rcdev.nr_resets = data->num_regs * 32;
+   data->rcdev.ops = &mtk_reset_ops;
+   data->rcdev.of_node = pdev->dev.of_node;
+
+   return reset_controller_register(&data->rcdev);
+}
+
+static int mtk_reset_remove(struct platform_device *pdev)
+{
+   struct mtk_reset_data *data = platform_get_drvdata(pdev);
+
+   reset_controller_unregister(&data->rcdev);
+
+   return 0;
+}
+
+static const struct of_device_id mtk_reset_dt_ids[] = {
+   { .compatible = "mediatek,reset", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, mtk_reset_dt_ids);
+
+static struct platform_driver mtk_reset_driver = {
+   .probe = mtk_reset_probe,
+   .remove = mtk_reset_remove,
+   .driver = {
+   .name = "mtk-reset",
+   .of_match_table = mtk_reset_dt_ids,
+   },
+};
+
+module_platform_driver(mtk_reset_driver);
+
+MODULE_AUTHOR("Flora Fu ");
+MODULE_DESCRIPTION("MediaTe

[PATCH v4 2/3] dt-bindings: Add Reset Controller for MediaTek SoC

[Flora Fu]

Add device tree bindings.

Acked-by: Philipp Zabel 
Signed-off-by: Flora Fu 
---
 .../devicetree/bindings/reset/mediatek,reset.txt   | 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/mediatek,reset.txt

diff --git a/Documentation/devicetree/bindings/reset/mediatek,reset.txt 
b/Documentation/devicetree/bindings/reset/mediatek,reset.txt
new file mode 100644
index 000..647b401
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/mediatek,reset.txt
@@ -0,0 +1,52 @@
+MediaTek SoC Reset Controller
+==
+The reset controller driver accesses registers through the syscon regmap. It
+is a child node of syscon.
+
+Required properties:
+- compatible : "mediatek,reset"
+- #reset-cells: 1
+- reg: The register region can be accessed from syscon. The first parameter is
+  reset base address offset. The second parameter is byte width of reset 
registers.
+
+example:
+infracfg: syscon@10001000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "mediatek,mt8135-infracfg", "syscon";
+   reg = <0 0x10001000 0 0x1000>;
+
+   infrarst: reset-controller@30 {
+   #reset-cells = <1>;
+   compatible = "mediatek,mt8135-infracfg-reset", "mediatek,reset";
+   reg = <0x30 0x8>;
+   };
+};
+
+Specifying reset lines connected to IP modules
+==
+
+The reset controller(mtk-reset) manages various reset sources. Those device 
nodes should
+specify the reset line on the rstc in their resets property, containing a 
phandle to the
+rstc device node and a RESET_INDEX specifying which module to reset, as 
described in
+reset.txt.
+
+For MediaTek SoC, RESET_INDEX is reset bit defined in INFRACFG or PERICFG 
registers.
+
+example:
+pwrap: pwrap@1000f000 {
+   compatible = "mediatek,mt8135-pwrap";
+   reg = <0 0x1000f000 0 0x1000>,
+   <0 0x11017000 0 0x1000>;
+   reg-names = "pwrap-base",
+   "pwrap-bridge-base";
+   resets = <&infrarst MT8135_INFRA_PMIC_WRAP_RST>,
+   <&perirst MT8135_PERI_PWRAP_BRIDGE_SW_RST>;
+   reset-names = "infrarst", "perirst";
+};
+
+Definitions for the supported resets by IC:
+MT8135:
+include/dt-bindings/reset-controller/mt8135-resets.h
+MT8173:
+include/dt-bindings/reset-controller/mt8173-resets.h
-- 
1.8.1.1.dirty

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

[PATCH v4 3/3] arm: dts: mt8135: Add Reset Controller for MediaTek SoC

[Flora Fu]

Add reset controller to MT8135.dtsi.

Acked-by: Philipp Zabel 
Signed-off-by: Flora Fu 
---
 arch/arm/boot/dts/mt8135.dtsi | 29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/mt8135.dtsi b/arch/arm/boot/dts/mt8135.dtsi
index ec83e69..989e488 100644
--- a/arch/arm/boot/dts/mt8135.dtsi
+++ b/arch/arm/boot/dts/mt8135.dtsi
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include "skeleton64.dtsi"
 
 / {
@@ -100,6 +101,34 @@
compatible = "simple-bus";
ranges;
 
+   infracfg: syscon@10001000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "mediatek,mt8135-infracfg", "syscon";
+   reg = <0 0x10001000 0 0x1000>;
+   #clock-cells = <1>;
+
+   infrarst: reset-controller@30 {
+   #reset-cells = <1>;
+   compatible = "mediatek,mt8135-infracfg-reset", 
"mediatek,reset";
+   reg = <0x30 0x8>;
+   };
+   };
+
+   pericfg: syscon@10003000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "mediatek,mt8135-pericfg", "syscon";
+   reg = <0 0x10003000 0 0x1000>;
+   #clock-cells = <1>;
+
+   perirst: reset-controller@00 {
+   #reset-cells = <1>;
+   compatible = "mediatek,mt8135-pericfg-reset", 
"mediatek,reset";
+   reg = <0x00 0x8>;
+   };
+   };
+
timer: timer@10008000 {
compatible = "mediatek,mt8135-timer",
"mediatek,mt6577-timer";
-- 
1.8.1.1.dirty

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

[PATCH v4] mmc: dw_mmc: add quirk for broken data transfer over scheme

[Addy Ke]

This patch add a new quirk to add a s/w timer to notify the driver
to terminate current transfer and report a data timeout to the core,
if DTO interrupt does NOT come within the given time.

dw_mmc call mmc_request_done func to finish transfer depends on
DTO interrupt. If DTO interrupt does not come in sending data state,
the current transfer will be blocked.

We got the reply from synopsys:
There are two counters but both use the same value of [31:8] bits.
Data timeout counter doesn't wait for stop clock and you should get
DRTO even when the clock is not stopped.
Host Starvation timeout counter is triggered with stop clock condition.

This means that host should get DRTO and DTO interrupt.

But this case really exists, when driver reads tuning data from
card on RK3288-pink2 board. I measured waveforms by oscilloscope
and found that card clock was always on and data lines were always
holded high level in sending data state.

There are two possibility that data over interrupt doesn't come in
reading data state on RK3X SoCs:
- get command done interrupt, but doesn't get any data-related interrupt.
- get data error interrupt, but doesn't get data over interrupt.

We don't know why we have this problem, but we need it to fix this problem now.
And I will post a follow up change when we find the root cause.

Signed-off-by: Addy Ke 
---
Changes in v2:
- fix some typo.
- remove extra timeout value (250ms).
- remove dw_mci_dto_start_monitor func.
- use "broken-dto" for new quirk and change Subject for it.

Changes in v3:
- Remove dts for broken-dto, just add this quirk in dw_mci_rockchip_init

Changes in v4:
- fix bug that may cause 32 bit overflow by (drto_clks * 1000).
- doesn't call mod_timer in writing data state, becase TMOUT register only
  for reading data.

 drivers/mmc/host/dw_mmc-rockchip.c |  3 ++
 drivers/mmc/host/dw_mmc.c  | 64 --
 include/linux/mmc/dw_mmc.h |  5 +++
 3 files changed, 70 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c 
b/drivers/mmc/host/dw_mmc-rockchip.c
index 5650ac4..ba92ebd 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -73,6 +73,9 @@ static int dw_mci_rockchip_init(struct dw_mci *host)
/* It is slot 8 on Rockchip SoCs */
host->sdio_id0 = 8;
 
+   /* It needs this quirk on all Rockchip SoCs */
+   host->pdata->quirks |= DW_MCI_QUIRK_BROKEN_DTO;
+
return 0;
 }
 
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 6e4d864..385dc0f 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1477,6 +1477,8 @@ static void dw_mci_tasklet_func(unsigned long priv)
enum dw_mci_state state;
enum dw_mci_state prev_state;
unsigned int err;
+   unsigned int drto_clks;
+   unsigned int drto_ms;
 
spin_lock(&host->lock);
 
@@ -1542,8 +1544,22 @@ static void dw_mci_tasklet_func(unsigned long priv)
}
 
if (!test_and_clear_bit(EVENT_XFER_COMPLETE,
-   &host->pending_events))
+   &host->pending_events)) {
+   drto_clks = mci_readl(host, TMOUT) >> 8;
+   drto_ms = DIV_ROUND_UP(drto_clks,
+  host->bus_hz / 1000);
+
+   /*
+* If all data-related interrupts don't come
+* within the given time in reading data state.
+* */
+   if ((host->quirks & DW_MCI_QUIRK_BROKEN_DTO) &&
+   (host->dir_status == DW_MCI_RECV_STATUS)) {
+   mod_timer(&host->dto_timer, jiffies +
+ msecs_to_jiffies(drto_ms));
+   }
break;
+   }
 
set_bit(EVENT_XFER_COMPLETE, &host->completed_events);
 
@@ -1573,8 +1589,22 @@ static void dw_mci_tasklet_func(unsigned long priv)
 
case STATE_DATA_BUSY:
if (!test_and_clear_bit(EVENT_DATA_COMPLETE,
-   &host->pending_events))
+   &host->pending_events)) {
+   drto_clks = mci_readl(host, TMOUT) >> 8;
+   drto_ms = DIV_ROUND_UP(drto_clks,
+  host->bus_hz / 1000);
+   /*
+* If data error interrupt comes but data over
+* interrupt doesn't come within the given time.
+* in reading data state.
+  

Re: [PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd

[Laurent Pinchart]

Hi Thierry,

On Thursday 25 December 2014 14:20:59 Thierry Reding wrote:
> On Mon, Dec 22, 2014 at 01:07:13PM +0200, Oded Gabbay wrote:
> > This small patch-set, was created to solve the bug described at
> > https://bugzilla.kernel.org/show_bug.cgi?id=89661 (Kernel panic when
> > trying use amdkfd driver on Kaveri). It replaces the previous patch-set
> > called [PATCH 0/3] Use workqueue for device init in amdkfd
> > (http://lists.freedesktop.org/archives/dri-devel/2014-December/074401.html
> > )
> > 
> > That bug appears only when radeon, amdkfd and amd_iommu_v2 are compiled
> > inside the kernel (not as modules). In that case, the correct loading
> > order, as determined by the exported symbol used by each driver, is
> > not enforced anymore and the kernel loads them based on who was linked
> > first. That makes radeon load first, amdkfd second and amd_iommu_v2
> > third.
> > 
> > Because the initialization of a device in amdkfd is initiated by radeon,
> > and can only be completed if amdkfd and amd_iommu_v2 were loaded and
> > initialized, then in the case mentioned above, this initalization fails
> > and there is a kernel panic as some pointers are not initialized but
> > used nontheless.
> > 
> > To solve this bug, this patch-set moves iommu/ before gpu/ in
> > drivers/Makefile and also moves amdkfd/ before radeon/ in
> > drivers/gpu/drm/Makefile.
> > 
> > The rationale is that in general, AMD GPU devices are dependent on AMD
> > IOMMU controller functionality to allow the GPU to access a process's
> > virtual memory address space, without the need for pinning the memory.
> > That's why it makes sense to initialize the iommu/ subsystem ahead of the
> > gpu/ subsystem.
>
> I strongly object to this patch set. This makes assumptions about how
> the build system influences probe order. That's bad because seemingly
> unrelated changes could easily break this in the future.
> 
> We already have ways to solve this kind of dependency (driver probe
> deferral), and I think you should be using it to solve this particular
> problem rather than some linking order hack.

While I agree with you that probe deferral is the way to go, I believe linkage 
ordering can still be used as an optimization to avoid deferring probe in the 
most common cases. I'm thus not opposed to moving iommu/ earlier in link order 
(provided we can properly test for side effects, as the jump is pretty large), 
but not as a replacement for probe deferral.

> Coincidentally there's a separate thread currently going on that deals
> with IOMMUs and probe order. The solution being worked on is currently
> somewhat ARM-specific, so adding a couple of folks for visibility. It
> looks like we're going to need something more generic since this is a
> problem that even the "big" architectures need to solve.

-- 
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: [PATCH] Drivers: bcma: Fix three coding style issues, more than 80 characters per line.

[Rafał Miłecki]

On 24 December 2014 at 08:20, Kalle Valo  wrote:
> Oscar Forner Martinez  writes:
>
>> Three lines with more than 80 characters per line have been split in several 
>> lines.
>>
>> Signed-off-by: Oscar Forner Martinez 
>> ---
>>  drivers/bcma/driver_chipcommon.c | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> Just to handle the bureaucracy before v2 is submitted:
>
> To which tree should this go to? I see that earlier John has applied
> patches to drivers/bcma/, but what about now? Should I take these? John,
> any suggestions?

bcma is a bus with multiple cores (devices)

As some of cores (devices) are very simply to handle and/or they are
needed very early (e.g. for initialization), bcma has:
1) Few bult-in drivers (like MIPS, ChipCommon)
2) Few "external" drivers using standard bus mechanism (e.g. b43,
brcmsmac, bgmac)

I guess the biggest bcma users are wireless drivers, so bcma was also
maintained using wireless tree. Unfortunately bus can't be just setup
once and not touched anymore. Drivers often need to touch ChipCommon
so there are some export_symbol-s in driver_chipcommon.c and you also
can get patchset-s touching bcma and then wireless driver.

Of course there are some problems with such maintenance. Rarely I've
to do changes in arch/mips/bcm47xx/ code, wait for a release and then
change sth in drivers/bcma. But I don't see a better solution for all
of this.

-- 
Rafał
--
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/4] mtd: nand: atmel: Rework driver to separate nfc and nand nodes

[Josh Wu]

Hi, Boris

On 12/5/2014 6:30 AM, Boris Brezillon wrote:

mtd: nand: atmel: Update DT documentation after splitting NFC and NAND

The NAND and NFC (NAND Flash Controller) were linked together with a
parent <-> child relationship.

This model has several drawbacks:
- it does not allow for multiple NAND chip handling while the controller
   support multi-chip (even though the driver is not ready yet)
- it mixes NAND partitions and NFC nodes at the same level (which is a bit
   disturbing)
- the introduction of the EBI bus implies defining NAND chips under the
   EBI node, and the ranges available under the EBI node should be
   restricted to EBI address space, while the NFC references several
   registers outside of these EBI ranges.

Move the NFC node outside of the NAND node, to get a more future-proof
DT representation.

Signed-off-by: Boris Brezillon 

I'm fine with this patch.
Acked-by: Josh Wu 

Best Regards,
Josh Wu


---
  drivers/mtd/nand/atmel_nand.c | 76 ++-
  1 file changed, 61 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 19d1e9d..0239fe6 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -123,6 +123,7 @@ struct atmel_nand_host {
struct dma_chan *dma_chan;
  
  	struct atmel_nfc	*nfc;

+   boolwait_for_nfc;
  
  	bool			has_pmecc;

u8  pmecc_corr_cap;
@@ -1423,6 +1424,12 @@ static void atmel_nand_hwctl(struct mtd_info *mtd, int 
mode)
ecc_writel(host->ecc, CR, ATMEL_ECC_RST);
  }
  
+static const struct of_device_id atmel_nand_nfc_match[] = {

+   { .compatible = "atmel,sama5d3-nfc" },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, atmel_nand_nfc_match);
+
  static int atmel_of_init_port(struct atmel_nand_host *host,
  struct device_node *np)
  {
@@ -1431,6 +1438,7 @@ static int atmel_of_init_port(struct atmel_nand_host 
*host,
int ecc_mode;
struct atmel_nand_data *board = &host->board;
enum of_gpio_flags flags = 0;
+   struct device_node *child;
  
  	if (of_property_read_u32(np, "atmel,nand-addr-offset", &val) == 0) {

if (val >= 32) {
@@ -1467,8 +1475,30 @@ static int atmel_of_init_port(struct atmel_nand_host 
*host,
  
  	host->has_pmecc = of_property_read_bool(np, "atmel,has-pmecc");
  
-	/* load the nfc driver if there is */

-   of_platform_populate(np, NULL, NULL, host->dev);
+   /*
+* Backward compatibility with DTs defining the NFC node as their
+* child.
+* The new model reference the NFC so that we can define several
+* chip controlled by the same controller.
+*/
+   for_each_available_child_of_node(np, child) {
+   /*
+* If we find an NFC node under the NAND node, then populate
+* the device so that it can be probed, and wait for it.
+*/
+   if (of_match_node(atmel_nand_nfc_match, child)) {
+   of_platform_populate(np, NULL, NULL, host->dev);
+   host->wait_for_nfc = true;
+   break;
+   }
+   }
+
+   /*
+* If there's an atmel,nfc property we should access the NAND
+* through the NFC.
+*/
+   if (of_property_read_bool(np, "atmel,nfc"))
+   host->wait_for_nfc = true;
  
  	if (!(board->ecc_mode == NAND_ECC_HW) || !host->has_pmecc)

return 0;   /* Not using PMECC */
@@ -2032,10 +2062,6 @@ static int atmel_nand_probe(struct platform_device *pdev)
if (!host)
return -ENOMEM;
  
-	res = platform_driver_register(&atmel_nand_nfc_driver);

-   if (res)
-   dev_err(&pdev->dev, "atmel_nand: can't register NFC driver\n");
-
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
host->io_base = devm_ioremap_resource(&pdev->dev, mem);
if (IS_ERR(host->io_base)) {
@@ -2089,6 +2115,13 @@ static int atmel_nand_probe(struct platform_device *pdev)
goto err_nand_ioremap;
}
} else {
+   /*
+* If the NFC is not initialized (or not probed) and the device
+* is asking to be accessed through the NFC then defer the
+* probe.
+*/
+   if (host->wait_for_nfc)
+   return -EPROBE_DEFER;
res = atmel_nand_set_enable_ready_pins(mtd);
if (res)
goto err_nand_ioremap;
@@ -2230,8 +2263,6 @@ static int atmel_nand_remove(struct platform_device *pdev)
if (host->dma_chan)
dma_release_channel(host->dma_chan);
  
-	platform_driver_unregister(&atmel_nand_nfc_driver);

-
return 0;
  }
  
@@ -2303,12 +2334,6 @@ static int atmel_nand_nfc_remove(struct platform_device *

Re: [PATCH 2/4] mtd: nand: atmel: Update DT documentation after splitting NFC and NAND

[Josh Wu]

Hi, Boris

Thanks for the patch.

You need to rebase on the top of current mtd-l2 git tree. As I had some 
change on the binding document.


Best Regards,
Josh Wu

On 12/5/2014 6:30 AM, Boris Brezillon wrote:

The NAND and NFC (NAND Flash Controller) were linked together with a
parent <-> child relationship.

This model has several drawbacks:
- it does not allow for multiple NAND chip handling while the controller
   support multi-chip (even though the driver is not ready yet)
- it mixes NAND partitions and NFC nodes at the same level (which is a bit
   disturbing)
- the introduction of the EBI bus implies defining NAND chips under the
   EBI node, and the ranges available under the EBI node should be
   restricted to EBI address space, while the NFC references several
   registers outside of these EBI ranges.

Move the NFC node outside of the NAND node, to get a more future-proof
model.

Signed-off-by: Boris Brezillon 
---
  .../devicetree/bindings/mtd/atmel-nand.txt | 46 --
  1 file changed, 26 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt 
b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index 6edc3b6..8896850 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -30,15 +30,19 @@ Optional properties:
sector size 1024.
  - nand-bus-width : 8 or 16 bus width if not present 8
  - nand-on-flash-bbt: boolean to enable on flash bbt option if not present 
false
-- Nand Flash Controller(NFC) is a slave driver under Atmel nand flash
-  - Required properties:
-- compatible : "atmel,sama5d3-nfc".
-- reg : should specify the address and size used for NFC command registers,
-NFC registers and NFC Sram. NFC Sram address and size can be absent
-if don't want to use it.
-- clocks: phandle to the peripheral clock
-  - Optional properties:
-- atmel,write-by-sram: boolean to enable NFC write by sram.
+- atmel,nfc: phandle referencing the NAND Flash Controller, if available.
+
+The NAND Flash Controller (NFC) is an advanced NAND controller and should be
+used in conjunction with the NAND flash device.
+Required properties:
+ - compatible : "atmel,sama5d3-nfc".
+ - reg : should specify the address and size used for NFC command registers,
+ NFC registers and NFC Sram. NFC Sram address and size can be absent
+ if you don't want to use it.
+ - clocks: phandle to the peripheral clock
+
+Optional properties:
+ - atmel,write-by-sram: boolean to enable NFC write by sram.
  
  Examples:

  nand0: nand@4000,0 {
@@ -89,21 +93,23 @@ nand0: nand@4000 {
  };
  
  /* for NFC supported chips */

+nfc: nfc@7000 {
+   compatible = "atmel,sama5d3-nfc";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   clocks = <&hsmc_clk>
+   reg = <
+   0x7000 0x1000   /* NFC Command Registers */
+   0xc000 0x0070   /* NFC HSMC regs */
+   0x0020 0x0010   /* NFC SRAM banks */
+   >;
+};
+
  nand0: nand@4000 {
compatible = "atmel,at91rm9200-nand";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+   atmel,nfc = <&nfc>;
  ...
-nfc@7000 {
-   compatible = "atmel,sama5d3-nfc";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   clocks = <&hsmc_clk>
-   reg = <
-   0x7000 0x1000   /* NFC Command Registers */
-   0xc000 0x0070   /* NFC HSMC regs */
-   0x0020 0x0010   /* NFC SRAM banks */
-   >;
-   };
  };


--
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/

panic at rb_next when do pick_next_task_fair because of rb_leftmost is NULL

[Neil Zhang]

Hi All,
I encountered the following crash in 3.10.24.

The panic log is as following.
The strange thing is that the nr_running change to NULL after pass the
check in the beginning of pick_next_task_fair.
So it seems there are race condition in the code.
Seems no related patch to fix it in the mainline.
Does anyone can help it?

struct rq {
lock = {
raw_lock = {
{
slock = 1463113524,
tickets = {
owner = 22324,
next = 22325
}
}
}
},
nr_running = 0,
cpu_load = {0, 0, 3, 33, 72},
last_load_update_tick = 83021764,
nohz_stamp = 0,
nohz_flags = 1,
skip_clock_update = 0,
nr_last_stamp = 83321795255303,
nr_running_integral = 54283347762368512,
ave_seqcnt = {
sequence = 690446180
},
load = {
weight = 0,
inv_weight = 0
},
nr_load_updates = 51751174,
nr_switches = 290795987,
cfs = {
load = {
weight = 0,
inv_weight = 0
},
nr_running = 0,
h_nr_running = 0,
exec_clock = 17025953367624,
min_vruntime = 125082978146967,
min_vruntime_copy = 125082978146967,
tasks_timeline = {
rb_node = 0x0
},
rb_leftmost = 0x0,
curr = 0x0,
next = 0x0,
last = 0x0,
skip = 0x0,
nr_spread_over = 57488,
runnable_load_avg = 0,

[83321.795281] c0 2084 (v.airplayserver) Unable to handle kernel NULL
pointer dereference at virtual address 0008
[83321.795286] c0 2084 (v.airplayserver) pgd = ea858000
[83321.795293] c0 2084 (v.airplayserver) [0008] *pgd=
[83321.795306] c0 2084 (v.airplayserver) Internal error: Oops: 205
[#1] PREEMPT SMP ARM
[83321.795315] c0 2084 (v.airplayserver) Modules linked in:
[83321.795324] c0 2084 (v.airplayserver) CPU: 0 PID: 2084 Comm:
v.airplayserver Not tainted 3.10.24-gc7b472f #1
[83321.795329] c0 2084 (v.airplayserver) task: ce1f1ac0 ti: ce156000
task.ti: ce156000
[83321.795349] c0 2084 (v.airplayserver) PC is at rb_next+0x0/0x60
[83321.795363] c0 2084 (v.airplayserver) LR is at
pick_next_task_fair+0x10c/0x138
[83321.795368] c0 2084 (v.airplayserver) pc : [] lr :
[] psr: 60060093
sp : ce157e18 ip :  fp : ce157edc
[83321.795371] c0 2084 (v.airplayserver) r10: c54474c0 r9 : c0c644c0
r8 : ce157f20
[83321.795376] c0 2084 (v.airplayserver) r7 : c54474c0 r6 : 
r5 :  r4 : c5447518
[83321.795380] c0 2084 (v.airplayserver) r3 : c0097294 r2 : c54478f8
r1 :  r0 : 0008
[83321.795388] c0 2084 (v.airplayserver) Flags: nZCv IRQs off FIQs on
Mode SVC_32 ISA ARM Segment user
[83321.795392] c0 2084 (v.airplayserver) Control: 30c5387d Table:
aa858000 DAC: fffd
[83321.795396] c0 2084 (v.airplayserver)
PC: 0xc02c2270:
[83321.795419] c0 2084 (v.airplayserver) 2270 1a01 ea04
e1a3 e5903004 e353 1afb e12fff1e e12fff1e
[83321.795439] c0 2084 (v.airplayserver) 2290 e1a03001 e5901000
e3d11003 05823000 0a03 e5912008 e152 05813008
[83321.795461] c0 2084 (v.airplayserver) 22b0 15813004 e5902008
e352 15921000 12011001 11831001 15821000 e5902004
[83321.795483] c0 2084 (v.airplayserver) 22d0 e352 15921000
12011001 11831001 15821000 e897 e8830007 e12fff1e
[83321.795504] c0 2084 (v.airplayserver) 22f0 e5902000 e152
0a12 e5903004 e353 1a01 ea06 e1a03002
[83321.795526] c0 2084 (v.airplayserver) 2310 e5932008 e352
1afb e1a3 e12fff1e e5932000 e3d23003 0afa
[83321.795546] c0 2084 (v.airplayserver) 2330 e5932004 e152
e1a3 0af8 e1a3 e12fff1e e3a03000 eaf2
[83321.795568] c0 2084 (v.airplayserver) 2350 e5902000 e152
0a12 e5903008 e353 1a01 ea06 e1a03002
[83321.795572] c0 2084 (v.airplayserver)
LR: 0xc0097320:
[83321.795592] c0 2084 (v.airplayserver) 7320 e5954128 e354
1ae1 e59f3090 e2455038 e5933000 e3130080 0a13
[83321.795612] c0 2084 (v.airplayserver) 7340 e59734e4 e283101f
e353 e203201f b1a03001 e59f106c e1a032c3 e5911000
[83321.795635] c0 2084 (v.airplayserver) 7360 e7913103 e1a03233
e3130001 0a07 e597355c e5933000 e5933018 e353
[83321.795657] c0 2084 (v.airplayserver) 7380 0a02 e1a7
e1a01005 ebfffe2a e1a5 e8bd80f8 e2860008 eb08abd3
[83321.795681] c0 2084 (v.airplayserver) 73a0 e350 0ac9
e2405008 e1a01006 e1a5 eb0d e350 c1a05006
[83321.795702] c0 2084 (v.airplayserver) 73c0 eac2 c0c9b4b4
c08945bc e92d00f0 e52de004 e8bd4000 e3a02020 e3a03000
[83321.795724] c0 2084 (v.airplayserver) 73e0 e1530001 0152
3a04 e59f30ec e0830100 e59000e4 e8bd00f0 e12fff1e
[83321.795746] c0 2084 (v.airplayserver) 7400 e351 03500f56
8a2e e1a04000 e1a05001 e3e0601f e3e07000 e3a0c000
[83321.795751] c0 2084 (v.airplayserver)
SP: 0xce157d98:
[83321.795771] c0 2084 (v.airplayserver) 7d98 ed711dc0 
  c54474c0   0002
[83321.795795] c0 2084 (v.airplayserver) 7db8 c02c22f0 60060093
 ce157e04 ce157f20 c000ead8 0008 
[83321.795815] c0 2084 (v.airplayserver) 7dd8 c54478f8 c0097294
c5447518   c54474c0 ce157f20 c0c644c0
[83321.795838] c0 2084 (v.airplayserver) 7df8 c54474c0 ce157edc
 ce157e18 c00973a0 c02c22f0 60060093 
[83321.795861] c0 2084 (v.airplayserver) 7e18 

how to replace an existing I2C driver with my driver?

[Nick Yao]

Hi experts,


The existing driver has compatibility issues with my devices, and
there're other devices depend on the old driver.
I want to replace the existing I2C driver with my own driver while not
affect the other I2C devices.
How can I do it?

Thanks.

BRs.



Nick Yao
--
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-next 2/2] tun: enable socket system calls

[Jason Wang]

On 12/26/2014 02:50 PM, Alex Gartrell wrote:
> By setting private_data to a socket and private_data_is_socket to true, we
> can use the socket syscalls.  We also can't just blindly use private_data
> anymore, so there's a __tun_file_get function that returns the container_of
> private_data appropriately.

So this in fact expose other socket syscalls to userspace. But some of
proto_ops was not supported. E.g consider what happens if a bind() was
called for tun socket?
> Signed-off-by: Alex Gartrell 
> ---
>  drivers/net/tun.c | 34 ++
>  1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index a5cbf67..b16ddc5 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -547,9 +547,18 @@ static void tun_detach_all(struct net_device *dev)
>   module_put(THIS_MODULE);
>  }
>  
> +static struct tun_file *tun_file_from_file(struct file *file)
> +{
> + struct socket *s = (struct socket *)file->private_data;
> +
> + if (!s)

Can s be NULL here? If yes, why tun_get() didn't check for NULL?
> + return NULL;
> + return container_of(s, struct tun_file, socket);
> +}
> +
>  static int tun_attach(struct tun_struct *tun, struct file *file, bool 
> skip_filter)
>  {
> - struct tun_file *tfile = file->private_data;
> + struct tun_file *tfile = tun_file_from_file(file);
>   int err;
>  
>   err = security_tun_dev_attach(tfile->socket.sk, tun->security);
> @@ -612,7 +621,7 @@ static struct tun_struct *__tun_get(struct tun_file 
> *tfile)
>  
>  static struct tun_struct *tun_get(struct file *file)
>  {
> - return __tun_get(file->private_data);
> + return __tun_get(tun_file_from_file(file));
>  }
>  
>  static void tun_put(struct tun_struct *tun)
> @@ -973,7 +982,7 @@ static void tun_net_init(struct net_device *dev)
>  /* Poll */
>  static unsigned int tun_chr_poll(struct file *file, poll_table *wait)
>  {
> - struct tun_file *tfile = file->private_data;
> + struct tun_file *tfile = tun_file_from_file(file);
>   struct tun_struct *tun = __tun_get(tfile);
>   struct sock *sk;
>   unsigned int mask = 0;
> @@ -1235,7 +1244,7 @@ static ssize_t tun_chr_write_iter(struct kiocb *iocb, 
> struct iov_iter *from)
>  {
>   struct file *file = iocb->ki_filp;
>   struct tun_struct *tun = tun_get(file);
> - struct tun_file *tfile = file->private_data;
> + struct tun_file *tfile = tun_file_from_file(file);
>   ssize_t result;
>  
>   if (!tun)
> @@ -1392,7 +1401,7 @@ static ssize_t tun_do_read(struct tun_struct *tun, 
> struct tun_file *tfile,
>  static ssize_t tun_chr_read_iter(struct kiocb *iocb, struct iov_iter *to)
>  {
>   struct file *file = iocb->ki_filp;
> - struct tun_file *tfile = file->private_data;
> + struct tun_file *tfile = tun_file_from_file(file);
>   struct tun_struct *tun = __tun_get(tfile);
>   ssize_t len = iov_iter_count(to), ret;
>  
> @@ -1567,7 +1576,7 @@ static DEVICE_ATTR(group, 0444, tun_show_group, NULL);
>  static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
>  {
>   struct tun_struct *tun;
> - struct tun_file *tfile = file->private_data;
> + struct tun_file *tfile = tun_file_from_file(file);
>   struct net_device *dev;
>   int err;
>  
> @@ -1801,7 +1810,7 @@ static void tun_set_sndbuf(struct tun_struct *tun)
>  
>  static int tun_set_queue(struct file *file, struct ifreq *ifr)
>  {
> - struct tun_file *tfile = file->private_data;
> + struct tun_file *tfile = tun_file_from_file(file);
>   struct tun_struct *tun;
>   int ret = 0;
>  
> @@ -1834,7 +1843,7 @@ unlock:
>  static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
>   unsigned long arg, int ifreq_len)
>  {
> - struct tun_file *tfile = file->private_data;
> + struct tun_file *tfile = tun_file_from_file(file);
>   struct tun_struct *tun;
>   void __user* argp = (void __user*)arg;
>   struct ifreq ifr;
> @@ -2122,7 +2131,7 @@ static long tun_chr_compat_ioctl(struct file *file,
>  
>  static int tun_chr_fasync(int fd, struct file *file, int on)
>  {
> - struct tun_file *tfile = file->private_data;
> + struct tun_file *tfile = tun_file_from_file(file);
>   int ret;
>  
>   if ((ret = fasync_helper(fd, file, on, &tfile->fasync)) < 0)
> @@ -2165,7 +2174,8 @@ static int tun_chr_open(struct inode *inode, struct 
> file * file)
>   tfile->sk.sk_write_space = tun_sock_write_space;
>   tfile->sk.sk_sndbuf = INT_MAX;
>  
> - file->private_data = tfile;
> + file->private_data = &tfile->socket;
> + file->private_data_is_socket = true;
>   set_bit(SOCK_EXTERNALLY_ALLOCATED, &tfile->socket.flags);
>   INIT_LIST_HEAD(&tfile->next);
>  
> @@ -2176,7 +2186,7 @@ static int tun_chr_open(struct inode *inode, struct 
> file * file)
>  
>  static int tun_chr_close(struct inode *inode, struct file *file)
>  {
>

Re: [PATCH v7 1/3] of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint

[Laurent Pinchart]

Hi Philipp,

Thank you for the patch.

On Tuesday 23 December 2014 14:09:16 Philipp Zabel wrote:
> Decrementing the reference count of the previous endpoint node allows to
> use the of_graph_get_next_endpoint function in a for_each_... style macro.
> All current users of this function that pass a non-NULL prev parameter
> (coresight, rcar-du, imx-drm, soc_camera, and omap2-dss) are changed to
> not decrement the passed prev argument's refcount themselves.
> 
> Signed-off-by: Philipp Zabel 
> Acked-by: Mauro Carvalho Chehab 
> Acked-by: Mathieu Poirier 
> ---
> Changes since v6:
>  - Added omap2-dss.
>  - Added Mathieu's ack.
> ---
>  drivers/coresight/of_coresight.c  | 13 ++---
>  drivers/gpu/drm/imx/imx-drm-core.c| 13 ++---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 ---

For rcar-du,

Acked-by: Laurent Pinchart 

>  drivers/media/platform/soc_camera/soc_camera.c|  3 ++-
>  drivers/of/base.c |  9 +
>  drivers/video/fbdev/omap2/dss/omapdss-boot-init.c |  7 +--
>  6 files changed, 12 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/coresight/of_coresight.c
> b/drivers/coresight/of_coresight.c index 5030c07..349c88b 100644
> --- a/drivers/coresight/of_coresight.c
> +++ b/drivers/coresight/of_coresight.c
> @@ -52,15 +52,6 @@ of_coresight_get_endpoint_device(struct device_node
> *endpoint) endpoint, of_dev_node_match);
>  }
> 
> -static struct device_node *of_get_coresight_endpoint(
> - const struct device_node *parent, struct device_node *prev)
> -{
> - struct device_node *node = of_graph_get_next_endpoint(parent, prev);
> -
> - of_node_put(prev);
> - return node;
> -}
> -
>  static void of_coresight_get_ports(struct device_node *node,
>  int *nr_inport, int *nr_outport)
>  {
> @@ -68,7 +59,7 @@ static void of_coresight_get_ports(struct device_node
> *node, int in = 0, out = 0;
> 
>   do {
> - ep = of_get_coresight_endpoint(node, ep);
> + ep = of_graph_get_next_endpoint(node, ep);
>   if (!ep)
>   break;
> 
> @@ -140,7 +131,7 @@ struct coresight_platform_data
> *of_get_coresight_platform_data( /* Iterate through each port to discover
> topology */
>   do {
>   /* Get a handle on a port */
> - ep = of_get_coresight_endpoint(node, ep);
> + ep = of_graph_get_next_endpoint(node, ep);
>   if (!ep)
>   break;
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> b/drivers/gpu/drm/imx/imx-drm-core.c index b250130..fed627d 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -436,15 +436,6 @@ static uint32_t imx_drm_find_crtc_mask(struct
> imx_drm_device *imxdrm, return 0;
>  }
> 
> -static struct device_node *imx_drm_of_get_next_endpoint(
> - const struct device_node *parent, struct device_node *prev)
> -{
> - struct device_node *node = of_graph_get_next_endpoint(parent, prev);
> -
> - of_node_put(prev);
> - return node;
> -}
> -
>  int imx_drm_encoder_parse_of(struct drm_device *drm,
>   struct drm_encoder *encoder, struct device_node *np)
>  {
> @@ -456,7 +447,7 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
>   for (i = 0; ; i++) {
>   u32 mask;
> 
> - ep = imx_drm_of_get_next_endpoint(np, ep);
> + ep = of_graph_get_next_endpoint(np, ep);
>   if (!ep)
>   break;
> 
> @@ -504,7 +495,7 @@ int imx_drm_encoder_get_mux_id(struct device_node *node,
> return -EINVAL;
> 
>   do {
> - ep = imx_drm_of_get_next_endpoint(node, ep);
> + ep = of_graph_get_next_endpoint(node, ep);
>   if (!ep)
>   break;
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 0c5ee61..480c4d9 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -206,7 +206,7 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu, enum rcar_du_encoder_type enc_type =
> RCAR_DU_ENCODER_NONE;
>   struct device_node *connector = NULL;
>   struct device_node *encoder = NULL;
> - struct device_node *prev = NULL;
> + struct device_node *ep_node = NULL;
>   struct device_node *entity_ep_node;
>   struct device_node *entity;
>   int ret;
> @@ -225,11 +225,7 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu, entity_ep_node = of_parse_phandle(ep->local_node,
> "remote-endpoint", 0);
> 
>   while (1) {
> - struct device_node *ep_node;
> -
> - ep_node = of_graph_get_next_endpoint(entity, prev);
> - of_node_put(prev);
> - prev = ep_node;
> + ep_node = of_graph_get_next_endpoint(entit

Re: [PATCH 4/4] ARM: at91/dt: sama5: move NAND nodes into board dts/dtsi

[Josh Wu]

Hi, Boris

On 12/5/2014 6:30 AM, Boris Brezillon wrote:

sama5d3 and sama5d4 SoCs provides several CS to interface with external
memories, and in particular NAND chips.
The NAND flash controller embedded in the these SoCs can connect to any of
the available CS (each CS is assigned a memory range, hence the nand@xxx
you're seeing in the DT), thus the NAND chip definition should be part of
the board description because we cannot guess at the SoC level which CS
will be chosen by the board designer.

Signed-off-by: Boris Brezillon 
---
  arch/arm/boot/dts/at91-sama5d3_xplained.dts | 18 +-
  arch/arm/boot/dts/at91-sama5d4ek.dts| 16 +++-
  arch/arm/boot/dts/sama5d3.dtsi  | 21 -
  arch/arm/boot/dts/sama5d3xcm.dtsi   | 18 +-
  arch/arm/boot/dts/sama5d4.dtsi  | 19 ---
  5 files changed, 49 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts 
b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index fec1fca..860258b 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -213,13 +213,29 @@
};
  
  		nand0: nand@6000 {

+   compatible = "atmel,at91rm9200-nand";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;

it would be better to leave this part to the sama5d3.dtsi.


+   reg = <  0x6000 0x0100   /* EBI CS3 */
+   0xc070 0x0490   /* SMC PMECC regs */
+   0xc500 0x0100   /* SMC PMECC Error 
Location regs */
+   0x0011 0x00018000   /* ROM code */
+   >;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH 6>;

ditto.

+   atmel,nand-addr-offset = <21>;
+   atmel,nand-cmd-offset = <22>;
+   atmel,nand-has-dma;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nand0_ale_cle>;
+   atmel,pmecc-lookup-table-offset = <0x0 0x8000>;

ditto.


+   atmel,nfc = <&nfc>;
nand-bus-width = <8>;
nand-ecc-mode = "hw";
atmel,has-pmecc;
atmel,pmecc-cap = <4>;
atmel,pmecc-sector-size = <512>;
nand-on-flash-bbt;
-   status = "okay";
  
  			at91bootstrap@0 {

label = "at91bootstrap";
diff --git a/arch/arm/boot/dts/at91-sama5d4ek.dts 
b/arch/arm/boot/dts/at91-sama5d4ek.dts
index b5b8400..5de0d2d 100644
--- a/arch/arm/boot/dts/at91-sama5d4ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d4ek.dts
@@ -204,11 +204,25 @@
};
  
  		nand0: nand@8000 {

+   compatible = "atmel,at91rm9200-nand";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;

it would be better to leave this part to the sama5d4.dtsi.


+   reg = <  0x8000 0x0800   /* EBI CS3 */
+   0xfc05c070 0x0490   /* SMC PMECC regs */
+   0xfc05c500 0x0100   /* SMC PMECC Error 
Location regs */
+   >;
+   interrupts = <22 IRQ_TYPE_LEVEL_HIGH 6>;

ditto.


+   atmel,nand-addr-offset = <21>;
+   atmel,nand-cmd-offset = <22>;
+   atmel,nand-has-dma;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nand>;
+   atmel,nfc = <&nfc>;
nand-bus-width = <8>;
nand-ecc-mode = "hw";
nand-on-flash-bbt;
atmel,has-pmecc;
-   status = "okay";
  
  			at91bootstrap@0 {

label = "at91bootstrap";
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 1749853..0a944e0 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1397,27 +1397,6 @@
status = "disabled";
};
  
-		nand0: nand@6000 {

-   compatible = "atmel,at91rm9200-nand";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-   reg = <  0x6000 0x0100   /* EBI CS3 */
-   0xc070 0x0490   /* SMC PMECC regs */
-   0xc500 0x0100   /* SMC PMECC Error 
Location regs */
-   0x0011 0x00018000   /* ROM code */
-

Re: [PATCH net-next 1/2] socket: Allow external sockets to use socket syscalls

[Jason Wang]

On 12/26/2014 02:50 PM, Alex Gartrell wrote:
> Currently the "is-socket" test for a file compares the ops table pointer,
> which is static and local to the socket.c.  Instead, this adds a flag for
> private_data_is_socket.  This is an exceptionally long commit message for a
> two-line patch.
>
> Signed-off-by: Alex Gartrell 
> ---
>  include/linux/fs.h | 2 +-
>  net/socket.c   | 3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index bb29b02..d162476 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -809,7 +809,7 @@ struct file {
>  #endif
>   /* needed for tty driver, and maybe others */
>   void*private_data;
> -
> + boolprivate_data_is_socket : 1;
>  #ifdef CONFIG_EPOLL
>   /* Used by fs/eventpoll.c to link all the hooks to this file */
>   struct list_headf_ep_links;
> diff --git a/net/socket.c b/net/socket.c
> index 8809afc..cd853be 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -388,6 +388,7 @@ struct file *sock_alloc_file(struct socket *sock, int 
> flags, const char *dname)
>   sock->file = file;
>   file->f_flags = O_RDWR | (flags & O_NONBLOCK);
>   file->private_data = sock;
> + file->private_data_is_socket = true;

This is only safe if all user of sock_alloc_file() have full support for
each method in proto_ops.
>   return file;
>  }
>  EXPORT_SYMBOL(sock_alloc_file);
> @@ -411,7 +412,7 @@ static int sock_map_fd(struct socket *sock, int flags)
>  
>  struct socket *sock_from_file(struct file *file, int *err)
>  {
> - if (file->f_op == &socket_file_ops)
> + if (file->private_data_is_socket)
>   return file->private_data;  /* set in sock_map_fd */
>  
>   *err = -ENOTSOCK;

Not sure it's the best method, how about a dedicated f_op to do this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] ARM: mediatek: Add MT8135 and MT8127 UART support

[Eddie Huang]

3.19-rc1 contains Joe's MT8135 & MT8127 basic support and sysirq driver patch.
But still can not boot to shell due to lack UART device node in device tree.
This patch enables MTK UART driver in multi_v7_defconfig and UART device node.

This patch base on 3.19-rc1, and Joe's sysirq dts patch [1]

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305812.html

Eddie Huang (2):
  ARM: mediatek: add UART dts for mt8127 and mt8135
  ARM: Add mediatek SoC UART support in defconfig

 arch/arm/boot/dts/mt8127.dtsi   | 34 ++
 arch/arm/boot/dts/mt8135.dtsi   | 34 ++
 arch/arm/configs/multi_v7_defconfig |  1 +
 3 files changed, 69 insertions(+)

--
1.8.1.1.dirty

* Email Confidentiality Notice 
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] ARM: Add mediatek SoC UART support in defconfig

[Eddie Huang]

Add mediatek SoC UART support in multi_v7_defconfig

Signed-off-by: Eddie Huang 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 2328fe7..fd0ff95 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -195,6 +195,7 @@ CONFIG_SERIO_AMBAKMI=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_DW=y
+CONFIG_SERIAL_8250_MT6577=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
 CONFIG_SERIAL_MESON=y
-- 
1.8.1.1

* Email Confidentiality Notice 
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] ARM: mediatek: add UART dts for mt8127 and mt8135

[Eddie Huang]

This add dts support for mt8127 and mt8135 SoC UART

Signed-off-by: Eddie Huang 
---
 arch/arm/boot/dts/mt8127.dtsi | 34 ++
 arch/arm/boot/dts/mt8135.dtsi | 34 ++
 2 files changed, 68 insertions(+)

diff --git a/arch/arm/boot/dts/mt8127.dtsi b/arch/arm/boot/dts/mt8127.dtsi
index 93bca88..69b1c39 100644
--- a/arch/arm/boot/dts/mt8127.dtsi
+++ b/arch/arm/boot/dts/mt8127.dtsi
@@ -64,6 +64,12 @@
clock-frequency = <32000>;
#clock-cells = <0>;
};
+
+   uart_clk: dummy26m {
+   compatible = "fixed-clock";
+   clock-frequency = <2600>;
+   #clock-cells = <0>;
+   };
};
 
soc {
@@ -99,5 +105,33 @@
  <0 0x10214000 0 0x2000>,
  <0 0x10216000 0 0x2000>;
};
+
+   uart0: serial@11002000 {
+   compatible = 
"mediatek,mt8127-uart","mediatek,mt6577-uart";
+   reg = <0 0x11002000 0 0x400>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   };
+
+   uart1: serial@11003000 {
+   compatible = 
"mediatek,mt8127-uart","mediatek,mt6577-uart";
+   reg = <0 0x11003000 0 0x400>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   };
+
+   uart2: serial@11004000 {
+   compatible = 
"mediatek,mt8127-uart","mediatek,mt6577-uart";
+   reg = <0 0x11004000 0 0x400>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   };
+
+   uart3: serial@11005000 {
+   compatible = 
"mediatek,mt8127-uart","mediatek,mt6577-uart";
+   reg = <0 0x11005000 0 0x400>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   };
};
 };
diff --git a/arch/arm/boot/dts/mt8135.dtsi b/arch/arm/boot/dts/mt8135.dtsi
index c5e04ef..ec83e69 100644
--- a/arch/arm/boot/dts/mt8135.dtsi
+++ b/arch/arm/boot/dts/mt8135.dtsi
@@ -86,6 +86,12 @@
clock-frequency = <32000>;
#clock-cells = <0>;
};
+
+   uart_clk: dummy26m {
+   compatible = "fixed-clock";
+   clock-frequency = <2600>;
+   #clock-cells = <0>;
+   };
};
 
soc {
@@ -121,5 +127,33 @@
  <0 0x10214000 0 0x2000>,
  <0 0x10216000 0 0x2000>;
};
+
+   uart0: serial@11006000 {
+   compatible = 
"mediatek,mt8135-uart","mediatek,mt6577-uart";
+   reg = <0 0x11006000 0 0x400>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   };
+
+   uart1: serial@11007000 {
+   compatible = 
"mediatek,mt8135-uart","mediatek,mt6577-uart";
+   reg = <0 0x11007000 0 0x400>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   };
+
+   uart2: serial@11008000 {
+   compatible = 
"mediatek,mt8135-uart","mediatek,mt6577-uart";
+   reg = <0 0x11008000 0 0x400>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   };
+
+   uart3: serial@11009000 {
+   compatible = 
"mediatek,mt8135-uart","mediatek,mt6577-uart";
+   reg = <0 0x11009000 0 0x400>;
+   interrupts = ;
+   clocks = <&uart_clk>;
+   };
};
 };
-- 
1.8.1.1

* Email Confidentiality Notice 
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kerne

Re: [PATCH 00/10] iio: KMX61 fixes

[Jonathan Cameron]

On 23/12/14 13:22, Daniel Baluta wrote:
> This is a series of cleanups after Hartmut's review:
> 
>   * http://marc.info/?l=linux-iio&m=141859700810393&w=2
>   * http://marc.info/?l=linux-iio&m=141859774010580&w=2
>   * http://marc.info/?l=linux-iio&m=141859828910703&w=2
>   * http://marc.info/?l=linux-kernel&m=141868557909385&w=2
> 
> Daniel Baluta (10):
>   iio: imu: kmx61: Save odr_bits for later use
>   iio: imu: kmx61: Don't ignore kmx61_set_power_state errors
>   iio: imu: kmx61: Enhance error handling
>   iio: imu: kmx61: Fixup parameters alignment
>   iio: imu: kmx61: Drop unused device parameter
>   iio: imu: kmx61: Use false instead of 0 for ev_enable_state
>   iio: imu: kmx61: Fix device initialization when setting trigger state
>   iio: imu: kmx61: Remove unnecessary REG_INS1 read
>   iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table
>   iio: imu: kmx61: Use correct base when reading data
> 
>  drivers/iio/imu/kmx61.c | 216 
> ++--
>  1 file changed, 101 insertions(+), 115 deletions(-)
> 
Ouch - I need to concentrate more when reviewing!
Anyhow, these all look fine to me, but I'd like to leave them for a few days
for Hartmut to take a look.

Jonathan

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

Re: [PATCH] staging/iio/accel: checkpatch: fixed long lines by moving comments

[Jonathan Cameron]

On 22/12/14 13:48, Sudip Mukherjee wrote:
> On Mon, Dec 22, 2014 at 02:23:42AM +0100, Helene Gsaenger wrote:
>> Signed-off-by: Helene Gsaenger 
>> Signed-off-by: Simone Weiss 
>> ---
>>  drivers/staging/iio/accel/adis16203.h | 41 
>> ++-
>>  1 file changed, 31 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/staging/iio/accel/adis16203.h 
>> b/drivers/staging/iio/accel/adis16203.h
>> index acc688d..fefe2f9 100644
>> --- a/drivers/staging/iio/accel/adis16203.h
>> +++ b/drivers/staging/iio/accel/adis16203.h
>> @@ -16,26 +16,47 @@
>>  #define ADIS16203_ALM_SMPL2  0x26 /* Alarm 2, sample period */
>>  #define ADIS16203_ALM_CTRL   0x28 /* Alarm control */
>>  #define ADIS16203_AUX_DAC0x30 /* Auxiliary DAC data */
>> -#define ADIS16203_GPIO_CTRL  0x32 /* General-purpose digital 
>> input/output control */
>> +#define ADIS16203_GPIO_CTRL  0x32 /* General-purpose digital 
>> input/output
>> +   * control */
>>  #define ADIS16203_MSC_CTRL   0x34 /* Miscellaneous control */
>> -#define ADIS16203_SMPL_PRD   0x36 /* Internal sample period (rate) 
>> control */
>> +#define ADIS16203_SMPL_PRD   0x36 /* Internal sample period (rate)
>> +   * control */
> 
> this is not the style for multiline comments. Check in CodingStyle.
> and besides, I think it will be better if you can put the comments in a line 
> of its own.
+ remember checkpatch is only for guidance.  Some rules such as the 80 
character limit
are often ignored if clarity would be gained by doing so, or if as here a large 
patch
would be needed (move all comments to separate lines) in order to meet the 80 
character
line limit for a couple of cases.
> 
> thanks
> sudip
>>  #define ADIS16203_AVG_CNT0x38 /* Operation, filter configuration */
>>  #define ADIS16203_SLP_CNT0x3A /* Operation, sleep mode control */
>>  #define ADIS16203_DIAG_STAT  0x3C /* Diagnostics, system status 
>> register */
>>  #define ADIS16203_GLOB_CMD   0x3E /* Operation, system command register 
>> */
>>  
>>  /* MSC_CTRL */
>> -#define ADIS16203_MSC_CTRL_PWRUP_SELF_TEST  (1 << 10) /* Self-test at 
>> power-on: 1 = disabled, 0 = enabled */
>> -#define ADIS16203_MSC_CTRL_REVERSE_ROT_EN   (1 << 9)  /* Reverses rotation 
>> of both inclination outputs */
>> +#define ADIS16203_MSC_CTRL_PWRUP_SELF_TEST  (1 << 10) /* Self-test at
>> +   * power-on:
>> +   * 1 = disabled,
>> +   * 0 = enabled */
>> +#define ADIS16203_MSC_CTRL_REVERSE_ROT_EN   (1 << 9)  /* Reverses rotation
>> +   * of both
>> +   * inclination
>> +   * outputs */
>>  #define ADIS16203_MSC_CTRL_SELF_TEST_EN (1 << 8)  /* Self-test 
>> enable */
>> -#define ADIS16203_MSC_CTRL_DATA_RDY_EN  (1 << 2)  /* Data-ready 
>> enable: 1 = enabled, 0 = disabled */
>> -#define ADIS16203_MSC_CTRL_ACTIVE_HIGH  (1 << 1)  /* Data-ready 
>> polarity: 1 = active high, 0 = active low */
>> -#define ADIS16203_MSC_CTRL_DATA_RDY_DIO1(1 << 0)  /* Data-ready line 
>> selection: 1 = DIO1, 0 = DIO0 */
>> +#define ADIS16203_MSC_CTRL_DATA_RDY_EN  (1 << 2)  /* Data-ready 
>> enable:
>> +   * 1 = enabled,
>> +   * 0 = disabled */
>> +#define ADIS16203_MSC_CTRL_ACTIVE_HIGH  (1 << 1)  /* Data-ready
>> +   * polarity:
>> +   * 1 = active high,
>> +   * 0 = active low */
>> +#define ADIS16203_MSC_CTRL_DATA_RDY_DIO1(1 << 0)  /* Data-ready line
>> +   * selection:
>> +   * 1 = DIO1,
>> +   * 0 = DIO0 */
>>  
>>  /* DIAG_STAT */
>> -#define ADIS16203_DIAG_STAT_ALARM2(1<<9) /* Alarm 2 status: 1 = 
>> alarm active, 0 = alarm inactive */
>> -#define ADIS16203_DIAG_STAT_ALARM1(1<<8) /* Alarm 1 status: 1 = 
>> alarm active, 0 = alarm inactive */
>> -#define ADIS16203_DIAG_STAT_SELFTEST_FAIL_BIT 5 /* Self-test diagnostic 
>> error flag */
>> +#define ADIS16203_DIAG_STAT_ALARM2(1<<9) /* Alarm 2 status:
>> +  * 1 = alarm active,
>> +  * 0 = alarm inactive */
>> +#define ADIS16203_DIAG_STAT_ALARM1(1<<8) /* Alarm 1 status:
>> +  * 1 = alarm active,
>> +  

Re: [RFC PATCH 3/3] virtio-net: using single MSIX irq for each TX/RX queue pair

[Jason Wang]

On 12/26/2014 10:53 AM, Jason Wang wrote:
> This patch try to reduce the number of MSIX irqs required for
> virtio-net by sharing a MSIX irq for each TX/RX queue pair through
> channels. If transport support channel, about half of the MSIX irqs
> were reduced.
>
> Cc: Rusty Russell 
> Cc: Michael S. Tsirkin 
> Signed-off-by: Jason Wang 
> ---
>  drivers/net/virtio_net.c | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
>

Note: an issue with this patch is it may trigger tx irq handler if at
least one more used. We could solve this by checking the used idx and
bypass the tx irq if host does not signal us. (Or just does the old tx
skbs reclaiming before the checking.)

--
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] add omap34xx temperature monitoring support

[Pavel Machek]

Signed-off-by: Pavel Machek 

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09..9007ca9 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -28,6 +28,10 @@ config HWMON_VID
tristate
default n
 
+config SENSORS_OMAP34XX
+   bool "TI OMAP34xx internal temperature sensor"
+   depends on ARCH_OMAP3 && HIGH_RES_TIMERS
+
 config HWMON_DEBUG_CHIP
bool "Hardware Monitoring Chip debugging messages"
default n
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5c3b5d1 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_NCT6683)   += nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)  += nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)  += nct7802.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)   += ntc_thermistor.o
+obj-$(CONFIG_SENSORS_OMAP34XX)  += omap34xx_temp.o
 obj-$(CONFIG_SENSORS_PC87360)  += pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)  += pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
diff --git a/drivers/hwmon/omap34xx_temp.c b/drivers/hwmon/omap34xx_temp.c
new file mode 100644
index 000..bc7a72f
--- /dev/null
+++ b/drivers/hwmon/omap34xx_temp.c
@@ -0,0 +1,263 @@
+/*
+ * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Written by Peter De Schrijver 
+ *
+ * Inspired by k8temp.c
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../../arch/arm/mach-omap2/control.h"
+
+#define TEMP_SENSOR_SOC BIT(8)
+#define TEMP_SENSOR_EOCZ BIT(7)
+
+/* minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_RISING_DELAY (11 * 30518)
+
+/* maximum delay for EOCZ rise after SOC rise is
+ * 14 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_RISING_DELAY (14 * 30518)
+
+/* minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_FALLING_DELAY (36 * 30518)
+
+/* maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_FALLING_DELAY (40 * 30518)
+
+struct omap34xx_data {
+   struct device *hwmon_dev;
+   struct clk *clk_32k;
+   struct mutex update_lock;
+   const char *name;
+   char valid;
+   unsigned long last_updated;
+   u32 temp;
+};
+
+static struct platform_device omap34xx_temp_device = {
+   .name   = "omap34xx_temp",
+   .id = -1,
+};
+
+static int adc_to_temp[] = {
+   -40, -40, -40, -40, -40, -39, -38, -36, -34, -32, -31, -29, -28, -26,
+   -25, -24, -22, -21, -19, -18, -17, -15, -14, -12, -11, -9, -8, -7, -5,
+   -4, -2, -1, 0, 1, 3, 4, 5, 7, 8, 10, 11, 13, 14, 15, 17, 18, 20, 21,
+   22, 24, 25, 27, 28, 30, 31, 32, 34, 35, 37, 38, 39, 41, 42, 44, 45,
+   47, 48, 49, 51, 52, 53, 55, 56, 58, 59, 60, 62, 63, 65, 66, 67, 69,
+   70, 72, 73, 74, 76, 77, 79, 80, 81, 83, 84, 85, 87, 88, 89, 91, 92,
+   94, 95, 96, 98, 99, 100, 102, 103, 105, 106, 107, 109, 110, 111, 113,
+   114, 116, 117, 118, 120, 121, 122, 124, 124, 125, 125, 125, 125, 125};
+
+static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level)
+{
+   struct timespec timeout;
+   ktime_t expire;
+   u32 temp_sensor_reg;
+
+   level &= 1;
+   level *= TEMP_SENSOR_EOCZ;
+
+   expire = ktime_add_ns(ktime_get(), max_delay);
+   timeout = ns_to_timespec(min_delay);
+   hrtimer_nanosleep(&timeout, NULL, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
+   do {
+   temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+   if ((temp_sensor_reg & TEMP_SENSOR_EOCZ) == level)
+   break;
+   } while (ktime_us_delta(expire, ktime_get()) > 0);
+
+   return (temp_sensor_reg & TEMP_SENSOR_EOCZ) == level;
+}
+
+static void omap34xx_update(struct omap34xx_data *data)
+{
+   u32 temp_sensor_reg;
+
+   mutex_lock(&data->update_lock);
+
+   if (!data->valid
+   || time_after(jiffies, data->last_updated + HZ)) {
+   clk_prepare_enable(data->clk_32k);
+
+   temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+   temp_sensor_reg |= TEMP_SENSOR_SOC;
+   omap_ctrl_writel(temp_sensor_reg, OMAP343X_CONTROL_TEMP_SENSOR);
+
+   if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
+   EOCZ_MAX_RISING_DELAY, 1))
+   goto err;
+
+   temp_sensor_reg = o

Re: [PATCH] staging : iio: meter: ade7759: fix space before , coding style issue

[Jonathan Cameron]

On 21/12/14 12:42, Mohammad Jamal wrote:
> This patch solves the space before , coding style issue found by
> checkpatch in ade7759.c
> 
> Signed-off-by: Mohammad Jamal 
Fixed by Zachery Warren back in November.  I'm a bit behind with
sending stuff upstream so won't have hit anything other than the
togreg branch of iio.git just yet.

Patch was:

[PATCH] drivers:staging:iio: fix checkpatch complaint about space before comma
Thanks,

Jonathan
> ---
>  drivers/staging/iio/meter/ade7759.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/iio/meter/ade7759.c 
> b/drivers/staging/iio/meter/ade7759.c
> index 7d21743..b0c7dbc 100644
> --- a/drivers/staging/iio/meter/ade7759.c
> +++ b/drivers/staging/iio/meter/ade7759.c
> @@ -116,7 +116,7 @@ static int ade7759_spi_read_reg_40(struct device *dev,
>  
>   mutex_lock(&st->buf_lock);
>   st->tx[0] = ADE7759_READ_REG(reg_address);
> - memset(&st->tx[1], 0 , 5);
> + memset(&st->tx[1], 0, 5);
>  
>   ret = spi_sync_transfer(st->us, xfers, ARRAY_SIZE(xfers));
>   if (ret) {
> 

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

Re: [PATCH] staging: iio: adc: ad7192: fix space before , coding style issue

[Jonathan Cameron]

On 21/12/14 12:35, Mohammad Jamal wrote:
> This patch solves the space before , error of the checkpatch.pl
> 
> Signed-off-by: Mohammad Jamal 
Also fixed in that earlier patch from Zachery.
> ---
>  drivers/staging/iio/adc/ad7192.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/iio/adc/ad7192.c 
> b/drivers/staging/iio/adc/ad7192.c
> index f6526aa..6f8ce6c 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -612,7 +612,7 @@ static int ad7192_probe(struct spi_device *spi)
>   const struct ad7192_platform_data *pdata = spi->dev.platform_data;
>   struct ad7192_state *st;
>   struct iio_dev *indio_dev;
> - int ret , voltage_uv = 0;
> + int ret, voltage_uv = 0;
>  
>   if (!pdata) {
>   dev_err(&spi->dev, "no platform data?\n");
> 

--
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 1/1] add support for Seagate BlackArmor NAS220

[Evgeni Dobrev]

Hello Sebastian,

On Thu, Dec 25, 2014 at 02:08:12PM +0100, Sebastian Hesselbarth wrote:
> On 22.12.2014 13:57, Evgeni Dobrev wrote:
> >This patch adds support for Seagate BlackArmor NAS220.
> >
> >The Seagate BlackArmor NAS 220 is a NAS system based on Marvell 88f6192. It 
> >has
> >32MB NAND and 128MB DRAM. It has two SATA slots, one Gigabit Ethernet port, 
> >two
> >USB 2.0 ports, two buttons and three LEDs. There is a serial port available 
> >on
> >the CN5 connector on the board (1 - TX, 4 - RX, 6 - GND).
> >
> >The only functionality still not implemented is the bi-color led on the front
> >panel (status). Pins mpp22 and mpp23 control this led. Setting mpp22 to high 
> >and
> >mpp23 to low results in orange color. Setting mpp22 to low and mpp23 to high
> >results in blue color.
> >
> >The third led is wired to show the SATA activity on the two drives.
> >
> >Signed-off-by: Evgeni Dobrev 
> 
> Evgeni,
> 
> sorry for the late review, but I do have some nits that should
> remove some inconsistencies. If we don't do it now, we'd never
> change that later.
> 

thank you for your review. I will make the changes you suggest and resubmit.

> >---
> >  arch/arm/boot/dts/Makefile|1 +
> >  arch/arm/boot/dts/kirkwood-nas220.dts |  166 
> > +
> >  2 files changed, 167 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/kirkwood-nas220.dts
> >
> >diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >index 38c89ca..8b9ad1d 100644
> >--- a/arch/arm/boot/dts/Makefile
> >+++ b/arch/arm/boot/dts/Makefile
> >@@ -132,6 +132,7 @@ dtb-$(CONFIG_MACH_KIRKWOOD) += kirkwood-b3.dtb \
> > kirkwood-lsxhl.dtb \
> > kirkwood-mplcec4.dtb \
> > kirkwood-mv88f6281gtw-ge.dtb \
> >+kirkwood-nas220.dtb \
> 
> I am not too happy with choosing "nas220" as the base name for the
> board. Can we make it a little bit more specific like
> "seagate-nas220" or "blackarmor-nas220" ?
> 
> > kirkwood-net2big.dtb \
> > kirkwood-net5big.dtb \
> > kirkwood-netgear_readynas_duo_v2.dtb \
> >diff --git a/arch/arm/boot/dts/kirkwood-nas220.dts 
> >b/arch/arm/boot/dts/kirkwood-nas220.dts
> >new file mode 100644
> >index 000..8175f3d
> >--- /dev/null
> >+++ b/arch/arm/boot/dts/kirkwood-nas220.dts
> >@@ -0,0 +1,166 @@
> >+/*
> >+ * Device Tree file for Seagate BlackArmor NAS220
> >+ *
> >+ * Copyright (C) 2014 Evgeni Dobrev 
> >+ *
> >+ * Licensed under GPLv2 or later.
> >+ */
> >+
> >+/dts-v1/;
> >+
> >+#include 
> >+#include 
> >+#include "kirkwood.dtsi"
> >+#include "kirkwood-6192.dtsi"
> >+
> >+/ {
> >+model = "Seagate NAS 220";
> 
> model = "Seagate BlackArmor NAS220";
> 
> i.e. choose the same spelling in comment above and model name here.
> 
> >+compatible = 
> >"seagate,nas220","marvell,kirkwood-88f6192","marvell,kirkwood";
> 
> compatible should reflect the chosen base name above.
> 
> >+
> >+memory { /* 128 MB */
> >+device_type = "memory";
> >+reg = <0x 0x800>;
> >+};
> >+
> >+chosen {
> >+bootargs = "console=ttyS0,115200n8";
> >+stdout-path = &uart0;
> >+};
> >+
> >+ocp@f100 {
> >+pinctrl: pin-controller@1 {
> 
> v3.19 should already have a label for the common pinctrl node.
> Please do not replay the bus structure but use a node reference
> like &nand and friends below.
> 
> >+pinctrl-0 = <&pmx_uart0
> >+ &pmx_button_reset
> >+ &pmx_button_power>;
> >+pinctrl-names = "default";
> >+
> >+pmx_act_sata0: pmx-act-sata0 {
> >+marvell,pins = "mpp15";
> >+marvell,function = "sata0";
> >+};
> 
> Insert a blank line between each of the pmx_foo nodes?
> 
> >+pmx_act_sata1: pmx-act-sata1 {
> >+marvell,pins = "mpp16";
> >+marvell,function = "sata1";
> >+};
> >+pmx_power_sata0: pmx-power-sata0 {
> >+marvell,pins = "mpp24";
> >+marvell,function = "gpio";
> >+};
> >+pmx_power_sata1: pmx-power-sata1 {
> >+marvell,pins = "mpp28";
> >+marvell,function = "gpio";
> >+};
> >+pmx_button_reset: pmx-button-reset {
> >+marvell,pins = "mpp29";
> >+marvell,function = "gpio";
> >+};
> >+pmx_button_power: pmx-button-power {
> >+marvell,pins = "mpp26";
> >+marvell,function = "gpio";
> >+};
> >+};
> >+
> >+
> 
> Remove extra blank line.
> 
> >+/*
> >+ * Serial port rout

Re: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors

[Jonathan Cameron]

On 18/12/14 16:51, Lars-Peter Clausen wrote:
> Adding V4L folks to Cc for more input.
Thanks Lars - we definitely would need the v4l guys to agree to a driver like
this going in IIO. (not that I'm convinced it should!)
> 
> On 12/08/2014 03:10 PM, Baluta, Teodora wrote:
>> Hello,
>>
>> On Vi, 2014-12-05 at 02:15 +, Jonathan Cameron wrote:
>>> On 04/12/14 13:00, Teodora Baluta wrote:
 This patchset adds support for fingerprint sensors through the IIO 
 interface.
 This way userspace applications collect information in a uniform way. All
 processing would be done in the upper layers as suggested in [0].

 In order to test out this proposal, a minimal implementation for UPEK's
 TouchChip Fingerprint Sensor via USB is also available. Although there is 
 an
 existing implementation in userspace for USB fingerprint devices, 
 including this
 particular device, the driver represents a proof of concept of how 
 fingerprint
 sensors could be integrated in the IIO framework regardless of the used 
 bus. For
 lower power requirements, the SPI bus is preferred and a kernel driver
 implementation makes more sense.
>>>
>>> So why not v4l?  These are effectively image sensors..
>>
>> Well, here's why I don't think v4l would be the best option:
>>
>> - an image scanner could be implemented in the v4l subsystem, but it
>> seems far more complicated for a simple fingerprint scanner - it usually
>> has drivers for webcams, TVs or video streaming devices. The v4l
>> subsystem (with all its support for colorspace, decoders, image
>> compression, frame control) seems a bit of an overkill for a very
>> straightforward fingerprint imaging sensor.
Whilst those are there, I would doubt the irrelevant bits would put much
burden on a fingerprint scanning driver.  Been a while since I did
anything in that area though so I could be wrong!
>>
>> - a fingerprint device could also send out a processed information, not
>> just the image of a fingerprint. This means that the processing is done
>> in hardware - the UPEK TouchStrip chipset in libfprint has this behavior
>> (see [0]). So, the IIO framework would support a uniform way of handling
>> fingerprint devices that either do processing in software or in
>> hardware.
This is more interesting, but does that map well to IIO style
channels anyway?  If not we are going to end up with a whole new
interface which ever subsystem is used for the image side of things.
>>
>> The way I see it now, for processed fingerprint information, an IIO
>> device could have an IIO_FINGERPRINT channel with a modifier and only
>> the sensitivity threshold attribute set. We would also need two
>> triggers: one for enrollment and one for the verification mode to
>> control the device from a userspace application.
Sure - what you proposed would work.  The question is whether it is
the best way to do it.


>>
>> Thanks,
>> Teodora
>>
>> [0] http://www.freedesktop.org/wiki/Software/fprint/libfprint/upekts/
>>
>>

 A sysfs trigger is enabled and the device starts scanning. As soon as an 
 image
 is available it is written in the character device /dev/iio:deviceX.

 Userspace applications will be able to calculate the expected image size 
 using
 the fingerprint attributes height, width and bit depth. Other attributes
 introduced for the fingerprint channel in IIO represent information that 
 aids in
 the fingerprint image processing. Besides these, the proposed interface 
 offers
 userspace a way to read a feedback after a scan (like the swipe was too 
 slow or
 too fast) through a modified fingerprint_status channel.

 [0] http://www.spinics.net/lists/linux-iio/msg11463.html

 Teodora Baluta (3):
iio: core: add support for fingerprint devices
iio: core: change channel's storagebits/realbits to u32
iio: fingerprint: add fingerprint sensor via USB

   Documentation/ABI/testing/sysfs-bus-iio |  51 +++
   drivers/iio/Kconfig |   1 +
   drivers/iio/Makefile|   1 +
   drivers/iio/fingerprint/Kconfig |  15 +
   drivers/iio/fingerprint/Makefile|   5 +
   drivers/iio/fingerprint/fp_tc.c | 162 +
   drivers/iio/fingerprint/fp_tc.h |  22 ++
   drivers/iio/fingerprint/fp_tc_usb.c | 618 
 
   drivers/iio/fingerprint/fp_tc_usb.h | 144 
   drivers/iio/industrialio-core.c |   9 +
   include/linux/iio/iio.h |  11 +-
   include/linux/iio/types.h   |  10 +
   12 files changed, 1047 insertions(+), 2 deletions(-)
   create mode 100644 drivers/iio/fingerprint/Kconfig
   create mode 100644 drivers/iio/fingerprint/Makefile
   create mode 100644 drivers/iio/fingerprint/fp_tc.c
   create mode 100644 drivers/iio/fingerprint/fp_tc.h
   cre

Re: [PATCH v2] ALSA: atmel: fix building the ac97 driver for at91-multiplatform

[Takashi Iwai]

At Thu, 25 Dec 2014 11:48:37 +0100,
Alexandre Belloni wrote:
> 
> Hi,
> 
> On 25/12/2014 at 11:19:04 +0100, Takashi Iwai wrote :
> > At Sun, 21 Dec 2014 12:18:09 +0100,
> > Alexandre Belloni wrote:
> > > 
> > > From: Arnd Bergmann 
> > > 
> > > at91 will no longer export the mach/cpu.h and mach/hardware.h header files
> > > in the future, which would break building the atmel ac97c driver.
> > > 
> > > Since the cpu_is_* check is only used to find out whether we are running
> > > on avr32 or arm/at91, we can hardcode that check in the ARM case.
> > > 
> > > Signed-off-by: Arnd Bergmann 
> > > Link: http://www.spinics.net/lists/arm-kernel/msg382068.html
> > 
> > Is this targeted for 3.19 or 3.20?
> > 
> 
> It is not urgent, that is definitely for 3.20.

OK.  But I can't apply it now because your sign-off is missing.
If you submit a patch, you must give your own sign-off, too, even if
it's not written by you.


thanks,

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

[PATCH] Staging: line6: pcm: Corrected checkpatch notices in pcm.h

[Damon Swayn]

Fixed a coding style issue

Signed-off-by: Damon Swayn 
---
 drivers/staging/line6/pcm.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/line6/pcm.h b/drivers/staging/line6/pcm.h
index 6aa0d46..5d87934 100644
--- a/drivers/staging/line6/pcm.h
+++ b/drivers/staging/line6/pcm.h
@@ -145,21 +145,21 @@ enum {
LINE6_BIT_PCM_IMPULSE_PLAYBACK_BUFFER |
 #endif
LINE6_BIT_PCM_ALSA_PLAYBACK_BUFFER |
-   LINE6_BIT_PCM_MONITOR_PLAYBACK_BUFFER ,
+   LINE6_BIT_PCM_MONITOR_PLAYBACK_BUFFER,
 
LINE6_BITS_PLAYBACK_STREAM =
 #ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE
LINE6_BIT_PCM_IMPULSE_PLAYBACK_STREAM |
 #endif
LINE6_BIT_PCM_ALSA_PLAYBACK_STREAM |
-   LINE6_BIT_PCM_MONITOR_PLAYBACK_STREAM ,
+   LINE6_BIT_PCM_MONITOR_PLAYBACK_STREAM,
 
LINE6_BITS_CAPTURE_BUFFER =
 #ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE
LINE6_BIT_PCM_IMPULSE_CAPTURE_BUFFER |
 #endif
LINE6_BIT_PCM_ALSA_CAPTURE_BUFFER |
-   LINE6_BIT_PCM_MONITOR_CAPTURE_BUFFER ,
+   LINE6_BIT_PCM_MONITOR_CAPTURE_BUFFER,
 
LINE6_BITS_CAPTURE_STREAM =
 #ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE
-- 
2.1.0

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

Re: [PATCH v2 1/3] iio: kfifo: Remove unused argument in iio_kfifo_allocate

[Jonathan Cameron]

On 19/12/14 17:39, Karol Wrona wrote:
> indio_dev was unused in function body plus some small style fix - add new
> lines after "if(sth) return sth" and before the last return statement.
> 
> The argument was removed also in its client.
> 
> Signed-off-by: Karol Wrona 
Good cleanup - some fuzz applying and required a bit of hand editting
in kfifo_buf.c for reasons I couldn't immediately spot.  Please sanity
check I haven't messed anything up.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/ti_am335x_adc.c |2 +-
>  drivers/iio/industrialio-triggered-buffer.c |2 +-
>  drivers/iio/kfifo_buf.c |6 --
>  drivers/staging/iio/accel/lis3l02dq_ring.c  |2 +-
>  drivers/staging/iio/iio_simple_dummy_buffer.c   |2 +-
>  drivers/staging/iio/impedance-analyzer/ad5933.c |2 +-
>  drivers/staging/iio/meter/ade7758_ring.c|2 +-
>  include/linux/iio/kfifo_buf.h   |2 +-
>  8 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index b730864..bf87993 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -250,7 +250,7 @@ static int tiadc_iio_buffered_hardware_setup(struct 
> iio_dev *indio_dev,
>   struct iio_buffer *buffer;
>   int ret;
>  
> - buffer = iio_kfifo_allocate(indio_dev);
> + buffer = iio_kfifo_allocate();
>   if (!buffer)
>   return -ENOMEM;
>  
> diff --git a/drivers/iio/industrialio-triggered-buffer.c 
> b/drivers/iio/industrialio-triggered-buffer.c
> index d6f54930..6c6307a 100644
> --- a/drivers/iio/industrialio-triggered-buffer.c
> +++ b/drivers/iio/industrialio-triggered-buffer.c
> @@ -49,7 +49,7 @@ int iio_triggered_buffer_setup(struct iio_dev *indio_dev,
>   struct iio_buffer *buffer;
>   int ret;
>  
> - buffer = iio_kfifo_allocate(indio_dev);
> + buffer = iio_kfifo_allocate();
>   if (!buffer) {
>   ret = -ENOMEM;
>   goto error_ret;
> diff --git a/drivers/iio/kfifo_buf.c b/drivers/iio/kfifo_buf.c
> index 7134e8a..a383291 100644
> --- a/drivers/iio/kfifo_buf.c
> +++ b/drivers/iio/kfifo_buf.c
> @@ -166,19 +166,21 @@ static const struct iio_buffer_access_funcs 
> kfifo_access_funcs = {
>   .release = &iio_kfifo_buffer_release,
>  };
>  
> -struct iio_buffer *iio_kfifo_allocate(struct iio_dev *indio_dev)
> +struct iio_buffer *iio_kfifo_allocate(void)
>  {
>   struct iio_kfifo *kf;
>  
> - kf = kzalloc(sizeof *kf, GFP_KERNEL);
> + kf = kzalloc(sizeof(*kf), GFP_KERNEL);
>   if (!kf)
>   return NULL;
> +
>   kf->update_needed = true;
>   iio_buffer_init(&kf->buffer);
>   kf->buffer.attrs = &iio_kfifo_attribute_group;
>   kf->buffer.access = &kfifo_access_funcs;
>   kf->buffer.length = 2;
>   mutex_init(&kf->user_lock);
> +
>   return &kf->buffer;
>  }
>  EXPORT_SYMBOL(iio_kfifo_allocate);
> diff --git a/drivers/staging/iio/accel/lis3l02dq_ring.c 
> b/drivers/staging/iio/accel/lis3l02dq_ring.c
> index 9efc77b..1fd9009 100644
> --- a/drivers/staging/iio/accel/lis3l02dq_ring.c
> +++ b/drivers/staging/iio/accel/lis3l02dq_ring.c
> @@ -393,7 +393,7 @@ int lis3l02dq_configure_buffer(struct iio_dev *indio_dev)
>   int ret;
>   struct iio_buffer *buffer;
>  
> - buffer = iio_kfifo_allocate(indio_dev);
> + buffer = iio_kfifo_allocate();
>   if (!buffer)
>   return -ENOMEM;
>  
> diff --git a/drivers/staging/iio/iio_simple_dummy_buffer.c 
> b/drivers/staging/iio/iio_simple_dummy_buffer.c
> index fd74f91..df765c9 100644
> --- a/drivers/staging/iio/iio_simple_dummy_buffer.c
> +++ b/drivers/staging/iio/iio_simple_dummy_buffer.c
> @@ -122,7 +122,7 @@ int iio_simple_dummy_configure_buffer(struct iio_dev 
> *indio_dev,
>   struct iio_buffer *buffer;
>  
>   /* Allocate a buffer to use - here a kfifo */
> - buffer = iio_kfifo_allocate(indio_dev);
> + buffer = iio_kfifo_allocate();
>   if (buffer == NULL) {
>   ret = -ENOMEM;
>   goto error_ret;
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c 
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index b6bd609..ace9ef8 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -626,7 +626,7 @@ static int ad5933_register_ring_funcs_and_init(struct 
> iio_dev *indio_dev)
>  {
>   struct iio_buffer *buffer;
>  
> - buffer = iio_kfifo_allocate(indio_dev);
> + buffer = iio_kfifo_allocate();
>   if (!buffer)
>   return -ENOMEM;
>  
> diff --git a/drivers/staging/iio/meter/ade7758_ring.c 
> b/drivers/staging/iio/meter/ade7758_ring.c
> index 6e90064..31d2cf3 100644
> --- a/drivers/staging/iio/meter/ade7758_ring.c
> +++ b/drivers/staging/iio/meter/ade7758_ring.c
> @@ -118,7 +118,7 @@ int ade7758_configure_ring(struct iio_dev *indio_dev)
>   struct iio_bu

Re: [PATCH v2 2/3] iio: kfifo: Add resource management devm_iio_kfifo_allocate/free

[Jonathan Cameron]

On 19/12/14 17:39, Karol Wrona wrote:
> iio kfifo allocate/free gained their devm_ wrappers.
> 
> Signed-off-by: Karol Wrona 
> Suggested-by: Jonathan Cameron 
Applied to the togreg branch of iio.git.

One addition - added to the list of devm functions in
Documentation/device-model/devres.txt


> ---
>  drivers/iio/kfifo_buf.c   |   54 
> +
>  include/linux/iio/kfifo_buf.h |3 +++
>  2 files changed, 57 insertions(+)
> 
> diff --git a/drivers/iio/kfifo_buf.c b/drivers/iio/kfifo_buf.c
> index a383291..5d44099 100644
> --- a/drivers/iio/kfifo_buf.c
> +++ b/drivers/iio/kfifo_buf.c
> @@ -191,4 +191,58 @@ void iio_kfifo_free(struct iio_buffer *r)
>  }
>  EXPORT_SYMBOL(iio_kfifo_free);
>  
> +static void devm_iio_kfifo_release(struct device *dev, void *res)
> +{
> + iio_kfifo_free(*(struct iio_buffer **)res);
> +}
> +
> +static int devm_iio_kfifo_match(struct device *dev, void *res, void *data)
> +{
> + struct iio_buffer **r = res;
> +
> + if (WARN_ON(!r || !*r))
> + return 0;
> +
> + return *r == data;
> +}
> +
> +/**
> + * devm_iio_fifo_allocate - Resource-managed iio_kfifo_allocate()
> + * @dev: Device to allocate kfifo buffer for
> + *
> + * RETURNS:
> + * Pointer to allocated iio_buffer on success, NULL on failure.
> + */
> +struct iio_buffer *devm_iio_kfifo_allocate(struct device *dev)
> +{
> + struct iio_buffer **ptr, *r;
> +
> + ptr = devres_alloc(devm_iio_kfifo_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return NULL;
> +
> + r = iio_kfifo_allocate();
> + if (r) {
> + *ptr = r;
> + devres_add(dev, ptr);
> + } else {
> + devres_free(ptr);
> + }
> +
> + return r;
> +}
> +EXPORT_SYMBOL(devm_iio_kfifo_allocate);
> +
> +/**
> + * devm_iio_fifo_free - Resource-managed iio_kfifo_free()
> + * @dev: Device the buffer belongs to
> + * @r:   The buffer associated with the device
> + */
> +void devm_iio_kfifo_free(struct device *dev, struct iio_buffer *r)
> +{
> + WARN_ON(devres_release(dev, devm_iio_kfifo_release,
> +devm_iio_kfifo_match, r));
> +}
> +EXPORT_SYMBOL(devm_iio_kfifo_free);
> +
>  MODULE_LICENSE("GPL");
> diff --git a/include/linux/iio/kfifo_buf.h b/include/linux/iio/kfifo_buf.h
> index 1a8d57a..1683bc7 100644
> --- a/include/linux/iio/kfifo_buf.h
> +++ b/include/linux/iio/kfifo_buf.h
> @@ -8,4 +8,7 @@
>  struct iio_buffer *iio_kfifo_allocate(void);
>  void iio_kfifo_free(struct iio_buffer *r);
>  
> +struct iio_buffer *devm_iio_kfifo_allocate(struct device *dev);
> +void devm_iio_kfifo_free(struct device *dev, struct iio_buffer *r);
> +
>  #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/

Re: [PATCH v2 3/3] iio: core: Get rid of misleading comment

[Jonathan Cameron]

On 19/12/14 17:39, Karol Wrona wrote:
> This comment did not fit here.  It explains why devm_kmalloc
> uses dr_alloc.  Generally is not needed at all.
> 
A classic bit of cut and paste I guess. Anyhow, applied.

Jonathan
> Signed-off-by: Karol Wrona 
> ---
>  drivers/iio/industrialio-core.c |1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index af3e76d..1d030ae 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1035,7 +1035,6 @@ struct iio_dev *devm_iio_device_alloc(struct device 
> *dev, int sizeof_priv)
>   if (!ptr)
>   return NULL;
>  
> - /* use raw alloc_dr for kmalloc caller tracing */
>   iio_dev = iio_device_alloc(sizeof_priv);
>   if (iio_dev) {
>   *ptr = iio_dev;
> 

--
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 2/2] iio: add driver for the TI DAC8554

[Jonathan Cameron]

On 15/12/14 11:39, Nikolaus Schulz wrote:
> The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
> interface.
> 
> Changes in v3:
> * Small fixes in the documentation of struct dac8554_state
> * Replace some magic constants with macros
> * Replace memset on powerdown state arrays with explicit loop
> * If probing fails due to invalid DT data, return -EINVAL instead of
>   -ENODEV
> * Add driver dependency on regulator support
> * Move regulator_get_voltage call from probe time to dac8554_read_raw
> * Rename _(read|write)_raw argument "mask" to "info"
> * Make iio_chan_spec variable static
> * DT: add vendor prefix to device specific "address" property
> * Whitespace fixes
> 
> Changes in v2:
> * Use DMA-safe buffer for SPI transfer
> * Normalize powerdown_mode name "hi-z" to "three_state" as per
>   ABI/testing/sysfs-bus-iio
> * Register device late in probe function
> * Avoid powerdown broadcast update, which touches all DAC on the bus
> 
> Signed-off-by: Nikolaus Schulz 
A slightly inconsistency inline (you only allow for chip addresses up
to 2 rather than 3)

Otherwise, looks good - though we'll want Mark to say if he is fine with
the addressing bit of the device tree file and you to drop the line at
the top as asked for.

Thanks,

Jonathan
> ---
>  drivers/iio/dac/Kconfig  |  11 ++
>  drivers/iio/dac/Makefile |   1 +
>  drivers/iio/dac/ti-dac8554.c | 381 
> +++
>  3 files changed, 393 insertions(+)
>  create mode 100644 drivers/iio/dac/ti-dac8554.c
> 
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index 2236ea2..d3b21c853b5 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -181,4 +181,15 @@ config MCP4922
> To compile this driver as a module, choose M here: the module
> will be called mcp4922.
>  
> +config TI_DAC8554
> + tristate "TI DAC8554 driver"
> + depends on SPI
> + depends on OF
> + depends on REGULATOR
> + help
> +   Say yes here to build the driver for the TI DAC8554.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called ti-dac8554.
> +
>  endmenu
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 52be7e1..b98d79a 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -20,3 +20,4 @@ obj-$(CONFIG_MAX517) += max517.o
>  obj-$(CONFIG_MAX5821) += max5821.o
>  obj-$(CONFIG_MCP4725) += mcp4725.o
>  obj-$(CONFIG_MCP4922) += mcp4922.o
> +obj-$(CONFIG_TI_DAC8554) += ti-dac8554.o
> diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
> new file mode 100644
> index 000..84b9f42
> --- /dev/null
> +++ b/drivers/iio/dac/ti-dac8554.c
> @@ -0,0 +1,381 @@
> +/*
> + * TI DAC8554 Digital to Analog Converter SPI driver
> + *
> + * Copyright (C) 2014 Avionic Design GmbH
> + *
> + * Based on ad5446r_spi.c
> + * Copyright (C) 2010,2011 Analog Devices Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DAC8554_DRIVERNAME   "ti-dac8554"
> +#define DAC8554_DAC_CHANNELS 4
> +#define DAC8554_DATABITS 16
> +
> +/* Load commands */
> +#define DAC8554_CMD_STORE_DAC_N  0x0
> +#define DAC8554_CMD_UPDATE_DAC_N 0x1
> +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL   0x2
> +#define DAC8554_CMD_UPDATE_BROADCAST 0x3
> +
> +#define DAC8554_BROADCAST_USE_SRDATA 0x2
> +
> +/* Powerdown modes (PD1 | PD2 bits) */
> +#define DAC8554_PWRDN_HIZ0x0
> +#define DAC8554_PWRDN_1K 0x1
> +#define DAC8554_PWRDN_100K   0x2
> +
> +/* Input shift register composition */
> +#define DAC8554_ADDR_TO_SR(addr) ((addr) << 22)
> +#define DAC8554_CMD_TO_SR(cmd)   ((cmd) << 20)
> +#define DAC8554_CHAN_TO_SR(chan) ((chan) << 17)
> +#define DAC8554_PWRDN_TO_SR(mode)(BIT(16) | (mode) << 14)
> +
> +/**
> + * struct dac8554_state - driver instance specific data
> + * @spi: SPI device
> + * @reg: supply regulator
> + * @addr:two-bit chip address
> + * @val: channel data
> + * @powerdown:   channel powerdown flag
> + * @powerdown_mode:  channel powerdown mode
> + * @xfer:SPI transfer buffer
> + */
> +struct dac8554_state {
> + struct spi_device   *spi;
> + struct regulator*reg;
> + unsignedaddr;
> + u16 val[DAC8554_DAC_CHANNELS];
> + boolpowerdown[DAC8554_DAC_CHANNELS];
> + u8  powerdown_mode[DAC8554_DAC_CHANNELS];
> +
> +  

[RFC] mm:change meminfo cached calculation

[Wang, Yalin]

This patch subtract sharedram from cached,
sharedram can only be swap into swap partitions,
they should be treated as swap pages, not as cached pages.

Signed-off-by: Yalin Wang 
---
 fs/proc/meminfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index d3ebf2e..2b598a6 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -45,7 +45,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
committed = percpu_counter_read_positive(&vm_committed_as);
 
cached = global_page_state(NR_FILE_PAGES) -
-   total_swapcache_pages() - i.bufferram;
+   total_swapcache_pages() - i.bufferram - i.sharedram;
if (cached < 0)
cached = 0;
 
-- 
2.1.3
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[GIT PULL] parisc fix for v3.19

[Helge Deller]

Hi Linus,

please pull one patch for the parisc architecture for kernel 3.19 from 

  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
parisc-3.19-1

This patch unbreaks the kernel compilation on parisc with gcc-4.9.

Thanks,
Helge


John David Anglin (1):
  parisc: fix out-of-register compiler error in ldcw inline assembler 
function

 arch/parisc/include/asm/ldcw.h | 13 ++---
 1 file changed, 10 insertions(+), 3 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/

deb-pkg: Cleaning of debian/*tmp files when running 'make (dist)clean'

[Sedat Dilek]

Hi,

I creating Debian/Ubuntu packages using builddeb script ('make deb-pkg').

While I was doing a 'make distclean' and grep-ed for some patterns I
saw that my debian/*tmp dirs were not deleted.

$ ls debian/*tmp
debian/fwtmp:
DEBIAN  lib  usr

debian/hdrtmp:
DEBIAN  lib  usr

debian/headertmp:
DEBIAN  usr

debian/tmp:
boot  DEBIAN  etc  lib  usr

Any chance that this is also done on 'make (dist)clean' (not only
within the builddeb script)?

111:rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir"
"$libc_headers_dir" "$dbg_dir"

Any other make (PHONY) target I don't know?

Or introduce sth. like clean_tmpdirs() executed before 'exit 0' (or
simply invoke above rm-line).

BTW, can we have some more meaningful var-names for both headers-dirs,
something like...

[ scripts/package/builddeb ]

-kernel_headers_dir="$objtree/debian/hdrtmp"
-libc_headers_dir="$objtree/debian/headertmp"
+kernel_headers_dir="$objtree/debian/k_hdrtmp"
+libc_headers_dir="$objtree/debian/c_hdrtmp"

...it's a bit confusing when you look at filesystem-level (dirs, files).

Thanks.

Regards,
- Sedat -
--
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: wireless-drivers 2014-12-26

[Kalle Valo]

Hi Dave,

here's my first wireless-drivers pull request after John's "retirement".
I'll start this with few fixes for 3.19, changelog below.

I used a signed tag to create this pull request, I hope that's ok.
Please let me know if there are any problems.

Kalle


The following changes since commit 02d6a746c3f0cdd6f8aad0afd0b32d4646d6525e:

  Merge branch 'for-upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth (2014-12-19 
15:47:32 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2014-12-26

for you to fetch changes up to 8975842bed0840f314281c9fbf021a1d29537cf0:

  brcmfmac: Do not crash if platform data is not populated (2014-12-24 15:26:46 
+0200)


o Paul made a Kconfig dependency fix to ipw2200, it was not possible to
  enable that driver because Wireless Extensions is now disabled by default.

o Mika fixed brcmfmac not to crash when platform data is not populated

o Emmanuel provided few fixes to iwlwifi, he says:

  "I have here new device IDs and a fix for double free bug I
  introduced. I also fix an issue with the RFKILL interrupt - the HW
  needs us to ACK the interrupt again after we reset it. Liad fixes an
  issue with the firmware debugging infrastructure. While working on
  torture scenarios of firmware restarts, Eliad found an issue which
  he fixed."


Eliad Peller (1):
  iwlwifi: mvm: clear IN_HW_RESTART flag on stop()

Emmanuel Grumbach (3):
  iwlwifi: pcie: re-ACK all interrupts after device reset
  iwlwifi: don't double free a pointer if no FW was found
  iwlwifi: add new device IDs for 3165

Kalle Valo (1):
  Merge tag 'iwlwifi-fixes-for-kalle-2014-12-18' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes

Liad Kaufman (1):
  iwlwifi: pcie: limit fw chunk sizes given to fh

Mika Westerberg (1):
  brcmfmac: Do not crash if platform data is not populated

Paul Bolle (1):
  ipw2200: select CFG80211_WEXT

 drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c |4 ++--
 drivers/net/wireless/ipw2x00/Kconfig |3 ++-
 drivers/net/wireless/iwlwifi/iwl-drv.c   |2 +-
 drivers/net/wireless/iwlwifi/iwl-fh.h|1 +
 drivers/net/wireless/iwlwifi/mvm/mac80211.c  |   15 +--
 drivers/net/wireless/iwlwifi/pcie/drv.c  |4 
 drivers/net/wireless/iwlwifi/pcie/trans.c|   17 +++--
 7 files changed, 34 insertions(+), 12 deletions(-)

-- 
Kalle Valo
--
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] x86: Remove excess calculations for heap_end_ptr

[Alexander Kuleshov]

heap_end_ptr default value defined as _end+STACK_SZE-512, but
STACK_SIZE is already 512.

Signed-off-by: Alexander Kuleshov 
---
 arch/x86/boot/header.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 16ef025..c69b870 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -342,7 +342,7 @@ ramdisk_size:   .long   0   # its size in 
bytes
 bootsect_kludge:
.long   0   # obsolete
 
-heap_end_ptr:  .word   _end+STACK_SIZE-512
+heap_end_ptr:  .word   _end
# (Header version 0x0201 or later)
# space from here (exclusive) down to
# end of setup code can be used by setup
-- 
2.2.1.201.gbbcefff

--
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 1/5] iio: common: ssp_sensors: Add sensorhub driver

[Jonathan Cameron]

On 16/12/14 10:17, Karol Wrona wrote:
> On 12/06/2014 03:09 PM, Jonathan Cameron wrote:
>> On 05/12/14 19:54, Karol Wrona wrote:
>>> Sensorhub  is MCU dedicated to collect data and manage several sensors.
>>> Sensorhub is a spi device which provides a layer for IIO devices. It 
>>> provides
>>> some data parsing and common mechanism for sensorhub sensors.
>>>
>>> Adds common sensorhub library for sensorhub driver and iio drivers
>>> which uses sensorhub MCU to communicate with sensors.
>>>
>>> Change-Id: I4f066e9f3f477d4f6faabd4507be98e32f79e344
>>> Signed-off-by: Karol Wrona 
>>> Acked-by: Kyungmin Park 
>> Nice bit of code.  A few comments inline, mostly slight preferences rather
>> than anything else.  I wonder if it's worth centralising some of the buffers
>> to cut down on the large number of little allocations.
> I have some questions (inline).

>>> +
>>> +/**
>>> + * ssp_disable_sensor() - disables sensor
>>> + *
>>> + * @data:  sensorhub structure
>>> + * @type:  SSP sensor type
>>> + *
>>> + * Returns 0 or negative value in case of error
>> Nice docs. Though why this rather obvious one gets docs and the less
>> obvious ones don't is an interesting question...
> Just because they are exported.
Hmm.  Nothing wrong with documenting things that aren't as well if it helps
with clarity ;)  
>>> + */
>>> +int ssp_disable_sensor(struct ssp_data *data, enum ssp_sensor_type type)
>>> +{
>>> +   int ret;
>>> +   __le32 command;
>>> +
>>> +   if (data->sensor_enable & BIT(type)) {
>>> +   command = cpu_to_le32(data->delay_buf[type]);
>>> +
>>> +   ret = ssp_send_instruction(data,
>>> +  SSP_MSG2SSP_INST_BYPASS_SENSOR_RM,
>>> +  type, (u8 *)&command,
>>> +  sizeof(command));
>>> +   if (ret < 0) {
>>> +   dev_err(&data->spi->dev, "Remove sensor fail\n");
>>> +   return ret;
>>> +   }
>>> +
>>> +   data->sensor_enable &= ~BIT(type);
>>> +   }
>>> +
>>> +   data->check_status[type] = SSP_ADD_SENSOR_STATE;
>>> +
>>> +   if (atomic_dec_and_test(&data->enable_refcount))
>>> +   ssp_disable_wdt_timer(data);
>>> +
>>> +   return 0;
>>> +}
>>> +EXPORT_SYMBOL(ssp_disable_sensor);
>>> +
>>> +static irqreturn_t sensordata_irq_thread_fn(int irq, void *dev_id)
>>> +{
>>> +   struct ssp_data *data = dev_id;
>>> +
>>> +   ssp_irq_msg(data);
>> Why have this trivial wrapper instead of just having the code here?
>> Might make sense but please explain.
> I wanted to preserve error path for ssp_irq_msg and keep it in spi file.
Fair enough.
>>> +
>>> +   return IRQ_HANDLED;
>>> +}
>>> +
>>> +static int ssp_initialize_mcu(struct ssp_data *data)
>>> +{
>>> +   int ret;
>>> +
>>> +   ssp_clean_pending_list(data);
>>> +
>>> +   ret = ssp_get_chipid(data);
>>> +   if (ret != SSP_DEVICE_ID) {
>>> +   dev_err(&data->spi->dev, "%s - MCU %s ret = %d\n", __func__,
>>> +   ret < 0 ? "is not working" : "identification failed",
>>> +   ret);
>>> +   return ret < 0 ? ret : -ENODEV;
>>> +   }
>>> +
>>> +   dev_info(&data->spi->dev, "MCU device ID = %d\n", ret);
>>> +
>>> +   ret = ssp_set_sensor_position(data);
>>> +   if (ret < 0) {
>>> +   dev_err(&data->spi->dev, "ssp_set_sensor_position failed\n");
>>> +   return ret;
>>> +   }
>>> +
>>> +   ret = ssp_set_magnetic_matrix(data);
>> Hmm. It feels like this might belong more in the iio driver than here.
>> Please justify.
>>> +   if (ret < 0) {
>>> +   dev_err(&data->spi->dev,
>>> +   "%s - ssp_set_magnetic_matrix failed\n", __func__);
>>> +   return ret;
>>> +   }
>>> +
>>> +   data->available_sensors = ssp_get_sensor_scanning_info(data);
>>> +   if (data->available_sensors == 0) {
>>> +   dev_err(&data->spi->dev,
>>> +   "%s - ssp_get_sensor_scanning_info failed\n", __func__);
>>> +   return -EIO;
>>> +   }
>>> +
>>> +   data->cur_firm_rev = ssp_get_firmware_rev(data);
>>> +   dev_info(&data->spi->dev, "MCU Firm Rev : New = %8u\n",
>>> +data->cur_firm_rev);
>>> +
>>> +   return ssp_command(data, SSP_MSG2SSP_AP_MCU_DUMP_CHECK, 0);
>>> +}
>>> +
>> What's this doing?  Perhaps a bit of documentation to explain why a
>> task might want refreshing?
>>> +static void ssp_refresh_task(struct work_struct *work)
>>> +{
>>> +   struct ssp_data *data = container_of((struct delayed_work *)work,
>>> +struct ssp_data, work_refresh);
>>> +
>>> +   dev_info(&data->spi->dev, "refreshing\n");
>>> +
>>> +   data->reset_cnt++;
>>> +
>>> +   if (ssp_initialize_mcu(data) >= 0) {
>>> +   ssp_sync_available_sensors(data);
>>> +   if (data->last_ap_state != 0)
>>> +   ssp_command(data, data->last_ap_state, 0);
>>> +
>>> +   if (data->last_resume_state != 0)
>>> +   ssp_command(data, data->last_resume_s

Re: [PATCH v3 2/5] iio: sensorhub: Add sensorhub bindings

[Jonathan Cameron]

On 16/12/14 07:30, Karol Wrona wrote:
> On 12/06/2014 03:29 PM, Jonathan Cameron wrote:
>> On 05/12/14 19:54, Karol Wrona wrote:
>>> Add sensorhub bindings for sensorhub on Galaxy Gear 2.
>>>
>>> Change-Id: I4ee25aef33c21a4662de230841de9a8684f2c26b
>>> Signed-off-by: Karol Wrona 
>>> Acked-by: Kyungmin Park 
>> Looks good to me.  Comments inline.  Note I either need a device tree
>> ack or a long delay before I can take this though.  Unlikely to get the
>> device tree ack as you haven't cc'd the maintainers or list ;)
> I am curious about DT community opinion and I prefer to know it before
> v4 sending.
They have a lot of patches to review, so might take a while ;)
> 
>>
>> I've added the cc's. Please make sure future versions have them or you'll
>> just be slowing the process down (particularly if no one notices they 
>> are missing!)
> Thanks, I will remember that.
>>
>>> ---
>>>  .../devicetree/bindings/iio/sensorhub.txt  |   46 
>>> 
>>>  1 file changed, 46 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/iio/sensorhub.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/sensorhub.txt 
>>> b/Documentation/devicetree/bindings/iio/sensorhub.txt
>>> new file mode 100644
>>> index 000..2aca0c3
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/sensorhub.txt
>>> @@ -0,0 +1,46 @@
>>> +Samsung Sensorhub driver
>>> +
>>> +Sensorhub is a MCU which manages several sensors and also plays the role
>>> +of a virtual sensor device.
>>> +
>>> +Required properties:
>>> +- compatible: "samsung,sensorhub-rinato" or "samsung,sensorhub-thermostat"
>>> +- spi-max-frequency: max SPI clock frequency
>>> +- interrupt-parent: interrupt parent
>>> +- interrupts: communication interrupt
>>> +- ap-mcu-gpio: [out] ap to sensorhub line - used during communication
>>> +- mcu-ap-gpio: [in] sensorhub to ap - used during communication
>>> +- mcu-reset: [out] sensorhub reset
>> as commented in previous patch, why do the first two have -gpio and the
>> third not?
> Ok, all 3 will have "gpios" ending
>>> +
>>> +Optional properties:
>>> +- sensor's nodes:
>>> +  compatible = "samsung,mpu6500-accel"
>>> +  compatible = "samsung,mpu6500-gyro"
>>> +  compatible = "samsung,adpd142"
>>> +
>>> +Sensor compatibles are used to match proper sensor driver to real sensor on
>>> +the board. The firmware does not give such information, so it helps to 
>>> specify
>>> +some sensors properties. Sensors have "samsung" prefixes because frequently
>>> +they will not have much in common with sensors used without sensorhub 
>>> because
>>> +it can do some data processing.
>> We'll keep that under review.  Might make sense, sometimes, to unify the
>> drivers.  The different compatible will probably still be needed, but if
>> these devices proliferate I don't want two drivers for everything that
>> gets stuck behind them.
> I think that sensorhub is very similar hid-sensor (without hotpluging) where
> every sensor type has its own representation.  The real sensors are not driven
> directly but by external MCU so very often these sensors will not have much
> common with real ones.  So I wonder if it could be better to resign from these
> sensor compatibles and represent each sensor as mfd cell so optional 
> properties
> probably will dropped (?)
Might do.
> Generally I intended to have i.e. one ssp-accel driver if they use another
> accelerometer then mpu6500 the buffering manner and sysfs will be handled in 
> the
> same way.  I think I was mistaken with these compatibles.  There is also some
> probability that the firmware will be fixed someday and it will be able to 
> tell
> more about sensor then the type.
Would be good - particularly if we start to get lots of variants out in the 
wild.
> 
>>> +
>>> +Example:
>>> +
>>> +   shub_spi: shub {
>>> +   compatible = "samsung,sensorhub-rinato";
>>> +   spi-max-frequency = <500>;
>>> +   interrupt-parent = <&gpx0>;
>>> +   interrupts = <2 0>;
>>> +   ap-mcu-gpio = <&gpx0 0 0>;
>>> +   mcu-ap-gpio = <&gpx0 4 0>;
>>> +   mcu-reset = <&gpx0 5 0>;
>>> +   sensor@0 {
>>> +   compatible = "samsung,mpu6500-accel";
>>> +   };
>>> +   sensor@1 {
>>> +   compatible = "samsung,mpu6500-gyro";
>>> +   };
>>> +   sensor@2 {
>>> +   compatible = "samsung,adpd142";
>>> +   };
>>> +   };
>>>
>>
>>
> 

--
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 4/5] iio: common: ssp_sensors: Add sensorhub accelerometer sensor

[Jonathan Cameron]

On 08/12/14 10:41, Karol Wrona wrote:
> On 12/06/2014 03:52 PM, Jonathan Cameron wrote:
>> On 05/12/14 19:54, Karol Wrona wrote:
>>> This patch adds accelerometer iio driver which uses sensorhub as data
>>> provider.
>>>
>>> Change-Id: I4686741b7401ec5cbf4b5d0f2a5cc146fbe24d53
>>> Signed-off-by: Karol Wrona 
>>> Acked-by: Kyungmin Park 
>>> ---
>>>   drivers/iio/accel/Makefile   |1 +
>>>   drivers/iio/accel/ssp_accel_sensor.c |  203 
>>> ++
>>>   2 files changed, 204 insertions(+)
>>>   create mode 100644 drivers/iio/accel/ssp_accel_sensor.c
>>>
>>> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
>>> index a593996..df6a0b2 100644
>>> --- a/drivers/iio/accel/Makefile
>>> +++ b/drivers/iio/accel/Makefile
>>> @@ -9,6 +9,7 @@ obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>>>   obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
>>>   obj-$(CONFIG_KXSD9)+= kxsd9.o
>>>   obj-$(CONFIG_MMA8452)+= mma8452.o
>>> +obj-$(CONFIG_IIO_SSP_SENSOR) += ssp_accel_sensor.o
>>>
>>>   obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
>>>   st_accel-y := st_accel_core.o
>>> diff --git a/drivers/iio/accel/ssp_accel_sensor.c 
>>> b/drivers/iio/accel/ssp_accel_sensor.c
>>> new file mode 100644
>>> index 000..0a47c29
>>> --- /dev/null
>>> +++ b/drivers/iio/accel/ssp_accel_sensor.c
>>> @@ -0,0 +1,203 @@
>>> +/*
>>> + *  Copyright (C) 2014, Samsung Electronics Co. Ltd. All Rights Reserved.
>>> + *
>>> + *  This program is free software; you can redistribute it and/or modify
>>> + *  it under the terms of the GNU General Public License as published by
>>> + *  the Free Software Foundation; either version 2 of the License, or
>>> + *  (at your option) any later version.
>>> + *
>>> + *  This program is distributed in the hope that it will be useful,
>>> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + *  GNU General Public License for more details.
>>> + *
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include "../common/ssp_sensors/ssp_iio_sensor.h"
>>> +
>>> +#define SSP_CHANNEL_COUNT 3
>>> +
>>> +#define SSP_ACCEL_NAME "ssp-accelerometer"
>>> +static const char ssp_accel_device_name[] = SSP_ACCEL_NAME;
>>> +
>>> +enum ssp_accel_3d_channel {
>>> +SSP_CHANNEL_SCAN_INDEX_X,
>>> +SSP_CHANNEL_SCAN_INDEX_Y,
>>> +SSP_CHANNEL_SCAN_INDEX_Z,
>>> +SSP_CHANNEL_SCAN_INDEX_TIME,
>>> +SSP_ACCEL_3D_CHANNEL_MAX,
>> you don't actually use this max element so drop it.
>>> +};
>>> +
>>> +static int ssp_accel_read_raw(struct iio_dev *indio_dev,
>>> +  struct iio_chan_spec const *chan,  int *val,
>>> +  int *val2, long mask)
>>> +{
>>> +u32 t;
>>> +struct ssp_data *data = dev_get_drvdata(indio_dev->dev.parent->parent);
>>> +
>>> +switch (mask) {
>>> +case IIO_CHAN_INFO_SAMP_FREQ:
>>> +t = ssp_get_sensor_delay(data, SSP_ACCELEROMETER_SENSOR);
>>> +ssp_convert_to_freq(t, val, val2);
>>> +return IIO_VAL_INT_PLUS_MICRO;
>>> +default:
>>> +break;
>>> +}
>>> +
>>> +return -EINVAL;
>>> +}
>>> +
>>> +static int ssp_accel_write_raw(struct iio_dev *indio_dev,
>>> +   struct iio_chan_spec const *chan, int val,
>>> +   int val2, long mask)
>>> +{
>>> +int ret;
>>> +struct ssp_data *data = dev_get_drvdata(indio_dev->dev.parent->parent);
>>> +
>>> +switch (mask) {
>>> +case IIO_CHAN_INFO_SAMP_FREQ:
>>> +ret = ssp_convert_to_time(val, val2);
>>> +ret = ssp_change_delay(data, SSP_ACCELEROMETER_SENSOR, ret);
>>> +if (ret < 0)
>>> +dev_err(&indio_dev->dev, "accel sensor enable fail\n");
>>> +
>>> +return ret;
>>> +default:
>>> +break;
>>> +}
>>> +
>>> +return -EINVAL;
>>> +}
>>> +
>>> +static struct iio_info ssp_accel_iio_info = {
>>> +.read_raw = &ssp_accel_read_raw,
>>> +.write_raw = &ssp_accel_write_raw,
>>> +};
>>> +
>>> +static const struct iio_chan_spec ssp_acc_channels[] = {
>>> +SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_X, SSP_CHANNEL_SCAN_INDEX_X),
>>> +SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_Y, SSP_CHANNEL_SCAN_INDEX_Y),
>>> +SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_Z, SSP_CHANNEL_SCAN_INDEX_Z),
>>> +IIO_CHAN_SOFT_TIMESTAMP(SSP_CHANNEL_SCAN_INDEX_TIME),
>> hmm. Not actually a soft timestamp so I guess we should really rename that
>> macro.  Actually is your resulting timestamp 32 bit?  If so you could
>> specify the channel as such and include a scale to allow userspace to
>> convert it as it wishes.
> Ok, I will rethink that.  This timestamp is 64-bit and it is system time
> plus diff taken from sample but I would have relative time at all on 32-bit.
>>> +};
>>> +
>>> +static int ssp_process_accel_data(struct iio_dev *indio_dev, void *buf,
>>> +  int64_t timestamp)
>> We could hang a set of tr

[PATCH 0/3] OMAP3 temperature sensor

[Sebastian Reichel]

Hi,

I've prepared an updated variant of the omap34xx temperature monitor driver.
It's based on the N9 driver instead of the N900 driver (and thus has omap36xx
support).

The differences compared to the original driver are:

 * DT based
 * No includes from arch, instead uses syscon DT node + regmap
 * Removed support for raw temperature reading
  - I assume this was used for debugging and regmap can be used
instead with newer kernels.
 * Introduction of managed resources where possible
 * Usage of module_platform_driver() macro
 * Added some comments referencing the TRM

So far the patchset is _compile-tested only_. I will test it on my N900 in
the next days.

-- Sebastian

Sebastian Reichel (3):
  DT Binding for omap3 temperature sensor
  hwmon: Driver for OMAP3 temperature sensor
  ARM: dts: OMAP34xx/36xx: Add temperature sensor

 .../bindings/hwmon/omap3-temperature.txt   |  25 ++
 arch/arm/boot/dts/omap34xx.dtsi|   7 +
 arch/arm/boot/dts/omap36xx.dtsi|   7 +
 drivers/hwmon/Kconfig  |   8 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/omap3-temp.c | 307 +
 6 files changed, 355 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
 create mode 100644 drivers/hwmon/omap3-temp.c

-- 
2.1.3

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

[PATCH 1/3] DT Binding for omap3 temperature sensor

[Sebastian Reichel]

OMAP34xx and OMAP36xx processors contain a register in the syscon area,
which can be used to determine the SoCs temperature. This provides a
DT binding specification for the temperature monitor.

Signed-off-by: Sebastian Reichel 
---
 .../bindings/hwmon/omap3-temperature.txt   | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/hwmon/omap3-temperature.txt

diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt 
b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
new file mode 100644
index 000..99631ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
@@ -0,0 +1,25 @@
+* OMAP3 temperature sensor
+
+The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
+which can be used to determine the SoCs temperature.
+
+Requires node properties:
+- compatible : should contain one of
+   - "ti,omap34xx-temperature-sensor" for OMAP34xx
+   - "ti,omap36xx-temperature-sensor" for OMAP36xx
+- syscon : Should be a phandle to system configuration node which
+   encompases the temperature register
+- clocks : Should contain 32KHz fclk clock specifier
+- clock-names :Should contain clock names
+   - "fck" for the 32KHz fclk clock specifier
+
+Example for omap34xx:
+
+/ {
+   temperature-sensor {
+   compatible = "ti,omap34xx-temperature-sensor";
+   syscon = <&omap3_scm_general>;
+   clocks = <&ts_fck>;
+   clock-names = "fck";
+   };
+};
-- 
2.1.3

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

[PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor

[Sebastian Reichel]

OMAP34xx and OMAP36xx processors contain a register in the syscon area,
which can be used to determine the SoCs temperature. This patch provides
a DT based driver for the temperature sensor based on an older driver
written by Peter De Schrijver for the Nokia N900 and N9.

Signed-off-by: Sebastian Reichel 
---
 drivers/hwmon/Kconfig  |   8 ++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/omap3-temp.c | 307 +
 3 files changed, 316 insertions(+)
 create mode 100644 drivers/hwmon/omap3-temp.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09..749748d 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1135,6 +1135,14 @@ config SENSORS_NCT7802
  This driver can also be built as a module.  If so, the module
  will be called nct7802.
 
+config SENSORS_OMAP3_TEMP
+   tristate "OMAP3 Temperature Sensor"
+   depends on OF && (ARCH_OMAP3 || COMPILE_TEST)
+   select MFD_SYSCON
+   help
+ If you say yes here you get support for the temperature sensor
+ built into OMAP3 processors.
+
 config SENSORS_PCF8591
tristate "Philips PCF8591 ADC/DAC"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5a69773 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_NCT6683)   += nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)  += nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)  += nct7802.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)   += ntc_thermistor.o
+obj-$(CONFIG_SENSORS_OMAP3_TEMP)   += omap3-temp.o
 obj-$(CONFIG_SENSORS_PC87360)  += pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)  += pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
new file mode 100644
index 000..5c331c5
--- /dev/null
+++ b/drivers/hwmon/omap3-temp.c
@@ -0,0 +1,307 @@
+/*
+ * omap3-temp.c - driver for OMAP34xx and OMAP36xx temperature sensor
+ *
+ * Copyright (c) 2014 Sebastian Reichel 
+ * Copyright (C) 2008, 2009, 2010 Nokia Corporation
+ *
+ * based on Peter De Schrijver's driver for N9
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* 32.768Khz clock speed in nano seconds */
+#define CLOCK_32K_SPEED_NS 30518
+
+/* minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_RISING_DELAY (11 * CLOCK_32K_SPEED_NS)
+
+/* From docs, maximum delay for EOCZ rise after SOC rise is
+ * 14 cycles of the 32.768Khz clock. But after some experiments,
+ * 24 cycles as maximum is safer. */
+#define EOCZ_MAX_RISING_DELAY (24 * CLOCK_32K_SPEED_NS)
+
+/* minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_FALLING_DELAY (36 * CLOCK_32K_SPEED_NS)
+
+/* maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_FALLING_DELAY (40 * CLOCK_32K_SPEED_NS)
+
+/* temperature register offset in the syscon register area */
+#define SYSCON_TEMP_REG 0x02B4
+
+/* TRM: Table 7-11. ADC Codes Versus Temperature */
+static const int adc_to_temp_3430[] = {
+   -400, -400, -400, -400, -400, -390, -380, -360, -340, -320, -310,
+   -290, -280, -260, -250, -240, -220, -210, -190, -180, -170, -150,
+   -140, -120, -110, -90, -80, -70, -50, -40, -20, -10, 00, 10, 30,
+   40, 50, 70, 80, 100, 110, 130, 140, 150, 170, 180, 200, 210, 220,
+   240, 250, 270, 280, 300, 310, 320, 340, 350, 370, 380, 390, 410, 420,
+   440, 450, 470, 480, 490, 510, 520, 530, 550, 560, 580, 590, 600, 620,
+   630, 650, 660, 670, 690, 700, 720, 730, 740, 760, 770, 790, 800, 810,
+   830, 840, 850, 870, 880, 890, 910, 920, 940, 950, 960, 980, 990, 1000,
+   1020, 1030, 1050, 1060, 1070, 1090, 1100, 1110, 1130, 1140, 1160,
+   1170, 1180, 1200, 1210, 1220, 1240, 1240, 1250, 1250, 1250, 1250,
+   1250};
+
+/* TRM: Table 13-11. ADC Code Versus Temperature */
+static const int adc_to_temp_3630[] = {
+   -400, -400, -400, -400, -400, -400, -400, -400, -400, -400, -400,
+   -400, -400, -400, -380, -350, -340, -320, -300, -280, -260, -240,
+   -220, -200, -185, -170, -150, -135, -120, -100, -80, -65, -50, -35,
+   -15, 0, 20, 35, 50, 65,

[PATCH 3/3] ARM: dts: OMAP34xx/36xx: Add temperature sensor

[Sebastian Reichel]

OMAP34xx and OMAP36xx processors contain a register in the
syscon area, which can be used to determine the SoCs temperature.

Signed-off-by: Sebastian Reichel 
---
 arch/arm/boot/dts/omap34xx.dtsi | 7 +++
 arch/arm/boot/dts/omap36xx.dtsi | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 3819c1e..64679ee 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -38,6 +38,13 @@
pinctrl-single,function-mask = <0xff1f>;
};
};
+
+   omap3_temperature_sensor: temperature-sensor {
+   compatible = "ti,omap34xx-temperature-sensor";
+   syscon = <&omap3_scm_general>;
+   clocks = <&ts_fck>;
+   clock-names = "fck";
+   };
 };
 
 &ssi {
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 541704a..be9ee1d 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -70,6 +70,13 @@
pinctrl-single,function-mask = <0xff1f>;
};
};
+
+   omap3_temperature_sensor: temperature-sensor {
+   compatible = "ti,omap36xx-temperature-sensor";
+   syscon = <&omap3_scm_general>;
+   clocks = <&ts_fck>;
+   clock-names = "fck";
+   };
 };
 
 /* OMAP3630 needs dss_96m_fck for VENC */
-- 
2.1.3

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

[PATCH] x86: Fix multiple coding style issues

[Alexander Kuleshov]

Signed-off-by: Alexander Kuleshov 
---
 arch/x86/boot/header.S | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 16ef025..75f016b 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -211,7 +211,8 @@ section_table:
.long   0   # PointerToLineNumbers
.word   0   # NumberOfRelocations
.word   0   # NumberOfLineNumbers
-   .long   0x60500020  # Characteristics (section 
flags)
+   .long   0x60500020  # Characteristics
+   # (section flags)
 
#
# The EFI application loader requires a relocation section
@@ -229,7 +230,8 @@ section_table:
.long   0   # PointerToLineNumbers
.word   0   # NumberOfRelocations
.word   0   # NumberOfLineNumbers
-   .long   0x42100040  # Characteristics (section 
flags)
+   .long   0x42100040  # Characteristics
+   # (section flags)
 
#
# The offset & size fields are filled in by build.c.
@@ -247,7 +249,8 @@ section_table:
.long   0   # PointerToLineNumbers
.word   0   # NumberOfRelocations
.word   0   # NumberOfLineNumbers
-   .long   0x60500020  # Characteristics (section 
flags)
+   .long   0x60500020  # Characteristics
+   # (section flags)
 
#
# The offset & size fields are filled in by build.c.
@@ -266,7 +269,8 @@ section_table:
.long   0   # PointerToLineNumbers
.word   0   # NumberOfRelocations
.word   0   # NumberOfLineNumbers
-   .long   0xc880  # Characteristics (section 
flags)
+   .long   0xc880  # Characteristics
+   # (section flags)
 
 #endif /* CONFIG_EFI_STUB */
 
@@ -426,7 +430,8 @@ cmdline_size:   .long   COMMAND_LINE_SIZE-1 #length of 
the command line,
 #added with boot protocol
 #version 2.06
 
-hardware_subarch:  .long 0 # subarchitecture, added with 
2.07
+hardware_subarch:  .long 0 # subarchitecture,
+   # added with 2.07
# default to 0 for normal x86 PC
 
 hardware_subarch_data: .quad 0
-- 
2.2.1.202.g98acd41

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

Re: [PATCH] staging: iio: accel: sca3000_core.c: Remove unused function

[Jonathan Cameron]

On 20/12/14 14:53, Rickard Strandqvist wrote:
> Remove the function sca3000_check_status() that is not used anywhere.
> 
> This was partially found by using a static code analysis program called 
> cppcheck.
> 
> Signed-off-by: Rickard Strandqvist 
Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  drivers/staging/iio/accel/sca3000_core.c |   27 ---
>  1 file changed, 27 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/sca3000_core.c 
> b/drivers/staging/iio/accel/sca3000_core.c
> index e4e5639..655e34c 100644
> --- a/drivers/staging/iio/accel/sca3000_core.c
> +++ b/drivers/staging/iio/accel/sca3000_core.c
> @@ -223,33 +223,6 @@ error_ret:
>   return ret;
>  }
>  
> -#ifdef SCA3000_DEBUG
> -/**
> - * sca3000_check_status() check the status register
> - *
> - * Only used for debugging purposes
> - **/
> -static int sca3000_check_status(struct device *dev)
> -{
> - int ret;
> - struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> - struct sca3000_state *st = iio_priv(indio_dev);
> -
> - mutex_lock(&st->lock);
> - ret = sca3000_read_data_short(st, SCA3000_REG_ADDR_STATUS, 1);
> - if (ret < 0)
> - goto error_ret;
> - if (st->rx[0] & SCA3000_EEPROM_CS_ERROR)
> - dev_err(dev, "eeprom error\n");
> - if (st->rx[0] & SCA3000_SPI_FRAME_ERROR)
> - dev_err(dev, "Previous SPI Frame was corrupt\n");
> -
> -error_ret:
> - mutex_unlock(&st->lock);
> - return ret;
> -}
> -#endif /* SCA3000_DEBUG */
> -
>  /**
>   * sca3000_show_rev() - sysfs interface to read the chip revision number
>   **/
> 

--
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: deb-pkg: Cleaning of debian/*tmp files when running 'make (dist)clean'

[Sedat Dilek]

On Fri, Dec 26, 2014 at 1:02 PM, Sedat Dilek  wrote:
[...]
>
> Any other make (PHONY) target I don't know?
>

I fell over "clean-dirs"...

scripts/package/Makefile:93:clean-dirs += $(objtree)/debian/

...but did not really understood how it works.
The main Makefile defines some clean-dirs PHONY#s.
I can only speculate, someone with more skillz in Makefile handling
should look at this.

Thanks.

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

[PATCH 1/2] mm/zpool: add name argument to create zpool

[Ganesh Mahendran]

Currently the underlay of zpool: zsmalloc/zbud, do not know
who creates them. There is not a method to let zsmalloc/zbud
find which caller they belogs to.

Now we want to add statistics collection in zsmalloc. We need
to name the debugfs dir for each pool created. The way suggested
by Minchan Kim is to use a name passed by caller(such as zram)
to create the zsmalloc pool.
/sys/kernel/debug/zsmalloc/zram0

This patch adds a argument *name* to zs_create_pool() and other
related functions.

Signed-off-by: Ganesh Mahendran 
---
 drivers/block/zram/zram_drv.c |8 +---
 include/linux/zpool.h |5 +++--
 include/linux/zsmalloc.h  |2 +-
 mm/zbud.c |3 ++-
 mm/zpool.c|5 +++--
 mm/zsmalloc.c |6 +++---
 mm/zswap.c|5 +++--
 7 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index bd8bda3..ebae0d9 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -314,9 +314,10 @@ static void zram_meta_free(struct zram_meta *meta)
kfree(meta);
 }
 
-static struct zram_meta *zram_meta_alloc(u64 disksize)
+static struct zram_meta *zram_meta_alloc(int device_id, u64 disksize)
 {
size_t num_pages;
+   char pool_name[8];
struct zram_meta *meta = kmalloc(sizeof(*meta), GFP_KERNEL);
if (!meta)
goto out;
@@ -328,7 +329,8 @@ static struct zram_meta *zram_meta_alloc(u64 disksize)
goto free_meta;
}
 
-   meta->mem_pool = zs_create_pool(GFP_NOIO | __GFP_HIGHMEM);
+   snprintf(pool_name, sizeof(pool_name), "zram%d", device_id);
+   meta->mem_pool = zs_create_pool(pool_name, GFP_NOIO | __GFP_HIGHMEM);
if (!meta->mem_pool) {
pr_err("Error creating memory pool\n");
goto free_table;
@@ -765,7 +767,7 @@ static ssize_t disksize_store(struct device *dev,
return -EINVAL;
 
disksize = PAGE_ALIGN(disksize);
-   meta = zram_meta_alloc(disksize);
+   meta = zram_meta_alloc(zram->disk->first_minor, disksize);
if (!meta)
return -ENOMEM;
 
diff --git a/include/linux/zpool.h b/include/linux/zpool.h
index f14bd75..56529b3 100644
--- a/include/linux/zpool.h
+++ b/include/linux/zpool.h
@@ -36,7 +36,8 @@ enum zpool_mapmode {
ZPOOL_MM_DEFAULT = ZPOOL_MM_RW
 };
 
-struct zpool *zpool_create_pool(char *type, gfp_t gfp, struct zpool_ops *ops);
+struct zpool *zpool_create_pool(char *type, char *name,
+   gfp_t gfp, struct zpool_ops *ops);
 
 char *zpool_get_type(struct zpool *pool);
 
@@ -80,7 +81,7 @@ struct zpool_driver {
atomic_t refcount;
struct list_head list;
 
-   void *(*create)(gfp_t gfp, struct zpool_ops *ops);
+   void *(*create)(char *name, gfp_t gfp, struct zpool_ops *ops);
void (*destroy)(void *pool);
 
int (*malloc)(void *pool, size_t size, gfp_t gfp,
diff --git a/include/linux/zsmalloc.h b/include/linux/zsmalloc.h
index 05c2147..3283c6a 100644
--- a/include/linux/zsmalloc.h
+++ b/include/linux/zsmalloc.h
@@ -36,7 +36,7 @@ enum zs_mapmode {
 
 struct zs_pool;
 
-struct zs_pool *zs_create_pool(gfp_t flags);
+struct zs_pool *zs_create_pool(char *name, gfp_t flags);
 void zs_destroy_pool(struct zs_pool *pool);
 
 unsigned long zs_malloc(struct zs_pool *pool, size_t size);
diff --git a/mm/zbud.c b/mm/zbud.c
index db8de74..6d7f128 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -130,7 +130,8 @@ static struct zbud_ops zbud_zpool_ops = {
.evict =zbud_zpool_evict
 };
 
-static void *zbud_zpool_create(gfp_t gfp, struct zpool_ops *zpool_ops)
+static void *zbud_zpool_create(char *name, gfp_t gfp,
+   struct zpool_ops *zpool_ops)
 {
return zbud_create_pool(gfp, zpool_ops ? &zbud_zpool_ops : NULL);
 }
diff --git a/mm/zpool.c b/mm/zpool.c
index 739cdf0..1fa01f6 100644
--- a/mm/zpool.c
+++ b/mm/zpool.c
@@ -140,7 +140,8 @@ static void zpool_put_driver(struct zpool_driver *driver)
  *
  * Returns: New zpool on success, NULL on failure.
  */
-struct zpool *zpool_create_pool(char *type, gfp_t gfp, struct zpool_ops *ops)
+struct zpool *zpool_create_pool(char *type, char *name, gfp_t gfp,
+   struct zpool_ops *ops)
 {
struct zpool_driver *driver;
struct zpool *zpool;
@@ -168,7 +169,7 @@ struct zpool *zpool_create_pool(char *type, gfp_t gfp, 
struct zpool_ops *ops)
 
zpool->type = driver->type;
zpool->driver = driver;
-   zpool->pool = driver->create(gfp, ops);
+   zpool->pool = driver->create(name, gfp, ops);
zpool->ops = ops;
 
if (!zpool->pool) {
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index b724039..2359e61 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -246,9 +246,9 @@ struct mapping_area {
 
 #ifdef CONFIG_ZPOOL
 
-static void *zs_zpool_create(gfp_t gfp, struct zpool_ops *zpool_ops)
+static vo

[PATCH 2/2] mm/zsmalloc: add statistics support

[Ganesh Mahendran]

Keeping fragmentation of zsmalloc in a low level is our target. But now
we still need to add the debug code in zsmalloc to get the quantitative data.

This patch adds a new configuration CONFIG_ZSMALLOC_STAT to enable the
statistics collection for developers. Currently only the objects statatitics
in each class are collected. User can get the information via debugfs.
 cat /sys/kernel/debug/zsmalloc/zram0/...

For example:

After I copied "jdk-8u25-linux-x64.tar.gz" to zram with ext4 filesystem:
 class  size obj_allocated   obj_used pages_used
 032 0  0  0
 148   256 12  3
 26464 14  1
 38051  7  1
 496   128  5  3
 5   11273  5  2
 6   12832  4  1
 7   144 0  0  0
 8   160 0  0  0
 9   176 0  0  0
10   192 0  0  0
11   208 0  0  0
12   224 0  0  0
13   240 0  0  0
14   25616  1  1
15   27215  9  1
16   288 0  0  0
17   304 0  0  0
18   320 0  0  0
19   336 0  0  0
20   352 0  0  0
21   368 0  0  0
22   384 0  0  0
23   400 0  0  0
24   416 0  0  0
25   432 0  0  0
26   448 0  0  0
27   464 0  0  0
28   480 0  0  0
29   49633  1  4
30   512 0  0  0
31   528 0  0  0
32   544 0  0  0
33   560 0  0  0
34   576 0  0  0
35   592 0  0  0
36   608 0  0  0
37   624 0  0  0
38   640 0  0  0
40   672 0  0  0
42   704 0  0  0
43   72017  1  3
44   736 0  0  0
46   768 0  0  0
49   816 0  0  0
51   848 0  0  0
52   86414  1  3
54   896 0  0  0
57   94413  1  3
58   960 0  0  0
62  1024 4  1  1
66  108815  2  4
67  1104 0  0  0
71  1168 0  0  0
74  1216 0  0  0
76  1248 0  0  0
83  1360 3  1  1
91  148811  1  4
94  1536 0  0  0
   100  1632 5  1  2
   107  1744 0  0  0
   111  1808 9  1  4
   126  2048 4  4  2
   144  2336 7  3  4
   151  2448 0  0  0
   168  272015 15 10
   190  307228 27 21
   202  3264 0  0  0
   254  4096 36209  36209  36209

 Total   37022  36326  36288

We can calculate the overall fragentation by the last line:
Total   37022  36326  36288
(37022 - 36326) / 37022 = 1.87%

Also by analysing objects alocated in every class we know why we got so low 
fragmentation:
Most of the allocated objects is in . And there is only 1 page 
in class
254 zspage.  So, No fragmentation will be introduced by allocating objs in 
class 254.

And in the future, we can collect other zsmalloc statistics as we need and 
analyse them.

Signed-off-by: Ganesh Mahendran 
Suggested-by: Minchan Kim 
Cc: Nitin Gupta 
---
 mm/Kconfig|   10 +++
 mm/zsmalloc.c |  244 -
 2 files changed, 250 insertions(+), 4 deletions(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 1d1ae6b..95c5728 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -601,6 +601,16 @@ config PGTABLE_MAPPING
  You can check speed with zsmalloc benchmark:
  https://github.com/spartacus06/zsmapbench
 
+config ZSMALLOC_ST

Re: [PATCH v5 18/18] Documentation: ACPI for ARM64

[Mark Brown]

On Wed, Dec 24, 2014 at 05:18:15PM +, Catalin Marinas wrote:
> On Fri, Oct 17, 2014 at 02:37:14PM +0100, Hanjun Guo wrote:

> > +ACPI drivers should only look at one specific ASL object -- the _DSD object
> > +-- for device driver parameters (known in DT as "bindings", or "Device
> > +Properties" in ACPI).  Not all DT bindings will be recognized. 

> This last sentence kind of implies that many of the DT bindings will be
> recognised. While it is useful to have some commonalities, I think this
> gives the wrong message that _DSD is a copy of DT. We should avoid this.

> > +so that they may be used on any operating system supporting ACPI.  Device
> > +properties that have not been registered with the UEFI Forum should not be
> > +used.

> More about this further down.

Indeed...

> > +Drivers should look for device properties in the _DSD object ONLY; the _DSD
> > +object is described in the ACPI specification section 6.2.5, but more
> > +specifically, use the _DSD Device Properties UUID:

> > +   -- UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301

> > +   -- 
> > http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf)

> > +The kernel has an interface for looking up device properties in a manner
> > +independent of whether DT or ACPI is being used and that interface should
> > +be used;

> I haven't followed the _DSD kernel support but does it provide a common
> API to be shared with DT? I'm not entirely convinced it's a good idea.

Yes, it does.  I'm not entirely convinced about that either but it
really meets the goals of some of the users.  Right now I'm seeing
several user communities:

 - x86 server
 - x86 laptop
 - x86 embedded 
 - ARM server

The _DSD/DT abstraction API is intended to meet the needs of the x86
embedded community, they are really only interested in Linux and just
want to be able to pick up Linux drivers that have been developed with
DT in mind and use them with the minimum fuss.  They are, to a good
approximation, not really interested in UEFI and ACPI per se.

> > it can eliminate some duplication of code paths in driver probing
> > +functions and discourage divergence between DT bindings and ACPI device
> > +properties.

> Given the current different mechanism of reviewing/approving bindings
> between DT and ACPI (kernel community vs UEFI forum), I don't see how we

Right now there is no real way of reviewing and approving bindings for
_DSD.

> encourage convergence (unless we state that _DSD are Linux-only, Windows
> should use a different mechanism like .inf files).

No, I don't think we want to encourage that.  It's what's happening
right now for the x86 laptop case and it's making things miserable for
people working with audio, what we end up with on the Linux side is
needing to have per-machine quirk tables which means that Linux has
little chance of working out of the box with unknown hardware.  It's bad
for users and not a lot of fun for developers.  What you're saying is
fine for the x86 embedded people but as soon as we want to run both
Windows and Linux on the same system we want to try to make sure that
the firmware itself describes the hardware.

Note also that there are already some non-_DSD ways of passing platform
data to ACPI devices (you can read at least integer properties easily)
so it's not just _DSD we have to consider here.

> > +The _DSD object is a very flexible mechanism in ACPI, as are the registered
> > +Device Properties.  This flexibility allows _DSD to cover more than just 
> > the
> > +generic server case and care should be taken in device drivers not to 
> > expect
> > +it to replicate highly specific embedded behaviour from DT.

> While this is all good, we need to be more specific on what "embedded
> behaviour" means. Maybe not for this document but the UEFI approval
> process for new properties doesn't give any hint on what is and is not
> sane (and I already disagree with some of the examples on uefi.org).

Right, though we also don't want the UEFI approval process to set down
standards that are too heavily tied to a specific view for ARM servers
since ARM servers are not the only users.

> My problems with _DSD:

> a) no clear guidance on what a good property means, whether it covers
>just device specific information or it may include Linux behaviour
>(like "linux,default-trigger", I don't think it should)

Right, though some people are going to want to do that.

> b) the Linux kernel community does not seem to be involved in the UEFI
>forum _DSD review process. This means that we'll be faced with
>patches against drivers to support UEFI-published _DSD properties.
>I want to avoid such arguments, rejecting kernel code is too late
>after _DSD properties have been published

I've been very concerned about this and chasing it up myself.  As far as
I have been able to tell there essentially is no UEFI forum _DSD review
process at this point, the brief bits that are there are essentially
placeholders r

Re: [PATCH 1/8] iio: core: Introduce CALORIES channel type

[Jonathan Cameron]

On 19/12/14 22:57, Irina Tirdea wrote:
> Some devices compute the number of calories that the user has
> burnt since the last reset.
> 
> One of this devices is Freescale's MMA9553L
> (http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
> that computes the number of calories based on weight and step rate.
> 
> Introduce a new channel type CALORIES to export these values.
> 
> Signed-off-by: Irina Tirdea 
hmm..  Ideally we use SI units for everything, but in human energy usage
Calories are the most common unit by a long way.  I'm having some trouble
even finding the conversion for this particular for of calorie. 

Now clearly it doesn't matter if the only energy sensors we ever get
are for human activity. However, that's unlikely to be the case.  We
already have devices doing instantaneous power and there are plenty
of smart meter chips out there (though of course, they will use the
option of kW Hours just to confuse matters).

I'd definitely prefer joules if we can do it with out a large amount of
pain.

Lars - any views on this?  (Analog do make plenty of 'energy' measurement
devices after all!)
> ---
>  Documentation/ABI/testing/sysfs-bus-iio |9 +
>  drivers/iio/industrialio-core.c |1 +
>  include/linux/iio/types.h   |1 +
>  3 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index df5e69e..bb9342b 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -282,6 +282,7 @@ What: 
> /sys/bus/iio/devices/iio:deviceX/in_current_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_accel_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
> +What:/sys/bus/iio/devices/iio:deviceX/in_calories_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_magn_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
> @@ -1049,6 +1050,14 @@ Description:
>   For a list of available output power modes read
>   in_accel_power_mode_available.
>  
> +What:/sys/.../iio:deviceX/in_calories_input
> +What:/sys/.../iio:deviceX/in_calories_raw
> +KernelVersion:   3.17
> +Contact: linux-...@vger.kernel.org
> +Description:
> + This attribute is used to read the number of calories burned 
> since the last
> + reset. Units after application of scale are Joules.
> +
>  What:/sys/bus/iio/devices/iio:deviceX/store_eeprom
>  KernelVersion:   3.4.0
>  Contact: linux-...@vger.kernel.org
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index ee442ee..5d95e84 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -72,6 +72,7 @@ static const char * const iio_chan_type_name_spec[] = {
>   [IIO_HUMIDITYRELATIVE] = "humidityrelative",
>   [IIO_ACTIVITY] = "activity",
>   [IIO_STEPS] = "steps",
> + [IIO_CALORIES] = "calories",
>  };
>  
>  static const char * const iio_modifier_names[] = {
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index 904dcbb..d2fe930 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -32,6 +32,7 @@ enum iio_chan_type {
>   IIO_HUMIDITYRELATIVE,
>   IIO_ACTIVITY,
>   IIO_STEPS,
> + IIO_CALORIES,
>  };
>  
>  enum iio_modifier {
> 

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

[PATCH v3] ALSA: atmel: fix building the ac97 driver for at91-multiplatform

[Alexandre Belloni]

From: Arnd Bergmann 

at91 will no longer export the mach/cpu.h and mach/hardware.h header files
in the future, which would break building the atmel ac97c driver.

Since the cpu_is_* check is only used to find out whether we are running
on avr32 or arm/at91, we can hardcode that check in the ARM case.

Signed-off-by: Arnd Bergmann 
Link: http://www.spinics.net/lists/arm-kernel/msg382068.html
Signed-off-by: Alexandre Belloni 
---
Changes in v3:
 - added my SoB

 sound/atmel/ac97c.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/atmel/ac97c.c b/sound/atmel/ac97c.c
index b59427d5a697..e458957c5f52 100644
--- a/sound/atmel/ac97c.c
+++ b/sound/atmel/ac97c.c
@@ -34,10 +34,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_AVR32
 #include 
-
-#ifdef CONFIG_ARCH_AT91
-#include 
+#else
+#define cpu_is_at32ap7000() 0
 #endif
 
 #include "ac97c.h"
-- 
2.1.0

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

Re: [PATCH 3/8] iio: core: Introduce SPEED channel type

[Jonathan Cameron]

On 19/12/14 22:57, Irina Tirdea wrote:
> Some devices export the current speed value of the user.
> 
> One of this devices is Freescale's MMA9553L
> (http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
> that computes the speed of the user based on the number of steps and
> stride length.
> 
> Introduce a new channel type SPEED to export these values.
> 
A fun question raised by this is whether we are going to end up with
both speed and velocity (depending on whether it is signed or not).
I suppose there isn't much to be done about that though and this looks fine
to me (as does the previous one).
> Signed-off-by: Irina Tirdea 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio |9 +
>  drivers/iio/industrialio-core.c |1 +
>  include/linux/iio/types.h   |1 +
>  3 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index a5c1dcc..07acef7 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -295,6 +295,7 @@ What: 
> /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_pressure_scale
>  What:
> /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
> +What:/sys/bus/iio/devices/iio:deviceX/in_speed_scale
>  KernelVersion:   2.6.35
>  Contact: linux-...@vger.kernel.org
>  Description:
> @@ -1146,6 +1147,14 @@ Description:
>   present, output should be considered as processed with the
>   unit in milliamps.
>  
> +What:/sys/.../iio:deviceX/in_speed_input
> +What:/sys/.../iio:deviceX/in_speed_raw
> +KernelVersion:   3.19
> +Contact: linux-...@vger.kernel.org
> +Description:
> + This attribute is used to read the current speed value of the 
> user.
> + Units after application of scale are m/s.
> +
>  What:/sys/.../iio:deviceX/in_steps_en
>  KernelVersion:   3.19
>  Contact: linux-...@vger.kernel.org
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 4a10d31..5e50aca 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -74,6 +74,7 @@ static const char * const iio_chan_type_name_spec[] = {
>   [IIO_STEPS] = "steps",
>   [IIO_CALORIES] = "calories",
>   [IIO_DISTANCE] = "distance",
> + [IIO_SPEED] = "speed",
>  };
>  
>  static const char * const iio_modifier_names[] = {
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index b98f751..c848f45 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -34,6 +34,7 @@ enum iio_chan_type {
>   IIO_STEPS,
>   IIO_CALORIES,
>   IIO_DISTANCE,
> + IIO_SPEED,
>  };
>  
>  enum iio_modifier {
> 

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

Re: [PATCH 5/8] iio: core: Introduce IIO_CHAN_INFO_CALIBGENDER

[Jonathan Cameron]

On 19/12/14 22:57, Irina Tirdea wrote:
> Some devices need the gender of the user to compute various
> parameters. One of this devices is Freescale's MMA9553L
> (http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
> that needs the gender of the user to compute distance, speed and activity 
> type.
> 
> Signed-off-by: Irina Tirdea 

> ---
>  Documentation/ABI/testing/sysfs-bus-iio |8 
>  drivers/iio/industrialio-core.c |1 +
>  include/linux/iio/iio.h |1 +
>  3 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index e480175..3b68c2d 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -343,6 +343,14 @@ Description:
>   production inaccuracies).  If shared across all channels,
>   _calibscale is used.
>  
> +What:/sys/bus/iio/devices/iio:deviceX/in_steps_calibgender
> +KernelVersion:   3.19
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Gender of the user: 0 for female and 1 for male. It is needed
> + by some pedometers to compute the stride length, distance,
> + speed and activity type.
This will have to go through the extended attribute enum interface. No magic
numbers in the interface please.  
> +
>  What:/sys/bus/iio/devices/iio:deviceX/in_steps_calibheight
>  KernelVersion:   3.19
>  Contact: linux-...@vger.kernel.org
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 4c435c8..93a39f9 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -125,6 +125,7 @@ static const char * const iio_chan_info_postfix[] = {
>   [IIO_CHAN_INFO_ENABLE] = "en",
>   [IIO_CHAN_INFO_CALIBHEIGHT] = "calibheight",
>   [IIO_CHAN_INFO_CALIBWEIGHT] = "calibweight",
> + [IIO_CHAN_INFO_CALIBGENDER] = "calibgender",
>  };
>  
>  /**
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index 752a929..63dac0f 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -41,6 +41,7 @@ enum iio_chan_info_enum {
>   IIO_CHAN_INFO_ENABLE,
>   IIO_CHAN_INFO_CALIBHEIGHT,
>   IIO_CHAN_INFO_CALIBWEIGHT,
> + IIO_CHAN_INFO_CALIBGENDER,
>  };
>  
>  enum iio_shared_by {
> 

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

Re: [PATCH 4/8] iio: core: Introduce IO_CHAN_INFO_CALIBWEIGHT

[Jonathan Cameron]

On 19/12/14 22:57, Irina Tirdea wrote:
> Some devices need the weight of the user to compute other
> parameters. One of this devices is Freescale's MMA9553L
> (http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
> that needs the weight of the user to compute the number of calories burnt.
> 
> Signed-off-by: Irina Tirdea 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio |7 +++
>  drivers/iio/industrialio-core.c |1 +
>  include/linux/iio/iio.h |1 +
>  3 files changed, 9 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 07acef7..e480175 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -351,6 +351,13 @@ Description:
>   to compute the stride length, distance, speed and activity
>   type.
>  
> +What:/sys/bus/iio/devices/iio:deviceX/in_steps_calibweight
> +KernelVersion:   3.19
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Weight of the user (in kg). It is needed by some pedometers
> + to compute the calories burnt by the user.
How about grams?  Nice to keep to SI units going forward (I appreciate we
have broken that for what seemed like good reasons at the time) in one
or two places, but it makes it much harder to define consistent interfaces in 
the
long run.

J
> +
>  What:
> /sys/bus/iio/devices/iio:deviceX/in_accel_scale_available
>  What:/sys/.../iio:deviceX/in_voltageX_scale_available
>  What:/sys/.../iio:deviceX/in_voltage-voltage_scale_available
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 5e50aca..4c435c8 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -124,6 +124,7 @@ static const char * const iio_chan_info_postfix[] = {
>   [IIO_CHAN_INFO_INT_TIME] = "integration_time",
>   [IIO_CHAN_INFO_ENABLE] = "en",
>   [IIO_CHAN_INFO_CALIBHEIGHT] = "calibheight",
> + [IIO_CHAN_INFO_CALIBWEIGHT] = "calibweight",
>  };
>  
>  /**
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index 878d861..752a929 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -40,6 +40,7 @@ enum iio_chan_info_enum {
>   IIO_CHAN_INFO_INT_TIME,
>   IIO_CHAN_INFO_ENABLE,
>   IIO_CHAN_INFO_CALIBHEIGHT,
> + IIO_CHAN_INFO_CALIBWEIGHT,
>  };
>  
>  enum iio_shared_by {
> 

--
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 37/37] perf data: Implement 'split' subcommand

[Jiri Olsa]

On Wed, Dec 24, 2014 at 04:15:33PM +0900, Namhyung Kim wrote:
> The perf data split command is for splitting a (large) single data
> file into multiple files under a directory (perf.data.dir by default)
> so that it can be processed and reported using multiple threads.
> 
> Signed-off-by: Namhyung Kim 
> ---
>  tools/perf/Documentation/perf-data.txt |  28 +
>  tools/perf/builtin-data.c  | 223 
> +
>  2 files changed, 251 insertions(+)
> 
> diff --git a/tools/perf/Documentation/perf-data.txt 
> b/tools/perf/Documentation/perf-data.txt
> index b8c83947715c..42708702f10c 100644
> --- a/tools/perf/Documentation/perf-data.txt
> +++ b/tools/perf/Documentation/perf-data.txt
> @@ -13,3 +13,31 @@ SYNOPSIS
>  DESCRIPTION
>  ---
>  Data file related processing.
> +
> +COMMANDS
> +
> +split::
> + Split single data file (perf.data) into multiple files under a directory
> + in order to be reported by multiple threads.
> +
> +OPTIONS for 'split'
> +-
> +-i::
> +--input::
> + Specify input perf data file path.
> +
> +-o::
> +--output::
> + Specify output perf data directory path.

should the -o have 'perf.data.dir' as default?

[jolsa@krava perf]$ ./perf record ls > /dev/null
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.000 MB perf.data (~0 samples) ]
[jolsa@krava perf]$ ./perf data split
[jolsa@krava perf]$ ll perf.data*
-rw--- 1 jolsa jolsa 16172 Dec 26 14:58 perf.data

jirka
--
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/PATCHSET 00/37] perf tools: Speed-up perf report by using multi thread (v1)

[Jiri Olsa]

On Wed, Dec 24, 2014 at 04:14:56PM +0900, Namhyung Kim wrote:

SNIP

> 
> 
> You can get it from 'perf/threaded-v1' branch on my tree at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> 
> Please take a look and play with it.  Any comments are welcome! :)

very nice at first round check ;-)

I'll do detailed review next week

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

Re: [PATCH] x86: Fix multiple coding style issues

[Jeremiah Mahler]

Alexander,

On Fri, Dec 26, 2014 at 06:38:59PM +0600, Alexander Kuleshov wrote:

Your description needs to be more specific than just "coding style
fixes".  What type of problems did you fix?  How did you find them?

(more inline...)

> Signed-off-by: Alexander Kuleshov 
> ---
>  arch/x86/boot/header.S | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> index 16ef025..75f016b 100644
> --- a/arch/x86/boot/header.S
> +++ b/arch/x86/boot/header.S
> @@ -211,7 +211,8 @@ section_table:
>   .long   0   # PointerToLineNumbers
>   .word   0   # NumberOfRelocations
>   .word   0   # NumberOfLineNumbers
> - .long   0x60500020  # Characteristics (section 
> flags)
> + .long   0x60500020  # Characteristics
> + # (section flags)
>  
>   #
>   # The EFI application loader requires a relocation section
> @@ -229,7 +230,8 @@ section_table:
>   .long   0   # PointerToLineNumbers
>   .word   0   # NumberOfRelocations
>   .word   0   # NumberOfLineNumbers
> - .long   0x42100040  # Characteristics (section 
> flags)
> + .long   0x42100040  # Characteristics
> + # (section flags)
>  
>   #
>   # The offset & size fields are filled in by build.c.
> @@ -247,7 +249,8 @@ section_table:
>   .long   0   # PointerToLineNumbers
>   .word   0   # NumberOfRelocations
>   .word   0   # NumberOfLineNumbers
> - .long   0x60500020  # Characteristics (section 
> flags)
> + .long   0x60500020  # Characteristics
> + # (section flags)
>  
>   #
>   # The offset & size fields are filled in by build.c.
> @@ -266,7 +269,8 @@ section_table:
>   .long   0   # PointerToLineNumbers
>   .word   0   # NumberOfRelocations
>   .word   0   # NumberOfLineNumbers
> - .long   0xc880  # Characteristics (section 
> flags)
> + .long   0xc880  # Characteristics
> + # (section flags)
>  
>  #endif /* CONFIG_EFI_STUB */
>  
> @@ -426,7 +430,8 @@ cmdline_size:   .long   COMMAND_LINE_SIZE-1 #length 
> of the command line,
>  #added with boot protocol
>  #version 2.06
>  
> -hardware_subarch:.long 0 # subarchitecture, added with 
> 2.07
> +hardware_subarch:.long 0 # subarchitecture,
> + # added with 2.07
>   # default to 0 for normal x86 PC
>  
>  hardware_subarch_data:   .quad 0
> -- 
> 2.2.1.202.g98acd41
> 

It looks like your fixes are for lines being over 80 characters.  While
it is preferrable that lines be less than 80 characters it is still
acceptable if they are longer.

If you are looking for things to fix I suggest looking in the
drivers/staging directory.  There are lots of things that need to be
fixed in there.

> --
> 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/

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

Re: [PATCH] x86: Remove excess calculations for heap_end_ptr

[Jeremiah Mahler]

Alexander,

On Fri, Dec 26, 2014 at 06:22:42PM +0600, Alexander Kuleshov wrote:
> heap_end_ptr default value defined as _end+STACK_SZE-512, but
STACK_SIZE 

> STACK_SIZE is already 512.
> 
> Signed-off-by: Alexander Kuleshov 
> ---
>  arch/x86/boot/header.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> index 16ef025..c69b870 100644
> --- a/arch/x86/boot/header.S
> +++ b/arch/x86/boot/header.S
> @@ -342,7 +342,7 @@ ramdisk_size: .long   0   # its size in 
> bytes
>  bootsect_kludge:
>   .long   0   # obsolete
>  
> -heap_end_ptr:.word   _end+STACK_SIZE-512
> +heap_end_ptr:.word   _end
>   # (Header version 0x0201 or later)
>   # space from here (exclusive) down to
>   # end of setup code can be used by setup

So right now STACK_SIZE happens to be 512 so STACK_SIZE-512 is zero.
What happens if someone changes the size of STACK_SIZE?

This change doesn't fix any problem right now and creates potential
problems in the future.

> -- 
> 2.2.1.201.gbbcefff
> 
> --
> 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/

-- 
- Jeremiah Mahler
--
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] stacktrace: add seq_print_stack_trace()

[Stefan I. Strogin]

Add a function seq_print_stack_trace() which prints stacktraces to seq_files.

Signed-off-by: Stefan I. Strogin 
---
 include/linux/stacktrace.h |  4 
 kernel/stacktrace.c| 17 +
 2 files changed, 21 insertions(+)

diff --git a/include/linux/stacktrace.h b/include/linux/stacktrace.h
index 669045a..6d62484 100644
--- a/include/linux/stacktrace.h
+++ b/include/linux/stacktrace.h
@@ -2,6 +2,7 @@
 #define __LINUX_STACKTRACE_H
 
 #include 
+#include 
 
 struct task_struct;
 struct pt_regs;
@@ -24,6 +25,8 @@ extern void save_stack_trace_tsk(struct task_struct *tsk,
 extern void print_stack_trace(struct stack_trace *trace, int spaces);
 extern int snprint_stack_trace(char *buf, size_t size,
struct stack_trace *trace, int spaces);
+extern void seq_print_stack_trace(struct seq_file *m,
+   struct stack_trace *trace, int spaces);
 
 #ifdef CONFIG_USER_STACKTRACE_SUPPORT
 extern void save_stack_trace_user(struct stack_trace *trace);
@@ -37,6 +40,7 @@ extern void save_stack_trace_user(struct stack_trace *trace);
 # define save_stack_trace_user(trace)  do { } while (0)
 # define print_stack_trace(trace, spaces)  do { } while (0)
 # define snprint_stack_trace(buf, size, trace, spaces) do { } while (0)
+# define seq_print_stack_trace(m, trace, spaces)   do { } while (0)
 #endif
 
 #endif
diff --git a/kernel/stacktrace.c b/kernel/stacktrace.c
index b6e4c16..66ef6f4 100644
--- a/kernel/stacktrace.c
+++ b/kernel/stacktrace.c
@@ -57,6 +57,23 @@ int snprint_stack_trace(char *buf, size_t size,
 }
 EXPORT_SYMBOL_GPL(snprint_stack_trace);
 
+void seq_print_stack_trace(struct seq_file *m, struct stack_trace *trace,
+   int spaces)
+{
+   int i;
+
+   if (WARN_ON(!trace->entries))
+   return;
+
+   for (i = 0; i < trace->nr_entries; i++) {
+   unsigned long ip = trace->entries[i];
+
+   seq_printf(m, "%*c[<%p>] %pS\n", 1 + spaces, ' ',
+   (void *) ip, (void *) ip);
+   }
+}
+EXPORT_SYMBOL_GPL(seq_print_stack_trace);
+
 /*
  * Architectures that do not implement save_stack_trace_tsk or
  * save_stack_trace_regs get this weak alias and a once-per-bootup warning
-- 
2.1.0

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

[PATCH 3/3] cma: add functions to get region pages counters

[Stefan I. Strogin]

From: Dmitry Safonov 

Here are two functions that provide interface to compute/get used size
and size of biggest free chunk in cma region.
Added that information in cmainfo.

Signed-off-by: Dmitry Safonov 
---
 include/linux/cma.h |  2 ++
 mm/cma.c| 34 ++
 2 files changed, 36 insertions(+)

diff --git a/include/linux/cma.h b/include/linux/cma.h
index 9384ba6..855e6f2 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -18,6 +18,8 @@ struct cma;
 extern unsigned long totalcma_pages;
 extern phys_addr_t cma_get_base(struct cma *cma);
 extern unsigned long cma_get_size(struct cma *cma);
+extern unsigned long cma_get_used(struct cma *cma);
+extern unsigned long cma_get_maxchunk(struct cma *cma);
 
 extern int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
diff --git a/mm/cma.c b/mm/cma.c
index ffaea26..5e560ed 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -78,6 +78,36 @@ unsigned long cma_get_size(struct cma *cma)
return cma->count << PAGE_SHIFT;
 }
 
+unsigned long cma_get_used(struct cma *cma)
+{
+   unsigned long ret = 0;
+
+   mutex_lock(&cma->lock);
+   /* pages counter is smaller than sizeof(int) */
+   ret = bitmap_weight(cma->bitmap, (int)cma->count);
+   mutex_unlock(&cma->lock);
+
+   return ret << (PAGE_SHIFT + cma->order_per_bit);
+}
+
+unsigned long cma_get_maxchunk(struct cma *cma)
+{
+   unsigned long maxchunk = 0;
+   unsigned long start, end = 0;
+
+   mutex_lock(&cma->lock);
+   for (;;) {
+   start = find_next_zero_bit(cma->bitmap, cma->count, end);
+   if (start >= cma->count)
+   break;
+   end = find_next_bit(cma->bitmap, cma->count, start);
+   maxchunk = max(end - start, maxchunk);
+   }
+   mutex_unlock(&cma->lock);
+
+   return maxchunk << (PAGE_SHIFT + cma->order_per_bit);
+}
+
 static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int align_order)
 {
if (align_order <= cma->order_per_bit)
@@ -591,6 +621,10 @@ static int s_show(struct seq_file *m, void *p)
struct cma_buffer *cmabuf;
struct stack_trace trace;
 
+   seq_printf(m, "CMARegion stat: %8lu kB total, %8lu kB used, %8lu kB max 
contiguous chunk\n\n",
+  cma_get_size(cma) >> 10,
+  cma_get_used(cma) >> 10,
+  cma_get_maxchunk(cma) >> 10);
mutex_lock(&cma->list_lock);
 
list_for_each_entry(cmabuf, &cma->buffers_list, list) {
-- 
2.1.0

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

[PATCH 0/3] mm: cma: /proc/cmainfo

[Stefan I. Strogin]

Hello all,

Here is a patch set that adds /proc/cmainfo.

When compiled with CONFIG_CMA_DEBUG /proc/cmainfo will contain information
about about total, used, maximum free contiguous chunk and all currently
allocated contiguous buffers in CMA regions. The information about allocated
CMA buffers includes pid, comm, allocation latency and stacktrace at the
moment of allocation.

Example:

# cat /proc/cmainfo 
CMARegion stat:65536 kB total,  248 kB used,65216 kB max contiguous 
chunk

0x3240 - 0x32401000 (4 kB), allocated by pid 63 (systemd-udevd), latency 74 
us
 [] dma_generic_alloc_coherent+0x86/0x160
 [] rpm_idle+0x1f/0x1f0
 [] dma_generic_alloc_coherent+0x0/0x160
 [] ohci_init+0x1fe/0x430 [ohci_hcd]
 [] dma_generic_alloc_coherent+0x0/0x160
 [] ohci_pci_reset+0x4f/0x60 [ohci_pci]
 [] usb_add_hcd+0x1fc/0x900 [usbcore]
 [] pcibios_set_master+0x38/0x90
 [] usb_hcd_pci_probe+0x176/0x4f0 [usbcore]
 [] pci_device_probe+0x6f/0xd0
 [] sysfs_create_link+0x25/0x50
 [] driver_probe_device+0x92/0x3b0
 [] __mutex_lock_slowpath+0x5b/0x90
 [] __driver_attach+0x0/0x80
 [] __driver_attach+0x79/0x80
 [] __driver_attach+0x0/0x80

0x32401000 - 0x32402000 (4 kB), allocated by pid 58 (systemd-udevd), latency 17 
us
 [] dmam_coherent_release+0x0/0x90
 [] __kmalloc_track_caller+0x31c/0x380
 [] dma_generic_alloc_coherent+0x86/0x160
 [] dma_generic_alloc_coherent+0x0/0x160
 [] dmam_alloc_coherent+0xb6/0x100
 [] ata_bmdma_port_start+0x43/0x60 [libata]
 [] ata_host_start.part.29+0xb8/0x190 [libata]
 [] pci_read+0x30/0x40
 [] ata_pci_sff_activate_host+0x29/0x220 [libata]
 [] ata_bmdma_interrupt+0x0/0x1f0 [libata]
 [] pcibios_set_master+0x38/0x90
 [] piix_init_one+0x44e/0x630 [ata_piix]
 [] mutex_lock+0x10/0x20
 [] kernfs_activate+0x63/0xd0
 [] kernfs_add_one+0xc3/0x130
 [] pci_device_probe+0x6f/0xd0
<...>

Dmitry Safonov (1):
  cma: add functions to get region pages counters

Stefan I. Strogin (2):
  stacktrace: add seq_print_stack_trace()
  mm: cma: introduce /proc/cmainfo

 include/linux/cma.h|   2 +
 include/linux/stacktrace.h |   4 +
 kernel/stacktrace.c|  17 
 mm/cma.c   | 236 +
 4 files changed, 259 insertions(+)

-- 
2.1.0

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

[PATCH 2/3] mm: cma: introduce /proc/cmainfo

[Stefan I. Strogin]

/proc/cmainfo contains a list of currently allocated CMA buffers for every
CMA area when CONFIG_CMA_DEBUG is enabled.

Format is:

 -  ( kB), allocated by \
(), latency  us
 

Signed-off-by: Stefan I. Strogin 
---
 mm/cma.c | 202 +++
 1 file changed, 202 insertions(+)

diff --git a/mm/cma.c b/mm/cma.c
index a85ae28..ffaea26 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -34,6 +34,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 struct cma {
unsigned long   base_pfn;
@@ -41,8 +45,25 @@ struct cma {
unsigned long   *bitmap;
unsigned int order_per_bit; /* Order of pages represented by one bit */
struct mutexlock;
+#ifdef CONFIG_CMA_DEBUG
+   struct list_head buffers_list;
+   struct mutexlist_lock;
+#endif
 };
 
+#ifdef CONFIG_CMA_DEBUG
+struct cma_buffer {
+   unsigned long pfn;
+   unsigned long count;
+   pid_t pid;
+   char comm[TASK_COMM_LEN];
+   unsigned int latency;
+   unsigned long trace_entries[16];
+   unsigned int nr_entries;
+   struct list_head list;
+};
+#endif
+
 static struct cma cma_areas[MAX_CMA_AREAS];
 static unsigned cma_area_count;
 static DEFINE_MUTEX(cma_mutex);
@@ -132,6 +153,10 @@ static int __init cma_activate_area(struct cma *cma)
} while (--i);
 
mutex_init(&cma->lock);
+#ifdef CONFIG_CMA_DEBUG
+   INIT_LIST_HEAD(&cma->buffers_list);
+   mutex_init(&cma->list_lock);
+#endif
return 0;
 
 err:
@@ -347,6 +372,86 @@ err:
return ret;
 }
 
+#ifdef CONFIG_CMA_DEBUG
+/**
+ * cma_buffer_list_add() - add a new entry to a list of allocated buffers
+ * @cma: Contiguous memory region for which the allocation is performed.
+ * @pfn: Base PFN of the allocated buffer.
+ * @count:   Number of allocated pages.
+ * @latency: Nanoseconds spent to allocate the buffer.
+ *
+ * This function adds a new entry to the list of allocated contiguous memory
+ * buffers in a CMA area. It uses the CMA area specificated by the device
+ * if available or the default global one otherwise.
+ */
+static int cma_buffer_list_add(struct cma *cma, unsigned long pfn,
+  int count, s64 latency)
+{
+   struct cma_buffer *cmabuf;
+   struct stack_trace trace;
+
+   cmabuf = kmalloc(sizeof(struct cma_buffer), GFP_KERNEL);
+   if (!cmabuf)
+   return -ENOMEM;
+
+   trace.nr_entries = 0;
+   trace.max_entries = ARRAY_SIZE(cmabuf->trace_entries);
+   trace.entries = &cmabuf->trace_entries[0];
+   trace.skip = 2;
+   save_stack_trace(&trace);
+
+   cmabuf->pfn = pfn;
+   cmabuf->count = count;
+   cmabuf->pid = task_pid_nr(current);
+   cmabuf->nr_entries = trace.nr_entries;
+   get_task_comm(cmabuf->comm, current);
+   cmabuf->latency = (unsigned int) div_s64(latency, NSEC_PER_USEC);
+
+   mutex_lock(&cma->list_lock);
+   list_add_tail(&cmabuf->list, &cma->buffers_list);
+   mutex_unlock(&cma->list_lock);
+
+   return 0;
+}
+
+/**
+ * cma_buffer_list_del() - delete an entry from a list of allocated buffers
+ * @cma:   Contiguous memory region for which the allocation was performed.
+ * @pfn:   Base PFN of the released buffer.
+ *
+ * This function deletes a list entry added by cma_buffer_list_add().
+ */
+static void cma_buffer_list_del(struct cma *cma, unsigned long pfn)
+{
+   struct cma_buffer *cmabuf;
+
+   mutex_lock(&cma->list_lock);
+
+   list_for_each_entry(cmabuf, &cma->buffers_list, list)
+   if (cmabuf->pfn == pfn) {
+   list_del(&cmabuf->list);
+   kfree(cmabuf);
+   goto out;
+   }
+
+   pr_err("%s(pfn %lu): couldn't find buffers list entry\n",
+  __func__, pfn);
+
+out:
+   mutex_unlock(&cma->list_lock);
+}
+#else
+static int cma_buffer_list_add(struct cma *cma, unsigned long pfn,
+  int count, s64 latency)
+{
+   return 0;
+}
+
+static void cma_buffer_list_del(struct cma *cma, unsigned long pfn)
+{
+}
+#endif /* CONFIG_CMA_DEBUG */
+
 /**
  * cma_alloc() - allocate pages from contiguous area
  * @cma:   Contiguous memory region for which the allocation is performed.
@@ -361,11 +466,15 @@ struct page *cma_alloc(struct cma *cma, int count, 
unsigned int align)
unsigned long mask, offset, pfn, start = 0;
unsigned long bitmap_maxno, bitmap_no, bitmap_count;
struct page *page = NULL;
+   struct timespec ts1, ts2;
+   s64 latency;
int ret;
 
if (!cma || !cma->count)
return NULL;
 
+   getnstimeofday(&ts1);
+
pr_debug("%s(cma %p, count %d, align %d)\n", __func__, (void *)cma,
 count, align);
 
@@ -413,6 +522,19 @@ struct page *cma_alloc(struct cma *cma, int count, 
unsigned int align)
start = bitmap_no + mask + 1;
}

[PATCH 6/27] cw1200: queue: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/cw1200/queue.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/cw1200/queue.c 
b/drivers/net/wireless/cw1200/queue.c
index 9c3925f..0ba5ef9 100644
--- a/drivers/net/wireless/cw1200/queue.c
+++ b/drivers/net/wireless/cw1200/queue.c
@@ -179,9 +179,7 @@ int cw1200_queue_init(struct cw1200_queue *queue,
INIT_LIST_HEAD(&queue->pending);
INIT_LIST_HEAD(&queue->free_pool);
spin_lock_init(&queue->lock);
-   init_timer(&queue->gc);
-   queue->gc.data = (unsigned long)queue;
-   queue->gc.function = cw1200_queue_gc;
+   setup_timer(&queue->gc, cw1200_queue_gc, (unsigned long)queue);
 
queue->pool = kzalloc(sizeof(struct cw1200_queue_item) * capacity,
GFP_KERNEL);

--
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 20/27] usb: r8a66597-hcd: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/usb/host/r8a66597-hcd.c |   10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index c4bcfae..a048b8e 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -2483,9 +2483,8 @@ static int r8a66597_probe(struct platform_device *pdev)
r8a66597->max_root_hub = 2;
 
spin_lock_init(&r8a66597->lock);
-   init_timer(&r8a66597->rh_timer);
-   r8a66597->rh_timer.function = r8a66597_timer;
-   r8a66597->rh_timer.data = (unsigned long)r8a66597;
+   setup_timer(&r8a66597->rh_timer, r8a66597_timer,
+   (unsigned long)r8a66597);
r8a66597->reg = reg;
 
/* make sure no interrupts are pending */
@@ -2496,9 +2495,8 @@ static int r8a66597_probe(struct platform_device *pdev)
 
for (i = 0; i < R8A66597_MAX_NUM_PIPE; i++) {
INIT_LIST_HEAD(&r8a66597->pipe_queue[i]);
-   init_timer(&r8a66597->td_timer[i]);
-   r8a66597->td_timer[i].function = r8a66597_td_timer;
-   r8a66597->td_timer[i].data = (unsigned long)r8a66597;
+   setup_timer(&r8a66597->td_timer[i], r8a66597_td_timer,
+   (unsigned long)r8a66597);
setup_timer(&r8a66597->interval_timer[i],
r8a66597_interval_timer,
(unsigned long)r8a66597);

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

[PATCH 5/27] [media] usbvision: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

The semantic patch also changes the cast to long to a cast to unsigned
long in the data initializer, as unsigned long is the type of the data field.

Signed-off-by: Julia Lawall 

---
 drivers/media/usb/usbvision/usbvision-core.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/usbvision/usbvision-core.c 
b/drivers/media/usb/usbvision/usbvision-core.c
index 302aa07..64c63d3 100644
--- a/drivers/media/usb/usbvision/usbvision-core.c
+++ b/drivers/media/usb/usbvision/usbvision-core.c
@@ -2194,9 +2194,8 @@ static void usbvision_power_off_timer(unsigned long data)
 
 void usbvision_init_power_off_timer(struct usb_usbvision *usbvision)
 {
-   init_timer(&usbvision->power_off_timer);
-   usbvision->power_off_timer.data = (long)usbvision;
-   usbvision->power_off_timer.function = usbvision_power_off_timer;
+   setup_timer(&usbvision->power_off_timer, usbvision_power_off_timer,
+   (unsigned long)usbvision);
 }
 
 void usbvision_set_power_off_timer(struct usb_usbvision *usbvision)

--
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 12/27] iwlwifi: dvm: main: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/iwlwifi/dvm/main.c |   10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/dvm/main.c 
b/drivers/net/wireless/iwlwifi/dvm/main.c
index 0b7f46f..75ec691 100644
--- a/drivers/net/wireless/iwlwifi/dvm/main.c
+++ b/drivers/net/wireless/iwlwifi/dvm/main.c
@@ -1011,13 +1011,11 @@ static void iwl_setup_deferred_work(struct iwl_priv 
*priv)
if (priv->lib->bt_params)
iwlagn_bt_setup_deferred_work(priv);
 
-   init_timer(&priv->statistics_periodic);
-   priv->statistics_periodic.data = (unsigned long)priv;
-   priv->statistics_periodic.function = iwl_bg_statistics_periodic;
+   setup_timer(&priv->statistics_periodic, iwl_bg_statistics_periodic,
+   (unsigned long)priv);
 
-   init_timer(&priv->ucode_trace);
-   priv->ucode_trace.data = (unsigned long)priv;
-   priv->ucode_trace.function = iwl_bg_ucode_trace;
+   setup_timer(&priv->ucode_trace, iwl_bg_ucode_trace,
+   (unsigned long)priv);
 }
 
 void iwl_cancel_deferred_work(struct iwl_priv *priv)

--
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 23/27] usb: isp1760: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/usb/host/isp1760-hcd.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/usb/host/isp1760-hcd.c
index 395649f..79261d5 100644
--- a/drivers/usb/host/isp1760-hcd.c
+++ b/drivers/usb/host/isp1760-hcd.c
@@ -1359,9 +1359,7 @@ static int isp1760_run(struct usb_hcd *hcd)
if (retval)
return retval;
 
-   init_timer(&errata2_timer);
-   errata2_timer.function = errata2_function;
-   errata2_timer.data = (unsigned long) hcd;
+   setup_timer(&errata2_timer, errata2_function, (unsigned long)hcd);
errata2_timer.expires = jiffies + SLOT_CHECK_PERIOD * HZ / 1000;
add_timer(&errata2_timer);
 

--
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 10/27] xhci-mem: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 

---
 drivers/usb/host/xhci-mem.c |   10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 5cb3d7a..e72265c 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -833,9 +833,8 @@ void xhci_free_stream_info(struct xhci_hcd *xhci,
 static void xhci_init_endpoint_timer(struct xhci_hcd *xhci,
struct xhci_virt_ep *ep)
 {
-   init_timer(&ep->stop_cmd_timer);
-   ep->stop_cmd_timer.data = (unsigned long) ep;
-   ep->stop_cmd_timer.function = xhci_stop_endpoint_command_watchdog;
+   setup_timer(&ep->stop_cmd_timer, xhci_stop_endpoint_command_watchdog,
+   (unsigned long)ep);
ep->xhci = xhci;
 }
 
@@ -2509,9 +2508,8 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
xhci_print_ir_set(xhci, 0);
 
/* init command timeout timer */
-   init_timer(&xhci->cmd_timer);
-   xhci->cmd_timer.data = (unsigned long) xhci;
-   xhci->cmd_timer.function = xhci_handle_command_timeout;
+   setup_timer(&xhci->cmd_timer, xhci_handle_command_timeout,
+   (unsigned long)xhci);
 
/*
 * XXX: Might need to set the Interrupter Moderation Register to

--
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 27/27] mwifiex: main: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/mwifiex/main.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/main.c 
b/drivers/net/wireless/mwifiex/main.c
index d4d2223..53f4202 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -83,9 +83,8 @@ static int mwifiex_register(void *card, struct mwifiex_if_ops 
*if_ops,
}
mwifiex_init_lock_list(adapter);
 
-   init_timer(&adapter->cmd_timer);
-   adapter->cmd_timer.function = mwifiex_cmd_timeout_func;
-   adapter->cmd_timer.data = (unsigned long) adapter;
+   setup_timer(&adapter->cmd_timer, mwifiex_cmd_timeout_func,
+   (unsigned long)adapter);
 
return 0;
 

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

[PATCH 25/27] mwifiex: tdls: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/mwifiex/tdls.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/tdls.c 
b/drivers/net/wireless/mwifiex/tdls.c
index 22884b4..5a64681 100644
--- a/drivers/net/wireless/mwifiex/tdls.c
+++ b/drivers/net/wireless/mwifiex/tdls.c
@@ -1367,9 +1367,8 @@ void mwifiex_check_auto_tdls(unsigned long context)
 
 void mwifiex_setup_auto_tdls_timer(struct mwifiex_private *priv)
 {
-   init_timer(&priv->auto_tdls_timer);
-   priv->auto_tdls_timer.function = mwifiex_check_auto_tdls;
-   priv->auto_tdls_timer.data = (unsigned long)priv;
+   setup_timer(&priv->auto_tdls_timer, mwifiex_check_auto_tdls,
+   (unsigned long)priv);
priv->auto_tdls_timer_active = true;
mod_timer(&priv->auto_tdls_timer,
  jiffies + msecs_to_jiffies(MWIFIEX_TIMER_10S));

--
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 15/27] net: sxgbe: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c |   10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c 
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 6984944..b6612d6 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -133,9 +133,8 @@ bool sxgbe_eee_init(struct sxgbe_priv_data * const priv)
return false;
 
priv->eee_active = 1;
-   init_timer(&priv->eee_ctrl_timer);
-   priv->eee_ctrl_timer.function = sxgbe_eee_ctrl_timer;
-   priv->eee_ctrl_timer.data = (unsigned long)priv;
+   setup_timer(&priv->eee_ctrl_timer, sxgbe_eee_ctrl_timer,
+   (unsigned long)priv);
priv->eee_ctrl_timer.expires = SXGBE_LPI_TIMER(eee_timer);
add_timer(&priv->eee_ctrl_timer);
 
@@ -1009,10 +1008,9 @@ static void sxgbe_tx_init_coalesce(struct 
sxgbe_priv_data *priv)
struct sxgbe_tx_queue *p = priv->txq[queue_num];
p->tx_coal_frames =  SXGBE_TX_FRAMES;
p->tx_coal_timer = SXGBE_COAL_TX_TIMER;
-   init_timer(&p->txtimer);
+   setup_timer(&p->txtimer, sxgbe_tx_timer,
+   (unsigned long)&priv->txq[queue_num]);
p->txtimer.expires = SXGBE_COAL_TIMER(p->tx_coal_timer);
-   p->txtimer.data = (unsigned long)&priv->txq[queue_num];
-   p->txtimer.function = sxgbe_tx_timer;
add_timer(&p->txtimer);
}
 }

--
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 17/27] iwl3945: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/iwlegacy/3945-mac.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/iwlegacy/3945-mac.c 
b/drivers/net/wireless/iwlegacy/3945-mac.c
index dc1d20c..e566580 100644
--- a/drivers/net/wireless/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/iwlegacy/3945-mac.c
@@ -3429,9 +3429,7 @@ il3945_setup_deferred_work(struct il_priv *il)
 
il3945_hw_setup_deferred_work(il);
 
-   init_timer(&il->watchdog);
-   il->watchdog.data = (unsigned long)il;
-   il->watchdog.function = il_bg_watchdog;
+   setup_timer(&il->watchdog, il_bg_watchdog, (unsigned long)il);
 
tasklet_init(&il->irq_tasklet,
 (void (*)(unsigned long))il3945_irq_tasklet,

--
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 26/27] mwifiex: 11n_rxreorder: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/mwifiex/11n_rxreorder.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/11n_rxreorder.c 
b/drivers/net/wireless/mwifiex/11n_rxreorder.c
index d73fda3..f33dc81 100644
--- a/drivers/net/wireless/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/mwifiex/11n_rxreorder.c
@@ -391,10 +391,8 @@ mwifiex_11n_create_rx_reorder_tbl(struct mwifiex_private 
*priv, u8 *ta,
new_node->timer_context.priv = priv;
new_node->timer_context.timer_is_set = false;
 
-   init_timer(&new_node->timer_context.timer);
-   new_node->timer_context.timer.function = mwifiex_flush_data;
-   new_node->timer_context.timer.data =
-   (unsigned long) &new_node->timer_context;
+   setup_timer(&new_node->timer_context.timer, mwifiex_flush_data,
+   (unsigned long)&new_node->timer_context);
 
for (i = 0; i < win_size; ++i)
new_node->rx_reorder_ptr[i] = NULL;

--
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/

fanotify bug on gdb -- hard crash

[ivo welch]

I am not a kernel developer, so forgive the intrusion.

I suspect I have found either a bug in gdb (less likely) or a bug in
fanotify (more likely).  it is replicable, and the code is almost
unchanged from the example in the fanotify man page.  to trigger it,
all an su needs to do is to step through the program below with gdb
7.8.1 'n' command, and linux locks up the system pretty hard (reboot
required).  I have confirmed the replicability of this issue on a
clean arch 2014.12.01 3.17.6-1 system and on a clean ubuntu 14.10
system, both VMs created just to check it.  /iaw


#define _GNU_SOURCE /* Needed to get O_LARGEFILE definition */
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[]) {
  int fd;
  fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT | FAN_NONBLOCK,
O_RDONLY | O_LARGEFILE);
  if (fd == -1) exit(1);
  fprintf(stderr, "calling fanotify_mark: fd=%d\n", fd);
  if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT, FAN_OPEN_PERM |
FAN_CLOSE_WRITE, -1, "/") == -1) exit(2);
  fprintf(stderr, "in gdb step through with 'n' for repeat.\n");
  fprintf(stderr, "  (and sometimes otherwise), a ^C works, but a ^Z
and then ^C does not.\n");
}

I don't know who else to tell this.  I hope this report is useful, if
someone competent can confirm it.  /iaw


PS: Is there an alternative to fanotify to avoid this?  I want to
learn of all file-open requests on a ro device.

Ivo Welch (ivo.we...@gmail.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 7/27] cw1200: main: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/cw1200/main.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/cw1200/main.c 
b/drivers/net/wireless/cw1200/main.c
index 3e78cc3..fa965ee 100644
--- a/drivers/net/wireless/cw1200/main.c
+++ b/drivers/net/wireless/cw1200/main.c
@@ -374,9 +374,8 @@ static struct ieee80211_hw *cw1200_init_common(const u8 
*macaddr,
INIT_WORK(&priv->update_filtering_work, cw1200_update_filtering_work);
INIT_WORK(&priv->set_beacon_wakeup_period_work,
  cw1200_set_beacon_wakeup_period_work);
-   init_timer(&priv->mcast_timeout);
-   priv->mcast_timeout.data = (unsigned long)priv;
-   priv->mcast_timeout.function = cw1200_mcast_timeout;
+   setup_timer(&priv->mcast_timeout, cw1200_mcast_timeout,
+   (unsigned long)priv);
 
if (cw1200_queue_stats_init(&priv->tx_queue_stats,
CW1200_LINK_ID_MAX,

--
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 13/27] iwlwifi: dvm: tt: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/iwlwifi/dvm/tt.c |   13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/dvm/tt.c 
b/drivers/net/wireless/iwlwifi/dvm/tt.c
index acb981a..c4736c8 100644
--- a/drivers/net/wireless/iwlwifi/dvm/tt.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tt.c
@@ -612,15 +612,10 @@ void iwl_tt_initialize(struct iwl_priv *priv)
memset(tt, 0, sizeof(struct iwl_tt_mgmt));
 
tt->state = IWL_TI_0;
-   init_timer(&priv->thermal_throttle.ct_kill_exit_tm);
-   priv->thermal_throttle.ct_kill_exit_tm.data = (unsigned long)priv;
-   priv->thermal_throttle.ct_kill_exit_tm.function =
-   iwl_tt_check_exit_ct_kill;
-   init_timer(&priv->thermal_throttle.ct_kill_waiting_tm);
-   priv->thermal_throttle.ct_kill_waiting_tm.data =
-   (unsigned long)priv;
-   priv->thermal_throttle.ct_kill_waiting_tm.function =
-   iwl_tt_ready_for_ct_kill;
+   setup_timer(&priv->thermal_throttle.ct_kill_exit_tm,
+   iwl_tt_check_exit_ct_kill, (unsigned long)priv);
+   setup_timer(&priv->thermal_throttle.ct_kill_waiting_tm,
+   iwl_tt_ready_for_ct_kill, (unsigned long)priv);
/* setup deferred ct kill work */
INIT_WORK(&priv->tt_work, iwl_bg_tt_work);
INIT_WORK(&priv->ct_enter, iwl_bg_ct_enter);

--
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 24/27] orinoco_usb: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/orinoco/orinoco_usb.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/orinoco/orinoco_usb.c 
b/drivers/net/wireless/orinoco/orinoco_usb.c
index 9958464..61612a6 100644
--- a/drivers/net/wireless/orinoco/orinoco_usb.c
+++ b/drivers/net/wireless/orinoco/orinoco_usb.c
@@ -364,9 +364,7 @@ static struct request_context *ezusb_alloc_ctx(struct 
ezusb_priv *upriv,
atomic_set(&ctx->refcount, 1);
init_completion(&ctx->done);
 
-   init_timer(&ctx->timer);
-   ctx->timer.function = ezusb_request_timerfn;
-   ctx->timer.data = (u_long) ctx;
+   setup_timer(&ctx->timer, ezusb_request_timerfn, (u_long)ctx);
return ctx;
 }
 

--
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 11/27] ksz884x: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/ethernet/micrel/ksz884x.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/micrel/ksz884x.c 
b/drivers/net/ethernet/micrel/ksz884x.c
index f1ebed6..d484f59 100644
--- a/drivers/net/ethernet/micrel/ksz884x.c
+++ b/drivers/net/ethernet/micrel/ksz884x.c
@@ -4348,9 +4348,7 @@ static void ksz_init_timer(struct ksz_timer_info *info, 
int period,
 {
info->max = 0;
info->period = period;
-   init_timer(&info->timer);
-   info->timer.function = function;
-   info->timer.data = (unsigned long) data;
+   setup_timer(&info->timer, function, (unsigned long)data);
 }
 
 static void ksz_update_timer(struct ksz_timer_info *info)

--
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 21/27] usb: oxu210hp-hcd: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/usb/host/oxu210hp-hcd.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
index 036924e..ea0ecbc 100644
--- a/drivers/usb/host/oxu210hp-hcd.c
+++ b/drivers/usb/host/oxu210hp-hcd.c
@@ -2598,9 +2598,7 @@ static int oxu_hcd_init(struct usb_hcd *hcd)
 
spin_lock_init(&oxu->lock);
 
-   init_timer(&oxu->watchdog);
-   oxu->watchdog.function = oxu_watchdog;
-   oxu->watchdog.data = (unsigned long) oxu;
+   setup_timer(&oxu->watchdog, oxu_watchdog, (unsigned long)oxu);
 
/*
 * hw default: 1K periodic list heads, one per frame.

--
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 16/27] ath6kl: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/ath/ath6kl/txrx.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/txrx.c 
b/drivers/net/wireless/ath/ath6kl/txrx.c
index 40432fe..3bc3aa7 100644
--- a/drivers/net/wireless/ath/ath6kl/txrx.c
+++ b/drivers/net/wireless/ath/ath6kl/txrx.c
@@ -1757,9 +1757,7 @@ void aggr_conn_init(struct ath6kl_vif *vif, struct 
aggr_info *aggr_info,
 
aggr_conn->aggr_sz = AGGR_SZ_DEFAULT;
aggr_conn->dev = vif->ndev;
-   init_timer(&aggr_conn->timer);
-   aggr_conn->timer.function = aggr_timeout;
-   aggr_conn->timer.data = (unsigned long) aggr_conn;
+   setup_timer(&aggr_conn->timer, aggr_timeout, (unsigned long)aggr_conn);
aggr_conn->aggr_info = aggr_info;
 
aggr_conn->timer_scheduled = false;

--
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 14/27] leds: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/leds/led-class.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index dbeebac..291ca45 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -239,9 +239,8 @@ int led_classdev_register(struct device *parent, struct 
led_classdev *led_cdev)
 
INIT_WORK(&led_cdev->set_brightness_work, set_brightness_delayed);
 
-   init_timer(&led_cdev->blink_timer);
-   led_cdev->blink_timer.function = led_timer_function;
-   led_cdev->blink_timer.data = (unsigned long)led_cdev;
+   setup_timer(&led_cdev->blink_timer, led_timer_function,
+   (unsigned long)led_cdev);
 
 #ifdef CONFIG_LEDS_TRIGGERS
led_trigger_set_default(led_cdev);

--
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 9/27] xhci: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 

---
 drivers/usb/host/xhci.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 01fcbb5..ae6d650 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -473,10 +473,8 @@ static void compliance_mode_recovery(unsigned long arg)
 static void compliance_mode_recovery_timer_init(struct xhci_hcd *xhci)
 {
xhci->port_status_u0 = 0;
-   init_timer(&xhci->comp_mode_recovery_timer);
-
-   xhci->comp_mode_recovery_timer.data = (unsigned long) xhci;
-   xhci->comp_mode_recovery_timer.function = compliance_mode_recovery;
+   setup_timer(&xhci->comp_mode_recovery_timer,
+   compliance_mode_recovery, (unsigned long)xhci);
xhci->comp_mode_recovery_timer.expires = jiffies +
msecs_to_jiffies(COMP_MODE_RCVRY_MSECS);
 

--
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 18/27] iwl4965: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/iwlegacy/4965-mac.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c 
b/drivers/net/wireless/iwlegacy/4965-mac.c
index 2748fde..976f65f 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -6247,13 +6247,10 @@ il4965_setup_deferred_work(struct il_priv *il)
 
INIT_WORK(&il->txpower_work, il4965_bg_txpower_work);
 
-   init_timer(&il->stats_periodic);
-   il->stats_periodic.data = (unsigned long)il;
-   il->stats_periodic.function = il4965_bg_stats_periodic;
+   setup_timer(&il->stats_periodic, il4965_bg_stats_periodic,
+   (unsigned long)il);
 
-   init_timer(&il->watchdog);
-   il->watchdog.data = (unsigned long)il;
-   il->watchdog.function = il_bg_watchdog;
+   setup_timer(&il->watchdog, il_bg_watchdog, (unsigned long)il);
 
tasklet_init(&il->irq_tasklet,
 (void (*)(unsigned long))il4965_irq_tasklet,

--
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 19/27] [media] pvrusb2: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 

---
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c |   26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c 
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index 2fd9b5e..08f2f5a 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -2425,22 +2425,18 @@ struct pvr2_hdw *pvr2_hdw_create(struct usb_interface 
*intf,
}
if (!hdw) goto fail;
 
-   init_timer(&hdw->quiescent_timer);
-   hdw->quiescent_timer.data = (unsigned long)hdw;
-   hdw->quiescent_timer.function = pvr2_hdw_quiescent_timeout;
+   setup_timer(&hdw->quiescent_timer, pvr2_hdw_quiescent_timeout,
+   (unsigned long)hdw);
 
-   init_timer(&hdw->decoder_stabilization_timer);
-   hdw->decoder_stabilization_timer.data = (unsigned long)hdw;
-   hdw->decoder_stabilization_timer.function =
-   pvr2_hdw_decoder_stabilization_timeout;
+   setup_timer(&hdw->decoder_stabilization_timer,
+   pvr2_hdw_decoder_stabilization_timeout,
+   (unsigned long)hdw);
 
-   init_timer(&hdw->encoder_wait_timer);
-   hdw->encoder_wait_timer.data = (unsigned long)hdw;
-   hdw->encoder_wait_timer.function = pvr2_hdw_encoder_wait_timeout;
+   setup_timer(&hdw->encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
+   (unsigned long)hdw);
 
-   init_timer(&hdw->encoder_run_timer);
-   hdw->encoder_run_timer.data = (unsigned long)hdw;
-   hdw->encoder_run_timer.function = pvr2_hdw_encoder_run_timeout;
+   setup_timer(&hdw->encoder_run_timer, pvr2_hdw_encoder_run_timeout,
+   (unsigned long)hdw);
 
hdw->master_state = PVR2_STATE_DEAD;
 
@@ -3680,10 +3676,8 @@ static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
hdw->ctl_timeout_flag = 0;
hdw->ctl_write_pend_flag = 0;
hdw->ctl_read_pend_flag = 0;
-   init_timer(&timer);
+   setup_timer(&timer, pvr2_ctl_timeout, (unsigned long)hdw);
timer.expires = jiffies + timeout;
-   timer.data = (unsigned long)hdw;
-   timer.function = pvr2_ctl_timeout;
 
if (write_len) {
hdw->cmd_debug_state = 2;

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

[PATCH 8/27] wireless: cw1200: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/wireless/cw1200/pm.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/cw1200/pm.c b/drivers/net/wireless/cw1200/pm.c
index 6907c8f..d2202ae 100644
--- a/drivers/net/wireless/cw1200/pm.c
+++ b/drivers/net/wireless/cw1200/pm.c
@@ -101,9 +101,8 @@ int cw1200_pm_init(struct cw1200_pm_state *pm,
 {
spin_lock_init(&pm->lock);
 
-   init_timer(&pm->stay_awake);
-   pm->stay_awake.data = (unsigned long)pm;
-   pm->stay_awake.function = cw1200_pm_stay_awake_tmo;
+   setup_timer(&pm->stay_awake, cw1200_pm_stay_awake_tmo,
+   (unsigned long)pm);
 
return 0;
 }

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

[PATCH 22/27] usb: sl811-hcd: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/usb/host/sl811-hcd.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/host/sl811-hcd.c b/drivers/usb/host/sl811-hcd.c
index 25fb1da..cef3140 100644
--- a/drivers/usb/host/sl811-hcd.c
+++ b/drivers/usb/host/sl811-hcd.c
@@ -1691,9 +1691,7 @@ sl811h_probe(struct platform_device *dev)
spin_lock_init(&sl811->lock);
INIT_LIST_HEAD(&sl811->async);
sl811->board = dev_get_platdata(&dev->dev);
-   init_timer(&sl811->timer);
-   sl811->timer.function = sl811h_timer;
-   sl811->timer.data = (unsigned long) sl811;
+   setup_timer(&sl811->timer, sl811h_timer, (unsigned long)sl811);
sl811->addr_reg = addr_reg;
sl811->data_reg = data_reg;
 

--
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: 3.19-rc1 errors when opening LID

[Rafael J. Wysocki]

On Wednesday, December 24, 2014 07:51:48 PM Pali Rohár wrote:
> 
> --nextPart5943893.pKyMBm5Emp
> Content-Type: Text/Plain;
>   charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
> 
> Hello!
> 
> With new 3.19-rc1 kernel every time when I open LID on my laptop, kernel pr=
> ints these error lines to dmesg:

Does your syste suspend when the lid is closed and resume when it is open?

> [25566.368133] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaim=
> ed register detected. Please use the i915.mmio_debug=3D1 to debug this prob=
> lem.
> [25566.368134] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed reg=
> ister before interrupt
> [25566.368192] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaim=
> ed register detected. Please use the i915.mmio_debug=3D1 to debug this prob=
> lem.
> [25566.368232] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaim=
> ed register detected. Please use the i915.mmio_debug=3D1 to debug this prob=
> lem.<4>[25568.446011] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]=
> =20
> has bogus alignment

The above messages are from i915 and don't seem to be related to ACPI.

> [25568.447018] pci_bus :02: Allocating resources
> [25568.447055] pci_bus :03: Allocating resources
> [25568.447135] pci_bus :04: Allocating resources
> [25568.447168] pci_bus :05: Allocating resources
> [25568.447195] pci_bus :06: Allocating resources
> [25568.447228] pci_bus :0e: Allocating resources
> [25568.447323] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog=
> us alignment
> [25568.447557] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog=
> us alignment
> [25568.447735] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog=
> us alignment
> [25568.447847] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog=
> us alignment
> [25568.448399] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog=
> us alignment
> [25568.448438] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog=
> us alignment

The above too.

> [25568.448566] acpi MSFT:00: Cannot transition to power state D3cold fo=
> r parent in (unknown)
> [25568.448572] acpi INT33C2:00: Cannot transition to non-D0 state from D3
> [25568.448577] acpi MSFT0002:00: Cannot transition to power state D3cold fo=
> r parent in (unknown)
> [25568.448581] acpi ELAN1010:00: Cannot transition to power state D3cold fo=
> r parent in (unknown)
> [25568.448587] acpi INT33C3:00: Cannot transition to non-D0 state from D3
> [25568.448590] acpi INT33C0:00: Cannot transition to non-D0 state from D3
> [25568.448594] acpi INT33C1:00: Cannot transition to non-D0 state from D3
> [25568.448598] acpi INT33C4:00: Cannot transition to non-D0 state from D3
> [25568.448602] acpi INT33C5:00: Cannot transition to non-D0 state from D3
> [25568.448623] acpi device:41: Cannot transition to power state D3cold for =
> parent in (unknown)
> [25568.448627] acpi INT33C6:00: Cannot transition to non-D0 state from D3

All of the above mean that power transitions were not carried out for some
devices, because they were in unexpected power states to start with.

They are devices on the Intel LPSS as far as I can say (CCing Mika and Andy).

> [25568.448890] pci_bus :01: Allocating resources
> [25568.448905] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog=
> us alignment
> [25568.449064] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog=
> us alignment
> [25568.449472] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog=
> us alignment
> 
> With older kernel (3.13) I do not see these errors, so it is regression.

It only is a regression if it leads to functional problems.  Do you see any?

> Ca=n you look at it? If it is needed, I can provide other logs, ACPI/DSTD 
> dump=
> s, etc.

It looks like 3.13 didn't try to use some devices that are now used in 3.19-rc1
and something doesn't work entirely as expected.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/27] Use setup_timer

[Julia Lawall]

These patches group a call to init_timer and initialization of the function
and data fields into a call to setup_timer.  Is there is no initialization
of the data field before add_timer is called, the the data value is set to
0UL.  If the data value has a cast to something other than unsigned long,
it is changes to a cast to unsigned long, which is the type of the data
field.

The semantic patch that performs this change is shown below
(http://coccinelle.lip6.fr/).  This semantic patch is fairly restrictive on
what appears between the init_timer call and the two field initializations,
to ensure that the there is no code that the initializations depend on.

// 
@@
expression t,d,f,e1,e2;
identifier x1,x2;
statement S1,S2;
@@

(
-t.data = d;
|
-t.function = f;
|
-init_timer(&t);
+setup_timer(&t,f,d);
|
-init_timer_on_stack(&t);
+setup_timer_on_stack(&t,f,d);
)
<... when != S1
t.x1 = e1;
...>
(
-t.data = d;
|
-t.function = f;
|
-init_timer(&t);
+setup_timer(&t,f,d);
|
-init_timer_on_stack(&t);
+setup_timer_on_stack(&t,f,d);
)
<... when != S2
t.x2 = e2;
...>
(
-t.data = d;
|
-t.function = f;
|
-init_timer(&t);
+setup_timer(&t,f,d);
|
-init_timer_on_stack(&t);
+setup_timer_on_stack(&t,f,d);
)

// --

@@
expression t,d,f,e1,e2;
identifier x1,x2;
statement S1,S2;
@@

(
-t->data = d;
|
-t->function = f;
|
-init_timer(t);
+setup_timer(t,f,d);
|
-init_timer_on_stack(t);
+setup_timer_on_stack(t,f,d);
)
<... when != S1
t->x1 = e1;
...>
(
-t->data = d;
|
-t->function = f;
|
-init_timer(t);
+setup_timer(t,f,d);
|
-init_timer_on_stack(t);
+setup_timer_on_stack(t,f,d);
)
<... when != S2
t->x2 = e2;
...>
(
-t->data = d;
|
-t->function = f;
|
-init_timer(t);
+setup_timer(t,f,d);
|
-init_timer_on_stack(t);
+setup_timer_on_stack(t,f,d);
)

// -
// no initialization of data field

@@
expression t,d1,d2,f;
@@

(
-init_timer(&t);
+setup_timer(&t,f,0UL);
|
-init_timer_on_stack(&t);
+setup_timer_on_stack(&t,f,0UL);
)
... when != t.data = d1;
-t.function = f;
... when != t.data = d2;
add_timer(&t);

@@
expression t,d,f,fn;
type T;
@@

-t.function = f;
... when != t.data
when != fn(...,(T)t,...)
(
-init_timer(&t);
+setup_timer(&t,f,d);
|
-init_timer_on_stack(&t);
+setup_timer_on_stack(&t,f,0UL);
)
... when != t.data = d;
add_timer(&t);

// --

@@
expression t,d1,d2,f;
@@

(
-init_timer(t);
+setup_timer(t,f,0UL);
|
-init_timer_on_stack(t);
+setup_timer_on_stack(t,f,0UL);
)
... when != t->data = d1;
-t->function = f;
... when != t->data = d2;
add_timer(t);

@@
expression t,d,f,fn;
type T;
@@

-t->function = f;
... when != t.data
when != fn(...,(T)t,...)
(
-init_timer(t);
+setup_timer(t,f,d);
|
-init_timer_on_stack(t);
+setup_timer_on_stack(t,f,0UL);
)
... when != t->data = d;
add_timer(t);

// -
// change data field type

@@
expression d;
type T;
@@

(
setup_timer
|
setup_timer_on_stack
)
 (...,
(
  (unsigned long)d
|
- (T)
+ (unsigned long)
  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/27] atl1e: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/ethernet/atheros/atl1e/atl1e_main.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c 
b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index 2326579..c88abf5 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -2373,9 +2373,8 @@ static int atl1e_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
netif_napi_add(netdev, &adapter->napi, atl1e_clean, 64);
 
-   init_timer(&adapter->phy_config_timer);
-   adapter->phy_config_timer.function = atl1e_phy_config;
-   adapter->phy_config_timer.data = (unsigned long) adapter;
+   setup_timer(&adapter->phy_config_timer, atl1e_phy_config,
+   (unsigned long)adapter);
 
/* get user settings */
atl1e_check_options(adapter);

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

[PATCH 2/27] [media] au0828: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-t.function = f;
-t.data = d;
-init_timer(&t);
+setup_timer(&t,f,d);
// 

Signed-off-by: Julia Lawall 

---
 drivers/media/usb/au0828/au0828-video.c |   11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c 
b/drivers/media/usb/au0828/au0828-video.c
index 5f337b1..0b24791 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -2043,13 +2043,10 @@ int au0828_analog_register(struct au0828_dev *dev,
INIT_LIST_HEAD(&dev->vbiq.active);
INIT_LIST_HEAD(&dev->vbiq.queued);
 
-   dev->vid_timeout.function = au0828_vid_buffer_timeout;
-   dev->vid_timeout.data = (unsigned long) dev;
-   init_timer(&dev->vid_timeout);
-
-   dev->vbi_timeout.function = au0828_vbi_buffer_timeout;
-   dev->vbi_timeout.data = (unsigned long) dev;
-   init_timer(&dev->vbi_timeout);
+   setup_timer(&dev->vid_timeout, au0828_vid_buffer_timeout,
+   (unsigned long)dev);
+   setup_timer(&dev->vbi_timeout, au0828_vbi_buffer_timeout,
+   (unsigned long)dev);
 
dev->width = NTSC_STD_W;
dev->height = NTSC_STD_H;

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

[PATCH 1/27] [media] s2255drv: Use setup_timer

[Julia Lawall]

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
// 

Signed-off-by: Julia Lawall 

---
 drivers/media/usb/s2255/s2255drv.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/usb/s2255/s2255drv.c 
b/drivers/media/usb/s2255/s2255drv.c
index de55e96..0f3c34d 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -2274,9 +2274,7 @@ static int s2255_probe(struct usb_interface *interface,
dev_err(&interface->dev, "Could not find bulk-in endpoint\n");
goto errorEP;
}
-   init_timer(&dev->timer);
-   dev->timer.function = s2255_timer;
-   dev->timer.data = (unsigned long)dev->fw_data;
+   setup_timer(&dev->timer, s2255_timer, (unsigned long)dev->fw_data);
init_waitqueue_head(&dev->fw_data->wait_fw);
for (i = 0; i < MAX_CHANNELS; i++) {
struct s2255_vc *vc = &dev->vc[i];

--
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/