linux-next: Tree for Jul 8

[Stephen Rothwell]

Hi all,

Changes since 20130705:

The v4l-dvb tree gained a build failure for which I reverted a commit.

The pm tree lost its build failure.

The vhost tree gained a conflict against the target-updates tree.

The arm-soc tree gained a conflict against Linus' tree.

The akpm tree gained a conflict against the drm-intel tree and lost a few
patches that turned up elsewhere.  I also remove a patch that was causing
problems and applied another fix patch.

The cpuinit tree lost some patches that turned up in Linus' tree.



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" as mentioned in the FAQ on the wiki
(see below).

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. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 228 trees (counting Linus' and 31 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

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.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (d2b4a64 Merge branch 'for-linus' of 
git://git.infradead.org/users/vkoul/slave-dma)
Merging fixes/master (8177a9d lseek(fd, n, SEEK_END) does *not* go to eof - n)
Merging kbuild-current/rc-fixes (42a0940 Merge branch 'yem-kconfig-rc-fixes' of 
git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes)
Merging arc-current/for-curr (baadb8f ARC: warn on improper stack unwind FDE 
entries)
Merging arm-current/fixes (3e0a07f ARM: 7773/1: PJ4B: Add support for errata 
4742)
Merging m68k-current/for-linus (767bcb4 Merge branch 'exotic-arch-fixes' into 
for-next)
Merging powerpc-merge/merge (ea461ab powerpc/eeh: Fix fetching bus for 
single-dev-PE)
Merging sparc/master (c069114 mn10300: Fix include dependency in irqflags.h et 
al.)
Merging net/master (8bb495e Linux 3.10)
Merging ipsec/master (01cb71d net_sched: restore "overhead xxx" handling)
Merging sound-current/for-linus (69de3f0 ALSA: hda - Keep halting ALC5505 DSP)
Merging pci-current/for-linus (65694c5 x86/PCI: Map PCI setup data with 
ioremap() so it can be in highmem)
Merging wireless/master (57bf744 Merge branch 'master' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth)
Merging driver-core.current/driver-core-linus (fc76a25 Merge tag 
'driver-core-3.11-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core)
Merging tty.current/tty-linus (9e895ac Linux 3.10-rc7)
Merging usb.current/usb-linus (fc76a25 Merge tag 'driver-core-3.11-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core)
Merging staging.current/staging-linus (fc76a25 Merge tag 'driver-core-3.11-rc1' 
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core)
Merging char-misc.current/char-misc-linus (fc76a25 Merge tag 
'driver-core-3.11-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core)
Merging input-current/for-linus (62f548d Input: cyttsp4 - use 16bit address for 
I2C/SPI communication)
Merging md-current/for-linus (1376512 md/raid10: fix bug which causes all 
RAID10 reshapes to move no data.)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (02c0241 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto)
Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe())
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging 

Re: [PATCH] kernel:time fix race condition in alaramtimer.c

[Srivatsa S. Bhat]

On 07/06/2013 09:37 PM, Marcus Gelderie wrote:
> This patch fixes a race condition whereby the process can be caused to
> sleep indefinitely. The problem occurs when the process is preempted
> after having set its state to TASK_INTERRUPTIBLE but before starting the
> alarm.
> 

I don't think there is any such problem. The __schedule() function does
this check before dequeuing a task:

if (prev->state && !(preempt_count() & PREEMPT_ACTIVE))

The latter part helps prevent the kind of indefinite sleeping you described
above. Also, take a look at preempt_schedule(), preempt_schedule_irq()
and friends to see how in-kernel preemption is dealt with, by using
PREEMPT_ACTIVE. That would clarify why there is no bug here.

Regards,
Srivatsa S. Bhat

> ---
>  kernel/time/alarmtimer.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
> index f11d83b..81c8b31 100644
> --- a/kernel/time/alarmtimer.c
> +++ b/kernel/time/alarmtimer.c
> @@ -585,15 +585,19 @@ static int alarmtimer_do_nsleep(struct alarm *alarm, 
> ktime_t absexp)
>  {
>   alarm->data = (void *)current;
>   do {
> + preempt_disable();
>   set_current_state(TASK_INTERRUPTIBLE);
>   alarm_start(alarm, absexp);
> + preempt_enable_no_resched();
>   if (likely(alarm->data))
>   schedule();
> 
> + preempt_disable();
>   alarm_cancel(alarm);
> + __set_current_state(TASK_RUNNING);
> + preempt_enable_no_resched();
>   } while (alarm->data && !signal_pending(current));
> 
> - __set_current_state(TASK_RUNNING);
> 
>   return (alarm->data == 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/

Re: [PATCH] virtio: include asm/barrier explicitly

[Stephen Rothwell]

Hi Rusty,

On Mon, 08 Jul 2013 11:31:45 +0930 Rusty Russell  wrote:
>
> PS.  I'll squeeze these into this merge window, since they're trivial.

s/'re trivial/fix bugs/  ;-)

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


pgpyfEvEm5Jnm.pgp
Description: PGP signature

Re: [PATCH v6 3/5] vmcore: Introduce remap_oldmem_pfn_range()

[HATAYAMA Daisuke]

(2013/07/02 4:32), Michael Holzheu wrote:

For zfcpdump we can't map the HSA storage because it is only available
via a read interface. Therefore, for the new vmcore mmap feature we have
introduce a new mechanism to create mappings on demand.

This patch introduces a new architecture function remap_oldmem_pfn_range()
that should be used to create mappings with remap_pfn_range() for oldmem
areas that can be directly mapped. For zfcpdump this is everything besides
of the HSA memory. For the areas that are not mapped by remap_oldmem_pfn_range()
a generic vmcore a new generic vmcore fault handler mmap_vmcore_fault()
is called.



This fault handler is only for s390 specific issue. Other architectures don't 
need
this for the time being.

Also, from the same reason, I'm doing this review based on source code only.
I cannot run the fault handler on meaningful system, which is currently s390 
only.

I'm also concerned about the fault handler covers a full range of vmcore, which
could hide some kind of mmap() bug that results in page fault.

So, the fault handler should be enclosed by ifdef CONFIG_S390 for the time 
being.


This handler works as follows:

* Get already available or new page from page cache (find_or_create_page)
* Check if /proc/vmcore page is filled with data (PageUptodate)
* If yes:
   Return that page
* If no:
   Fill page using __vmcore_read(), set PageUptodate, and return page



It seems good to me on this page-in logic.



@@ -225,6 +250,48 @@ static ssize_t read_vmcore(struct file *file, char __user 
*buffer,
return acc;
  }

+static ssize_t read_vmcore(struct file *file, char __user *buffer,
+  size_t buflen, loff_t *fpos)
+{
+   return __read_vmcore(buffer, buflen, fpos, 1);
+}
+
+/*
+ * The vmcore fault handler uses the page cache and fills data using the
+ * standard __vmcore_read() function.
+ */


Could you describe usecase of this fault handler on s390?


+static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
+{
+   struct address_space *mapping = vma->vm_file->f_mapping;
+   pgoff_t index = vmf->pgoff;
+   struct page *page;
+   loff_t src;
+   char *buf;
+   int rc;
+


You should check where faulting address points to valid range.
If the fault happens on invalid range, return VM_FAULT_SIGBUS.

On s390 case, I think the range except for HSA should be thought of as invalid.


+   page = find_or_create_page(mapping, index, GFP_KERNEL);
+   if (!page)
+   return VM_FAULT_OOM;
+   if (!PageUptodate(page)) {
+   src = index << PAGE_CACHE_SHIFT;


src = (loff_t)index << PAGE_CACHE_SHIFT;

loff_t has long long while index has unsigned long.
On s390 both might have the same byte length.

Also I prefer offset to src, but this is minor suggestion.


+   buf = (void *) (page_to_pfn(page) << PAGE_SHIFT);


I found page_to_virt() macro.


+   rc = __read_vmcore(buf, PAGE_SIZE, , 0);
+   if (rc < 0) {
+   unlock_page(page);
+   page_cache_release(page);
+   return (rc == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
+   }
+   SetPageUptodate(page);
+   }
+   unlock_page(page);
+   vmf->page = page;
+   return 0;
+}
+
+static const struct vm_operations_struct vmcore_mmap_ops = {
+   .fault = mmap_vmcore_fault,
+};
+
  static int mmap_vmcore(struct file *file, struct vm_area_struct *vma)
  {
size_t size = vma->vm_end - vma->vm_start;
@@ -242,6 +309,7 @@ static int mmap_vmcore(struct file *file, struct 
vm_area_struct *vma)

vma->vm_flags &= ~(VM_MAYWRITE | VM_MAYEXEC);
vma->vm_flags |= VM_MIXEDMAP;
+   vma->vm_ops = _mmap_ops;

len = 0;



--
Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: fix typo in iov.c

[Jonghwan Choi]

Devic3 should be device.

Signed-off-by: Jonghwan Choi 
---
 drivers/pci/iov.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index de8ffac..de4034e 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -786,7 +786,7 @@ int pci_sriov_set_totalvfs(struct pci_dev *dev, u16
numvfs)
 EXPORT_SYMBOL_GPL(pci_sriov_set_totalvfs);
 
 /**
- * pci_sriov_get_totalvfs -- get total VFs supported on this devic3
+ * pci_sriov_get_totalvfs -- get total VFs supported on this device
  * @dev: the PCI PF device
  *
  * For a PCIe device with SRIOV support, return the PCIe
-- 
1.7.9.5

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

linux-next: build failure after merge of the final tree (v4l-dvb tree related)

[Stephen Rothwell]

Hi all,

After merging the final tree, today's linux-next build
(powerpc_ppc44x_defconfig) failed like this:

arch/powerpc/boot/wrapper: line 314: .../scripts/mkuboot.sh: Permission denied

Caused by commit cda2bf15f6dc ("Update email to m.che...@samsung.com")
from the v4l-dvb tree.

I have reverted that commit for today.

Linus, please don't merge the v4l-dvb tree like it is.

Mauro, in the case of copyright notices, you should just remove your
email address, not bother changing it.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp1hsJtctxpr.pgp
Description: PGP signature

Re: [PATCH v3] lib/idr.c rewrite, percpu ida/tag allocator

[Michael S. Tsirkin]

On Sun, Jul 07, 2013 at 07:09:35PM -0700, Nicholas A. Bellinger wrote:
> On Sun, 2013-07-07 at 14:48 +0300, Michael S. Tsirkin wrote:
> > On Sat, Jul 06, 2013 at 03:59:06PM -0700, Nicholas A. Bellinger wrote:
> > > On Fri, 2013-07-05 at 22:08 -0700, Kent Overstreet wrote:
> > > > Previous posting: http://thread.gmane.org/gmane.linux.kernel/1511216
> > > > 
> > > > The only real change since the last version is that I've reworked the
> > > > new ida implementation to not use one giant allocation - it's still
> > > > logically one big arary, but it's implemented as an array of arrays.
> > > > 
> > > > With that, it scales up to INT_MAX allocated ids just fine. Benchmarks
> > > > are included in that patch.
> > > > 
> > > > Patch series is available in my git repo:
> > > > git://evilpiepirate.org/~kent/linux-bcache.git idr
> > > > 
> > > > Andrew, want to pick this up for 3.12?
> > > 
> > > Just FYI that the target-pending/target-per-cpu-ida branch utilizing
> > > per-cpu ida logic for vhost-scsi has been rebased to include this latest
> > > series.  Thanks Kent!
> > > 
> > > Andrew, what are your plans for this..?
> > > 
> > > Would you consider allowing this series be merged through target-pending
> > > in order to allow us to start taking advantage of per-cpu ida tag
> > > pre-allocation optimizations for v3.12 target code..? 
> > > 
> > > Another option would be to merge the per-cpu ida specific piece now for
> > > v3.11 for which the risk is low given it doesn't touch any existing
> > > code, and then include Kent's full idr rewrite separately as v3.12 item.
> > > 
> > > WDYT..?
> > 
> > Takes as is, this conflicts with cleanup patches by Asias in vhost-next
> > that I was going to send to Linus for 3.11.
> 
> So the proposed vhost-scsi per-cpu ida/tag pre-allocation changes should
> be considered v3.12 items.
> 
> > Merging new target code for 3.11 and vhost code for 3.12
> > helps keep the dependencies simple, so I'm all for it.
> > 
> 
> My point above is that having (at least) Kent's per-cpu ida code merged
> for v3.11 would make it easier to move forward during the v3.12 cycle on
> per-cpu ida/tag conversions for vhost-scsi + other target fabric
> drivers.
> 
> --nab

Exactly. I think it's a good idea, too.

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

Re: [PATCH] arm: dts: AM43x: Add usb_otg_hs node

[George Cherian]

On 7/7/2013 2:05 PM, Felipe Balbi wrote:

Hi,

On Fri, Jun 28, 2013 at 12:14:47PM +0530, George Cherian wrote:

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..e4f5eb8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,24 @@
compatible = 
"ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+   usb_otg_hs1: am4372_dwc3@4838 {
+   compatible = "ti,am437x-dwc3";
+   reg = <0x4838 0x1ff>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   utmi-mode = <1>;
+   ranges;
+
+   dwc3@4839 {
+   compatible = "synopsys,dwc3";

let's us snps,dwc3. I recently posted a patch converting synopsys to
snps like all other DesignWare drivers. Support for synopsys,dwc3 is
still there, but shouldn't be used.

okay



+   reg = <0x4839 0xcfff>;
+   interrupts = ;
+   tx-fifo-resize;

is this flag *really* necessary, I asked you and didn't get an answer.
We will not be needing this flag , since each EP has 3K tx fifo size. 
Also given the fact that we will be operating only

in 2.0 mode the default values are only sufficient.
I will re-send the patch with above changes.

Regards,
-George

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pci: exynos: split into two parts such as Synopsys part and Exynos part

[Jingoo Han]

On Monday, July 08, 2013 2:06 PM, Jingoo Han wrote:
> On Friday, July 05, 2013 7:44 PM, Pratyush Anand wrote:
> > On 7/5/2013 1:59 PM, Jingoo Han wrote:
> > > Exynos PCIe IP consists of Synopsys specific part and Exynos
> > > specific part. Only core block is a Synopsys designware part;
> > > other parts are Exynos specific.
> > > Also, the Synopsys designware part can be shared with other
> > > platforms; thus, it can be split two parts such as Synopsys
> > > designware part and Exynos specific part.
> > >
> >
> > A quick and nice job :)
> > Just few minor comments.
> 
> Thank you.
> Without your comment, it could be done. :)

Oops, it is a typo.
Without your comment, it could 'NOT' be done. :)

Thank you for your comment.
It is very helpful.

Best regards,
Jingoo Han


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

Re: [RFC PATCH 7/7] autofs - change CONFIG_AUTOFS4_FS to CONFIG_AUTOFS_FS

[Stephen Rothwell]

Hi Ian,

On Fri, 05 Jul 2013 17:51:24 +0800 Ian Kent  wrote:
>
> On Mon, 2013-07-01 at 14:39 +1000, Stephen Rothwell wrote:
> > 
> > On Mon, 01 Jul 2013 11:14:51 +0800 Ian Kent  wrote:
> > >
> > > Signed-off-by: Ian Kent 
> > 
> > Please don't do this.  Find a simple way to make sure that if
> > CONFIG_AUTOFS4_FS is set, then "make oldconfig"  (or equivalent) will
> > cause CONFIG_AUTOFS_FS to be set the same.
> 
> I get what your recommending but still can't think of a way to do it,
> any thoughts?

Isn't just having

config AUTOFS4_FS
tristate
select AUTOFS_FS

enough?

> Am I correct that's a +1 for an outright rename of autofs4 to autofs
> rather than keeping the autofs4 directory and a compile stub?

I have no opinion :-)

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


pgpytjymiyz3h.pgp
Description: PGP signature

[PATCH] c6x: remove unused parameter in Kconfig

[Michael Opdenacker]

This patch proposes to remove the TMS320C6X_CACHES_ON kernel configuration
parameter defined in arch/c6x/Kconfig, but used nowhere
in the makefiles and source code.

Signed-off-by: Michael Opdenacker 
---
 arch/c6x/Kconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index f6a3648..7d10256 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -106,10 +106,6 @@ menu "Processor type and features"
 
 source "arch/c6x/platforms/Kconfig"
 
-config TMS320C6X_CACHES_ON
-   bool "L2 cache support"
-   default y
-
 config KERNEL_RAM_BASE_ADDRESS
hex "Virtual address of memory base"
default 0xe000 if SOC_TMS320C6455
-- 
1.8.1.2

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

Re: [PATCH] pci: exynos: split into two parts such as Synopsys part and Exynos part

[Jingoo Han]

On Friday, July 05, 2013 7:44 PM, Pratyush Anand wrote:
> On 7/5/2013 1:59 PM, Jingoo Han wrote:
> > Exynos PCIe IP consists of Synopsys specific part and Exynos
> > specific part. Only core block is a Synopsys designware part;
> > other parts are Exynos specific.
> > Also, the Synopsys designware part can be shared with other
> > platforms; thus, it can be split two parts such as Synopsys
> > designware part and Exynos specific part.
> >
> 
> A quick and nice job :)
> Just few minor comments.

Thank you.
Without your comment, it could be done. :)

> 
> > Signed-off-by: Jingoo Han 
> > Cc: Pratyush Anand 
> > Cc: Mohit KUMAR 
> > ---
> >   drivers/pci/host/Makefile  |1 +
> >   drivers/pci/host/pcie-designware.c |  907 
> > +++-
> >   drivers/pci/host/pcie-designware.h |   72 +++
> >   drivers/pci/host/pcie-exynos.c |  619 
> >   4 files changed, 862 insertions(+), 737 deletions(-)
> >   create mode 100644 drivers/pci/host/pcie-designware.h
> >   create mode 100644 drivers/pci/host/pcie-exynos.c
> >
> 
> [...]
> 
> 
> > -
> > -struct pcie_port {
> > -   struct device   *dev;
> > -   u8  controller;
> > -   u8  root_bus_nr;
> > -   void __iomem*dbi_base;
> > -   void __iomem*elbi_base;
> > -   void __iomem*phy_base;
> > -   void __iomem*purple_base;
> 
> Just for knowledge, what is the purple_base. It might not be needed by
> all vendors. Can we explain the name in comment or can give some generic
> name?

purple_base is a register to control PCIe block.

For example, controlling various reset control signals, 
PLL lock indication, etc.

Generic name would be 'block_base' or 'misc_base'?


> 
> > -   u64 cfg0_base;
> > -   void __iomem*va_cfg0_base;
> > -   u64 cfg1_base;
> > -   void __iomem*va_cfg1_base;
> > -   u64 io_base;
> > -   u64 mem_base;
> > -   spinlock_t  conf_lock;
> > -   struct resource cfg;
> > -   struct resource io;
> > -   struct resource mem;
> > -   struct pcie_port_info   config;
> > -   struct clk  *clk;
> > -   struct clk  *bus_clk;
> > -   int irq;
> > -   int reset_gpio;
> > -};
> > -
> 
> [...]
> 
> > -
> > -static inline void readl_rc(struct pcie_port *pp, void *dbi_base, u32 *val)
> > +static inline void dw_pcie_readl_rc(struct pcie_port *pp, void *dbi_base,
> > +   u32 *val)
> 
> dbi_base is part of pp. So why to pass 3 args?

OK, I see.
I will use 2 args.

Best regards,
Jingoo Han



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/video: remove unused parameter in Kconfig

[Michael Opdenacker]

This patch proposes to remove the FB_NUC900_DEBUG kernel configuration
parameter defined in drivers/video/Kconfig, but used nowhere
in the makefiles and source code.

Signed-off-by: Michael Opdenacker 
---
 drivers/video/Kconfig | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2e937bd..a9c0964 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2098,13 +2098,6 @@ config GPM1040A0_320X240
 bool "Giantplus Technology GPM1040A0 320x240 Color TFT LCD"
 depends on FB_NUC900
 
-config FB_NUC900_DEBUG
-bool "NUC900 lcd debug messages"
-depends on FB_NUC900
-help
-  Turn on debugging messages. Note that you can set/unset at run time
-  through sysfs
-
 config FB_SM501
tristate "Silicon Motion SM501 framebuffer support"
depends on FB && MFD_SM501
-- 
1.8.1.2

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

Re: [v9fs:for-linus 7/7] ERROR: code indent should use tabs where possible

[Fengguang Wu]

On Mon, Jul 08, 2013 at 12:47:47PM +0800, Fengguang Wu wrote:
> > > > TRAILING_STATEMENTS
> > > 
> > > False positives?  Got an example?
> > 
> > tree:   git://git.freedesktop.org/git/nouveau/linux-2.6 drm-nouveau-next
> > head:   d2989b534ef6834ebf2425aecc040b894b567c91
> > commit: 01672ef454307bf63e93defb3599399b678ff58b [3/68] drm/nve0/fifo: copy 
> > engine context stored in ramfc, not externally
> > 
> > ERROR: trailing statements should be on next line
> > #28: FILE: drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:146:
> > +   case NVDEV_ENGINE_GR   : addr = 0x0210; break;
> > 
> > ERROR: trailing statements should be on next line
> > #40: FILE: drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:183:
> > +   case NVDEV_ENGINE_COPY2: addr = 0x; break;
> > 
> > ERROR: trailing statements should be on next line
> > #41: FILE: drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:184:
> > +   case NVDEV_ENGINE_GR   : addr = 0x0210; break;
> 
> In this case the code does look neat:
> 
> switch (nv_engidx(object->engine)) {
> case NVDEV_ENGINE_SW   : return 0;
> -   case NVDEV_ENGINE_GR   :
> case NVDEV_ENGINE_COPY0:
> -   case NVDEV_ENGINE_COPY1: addr = 0x0210; break;
> +   case NVDEV_ENGINE_COPY1:
> +   case NVDEV_ENGINE_COPY2: addr = 0x; break;
> +   case NVDEV_ENGINE_GR   : addr = 0x0210; break;
> case NVDEV_ENGINE_BSP  : addr = 0x0270; break;
> case NVDEV_ENGINE_VP   : addr = 0x0250; break;
> case NVDEV_ENGINE_PPP  : addr = 0x0260; break;

It's actually a common case.

git grep ';.*;$' -- '*.c' | grep -o '\S*$' | sort | uniq -c | sort -nr 
| head

==>4156 break;
465 return;);
273 -1;);
158 0;
146 mdelay(1);
143 eieio();
140 msleep(1);
135 4;
 94 ;
 93 8;

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v9fs:for-linus 7/7] ERROR: code indent should use tabs where possible

[Joe Perches]

On Mon, 2013-07-08 at 12:45 +0800, Fengguang Wu wrote:
> On Sun, Jul 07, 2013 at 08:54:04PM -0700, Joe Perches wrote:
> > On Mon, 2013-07-08 at 11:30 +0800, Fengguang Wu wrote:
> > > In long run I'd like to disable
> > > the check types that tend to have false positives.  As for now, these
> > > checks are disabled in my checkpatch robot:
> > 
> > Are you using a .checkpatch.conf file?
> 
> Nope.
> 
> > > PATCH_PREFIX
> > > LONG_LINE
> > > CAMELCASE
> > 
> > That's a --strict test
> 
> Yes. The CAMELCASE checks are false positives for the USB subsystem.
> Where they followed the USB spec and use names like bInterfaceClass
> all over the places.

The latest version of checkpatch should avoid this.

> > > MISSING_SIGN_OFF
> > 
> > Why would you even consider this one?
> 
> It produces
> 
> ERROR: Missing Signed-off-by: line(s)
> 
> on
> commit: 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376 Linux 3.10

Well, clearly Linus should sign off on his own commits...

> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
> master
> commit: 97966e7ec944580bc3f46712f34ecb3c854fdd4b [37/81] Revert 
> "ALSA: hda - Fix wrong power setup for HP paths of VIA codecs"
> 
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
> master
> head:   120b1922175789a8a9bdafb7ea755fc63de2f392
> commit: 10296279acc5d3caeca7b2cfde329c8280fe67e5 [32/81] Merge branch 
> 'for-linus'
> 
> and many other commits

Not in -next as of today.

> > > TRAILING_STATEMENTS
> > False positives?  Got an example?
> tree:   git://git.freedesktop.org/git/nouveau/linux-2.6 drm-nouveau-next
> head:   d2989b534ef6834ebf2425aecc040b894b567c91
> commit: 01672ef454307bf63e93defb3599399b678ff58b [3/68] drm/nve0/fifo: copy 
> engine context stored in ramfc, not externally
> 
> ERROR: trailing statements should be on next line
> #28: FILE: drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:146:
> +   case NVDEV_ENGINE_GR   : addr = 0x0210; break;

Not false positives.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] blackfin: remove unused parameters in Kconfig

[Michael Opdenacker]

This patch proposes to remove kernel configuration parameters
defined in arch/blackfin/Kconfig, but used nowhere
in the makefiles and source code.

Signed-off-by: Michael Opdenacker 
---
 arch/blackfin/Kconfig | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index 08c7ac6..22478a6 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -861,14 +861,6 @@ config SYS_BFIN_SPINLOCK_L1
  If enabled, sys_bfin_spinlock function is linked
  into L1 instruction memory. (less latency)
 
-config IP_CHECKSUM_L1
-   bool "Locate IP Checksum function in L1 Memory"
-   default n
-   depends on !SMP
-   help
- If enabled, the IP Checksum function is linked
- into L1 instruction memory. (less latency)
-
 config CACHELINE_ALIGNED_L1
bool "Locate cacheline_aligned data to L1 Data Memory"
default y if !BF54x
@@ -1330,13 +1322,6 @@ config PM_BFIN_WAKE_PB15
help
  Enable PB15 Wake-Up
 
-config PM_BFIN_WAKE_PB15_POL
-   int "Wake-up priority"
-   depends on PM_BFIN_WAKE_PB15
-   default 0
-   help
- Wake-Up priority 0(low) 1(high)
-
 config PM_BFIN_WAKE_PC15
bool "Allow Wake-Up from PC15"
depends on PM && BF60x
-- 
1.8.1.2

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

Re: [v9fs:for-linus 7/7] ERROR: code indent should use tabs where possible

[Fengguang Wu]

> > > TRAILING_STATEMENTS
> > 
> > False positives?  Got an example?
> 
> tree:   git://git.freedesktop.org/git/nouveau/linux-2.6 drm-nouveau-next
> head:   d2989b534ef6834ebf2425aecc040b894b567c91
> commit: 01672ef454307bf63e93defb3599399b678ff58b [3/68] drm/nve0/fifo: copy 
> engine context stored in ramfc, not externally
> 
> ERROR: trailing statements should be on next line
> #28: FILE: drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:146:
> +   case NVDEV_ENGINE_GR   : addr = 0x0210; break;
> 
> ERROR: trailing statements should be on next line
> #40: FILE: drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:183:
> +   case NVDEV_ENGINE_COPY2: addr = 0x; break;
> 
> ERROR: trailing statements should be on next line
> #41: FILE: drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:184:
> +   case NVDEV_ENGINE_GR   : addr = 0x0210; break;

In this case the code does look neat:

switch (nv_engidx(object->engine)) {
case NVDEV_ENGINE_SW   : return 0;
-   case NVDEV_ENGINE_GR   :
case NVDEV_ENGINE_COPY0:
-   case NVDEV_ENGINE_COPY1: addr = 0x0210; break;
+   case NVDEV_ENGINE_COPY1:
+   case NVDEV_ENGINE_COPY2: addr = 0x; break;
+   case NVDEV_ENGINE_GR   : addr = 0x0210; break;
case NVDEV_ENGINE_BSP  : addr = 0x0270; break;
case NVDEV_ENGINE_VP   : addr = 0x0250; break;
case NVDEV_ENGINE_PPP  : addr = 0x0260; break;

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v9fs:for-linus 7/7] ERROR: code indent should use tabs where possible

[Fengguang Wu]

On Sun, Jul 07, 2013 at 08:54:04PM -0700, Joe Perches wrote:
> On Mon, 2013-07-08 at 11:30 +0800, Fengguang Wu wrote:
> > In long run I'd like to disable
> > the check types that tend to have false positives.  As for now, these
> > checks are disabled in my checkpatch robot:
> 
> Are you using a .checkpatch.conf file?

Nope.

> > PATCH_PREFIX
> > LONG_LINE
> > CAMELCASE
> 
> That's a --strict test

Yes. The CAMELCASE checks are false positives for the USB subsystem.
Where they followed the USB spec and use names like bInterfaceClass
all over the places.

> > MISSING_SIGN_OFF
> 
> Why would you even consider this one?

It produces

ERROR: Missing Signed-off-by: line(s)

on
commit: 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376 Linux 3.10

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
master
commit: 97966e7ec944580bc3f46712f34ecb3c854fdd4b [37/81] Revert "ALSA: 
hda - Fix wrong power setup for HP paths of VIA codecs"

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
master
head:   120b1922175789a8a9bdafb7ea755fc63de2f392
commit: 10296279acc5d3caeca7b2cfde329c8280fe67e5 [32/81] Merge branch 
'for-linus'

and many other commits

> > COMPLEX_MACRO
> > BRACES
> > SPACING
> > LONG_LINE
> 
> OK by me.
> 
> > REDUNDANT_CODE
> 
> Also a --strict test
> 
> > TRAILING_STATEMENTS
> 
> False positives?  Got an example?

tree:   git://git.freedesktop.org/git/nouveau/linux-2.6 drm-nouveau-next
head:   d2989b534ef6834ebf2425aecc040b894b567c91
commit: 01672ef454307bf63e93defb3599399b678ff58b [3/68] drm/nve0/fifo: copy 
engine context stored in ramfc, not externally

ERROR: trailing statements should be on next line
#28: FILE: drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:146:
+   case NVDEV_ENGINE_GR   : addr = 0x0210; break;

ERROR: trailing statements should be on next line
#40: FILE: drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:183:
+   case NVDEV_ENGINE_COPY2: addr = 0x; break;

ERROR: trailing statements should be on next line
#41: FILE: drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:184:
+   case NVDEV_ENGINE_GR   : addr = 0x0210; break;
 
> > UNCOMMENTED_DEFINITION

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] powerpc: add real mode support for dma operations on powernv

[Alexey Kardashevskiy]

The existing TCE machine calls (tce_build and tce_free) only support
virtual mode as they call __raw_writeq for TCE invalidation what
fails in real mode.

This introduces tce_build_rm and tce_free_rm real mode versions
which do mostly the same but use "Store Doubleword Caching Inhibited
Indexed" instruction for TCE invalidation.

This new feature is going to be utilized by real mode support of VFIO.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
2013/08/07:
* tested on p7ioc and fixed a bug with realmode addresses

Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/include/asm/machdep.h| 12 +
 arch/powerpc/platforms/powernv/pci-ioda.c | 43 ++-
 arch/powerpc/platforms/powernv/pci.c  | 38 ++-
 arch/powerpc/platforms/powernv/pci.h  |  3 ++-
 4 files changed, 77 insertions(+), 19 deletions(-)

diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 92386fc..0c19eef 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -75,6 +75,18 @@ struct machdep_calls {
long index);
void(*tce_flush)(struct iommu_table *tbl);
 
+   /* _rm versions are for real mode use only */
+   int (*tce_build_rm)(struct iommu_table *tbl,
+long index,
+long npages,
+unsigned long uaddr,
+enum dma_data_direction direction,
+struct dma_attrs *attrs);
+   void(*tce_free_rm)(struct iommu_table *tbl,
+   long index,
+   long npages);
+   void(*tce_flush_rm)(struct iommu_table *tbl);
+
void __iomem *  (*ioremap)(phys_addr_t addr, unsigned long size,
   unsigned long flags, void *caller);
void(*iounmap)(volatile void __iomem *token);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index d200594..8a70003 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -68,6 +68,12 @@ define_pe_printk_level(pe_err, KERN_ERR);
 define_pe_printk_level(pe_warn, KERN_WARNING);
 define_pe_printk_level(pe_info, KERN_INFO);
 
+static inline void __raw_rm_writeq(u64 val, volatile void __iomem *paddr)
+{
+   __asm__ __volatile__("stdcix %0,0,%1"
+   : : "r" (val), "r" (paddr) : "memory");
+}
+
 static int pnv_ioda_alloc_pe(struct pnv_phb *phb)
 {
unsigned long pe;
@@ -452,10 +458,13 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe 
*pe, struct pci_bus *bus)
}
 }
 
-static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
-u64 *startp, u64 *endp)
+static void pnv_pci_ioda1_tce_invalidate(struct pnv_ioda_pe *pe,
+struct iommu_table *tbl,
+u64 *startp, u64 *endp, bool rm)
 {
-   u64 __iomem *invalidate = (u64 __iomem *)tbl->it_index;
+   u64 __iomem *invalidate = rm?
+   (u64 __iomem *)pe->it_index_rm:
+   (u64 __iomem *)tbl->it_index;
unsigned long start, end, inc;
 
start = __pa(startp);
@@ -482,7 +491,10 @@ static void pnv_pci_ioda1_tce_invalidate(struct 
iommu_table *tbl,
 
 mb(); /* Ensure above stores are visible */
 while (start <= end) {
-__raw_writeq(start, invalidate);
+   if (rm)
+   __raw_rm_writeq(start, invalidate);
+   else
+   __raw_writeq(start, invalidate);
 start += inc;
 }
 
@@ -494,10 +506,12 @@ static void pnv_pci_ioda1_tce_invalidate(struct 
iommu_table *tbl,
 
 static void pnv_pci_ioda2_tce_invalidate(struct pnv_ioda_pe *pe,
 struct iommu_table *tbl,
-u64 *startp, u64 *endp)
+u64 *startp, u64 *endp, bool rm)
 {
unsigned long start, end, inc;
-   u64 __iomem *invalidate = (u64 __iomem *)tbl->it_index;
+   u64 __iomem *invalidate = rm?
+   (u64 __iomem *)pe->it_index_rm:
+   (u64 __iomem *)tbl->it_index;
 
/* We'll invalidate DMA address in PE scope */
start = 0x2ul << 60;
@@ -513,22 +527,25 @@ static void pnv_pci_ioda2_tce_invalidate(struct 
pnv_ioda_pe *pe,
mb();
 
while (start <= end) {
-   __raw_writeq(start, invalidate);
+   if (rm)
+   __raw_rm_writeq(start, invalidate);
+   else
+   __raw_writeq(start, invalidate);
start += inc;
}
 }
 
 void 

Re: linux-next: Tree for Jul 3

[Stephen Rothwell]

Hi Jörn,

On Wed, 3 Jul 2013 10:48:03 -0400 Jörn Engel  wrote:
>
> On Wed, 3 July 2013 12:25:41 +0100, Steve Capper wrote:
> > 
> > Today's linux-next appears to introduce some BUGs when running the 
> > libhugetlbfs
> > testsuite (under both ARM64 and x86_64):
> > 
> > [   94.320661] BUG: Bad rss-counter state mm:880119461040 idx:1 val:-512
> > [   94.330346] BUG: Bad rss-counter state mm:880119460680 idx:1 
> > val:-2560
> > [   94.341746] BUG: Bad rss-counter state mm:880119460d00 idx:1 val:-512
> > [   94.347518] BUG: Bad rss-counter state mm:880119460d00 idx:1 val:-512
> > [   94.415203] BUG: Bad rss-counter state mm:8801194f9040 idx:1 
> > val:-1024
> > 
> > I've bisected this to commit:
> > commit 446313e3e4e7274c4d1e449d107fab6c041ec59c
> > hugetlb: properly account rss
> > 
> > The bad counter values I get are all negative.
> > 
> > To reproduce this, just run through the latest libhugetlbfs test suite, 
> > these
> > warnings appear pretty much immediately. (I set aside 200 huge pages first):
> > http://libhugetlbfs.sourceforge.net/
> > 
> > Reverting this commit allows the test suite to run without problems.
> 
> Thank you, I will have a look.  For the interim, dropping this patch
> from -mm seems the best approach.

OK, I have dropped that from the akpm tree in linux-next today.

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


pgpR489IzqW7X.pgp
Description: PGP signature

[PATCH] mtd: diskonchip: remove unused entries in Kconfig

[Michael Opdenacker]

This patch proposes to remove kernel configuration parameters
defined in drivers/mtd/devices/Kconfig, but used nowhere
in the makefiles and source code (except in comments).

Signed-off-by: Michael Opdenacker 
---
 drivers/mtd/devices/Kconfig   | 55 ---
 drivers/mtd/nand/diskonchip.c |  4 ++--
 2 files changed, 2 insertions(+), 57 deletions(-)

diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 2a4d55e..74ab4b7 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -224,59 +224,4 @@ config BCH_CONST_T
default 4
 endif
 
-config MTD_DOCPROBE
-   tristate
-   select MTD_DOCECC
-
-config MTD_DOCECC
-   tristate
-
-config MTD_DOCPROBE_ADVANCED
-   bool "Advanced detection options for DiskOnChip"
-   depends on MTD_DOCPROBE
-   help
- This option allows you to specify nonstandard address at which to
- probe for a DiskOnChip, or to change the detection options.  You
- are unlikely to need any of this unless you are using LinuxBIOS.
- Say 'N'.
-
-config MTD_DOCPROBE_ADDRESS
-   hex "Physical address of DiskOnChip" if MTD_DOCPROBE_ADVANCED
-   depends on MTD_DOCPROBE
-   default "0x0"
-   ---help---
- By default, the probe for DiskOnChip devices will look for a
- DiskOnChip at every multiple of 0x2000 between 0xC8000 and 0xEE000.
- This option allows you to specify a single address at which to probe
- for the device, which is useful if you have other devices in that
- range which get upset when they are probed.
-
- (Note that on PowerPC, the normal probe will only check at
- 0xE400.)
-
- Normally, you should leave this set to zero, to allow the probe at
- the normal addresses.
-
-config MTD_DOCPROBE_HIGH
-   bool "Probe high addresses"
-   depends on MTD_DOCPROBE_ADVANCED
-   help
- By default, the probe for DiskOnChip devices will look for a
- DiskOnChip at every multiple of 0x2000 between 0xC8000 and 0xEE000.
- This option changes to make it probe between 0xFFFC8000 and
- 0xFFFEE000.  Unless you are using LinuxBIOS, this is unlikely to be
- useful to you.  Say 'N'.
-
-config MTD_DOCPROBE_55AA
-   bool "Probe for 0x55 0xAA BIOS Extension Signature"
-   depends on MTD_DOCPROBE_ADVANCED
-   help
- Check for the 0x55 0xAA signature of a DiskOnChip, and do not
- continue with probing if it is absent.  The signature will always be
- present for a DiskOnChip 2000 or a normal DiskOnChip Millennium.
- Only if you have overwritten the first block of a DiskOnChip
- Millennium will it be absent.  Enable this option if you are using
- LinuxBIOS or if you need to recover a DiskOnChip Millennium on which
- you have managed to wipe the first block.
-
 endmenu
diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index 81fa578..eaa3c29 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -46,13 +46,13 @@ static unsigned long __initdata doc_locations[] = {
0xfffd8000, 0xfffda000, 0xfffdc000, 0xfffde000,
0xfffe, 0xfffe2000, 0xfffe4000, 0xfffe6000,
0xfffe8000, 0xfffea000, 0xfffec000, 0xfffee000,
-#else /*  CONFIG_MTD_DOCPROBE_HIGH */
+#else
0xc8000, 0xca000, 0xcc000, 0xce000,
0xd, 0xd2000, 0xd4000, 0xd6000,
0xd8000, 0xda000, 0xdc000, 0xde000,
0xe, 0xe2000, 0xe4000, 0xe6000,
0xe8000, 0xea000, 0xec000, 0xee000,
-#endif /*  CONFIG_MTD_DOCPROBE_HIGH */
+#endif
 #endif
0x };
 
-- 
1.8.1.2

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

Re: [PATCH 0/2] introduce list_for_each_entry_del

[Dave Chinner]

On Fri, Jul 05, 2013 at 04:41:00PM -0400, Jörn Engel wrote:
> On Mon, 3 June 2013 13:28:03 -0400, Joern Engel wrote:
> > 
> > A purely janitorial patchset.  A fairly common pattern is to take a
> > list, remove every object from it and do something with this object -
> > usually kfree() some variant.  A stupid grep identified roughly 300
> > instances, with many more hidden behind more complicated patterns to
> > achieve the same end results.
> 
> Next version of the same patchset.  Object size is shrinking now, at
> least for the one compiler I tested.  And a few kernel hackers met on
> a frozen lake in hell with pigs flying overhead and could actually
> agree on a name.  While I am sure almost every reader will still
> disagree and have one or two better suggestions, I would like to use
> this historical moment.
> 
> list_del_each and list_del_each_entry is shall be!

Can you add _init variants to this? There are many loops that
actually require list_del_init() rather than list_del()...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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/

Re: [PATCH] pci: Avoid unnecessary calls to work_on_cpu

[Andi Kleen]

> > But Rusty added this (in 873392ca51), and he knows way more about this
> > stuff than I do.
> 
> Actually, I just stopped the code from playing cpumask games, which is
> what it used to do.

You're right the numa_node_id() check ptimization is not 100% safe on preempt 
kernels and should be probably removed. Also I agree it would probably
make sense to move it up to the generic device layer (although I'm not
sure that other bus types really care that much about NUMA locality)

None of it seems to be a fatal problem though, so it boils down to
"if someone cares enough to write a patch"

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: pxa: propagate errors from regulator_enable() to pxamci

[Sachin Kamat]

On 5 July 2013 21:21, Arnd Bergmann  wrote:
> The em_x270_mci_setpower() and em_x270_usb_hub_init() functions
> call regulator_enable(), which may return an error that must
> be checked.
>
> This changes the em_x270_usb_hub_init() function to bail out
> if it fails, and changes the pxamci_platform_data->setpower
> callback so that the a failed em_x270_mci_setpower call
> can be propagated by the pxamci driver into the mmc core.
>
> Signed-off-by: Arnd Bergmann 
> Cc: Mike Rapoport 
> Cc: Paul Gortmaker 
> Cc: Mark Brown 
> Cc: Haojian Zhuang 
> Cc: Chris Ball 
>
> diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
> index f6726bb..f8062e4 100644
> --- a/arch/arm/mach-pxa/em-x270.c
> +++ b/arch/arm/mach-pxa/em-x270.c
> @@ -477,16 +477,24 @@ static int em_x270_usb_hub_init(void)
> /* USB Hub power-on and reset */
> gpio_direction_output(usb_hub_reset, 1);
> gpio_direction_output(GPIO9_USB_VBUS_EN, 0);
> -   regulator_enable(em_x270_usb_ldo);
> +   err = regulator_enable(em_x270_usb_ldo);
> +   if (err)
> +   goto err_free_rst_gpio;
> +
> gpio_set_value(usb_hub_reset, 0);
> gpio_set_value(usb_hub_reset, 1);
> regulator_disable(em_x270_usb_ldo);
> -   regulator_enable(em_x270_usb_ldo);
> +   if (err)
> +   goto err_free_rst_gpio;

Shouldn't this check be after the below (regulator_enable) statement?

> +
> +   err = regulator_enable(em_x270_usb_ldo);
> gpio_set_value(usb_hub_reset, 0);
> gpio_set_value(GPIO9_USB_VBUS_EN, 1);
>
> return 0;
>
> +err_free_rst_gpio:
> +   gpio_free(usb_hub_reset);
>  err_free_vbus_gpio:
> gpio_free(GPIO9_USB_VBUS_EN);
>  err_free_usb_ldo:
> @@ -592,7 +600,7 @@ err_irq:
> return err;
>  }

-- 
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: manual merge of the akpm tree with the drm-intel tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commit 857d0a9a6e9e ("drm/i915:
Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list") from
the drm-intel tree and commit
"drivers-convert-shrinkers-to-new-count-scan-api-fix" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/gpu/drm/i915/i915_gem.c
index 8e57029,e743c27..000
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@@ -4605,13 -4605,13 +4605,13 @@@ i915_gem_inactive_count(struct shrinke
unlock = false;
}
  
-   cnt = 0;
+   count = 0;
list_for_each_entry(obj, _priv->mm.unbound_list, global_list)
if (obj->pages_pin_count == 0)
-   cnt += obj->base.size >> PAGE_SHIFT;
+   count += obj->base.size >> PAGE_SHIFT;
 -  list_for_each_entry(obj, _priv->mm.inactive_list, global_list)
 +  list_for_each_entry(obj, _priv->mm.inactive_list, mm_list)
if (obj->pin_count == 0 && obj->pages_pin_count == 0)
-   cnt += obj->base.size >> PAGE_SHIFT;
+   count += obj->base.size >> PAGE_SHIFT;
  
if (unlock)
mutex_unlock(>struct_mutex);


pgpM2KBxB8ReH.pgp
Description: PGP signature

paper supplier

[Uurux]

Dear Purchasing manager:
Nice time to you

It is my big pleasure to hear you need A4 paper
we have A4 paper and A3 paper
If you still need that pls tell me

Then i can send you our best price
Best wishes
Ida

Ida Chen

SALES MANAGER

East Siweite industry Co., Ltd
www.dfswtpaper.com

SKYPE: siweite

Email:s...@swtindustry.com

Re: [PATCH RFC 3/3] cpufreq: cpufreq-cpu0: clk rate-change notifiers

[Viresh Kumar]

On Mon, Jul 8, 2013 at 7:14 AM, Mike Turquette  wrote:
> Removes direct handling of OPP tables and voltage regulators by calling
> of_clk_cpufreq_notifier_handler, introduced by commit "clk: cpufreq
> helper for voltage scaling".
>
> In the future this can help consolidate code found across similar
> CPUfreq drivers.
>
> Signed-off-by: Mike Turquette 
> ---
>  drivers/cpufreq/cpufreq-cpu0.c | 125 
> -
>  1 file changed, 22 insertions(+), 103 deletions(-)

Good patch, really gets lots of stuff out from cpufreq drivers.

Acked-by: Viresh Kumar 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: manual merge of the arm-soc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/Kconfig between commit 4a1b573346ee ("ARM: 7758/1:
introduce config HAS_BANDGAP") from Linus' tree and commit 59d92875a6d9
("ARM: OMAP: build mach-omap code only if needed") from the arm-soc tree.

I fixed it up (the latter moved the "config ARCH_OMAP2PLUS" and included
the "select ARCH_HAS_BANDGAP" despite there being no ARCH_HAS_BANDGAP
config in the arm-soc tree :-() and can carry the fix as necessary (no
action is required).

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


pgpG8Vjyb4Ex3.pgp
Description: PGP signature

Re: [GIT PULL] Stage 1 of __cpuinit removal

[Paul Gortmaker]

[Re: [GIT PULL] Stage 1 of __cpuinit removal] On 07/07/2013 (Sun 11:07) Linus 
Torvalds wrote:

> On Tue, Jul 2, 2013 at 10:44 AM, Paul Gortmaker
>  wrote:
> >
> >  include/asm-generic/vmlinux.lds.h | 12 -
> >  include/linux/init.h  | 19 +++---
> >  scripts/mod/modpost.c | 52 
> > +++
> >  3 files changed, 19 insertions(+), 65 deletions(-)
> 
> Your diffstat is odd, and doesn't match mine. But I'm pretty sure
> yours is just plain wrong, because your numbers just don't add up.
> 
> You have:
>   12+19+52 = 83
>   19+65 = 84
> 
> how the heck did you manage that?

I must have fat fingered it in vim/mutt under screen with a stray
Ctrl-A (increase number), since I still have the raw output from
git request-pull that I pulled into mutt and it is sane and correct.

--
$ ls -l prq
-rw-rw-r-- 1 paul paul 845 Jul  2 13:11 prq
$ grep changed prq
 3 files changed, 18 insertions(+), 65 deletions(-)
--

Sorry about the confusion.

Paul.
--

> 
> The correct diffstat would seem to be
> 
>  include/asm-generic/vmlinux.lds.h | 12 
>  include/linux/init.h  | 19 +-
>  scripts/mod/modpost.c | 52
> +
>  3 files changed, 18 insertions(+), 65 deletions(-)
> 
> (where both set of numbers add up to 83).
> 
>   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v9fs:for-linus 7/7] ERROR: code indent should use tabs where possible

[Joe Perches]

On Mon, 2013-07-08 at 11:30 +0800, Fengguang Wu wrote:
> In long run I'd like to disable
> the check types that tend to have false positives.  As for now, these
> checks are disabled in my checkpatch robot:

Are you using a .checkpatch.conf file?

> PATCH_PREFIX
> LONG_LINE
> CAMELCASE

That's a --strict test

> MISSING_SIGN_OFF

Why would you even consider this one?

> COMPLEX_MACRO
> BRACES
> SPACING
> LONG_LINE

OK by me.

> REDUNDANT_CODE

Also a --strict test

> TRAILING_STATEMENTS

False positives?  Got an example?

> UNCOMMENTED_DEFINITION


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: manual merge of the vhost tree with the target-updates tree

[Stephen Rothwell]

Hi Michael,

Today's linux-next merge of the vhost tree got a conflict in
drivers/vhost/scsi.c between commit 084ed45b3846 ("vhost/scsi: Convert to
se_cmd->cmd_kref TARGET_SCF_ACK_KREF usage") from the target-updates tree
and commit 3c63f66a0dcd ("vhost-scsi: Rename struct tcm_vhost_cmd *tv_cmd
to *cmd") from the vhost tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/vhost/scsi.c
index b351938,4264840..000
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@@ -446,19 -448,7 +448,19 @@@ static u32 tcm_vhost_tpg_get_inst_index
  
  static void tcm_vhost_release_cmd(struct se_cmd *se_cmd)
  {
-   struct tcm_vhost_cmd *tv_cmd = container_of(se_cmd,
 -  return;
++  struct tcm_vhost_cmd *cmd = container_of(se_cmd,
 +  struct tcm_vhost_cmd, tvc_se_cmd);
 +
-   if (tv_cmd->tvc_sgl_count) {
++  if (cmd->tvc_sgl_count) {
 +  u32 i;
-   for (i = 0; i < tv_cmd->tvc_sgl_count; i++)
-   put_page(sg_page(_cmd->tvc_sgl[i]));
++  for (i = 0; i < cmd->tvc_sgl_count; i++)
++  put_page(sg_page(>tvc_sgl[i]));
 +
-   kfree(tv_cmd->tvc_sgl);
++  kfree(cmd->tvc_sgl);
 +}
 +
-   tcm_vhost_put_inflight(tv_cmd->inflight);
-   kfree(tv_cmd);
++  tcm_vhost_put_inflight(cmd->inflight);
++  kfree(cmd);
  }
  
  static int tcm_vhost_shutdown_session(struct se_session *se_sess)
@@@ -564,22 -555,28 +567,22 @@@ tcm_vhost_allocate_evt(struct vhost_scs
return evt;
  }
  
- static void vhost_scsi_free_cmd(struct tcm_vhost_cmd *tv_cmd)
+ static void vhost_scsi_free_cmd(struct tcm_vhost_cmd *cmd)
  {
-   struct se_cmd *se_cmd = _cmd->tvc_se_cmd;
+   struct se_cmd *se_cmd = >tvc_se_cmd;
  
/* TODO locking against target/backend threads? */
 -  transport_generic_free_cmd(se_cmd, 1);
 +  transport_generic_free_cmd(se_cmd, 0);
  
 -  if (cmd->tvc_sgl_count) {
 -  u32 i;
 -  for (i = 0; i < cmd->tvc_sgl_count; i++)
 -  put_page(sg_page(>tvc_sgl[i]));
 -
 -  kfree(cmd->tvc_sgl);
 -  }
 -
 -  tcm_vhost_put_inflight(cmd->inflight);
 +}
  
 -  kfree(cmd);
 +static int vhost_scsi_check_stop_free(struct se_cmd *se_cmd)
 +{
 +  return target_put_sess_cmd(se_cmd->se_sess, se_cmd);
  }
  
- static void tcm_vhost_do_evt_work(struct vhost_scsi *vs,
-   struct tcm_vhost_evt *evt)
+ static void
+ tcm_vhost_do_evt_work(struct vhost_scsi *vs, struct tcm_vhost_evt *evt)
  {
struct vhost_virtqueue *vq = >vqs[VHOST_SCSI_VQ_EVT].vq;
struct virtio_scsi_event *event = >event;
@@@ -847,13 -850,13 +856,13 @@@ static void tcm_vhost_submission_work(s
} else {
sg_ptr = NULL;
}
-   tv_nexus = tv_cmd->tvc_nexus;
+   tv_nexus = cmd->tvc_nexus;
  
rc = target_submit_cmd_map_sgls(se_cmd, tv_nexus->tvn_se_sess,
-   tv_cmd->tvc_cdb, _cmd->tvc_sense_buf[0],
-   tv_cmd->tvc_lun, tv_cmd->tvc_exp_data_len,
-   tv_cmd->tvc_task_attr, tv_cmd->tvc_data_direction,
-   TARGET_SCF_ACK_KREF, sg_ptr, tv_cmd->tvc_sgl_count,
+   cmd->tvc_cdb, >tvc_sense_buf[0],
+   cmd->tvc_lun, cmd->tvc_exp_data_len,
+   cmd->tvc_task_attr, cmd->tvc_data_direction,
 -  0, sg_ptr, cmd->tvc_sgl_count,
++  TARGET_SCF_ACK_KREF, sg_ptr, cmd->tvc_sgl_count,
sg_bidi_ptr, sg_no_bidi);
if (rc < 0) {
transport_send_check_condition_and_sense(se_cmd,


pgp5Qfc6QzZQz.pgp
Description: PGP signature

Re: [v9fs:for-linus 7/7] ERROR: code indent should use tabs where possible

[Fengguang Wu]

Hi Eric,

On Sun, Jul 07, 2013 at 10:14:09PM -0500, Eric Van Hensbergen wrote:
> I've fixed this in my for-next branch, Linus rejected my pull on other
> grounds so this should let us fix up these style issues before the merge.
>  Thanks for catching this, I need to go back to running
> checkpatch.plbefore I pull into my tree.  Jim, please run
> checkpatch.pl before sending the patches in the future.  Its annoying and
> there are false positives, but we need to keep things consistent.

Thanks for fixing the style warnings! In long run I'd like to disable
the check types that tend to have false positives.  As for now, these
checks are disabled in my checkpatch robot:

PATCH_PREFIX
LONG_LINE
CAMELCASE
MISSING_SIGN_OFF
COMPLEX_MACRO
BRACES
SPACING
LONG_LINE
REDUNDANT_CODE
TRAILING_STATEMENTS
UNCOMMENTED_DEFINITION

Hopefully this can remind people to run scripts/checkpatch.pl earlier
when patches are still in their hands. :)

Thanks,
Fengguang

> On Sun, Jul 7, 2013 at 7:42 PM, Fengguang Wu  wrote:
>
> >
> > tree:   
> > git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.gitfor-linus
> > head:   ceb251d27e4f1001f3b3feca2e2c774f582e195d
> > commit: ceb251d27e4f1001f3b3feca2e2c774f582e195d [7/7] fs/9p: xattr: add
> > trusted and security namespaces
> >
> > scripts/checkpatch.pl0001-fs-9p-xattr-add-trusted-and-security-namespaces.patch
> >
> > ERROR: code indent should use tabs where possible
> > #84: FILE: fs/9p/xattr.c:176:
> > +_xattr_security_handler,$
> >
> > WARNING: please, no spaces at the start of a line
> > #84: FILE: fs/9p/xattr.c:176:
> > +_xattr_security_handler,$
> >
> > ---
> > 0-DAY kernel build testing backend  Open Source Technology
> > Center
> > http://lists.01.org/mailman/listinfo/kbuild Intel
> > Corporation
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sched: smart wake-affine

[Mike Galbraith]

On Mon, 2013-07-08 at 10:49 +0800, Michael Wang wrote:

> BTW, could you please show me the '/proc/cpuinfo' of your box? I'd like
> to collect some data for analyse later ;-)

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 Quad CPUQ6600  @ 2.40GHz
stepping: 11
microcode   : 0xba
cpu MHz : 1600.000
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor 
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow vnmi 
flexpriority
bogomips: 4784.89
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

-Mike

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

Re: [GIT] Networking

[David Miller]

From: Linus Torvalds 
Date: Sun, 7 Jul 2013 15:33:31 -0700

> End result: I think the code is salvageable and people who want this
> kind of busy-looping can have it. But I really don't want to merge it
> as-is. I think it was badly done, I think it was badly documented, and
> I think somebody over-sold the feature by emphasizing the upsides and
> not the problems.

Fair enough, Eliezer, please address all of Linus's feedback.

It's holding the entire net-next merge up.

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

[PATCH net-next] net/usb: add relative mii functions for r815x

[Hayes Wang]

Base on cdc_ether, add the mii functions for RTL8152 and RTL8153.
The RTL8152 and RTL8153 support ECM mode which use the driver of
cdc_ether. Add the mii functions. Then, the basic PHY access is
possible.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/Makefile|   2 +-
 drivers/net/usb/cdc_ether.c |   9 +-
 drivers/net/usb/r815x.c | 231 
 3 files changed, 239 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/usb/r815x.c

diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 9ab5c9d..e817178 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_USB_HSO) += hso.o
 obj-$(CONFIG_USB_NET_AX8817X)  += asix.o
 asix-y := asix_devices.o asix_common.o ax88172a.o
 obj-$(CONFIG_USB_NET_AX88179_178A)  += ax88179_178a.o
-obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o
+obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o r815x.o
 obj-$(CONFIG_USB_NET_CDC_EEM)  += cdc_eem.o
 obj-$(CONFIG_USB_NET_DM9601)   += dm9601.o
 obj-$(CONFIG_USB_NET_SMSC75XX) += smsc75xx.o
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 4393f14..03ad4dc 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -646,13 +646,18 @@ static const struct usb_device_id products [] = {
 },
 
 /* Realtek RTL8152 Based USB 2.0 Ethernet Adapters */
-#if defined(CONFIG_USB_RTL8152) || defined(CONFIG_USB_RTL8152_MODULE)
 {
USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8152, USB_CLASS_COMM,
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
.driver_info = 0,
 },
-#endif
+
+/* Realtek RTL8153 Based USB 3.0 Ethernet Adapters */
+{
+   USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8153, USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+   .driver_info = 0,
+},
 
 /*
  * WHITELIST!!!
diff --git a/drivers/net/usb/r815x.c b/drivers/net/usb/r815x.c
new file mode 100644
index 000..6516737
--- /dev/null
+++ b/drivers/net/usb/r815x.c
@@ -0,0 +1,231 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RTL815x_REQT_READ  0xc0
+#define RTL815x_REQT_WRITE 0x40
+#define RTL815x_REQ_GET_REGS   0x05
+#define RTL815x_REQ_SET_REGS   0x05
+
+#define MCU_TYPE_PLA   0x0100
+#define OCP_BASE   0xe86c
+#define BASE_MII   0xa400
+
+#define BYTE_EN_DWORD  0xff
+#define BYTE_EN_WORD   0x33
+#define BYTE_EN_BYTE   0x11
+
+#define R815x_PHY_ID   32
+#define REALTEK_VENDOR_ID  0x0bda
+
+
+static int pla_read_word(struct usb_device *udev, u16 index)
+{
+   int data, ret;
+   u8 shift = index & 2;
+
+   index &= ~3;
+
+   ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ RTL815x_REQ_GET_REGS, RTL815x_REQT_READ,
+ index, MCU_TYPE_PLA, , sizeof(data), 500);
+   if (ret < 0)
+   return ret;
+
+   data = __le32_to_cpu(data);
+   data >>= (shift * 8);
+   data &= 0x;
+
+   return data;
+}
+
+static int pla_write_word(struct usb_device *udev, u16 index, u32 data)
+{
+   u32 tmp, mask = 0x;
+   u16 byen = BYTE_EN_WORD;
+   u8 shift = index & 2;
+   int ret;
+
+   data &= mask;
+
+   if (shift) {
+   byen <<= shift;
+   mask <<= (shift * 8);
+   data <<= (shift * 8);
+   index &= ~3;
+   }
+
+   ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ RTL815x_REQ_GET_REGS, RTL815x_REQT_READ,
+ index, MCU_TYPE_PLA, , sizeof(tmp), 500);
+   if (ret < 0)
+   return ret;
+
+   tmp = __le32_to_cpu(tmp) & ~mask;
+   tmp |= data;
+   tmp = __cpu_to_le32(tmp);
+
+   ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ RTL815x_REQ_SET_REGS, RTL815x_REQT_WRITE,
+ index, MCU_TYPE_PLA | byen, ,
+ sizeof(tmp), 500);
+
+   return ret;
+}
+
+static int ocp_reg_read(struct usbnet *dev, u16 addr)
+{
+   u16 ocp_base, ocp_index;
+   int ret;
+
+   ocp_base = addr & 0xf000;
+   ret = pla_write_word(dev->udev, OCP_BASE, ocp_base);
+   if (ret < 0)
+   goto out;
+
+   ocp_index = (addr & 0x0fff) | 0xb000;
+   ret = pla_read_word(dev->udev, ocp_index);
+
+out:
+   return ret;
+}
+
+static int ocp_reg_write(struct usbnet *dev, u16 addr, u16 data)
+{
+   u16 ocp_base, ocp_index;
+   int ret;
+
+   ocp_base = addr & 0xf000;
+   ret = pla_write_word(dev->udev, OCP_BASE, ocp_base);
+   if (ret < 0)
+   goto out1;
+
+   ocp_index = (addr & 0x0fff) | 0xb000;
+   ret = pla_write_word(dev->udev, ocp_index, data);
+
+out1:
+   return ret;
+}
+
+static int r815x_mdio_read(struct net_device *netdev, int 

Re: [PATCH] sched: smart wake-affine

[Michael Wang]

On 07/07/2013 02:43 PM, Mike Galbraith wrote:
> On Fri, 2013-07-05 at 14:16 +0800, Michael Wang wrote:
> 
>> PeterZ has suggested some optimization which I sent out yesterday, I
>> suppose they haven't been included into this test yet, correct?
> 
> No, that was with both v3 patches applied.  hackbench -l 1000 delta
> tracked to next pull/build fwiw, but I don't see anything noteworthy
> elsewhere, so I'm filing it under "tasks/core ~= zillion ~= hohum".

I see, thanks for the testing, Mike :)

I still can't reproduce the issue on my box, so I suggest we put down
this temporarily, if later more similar report show up, let's try to
catch the point.

BTW, could you please show me the '/proc/cpuinfo' of your box? I'd like
to collect some data for analyse later ;-)

Regards,
Michael Wang

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

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

Re: amba-pl08x and 'get_signal' namespace collision/build error

[Vinod Koul]

On Sun, Jul 07, 2013 at 07:04:53PM +0530, Vinod Koul wrote:
> On Sun, Jul 07, 2013 at 01:32:40PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Jul 05, 2013 at 11:48:02AM +0530, Vinod Koul wrote:
> > > On Wed, Jul 03, 2013 at 11:27:12AM -0700, Olof Johansson wrote:
> > > > This has now hit the mainline kernel, and several defconfigs (nhk815,
> > > > lpc32xx and the spear ones) are broken there.
> > > > 
> > > > Vinod, when are you sending up your pull request with the fix? It'd be
> > > > good to see it go in soon.
> > > It should be on its way by the weekend
> > 
> > It still isn't in the tree.
> I sent this morning, depends on how soon can linus merge this
Linus has merged this, so please merge the linus's tree and you should be happy
:)

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

Re: [GIT PULL] slave-dmaengine updates

[Vinod Koul]

On Sun, Jul 07, 2013 at 02:39:18PM -0700, Linus Torvalds wrote:
> On Sat, Jul 6, 2013 at 9:17 PM, Vinod Koul  wrote:
> >
> > Once you have some time from extended weekend celebrations please consider
> > pulling the following to get:
> > - Various fixes and PCI driver for dw_dmac by Andy
> > - DT binding for imx-dma by Markus & imx-sdma by Shawn
> > - DT fixes for dmaengine by Lars
> > - jz4740 dmac driver by Lars
> > - and various fixes across the drivers
> 
> Sadly, I noticed much too late that I should have checked the
> time-stamps on this too. Almost all of the commits seem to have been
> rebased recently. Not quite minutes before the pull request, but 90%
> of the commits seem to have been created long after the merge window
> opened.
I should have mentioned in my pull request. I had to rebase many commits as
there were some duplicate due to bad merge on my part. Wouldnt have been good
idea to send you along with thses. All these have been in -next for quite some
time

> 
> I have already pushed this out so it's too late now, but if I had
> noticed earlier I would have rejected this pull too.

> Today has not been a good day for pulling. If it wasn't for the
> __cpuinit removal pull, I wouldn't have had *anything* today that did
> things properly.
> 
>  Linus "very annoyed" Torvalds
Thanks a bunch for merging
Sorry, will try to ensure its Linus "very happy" Torvalds next time...


Thanks
~Vinod

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] sched: smart wake-affine foundation

[Michael Wang]

Hi, Sam

On 07/07/2013 09:31 AM, Sam Ben wrote:
> On 07/04/2013 12:55 PM, Michael Wang wrote:
>> wake-affine stuff is always trying to pull wakee close to waker, by
>> theory,
>> this will bring benefit if waker's cpu cached hot data for wakee, or the
>> extreme ping-pong case.
> 
> What's the meaning of ping-pong case?

PeterZ explained it well in here:

https://lkml.org/lkml/2013/3/7/332

And you could try to compare:
taskset 1 perf bench sched pipe
with
perf bench sched pipe

to confirm it ;-)

Regards,
Michael Wang

> 
>>
>> And testing show it could benefit hackbench 15% at most.
>>
>> However, the whole stuff is somewhat blindly and time-consuming, some
>> workload therefore suffer.
>>
>> And testing show it could damage pgbench 50% at most.
>>
>> Thus, wake-affine stuff should be more smart, and realise when to stop
>> it's thankless effort.
>>
>> This patch introduced 'nr_wakee_switch', which will be increased each
>> time the task switch it's wakee.
>>
>> So a high 'nr_wakee_switch' means the task has more than one wakee, and
>> bigger the number, higher the wakeup frequency.
>>
>> Now when making the decision on whether to pull or not, pay attention on
>> the wakee with a high 'nr_wakee_switch', pull such task may benefit
>> wakee,
>> but also imply that waker will face cruel competition later, it could be
>> very cruel or very fast depends on the story behind 'nr_wakee_switch',
>> whatever, waker therefore suffer.
>>
>> Furthermore, if waker also has a high 'nr_wakee_switch', imply that
>> multiple
>> tasks rely on it, then waker's higher latency will damage all of them,
>> pull
>> wakee seems to be a bad deal.
>>
>> Thus, when 'waker->nr_wakee_switch / wakee->nr_wakee_switch' become
>> higher
>> and higher, the deal seems to be worse and worse.
>>
>> The patch therefore help wake-affine stuff to stop it's work when:
>>
>> wakee->nr_wakee_switch > factor &&
>> waker->nr_wakee_switch > (factor * wakee->nr_wakee_switch)
>>
>> The factor here is the node-size of current-cpu, so bigger node will lead
>> to more pull since the trial become more severe.
>>
>> After applied the patch, pgbench show 40% improvement at most.
>>
>> Test:
>> Tested with 12 cpu X86 server and tip 3.10.0-rc7.
>>
>> pgbenchbasesmart
>>
>> | db_size | clients |  tps  ||  tps  |
>> +-+-+---+   +---+
>> | 22 MB   |   1 | 10598 |   | 10796 |
>> | 22 MB   |   2 | 21257 |   | 21336 |
>> | 22 MB   |   4 | 41386 |   | 41622 |
>> | 22 MB   |   8 | 51253 |   | 57932 |
>> | 22 MB   |  12 | 48570 |   | 54000 |
>> | 22 MB   |  16 | 46748 |   | 55982 | +19.75%
>> | 22 MB   |  24 | 44346 |   | 55847 | +25.93%
>> | 22 MB   |  32 | 43460 |   | 54614 | +25.66%
>> | 7484 MB |   1 |  8951 |   |  9193 |
>> | 7484 MB |   2 | 19233 |   | 19240 |
>> | 7484 MB |   4 | 37239 |   | 37302 |
>> | 7484 MB |   8 | 46087 |   | 50018 |
>> | 7484 MB |  12 | 42054 |   | 48763 |
>> | 7484 MB |  16 | 40765 |   | 51633 | +26.66%
>> | 7484 MB |  24 | 37651 |   | 52377 | +39.11%
>> | 7484 MB |  32 | 37056 |   | 51108 | +37.92%
>> | 15 GB   |   1 |  8845 |   |  9104 |
>> | 15 GB   |   2 | 19094 |   | 19162 |
>> | 15 GB   |   4 | 36979 |   | 36983 |
>> | 15 GB   |   8 | 46087 |   | 49977 |
>> | 15 GB   |  12 | 41901 |   | 48591 |
>> | 15 GB   |  16 | 40147 |   | 50651 | +26.16%
>> | 15 GB   |  24 | 37250 |   | 52365 | +40.58%
>> | 15 GB   |  32 | 36470 |   | 50015 | +37.14%
>>
>> CC: Ingo Molnar 
>> CC: Peter Zijlstra 
>> CC: Mike Galbraith 
>> Signed-off-by: Michael Wang 
>> ---
>>   include/linux/sched.h |3 +++
>>   kernel/sched/fair.c   |   47
>> +++
>>   2 files changed, 50 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index 178a8d9..1c996c7 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -1041,6 +1041,9 @@ struct task_struct {
>>   #ifdef CONFIG_SMP
>>   struct llist_node wake_entry;
>>   int on_cpu;
>> +struct task_struct *last_wakee;
>> +unsigned long nr_wakee_switch;
>> +unsigned long last_switch_decay;
>>   #endif
>>   int on_rq;
>>   diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index c61a614..a4ddbf5 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -2971,6 +2971,23 @@ static unsigned long cpu_avg_load_per_task(int
>> cpu)
>>   return 0;
>>   }
>>   +static void record_wakee(struct task_struct *p)
>> +{
>> +/*
>> + * Rough decay(wiping) for cost saving, don't worry
>> + * about the boundary, really active task won't care
>> + * the loose.
>> + */
>> +if (jiffies > current->last_switch_decay + HZ) {
>> +current->nr_wakee_switch = 0;
>> +

Re: [RFC][PATCH 3/4] tracing/kprobes: Fail to unregister if probe event files are open

[Masami Hiramatsu]

(2013/07/06 2:26), Oleg Nesterov wrote:
> On 07/05, Masami Hiramatsu wrote:
>>
>> (2013/07/05 3:48), Oleg Nesterov wrote:
>>> On 07/04, Masami Hiramatsu wrote:

 Actually disable_kprobe() doesn't ensure to finish the current running
 kprobe handlers.
>>>
>>> Yes. in fact disable_trace_probe(file != NULL) does, but perf doesn't.
>>
>> Ah, right. we did that.
> 
> And thus we only need to synchronize kprobe_dispatcher()->kprobe_perf_func()
> path. And afaics kprobe_perf_func() doesn't use anything which can be freed
> by trace_remove_event_call?
> 
 OTOH, unregister_kprobe() waits for that.
>>>
>>> Yes.
>>>
>>> So I think we only need to move kfree(tp->call.print_fmt).
> 
> OOPS. I was wrong. It seems that ->print_fmt is only for event/format ?
> Then it is fine to kfree it right after trace_remove_event_call().
> 
>>> So the sequence should be:
>>>
>>> if (trace_remove_event_call(...))
>>> return;
>>>
>>> /* does synchronize_sched */
>>> unregister_kprobe();
>>>
>>> kfree(everything);
>>>
>>> Agreed?
>>
>> If we can free everything after all, I'd like to do so.
>> Hmm, but AFAICS, trace_remove_event_call() supposes that
>> all event is disabled completely.
> 
> Yes, but kprobe_trace_func() is really disabled?

No, currently, doesn't. We need to fix that.
(Perhaps, uprobes too.)

>> A safe way is to wait rcu always right after disable_*probe
>> in disable_trace_probe. If we have an unused link, we can
>> free it after that.
> 
> Aaaah... I am starting to understand... Even if kprobe_perf_func()
> is fine, synchronize_sched() is calles _before_ disable_kprobe()
> and thus it can't synchronize with the handlers which hit this probe
> after we start synchronize_sched().
> 
> Did you mean this or I misssed something else?

Right, thus perf path also need to be synchronized.

Thank you,


-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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/

Re: [PATCH] virtio: include asm/barrier explicitly

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> virtio_ring.h uses mb() and friends, make
> it pull in asm/barrier.h itself, not rely
> on other headers to do it.
>
> Signed-off-by: Michael S. Tsirkin 

Applied.

Thanks,
Rusty.
PS.  I'll squeeze these into this merge window, since they're trivial.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tools/virtio: move module license stub to module.h

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> This fixes build for the vringh test:
> [linux]$ make -C tools/virtio/
> make: Entering directory `/home/mst/scm/linux/tools/virtio'
> cc -g -O2 -Wall -I. -I ../../usr/include/ -Wno-pointer-sign
> -fno-strict-overflow -fno-strict-aliasing -fno-common -MMD
> -U_FORTIFY_SOURCE   -c -o vringh.o ../../drivers/vhost/vringh.c
> ../../drivers/vhost/vringh.c:1010:16: error: expected declaration
> specifiers or ‘...’ before string constant
>
> Signed-off-by: Michael S. Tsirkin 
> ---
>  tools/virtio/linux/module.h | 5 +
>  tools/virtio/linux/virtio.h | 3 ---
>  2 files changed, 5 insertions(+), 3 deletions(-)

Applied, thanks.

Cheers,
Rusty.

> diff --git a/tools/virtio/linux/module.h b/tools/virtio/linux/module.h
> index 3039a7e..28ce95a 100644
> --- a/tools/virtio/linux/module.h
> +++ b/tools/virtio/linux/module.h
> @@ -1 +1,6 @@
>  #include 
> +
> +#define MODULE_LICENSE(__MODULE_LICENSE_value) \
> + static __attribute__((unused)) const char *__MODULE_LICENSE_name = \
> + __MODULE_LICENSE_value
> +
> diff --git a/tools/virtio/linux/virtio.h b/tools/virtio/linux/virtio.h
> index cd80183..8447830 100644
> --- a/tools/virtio/linux/virtio.h
> +++ b/tools/virtio/linux/virtio.h
> @@ -45,9 +45,6 @@ struct virtqueue {
>   void *priv;
>  };
>  
> -#define MODULE_LICENSE(__MODULE_LICENSE_value) \
> - const char *__MODULE_LICENSE_name = __MODULE_LICENSE_value
> -
>  /* Interfaces exported by virtio_ring. */
>  int virtqueue_add_sgs(struct virtqueue *vq,
> struct scatterlist *sgs[],
> -- 
> MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pci: Avoid unnecessary calls to work_on_cpu

[Rusty Russell]

Bjorn Helgaas  writes:
> [+cc Rusty]
>
> On Mon, Jun 24, 2013 at 2:05 PM, Alexander Duyck
>  wrote:
>> This patch is meant to address the fact that we are making unnecessary calls
>> to work_on_cpu.  To resolve this I have added a check to see if the current
>> node is the correct node for the device before we decide to assign the probe
>> task to another CPU.
>>
>> The advantages to this approach is that we can avoid reentrant calls to
>> work_on_cpu.  In addition we should not make any calls to setup the work
>> remotely in the case of a single node system that has NUMA enabled.
>
> The description above makes it sound like this is just a minor
> performance enhancement, but I think the real reason you want this is
> to resolve the lockdep warning mentioned at [1].  That thread is long
> and confusing, so I'd like to see a bugzilla that distills out the
> useful details, and a synopsis in this changelog.
>
> [1] 
> https://lkml.kernel.org/r/1368498506-25857-7-git-send-email-ying...@kernel.org
>
>> Signed-off-by: Alexander Duyck 
>> ---
>>
>> This patch is based off of work I submitted in an earlier patch that I never
>> heard back on.  The change was originally submitted in:
>>   pci: Avoid reentrant calls to work_on_cpu
>>
>> I'm not sure what ever happened with that patch, however after reviewing it
>> some myself I decided I could do without the change to the comments since 
>> they
>> were unneeded.  As such I am resubmitting this as a much simpler patch that
>> only adds the line of code needed to avoid calling work_on_cpu for every call
>> to probe on an NUMA node specific device.
>>
>>  drivers/pci/pci-driver.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>> index 79277fb..7d81713 100644
>> --- a/drivers/pci/pci-driver.c
>> +++ b/drivers/pci/pci-driver.c
>> @@ -282,7 +282,7 @@ static int pci_call_probe(struct pci_driver *drv, struct 
>> pci_dev *dev,
>>its local memory on the right node without any need to
>>change it. */
>> node = dev_to_node(>dev);
>> -   if (node >= 0) {
>> +   if ((node >= 0) && (node != numa_node_id())) {
>> int cpu;
>>
>> get_online_cpus();
>
> I think it's theoretically unsafe to use numa_node_id() while
> preemption is enabled.
>
> It seems a little strange to me that this "run the driver probe method
> on the correct node" code is in PCI.  I would think this behavior
> would be desirable for *all* bus types, not just PCI, so maybe it
> would make sense to do this up in device_attach() or somewhere
> similar.
>
> But Rusty added this (in 873392ca51), and he knows way more about this
> stuff than I do.

Actually, I just stopped the code from playing cpumask games, which is
what it used to do.

You want Andi and/or Greg KH:

commit d42c69972b853fd33a26c8c7405624be41a22136
Author: Andi Kleen 
Date:   Wed Jul 6 19:56:03 2005 +0200

[PATCH] PCI: Run PCI driver initialization on local node

Run PCI driver initialization on local node

Instead of adding messy kmalloc_node()s everywhere run the
PCI driver probe on the node local to the device.

This would not have helped for IDE, but should for
other more clean drivers that do more initialization in probe().
It won't help for drivers that do most of the work
on first open (like many network drivers)

Signed-off-by: Andi Kleen 
Signed-off-by: Greg Kroah-Hartman 

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAINTAINERS: add tools/virtio/ under virtio

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> This should help make sure patches go to the correct list.
>
> Signed-off-by: Michael S. Tsirkin 

Indeed.  Thanks.

Applied,
Rusty.

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ad7e322..66172fc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8800,6 +8800,7 @@ M:  "Michael S. Tsirkin" 
>  L:   virtualizat...@lists.linux-foundation.org
>  S:   Maintained
>  F:   drivers/virtio/
> +F:   tools/virtio/
>  F:   drivers/net/virtio_net.c
>  F:   drivers/block/virtio_blk.c
>  F:   include/linux/virtio_*.h
> -- 
> MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lib: One less subtraction in binary search iterations.

[Rusty Russell]

Wedson Almeida Filho  writes:
> There is no functional change, but this change eliminates a subtraction that
> the compiler doesn't optimize out (as of gcc 4.7.3).
>
> Signed-off-by: Wedson Almeida Filho 
> ---
>  lib/bsearch.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/bsearch.c b/lib/bsearch.c
> index e33c179..3264146 100644
> --- a/lib/bsearch.c
> +++ b/lib/bsearch.c
> @@ -37,7 +37,7 @@ void *bsearch(const void *key, const void *base, size_t 
> num, size_t size,
>   int result;
>  
>   while (start < end) {
> - size_t mid = start + (end - start) / 2;
> + size_t mid = (start + end) / 2;
>  
>   result = cmp(key, base + mid * size);
>   if (result < 0)
> -- 
> 1.7.9.5

Please add a comment about overflow instead?

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen Gang F T]

Firstly, thank you very much for your reply.

On 07/05/2013 07:13 PM, Arnd Bergmann wrote:
> On Friday 05 July 2013, Chen Gang F T wrote:
>> > Hello All:
>> > 
>> > It seems 'asm-generic' dislikes 'mad users' (e.g allmodconfig,
>> > randconfig, and me).
>> > 
>> > I guess the main reason is: 'asm-generic' thinks what mad users talk
>> > about is useless in real world, so it is just noisy.
>> > 
>> > I can understand, at least what I talk about is not for urgent things.
>> > (maybe 'asm-generic' also thinks it not important either, every members
>> > have their own opinions).
>> > 
>> > Next, I still use allmodconfig/randconfig for some architectures which I
>> > am interested in (and also for learning compilers), but I will skip all
>> > things which are related with 'asm-generic', since it dislikes me (a mad
>> > user).
> As the asm-generic maintainer I think I have to clarify a few things:
> 
> * Build-time fixes for warnings and randconfig errors are good,
>   and you have sent a number of good bug fixes all over the kernel,
>   I definitely welcome getting more of those. In many cases the
>   fix is trivial and obvious, in other cases you need to know
>   much more of the background to understand what the underlying
>   problem is and why you should not just fix the symptom.
> 

Since we (at least my company) has already get benifits from Public Open
Source, we should try to provide the contribution back to Public Open
Source.

Providing contributions to Public Open Source is part of my duty (what
I should do).


> * You have made an (understandable) mistake with this particular
>   patch. It would have been nice if you had not made it, but I
>   can see that you are still learning about these things. There
>   is a fine line between what makes sense to be enabled as a
>   'compile test' and what should better be left disabled by
>   Kconfig.
> 

We have to meet three roles: 'user', 'provider' and 'tester' (which is
may mad user, and not quite familiar with the details).

For 'user', they really need 'COMPILE_TEST', so it should be added into
kernel wide. And 'user' often thinks the 'tester' is just a 'mad user'
for 'tester' offten does "mad things" which will be useless in real
world.

For 'provider', he/she often feels the 'tester' is not familiar the
details (in fact, they really not familiar), but he/she has to discuss
with 'tester' (especially 'user' does not care about it). He/She really
feels it is just boring and waste time.

Instead of discussing the details, 'tester' should only provide the
related proof and only can discus the related API, he/she wants the
'provider' to explain about the proof and make the API clearer to every
one (not only for 'expert').

Now, I think, I may just play a 'tester' role for 'asm-generic'.


> * When experienced developers tell you that you are mistaken, you
>   need to make an effort to understand what the mistake was so you
>   can learn from it and not make the same mistake again. If you
>   make the same mistakes again, maintainers will get annoyed and
>   ignore you (or worse), which is not a good situation to be
>   in when you want to get your patches merged.

'tester' wants the 'provider' to explain the proof:

  e.g. 'COMPILE_TEST' help contents whether really say: "can allow 
'COMIPLE_TEST=y' in architectures which no related HW support"
  e.g. If compile fails because of no HW support with "COMPILE_TEST=y", can we 
still let it suspending ?
  e.g. Does it still count an issue, although in real world, it may not happen, 
at least now ?

'tester' also wants the 'provider' to explain 'asm-generic':

  Arnd said:
"It's a set of examples for the architectures to look at and include if 
they want to"
  Steven saind:
"The purpose of asm-generic is to add a standard infrastructure that some 
archs may be able to optimize."

  (In fact, they are not precisely the same).

  Did 'provider' have the related document for it (I guess so, could you 
provide the related location), thanks ?

  according to the definition of 'asm-generic' (either of them):
the 'CONFIG_BUG' need really remove from 'asm-generic', for it is only 
related with some of architectures, not generic enough for all architectures
  (we can continue to discus it in the related thread).
it belongs architectures wide, not kernel wide, is it better to move 
"./include/asm-generic" to "./arch/asm-default" or "./arch/asm-standard" ?

'tester' also wants to try something (but maybe incorrect).

  one sample for string, its value has 4 kinds: 'volatile string', 'const 
string', '""', 'NULL'.  ('""' is not equal to 'NULL').
  may we also have the 4 kinds: 'HAS_IOMAP', 'NOMMU', 'COMPILE_TEST', 'N/A' 
('COMPILE_TEST' is not equal to 'N/A')?

  (this is maybe just boring or wast time, need not reply).


Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [merged] memstick-add-support-for-legacy-memorysticks.patch removed from -mm tree

[Valdis . Kletnieks]

On Mon, 08 Jul 2013 03:41:42 +0300, Maxim Levitsky said:

> +/* Debug test to validate free block counts */
> +#ifdef DEBUG
> +static int msb_validate_used_block_bitmap(struct msb_data *msb)
> +{

Is there a reason this should be inside a #ifdef DEBUG with no
easy way to select DEBUG?  Maybe CONFIG_MS_BLOCK_DEBUG similar to
the way other subsystems allow configuring additional debug code?


pgpvkyqvFxXCw.pgp
Description: PGP signature

Re: [PATCH v3] lib/idr.c rewrite, percpu ida/tag allocator

[Nicholas A. Bellinger]

On Sun, 2013-07-07 at 14:48 +0300, Michael S. Tsirkin wrote:
> On Sat, Jul 06, 2013 at 03:59:06PM -0700, Nicholas A. Bellinger wrote:
> > On Fri, 2013-07-05 at 22:08 -0700, Kent Overstreet wrote:
> > > Previous posting: http://thread.gmane.org/gmane.linux.kernel/1511216
> > > 
> > > The only real change since the last version is that I've reworked the
> > > new ida implementation to not use one giant allocation - it's still
> > > logically one big arary, but it's implemented as an array of arrays.
> > > 
> > > With that, it scales up to INT_MAX allocated ids just fine. Benchmarks
> > > are included in that patch.
> > > 
> > > Patch series is available in my git repo:
> > > git://evilpiepirate.org/~kent/linux-bcache.git idr
> > > 
> > > Andrew, want to pick this up for 3.12?
> > 
> > Just FYI that the target-pending/target-per-cpu-ida branch utilizing
> > per-cpu ida logic for vhost-scsi has been rebased to include this latest
> > series.  Thanks Kent!
> > 
> > Andrew, what are your plans for this..?
> > 
> > Would you consider allowing this series be merged through target-pending
> > in order to allow us to start taking advantage of per-cpu ida tag
> > pre-allocation optimizations for v3.12 target code..? 
> > 
> > Another option would be to merge the per-cpu ida specific piece now for
> > v3.11 for which the risk is low given it doesn't touch any existing
> > code, and then include Kent's full idr rewrite separately as v3.12 item.
> > 
> > WDYT..?
> 
> Takes as is, this conflicts with cleanup patches by Asias in vhost-next
> that I was going to send to Linus for 3.11.

So the proposed vhost-scsi per-cpu ida/tag pre-allocation changes should
be considered v3.12 items.

> Merging new target code for 3.11 and vhost code for 3.12
> helps keep the dependencies simple, so I'm all for it.
> 

My point above is that having (at least) Kent's per-cpu ida code merged
for v3.11 would make it easier to move forward during the v3.12 cycle on
per-cpu ida/tag conversions for vhost-scsi + other target fabric
drivers.

--nab

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

Re: [RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards

[Bo Shen]

Hi Richard,

On 7/5/2013 23:15, Richard Genoud wrote:

+   card->dev = >dev;
>>+   card->owner = THIS_MODULE;
>>+   card->dai_link = dai;
>>+   card->num_links = 1;
>>+   dai->name = "WM8731";
>>+   dai->stream_name = "WM8731 PCM";
>>+   dai->codec_dai_name = "wm8731-hifi";
>>+   dai->init = at91sam9x5ek_wm8731_init;
>>+   card->dapm_widgets = at91sam9x5ek_dapm_widgets;
>>+   card->num_dapm_widgets = ARRAY_SIZE(at91sam9x5ek_dapm_widgets);

>
>
>Will keep these as snd_soc_card and snd_soc_dai_link structure separately?

I don't really understand what you mean here.
do you mean that something like that will more explicit ? :
+   card->dai_link[0].name = "WM8731";
+   card->dai_link[0].stream_name = "WM8731 PCM";
+   card->dai_link[0].codec_dai_name = "wm8731-hifi";
+   card->dai_link[0].init = at91sam9x5ek_wm8731_init;



I mean using structure to define snd_soc_card and snd_soc_dai_link, look 
like:

struct snd_soc_dai_link dai_link_name = {
.name = xxx,
.stream_name = xxx,
...
};

struct snd_soc_card card_name = {
.name = 
.ower = THIS_MODULE,
.dai_link = _link_name,
...
};

In this way, I think it will be more clear than put them in code.

Best Regards,
Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Seg fault occurs when running statically compiled binary from kernel using call_usermodehelper

[Ashish Sangwan]

Forget to mention, we are using ARM

On Mon, Jul 8, 2013 at 10:45 AM, Ashish Sangwan
 wrote:
> On kernel version 3.8.13, when we try to execute a statically compiled
> binary from kernel, it is giving segfault:
>
> insmod /mnt/module2.ko
> [   35.56] sample.static: unhandled page fault (11) at 0x,
> code 0x8007
> [   36.44] Pid: 257, comm:sample.static
> [   36.444000] CPU: 3Tainted: GW  O  (3.8.13+ #35)
> [   36.448000] PC is at 0x0
> [   36.452000] LR is at 0xa420
> [   36.456000] pc : [<>]lr : []psr: 6030
> [   36.456000] sp : beb30d70  ip : 0004  fp : 
> [   36.464000] r10: a004  r9 : a0a4  r8 : 0001
> [   36.472000] r7 : 0001  r6 : 0008be5c  r5 :   r4 : 0008ce80
> [   36.476000] r3 : 0001  r2 : 0001  r1 :   r0 : 
> [   36.484000] Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA Thumb
> Segment user
> [   36.492000] Control: 10c53c7d  Table: 7b1f806a  DAC: 0015
> [   36.496000] Backtrace:
> [   36.50] [] (dump_backtrace+0x0/0x11c) from
> [] (dump_stack+0x20/0x24)
> [   36.508000]  r6:e514dd80 r5: r4:e5175fb0 r3:271ae511
> [   36.516000] [] (dump_stack+0x0/0x24) from []
> (show_regs+0x58/0x5c)
> [   36.524000] [] (show_regs+0x0/0x5c) from []
> (show_info+0xe0/0x14c)
> [   36.532000]  r4: r3:
> [   36.532000] [] (show_info+0x0/0x14c) from []
> (__do_user_fault+0x78/0xc8)
> [   36.54]  r7:8007 r6:000b r5: r4:e514dd80
> [   36.548000] [] (__do_user_fault+0x0/0xc8) from
> [] (do_page_fault+0x360/0x3d4)
> [   36.556000] [] (do_page_fault+0x0/0x3d4) from
> [] (do_PrefetchAbort+0x44/0xa8)
> [   36.564000] [] (do_PrefetchAbort+0x0/0xa8) from
> [] (ret_from_exception+0x0/0x10)
> [   36.572000] Exception stack(0xe5175fb0 to 0xe5175ff8)
> [   36.96] do_init_module: 'module2'->init suspiciously returned
> 11, it should follow 0/-E convention
> [   36.96] do_init_module: loading module anyway...
> [   36.964000] Backtrace:
> [   36.968000] [] (dump_backtrace+0x0/0x11c) from
> [] (dump_stack+0x20/0x24)
> [   36.972000]  r6:bf90 r5:bf9c r4:e51d7f48 r3:
> [   36.98] [] (dump_stack+0x0/0x24) from []
> (load_module+0x1a90/0x1eb4)
> [   36.984000] [] (load_module+0x0/0x1eb4) from []
> (sys_init_module+0xe8/0xf8)
> [   36.988000] [] (sys_init_module+0x0/0xf8) from
> [] (ret_fast_syscall+0x0/0x48)
> [   36.992000]  r6:bea51a14 r5:bea51b7c r4:6ee4
> [   36.996000] module2 mod ld
>
> module2.c =>
> #include 
> #include 
> #include 
> MODULE_LICENSE( "GPL" );
> static int test( void )
> {
>   char *argv[] = { "/mnt/sample.static", NULL };
>   static char *envp[] = {
> "HOME=/",
> "TERM=linux",
> "PATH=/sbin:/bin:/usr/sbin:/usr/bin", NULL };
>   return call_usermodehelper(argv[0], argv, envp, UMH_WAIT_PROC );
> }
> static int __init mod_entry_func( void )
> {
>   return test();
> }
>
> static void __exit mod_exit_func( void )
> {
>   return;
> }
> module_init( mod_entry_func );
> module_exit( mod_exit_func );
>
>
> sample.static is a simple "Hello_world" program.
>
> However, there is no problem in executing dynamically compiled binaries.
>
> When we revert commit 9fff2fa0db911b0b75ec1f9bec72460c0a676ef5 (arm:
> switch to saner kernel_execve() semantics), there is no problem.
>
> OR
>
> for kernel 3.8.13 (which is just a plain revert when arch specific
> kernel_execve was present), then also no problem =>
>
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 0023a87..9cf6e15 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -184,6 +184,10 @@ static int call_usermodehelper(void *data)
> struct subprocess_info *sub_info = data;
> struct cred *new;
> int retval;
> +#ifdef ARM
> +   struct pt_regs regs;
> +   struct pt_regs *curr_ptr;
> +#endif
> spin_lock_irq(>sighand->siglock);
> flush_signal_handlers(current, 1);
> @@ -222,6 +226,36 @@ static int call_usermodehelper(void *data)
> retval = do_execve(sub_info->path,
>(const char __user *const __user *)sub_info->argv,
>(const char __user *const __user *)sub_info->envp);
> +
> +#ifdef ARM
> +   if (retval)
> +   goto fail;
> +   curr_ptr = current_pt_regs();
> +   memcpy(, curr_ptr, sizeof(struct pt_regs));
> +   /*
> +* Save argc to the register structure for userspace.
> +*/
> +   regs.ARM_r0 = retval;
> +
> +   /*
> +* We were successful.  We won't be returning to our caller, but
> +* instead to user space by manipulating the kernel stack.
> +*/
> +   asm("addr0, %0, %1\n\t"
> +   "movr1, %2\n\t"
> +   "movr2, %3\n\t"
> +   "bl memmove\n\t"/* copy regs to top of stack */
> +   "movr8, #0\n\t" /* not a syscall */
> +   "movr9, %0\n\t" /* thread 

[PATCH RFC 1/3] clk: notifier handler for dynamic voltage scaling

[Mike Turquette]

This patch provides helper functions for drivers that wish to scale
voltage through the clock rate-change notifiers. The approach taken is
that the driver does not care about the details of the OPP table, nor
does it care about handling the voltage regulator directly. The driver
only has a pointer to the struct clk object; the other details are
hidden in the helper functions.

The assumptions about DT structure mostly come from the cpufreq-cpu0
binding. Since this is a helper function it does not have a binding
document of its own.

A similar patch using platform data instead of DT was proposed in
February[1].

[1] http://patches.linaro.org/15128/

Signed-off-by: Mike Turquette 
---
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-voltage-notifier.c | 135 +
 include/linux/clk.h|   7 +-
 3 files changed, 142 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/clk-voltage-notifier.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d3c3733..beb39f1 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-fixed-rate.o
 obj-$(CONFIG_COMMON_CLK)   += clk-gate.o
 obj-$(CONFIG_COMMON_CLK)   += clk-mux.o
 obj-$(CONFIG_COMMON_CLK)   += clk-composite.o
+obj-$(CONFIG_COMMON_CLK)   += clk-voltage-notifier.o
 
 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
diff --git a/drivers/clk/clk-voltage-notifier.c 
b/drivers/clk/clk-voltage-notifier.c
new file mode 100644
index 000..cb6b85f
--- /dev/null
+++ b/drivers/clk/clk-voltage-notifier.c
@@ -0,0 +1,135 @@
+/*
+ * Copyright (C) 2013 Linaro Ltd 
+ *
+ * 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.
+ *
+ * Helper functions for registering clock rate-change notifier handlers
+ * that scale voltage when a clock changes its output frequency.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct volt_scale_data {
+   struct device *dev;
+   struct clk *clk;
+   struct regulator *reg;
+   int tol;
+   struct notifier_block nb;
+};
+
+#define to_volt_scale_data(_nb) container_of(_nb, \
+   struct volt_scale_data, nb)
+
+static int clk_volt_notifier_handler(struct notifier_block *nb,
+   unsigned long flags, void *data)
+{
+   struct clk_notifier_data *cnd = data;
+   struct volt_scale_data *vsd = to_volt_scale_data(nb);
+   int ret, new_volt, old_volt, tol;
+   struct opp *opp;
+   unsigned long old_rate = cnd->old_rate;
+   unsigned long new_rate = cnd->new_rate;
+
+   rcu_read_lock();
+   opp = opp_find_freq_ceil(vsd->dev, _rate);
+   if (IS_ERR(opp)) {
+   rcu_read_unlock();
+   dev_err(vsd->dev, "%s: failed to find OPP for %lu\n",
+   __func__, new_rate);
+   return notifier_from_errno(PTR_ERR(opp));
+   }
+   new_volt = opp_get_voltage(opp);
+   rcu_read_unlock();
+
+   tol = new_volt * vsd->tol / 100;
+   old_volt = regulator_get_voltage(vsd->reg);
+
+   /* scaling up? scale voltage before frequency */
+   if (new_rate > old_rate) {
+   ret = regulator_set_voltage_tol(vsd->reg, new_volt, tol);
+   if (ret) {
+   dev_err(vsd->dev, "%s: failed to scale voltage up: 
%d\n",
+   __func__, ret);
+   return notifier_from_errno(ret);
+   }
+   }
+
+   /* scaling down? scale voltage after frequency */
+   if (new_rate < old_rate) {
+   ret = regulator_set_voltage_tol(vsd->reg, new_volt, tol);
+   if (ret) {
+   dev_err(vsd->dev, "%s: failed to scale voltage down: 
%d\n",
+   __func__, ret);
+   return notifier_from_errno(ret);
+   }
+   }
+
+   return NOTIFY_OK;
+}
+
+/**
+ * of_clk_volt_notifier_register - register clock notifier to scale voltage
+ * @dev: device that scales clock and voltage regulator
+ * @np: pointer to DeviceTree node
+ * @supply: regulator id string
+ */
+struct notifier_block *of_clk_volt_notifier_register(struct device *dev,
+   struct device_node *np, struct clk *clk, const char *supply,
+   int *voltage_latency)
+{
+   struct volt_scale_data *vsd;
+   int ret;
+
+   vsd = kzalloc(sizeof(struct volt_scale_data), GFP_KERNEL);
+   if (!vsd)
+   return ERR_PTR(-ENOMEM);
+
+   vsd->dev = dev;
+   vsd->clk = clk;
+   vsd->nb.notifier_call = clk_volt_notifier_handler;
+
+   vsd->reg = devm_regulator_get(dev, supply);
+   if (IS_ERR(vsd->reg)) {
+   ret = PTR_ERR(vsd->reg);
+   goto 

[PATCH RFC 0/3] voltage scaling via clock rate-change notifiers

[Mike Turquette]

Scaling regulator voltage as a function of clock frequency is a common
power saving technique. It is often referred to as dynamic voltage &
frequency scaling (DVFS). The common clock framework has clock
rate-change notifier (pre & post) which provide a convenient hook for
scaling voltage whenever clk_set_rate is called.

The first patch in the series provides helper functions for drivers that
wish to scale voltage through the clock rate-change notifiers. The
approach taken is that the driver does not care about the details of the
OPP table, nor does it care about handling the voltage regulator
directly. The driver only has a pointer to the struct clk object; the
other details are hidden in the helper functions.

The second patch provides a CPUfreq-centric helper, built on top of the
first one. This is primarly to help with the struct
cpufreq_frequency_table bits and latency calculation.

The final patch in the series converts the cpufreq-cpu0 driver to use
these functions. Other cpufreq drivers can be converted later.

There are not many cases of DVFS usage in the kernel; vendors often keep
these out-of-tree. By providing a common approach using the clock rate
change notifiers this series hopes to consolidate code across drivers
and encourage vendors to upstream their DVFS bits.

Mike Turquette (3):
  clk: notifier handler for dynamic voltage scaling
  clk: cpufreq helper for voltage scaling
  cpufreq: cpufreq-cpu0: clk rate-change notifiers

 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-voltage-notifier.c | 206 +
 drivers/cpufreq/cpufreq-cpu0.c | 125 --
 include/linux/clk.h|  13 ++-
 4 files changed, 241 insertions(+), 104 deletions(-)
 create mode 100644 drivers/clk/clk-voltage-notifier.c

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

Seg fault occurs when running statically compiled binary from kernel using call_usermodehelper

[Ashish Sangwan]

On kernel version 3.8.13, when we try to execute a statically compiled
binary from kernel, it is giving segfault:

insmod /mnt/module2.ko
[   35.56] sample.static: unhandled page fault (11) at 0x,
code 0x8007
[   36.44] Pid: 257, comm:sample.static
[   36.444000] CPU: 3Tainted: GW  O  (3.8.13+ #35)
[   36.448000] PC is at 0x0
[   36.452000] LR is at 0xa420
[   36.456000] pc : [<>]lr : []psr: 6030
[   36.456000] sp : beb30d70  ip : 0004  fp : 
[   36.464000] r10: a004  r9 : a0a4  r8 : 0001
[   36.472000] r7 : 0001  r6 : 0008be5c  r5 :   r4 : 0008ce80
[   36.476000] r3 : 0001  r2 : 0001  r1 :   r0 : 
[   36.484000] Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA Thumb
Segment user
[   36.492000] Control: 10c53c7d  Table: 7b1f806a  DAC: 0015
[   36.496000] Backtrace:
[   36.50] [] (dump_backtrace+0x0/0x11c) from
[] (dump_stack+0x20/0x24)
[   36.508000]  r6:e514dd80 r5: r4:e5175fb0 r3:271ae511
[   36.516000] [] (dump_stack+0x0/0x24) from []
(show_regs+0x58/0x5c)
[   36.524000] [] (show_regs+0x0/0x5c) from []
(show_info+0xe0/0x14c)
[   36.532000]  r4: r3:
[   36.532000] [] (show_info+0x0/0x14c) from []
(__do_user_fault+0x78/0xc8)
[   36.54]  r7:8007 r6:000b r5: r4:e514dd80
[   36.548000] [] (__do_user_fault+0x0/0xc8) from
[] (do_page_fault+0x360/0x3d4)
[   36.556000] [] (do_page_fault+0x0/0x3d4) from
[] (do_PrefetchAbort+0x44/0xa8)
[   36.564000] [] (do_PrefetchAbort+0x0/0xa8) from
[] (ret_from_exception+0x0/0x10)
[   36.572000] Exception stack(0xe5175fb0 to 0xe5175ff8)
[   36.96] do_init_module: 'module2'->init suspiciously returned
11, it should follow 0/-E convention
[   36.96] do_init_module: loading module anyway...
[   36.964000] Backtrace:
[   36.968000] [] (dump_backtrace+0x0/0x11c) from
[] (dump_stack+0x20/0x24)
[   36.972000]  r6:bf90 r5:bf9c r4:e51d7f48 r3:
[   36.98] [] (dump_stack+0x0/0x24) from []
(load_module+0x1a90/0x1eb4)
[   36.984000] [] (load_module+0x0/0x1eb4) from []
(sys_init_module+0xe8/0xf8)
[   36.988000] [] (sys_init_module+0x0/0xf8) from
[] (ret_fast_syscall+0x0/0x48)
[   36.992000]  r6:bea51a14 r5:bea51b7c r4:6ee4
[   36.996000] module2 mod ld

module2.c =>
#include 
#include 
#include 
MODULE_LICENSE( "GPL" );
static int test( void )
{
  char *argv[] = { "/mnt/sample.static", NULL };
  static char *envp[] = {
"HOME=/",
"TERM=linux",
"PATH=/sbin:/bin:/usr/sbin:/usr/bin", NULL };
  return call_usermodehelper(argv[0], argv, envp, UMH_WAIT_PROC );
}
static int __init mod_entry_func( void )
{
  return test();
}

static void __exit mod_exit_func( void )
{
  return;
}
module_init( mod_entry_func );
module_exit( mod_exit_func );


sample.static is a simple "Hello_world" program.

However, there is no problem in executing dynamically compiled binaries.

When we revert commit 9fff2fa0db911b0b75ec1f9bec72460c0a676ef5 (arm:
switch to saner kernel_execve() semantics), there is no problem.

OR

for kernel 3.8.13 (which is just a plain revert when arch specific
kernel_execve was present), then also no problem =>

diff --git a/kernel/kmod.c b/kernel/kmod.c
index 0023a87..9cf6e15 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -184,6 +184,10 @@ static int call_usermodehelper(void *data)
struct subprocess_info *sub_info = data;
struct cred *new;
int retval;
+#ifdef ARM
+   struct pt_regs regs;
+   struct pt_regs *curr_ptr;
+#endif
spin_lock_irq(>sighand->siglock);
flush_signal_handlers(current, 1);
@@ -222,6 +226,36 @@ static int call_usermodehelper(void *data)
retval = do_execve(sub_info->path,
   (const char __user *const __user *)sub_info->argv,
   (const char __user *const __user *)sub_info->envp);
+
+#ifdef ARM
+   if (retval)
+   goto fail;
+   curr_ptr = current_pt_regs();
+   memcpy(, curr_ptr, sizeof(struct pt_regs));
+   /*
+* Save argc to the register structure for userspace.
+*/
+   regs.ARM_r0 = retval;
+
+   /*
+* We were successful.  We won't be returning to our caller, but
+* instead to user space by manipulating the kernel stack.
+*/
+   asm("addr0, %0, %1\n\t"
+   "movr1, %2\n\t"
+   "movr2, %3\n\t"
+   "bl memmove\n\t"/* copy regs to top of stack */
+   "movr8, #0\n\t" /* not a syscall */
+   "movr9, %0\n\t" /* thread structure */
+   "movsp, r0\n\t" /* reposition stack pointer */
+   "b  ret_to_user"
+   :
+   : "r" (current_thread_info()),
+ "Ir" (THREAD_START_SP - sizeof(regs)),
+ "r" (),
+ "Ir" (sizeof(regs))
+   : "r0", "r1", "r2", 

[PATCH RFC 3/3] cpufreq: cpufreq-cpu0: clk rate-change notifiers

[Mike Turquette]

Removes direct handling of OPP tables and voltage regulators by calling
of_clk_cpufreq_notifier_handler, introduced by commit "clk: cpufreq
helper for voltage scaling".

In the future this can help consolidate code found across similar
CPUfreq drivers.

Signed-off-by: Mike Turquette 
---
 drivers/cpufreq/cpufreq-cpu0.c | 125 -
 1 file changed, 22 insertions(+), 103 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..1e8f928 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -16,18 +16,15 @@
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 
 static unsigned int transition_latency;
-static unsigned int voltage_tolerance; /* in percentage */
 
 static struct device *cpu_dev;
 static struct clk *cpu_clk;
-static struct regulator *cpu_reg;
 static struct cpufreq_frequency_table *freq_table;
+static struct notifier_block *clk_nb;
 
 static int cpu0_verify_speed(struct cpufreq_policy *policy)
 {
@@ -43,8 +40,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
   unsigned int target_freq, unsigned int relation)
 {
struct cpufreq_freqs freqs;
-   struct opp *opp;
-   unsigned long volt = 0, volt_old = 0, tol = 0;
+   unsigned long volt = 0, volt_old = 0;
long freq_Hz, freq_exact;
unsigned int index;
int ret;
@@ -69,56 +65,16 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
 
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
 
-   if (cpu_reg) {
-   rcu_read_lock();
-   opp = opp_find_freq_ceil(cpu_dev, _Hz);
-   if (IS_ERR(opp)) {
-   rcu_read_unlock();
-   pr_err("failed to find OPP for %ld\n", freq_Hz);
-   freqs.new = freqs.old;
-   ret = PTR_ERR(opp);
-   goto post_notify;
-   }
-   volt = opp_get_voltage(opp);
-   rcu_read_unlock();
-   tol = volt * voltage_tolerance / 100;
-   volt_old = regulator_get_voltage(cpu_reg);
-   }
-
pr_debug("%u MHz, %ld mV --> %u MHz, %ld mV\n",
 freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
 freqs.new / 1000, volt ? volt / 1000 : -1);
 
-   /* scaling up?  scale voltage before frequency */
-   if (cpu_reg && freqs.new > freqs.old) {
-   ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
-   if (ret) {
-   pr_err("failed to scale voltage up: %d\n", ret);
-   freqs.new = freqs.old;
-   goto post_notify;
-   }
-   }
-
ret = clk_set_rate(cpu_clk, freq_exact);
if (ret) {
pr_err("failed to set clock rate: %d\n", ret);
-   if (cpu_reg)
-   regulator_set_voltage_tol(cpu_reg, volt_old, tol);
freqs.new = freqs.old;
-   goto post_notify;
-   }
-
-   /* scaling down?  scale voltage after frequency */
-   if (cpu_reg && freqs.new < freqs.old) {
-   ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
-   if (ret) {
-   pr_err("failed to scale voltage down: %d\n", ret);
-   clk_set_rate(cpu_clk, freqs.old * 1000);
-   freqs.new = freqs.old;
-   }
}
 
-post_notify:
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
 
return ret;
@@ -175,6 +131,7 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
 static int cpu0_cpufreq_probe(struct platform_device *pdev)
 {
struct device_node *np, *parent;
+   unsigned int voltage_latency;
int ret;
 
parent = of_find_node_by_path("/cpus");
@@ -197,22 +154,6 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
cpu_dev = >dev;
cpu_dev->of_node = np;
 
-   cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
-   if (IS_ERR(cpu_reg)) {
-   /*
-* If cpu0 regulator supply node is present, but regulator is
-* not yet registered, we should try defering probe.
-*/
-   if (PTR_ERR(cpu_reg) == -EPROBE_DEFER) {
-   dev_err(cpu_dev, "cpu0 regulator not ready, retry\n");
-   ret = -EPROBE_DEFER;
-   goto out_put_node;
-   }
-   pr_warn("failed to get cpu0 regulator: %ld\n",
-   PTR_ERR(cpu_reg));
-   cpu_reg = NULL;
-   }
-
cpu_clk = devm_clk_get(cpu_dev, NULL);
if (IS_ERR(cpu_clk)) {
ret = PTR_ERR(cpu_clk);
@@ -220,60 +161,38 @@ static int cpu0_cpufreq_probe(struct platform_device 
*pdev)
goto out_put_node;
}
 
-   ret = 

Re: [PATCH 8/8] ARM: exynos: select PM_GENERIC_DOMAINS only when used

[Jingoo Han]

On Friday, July 05, 2013 9:25 AM, Arnd Bergmann wrote:

Hi Arnd,

This bug fix patch was already submitted on May 27th, as below:

https://patchwork.kernel.org/patch/2617191/


Best regards,
Jingoo Han

> This fixes building exynos kernels with CONFIG_PM disabled.
>
> Signed-off-by: Arnd Bergmann 
> Cc: Kukjin Kim 
> ---
>  arch/arm/mach-exynos/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 2d503b3..ba70a84 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -38,7 +38,7 @@ config CPU_EXYNOS4210
>   depends on ARCH_EXYNOS4
>   select ARM_CPU_SUSPEND if PM
>   select PINCTRL_EXYNOS
> - select PM_GENERIC_DOMAINS
> + select PM_GENERIC_DOMAINS if PM
>   select S5P_PM if PM
>   select S5P_SLEEP if PM
>   select SAMSUNG_DMADEV
> --

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC 2/3] clk: cpufreq helper for voltage scaling

[Mike Turquette]

This patch builds on "clk: notifier handler for dynamic voltage scaling"
by adding a CPUfreq-specific helper function for registering a clock
rate-change notifier to scale regulator voltage as a function of clock
rate.

In particular this patch creates an instance of struct
cpufreq_frequency_table and also calculate the voltage scaling latency,
both of which are returned to the caller for use in the CPUfreq driver.

Signed-off-by: Mike Turquette 
---
 drivers/clk/clk-voltage-notifier.c | 71 ++
 include/linux/clk.h|  6 
 2 files changed, 77 insertions(+)

diff --git a/drivers/clk/clk-voltage-notifier.c 
b/drivers/clk/clk-voltage-notifier.c
index cb6b85f..8e1707f 100644
--- a/drivers/clk/clk-voltage-notifier.c
+++ b/drivers/clk/clk-voltage-notifier.c
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -133,3 +134,73 @@ void of_clk_volt_notifier_unregister(struct notifier_block 
*nb)
kfree(vsd);
 }
 EXPORT_SYMBOL_GPL(of_clk_volt_notifier_unregister);
+
+void of_clk_cpufreq_notifier_unregister(struct notifier_block *nb,
+   struct cpufreq_frequency_table *freq_table)
+{
+   struct volt_scale_data *data = to_volt_scale_data(nb);
+   struct device *dev = data->dev;
+
+   opp_free_cpufreq_table(dev, _table);
+   of_clk_volt_notifier_unregister(nb);
+}
+EXPORT_SYMBOL_GPL(of_clk_cpufreq_notifier_unregister);
+
+/**
+ * of_clk_cpufreq_notifer_register - register clock notifier to scale voltage
+ * @dev: device that owns this scaling operation
+ * @np: pointer to device's DT node
+ * @clk: clock whose rate-change notifier triggers voltage scaling
+ * @supply: regulator id string
+ * @freq_table: pointer to uninitialized CPUfreq frequency scaling table
+ * @voltage_latency: worst case voltage scaling latency
+ */
+struct notifier_block *of_clk_cpufreq_notifier_register(struct device *dev,
+   struct device_node *np, struct clk *clk, const char *supply,
+   struct cpufreq_frequency_table **table,
+   unsigned int *voltage_latency)
+{
+   struct notifier_block *nb;
+   struct volt_scale_data *vsd;
+   struct opp *opp;
+   unsigned long min, max;
+   int ret, i;
+
+   nb = of_clk_volt_notifier_register(dev, np, clk, supply,
+   voltage_latency);
+   if (IS_ERR(nb))
+   return nb;
+
+   vsd = to_volt_scale_data(nb);
+
+   ret = opp_init_cpufreq_table(dev, table);
+   if (ret) {
+   pr_err("failed to init cpufreq table: %d\n", ret);
+   goto err_unregister;
+   }
+
+   /* find the min and max voltages and compute worst-case latency */
+   for (i = 0; table[0][i].frequency != CPUFREQ_TABLE_END; i++)
+   ;
+
+   rcu_read_lock();
+   opp = opp_find_freq_exact(dev,
+   table[0][0].frequency * 1000, true);
+   min = opp_get_voltage(opp);
+   opp = opp_find_freq_exact(dev,
+   table[0][i-1].frequency * 1000, true);
+   max = opp_get_voltage(opp);
+   rcu_read_unlock();
+
+   *voltage_latency = regulator_set_voltage_time(vsd->reg, min, max);
+   if (*voltage_latency < 0)
+   pr_warn("%s: failed to calculate voltage latency, %d\n",
+   __func__, ret);
+
+   return nb;
+
+err_unregister:
+   of_clk_volt_notifier_unregister(nb);
+   return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(of_clk_cpufreq_notifier_register);
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 85ea520..3104883 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -86,6 +86,12 @@ struct notifier_block *of_clk_volt_notifier_register(struct 
device *dev,
struct device_node *np, struct clk *clk, const char *supply,
int *voltage_latency);
 void of_clk_volt_notifier_unregister(struct notifier_block *nb);
+struct notifier_block *of_clk_cpufreq_notifier_register(struct device *dev,
+   struct device_node *np, struct clk *clk, const char *supply,
+   struct cpufreq_frequency_table **table,
+   unsigned int *voltage_latency);
+void of_clk_cpufreq_notifier_unregister(struct notifier_block *nb,
+   struct cpufreq_frequency_table *freq_table);
 
 #endif
 
-- 
1.8.1.2

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

Re: [PATCH 1/2] extcon: palmas: rename device tree binding matching with file name

[Chanwoo Choi]

On 07/05/2013 10:59 PM, Laxman Dewangan wrote:
> The driver name is extcon/extcon-palmas.c and hence renaming the
> device tree binding document to extcon-palmas.txt.
> 
> Signed-off-by: Laxman Dewangan 
> ---
>  .../extcon/{extcon-twl.txt => extcon-palmas.txt}   |0
>  1 files changed, 0 insertions(+), 0 deletions(-)
>  rename Documentation/devicetree/bindings/extcon/{extcon-twl.txt => 
> extcon-palmas.txt} (100%)
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/extcon/extcon-twl.txt
> rename to Documentation/devicetree/bindings/extcon/extcon-palmas.txt
> 

Applied patch1 and patch2.

You can check it on following git repo:
- git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git (extcon-linus)

Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] powerpc: Prepare to support kernel handling of IOMMU map/unmap

[Benjamin Herrenschmidt]

On Sun, 2013-07-07 at 01:07 +1000, Alexey Kardashevskiy wrote:
> The current VFIO-on-POWER implementation supports only user mode
> driven mapping, i.e. QEMU is sending requests to map/unmap pages.
> However this approach is really slow, so we want to move that to KVM.
> Since H_PUT_TCE can be extremely performance sensitive (especially with
> network adapters where each packet needs to be mapped/unmapped) we chose
> to implement that as a "fast" hypercall directly in "real
> mode" (processor still in the guest context but MMU off).
> 
> To be able to do that, we need to provide some facilities to
> access the struct page count within that real mode environment as things
> like the sparsemem vmemmap mappings aren't accessible.
> 
> This adds an API to increment/decrement page counter as
> get_user_pages API used for user mode mapping does not work
> in the real mode.
> 
> CONFIG_SPARSEMEM_VMEMMAP and CONFIG_FLATMEM are supported.

This patch will need an ack from "mm" people to make sure they are ok
with our approach and ack the change to the generic header.

(Added linux-mm).

Cheers,
Ben.

> Reviewed-by: Paul Mackerras 
> Signed-off-by: Paul Mackerras 
> Signed-off-by: Alexey Kardashevskiy 
> 
> ---
> 
> Changes:
> 2013/06/27:
> * realmode_get_page() fixed to use get_page_unless_zero(). If failed,
> the call will be passed from real to virtual mode and safely handled.
> * added comment to PageCompound() in include/linux/page-flags.h.
> 
> 2013/05/20:
> * PageTail() is replaced by PageCompound() in order to have the same checks
> for whether the page is huge in realmode_get_page() and realmode_put_page()
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
>  arch/powerpc/include/asm/pgtable-ppc64.h |  4 ++
>  arch/powerpc/mm/init_64.c| 78 
> +++-
>  include/linux/page-flags.h   |  4 +-
>  3 files changed, 84 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h 
> b/arch/powerpc/include/asm/pgtable-ppc64.h
> index e3d55f6f..7b46e5f 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> @@ -376,6 +376,10 @@ static inline pte_t *find_linux_pte_or_hugepte(pgd_t 
> *pgdir, unsigned long ea,
>  }
>  #endif /* !CONFIG_HUGETLB_PAGE */
>  
> +struct page *realmode_pfn_to_page(unsigned long pfn);
> +int realmode_get_page(struct page *page);
> +int realmode_put_page(struct page *page);
> +
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* _ASM_POWERPC_PGTABLE_PPC64_H_ */
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index a90b9c4..7031be3 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -297,5 +297,81 @@ void vmemmap_free(unsigned long start, unsigned long end)
>  {
>  }
>  
> -#endif /* CONFIG_SPARSEMEM_VMEMMAP */
> +/*
> + * We do not have access to the sparsemem vmemmap, so we fallback to
> + * walking the list of sparsemem blocks which we already maintain for
> + * the sake of crashdump. In the long run, we might want to maintain
> + * a tree if performance of that linear walk becomes a problem.
> + *
> + * Any of realmode_ functions can fail due to:
> + * 1) As real sparsemem blocks do not lay in RAM continously (they
> + * are in virtual address space which is not available in the real mode),
> + * the requested page struct can be split between blocks so get_page/put_page
> + * may fail.
> + * 2) When huge pages are used, the get_page/put_page API will fail
> + * in real mode as the linked addresses in the page struct are virtual
> + * too.
> + * When 1) or 2) takes place, the API returns an error code to cause
> + * an exit to kernel virtual mode where the operation will be completed.
> + */
> +struct page *realmode_pfn_to_page(unsigned long pfn)
> +{
> + struct vmemmap_backing *vmem_back;
> + struct page *page;
> + unsigned long page_size = 1 << mmu_psize_defs[mmu_vmemmap_psize].shift;
> + unsigned long pg_va = (unsigned long) pfn_to_page(pfn);
>  
> + for (vmem_back = vmemmap_list; vmem_back; vmem_back = vmem_back->list) {
> + if (pg_va < vmem_back->virt_addr)
> + continue;
> +
> + /* Check that page struct is not split between real pages */
> + if ((pg_va + sizeof(struct page)) >
> + (vmem_back->virt_addr + page_size))
> + return NULL;
> +
> + page = (struct page *) (vmem_back->phys + pg_va -
> + vmem_back->virt_addr);
> + return page;
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
> +
> +#elif defined(CONFIG_FLATMEM)
> +
> +struct page *realmode_pfn_to_page(unsigned long pfn)
> +{
> + struct page *page = pfn_to_page(pfn);
> + return page;
> +}
> +EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
> +
> +#endif /* CONFIG_SPARSEMEM_VMEMMAP/CONFIG_FLATMEM */
> +
> +#if defined(CONFIG_SPARSEMEM_VMEMMAP) || 

Re: [Patch v5 0/9] liblockdep: userspace lockdep

[Sasha Levin]

On 06/27/2013 09:55 AM, Sasha Levin wrote:

On 06/27/2013 05:07 AM, Ingo Molnar wrote:


* Sasha Levin  wrote:


On 06/26/2013 11:53 AM, Ingo Molnar wrote:

Ingo, I don't think I see anything holding this back; however I remember

reading some email about people not liking stuff like this living in the
tools/ directory or such.

Will you pick this up?

So I'd really be interested in how interesting/useful this is to userspace
developers? Does it work for something complex as Firefox, or Apache, to
the extent they make use of these locking APIs?


So far I've tested it on Firefox, Apache, QEMU, LKVM, GCC and random
smallish programs. I haven't really done full testing for each of those,
but just made sure that liblockdep behaves as it supposed to. I'm
guessing that with further work it will dig up actual issues.


The other issue is that with lock classes disabled you have to hit an
actual deadlock to trigger any output.

I.e. much of the power of lockdep is diminished :-/ When actual deadlocks
are triggered then it's not particularly complex to debug user-space apps:
gdb the hung task(s) and look at the backtraces.


Lock classes are disabled only if you're using the LD_PRELOAD method of
testing. If you actually re-compile your code with the library (by just
including the header and setting a #define to enable it) you will have
lock classes.


Hi Ingo,

Just wondering if you're planning on pushing it over to Linus from your tree,
or should I go ahead and do it on my own?


Thanks,
Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1] ia64/pci: set mmio decoding on for some host bridge

[Li, Zhen-Hua]

On some IA64 platforms with intel PCI bridge, for example, HP BL890c i2 
with  Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port,
when kernel tries to disable the mmio decoding on the PCI bridge devices,
kernel may crash. 

And in the comment of function quirk_mmio_always_on, it also says:
"But doing so (disable the mmio decoding) may cause problems on host bridge
 and perhaps other key system devices"

So, for these PCI bridges,  dev->mmio_always_on bit should be set to 1.


Signed-off-by: Li, Zhen-Hua 
---
 drivers/pci/quirks.c |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e85d230..24b8024 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -44,6 +44,21 @@ static void quirk_mmio_always_on(struct pci_dev *dev)
 DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_BRIDGE_HOST, 8, quirk_mmio_always_on);
 
+#ifdef CONFIG_IA64
+/*
+ * On some IA64 platforms, for some intel PCI bridge devices, for example,
+ * the Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port,
+ * disable the mmio decoding on these devices may cause system crash.
+ * So dev->mmio_always_on bit should be set to 1.
+ */
+static void quirk_mmio_on_intel_pcibridge(struct pci_dev *dev)
+{
+   dev->mmio_always_on = 1;
+}
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_ANY_ID, PCI_ANY_ID,
+   PCI_CLASS_BRIDGE_PCI, 8, quirk_mmio_on_intel_pcibridge);
+#endif
+
 /* The Mellanox Tavor device gives false positive parity errors
  * Mark this device with a broken_parity_status, to allow
  * PCI scanning code to "skip" this now blacklisted device.
-- 
1.7.10.4

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

Re: [Xen-devel] [PATCH v6 0/5] Xen/ACPI: support sleep state entering on hardware reduced systems

[Ben Guthro]

On Mon, Jul 1, 2013 at 7:48 AM, Ben Guthro  wrote:
> In version 3.4 acpi_os_prepare_sleep() got introduced in parallel with
> reduced hardware sleep support, and the two changes didn't get
> synchronized: The new code doesn't call the hook function (if so
> requested). Fix this, requiring a boolean parameter to be added to the
> hook function to distinguish "extended" from "legacy" sleep.
>
> This requires adjusting TXT, but the adjustments only go as far as
> failing the extended mode call (since, looking at the TXT interface,
> there doesn't even appear to be precautions to deal with that
> alternative interface).
>
> The hypervisor change underlying this is commit 62d1a69 ("ACPI: support
> v5 (reduced HW) sleep interface") on the master branch of
> git://xenbits.xen.org/xen.git.
>
> Signed-off-by: Jan Beulich 
> Signed-off-by: Ben Guthro 
> Cc: Richard L Maliszewski 
> Cc: Gang Wei 
> Cc: Shane Wang 
> Cc: Bob Moore 
> Cc: Rafael J. Wysocki 
> Cc: linux-a...@vger.kernel.org
> Cc: tboot-de...@lists.sourceforge.net
>
> v2: Extend description to include reference to hypervisor side change
> v3: Split into multiple patches, separating subsystems
> Remove bool parameters, in favor of u8
> v4: Remove linux/acpi.h dependencies
> Further patch split to break out acpica from OSL
> More bool vs u8 fixes
> v5: Fix build of consumers of acpi_os_prepare_sleep() interface change,
> so intermediate builds of partial patch series will not fail.
> v6: Rebased to linux-pm linux-next branch
> Added warning in tboot early return code
> Added Reviewed-by lines
>
> Ben Guthro (5):
>   acpi: Remove need to include linux/acpi.h in common acpica code
>   acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path
>   acpi/xen/tboot: Adjust linux acpi OS functions to new extended
> parameter
>   x86/tboot: Fail extended mode reduced hardware sleep
>   xen/acpi: notify xen when reduced hardware sleep is available

Rafael, Bob -

Is this version of the series something that you may consider taking?
If not - is there something specific you would like to see addressed?

Thanks for your time.


Ben

>
>  arch/x86/kernel/tboot.c  |9 -
>  drivers/acpi/acpica/hwesleep.c   |7 +++
>  drivers/acpi/acpica/hwsleep.c|3 +--
>  drivers/acpi/osl.c   |   16 
>  drivers/xen/acpi.c   |   26 +-
>  include/acpi/acpiosxf.h  |6 ++
>  include/linux/acpi.h |9 +++--
>  include/xen/acpi.h   |4 ++--
>  include/xen/interface/platform.h |7 ---
>  9 files changed, 52 insertions(+), 35 deletions(-)
>
> --
> 1.7.9.5
>
>
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> http://lists.xen.org/xen-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Jason Cooper]

On Sun, Jul 07, 2013 at 06:45:15PM +0200, Daniel Lezcano wrote:
> On 07/07/2013 05:30 PM, Thomas Gleixner wrote:
> > On Sun, 7 Jul 2013, Jason Cooper wrote:
> >> Sure, but to be clear, Daniel, please drop this patch from your tree.  I
> >> have no desire to create an out-of-tree dependency if we can avoid it.
> >> It has a habit of going horribly wrong [1].
> >>
> >> I'll cherry-pick
> >>
> >>   0c1dcfd clocksource: Add Marvell Orion SoC timer
> > 
> > Don't do that. Do a git fetch on that branch and then git merge
> > 0c1dcfd. The patches before that Marvel commit are already in Linus
> > tree. That way it does not matter who sends first or not.
> > 
> > We don't force others to drop stuff and cherry picking is a nuisance
> > as well as you end up with two different commits doing the same thing.
> > 
> > Also for the next merge window: Can we please let everything under
> > drivers/clocksoure go through Daniels and my trees?
> > 
> > I'm starting to be grumpy about anyone thinking that this directory is
> > a public dump ground with no rules.
> 
> Yes I agree. I will meet John this week and we will sort out this and
> define a clear set of rules to prevent that to happen again.

Oh god no!  The rules we have are fine.  "Defer to the appropriate
maintainer first."  Which I did (that's why the patch is in your tree
;-) ).  A mistake happened, and we're working together to find the best
solution.

The last thing we need is more bureaucratic crap.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / scan: Always call acpi_bus_scan() for bus check notifications

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the
entire namespace starting from the given handle even if the device
represented by that handle is present (other devices below it may
just have been added).

For this reason, modify acpi_scan_bus_device_check() to always run
acpi_bus_scan() if the notification being handled is of type
ACPI_NOTIFY_BUS_CHECK.

Signed-off-by: Rafael J. Wysocki 
Cc: 3.10+ 
---
 drivers/acpi/scan.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -353,10 +353,12 @@ static void acpi_scan_bus_device_check(a
mutex_lock(_scan_lock);
lock_device_hotplug();
 
-   acpi_bus_get_device(handle, );
-   if (device) {
-   dev_warn(>dev, "Attempt to re-insert\n");
-   goto out;
+   if (ost_source != ACPI_NOTIFY_BUS_CHECK) {
+   acpi_bus_get_device(handle, );
+   if (device) {
+   dev_warn(>dev, "Attempt to re-insert\n");
+   goto out;
+   }
}
acpi_evaluate_hotplug_ost(handle, ost_source,
  ACPI_OST_SC_INSERT_IN_PROGRESS, 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/

Re: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Jason Cooper]

On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Jason Cooper wrote:
> > Sure, but to be clear, Daniel, please drop this patch from your tree.  I
> > have no desire to create an out-of-tree dependency if we can avoid it.
> > It has a habit of going horribly wrong [1].
> > 
> > I'll cherry-pick
> > 
> >   0c1dcfd clocksource: Add Marvell Orion SoC timer
> 
> Don't do that. Do a git fetch on that branch and then git merge
> 0c1dcfd.

> The patches before that Marvel commit are already in Linus tree. That
> way it does not matter who sends first or not.

ahh, ok.  I see your point now, thanks.

Daniel, do you mind tagging that commit, eg 'mvebu-deps-3.12' or
similar?

> Also for the next merge window: Can we please let everything under
> drivers/clocksoure go through Daniels and my trees?

Of course, that's what I've been encouraging:

http://permalink.gmane.org/gmane.linux.ports.arm.kernel/242342

""" Using Thomas Petazzoni's quoting style here :)

Is there a reason why the following breakdown wouldn't work?

>  arch/arm/boot/dts/armada-370-xp.dtsi |   1 +
>  arch/arm/boot/dts/armada-370.dtsi|   1 +
>  arch/arm/boot/dts/armada-xp-mv78230.dtsi |   1 +
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi |   1 +
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi |   1 +

through mvebu/arm-soc

>  arch/arm/mach-mvebu/Kconfig  |   1 +

through mvebu/arm-soc after the other three have landed (v3.11-rc1)

>  drivers/irqchip/irq-armada-370-xp.c  | 186 
> ++-

through tglx

>  drivers/pci/host/pci-mvebu.c |  21 
>  drivers/pci/msi.c|  59 +-
>  drivers/pci/probe.c  |   1 +
>  include/linux/msi.h  |  22 
>  include/linux/pci.h  |   1 +

through Bjorn

I think we should view the manner in which we brought in the initial
mvebu-pcie series (all through arm-soc) as the exception, not the rule.
I have no problem, and in fact, prefer to have them reviewed as a
series, but if at *all* possible, the series should be structured so
relevant maintainers can pick up the relevant patches into their trees.

""" End quote

There's a delicate three-way balance between pushing patches that we
depend on to the appropriate maintainers, avoiding out-of-tree
dependencies for arm-soc, and keeping the ball moving.

I don't mind delaying half of a series so the drivers/ portion can land
in mainline, and the rest can land in the next cycle.  But when things
don't go according to that plan, I'd like a little consideration /
flexibility about solving the problem.  Especially considering I'm
*trying* to do the right thing by pushing to appropriate maintainers
first.

Of course, this is a moot point since, as you clarified above, this
dependency doesn't have the hazards typically associated with
out-of-tree dependencies.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] cpufreq: Add debugfs directory for cpufreq

[Chanwoo Choi]

Hi Pankaj,

On 07/08/2013 03:54 AM, Pankaj Jangra wrote:
> Hi Chanwoo,
> 
> On Fri, Jul 5, 2013 at 1:46 AM, Chanwoo Choi  wrote:
>> This patch create debugfs root directory and child directory according to
>> the number of CPUs for CPUFreq as below debugfs directory path:
>> - /sys/kernel/debug/cpufreq/cpuX
>>
>> If many CPUs share only one cpufreq policy, other CPU(except for CPU0) create
>> a link for debugfs directory of CPU0.
>> - /sys/kernel/debug/cpufreq/cpu0
>> - /sys/kernel/debug/cpufreq/cpu[1-(N-1)] -> /sys/kernel/debug/cpufreq/cpu0
>>
>> And then cpufreq may need to create debugfs specific file below of debugfs
>> directory of cpufreq. (e.g., /sys/kernel/debug/cpufreq/cpu0/load_table)
>>
>> Signed-off-by: Chanwoo Choi 
>> Signed-off-by: Kyungmin Park 
>> Signed-off-by: Myungjoo Ham 
>> ---
>>  drivers/cpufreq/cpufreq.c | 57 
>> +++
>>  include/linux/cpufreq.h   |  1 +
>>  2 files changed, 58 insertions(+)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 2d53f47..bc01c8e 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -23,6 +23,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -47,6 +48,10 @@ static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], 
>> cpufreq_cpu_governor);
>>  #endif
>>  static DEFINE_RWLOCK(cpufreq_driver_lock);
>>
>> +/* The cpufreq_debugfs is used to create debugfs root directory for 
>> CPUFreq. */
>> +#define MAX_DEBUGFS_NAME_LEN   CPUFREQ_NAME_LEN
>> +static struct dentry *cpufreq_debugfs;
>> +
>>  /*
>>   * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
>>   * all cpufreq/hotplug/workqueue/etc related lock issues.
>> @@ -726,6 +731,20 @@ static int cpufreq_add_dev_symlink(unsigned int cpu,
>> cpufreq_cpu_put(managed_policy);
>> return ret;
>> }
>> +
>> +   if (cpufreq_debugfs) {
>> +   char symlink_name[MAX_DEBUGFS_NAME_LEN];
>> +   char target_name[MAX_DEBUGFS_NAME_LEN];
>> +
>> +   sprintf(symlink_name, "cpu%d", j);
>> +   sprintf(target_name, "./cpu%d", cpu);
>> +   managed_policy->cpu_debugfs[j] = 
>> debugfs_create_symlink(
>> +   symlink_name,
>> +   cpufreq_debugfs,
>> +   target_name);
>> +   if (!managed_policy->cpu_debugfs[j])
>> +   pr_debug("creating debugfs symlink 
>> failed\n");
>> +   }
>> }
>> return ret;
>>  }
>> @@ -746,6 +765,22 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
>> if (ret)
>> return ret;
>>
>> +   /* prepare interface data for debugfs */
>> +   if (cpufreq_debugfs) {
>> +   char name[MAX_DEBUGFS_NAME_LEN];
>> +   int size, i;
>> +
>> +   sprintf(name, "cpu%d", policy->cpu);
>> +   size = sizeof(struct dentry*) * NR_CPUS;
>> +   i = cpu;
>> +
>> +   policy->cpu_debugfs = devm_kzalloc(dev, size, GFP_KERNEL);
>> +   policy->cpu_debugfs[i] = debugfs_create_dir(name,
>> +   cpufreq_debugfs);
>> +   if (!policy->cpu_debugfs[i])
>> +   pr_debug("creating debugfs directory failed\n");
>> +   }
>> +
>> /* set up files for this cpu device */
>> drv_attr = cpufreq_driver->attr;
>> while ((drv_attr) && (*drv_attr)) {
>> @@ -839,6 +874,20 @@ static int cpufreq_add_policy_cpu(unsigned int cpu, 
>> unsigned int sibling,
>> return ret;
>> }
>>
>> +   if (cpufreq_debugfs) {
>> +   char symlink_name[MAX_DEBUGFS_NAME_LEN];
>> +   char target_name[MAX_DEBUGFS_NAME_LEN];
>> +
>> +   sprintf(symlink_name, "cpu%d", cpu);
>> +   sprintf(target_name, "./cpu%d", sibling);
>> +   policy->cpu_debugfs[cpu] = debugfs_create_symlink(
>> +   symlink_name,
>> +   cpufreq_debugfs,
>> +   target_name);
>> +   if (!policy->cpu_debugfs[cpu])
>> +   pr_debug("creating debugfs symlink failed\n");
>> +   }
>> +
>> return 0;
>>  }
>>  #endif
>> @@ -1046,6 +1095,7 @@ static int __cpufreq_remove_dev(struct device *dev, 
>> struct subsys_interface *sif
>>
>> if (cpu != data->cpu) {
>> sysfs_remove_link(>kobj, "cpufreq");
>> +   debugfs_remove(data->cpu_debugfs[cpu]);
> 
> I think you should add the call to remove the "cpufreq" also ???

No, we have to remove 'cpufreq' 

Re: [PATCH for 3.2] memcg: do not trap chargers with full callstack on OOM

[azurIt]

> CC: "Michal Hocko" , linux-kernel@vger.kernel.org, 
> linux...@kvack.org, "cgroups mailinglist" , 
> "KAMEZAWA Hiroyuki" 
>On Fri, Jul 05, 2013 at 09:02:46PM +0200, azurIt wrote:
>> >I looked at your debug messages but could not find anything that would
>> >hint at a deadlock.  All tasks are stuck in the refrigerator, so I
>> >assume you use the freezer cgroup and enabled it somehow?
>> 
>> 
>> Yes, i'm really using freezer cgroup BUT i was checking if it's not
>> doing problems - unfortunately, several days passed from that day
>> and now i don't fully remember if i was checking it for both cases
>> (unremoveabled cgroups and these freezed processes holding web
>> server port). I'm 100% sure i was checking it for unremoveable
>> cgroups but not so sure for the other problem (i had to act quickly
>> in that case). Are you sure (from stacks) that freezer cgroup was
>> enabled there?
>
>Yeah, all the traces without exception look like this:
>
>1372089762/23433/stack:[] refrigerator+0x95/0x160
>1372089762/23433/stack:[] get_signal_to_deliver+0x1cb/0x540
>1372089762/23433/stack:[] do_signal+0x6b/0x750
>1372089762/23433/stack:[] do_notify_resume+0x55/0x80
>1372089762/23433/stack:[] int_signal+0x12/0x17
>1372089762/23433/stack:[] 0x
>
>so the freezer was already enabled when you took the backtraces.
>
>> Btw, what about that other stacks? I mean this file:
>> http://watchdog.sk/lkml/memcg-bug-7.tar.gz
>> 
>> It was taken while running the kernel with your patch and from
>> cgroup which was under unresolveable OOM (just like my very original
>> problem).
>
>I looked at these traces too, but none of the tasks are stuck in rmdir
>or the OOM path.  Some /are/ in the page fault path, but they are
>happily doing reclaim and don't appear to be stuck.  So I'm having a
>hard time matching this data to what you otherwise observed.
>
>However, based on what you reported the most likely explanation for
>the continued hangs is the unfinished OOM handling for which I sent
>the followup patch for arch/x86/mm/fault.c.
>



Johannes,

today I tested both of your patches but problem with unremovable cgroups, 
unfortunately, persists.

azur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI / ACPI cleanups

[Rafael J. Wysocki]

Hi,

These two patches clean up the ACPI part of the PCI core and ACPIPHP.

[1/2] Make bus registration and unregistration symmetric.
[2/2] Consolidate acpiphp_enumerate_slots().

They are on top of 3.10 plus my 3.11 queue (should apply on plain 3.10),
but if they look good, I'll add them to the previous ACPI dock cleanups.

Thanks,
Rafael


-- 
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 2/2] ACPI / PCI: Consolidate acpiphp_enumerate_slots()

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The acpiphp_enumerate_slots() function is now split into two parts,
acpiphp_enumerate_slots() proper and init_bridge_misc() which is
only called by the former.  If these functions are combined,
it is possible to make the code easier to follow and to clean up
the error handling (to prevent memory leaks on error from
happening in particular), so do that.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/pci/hotplug/acpiphp_glue.c |   94 ++---
 1 file changed, 46 insertions(+), 48 deletions(-)

Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -363,46 +363,6 @@ static int detect_ejectable_slots(acpi_h
return found;
 }
 
-/* initialize miscellaneous stuff for both root and PCI-to-PCI bridge */
-static void init_bridge_misc(struct acpiphp_bridge *bridge)
-{
-   acpi_status status;
-
-   /* must be added to the list prior to calling register_slot */
-   mutex_lock(_mutex);
-   list_add(>list, _list);
-   mutex_unlock(_mutex);
-
-   /* register all slot objects under this bridge */
-   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, bridge->handle, (u32)1,
-register_slot, NULL, bridge, NULL);
-   if (ACPI_FAILURE(status)) {
-   mutex_lock(_mutex);
-   list_del(>list);
-   mutex_unlock(_mutex);
-   return;
-   }
-
-   /* install notify handler for P2P bridges */
-   if (!pci_is_root_bus(bridge->pci_bus)) {
-   if ((bridge->flags & BRIDGE_HAS_EJ0) && bridge->func) {
-   status = 
acpi_remove_notify_handler(bridge->func->handle,
-   ACPI_SYSTEM_NOTIFY,
-   handle_hotplug_event_func);
-   if (ACPI_FAILURE(status))
-   err("failed to remove notify handler\n");
-   }
-   status = acpi_install_notify_handler(bridge->handle,
-ACPI_SYSTEM_NOTIFY,
-handle_hotplug_event_bridge,
-bridge);
-
-   if (ACPI_FAILURE(status)) {
-   err("failed to register interrupt notify handler\n");
-   }
-   }
-}
-
 
 /* find acpiphp_func from acpiphp_bridge */
 static struct acpiphp_func *acpiphp_bridge_handle_to_function(acpi_handle 
handle)
@@ -1171,8 +1131,9 @@ static void handle_hotplug_event_func(ac
  */
 void acpiphp_enumerate_slots(struct pci_bus *bus)
 {
-   acpi_handle handle, dummy_handle;
struct acpiphp_bridge *bridge;
+   acpi_handle handle;
+   acpi_status status;
 
if (acpiphp_disabled)
return;
@@ -1200,15 +1161,52 @@ void acpiphp_enumerate_slots(struct pci_
 */
get_device(>dev);
 
-   if (!pci_is_root_bus(bridge->pci_bus) &&
-   ACPI_SUCCESS(acpi_get_handle(bridge->handle,
-   "_EJ0", _handle))) {
-   dbg("found ejectable p2p bridge\n");
-   bridge->flags |= BRIDGE_HAS_EJ0;
-   bridge->func = acpiphp_bridge_handle_to_function(handle);
+   /* must be added to the list prior to calling register_slot */
+   mutex_lock(_mutex);
+   list_add(>list, _list);
+   mutex_unlock(_mutex);
+
+   /* register all slot objects under this bridge */
+   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, bridge->handle, 1,
+register_slot, NULL, bridge, NULL);
+   if (ACPI_FAILURE(status)) {
+   acpi_handle_err(bridge->handle, "failed to register slots\n");
+   goto err;
}
 
-   init_bridge_misc(bridge);
+   if (pci_is_root_bus(bridge->pci_bus))
+   return;
+
+   /* install notify handler for P2P bridges */
+   status = acpi_install_notify_handler(bridge->handle, ACPI_SYSTEM_NOTIFY,
+handle_hotplug_event_bridge,
+bridge);
+   if (ACPI_FAILURE(status)) {
+   acpi_handle_err(bridge->handle,
+   "failed to register notify handler\n");
+   goto err;
+   }
+
+   status = acpi_get_handle(bridge->handle, "_EJ0", );
+   if (ACPI_FAILURE(status))
+   return;
+
+   dbg("found ejectable p2p bridge\n");
+   bridge->flags |= BRIDGE_HAS_EJ0;
+   bridge->func = acpiphp_bridge_handle_to_function(bridge->handle);
+   if (bridge->func) {
+   status = acpi_remove_notify_handler(bridge->func->handle,
+   ACPI_SYSTEM_NOTIFY,
+   

[PATCH 1/2] ACPI / PCI: Make bus registration and unregistration symmetric

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Since acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() can get
the ACPI device handle they need from bus->bridge, it is not
necessary to pass that handle to them as an argument.

Drop the second argument of acpi_pci_slot_enumerate() and
acpiphp_enumerate_slots(), rework them to obtain the ACPI handle
from bus->bridge and make acpi_pci_add_bus() and
acpi_pci_remove_bus() entirely symmetrical.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/pci_slot.c|   14 +-
 drivers/pci/hotplug/acpiphp_glue.c |7 ---
 drivers/pci/pci-acpi.c |   16 
 include/linux/pci-acpi.h   |   10 --
 4 files changed, 21 insertions(+), 26 deletions(-)

Index: linux-pm/drivers/acpi/pci_slot.c
===
--- linux-pm.orig/drivers/acpi/pci_slot.c
+++ linux-pm/drivers/acpi/pci_slot.c
@@ -159,12 +159,16 @@ register_slot(acpi_handle handle, u32 lv
return AE_OK;
 }
 
-void acpi_pci_slot_enumerate(struct pci_bus *bus, acpi_handle handle)
+void acpi_pci_slot_enumerate(struct pci_bus *bus)
 {
-   mutex_lock(_list_lock);
-   acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
-   register_slot, NULL, bus, NULL);
-   mutex_unlock(_list_lock);
+   acpi_handle handle = ACPI_HANDLE(bus->bridge);
+
+   if (handle) {
+   mutex_lock(_list_lock);
+   acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
+   register_slot, NULL, bus, NULL);
+   mutex_unlock(_list_lock);
+   }
 }
 
 void acpi_pci_slot_remove(struct pci_bus *bus)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -1169,15 +1169,16 @@ static void handle_hotplug_event_func(ac
  * Create hotplug slots for the PCI bus.
  * It should always return 0 to avoid skipping following notifiers.
  */
-void acpiphp_enumerate_slots(struct pci_bus *bus, acpi_handle handle)
+void acpiphp_enumerate_slots(struct pci_bus *bus)
 {
-   acpi_handle dummy_handle;
+   acpi_handle handle, dummy_handle;
struct acpiphp_bridge *bridge;
 
if (acpiphp_disabled)
return;
 
-   if (detect_ejectable_slots(handle) <= 0)
+   handle = ACPI_HANDLE(bus->bridge);
+   if (!handle || detect_ejectable_slots(handle) <= 0)
return;
 
bridge = kzalloc(sizeof(struct acpiphp_bridge), GFP_KERNEL);
Index: linux-pm/drivers/pci/pci-acpi.c
===
--- linux-pm.orig/drivers/pci/pci-acpi.c
+++ linux-pm/drivers/pci/pci-acpi.c
@@ -290,24 +290,16 @@ static struct pci_platform_pm_ops acpi_p
 
 void acpi_pci_add_bus(struct pci_bus *bus)
 {
-   acpi_handle handle = NULL;
-
-   if (bus->bridge)
-   handle = ACPI_HANDLE(bus->bridge);
-   if (acpi_pci_disabled || handle == NULL)
+   if (acpi_pci_disabled || !bus->bridge)
return;
 
-   acpi_pci_slot_enumerate(bus, handle);
-   acpiphp_enumerate_slots(bus, handle);
+   acpi_pci_slot_enumerate(bus);
+   acpiphp_enumerate_slots(bus);
 }
 
 void acpi_pci_remove_bus(struct pci_bus *bus)
 {
-   /*
-* bus->bridge->acpi_node.handle has already been reset to NULL
-* when acpi_pci_remove_bus() is called, so don't check ACPI handle.
-*/
-   if (acpi_pci_disabled)
+   if (acpi_pci_disabled || !bus->bridge)
return;
 
acpiphp_remove_slots(bus);
Index: linux-pm/include/linux/pci-acpi.h
===
--- linux-pm.orig/include/linux/pci-acpi.h
+++ linux-pm/include/linux/pci-acpi.h
@@ -47,24 +47,22 @@ void acpi_pci_remove_bus(struct pci_bus
 
 #ifdef CONFIG_ACPI_PCI_SLOT
 void acpi_pci_slot_init(void);
-void acpi_pci_slot_enumerate(struct pci_bus *bus, acpi_handle handle);
+void acpi_pci_slot_enumerate(struct pci_bus *bus);
 void acpi_pci_slot_remove(struct pci_bus *bus);
 #else
 static inline void acpi_pci_slot_init(void) { }
-static inline void acpi_pci_slot_enumerate(struct pci_bus *bus,
-  acpi_handle handle) { }
+static inline void acpi_pci_slot_enumerate(struct pci_bus *bus) { }
 static inline void acpi_pci_slot_remove(struct pci_bus *bus) { }
 #endif
 
 #ifdef CONFIG_HOTPLUG_PCI_ACPI
 void acpiphp_init(void);
-void acpiphp_enumerate_slots(struct pci_bus *bus, acpi_handle handle);
+void acpiphp_enumerate_slots(struct pci_bus *bus);
 void acpiphp_remove_slots(struct pci_bus *bus);
 void acpiphp_check_host_bridge(acpi_handle handle);
 #else
 static inline void acpiphp_init(void) { }
-static inline void acpiphp_enumerate_slots(struct pci_bus *bus,
-  acpi_handle handle) { }
+static inline 

[PATCH] net: mv643xx_eth: do not use port number as platform device id

[Jonas Gorski]

The port number is only local to the ethernet block, not global, so
there can be two ethernet blocks both using the same port, like
kirkwood with both using port 0.

Fix this by using the array index offset for the allocated platform
devices as the id.

Signed-off-by: Jonas Gorski 
---
 drivers/net/ethernet/marvell/mv643xx_eth.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 6495bea..c35db73 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2483,6 +2483,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
struct resource res;
const char *mac_addr;
int ret;
+   int dev_num = 0;
 
memset(, 0, sizeof(ppd));
ppd.shared = pdev;
@@ -2503,6 +2504,14 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
return -EINVAL;
}
 
+   while (dev_num < 3 && port_platdev[dev_num])
+   dev_num++;
+
+   if (dev_num == 3) {
+   dev_err(>dev, "too many ports registered\n");
+   return -EINVAL;
+   }
+
mac_addr = of_get_mac_address(pnp);
if (mac_addr)
memcpy(ppd.mac_addr, mac_addr, 6);
@@ -2521,7 +2530,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
of_property_read_u32(pnp, "duplex", );
}
 
-   ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
+   ppdev = platform_device_alloc(MV643XX_ETH_NAME, dev_num);
if (!ppdev)
return -ENOMEM;
ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -2538,7 +2547,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
if (ret)
goto port_err;
 
-   port_platdev[ppd.port_number] = ppdev;
+   port_platdev[dev_num] = ppdev;
 
return 0;
 
-- 
1.8.3.2

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

Re: [GIT] Networking

[Linus Torvalds]

On Sun, Jul 7, 2013 at 2:27 PM, Linus Torvalds
 wrote:
>
> Because quite frankly, the fs/select.c changes make me go: "No way in
> hell". Partly because of the idiotic and completely undescriptive
> naming, partly because of the disgisting calling convetions with
> random flags variables passed in to be changed be helper functions.

Actually, I take that second one back. I mis-read things.

So I would suggest fixing this by:

 - get rid of all those idiotic "ll" things. They describe nothing at
all, and code like this

if (ll_flag && can_ll && can_poll_ll(ll_start, ll_time))

   should have made anybody sane go "WTF?" and wonder about bad drugs.
Seriously, I'm disappointed code like this reaches me. In some random
driver I can see bad naming conventions like this, but in the core
kernel? We should have better taste.

 - talk about what it is, not short-hand. The "ll" stands for "low
latency", but that makes it sound all good. Make it describe what it
actually does: "busy loop", and write it out. So that people
understand what the actual downsides are. We're not a marketing group.
People shouldn't go "Oh, I like low-latency select(), I'll set that
latency value to 100usec". It should damn well be clear that this
enables BUSY LOOPING.

   So no POLL_LL crap. Call it POLL_BUSY_LOOP. Make everybody aware of
what it actually does.

 - Stop the marketing crap #2:

"Recommended value is 50. May increase power usage"

   WTF? The default value is 0. Not 50. And I think "May increase
power usage" is the lie of the century. I don't see that there is any
"may" about it. Since when did we sugar-coat things?

 - I was confused by that whole ll_flag vs can_ll thing. "can_ll" is
not about whether we "can", it's actually "should_busy_loop", and
about whether we *should* busy loop. And to mention that nasty "lots
of nonsensical ll" line again:

if (ll_flag && can_ll && can_poll_ll(ll_start, ll_time))

   that doesn't make much sense. If ll_flag isn't set, then can_ll
shouldn't have been set either, so why are we testing both values? And
because the code is mixing booleans with that mask, it's all
unnecessarily complicated in general. We'd be much better off having
"can_ll" be a mask value, and (along with renaming) we'd have

unsigned int should_busy_loop = 0;
...
should_busy_loop != mask & busy_loop_flag;

which does it all without conditionals, just by making the types
simpler. And then remove that "ll_flag && can_ll &&" which should be
just pointless, replacing it with just testing "should_busy_loop".

(That "can_poll_ll" and ll_start/ll_time should obviously *also* get
fixed naming-wise)

Finally, there is NO WAY IN HELL that busy-looping is ok if
need_resched is set. So this code also needs to make it very very
clear that it tests "current->need_resched" before busy-looping
anything at all.

End result: I think the code is salvageable and people who want this
kind of busy-looping can have it. But I really don't want to merge it
as-is. I think it was badly done, I think it was badly documented, and
I think somebody over-sold the feature by emphasizing the upsides and
not the problems.

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

Fwd: BUG: key ffff880c1148c478 not in .data! (V3.10.0)

[Linda Walsh]

Also am seeing this for the first time:

(don't know, but seems unlikely to be related to
https://patchwork.kernel.org/patch/87359/
Yet it is the only hit I found for the same message.


Looks like it's back to a more stable 3.9.8...
(*sigh*)


BUG: key 880c1148c478 not in .data!
[4.429474] [ cut here ]
[4.434236] WARNING: at kernel/lockdep.c:2987 
lockdep_init_map+0x45e/0x490()

[4.441414] DEBUG_LOCKS_WARN_ON(1)
[4.444684] Modules linked in:
[4.448168] usb 1-3.2: new low-speed USB device number 3 using ehci-pci
[4.454975] CPU: 10 PID: 1 Comm: swapper/0 Tainted: G  I  
3.10.0-Isht-Van #1
[4.462862] Hardware name: Dell Inc. PowerEdge T610/0CX0R0, BIOS 
6.3.0 07/24/2012
[4.470475]  0009 880c13175a70 815bb279 
880c13175aa8
[4.478221]  8104641c 880c11c12130 880c1148c478 

[4.485988]  880c11c12058 880c12386180 880c13175b08 
81046487

[4.493800] Call Trace:
[4.496472]  [] dump_stack+0x19/0x1b
[4.501776]  [] warn_slowpath_common+0x5c/0x80
[4.507917]  [] warn_slowpath_fmt+0x47/0x50
[4.513790]  [] lockdep_init_map+0x45e/0x490
[4.519775]  [] debug_mutex_init+0x2d/0x40
[4.525567]  [] __mutex_init+0x51/0x60
[4.531017]  [] bus_register+0x158/0x2c0
[4.536646]  [] edac_create_sysfs_mci_device+0x53/0x540
[4.542512] usb 1-3.2: New USB device found, idVendor=413c, 
idProduct=2003
[4.542513] usb 1-3.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0

[4.542514] usb 1-3.2: Product: Dell USB Keyboard
[4.542515] usb 1-3.2: Manufacturer: Dell
[4.567013]  [] edac_mc_add_mc+0x103/0x270
[4.572804]  [] i7core_probe+0x530/0xe70
[4.578435]  [] local_pci_probe+0x39/0x70
[4.584136]  [] pci_device_probe+0x111/0x120
[4.590107]  [] driver_probe_device+0x71/0x230
[4.596251]  [] __driver_attach+0x8b/0x90
[4.601955]  [] ? __device_attach+0x40/0x40
[4.607836]  [] bus_for_each_dev+0x63/0xa0
[4.613625]  [] driver_attach+0x19/0x20
[4.619167]  [] bus_add_driver+0x1d8/0x270
[4.624963]  [] driver_register+0x6c/0x150
[4.630756]  [] __pci_register_driver+0x58/0x60
[4.636990]  [] ? edac_init+0x67/0x67
[4.642343]  [] i7core_init+0x38/0xb7
[4.647702]  [] ? edac_init+0x67/0x67
[4.653065]  [] do_one_initcall+0xfa/0x150
[4.658859]  [] kernel_init_freeable+0x15a/0x1da
[4.665176]  [] ? do_early_param+0x88/0x88
[4.673917]  [] ? rest_init+0xd0/0xd0
[4.679278]  [] kernel_init+0x9/0x180
[4.684640]  [] ret_from_fork+0x7c/0xb0
[4.690174]  [] ? rest_init+0xd0/0xd0
[4.695534] ---[ end trace 9ddab1480c5d91dc ]---
[4.700444] EDAC MC1: Giving out device to 'i7core_edac.c' 'i7 core 
#1': DEV :fe:03.0
[4.708791] EDAC PCI0: Giving out device to module 'i7core_edac' 
controller 'EDAC PCI controller': DEV ':fe:03.0' (POLLED)

[4.720714] BUG: key 880c11a1c478 not in .data!




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mv643xx_eth: fix DT port device name

[Jonas Gorski]

On Sun, 7 Jul 2013 23:43:41 +0200
Jonas Gorski  wrote:

> On Sun,  7 Jul 2013 22:33:51 +0200
> Sebastian Hesselbarth  wrote:
> 
> > Device tree support added to Marvell MV643xx ethernet driver registers
> > port devices from port device nodes found on the corresponding controller
> > node. The current port device name will cause the second controller to
> > fail on registration because of two identical device names. This fixes
> > the issue by taking the device node's name also as port device name.
> > 
> > Signed-off-by: Sebastian Hesselbarth 
> > Reported-by: Jonas Gorski 
> > ---
> > Cc: Lennert Buytenhek 
> > Cc: Jonas Gorski 
> > Cc: net...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >  drivers/net/ethernet/marvell/mv643xx_eth.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
> > b/drivers/net/ethernet/marvell/mv643xx_eth.c
> > index 6495bea..1f3a03d 100644
> > --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> > +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> > @@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
> > platform_device *pdev,
> > of_property_read_u32(pnp, "duplex", );
> > }
> >  
> > -   ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
> > +   ppdev = platform_device_alloc(pnp->name, ppd.port_number);
> > if (!ppdev)
> > return -ENOMEM;
> > ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> 
> This breaks ethernet completely, as there is no platform driver
> registered for pnp->name ("ethernetX-port"), only for MV643XX_ETH_NAME.

Looking back at our conversation, this is my fault.
I actually did not change this part as you asked, but I saw the
alloc/del issue with port 0, then added the counter and also only
replaced the ppd.port_number in the alloc with it. I had completely
forgotten at that time to replace the device name; else I would
have caught it back then.

I only caught it now because I tried your patch and wondered why there
wasn't anything registered, not because I saw the problem by review.

Sorry for that.

Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mv643xx_eth: fix DT port device name

[Sebastian Hesselbarth]

On 07/07/2013 11:43 PM, Jonas Gorski wrote:

On Sun,  7 Jul 2013 22:33:51 +0200
Sebastian Hesselbarth  wrote:


Device tree support added to Marvell MV643xx ethernet driver registers
port devices from port device nodes found on the corresponding controller
node. The current port device name will cause the second controller to
fail on registration because of two identical device names. This fixes
the issue by taking the device node's name also as port device name.

Signed-off-by: Sebastian Hesselbarth
Reported-by: Jonas Gorski
---
Cc: Lennert Buytenhek
Cc: Jonas Gorski
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
  drivers/net/ethernet/marvell/mv643xx_eth.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 6495bea..1f3a03d 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
of_property_read_u32(pnp, "duplex",);
}

-   ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
+   ppdev = platform_device_alloc(pnp->name, ppd.port_number);
if (!ppdev)
return -ENOMEM;
ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);


This breaks ethernet completely, as there is no platform driver
registered for pnp->name ("ethernetX-port"), only for MV643XX_ETH_NAME.


Jonas,

I asked you to test the above earlier today. You said this would fix
the issue. I have no Kirkwood board with two ethernet's available, so
I really needed on your help here.

Please prepare a patch yourself, that fixes the issue.

Sebastian


Also since I didn't see a patch for it and no mentioning of it:

There's still one further issue from having two ethernet-ports with
port_number 0, it causes a device leak:

static struct platform_device *port_platdev[3];

mv643xx_eth_shared_of_add_port()
{
...
port_platdev[ppd.port_number] = ppdev;
...
}

The second port at 0 will overwrite the first and thus will never be
deleted in

mv643xx_eth_shared_of_remove()
{
...
for (n = 0; n<  3; n++) {
platform_device_del(port_platdev[n]);
port_platdev[n] = NULL;
}
}

I doubt a insmod-rmmod-insmod will go well in that case ;-)


Regards
Jonas


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

Disabling interrupt remapping seems to cause 50% drop in ethernet speed (v3.10)

[Linda Walsh]

There seems to be a new check :


   Comments

Neil Horman  - April 15, 2013, 4:28 p.m.

A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf

For the 5520 and 5500 chipsets which contained an errata (specificially errata
53), which noted that these chipsets can't properly do interrupt remapping, and
as a result the recommend that interrupt remapping be disabled in bios.  While
many vendors have a bios update to do exactly that, not all do, and of course
not all users update their bios to a level that corrects the problem.  As a
result, occasionally interrupts can arrive at a cpu even after affinity for that
interrupt has be moved, leading to lost or spurrious interrupts (usually
characterized by the message:
kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)

There have been several incidents recently of people seeing this error, and
investigation has shown that they have system for which their BIOS level is such
that this feature was not properly turned off.  As such, it would be good to
give them a reminder that their systems are vulnurable to this problem.  For
details of those that reported the problem, please see:
https://bugzilla.redhat.com/show_bug.cgi?id=887006

Signed-off-by: Neil Horman 
CC: Prarit Bhargava 
CC: Don Zickus 
CC: Don Dutile 
CC: Bjorn Helgaas 
CC: Asit Mallick 
CC: David Woodhouse 
CC: linux-...@vger.kernel.org
CC: Joerg Roedel 
CC: Konrad Rzeszutek Wilk 


That causes a >=50% drop in receive performance on
ethernet file transfers (with the linux machine being
receiving a file)... Sending doesn't appear to be affected.

Is the above error message "No irq handler for vector" the only
error message I would see if I suffered from this bug?

I looked through message logs going back to 2012-01-27 and found 0 
of those messages.  I do have the part that that is claimed to be affected.


I've been using interrupt affinity /steering (not irqbalancing) to put
ethernet interrupts for this interface on a specific cpu, keeping
the file server for that interface on the same cpu as well as keeping
other HW interrupts off of that node.


Without the remapping, I am finding 50% or greater drop in receive speed,
yet with the remapping, I am not finding the error indicated above.

It is possible I don't see the interrupt because I don't dynamically
changed affinity after it is initialized -- dunno.  According to the
report this shouldn't be the case.  If the above error message is the
symptom, I'd think I'd see it in 2 years of logs.

Is there a way to disable this short of reverting the patch?




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mv643xx_eth: fix DT port device name

[Jonas Gorski]

On Sun,  7 Jul 2013 22:33:51 +0200
Sebastian Hesselbarth  wrote:

> Device tree support added to Marvell MV643xx ethernet driver registers
> port devices from port device nodes found on the corresponding controller
> node. The current port device name will cause the second controller to
> fail on registration because of two identical device names. This fixes
> the issue by taking the device node's name also as port device name.
> 
> Signed-off-by: Sebastian Hesselbarth 
> Reported-by: Jonas Gorski 
> ---
> Cc: Lennert Buytenhek 
> Cc: Jonas Gorski 
> Cc: net...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/net/ethernet/marvell/mv643xx_eth.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
> b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 6495bea..1f3a03d 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
> platform_device *pdev,
>   of_property_read_u32(pnp, "duplex", );
>   }
>  
> - ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
> + ppdev = platform_device_alloc(pnp->name, ppd.port_number);
>   if (!ppdev)
>   return -ENOMEM;
>   ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);

This breaks ethernet completely, as there is no platform driver
registered for pnp->name ("ethernetX-port"), only for MV643XX_ETH_NAME.

Also since I didn't see a patch for it and no mentioning of it:

There's still one further issue from having two ethernet-ports with
port_number 0, it causes a device leak:

static struct platform_device *port_platdev[3];

mv643xx_eth_shared_of_add_port()
{
...
port_platdev[ppd.port_number] = ppdev;
...
}

The second port at 0 will overwrite the first and thus will never be
deleted in

mv643xx_eth_shared_of_remove()
{
...
for (n = 0; n < 3; n++) {
platform_device_del(port_platdev[n]);
port_platdev[n] = NULL;
}
}

I doubt a insmod-rmmod-insmod will go well in that case ;-)


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

Re: [GIT PULL] slave-dmaengine updates

[Linus Torvalds]

On Sat, Jul 6, 2013 at 9:17 PM, Vinod Koul  wrote:
>
> Once you have some time from extended weekend celebrations please consider
> pulling the following to get:
> - Various fixes and PCI driver for dw_dmac by Andy
> - DT binding for imx-dma by Markus & imx-sdma by Shawn
> - DT fixes for dmaengine by Lars
> - jz4740 dmac driver by Lars
> - and various fixes across the drivers

Sadly, I noticed much too late that I should have checked the
time-stamps on this too. Almost all of the commits seem to have been
rebased recently. Not quite minutes before the pull request, but 90%
of the commits seem to have been created long after the merge window
opened.

I have already pushed this out so it's too late now, but if I had
noticed earlier I would have rejected this pull too.

Today has not been a good day for pulling. If it wasn't for the
__cpuinit removal pull, I wouldn't have had *anything* today that did
things properly.

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

Re: [GIT PULL] 9p changes for 3.11 merge window (part 1)

[Linus Torvalds]

On Sun, Jul 7, 2013 at 12:39 PM, Eric Van Hensbergen  wrote:
> The following changes since commit c1be5a5b1b355d40e6cf79cc979eb66dafa24ad1:
>
>   Linux 3.9 (2013-04-28 17:36:01 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git
> tags/9p-for-3.11-merge-window-part-1

What the F*CK is wrong with people?

This is the second pull request in minutes that I'm going to have to
reject, this time because all the commits were apparently rebased just
minutes before sending me the pull request. So it clearly hasn't
gotten any testing, and hasn't been in next.

Why? No explanation, no nothing.

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

Re: [GIT] Networking

[Linus Torvalds]

On Sun, Jul 7, 2013 at 1:21 PM, David Miller  wrote:
>
> 5) arch/arm/mach-mxs/Kconfig
>
>Overlapping additions of select statements for SOC_IMX2.

Nope. Removals.

> 6) arch/arm/mach-mxs/mach-mxs.c
>
>In mxs_machine_init(), the of_platform_populate() call has it's final
>two arguments changed to be NULL.

Hmm. That's not how I read it. The next-to-last argument in changed to
NULL in one branch, the other adds "parent".

> 11) fs/select.c
>
> Overlapping additions of include directives, keep both.

This LL_POLL thing is ugly as hell. Where was this discussed?
Apparently on lkml without talking to people who are actually involved
in select/poll.

I'm not at all sure I want to pull this kind of crap without having
seen the full discussion, and the performance numbers are kind of
pointless without also talking about CPU utilization etc. Since when
is it ok to start doing things like this without any acks from anybody
else?

Because quite frankly, the fs/select.c changes make me go: "No way in
hell". Partly because of the idiotic and completely undescriptive
naming, partly because of the disgisting calling convetions with
random flags variables passed in to be changed be helper functions.

So no, I'm not pulling this. Things like this need discussion and
heads-up, not just random "let's add completely ugly things to core
kernel functionality without even asking people".

Even the commit messages in question are just PURE AND UTTER CRAP. Ask
yourself honestly what the F*CK this means:

  net: convert lls to use time_in_range

what the hell, David? What diseased mind uses idiotic short-hand like
this that makes no sense? And dammit, I'd expect the VFS people to be
cc'd on changes to the VFS layer functions. I wasn't, Al wasn't.

So not pulled. Fix up this mess.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] swap: warn when a swap area overflows the maximum size

[Raymond Jennings]

Screwed up and didn't attach my fixed test log to the second version.

See below.

On Sun, 2013-07-07 at 15:31 -0400, Rik van Riel wrote:
> On 07/07/2013 03:13 PM, Raymond Jennings wrote:
> > Turned the comparison around for clarity of "bigger than"
> >
> > No semantic changes, if it still compiles it should do the same thing so
> > I've omitted the testing this time.  Will be happy to retest if required
> > but I'm on an atom 330 and kernel rebuilds are a nightmare.
> 
> Added CC: Andrew Morton, since this should probably go into -mm :)
> 
> > 
> >
> > swap: warn when a swap area overflows the maximum size
> >
> > It is possible to swapon a swap area that is too big for the pte width
> > to handle.
> >
> > Presently this failure happens silently.
> >
> > Instead, emit a diagnostic to warn the user.
> >
> > Signed-off-by: Raymond Jennings 
> > Acked-by: Valdis Kletnieks 
> 
> Reviewed-by: Rik van Riel 
> 
> > diff --git a/mm/swapfile.c b/mm/swapfile.c
> > index 36af6ee..5a4ce53 100644
> > --- a/mm/swapfile.c
> > +++ b/mm/swapfile.c
> > @@ -1953,6 +1953,12 @@ static unsigned long read_swap_header(struct
> > swap_info_struct *p,
> >   */
> >  maxpages = swp_offset(pte_to_swp_entry(
> >  swp_entry_to_pte(swp_entry(0, ~0UL + 1;
> > +   if (swap_header->info.last_page > maxpages) {
> > +   printk(KERN_WARNING
> > +  "Truncating oversized swap area, only using %luk
> > out of %luk
> > \n",
> > +  maxpages << (PAGE_SHIFT - 10),
> > +  swap_header->info.last_page << (PAGE_SHIFT -
> > 10));
> > +   }
> >  if (maxpages > swap_header->info.last_page) {
> >  maxpages = swap_header->info.last_page + 1;
> >  /* p->max is an unsigned int: don't overflow it */
> >
> > 
> >
> > Testing results, root prompt commands and kernel log messages:
> >
> > # lvresize /dev/system/swap --size 16G
> > # mkswap /dev/system/swap
> > # swapon /dev/system/swap
> >
> > Jul  7 04:27:22 warfang kernel: Adding 16777212k swap
> > on /dev/mapper/system-swap.  Priority:-1 extents:1 across:16777212k
> >
> > # lvresize /dev/system/swap --size 16G

On Sun, 2013-07-07 at 04:52 -0700, Raymond Jennings wrote:
> # lvresize /dev/system/swap --size 16G

Typo in the second test.

The first line should read:

# lvresize /dev/system/swap --size 64G

First ever serious patch, got excited and burned the copypasta.

> # mkswap /dev/system/swap
> # swapon /dev/system/swap

> > # mkswap /dev/system/swap
> > # swapon /dev/system/swap
> >
> > Jul  7 04:27:22 warfang kernel: Truncating oversized swap area, only
> > using 33554432k out of 67108860k
> > Jul  7 04:27:22 warfang kernel: Adding 33554428k swap
> > on /dev/mapper/system-swap.  Priority:-1 extents:1 across:33554428k
> >
> >
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf: free original memory on realloc failure in str_append

[David Ahern]

str_append was added in 578d9c6. If realloc fails orignal block is
not freed. Need to save the original pointer to handle on failure.

Signed-off-by: David Ahern 
Cc: Andi Kleen 
---
 tools/perf/util/string.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/string.c b/tools/perf/util/string.c
index f0b0c00..53bca50 100644
--- a/tools/perf/util/string.c
+++ b/tools/perf/util/string.c
@@ -398,13 +398,20 @@ int str_append(char **s, int *len, const char *a)
 {
int olen = *s ? strlen(*s) : 0;
int nlen = olen + strlen(a) + 1;
+   char *p;
+
if (*len < nlen) {
*len = *len * 2;
if (*len < nlen)
*len = nlen;
+
+   p = *s;
*s = realloc(*s, *len);
-   if (!*s)
+   if (!*s) {
+   free(p);
return -ENOMEM;
+   }
+
if (olen == 0)
**s = 0;
}
-- 
1.7.10.1

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

[PATCH] perf: Free memory allocated in parse_events_fixup

[David Ahern]

578d9c6 added a memory allocation that is not freed. Do that when
the scanner is done.

Signed-off-by: David Ahern 
Cc: Andi Kleen 
---
 tools/perf/util/parse-events.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 2c460ed..707368f 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -846,7 +846,9 @@ static int parse_events_fixup(int ret, const char *str, 
void *data,
free(o);
if (!s)
return -ENOMEM;
-   return parse_events__scanner(s, data, start_token);
+   ret = parse_events__scanner(s, data, start_token);
+   free(s);
+   return ret;
 }
 
 static int parse_events__scanner(const char *str, void *data, int start_token)
-- 
1.7.10.1

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

[PATCH] perf: free list on error path parsing events

[David Ahern]

5f48cb6 moved list memory allocations into parse-events.y. That memory
needs to be freed on a parse failure.

Reported-by: Jiri Olsa 
Signed-off-by: David Ahern 
Cc: Ingo Molnar 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
---
 tools/perf/util/parse-events.y |   41 
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 4eb67ec..85d0999 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -22,6 +22,14 @@ do { \
YYABORT; \
 } while (0)
 
+#define ABORT_ON_FREE(val, p) \
+do { \
+   if (val) { \
+   free(p); \
+   YYABORT; \
+   } \
+} while (0)
+
 #define ALLOC_LIST(list) \
 do { \
list = malloc(sizeof(*list)); \
@@ -206,7 +214,7 @@ PE_NAME '/' event_config '/'
struct list_head *list;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_pmu(list, >idx, $1, $3));
+   ABORT_ON_FREE(parse_events_add_pmu(list, >idx, $1, $3), list);
parse_events__free_terms($3);
$$ = list;
 }
@@ -225,8 +233,8 @@ value_sym '/' event_config '/'
int config = $1 & 255;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_numeric(list, >idx,
- type, config, $3));
+   ABORT_ON_FREE(parse_events_add_numeric(list, >idx,
+ type, config, $3), list);
parse_events__free_terms($3);
$$ = list;
 }
@@ -239,8 +247,8 @@ value_sym sep_slash_dc
int config = $1 & 255;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_numeric(list, >idx,
- type, config, NULL));
+   ABORT_ON_FREE(parse_events_add_numeric(list, >idx,
+ type, config, NULL), list);
$$ = list;
 }
 
@@ -251,7 +259,7 @@ PE_NAME_CACHE_TYPE '-' PE_NAME_CACHE_OP_RESULT '-' 
PE_NAME_CACHE_OP_RESULT
struct list_head *list;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_cache(list, >idx, $1, $3, $5));
+   ABORT_ON_FREE(parse_events_add_cache(list, >idx, $1, $3, $5), 
list);
$$ = list;
 }
 |
@@ -261,7 +269,7 @@ PE_NAME_CACHE_TYPE '-' PE_NAME_CACHE_OP_RESULT
struct list_head *list;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_cache(list, >idx, $1, $3, NULL));
+   ABORT_ON_FREE(parse_events_add_cache(list, >idx, $1, $3, NULL), 
list);
$$ = list;
 }
 |
@@ -271,7 +279,7 @@ PE_NAME_CACHE_TYPE
struct list_head *list;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_cache(list, >idx, $1, NULL, NULL));
+   ABORT_ON_FREE(parse_events_add_cache(list, >idx, $1, NULL, NULL), 
list);
$$ = list;
 }
 
@@ -282,8 +290,8 @@ PE_PREFIX_MEM PE_VALUE ':' PE_MODIFIER_BP sep_dc
struct list_head *list;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_breakpoint(list, >idx,
-(void *) $2, $4));
+   ABORT_ON_FREE(parse_events_add_breakpoint(list, >idx,
+(void *) $2, $4), list);
$$ = list;
 }
 |
@@ -293,8 +301,8 @@ PE_PREFIX_MEM PE_VALUE sep_dc
struct list_head *list;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_breakpoint(list, >idx,
-(void *) $2, NULL));
+   ABORT_ON_FREE(parse_events_add_breakpoint(list, >idx,
+(void *) $2, NULL), list);
$$ = list;
 }
 
@@ -305,7 +313,7 @@ PE_NAME ':' PE_NAME
struct list_head *list;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_tracepoint(list, >idx, $1, $3));
+   ABORT_ON_FREE(parse_events_add_tracepoint(list, >idx, $1, $3), 
list);
$$ = list;
 }
 
@@ -316,7 +324,8 @@ PE_VALUE ':' PE_VALUE
struct list_head *list;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_numeric(list, >idx, (u32)$1, $3, NULL));
+   ABORT_ON_FREE(parse_events_add_numeric(list, >idx,
+   (u32)$1, $3, NULL), list);
$$ = list;
 }
 
@@ -327,8 +336,8 @@ PE_RAW
struct list_head *list;
 
ALLOC_LIST(list);
-   ABORT_ON(parse_events_add_numeric(list, >idx,
- PERF_TYPE_RAW, $1, NULL));
+   ABORT_ON_FREE(parse_events_add_numeric(list, >idx,
+ PERF_TYPE_RAW, $1, NULL), list);
$$ = list;
 }
 
-- 
1.7.10.1

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

[PATCH] net: mv643xx_eth: fix DT port device name

[Sebastian Hesselbarth]

Device tree support added to Marvell MV643xx ethernet driver registers
port devices from port device nodes found on the corresponding controller
node. The current port device name will cause the second controller to
fail on registration because of two identical device names. This fixes
the issue by taking the device node's name also as port device name.

Signed-off-by: Sebastian Hesselbarth 
Reported-by: Jonas Gorski 
---
Cc: Lennert Buytenhek 
Cc: Jonas Gorski 
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/net/ethernet/marvell/mv643xx_eth.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 6495bea..1f3a03d 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
of_property_read_u32(pnp, "duplex", );
}
 
-   ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
+   ppdev = platform_device_alloc(pnp->name, ppd.port_number);
if (!ppdev)
return -ENOMEM;
ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-- 
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 v7 2/7] ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes

[Sebastian Hesselbarth]

This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis.

Signed-off-by: Sebastian Hesselbarth 
---
Changelog:
v6->v7:
- fix ethernet 1 port 0 name in kirkwood.dtsi (Reported by Jonas Gorski)

v5->v6:
- rebase for v3.11-rc1
- also convert Sheevaplug and DB628x

Cc: Russell King 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Thomas Petazzoni 
Cc: Gregory CLEMENT 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: net...@vger.kernel.org
---
 arch/arm/boot/dts/kirkwood-cloudbox.dts|   16 ++
 arch/arm/boot/dts/kirkwood-db.dtsi |   16 ++
 arch/arm/boot/dts/kirkwood-dnskw.dtsi  |   16 ++
 arch/arm/boot/dts/kirkwood-dockstar.dts|   17 +++
 arch/arm/boot/dts/kirkwood-dreamplug.dts   |   28 +++
 arch/arm/boot/dts/kirkwood-goflexnet.dts   |   16 ++
 .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |   30 +++
 arch/arm/boot/dts/kirkwood-ib62x0.dts  |   16 ++
 arch/arm/boot/dts/kirkwood-iconnect.dts|   16 ++
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts  |   24 +
 arch/arm/boot/dts/kirkwood-is2.dts |2 +
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts |   16 ++
 arch/arm/boot/dts/kirkwood-lsxl.dtsi   |   28 +++
 arch/arm/boot/dts/kirkwood-mplcec4.dts |   27 ++
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |   16 ++
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi |   16 ++
 arch/arm/boot/dts/kirkwood-ns2.dts |2 +
 arch/arm/boot/dts/kirkwood-ns2lite.dts |2 +
 arch/arm/boot/dts/kirkwood-ns2max.dts  |2 +
 arch/arm/boot/dts/kirkwood-ns2mini.dts |2 +
 arch/arm/boot/dts/kirkwood-openblocks_a6.dts   |   16 ++
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi  |   16 ++
 arch/arm/boot/dts/kirkwood-topkick.dts |   16 ++
 arch/arm/boot/dts/kirkwood-ts219-6281.dts  |4 +-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts  |4 +-
 arch/arm/boot/dts/kirkwood-ts219.dtsi  |   16 ++
 arch/arm/boot/dts/kirkwood.dtsi|   52 
 27 files changed, 430 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-cloudbox.dts 
b/arch/arm/boot/dts/kirkwood-cloudbox.dts
index 00c48d2..85eed62 100644
--- a/arch/arm/boot/dts/kirkwood-cloudbox.dts
+++ b/arch/arm/boot/dts/kirkwood-cloudbox.dts
@@ -89,3 +89,19 @@
gpios = < 17 0>;
};
 };
+
+ {
+   status = "okay";
+
+   ethphy0: ethernet-phy@0 {
+   device_type = "ethernet-phy";
+   reg = <0>;
+   };
+};
+
+ {
+   status = "okay";
+   ethernet0-port@0 {
+   phy-handle = <>;
+   };
+};
diff --git a/arch/arm/boot/dts/kirkwood-db.dtsi 
b/arch/arm/boot/dts/kirkwood-db.dtsi
index c87cfb8..ca8bf36 100644
--- a/arch/arm/boot/dts/kirkwood-db.dtsi
+++ b/arch/arm/boot/dts/kirkwood-db.dtsi
@@ -87,3 +87,19 @@
};
};
 };
+
+ {
+   status = "okay";
+
+   ethphy0: ethernet-phy@8 {
+   device_type = "ethernet-phy";
+   reg = <8>;
+   };
+};
+
+ {
+   status = "okay";
+   ethernet0-port@0 {
+   phy-handle = <>;
+   };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi 
b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 0afe1d0..f600ed7 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -219,3 +219,19 @@
};
};
 };
+
+ {
+   status = "okay";
+
+   ethphy0: ethernet-phy@8 {
+   device_type = "ethernet-phy";
+   reg = <8>;
+   };
+};
+
+ {
+   status = "okay";
+   ethernet0-port@0 {
+   phy-handle = <>;
+   };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dockstar.dts 
b/arch/arm/boot/dts/kirkwood-dockstar.dts
index 7714742..915aca6 100644
--- a/arch/arm/boot/dts/kirkwood-dockstar.dts
+++ b/arch/arm/boot/dts/kirkwood-dockstar.dts
@@ -90,3 +90,20 @@
};
};
 };
+
+ {
+   status = "okay";
+
+   ethphy0: ethernet-phy@0 {
+   device_type = "ethernet-phy";
+   compatible = "marvell,88e1116";
+   reg = <0>;
+   };
+};
+
+ {
+   status = "okay";
+   ethernet0-port@0 {
+   phy-handle = <>;
+   };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts 
b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 36c7ba3..300fbf8 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -99,3 +99,31 @@
};
};
 };
+
+ {
+   status = "okay";
+
+   ethphy0: ethernet-phy@0 {
+   device_type = "ethernet-phy";
+   reg = <0>;
+   };
+
+  

[PATCH v3 1/1] [SCSI] sg: fix race condition when do exclusive open

[vaughan]

Use rwsem to aid opens. Exclusive open has to get write lock and non-exclusive 
open should get read lock.
Replace global sg_open_exclusive_lock with a per device lock - sfd_lock. Since 
sfds list is now protected by the lock owned by the same sg_device, 
sg_index_lock becomes a real global lock to only protect sg devices lookup.

Please pay attention to sdp->detached. Previously sg_open may also race with 
sg_remove. Now there are two points for sg_open to detect detached and finish 
itself. One is at sg_device lookup and the other is when trying to link new sfp 
into the sfds list in sg_add_sfp.
I don't think it's necessary to do extra set_exclude and wake_up o_excl_wait in 
sg_release before, so I remove them and only do the cleanup in sg_remove_sfp.
Although simple testcases are passed, I'm not certain if I've fixed it well, 
please give me any comments as you wish.

Signed-off-by: Vaughan Cao 
---
 drivers/scsi/sg.c | 187 ++
 1 file changed, 89 insertions(+), 98 deletions(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 25b5455..3fc8c19 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -103,11 +103,8 @@ static int scatter_elem_sz_prev = SG_SCATTER_SZ;
 static int sg_add(struct device *, struct class_interface *);
 static void sg_remove(struct device *, struct class_interface *);
 
-static DEFINE_SPINLOCK(sg_open_exclusive_lock);

-
 static DEFINE_IDR(sg_index_idr);
-static DEFINE_RWLOCK(sg_index_lock);   /* Also used to lock
-  file descriptor list 
for device */
+static DEFINE_RWLOCK(sg_index_lock);   /* protect sg index */
 
 static struct class_interface sg_interface = {

.add_dev= sg_add,
@@ -144,7 +141,7 @@ typedef struct sg_request { /* SG_MAX_QUEUE requests 
outstanding per file */
 } Sg_request;
 
 typedef struct sg_fd {		/* holds the state of a file descriptor */

-   /* sfd_siblings is protected by sg_index_lock */
+   /* sfd_siblings is protected by sfd_lock of sg_device */
struct list_head sfd_siblings;
struct sg_device *parentdp; /* owning device */
wait_queue_head_t read_wait;/* queue read until command done */
@@ -168,13 +165,12 @@ typedef struct sg_fd {/* holds the state of a 
file descriptor */
 
 typedef struct sg_device { /* holds the state of each scsi generic device */

struct scsi_device *device;
-   wait_queue_head_t o_excl_wait;  /* queue open() when O_EXCL in use */
int sg_tablesize;   /* adapter's max scatter-gather table size */
u32 index;  /* device index number */
-   /* sfds is protected by sg_index_lock */
+   spinlock_t sfd_lock;/* protect sfds, exclude */
struct list_head sfds;
+   struct rw_semaphore o_sem;  /* exclude open should hold this rwsem 
*/
volatile char detached; /* 0->attached, 1->detached pending removal */
-   /* exclude protected by sg_open_exclusive_lock */
char exclude;   /* opened for exclusive access */
char sgdebug;   /* 0->off, 1->sense, 9->dump dev, 10-> all devs 
*/
struct gendisk *disk;
@@ -199,7 +195,7 @@ static void sg_remove_scat(Sg_scatter_hold * schp);
 static void sg_build_reserve(Sg_fd * sfp, int req_size);
 static void sg_link_reserve(Sg_fd * sfp, Sg_request * srp, int size);
 static void sg_unlink_reserve(Sg_fd * sfp, Sg_request * srp);
-static Sg_fd *sg_add_sfp(Sg_device * sdp, int dev);
+static Sg_fd *sg_add_sfp(Sg_device * sdp, int dev, int excl, int * reason);
 static void sg_remove_sfp(struct kref *);
 static Sg_request *sg_get_rq_mark(Sg_fd * sfp, int pack_id);
 static Sg_request *sg_add_request(Sg_fd * sfp);
@@ -224,35 +220,14 @@ static int sg_allow_access(struct file *filp, unsigned 
char *cmd)
return blk_verify_command(q, cmd, filp->f_mode & FMODE_WRITE);
 }
 
-static int get_exclude(Sg_device *sdp)

-{
-   unsigned long flags;
-   int ret;
-
-   spin_lock_irqsave(_open_exclusive_lock, flags);
-   ret = sdp->exclude;
-   spin_unlock_irqrestore(_open_exclusive_lock, flags);
-   return ret;
-}
-
-static int set_exclude(Sg_device *sdp, char val)
-{
-   unsigned long flags;
-
-   spin_lock_irqsave(_open_exclusive_lock, flags);
-   sdp->exclude = val;
-   spin_unlock_irqrestore(_open_exclusive_lock, flags);
-   return val;
-}
-
 static int sfds_list_empty(Sg_device *sdp)
 {
unsigned long flags;
int ret;
 
-	read_lock_irqsave(_index_lock, flags);

+   spin_lock_irqsave(>sfd_lock, flags);
ret = list_empty(>sfds);
-   read_unlock_irqrestore(_index_lock, flags);
+   spin_unlock_irqrestore(>sfd_lock, flags);
return ret;
 }
 
@@ -264,8 +239,8 @@ sg_open(struct inode *inode, struct file *filp)

struct request_queue *q;
Sg_device *sdp;
Sg_fd *sfp;
-   int res;
int retval;
+   unsigned long 

Re: [PATCH v3 2/6] misc: sram: add ability to mark sram sections as reserved

[Rob Herring]

On Fri, Jul 5, 2013 at 7:41 AM, Heiko Stübner  wrote:
> Some SoCs need parts of their sram for special purposes. So while being part
> of the periphal, it should not be part of the genpool controlling the sram.

s/periphal/peripheral/

>
> Threfore add an option mmio-sram-reserved to keep arbitary portions of the

s/Threfore/Therefore/
s/arbitary/arbitrary/

> sram from being part of the pool.
>
> Suggested-by: Rob Herring 
> Signed-off-by: Heiko Stuebner 
> Tested-by: Ulrich Prinz 
> ---
>  Documentation/devicetree/bindings/misc/sram.txt |8 +++
>  drivers/misc/sram.c |   80 
> +--
>  2 files changed, 82 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt 
> b/Documentation/devicetree/bindings/misc/sram.txt
> index 4d0a00e..eae080e 100644
> --- a/Documentation/devicetree/bindings/misc/sram.txt
> +++ b/Documentation/devicetree/bindings/misc/sram.txt
> @@ -8,9 +8,17 @@ Required properties:
>
>  - reg : SRAM iomem address range
>
> +Optional properties:
> +
> +- mmio-sram-reserved: ordered list of reserved chunks inside the sram that
> +  should not become part of the genalloc pool.

genalloc is linux specific. "should not be used by the OS" would be better.

> +  Format is , , ...; with base being relative to the
> +  reg property base.
> +
>  Example:
>
>  sram: sram@5c00 {
> compatible = "mmio-sram";
> reg = <0x5c00 0x4>; /* 256 KiB SRAM at address 0x5c00 */
> +   mmio-sram-reserved = <0x0 0x100>; /* reserve 0x5c00-0x5c000100 */
>  };
> diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> index afe66571..9131e4a 100644
> --- a/drivers/misc/sram.c
> +++ b/drivers/misc/sram.c
> @@ -42,6 +42,13 @@ static int sram_probe(struct platform_device *pdev)
> struct sram_dev *sram;
> struct resource *res;
> unsigned long size;
> +   const __be32 *reserved_list = NULL;
> +   int reserved_size = 0;
> +   unsigned int cur_start = 0;
> +   unsigned int cur_size;
> +   unsigned int rstart;
> +   unsigned int rsize;

Use one line for each type.

> +   int i;
> int ret;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -65,12 +72,73 @@ static int sram_probe(struct platform_device *pdev)
> if (!sram->pool)
> return -ENOMEM;
>
> -   ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
> -   res->start, size, -1);
> -   if (ret < 0) {
> -   if (sram->clk)
> -   clk_disable_unprepare(sram->clk);
> -   return ret;
> +   if (pdev->dev.of_node) {
> +   reserved_list = of_get_property(pdev->dev.of_node,
> +   "mmio-sram-reserved",
> +   _size);
> +   if (reserved_list) {
> +   reserved_size /= sizeof(*reserved_list);
> +   if (!reserved_size || reserved_size % 2) {
> +   dev_warn(>dev, "wrong number of 
> arguments in mmio-sram-reserved\n");
> +   reserved_list = NULL;
> +   }
> +   }
> +   }
> +
> +   if (!reserved_list)
> +   reserved_size = 0;

This can be moved to where you set reserved_list to NULL.

> +
> +   for (i = 0; i < (reserved_size + 2); i += 2) {
> +   if (i < reserved_size) {

This loop is hard to follow. For example, it is not immediate obvious
why you loop an extra time. I think it would be more straight forward
to determine the free regions first and then do the allocations. This
will require a kmalloc or fixed max number of regions, but would
improve readability.

Rob

> +   /* get the next reserved block */
> +   rstart = be32_to_cpu(*reserved_list++);
> +   rsize = be32_to_cpu(*reserved_list++);
> +
> +   /* catch unsorted list entries */
> +   if (rstart < cur_start) {
> +   dev_err(>dev,
> +   "unsorted reserved list (0x%x before 
> current 0x%x)\n",
> +   rstart, cur_start);
> +   if (sram->clk)
> +   clk_disable_unprepare(sram->clk);
> +   return -EINVAL;
> +   }
> +
> +   dev_dbg(>dev,
> +   "found reserved block 0x%x-0x%x\n",
> +   rstart, rstart + rsize);
> +   } else {
> +   /* the last chunk extends to the end of the region */
> +   rstart = size;
> +   rsize = 0;
> +   }
> +
> +   /* current start is in a reserved block */
> 

Re: [PATCH v2] swap: warn when a swap area overflows the maximum size

[Rik van Riel]

On 07/07/2013 03:13 PM, Raymond Jennings wrote:

Turned the comparison around for clarity of "bigger than"

No semantic changes, if it still compiles it should do the same thing so
I've omitted the testing this time.  Will be happy to retest if required
but I'm on an atom 330 and kernel rebuilds are a nightmare.


Added CC: Andrew Morton, since this should probably go into -mm :)




swap: warn when a swap area overflows the maximum size

It is possible to swapon a swap area that is too big for the pte width
to handle.

Presently this failure happens silently.

Instead, emit a diagnostic to warn the user.

Signed-off-by: Raymond Jennings 
Acked-by: Valdis Kletnieks 


Reviewed-by: Rik van Riel 


diff --git a/mm/swapfile.c b/mm/swapfile.c
index 36af6ee..5a4ce53 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1953,6 +1953,12 @@ static unsigned long read_swap_header(struct
swap_info_struct *p,
  */
 maxpages = swp_offset(pte_to_swp_entry(
 swp_entry_to_pte(swp_entry(0, ~0UL + 1;
+   if (swap_header->info.last_page > maxpages) {
+   printk(KERN_WARNING
+  "Truncating oversized swap area, only using %luk
out of %luk
\n",
+  maxpages << (PAGE_SHIFT - 10),
+  swap_header->info.last_page << (PAGE_SHIFT -
10));
+   }
 if (maxpages > swap_header->info.last_page) {
 maxpages = swap_header->info.last_page + 1;
 /* p->max is an unsigned int: don't overflow it */



Testing results, root prompt commands and kernel log messages:

# lvresize /dev/system/swap --size 16G
# mkswap /dev/system/swap
# swapon /dev/system/swap

Jul  7 04:27:22 warfang kernel: Adding 16777212k swap
on /dev/mapper/system-swap.  Priority:-1 extents:1 across:16777212k

# lvresize /dev/system/swap --size 16G
# mkswap /dev/system/swap
# swapon /dev/system/swap

Jul  7 04:27:22 warfang kernel: Truncating oversized swap area, only
using 33554432k out of 67108860k
Jul  7 04:27:22 warfang kernel: Adding 33554428k swap
on /dev/mapper/system-swap.  Priority:-1 extents:1 across:33554428k





--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Input: cyttsp4 - SPI driver for Cypress TMA4XX touchscreen devices

[Geert Uytterhoeven]

On Fri, Jul 5, 2013 at 1:51 AM, Linux Kernel Mailing List
 wrote:
> +++ b/drivers/input/touchscreen/cyttsp4_spi.c

> +static int cyttsp_spi_xfer(struct device *dev, u8 *xfer_buf,
> +  u8 op, u8 reg, u8 *buf, int length)
> +{

> +   if (reg > 255)

As "reg" is "u8", this is never true:

drivers/input/touchscreen/cyttsp4_spi.c: In function ‘cyttsp_spi_xfer’:
drivers/input/touchscreen/cyttsp4_spi.c:66: warning: comparison is
always false due to limited range of data type

> +   wr_buf[0] = op + CY_SPI_A8_BIT;
> +   else
> +   wr_buf[0] = op;

Can the if-clause and the first branch just be removed, or is there a real bug
involved (e.g. wrong type for "reg")?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] swap: warn when a swap area overflows the maximum size

[Raymond Jennings]

Turned the comparison around for clarity of "bigger than"

No semantic changes, if it still compiles it should do the same thing so
I've omitted the testing this time.  Will be happy to retest if required
but I'm on an atom 330 and kernel rebuilds are a nightmare.



swap: warn when a swap area overflows the maximum size

It is possible to swapon a swap area that is too big for the pte width
to handle.

Presently this failure happens silently.

Instead, emit a diagnostic to warn the user.

Signed-off-by: Raymond Jennings 
Acked-by: Valdis Kletnieks 



diff --git a/mm/swapfile.c b/mm/swapfile.c
index 36af6ee..5a4ce53 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1953,6 +1953,12 @@ static unsigned long read_swap_header(struct
swap_info_struct *p,
 */
maxpages = swp_offset(pte_to_swp_entry(
swp_entry_to_pte(swp_entry(0, ~0UL + 1;
+   if (swap_header->info.last_page > maxpages) {
+   printk(KERN_WARNING
+  "Truncating oversized swap area, only using %luk
out of %luk
\n",
+  maxpages << (PAGE_SHIFT - 10),
+  swap_header->info.last_page << (PAGE_SHIFT -
10));
+   }
if (maxpages > swap_header->info.last_page) {
maxpages = swap_header->info.last_page + 1;
/* p->max is an unsigned int: don't overflow it */



Testing results, root prompt commands and kernel log messages:

# lvresize /dev/system/swap --size 16G
# mkswap /dev/system/swap
# swapon /dev/system/swap

Jul  7 04:27:22 warfang kernel: Adding 16777212k swap
on /dev/mapper/system-swap.  Priority:-1 extents:1 across:16777212k 

# lvresize /dev/system/swap --size 16G
# mkswap /dev/system/swap
# swapon /dev/system/swap

Jul  7 04:27:22 warfang kernel: Truncating oversized swap area, only
using 33554432k out of 67108860k
Jul  7 04:27:22 warfang kernel: Adding 33554428k swap
on /dev/mapper/system-swap.  Priority:-1 extents:1 across:33554428k 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: cyttsp4 - Kill defined but not used compiler warnings

[Geert Uytterhoeven]

If both CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME are unset:

drivers/input/touchscreen/cyttsp4_core.c:1556: warning: ‘cyttsp4_core_sleep’ 
defined but not used
drivers/input/touchscreen/cyttsp4_core.c:1634: warning: ‘cyttsp4_core_wake’ 
defined but not used

Move cyttsp4_core_sleep(), cyttsp4_core_wake(), and cyttsp4_core_wake_()
(which is called from cyttsp4_core_wake() only) inside the existing section
protected by #if defined(CONFIG_PM_SLEEP) || defined(CONFIG_PM_RUNTIME)

Signed-off-by: Geert Uytterhoeven 
---
 drivers/input/touchscreen/cyttsp4_core.c |  200 +++---
 1 file changed, 100 insertions(+), 100 deletions(-)

diff --git a/drivers/input/touchscreen/cyttsp4_core.c 
b/drivers/input/touchscreen/cyttsp4_core.c
index edcf799..c49161c2 100644
--- a/drivers/input/touchscreen/cyttsp4_core.c
+++ b/drivers/input/touchscreen/cyttsp4_core.c
@@ -1552,106 +1552,6 @@ exit:
return rc;
 }
 
-static int cyttsp4_core_sleep(struct cyttsp4 *cd)
-{
-   int rc;
-
-   rc = cyttsp4_request_exclusive(cd, cd->dev,
-   CY_CORE_SLEEP_REQUEST_EXCLUSIVE_TIMEOUT);
-   if (rc < 0) {
-   dev_err(cd->dev, "%s: fail get exclusive ex=%p own=%p\n",
-   __func__, cd->exclusive_dev, cd->dev);
-   return 0;
-   }
-
-   rc = cyttsp4_core_sleep_(cd);
-
-   if (cyttsp4_release_exclusive(cd, cd->dev) < 0)
-   dev_err(cd->dev, "%s: fail to release exclusive\n", __func__);
-   else
-   dev_vdbg(cd->dev, "%s: pass release exclusive\n", __func__);
-
-   return rc;
-}
-
-static int cyttsp4_core_wake_(struct cyttsp4 *cd)
-{
-   struct device *dev = cd->dev;
-   int rc;
-   u8 mode;
-   int t;
-
-   /* Already woken? */
-   mutex_lock(>system_lock);
-   if (cd->sleep_state == SS_SLEEP_OFF) {
-   mutex_unlock(>system_lock);
-   return 0;
-   }
-   cd->int_status &= ~CY_INT_IGNORE;
-   cd->int_status |= CY_INT_AWAKE;
-   cd->sleep_state = SS_WAKING;
-
-   if (cd->cpdata->power) {
-   dev_dbg(dev, "%s: Power up HW\n", __func__);
-   rc = cd->cpdata->power(cd->cpdata, 1, dev, >ignore_irq);
-   } else {
-   dev_dbg(dev, "%s: No power function\n", __func__);
-   rc = -ENOSYS;
-   }
-   if (rc < 0) {
-   dev_err(dev, "%s: HW Power up fails r=%d\n",
-   __func__, rc);
-
-   /* Initiate a read transaction to wake up */
-   cyttsp4_adap_read(cd, CY_REG_BASE, sizeof(mode), );
-   } else
-   dev_vdbg(cd->dev, "%s: HW power up succeeds\n",
-   __func__);
-   mutex_unlock(>system_lock);
-
-   t = wait_event_timeout(cd->wait_q,
-   (cd->int_status & CY_INT_AWAKE) == 0,
-   msecs_to_jiffies(CY_CORE_WAKEUP_TIMEOUT));
-   if (IS_TMO(t)) {
-   dev_err(dev, "%s: TMO waiting for wakeup\n", __func__);
-   mutex_lock(>system_lock);
-   cd->int_status &= ~CY_INT_AWAKE;
-   /* Try starting up */
-   cyttsp4_queue_startup_(cd);
-   mutex_unlock(>system_lock);
-   }
-
-   mutex_lock(>system_lock);
-   cd->sleep_state = SS_SLEEP_OFF;
-   mutex_unlock(>system_lock);
-
-   cyttsp4_start_wd_timer(cd);
-
-   return 0;
-}
-
-static int cyttsp4_core_wake(struct cyttsp4 *cd)
-{
-   int rc;
-
-   rc = cyttsp4_request_exclusive(cd, cd->dev,
-   CY_CORE_REQUEST_EXCLUSIVE_TIMEOUT);
-   if (rc < 0) {
-   dev_err(cd->dev, "%s: fail get exclusive ex=%p own=%p\n",
-   __func__, cd->exclusive_dev, cd->dev);
-   return 0;
-   }
-
-   rc = cyttsp4_core_wake_(cd);
-
-   if (cyttsp4_release_exclusive(cd, cd->dev) < 0)
-   dev_err(cd->dev, "%s: fail to release exclusive\n", __func__);
-   else
-   dev_vdbg(cd->dev, "%s: pass release exclusive\n", __func__);
-
-   return rc;
-}
-
 static int cyttsp4_startup_(struct cyttsp4 *cd)
 {
int retry = CY_CORE_STARTUP_RETRY_COUNT;
@@ -1821,6 +1721,106 @@ static void cyttsp4_free_si_ptrs(struct cyttsp4 *cd)
 }
 
 #if defined(CONFIG_PM_SLEEP) || defined(CONFIG_PM_RUNTIME)
+static int cyttsp4_core_sleep(struct cyttsp4 *cd)
+{
+   int rc;
+
+   rc = cyttsp4_request_exclusive(cd, cd->dev,
+   CY_CORE_SLEEP_REQUEST_EXCLUSIVE_TIMEOUT);
+   if (rc < 0) {
+   dev_err(cd->dev, "%s: fail get exclusive ex=%p own=%p\n",
+   __func__, cd->exclusive_dev, cd->dev);
+   return 0;
+   }
+
+   rc = cyttsp4_core_sleep_(cd);
+
+   if (cyttsp4_release_exclusive(cd, cd->dev) < 0)
+   dev_err(cd->dev, "%s: fail to release exclusive\n", __func__);
+   else
+   dev_vdbg(cd->dev, "%s: pass release 

Re: [PATCH 1/6] cpufreq: Add debugfs directory for cpufreq

[Pankaj Jangra]

Hi Chanwoo,

On Fri, Jul 5, 2013 at 1:46 AM, Chanwoo Choi  wrote:
> This patch create debugfs root directory and child directory according to
> the number of CPUs for CPUFreq as below debugfs directory path:
> - /sys/kernel/debug/cpufreq/cpuX
>
> If many CPUs share only one cpufreq policy, other CPU(except for CPU0) create
> a link for debugfs directory of CPU0.
> - /sys/kernel/debug/cpufreq/cpu0
> - /sys/kernel/debug/cpufreq/cpu[1-(N-1)] -> /sys/kernel/debug/cpufreq/cpu0
>
> And then cpufreq may need to create debugfs specific file below of debugfs
> directory of cpufreq. (e.g., /sys/kernel/debug/cpufreq/cpu0/load_table)
>
> Signed-off-by: Chanwoo Choi 
> Signed-off-by: Kyungmin Park 
> Signed-off-by: Myungjoo Ham 
> ---
>  drivers/cpufreq/cpufreq.c | 57 
> +++
>  include/linux/cpufreq.h   |  1 +
>  2 files changed, 58 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2d53f47..bc01c8e 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -47,6 +48,10 @@ static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], 
> cpufreq_cpu_governor);
>  #endif
>  static DEFINE_RWLOCK(cpufreq_driver_lock);
>
> +/* The cpufreq_debugfs is used to create debugfs root directory for CPUFreq. 
> */
> +#define MAX_DEBUGFS_NAME_LEN   CPUFREQ_NAME_LEN
> +static struct dentry *cpufreq_debugfs;
> +
>  /*
>   * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
>   * all cpufreq/hotplug/workqueue/etc related lock issues.
> @@ -726,6 +731,20 @@ static int cpufreq_add_dev_symlink(unsigned int cpu,
> cpufreq_cpu_put(managed_policy);
> return ret;
> }
> +
> +   if (cpufreq_debugfs) {
> +   char symlink_name[MAX_DEBUGFS_NAME_LEN];
> +   char target_name[MAX_DEBUGFS_NAME_LEN];
> +
> +   sprintf(symlink_name, "cpu%d", j);
> +   sprintf(target_name, "./cpu%d", cpu);
> +   managed_policy->cpu_debugfs[j] = 
> debugfs_create_symlink(
> +   symlink_name,
> +   cpufreq_debugfs,
> +   target_name);
> +   if (!managed_policy->cpu_debugfs[j])
> +   pr_debug("creating debugfs symlink failed\n");
> +   }
> }
> return ret;
>  }
> @@ -746,6 +765,22 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
> if (ret)
> return ret;
>
> +   /* prepare interface data for debugfs */
> +   if (cpufreq_debugfs) {
> +   char name[MAX_DEBUGFS_NAME_LEN];
> +   int size, i;
> +
> +   sprintf(name, "cpu%d", policy->cpu);
> +   size = sizeof(struct dentry*) * NR_CPUS;
> +   i = cpu;
> +
> +   policy->cpu_debugfs = devm_kzalloc(dev, size, GFP_KERNEL);
> +   policy->cpu_debugfs[i] = debugfs_create_dir(name,
> +   cpufreq_debugfs);
> +   if (!policy->cpu_debugfs[i])
> +   pr_debug("creating debugfs directory failed\n");
> +   }
> +
> /* set up files for this cpu device */
> drv_attr = cpufreq_driver->attr;
> while ((drv_attr) && (*drv_attr)) {
> @@ -839,6 +874,20 @@ static int cpufreq_add_policy_cpu(unsigned int cpu, 
> unsigned int sibling,
> return ret;
> }
>
> +   if (cpufreq_debugfs) {
> +   char symlink_name[MAX_DEBUGFS_NAME_LEN];
> +   char target_name[MAX_DEBUGFS_NAME_LEN];
> +
> +   sprintf(symlink_name, "cpu%d", cpu);
> +   sprintf(target_name, "./cpu%d", sibling);
> +   policy->cpu_debugfs[cpu] = debugfs_create_symlink(
> +   symlink_name,
> +   cpufreq_debugfs,
> +   target_name);
> +   if (!policy->cpu_debugfs[cpu])
> +   pr_debug("creating debugfs symlink failed\n");
> +   }
> +
> return 0;
>  }
>  #endif
> @@ -1046,6 +1095,7 @@ static int __cpufreq_remove_dev(struct device *dev, 
> struct subsys_interface *sif
>
> if (cpu != data->cpu) {
> sysfs_remove_link(>kobj, "cpufreq");
> +   debugfs_remove(data->cpu_debugfs[cpu]);

I think you should add the call to remove the "cpufreq" also ???
   "debugfs_remove(cpufreq_debugfs);"
> } else if (cpus > 1) {
> /* first sibling now owns the new sysfs dir */
> cpu_dev = get_cpu_device(cpumask_first(data->cpus));
> 

Re: [PATCH] menuconfig: Allow j/k to move down/up the menu

[Ramkumar Ramachandra]

Rob Landley wrote:
>>  Unsure why nobody has done this yet.
>
> [...]
> And now you know _why_ Linux is over 20 years old and has never needed this.

I was just asking out of curiosity: I'm not old enough to know that
much history.  Isn't it a nice convenience to have _now_?  Or do you
have something against it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: linux-next: build warning after merge of the mfd tree

[Sebastian Andrzej Siewior]

On Wed, Jul 03, 2013 at 03:56:55PM +1000, Stephen Rothwell wrote:
> Hi Samuel,
Hi Stephen,

> Introduced by commit 18926edebcb8 ("iio: ti_am335x_adc: Allow to specify
> input line").  CONFIG_OF is not set in this build.
> 
> Maybe someone could come up with a way to make these arguments to
> of_property_for_each_u32() etc look used in the !CONFIG_OF case.

Already posted:

  https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/035703.html

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] menuconfig: Allow j/k to move down/up the menu

[Rob Landley]

On 07/05/2013 06:32:59 AM, Ramkumar Ramachandra wrote:

Like in Vim.

Cc: Michal Marek 
Signed-off-by: Ramkumar Ramachandra 
---
 Unsure why nobody has done this yet.


While you're at it, why don't you add the ws up and down bindings from  
World of Warcraft?


The reason nobody has done this yet is that vi predates the invention  
of cursor keys. They keyboards Bill Joy was using in the 1970's did not  
have standardized cursor keys, in large part because you can't cursor  
around on a teletype printer. Once people started using "glass tty"  
devices (vt100 and such) cursor keys got standardized within a few  
years. They were reasonably ubiquitous by the time the IBM PC showed up  
(the vic 20 and commodore 64 and such all had them; anything that  
displayed to a television instead of through a daisy wheel).


They also didn't have ALT or control keys. The vi modal interface is a  
legacy of not having any standardized keys on the keyboard except  
letters, numbers, and (for 8 bit machines) shift. (There's a song  
"double bucky" to the tune of "Rubber Ducky" that commemorates a  
particular bespoke keyboard design from MIT in the 1970's.) Even the  
punctuation was potluck for a while there, although they could copy  
manual typewriters and the IBM selectric and such for some of that.


And now you know _why_ Linux is over 20 years old and has never needed  
this.


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

Re: [GIT PULL] Stage 1 of __cpuinit removal

[Linus Torvalds]

On Tue, Jul 2, 2013 at 10:44 AM, Paul Gortmaker
 wrote:
>
>  include/asm-generic/vmlinux.lds.h | 12 -
>  include/linux/init.h  | 19 +++---
>  scripts/mod/modpost.c | 52 
> +++
>  3 files changed, 19 insertions(+), 65 deletions(-)

Your diffstat is odd, and doesn't match mine. But I'm pretty sure
yours is just plain wrong, because your numbers just don't add up.

You have:
  12+19+52 = 83
  19+65 = 84

how the heck did you manage that?

The correct diffstat would seem to be

 include/asm-generic/vmlinux.lds.h | 12 
 include/linux/init.h  | 19 +-
 scripts/mod/modpost.c | 52
+
 3 files changed, 18 insertions(+), 65 deletions(-)

(where both set of numbers add up to 83).

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: iop: fix new warnings

[Olof Johansson]

The recent "drivers/dma: remove unused support for MEMSET operations"
change has fallout from lack of build testing by the author. This fixes:

drivers/dma/iop-adma.c:1020:13: warning: unused variable 'dma_addr' 
[-Wunused-variable]
drivers/dma/iop-adma.c:1519:2: warning: format '%s' expects a matching 'char *' 
argument [-Wformat=]

Signed-off-by: Olof Johansson 
---
 drivers/dma/iop-adma.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index c9cc08c..cc727ec 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -1017,7 +1017,7 @@ iop_adma_xor_val_self_test(struct iop_adma_device *device)
struct page *xor_srcs[IOP_ADMA_NUM_SRC_TEST];
struct page *zero_sum_srcs[IOP_ADMA_NUM_SRC_TEST + 1];
dma_addr_t dma_srcs[IOP_ADMA_NUM_SRC_TEST + 1];
-   dma_addr_t dma_addr, dest_dma;
+   dma_addr_t dest_dma;
struct dma_async_tx_descriptor *tx;
struct dma_chan *dma_chan;
dma_cookie_t cookie;
@@ -1516,7 +1516,7 @@ static int iop_adma_probe(struct platform_device *pdev)
goto err_free_iop_chan;
}
 
-   dev_info(>dev, "Intel(R) IOP: ( %s%s%s%s%s%s%s)\n",
+   dev_info(>dev, "Intel(R) IOP: ( %s%s%s%s%s%s)\n",
 dma_has_cap(DMA_PQ, dma_dev->cap_mask) ? "pq " : "",
 dma_has_cap(DMA_PQ_VAL, dma_dev->cap_mask) ? "pq_val " : "",
 dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
-- 
1.7.10.4

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

Re: [PATCH 3/3] smp/ipi:Remove check around csd lock in handler for smp_call_function variants

[Wang YanQing]

On Sun, Jul 07, 2013 at 09:53:48PM +0530, Preeti U Murthy wrote:
> > "
> >  /* 
> >   
> >   * Unlocked CSDs are valid through generic_exec_single():  
> >   
> >   */
> 
> I don't understand this comment. All callers of generic_exec_single()
> take the csd lock. So where is the scenario of csds being unlocked in
> generic_exec_single() before the call to
> arch_send_call_function_single_ipi() is made?
>   Rather what is the above comment trying to say?

I have given the answer to this question in last reply.

I don't know whether it is right to make a assumption through
this way that what you do currently:

Find all the current api users, and drop all the robust codes,
despite the unpredictable future users.

Ok, I know the balance between "robust" vs "performance",
robust check codes will bring performance penalty in fastest
code path, but the "penalty" is neglectable sometimes for
modern CPU.

I decide to respect the MAINTAINER's decision to accept this 
change or not.

Thanks.



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

[PATCH] clk: fix typos

[Peter Meerwald]

Signed-off-by: Peter Meerwald 
---
 drivers/clk/Kconfig |  2 +-
 drivers/clk/clk.c   | 13 +++--
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 51380d6..cd49096 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -27,7 +27,7 @@ config COMMON_CLK_DEBUG
bool "DebugFS representation of clock tree"
select DEBUG_FS
---help---
- Creates a directory hierchy in debugfs for visualizing the clk
+ Creates a directory hierarchy in debugfs for visualizing the clk
  tree structure.  Each directory contains read-only members
  that export information specific to that clk node: clk_rate,
  clk_flags, clk_prepare_count, clk_enable_count &
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 54a191c..56a00db 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -702,7 +702,7 @@ void __clk_unprepare(struct clk *clk)
 
 /**
  * clk_unprepare - undo preparation of a clock source
- * @clk: the clk being unprepare
+ * @clk: the clk being unprepared
  *
  * clk_unprepare may sleep, which differentiates it from clk_disable.  In a
  * simple case, clk_unprepare can be used instead of clk_disable to gate a clk
@@ -869,6 +869,7 @@ EXPORT_SYMBOL_GPL(clk_enable);
 /**
  * __clk_round_rate - round the given rate for a clk
  * @clk: round the rate of this clock
+ * @rate: the rate which is to be rounded
  *
  * Caller must hold prepare_lock.  Useful for clk_ops such as .set_rate
  */
@@ -956,7 +957,7 @@ static int __clk_notify(struct clk *clk, unsigned long msg,
  *
  * Walks the subtree of clks starting with clk and recalculates rates as it
  * goes.  Note that if a clk does not implement the .recalc_rate callback then
- * it is assumed that the clock will take on the rate of it's parent.
+ * it is assumed that the clock will take on the rate of its parent.
  *
  * clk_recalc_rates also propagates the POST_RATE_CHANGE notification,
  * if necessary.
@@ -1026,7 +1027,7 @@ EXPORT_SYMBOL_GPL(clk_get_rate);
  * pre-rate change notifications and returns early if no clks in the
  * subtree have subscribed to the notifications.  Note that if a clk does not
  * implement the .recalc_rate callback then it is assumed that the clock will
- * take on the rate of it's parent.
+ * take on the rate of its parent.
  *
  * Caller must hold prepare_lock.
  */
@@ -1198,7 +1199,7 @@ static void clk_change_rate(struct clk *clk)
  * outcome of clk's .round_rate implementation.  If *parent_rate is unchanged
  * after calling .round_rate then upstream parent propagation is ignored.  If
  * *parent_rate comes back with a new rate for clk's parent then we propagate
- * up to clk's parent and set it's rate.  Upward propagation will continue
+ * up to clk's parent and set its rate.  Upward propagation will continue
  * until either a clk does not support the CLK_SET_RATE_PARENT flag or
  * .round_rate stops requesting changes to clk's parent_rate.
  *
@@ -1648,7 +1649,7 @@ int __clk_init(struct device *dev, struct clk *clk)
 * The .init callback is not used by any of the basic clock types, but
 * exists for weird hardware that must perform initialization magic.
 * Please consider other ways of solving initialization problems before
-* using this callback, as it's use is discouraged.
+* using this callback, as its use is discouraged.
 */
if (clk->ops->init)
clk->ops->init(clk->hw);
@@ -1675,7 +1676,7 @@ out:
  * very large numbers of clocks that need to be statically initialized.  It is
  * a layering violation to include clk-private.h from any code which implements
  * a clock's .ops; as such any statically initialized clock data MUST be in a
- * separate C file from the logic that implements it's operations.  Returns 0
+ * separate C file from the logic that implements its operations.  Returns 0
  * on success, otherwise an error code.
  */
 struct clk *__clk_register(struct device *dev, struct clk_hw *hw)
-- 
1.8.3.2

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

Re: [PATCH 6/6] perf parse events: demystify memory allocations

[Jiri Olsa]

On Sun, Jul 07, 2013 at 10:45:13AM -0600, David Ahern wrote:
> On 7/7/13 9:26 AM, Jiri Olsa wrote:
> >On Tue, Jul 02, 2013 at 01:27:25PM -0600, David Ahern wrote:
> >>List heads are currently allocated way down the function chain in 
> >>__add_event
> >>and add_tracepoint and then freed when the scanner code calls
> >>parse_events_update_lists.
> >>
> >>Be more explicit with where memory is allocated and who should free it. With
> >>this patch the list_head is allocated in the scanner code and freed when the
> >>scanner code calls parse_events_update_lists.
> >>
> >
> >SNIP
> >
> >>@@ -266,9 +279,10 @@ event_legacy_mem:
> >>  PE_PREFIX_MEM PE_VALUE ':' PE_MODIFIER_BP sep_dc
> >>  {
> >>struct parse_events_evlist *data = _data;
> >>-   struct list_head *list = NULL;
> >>+   struct list_head *list;
> >>
> >>-   ABORT_ON(parse_events_add_breakpoint(, >idx,
> >>+   ALLOC_LIST(list);
> >>+   ABORT_ON(parse_events_add_breakpoint(list, >idx,
> >> (void *) $2, $4));
> >>$$ = list;
> >>  }
> >>@@ -276,9 +290,10 @@ PE_PREFIX_MEM PE_VALUE ':' PE_MODIFIER_BP sep_dc
> >>  PE_PREFIX_MEM PE_VALUE sep_dc
> >>  {
> >>struct parse_events_evlist *data = _data;
> >>-   struct list_head *list = NULL;
> >>+   struct list_head *list;
> >>
> >>-   ABORT_ON(parse_events_add_breakpoint(, >idx,
> >>+   ALLOC_LIST(list);
> >>+   ABORT_ON(parse_events_add_breakpoint(list, >idx,
> >> (void *) $2, NULL));
> >
> >so who now frees the list if there's an error
> >in parse_events_add_breakpoint?
> 
> According to valgrind that memory is not freed prior to this patch,
> so this one does not introduce new leaks.

I thought this hunk did:


evsel = perf_evsel__new(attr, (*idx)++);
-   if (!evsel) {
-   free(list);


but I might have missed other cases..

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/