Re: [PATCH RFC 1/2] qrwlock: A queue read/write lock implementation

[Raghavendra K T]

On 07/18/2013 07:49 PM, Waiman Long wrote:

On 07/18/2013 06:22 AM, Thomas Gleixner wrote:

Waiman,

On Mon, 15 Jul 2013, Waiman Long wrote:

On 07/15/2013 06:31 PM, Thomas Gleixner wrote:

On Fri, 12 Jul 2013, Waiman Long wrote:

[...]



+ * an increase in lock size is not an issue.

So is it faster in the general case or only for the high contention or
single thread operation cases?

And you still miss to explain WHY it is faster. Can you please explain
proper WHY it is faster and WHY we can't apply that technique you
implemented for qrwlocks to writer only locks (aka spinlocks) with a
smaller lock size?

I will try to collect more data to justify the usefulness of qrwlock.

And please provide a proper argument why we can't use the same
technique for spinlocks.


Of course, we can use the same technique for spinlock. Since we only
need 1 bit for lock, we could combine the lock bit with the queue
address with a little bit more overhead in term of coding and speed.
That will make the new lock 4 bytes in size for 32-bit code & 8 bytes
for 64-bit code. That could solve a lot of performance problem that we
have with spinlock. However, I am aware that increasing the size of
spinlock (for 64-bit systems) may break a lot of inherent alignment in
many of the data structures. That is why I am not proposing such a
change right now. But if there is enough interest, we could certainly go
ahead and see how things go.


keeping apart the lock size part, for spinlocks, is it that
 fastpath overhead is less significant in low contention scenarios for
qlocks?

Also let me know if you have POC implementation for the spinlocks that
you can share. I am happy to test that.

sorry. different context:
apart from AIM7 fserver, is there any other benchmark to exercise this
qrwlock series? (to help in the testing).

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

[PATCH] Documentation/Changes: phase out Changes file that hasn't changed

[Paul Gortmaker]

It has been over two years since this file has been touched, and
even that prior change was just to delete some ancient text.

Looking at the bigger picture, the need for this file has simply
passed.  It was trying to detail required versions of userspace
packages, in order to cater to hand-crafted systems.  But now the
majority of users get their userspace all at once from some kind
of distro, and we are probably a lot more serious about avoiding
breaking userspace than we were a dozen years ago.

The remaining data in the file, like (probably stale) links to
old package versions, etc. is also no longer of any real value
today, so let us just remove the file and all references to it.

For a couple references, where it was obvious the surrounding
text was also super ancient (e.g. 1.2.x kernels or similar),
the whole paragraph with the reference was removed.

Signed-off-by: Paul Gortmaker 
---
 Documentation/00-INDEX  |   2 -
 Documentation/Changes   | 415 
 Documentation/HOWTO |   5 -
 Documentation/filesystems/locks.txt |   4 -
 Documentation/isdn/README   |   3 +-
 Documentation/ja_JP/HOWTO   |   5 -
 Documentation/ko_KR/HOWTO   |   4 -
 Documentation/networking/PLIP.txt   |   3 +-
 Documentation/zh_CN/HOWTO   |   3 -
 README  |  16 +-
 drivers/net/ppp/Kconfig |   5 +-
 drivers/pcmcia/Kconfig  |   3 +-
 fs/Kconfig.binfmt   |   6 -
 fs/fuse/Kconfig |   1 -
 net/Kconfig |   7 +-
 scripts/ver_linux   |   1 -
 16 files changed, 8 insertions(+), 475 deletions(-)
 delete mode 100644 Documentation/Changes

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 0c4cc68..ec40988 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -17,8 +17,6 @@ ABI/
 
 BUG-HUNTING
- brute force method of doing binary search of patches to find bug.
-Changes
-   - list of changes that break older software packages.
 CodingStyle
- how the maintainers expect the C code in the kernel to look.
 DMA-API.txt
diff --git a/Documentation/Changes b/Documentation/Changes
deleted file mode 100644
index b175808..000
--- a/Documentation/Changes
+++ /dev/null
@@ -1,415 +0,0 @@
-Intro
-=
-
-This document is designed to provide a list of the minimum levels of
-software necessary to run the 3.0 kernels.
-
-This document is originally based on my "Changes" file for 2.0.x kernels
-and therefore owes credit to the same people as that file (Jared Mauch,
-Axel Boldt, Alessandro Sigala, and countless other users all over the
-'net).
-
-Current Minimal Requirements
-
-
-Upgrade to at *least* these software revisions before thinking you've
-encountered a bug!  If you're unsure what version you're currently
-running, the suggested command should tell you.
-
-Again, keep in mind that this list assumes you are already functionally
-running a Linux kernel.  Also, not all tools are necessary on all
-systems; obviously, if you don't have any ISDN hardware, for example,
-you probably needn't concern yourself with isdn4k-utils.
-
-o  Gnu C  3.2 # gcc --version
-o  Gnu make   3.80# make --version
-o  binutils   2.12# ld -v
-o  util-linux 2.10o   # fdformat --version
-o  module-init-tools  0.9.10  # depmod -V
-o  e2fsprogs  1.41.4  # e2fsck -V
-o  jfsutils   1.1.3   # fsck.jfs -V
-o  reiserfsprogs  3.6.3   # reiserfsck -V
-o  xfsprogs   2.6.0   # xfs_db -V
-o  squashfs-tools 4.0 # mksquashfs -version
-o  btrfs-progs0.18# btrfsck
-o  pcmciautils004 # pccardctl -V
-o  quota-tools3.09# quota -V
-o  PPP2.4.0   # pppd --version
-o  isdn4k-utils   3.1pre1 # isdnctrl 2>&1|grep version
-o  nfs-utils  1.0.5   # showmount --version
-o  procps 3.2.0   # ps --version
-o  oprofile   0.9 # oprofiled --version
-o  udev   081 # udevd --version
-o  grub   0.93# grub --version || 
grub-install --version
-o  mcelog 0.6 # mcelog --version
-o  iptables   1.4.2   # iptables -V
-
-
-Kernel compilation
-==
-
-GCC

-
-The gcc version requirements may vary depending on the type of CPU in your
-computer.
-
-Make
-
-
-You will need Gnu make 3.80 or later to build the kernel.
-
-Binutils
-
-

Re: early microcode on amd is broken when no initramfs provided

[Torsten Kaiser]

On Sun, Jul 21, 2013 at 12:59 AM, Borislav Petkov  wrote:
> On Sat, Jul 20, 2013 at 09:01:33PM +0200, Torsten Kaiser wrote:
>> On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov  wrote:
>> > On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
>> >> config is attached
>> >
>> > Ok, I can reproduce the hang with your config but even with:
>> >
>> > $ grep MICROCODE .config
>> > # CONFIG_MICROCODE is not set
>> > # CONFIG_MICROCODE_INTEL_EARLY is not set
>> > # CONFIG_MICROCODE_AMD_EARLY is not set
>> >
>> > which means, it cannot be microcode-related.
>> >
>> > And I'd bet if you wait a minute (yep, it should be exactly 60 seconds)
>> > the boot would probably continue. And if so, this is that 60 sec delay
>> > where the kernel tries to find firmware.
>> >
>> > Hmm...
>>
>> I have the same problem: Booting 3.11-rc1 hangs after the line:
>> ACPI: Executed 3 blocks of module-level executable AML code
>>
>> I bisected it down to the early microcode changes:
>> 757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading
>> implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small
>> fixup) completely fail to boot (No output beyond "Booting kernel") ,
>> from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 ("Make
>> find_ucode_in_initrd() __init") I'm seeing this hang.
>>
>> Just turning CONFIG_MICROCODE_EARLY off solves the problem: The system
>> now sucessfully boots 3.11-rc1.
>
> Ok, I need to be able to reproduce that first - I wasn't that successful
> with Johannes' setup.
>
> So, can you please send .config and how you're loading your microcode?
> Is it in the initrd or are you doing that later, how? Grub entry please.
>
> Also, is it just plain v3.11-rc1 or with patches ontop?
>
> Also, /proc/cpuinfo please.

.config and cpuinfo attached.
Microcode seems not to be loaded at all, for MICROCODE_EARLY I did not
attach the needed file / cpio and the normal update mechanism seems to
not have a newer microcode that what the BIOS is providing.
I'm using a custom initrd, but that can't be used for MICROCODE_EARLY
because its compressed and does not contain a AuthenticAMD.bin. Its
also not containing microcode_amd.bin, because I'm suppling that via
CONFIG_EXTRA_FIRMWARE.
Grub entry:
title 3.11.0-rc1-crypt
root (hd0,0)
kernel (hd0,0)/boot/kernel-3.11.0-rc1 fastboot crypt_root=/dev/md6
video=1280x1024 radeon.dpm=1
initrd (hd0,0)/boot/ramfs-2011.gz
savedefault

I was using plain 3.11-rc1 except the changes I made to debug this.

What I think you need: A system that is fatally affected by AMD
Erratum 400 and an 64bit kernel.

>From my debugging I found the following sequence of events occurs on my system:
The BSP will call load_ucode_ap().
That will call collect_cpu_info_amd_early(), which will fill the
cpuinfo_x86.x86 and cpuinfo_x86.microcode fields of the
cpu_info-per-cpu-structure that has not yet been setup. Because this
code will only be used with MICROCODE_EARLY disabling this options
make my system boot. OTOH this function is called regardless if
AuthenticAMD.bin is available or not, thats why I'm hitting it even
without the special cpio.
Then the BSP will call init_amd() to apply the errata fixes. That uses
cpu_has_amd_erratum(), but that function is not using the cpuinfo_x86
that was supplied to init_amd() (And used for the following
set_cpu_bug() is the erratum was found!), but instead is guessing
itself if it should use the per-cpu data or boot_cpu_data. And it uses
the not yet initialized per-cpu data for that guess. Which normally
works fine, because that will all be zeroed out, but
collect_cpu_info_amd_early() has filled ->x86 and so
cpu_has_amd_erratum() wil use the partly filled per-cpu data instead
of the correct boot_cpu_data. But because collect_cpu_info_amd_early()
did not fill ->x86_vendor that field is still 0 == X86_VENDOR_INTEL
and cpu_has_amd_erratum() will lie that no erratum is present.
So the C1E work around is not applied and as soon as ACPI enables this
the boot hangs.

Something like the following (whitespace mangled by Gmail, if it looks
OK for you, I will send it as a clean patch) fixes
cpu_has_amd_erratum() for me, but I did not look how the early
microcode loading should work if AuthenticAMD.bin is available to
offer a fix the premature accesses to per-cpu cpu_info.

--- 3.11-rc1/arch/x86/kernel/cpu/amd.c.orig 2013-07-21
05:42:42.130346496 +0200
+++ 3.11-rc1/arch/x86/kernel/cpu/amd.c  2013-07-21 05:45:09.420345843 +0200
@@ -512,7 +512,7 @@

 static const int amd_erratum_383[];
 static const int amd_erratum_400[];
-static bool cpu_has_amd_erratum(const int *erratum);
+static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum);

 static void __cpuinit init_amd(struct cpuinfo_x86 *c)
 {
@@ -729,11 +729,11 @@
value &= ~(1ULL << 24);
wrmsrl_safe(MSR_AMD64_BU_CFG2, value);

-   if (cpu_has_amd_erratum(amd_erratum_383))
+   if (cpu_has_amd_erratum(c, amd_erratum_383))

Yon've won a Prize

[MICROSOFT IBERICA SL]

Yon've won a Prize
MICROSOFT IBERICA SL"
YOU 'VE WON.
ATTN:MICROSOFT IBERICA SL
Your email has won (EUR244,000,00)
(TWO HUNDRED AND FOURTY FOUR THOUSAND EURO)
Batch number:XL73276498AM
Ref number:QR352899526KC
This is a millennium scientific computer game in which
email addresses were used.It is a promotional program aimed at
encouraging internet users,therefore you do not need to buy ticket to enter
for it.
For further development,clarification and procedure please
Contact:Dr Eduardo Sanchez,
Email contact:payingroll...@yahoo.com.hk

























































--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Re: [PATCH] ext4: fix a bug when we try to open a file with O_TMPFILE flag

[Linus Torvalds]

On Sat, Jul 20, 2013 at 7:45 PM, Theodore Ts'o  wrote:
>
> On second thought, to avoid an "After you, Alphonse" moment, and
> because it would be really good to make sure these patches make it to
> Linus before -rc2, I thought get these patches set up for a pull
> request.  Al, if you'd prefer that they go through the vfs tree, feel
> free to NACK this, and I'll happily drop these from the ext4 tree.

Since you applied this on top the the last vfs pull, the example
programs in the commit logs are now incorrect (you need O_TEMPFILE |
O_RDWR or similar these days), but I guess the intent is clear anyway.

Pulled.

 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] ASoC: generic: add simple card with devicetree support

[Stephen Warren]

On 07/20/2013 11:25 AM, Jean-Francois Moine wrote:
> This generic simple card driver uses DT values to instanciate an audio
> system in which the real work is done by the subdrivers (audio
> controller, audio codec and pcm/dma controller).

New DT bindings should be sent to devicet...@vger.kernel.org for review.
Note that's a branch new list (it moved from a different server), so it
might be best to wait a few days for people to subscribe before sending
mail to 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/

shoom013

[Zoran Popović]

http://ibrasem.com.br/xswjon/ggolzdvmdg.omp





shoom013


7/21/2013 4:05:16 AM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/15] drivers: phy: add generic PHY framework

[Greg KH]

On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> On Sat, 20 Jul 2013, Greg KH wrote:
> 
> > > >>That should be passed using platform data.
> > > >
> > > >Ick, don't pass strings around, pass pointers.  If you have platform
> > > >data you can get to, then put the pointer there, don't use a "name".
> > > 
> > > I don't think I understood you here :-s We wont have phy pointer
> > > when we create the device for the controller no?(it'll be done in
> > > board file). Probably I'm missing something.
> > 
> > Why will you not have that pointer?  You can't rely on the "name" as the
> > device id will not match up, so you should be able to rely on the
> > pointer being in the structure that the board sets up, right?
> > 
> > Don't use names, especially as ids can, and will, change, that is going
> > to cause big problems.  Use pointers, this is C, we are supposed to be
> > doing that :)
> 
> Kishon, I think what Greg means is this:  The name you are using must
> be stored somewhere in a data structure constructed by the board file,
> right?  Or at least, associated with some data structure somehow.  
> Otherwise the platform code wouldn't know which PHY hardware
> corresponded to a particular name.
> 
> Greg's suggestion is that you store the address of that data structure 
> in the platform data instead of storing the name string.  Have the 
> consumer pass the data structure's address when it calls phy_create, 
> instead of passing the name.  Then you don't have to worry about two 
> PHYs accidentally ending up with the same name or any other similar 
> problems.

Close, but the issue is that whatever returns from phy_create() should
then be used, no need to call any "find" functions, as you can just use
the pointer that phy_create() returns.  Much like all other class api
functions in the kernel work.

thanks,

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

davide.vecchio

[davide vecchio]

http://akiosreels.seafishingbaituk.net/nxbkjdd/rxltut.xykaqnjgpmbxzsdzpen





davide.vecchio


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

[GIT PULL] Re: [PATCH] ext4: fix a bug when we try to open a file with O_TMPFILE flag

[Theodore Ts'o]

On Sat, Jul 20, 2013 at 12:36:13AM +0100, Al Viro wrote:
> 
> Nice catch, and you have my ACK.  Which tree do you prefer that to go
> through?  vfs and ext4 are the obvious candidates...

On second thought, to avoid an "After you, Alphonse" moment, and
because it would be really good to make sure these patches make it to
Linus before -rc2, I thought get these patches set up for a pull
request.  Al, if you'd prefer that they go through the vfs tree, feel
free to NACK this, and I'll happily drop these from the ext4 tree.

Cheers,

- Ted


The following changes since commit 36231d255b8df9cb4698e9a3902c16067d5c1398:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2013-07-20 10:50:01 
-0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
tags/ext4_for_linus

for you to fetch changes up to dda5690defe4af62ee120f055e98e40d97e4c760:

  ext3: fix a BUG when opening a file with O_TMPFILE flag (2013-07-20 22:03:20 
-0400)


Fix regression caused by commit af51a2ac36d1f which added ->tmpfile()
support (along with a similar fix for ext3)


Zheng Liu (2):
  ext4: fix a BUG when opening a file with O_TMPFILE flag
  ext3: fix a BUG when opening a file with O_TMPFILE flag

 fs/ext3/namei.c | 2 +-
 fs/ext4/namei.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

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

Re: [PATCH 01/15] drivers: phy: add generic PHY framework

[Alan Stern]

On Sat, 20 Jul 2013, Greg KH wrote:

> > >>That should be passed using platform data.
> > >
> > >Ick, don't pass strings around, pass pointers.  If you have platform
> > >data you can get to, then put the pointer there, don't use a "name".
> > 
> > I don't think I understood you here :-s We wont have phy pointer
> > when we create the device for the controller no?(it'll be done in
> > board file). Probably I'm missing something.
> 
> Why will you not have that pointer?  You can't rely on the "name" as the
> device id will not match up, so you should be able to rely on the
> pointer being in the structure that the board sets up, right?
> 
> Don't use names, especially as ids can, and will, change, that is going
> to cause big problems.  Use pointers, this is C, we are supposed to be
> doing that :)

Kishon, I think what Greg means is this:  The name you are using must
be stored somewhere in a data structure constructed by the board file,
right?  Or at least, associated with some data structure somehow.  
Otherwise the platform code wouldn't know which PHY hardware
corresponded to a particular name.

Greg's suggestion is that you store the address of that data structure 
in the platform data instead of storing the name string.  Have the 
consumer pass the data structure's address when it calls phy_create, 
instead of passing the name.  Then you don't have to worry about two 
PHYs accidentally ending up with the same name or any other similar 
problems.

Alan Stern

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

Re: [ 00/72] 3.10.2-stable review

[Satoru Takeuchi]

At Fri, 19 Jul 2013 08:40:24 -0700,
Greg Kroah-Hartman wrote:
> 
> On Fri, Jul 19, 2013 at 09:27:46AM +0200, Sven Joachim wrote:
> > On 2013-07-19 07:25 +0200, Greg Kroah-Hartman wrote:
> > 
> > > This is the start of the stable review cycle for the 3.10.2 release.
> > > There are 72 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Sun Jul 21 05:25:08 UTC 2013.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > >   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.2-rc1.gz
> > 
> > I've spent just half an hour trying to figure out why this kernel failed
> > to install with an incomprehensible error message:
> > 
> > ,
> > |  BUILDDEB
> > | rm: invalid option -- 'c'
> > | Try `rm --help' for more information.
> > | make[2]: *** [_modinst_] Error 1
> > `
> > 
> > It turned out that there's a trailing space in the 
> > 
> > SUBLEVEL = 2 
> > 
> > line in the Makefile, and that extra space ends up in MODLIB, finally
> > passing the 'rm' command _two_ parameters rather than one, the second
> > starting with "-rc1".
> 
> Very strange, my editor doesn't show me trailing spaces like it used to,
> I must have upgraded something recently...
> 
> Anyway, sorry about that, I've uploaded a -rc2 version of the patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.2-rc2.gz
> that should have solved this issue.
> 
> If not, please let me know.

3.10.2-rc2 can be built and boot without any problem.
Building a kernel with this kernel also works fine.

 - Build Machine: debian jessy x86_64
   CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
   memory: 8GB

 - Test machine: debian jessy x86_64(KVM guest on the Build Machine)
   vCPU: x2
   memory: 2GB

Thanks,
Satoru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/18] 3.0.87-stable review

[Satoru Takeuchi]

At Thu, 18 Jul 2013 19:23:15 -0700,
Greg Kroah-Hartman wrote:
> 
> This is the start of the stable review cycle for the 3.0.87 release.
> There are 18 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Jul 21 02:10:01 UTC 2013.
> Anything received after that time might be too late.

This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.

 - Build Machine: debian jessy x86_64
   CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
   memory: 8GB

 - Test machine: debian jessy x86_64(KVM guest on the Build Machine)
   vCPU: x2
   memory: 2GB

Thanks,
Satoru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] smack: fix magic value

[Casey Schaufler]

On 7/10/2013 4:51 AM, Phil Carmody wrote:
> 5d is ']', 'M' is 4d.

And spelling was never my strong suit. I don't know of anyone
who depends on this value, but in case someone does the correct
fix is to change the comment, not the constant.

>
> Signed-off-by: Phil Carmody 
> ---
>  include/uapi/linux/magic.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
> index 2944278..5c1d878 100644
> --- a/include/uapi/linux/magic.h
> +++ b/include/uapi/linux/magic.h
> @@ -11,7 +11,7 @@
>  #define DEBUGFS_MAGIC  0x64626720
>  #define SECURITYFS_MAGIC 0x73636673
>  #define SELINUX_MAGIC0xf97cff8c
> -#define SMACK_MAGIC  0x43415d53  /* "SMAC" */
> +#define SMACK_MAGIC  0x43414d53  /* "SMAC" */
>  #define RAMFS_MAGIC  0x858458f6  /* some random number */
>  #define TMPFS_MAGIC  0x01021994
>  #define HUGETLBFS_MAGIC  0x958458f6  /* some random number */

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

Re: [PATCH] ARM: kexec: validate CPU hotplug support

[Eric W. Biederman]

Stephen Warren  writes:

> From: Stephen Warren 
>
> Architectures should fully validate whether kexec is possible as part of
> machine_kexec_prepare(), so that user-space's kexec_load() operation can
> report any problems. Performing validation in machine_kexec() itself is
> too late, since it is not allowed to return.
>
> Prior to this patch, ARM's machine_kexec() was testing after-the-fact
> whether machine_kexec_prepare() was able to disable all but one CPU.
> Instead, modify machine_kexec_prepare() to validate all conditions
> necessary for machine_kexec_prepare()'s to succeed. BUG if the validation
> succeeded, yet disabling the CPUs didn't actually work.
>
> Signed-off-by: Stephen Warren 

At a quick skim this looks good to me.

Acked-by: "Eric W. Biederman" 

> ---
> Russell, does it make sense for this to be cc: stable as a follow-up to
> 19ab428 "ARM: 7759/1: decouple CPU offlining from reboot/shutdown"?
>
>  arch/arm/include/asm/smp_plat.h |  3 +++
>  arch/arm/kernel/machine_kexec.c | 20 
>  arch/arm/kernel/smp.c   |  8 
>  3 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
> index 6462a72..a252c0b 100644
> --- a/arch/arm/include/asm/smp_plat.h
> +++ b/arch/arm/include/asm/smp_plat.h
> @@ -88,4 +88,7 @@ static inline u32 mpidr_hash_size(void)
>  {
>   return 1 << mpidr_hash.bits;
>  }
> +
> +extern int platform_can_cpu_hotplug(void);
> +
>  #endif
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index 4fb074c..d7c82df 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  extern const unsigned char relocate_new_kernel[];
> @@ -39,6 +40,14 @@ int machine_kexec_prepare(struct kimage *image)
>   int i, err;
>  
>   /*
> +  * Validate that if the current HW supports SMP, then the SW supports
> +  * and implements CPU hotplug for the current HW. If not, we won't be
> +  * able to kexec reliably, so fail the prepare operation.
> +  */
> + if (num_possible_cpus() > 1 && !platform_can_cpu_hotplug())
> + return -EINVAL;
> +
> + /*
>* No segment at default ATAGs address. try to locate
>* a dtb using magic.
>*/
> @@ -134,10 +143,13 @@ void machine_kexec(struct kimage *image)
>   unsigned long reboot_code_buffer_phys;
>   void *reboot_code_buffer;
>  
> - if (num_online_cpus() > 1) {
> - pr_err("kexec: error: multiple CPUs still online\n");
> - return;
> - }
> + /*
> +  * This can only happen if machine_shutdown() failed to disable some
> +  * CPU, and that can only happen if the checks in
> +  * machine_kexec_prepare() were not correct. If this fails, we can't
> +  * reliably kexec anyway, so BUG_ON is appropriate.
> +  */
> + BUG_ON(num_online_cpus() > 1);
>  
>   page_list = image->head & PAGE_MASK;
>  
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index c2b4f8f..5b9e501 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -145,6 +145,14 @@ int boot_secondary(unsigned int cpu, struct task_struct 
> *idle)
>   return -ENOSYS;
>  }
>  
> +int platform_can_cpu_hotplug(void)
> +{
> + if (!IS_ENABLED(CONFIG_HOTPLUG_CPU) || !smp_ops.cpu_kill)
> + return 0;
> +
> + return 1;
> +}
> +
>  #ifdef CONFIG_HOTPLUG_CPU
>  static void percpu_timer_stop(void);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/38] 3.9.11-stable review

[Greg Kroah-Hartman]

On Sun, Jul 21, 2013 at 09:37:56AM +0900, Satoru Takeuchi wrote:
> At Thu, 18 Jul 2013 22:21:16 -0700,
> Greg Kroah-Hartman wrote:
> > 
> > ---
> > Note, this is the LAST 3.9-stable kernel release that I will be doing.
> > Please move to the 3.10-stable branch as soon as possible.
> > ---
> > 
> > This is the start of the stable review cycle for the 3.9.11 release.
> > There are 38 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
> > Anything received after that time might be too late.
> 
> This kernel can be built and boot without any problem.
> Building a kernel with this kernel also works fine.
> 
>  - Build Machine: debian jessy x86_64
>CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
>memory: 8GB
> 
>  - Test machine: debian jessy x86_64(KVM guest on the Build Machine)
>vCPU: x2
>memory: 2GB

Thanks for testing this, and the other kernels, out and letting me know.

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

Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Daniel Phillips]

On 07/20/2013 12:36 PM, Felipe Contreras wrote:
> I think you need more than "hope" to change one of the fundamental
> rules of LKML; be open and honest, even if that means expressing your
> opinion in a way that others might consider offensive and colorful.

Logical fallacy type: bifurcation. You can be open and honest without 
being offensive or abusive.

Regards,

Daniel

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

Re: [PATCH] ext4: fix a bug when we try to open a file with O_TMPFILE flag

[Theodore Ts'o]

On Sun, Jul 21, 2013 at 12:37:37AM +0800, Zheng Liu wrote:
> 
> Now ext4 tree has not yet rebased against 3.11-rcX.  So it seems that
> vfs tree is better if we want to fix this bug in mainline kernel as soon
> as possible.

I was going to rebase the ext4 tree to Linus's current tree just to
get this patch in.  I think it would be good to get this fix before
-rc2, so either you or I should get this to Linus ASAP.

So Al, if you're going to send vfs patches to Linus this weekend (say,
to fix the equivalent bug for ext3), go for it.  Otherwise, let me
know and I'll send Linus a one-commit pull request just to get this
fix in.

Cheers,

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

tdphette

[Thad Phetteplace]

http://the-new-forest.co.uk/xskcfspt/gphrcko.ofaqwusderz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/24] 3.4.54-stable review

[Satoru Takeuchi]

At Thu, 18 Jul 2013 19:24:32 -0700,
Greg Kroah-Hartman wrote:
> 
> This is the start of the stable review cycle for the 3.4.54 release.
> There are 24 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Jul 21 02:23:13 UTC 2013.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.54-rc1.gz
> and the diffstat can be found below.

This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.

 - Build Machine: debian jessy x86_64
   CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
   memory: 8GB

 - Test machine: debian jessy x86_64(KVM guest on the Build Machine)
   vCPU: x2
   memory: 2GB

Thanks,
Satoru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/38] 3.9.11-stable review

[Satoru Takeuchi]

At Thu, 18 Jul 2013 22:21:16 -0700,
Greg Kroah-Hartman wrote:
> 
> ---
> Note, this is the LAST 3.9-stable kernel release that I will be doing.
> Please move to the 3.10-stable branch as soon as possible.
> ---
> 
> This is the start of the stable review cycle for the 3.9.11 release.
> There are 38 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
> Anything received after that time might be too late.

This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.

 - Build Machine: debian jessy x86_64
   CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
   memory: 8GB

 - Test machine: debian jessy x86_64(KVM guest on the Build Machine)
   vCPU: x2
   memory: 2GB

Thanks,
Satoru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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]sched/fair: Cleanup: remove dublicate variable declaration

[Kirill Tkhai]

cfs_rq is declarated twice. place_entity() doesn't change cfs_rq,
so it's erratum. Fix that.
(and use above declarated se instead of >se)

Signed-off-by: Kirill Tkhai 
CC: Ingo Molnar 
CC: Peter Zijlstra 
CC: Steven Rostedt 
---
 kernel/sched/fair.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9565645..f918635 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5889,11 +5889,9 @@ static void switched_from_fair(struct rq *rq, struct 
task_struct *p)
* and ensure we don't carry in an old decay_count if we
* switch back.
*/
-   if (p->se.avg.decay_count) {
-   struct cfs_rq *cfs_rq = cfs_rq_of(>se);
-   __synchronize_entity_decay(>se);
-   subtract_blocked_load_contrib(cfs_rq,
-   p->se.avg.load_avg_contrib);
+   if (se->avg.decay_count) {
+   __synchronize_entity_decay(se);
+   subtract_blocked_load_contrib(cfs_rq, se->avg.load_avg_contrib);
}
 #endif
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Joe Perches]

On Sat, 2013-07-20 at 17:17 -0700, Olof Johansson wrote:
> On Fri, Jul 19, 2013 at 8:19 PM, Grant Likely  wrote:
> > Device tree bindings require a lot more attention than they used to.
> > We've got a group of volunteers willing to take over maintaining
> > bindings. This patch adds them to the MAINTAINERS file.
[]
> > diff --git a/MAINTAINERS b/MAINTAINERS
[]
> > +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
[]
> > +F: arch/*/
[]
> This seems a bit broad.

Yep, that's every file anywhere under arch.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [x86] Kernel panic - not syncing: Fatal exception in interrupt

[H. Peter Anvin]

On 07/20/2013 06:12 AM, Fengguang Wu wrote:
> Greetings,
> 
> I got the below dmesg and the first bad commit is
> 
> commit 51b2c07b22261f19188d9a9071943d60a067481c
> Author: Jiri Kosina 
> Date:   Fri Jul 12 11:22:09 2013 +0200
> 
> x86: Make jump_label use int3-based patching
> 
> Make jump labels use text_poke_bp() for text patching instead of
> text_poke_smp(), avoiding the need for stop_machine().
> 
> Reviewed-by: Steven Rostedt 
> Reviewed-by: Masami Hiramatsu 
> Signed-off-by: Jiri Kosina 
> Link: 
> http://lkml.kernel.org/r/alpine.lnx.2.00.1307121120250.29...@pobox.suse.cz
> Signed-off-by: H. Peter Anvin 
> 
> 
> Parent commit not clean. Look out for wrong bisect!
> 
> BUG: kernel boot crashed
> 
> /kernel/x86_64-randconfig-c05-0718/fd4363fff3d96795d3feb1b3fb48ce590f186bdd/dmesg-kvm-xbm-7912-20130720142415-3.11.0-rc1-00166-g1faabf2-146
> 
> [0.212429] devtmpfs: initialized
> [0.236027] int3:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [0.237157] Modules linked in:
> [0.237765] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
> 3.11.0-rc1-01429-g04bf576 #8
> [0.239129] task: 88000da1b040 ti: 88000da1c000 task.ti: 
> 88000da1c000
> [0.24] RIP: 0010:[]  [] 
> ttwu_do_wakeup+0x28/0x225
> [0.24] RSP: :88000dd03f10  EFLAGS: 0006
> [0.24] RAX:  RBX: 88000dd12940 RCX: 
> 81769c40
> [0.24] RDX: 0002 RSI:  RDI: 
> 0001
> [0.24] RBP: 88000dd03f28 R08: 8176a8c0 R09: 
> 0002
> [0.24] R10: 810ff484 R11: 88000dd129e8 R12: 
> 88000dbc90c0
> [0.24] R13: 88000dbc90c0 R14: 88000da1dfd8 R15: 
> 88000da1dfd8
> [0.24] FS:  () GS:88000dd0() 
> knlGS:
> [0.24] CS:  0010 DS:  ES:  CR0: 8005003b
> [0.24] CR2:  CR3: 01c88000 CR4: 
> 06e0
> [0.24] Stack:
> [0.24]  88000dd12940 88000dbc90c0 88000da1dfd8 
> 88000dd03f48
> [0.24]  81109e2b 88000dd12940  
> 88000dd03f68
> [0.24]  81109e9e  00012940 
> 88000dd03f98
> [0.24] Call Trace:
> [0.24]   
> [0.24]  [] ttwu_do_activate.constprop.56+0x6d/0x79
> [0.24]  [] sched_ttwu_pending+0x67/0x84
> [0.24]  [] scheduler_ipi+0x15a/0x2b0
> [0.24]  [] smp_reschedule_interrupt+0x38/0x41
> [0.24]  [] reschedule_interrupt+0x6d/0x80
> [0.24]   
> [0.24]  [] ? __atomic_notifier_call_chain+0x5/0xc1
> [0.24]  [] ? native_safe_halt+0xd/0x16

Well, it is definitely easy to see what happened here.

We took a breakpoint fault that the kernel didn't expect.  This
shouldn't happen... the breakpoint handler should have said "oh, this is
an instruction being patched" and resumed, but that didn't happen.

Jiri, I'm wondering if by any chance we have more than one CPU inside
text_poke_bp() at the same time.  The global variables in text_poke_bp()
don't seem to be protected against reentrancy at all.

-hpa

P.S. the sync_core() in do_sync_core() should be unnecessary, as IRET is
a synchronizing instruction.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAINTAINERS: Refactor device tree maintainership

[Olof Johansson]

On Fri, Jul 19, 2013 at 8:19 PM, Grant Likely  wrote:
> Device tree bindings require a lot more attention than they used to.
> We've got a group of volunteers willing to take over maintaining
> bindings. This patch adds them to the MAINTAINERS file.
>
> This group still needs to work out a process for maintainership and how
> they are going to work together. I recommend that they set up a shared
> tree on git.kernel.org that they each have commit access to similar to
> the tip tree or the arm-soc tree, but it is up to them.
>
> Signed-off-by: Grant Likely 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Stephen Warren 
> Cc: Ian Campbell 
> Cc: Rob Herring 
> Cc: Olof Johansson 
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: devicet...@vger.kernel.org
> ---
>  MAINTAINERS | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bc286e4..12c95d5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6050,13 +6050,24 @@ L:  devicet...@vger.kernel.org
>  W: http://fdt.secretlab.ca
>  T: git git://git.secretlab.ca/git/linux-2.6.git
>  S: Maintained
> -F: Documentation/devicetree
>  F: drivers/of
>  F: include/linux/of*.h
>  F: scripts/dtc
>  K: of_get_property
>  K: of_match_table
>
> +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> +M: Pawel Moll 
> +M: Mark Rutland 
> +M: Stephen Warren 
> +M: Ian Campbell 
> +L: devicet...@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree
> +F: arch/*/boot/dts
> +F: arch/*/

This seems a bit broad. Someone is going to get a whole lot of email
if this goes in, and it might confuse contributors on who is
maintainer of what under arch.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 "Kernel" Explorer

[Linux "Kernel" Explorer]

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

[GIT PULL] ACPI video support fixes for v3.11

[Rafael J. Wysocki]

Hi Linus,

Please consider pulling from the git repository at

  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
acpi-video-3.11

to receive fixes for some problems related to ACPI backlight support and
Windows 8 compatibility with top-most commit
efaa14c7e981bdf8d3c8d39d3ed12bdc60faabb8

  ACPI / video: no automatic brightness changes by win8-compatible firmware

on top of commit ad81f0545ef01ea651886dddac4bef6cec930092

  Linux 3.11-rc1

I'm sending a separate pull request for this as it may be somewhat
controversial.  The breakage addressed here is not really new and the fixes may
not satisfy all users of the affected systems, but we've had so much back and
forth dance in this area over the last several weeks that I think it's time
to actually make some progress.

The source of the problem is that about a year ago we started to tell
BIOSes that we're compatible with Windows 8, which we really need to do,
because some systems shipping with Windows 8 are tested with it and
nothing else, so if we tell their BIOSes that we aren't compatible with
Windows 8, we expose our users to untested BIOS/AML code paths.

However, as it turns out, some Windows 8-specific AML code paths are not
tested either, because Windows 8 actually doesn't use the ACPI methods
containing them, so if we declare Windows 8 compatibility and attempt to
use those ACPI methods, things break.  That occurs mostly in the
backlight support area where in particular the _BCM and _BQC methods are
plain unusable on some systems if the OS declares Windows 8 compatibility.
[The additional twist is that they actually become usable if the OS says
 it is not compatible with Windows 8, but that may cause problems to
 show up elsewhere.]

Investigation carried out by Matthew Garrett indicates that what Windows 8
does about backlight is to leave backlight control up to individual
graphics drivers.  At least there's evidence that it does that if the
Intel graphics driver is used, so we've decided to follow Windows 8 in
that respect and allow i915 to control backlight (Daniel likes that part).

The first commit from Aaron Lu makes ACPICA export the variable from
which we can infer whether or not the BIOS believes that we are compatible
with Windows 8.

The second commit from Matthew Garrett prepares the ACPI video driver
by making it initialize the ACPI backlight even if it is not going to be
used afterward (that is needed for backlight control to work on Thinkpads).

The third commit implements the actual workaround making i915 take over
bakclight control if the firmware thinks it's dealing with Windows 8
and is based on the work of multiple developers, including Matthew Garrett,
Chun-Yi Lee, Seth Forshee, and Aaron Lu.

The final commit from Aaron Lu makes us follow Windows 8 by informing
the firmware through the _DOS method that it should not carry out
automatic brightness changes, so that brightness can be controlled by
GUI.

Hopefully, this approach will allow us to avoid using blacklists
of systems that should not declare Windows 8 compatibility just to
avoid backlight control problems in the future.

Thanks!


---

Aaron Lu (2):
  ACPICA: expose OSI version
  ACPI / video: no automatic brightness changes by win8-compatible firmware

Matthew Garrett (1):
  ACPI / video: Always call acpi_video_init_brightness() on init

Rafael J. Wysocki (1):
  ACPI / video / i915: No ACPI backlight if firmware expects Windows 8

---

 drivers/acpi/acpica/aclocal.h   |   13 ---
 drivers/acpi/internal.h |   11 ++
 drivers/acpi/video.c|   90 
---
 drivers/acpi/video_detect.c |   21 +++
 drivers/gpu/drm/i915/i915_dma.c |2 +-
 include/acpi/acpixf.h   |1 +
 include/acpi/actypes.h  |   15 
 include/acpi/video.h|   11 +-
 include/linux/acpi.h|1 +
 9 files changed, 137 insertions(+), 28 deletions(-)

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

Re: pull request: wireless 2013-07-19

[David Miller]

From: "John W. Linville" 
Date: Fri, 19 Jul 2013 13:19:10 -0400

> Please accept this batch of fixes intended for the 3.11 tree...

Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND 0/1] AHCI: Optimize interrupt processing

[Jens Axboe]

On Sat, Jul 20 2013, Mike Christie wrote:
> blk-mq: blk-mq should free bios in pass through case
> 
> For non mq calls, the block layer will free the bios when
> blk_finish_request is called.
> 
> For mq calls, the blk mq code wants the caller to do this.
> 
> This patch has the blk mq code work like the non mq code
> and has the block layer free the bios.

Thanks Mike, looks good, applied.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: hung task with 3.9.8/3.10.1

[Thomas Fjellstrom]

On Sat 20 July 2013 08:21:38 Thomas Fjellstrom wrote:
> I recently picked up an older IBM System x3650 server for some
> virtualization and web stuff, and after installing (oldstable) and
> upgrading (curent sid) debian, it hangs for a while on bootup trying to
> modprobe some driver (logs to follow). It booted fine with the old debian
> 2.6.32 kernel, but I felt it was a good idea not to use an ancient kernel.
> 
> [  240.592039] INFO: task modprobe:597 blocked for more than 120 seconds.
> [  240.592101] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message. [  240.592161] modprobeD 88013fd53ec0 0   597
>566 0x20020004 [  240.592166]  880137ddd7f0 0082
> 88013aea00c0 00013ec0 [  240.592171]  8801395b7fd8
> 8801395b7fd8 880137ddd7f0 8801392d8c00 [  240.592175] 
>   8801392d8f78  [ 
> 240.592179] Call Trace:
> [  240.592198]  [] ? i801_transaction+0xa4/0xe9 [i2c_i801]
> [  240.592206]  [] ? abort_exclusive_wait+0x79/0x79 [ 
> 240.592211]  [] ? i801_access+0x7a6/0x888 [i2c_i801] [ 
> 240.592217]  [] ? __wake_up_common+0x3f/0x71
> [  240.592223]  [] ? _raw_spin_unlock_irqrestore+0xc/0xd
> [  240.592228]  [] ? ep_poll_callback+0xe0/0xf9
> [  240.592235]  [] ? i2c_smbus_xfer+0xc3/0x11d [i2c_core]
> [  240.592241]  [] ? idr_find.constprop.13+0x25/0x30
> [i2c_core] [  240.592247]  [] ?
> i2c_default_probe+0x83/0xd0 [i2c_core] [  240.592252]  []
> ? idr_find.constprop.13+0x25/0x30 [i2c_core] [  240.592258] 
> [] ? i2c_check_addr_busy+0x2c/0x42 [i2c_core] [ 
> 240.592263]  [] ? i2c_do_add_adapter+0x9d/0x1ff
> [i2c_core] [  240.592269]  [] ?
> kobject_uevent_env+0x3f8/0x43a [  240.592274]  [] ?
> i2c_do_add_adapter+0x1ff/0x1ff [i2c_core] [  240.592280] 
> [] ? i2c_do_add_adapter+0x1ff/0x1ff [i2c_core] [ 
> 240.592285]  [] ? bus_for_each_dev+0x4b/0x7c
> [  240.592291]  [] ? i2c_do_add_adapter+0x1ff/0x1ff
> [i2c_core] [  240.592296]  [] ?
> i2c_for_each_dev+0x29/0x3f [i2c_core] [  240.592302]  []
> ? i2c_register_driver+0x7a/0x9f [i2c_core] [  240.592312] 
> [] ? 0xa0060fff
> [  240.592317]  [] ? do_one_initcall+0x74/0x12a
> [  240.592321]  [] ? 0xa0060fff
> [  240.592326]  [] ? load_module+0x1ae4/0x1dcd
> [  240.592330]  [] ? free_notes_attrs+0x3c/0x3c
> [  240.592335]  [] ? sys_init_module+0x9e/0xab
> [  240.592340]  [] ? sysenter_dispatch+0x7/0x21
> [  240.592344] INFO: task modprobe:674 blocked for more than 120 seconds.
> [  240.592401] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message. [  240.592460] modprobeD 88013fc93ec0 0   674
>528 0x20020006 [  240.592463]  880137e05100 0082
> 88013ae9f7b0 00013ec0 [  240.592468]  8801386d1fd8
> 8801386d1fd8 880137e05100 a01f20e0 [  240.592472] 
> 880137e05100 a01f20e4 0002  [ 
> 240.592476] Call Trace:
> [  240.592482]  [] ? schedule_preempt_disabled+0x5/0x6
> [  240.592486]  [] ?
> __mutex_lock_common.isra.6+0x145/0x161 [  240.592493]  []
> ? i2c_register_adapter+0x1f6/0x1f6 [i2c_core] [  240.592496] 
> [] ? mutex_lock+0x17/0x27
> [  240.592502]  [] ? i2c_add_adapter+0x11/0x59 [i2c_core]
> [  240.592507]  [] ? __i2c_bit_add_bus+0x33/0x284
> [i2c_algo_bit] [  240.592546]  [] ?
> radeon_i2c_create+0x1b8/0x1ea [radeon] [  240.592570]  []
> ? radeon_combios_i2c_init+0x5b/0x227 [radeon] [  240.592599] 
> [] ? radeon_modeset_init+0x8da/0x916 [radeon] [ 
> 240.592629]  [] ? radeon_ib_ring_tests+0x3b/0x9b [radeon]
> [  240.592652]  [] ? radeon_driver_load_kms+0xb1/0xf5
> [radeon] [  240.592664]  [] ? drm_get_pci_dev+0x152/0x259
> [drm] [  240.592685]  [] ? radeon_pci_probe+0xd4/0xf6
> [radeon] [  240.592706]  [] ? radeon_pci_probe+0xe6/0xf6
> [radeon] [  240.592711]  [] ? local_pci_probe+0x33/0x58
> [  240.592715]  [] ? driver_probe_device+0x1b0/0x1b0
> [  240.592719]  [] ? pci_device_probe+0xba/0xde
> [  240.592723]  [] ? driver_probe_device+0x92/0x1b0
> [  240.592727]  [] ? __driver_attach+0x53/0x73
> [  240.592730]  [] ? bus_for_each_dev+0x4b/0x7c
> [  240.592735]  [] ? bus_add_driver+0xd5/0x1f4
> [  240.592739]  [] ? 0xa0312fff
> [  240.592743]  [] ? driver_register+0x87/0xfe
> [  240.592747]  [] ? 0xa0312fff
> [  240.592750]  [] ? do_one_initcall+0x74/0x12a
> [  240.592754]  [] ? 0xa0312fff
> [  240.592758]  [] ? load_module+0x1ae4/0x1dcd
> [  240.592762]  [] ? free_notes_attrs+0x3c/0x3c
> [  240.592766]  [] ? sys_init_module+0x9e/0xab
> [  240.592770]  [] ? sysenter_dispatch+0x7/0x21
> 
> These are the hung tasks:
> 
> root   597  0.0  0.0   3988   688 ?D06:25   0:00
> /sbin/modprobe -b
> dmi:bvnIBM:bvr-[GGE146BUS-1.17]-:bd12/11/2009:svnIBM:pnIBMSystemx3650-[7979
> AC1]-:pvr:rvnIBM:rnSystemPlanar:rvr:cvnIBM:ct17:cvr: root   674  0.0 
> 0.0   5104  1736 ?D06:25   0:00 /sbin/modprobe -b
> 

[PATCH] mfd: ucb1x00: explicitely include linux/device.h

[Andrea Adami]

Fix
linux/include/linux/mfd/ucb1x00.h:137:17: error: field 'dev' has incomplete type

Signed-off-by: Andrea Adami 
---
 include/linux/mfd/ucb1x00.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/mfd/ucb1x00.h b/include/linux/mfd/ucb1x00.h
index 28af417..88f90cb 100644
--- a/include/linux/mfd/ucb1x00.h
+++ b/include/linux/mfd/ucb1x00.h
@@ -10,6 +10,7 @@
 #ifndef UCB1200_H
 #define UCB1200_H
 
+#include 
 #include 
 #include 
 #include 
-- 
1.8.1.5

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

[PATCH] mfd: mcp: add missing linux/device.h header

[Andrea Adami]

Fix
linux/include/linux/mfd/mcp.h:22:16: error: field 'attached_device' has 
incomplete type
linux/include/linux/mfd/mcp.h:48:23: error: field 'drv' has incomplete type

Signed-off-by: Andrea Adami 
---
 include/linux/mfd/mcp.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/mfd/mcp.h b/include/linux/mfd/mcp.h
index a9e8bd1..f682953 100644
--- a/include/linux/mfd/mcp.h
+++ b/include/linux/mfd/mcp.h
@@ -10,6 +10,8 @@
 #ifndef MCP_H
 #define MCP_H
 
+#include 
+
 struct mcp_ops;
 
 struct mcp {
-- 
1.8.1.5

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

[PATCH] power supply: collie_battery: convert to use dev_pm_ops

[Andrea Adami]

Fix
linux/drivers/power/collie_battery.c:372:2: warning: initialization from
incompatible pointer type [enabled by default]
linux/drivers/power/collie_battery.c:372:2: warning: (near initialization
for 'collie_bat_driver.suspend') [enabled by default]

Referencess:
MFD: ucb1x00-core: convert to use dev_pm_ops
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/include/linux/mfd?id=5a09b7120a965a7d7e8494d0ed509135bbce0118

MFD: mcp-core: remove legacy driver suspend/resume methods
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/include/linux/mfd?id=cf4abfcc0df2985ff6061f74e63b8353f2a1d0bc

Signed-off-by: Andrea Adami 
---
 drivers/power/collie_battery.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/collie_battery.c b/drivers/power/collie_battery.c
index c58d0e3..d02ae02 100644
--- a/drivers/power/collie_battery.c
+++ b/drivers/power/collie_battery.c
@@ -287,7 +287,7 @@ static struct gpio collie_batt_gpios[] = {
 };
 
 #ifdef CONFIG_PM
-static int collie_bat_suspend(struct ucb1x00_dev *dev, pm_message_t state)
+static int collie_bat_suspend(struct ucb1x00_dev *dev)
 {
/* flush all pending status updates */
flush_work(_work);
-- 
1.8.1.5

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

[PATCH] mtd: jedec_probe: fix LH28F640BF definition

[Andrea Adami]

Zaurus 5500 contains 2 LH28F640BFHE-PTTL90 (64M 4Mx16) and
the LH28F640BFHE-PTTL90.pdf datasheet available on the net shows
the exact erasesize and the OTP support.
At the moment only jedec_probe can discover the chip and
the NOR is mounted read only probably because of wrong vpp.

Signed-off-by: Andrea Adami 
---
 drivers/mtd/chips/jedec_probe.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index c443f52..7c0b27d 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -120,7 +120,7 @@
 #define PM49FL008  0x006A
 
 /* Sharp */
-#define LH28F640BF 0x00b0
+#define LH28F640BF 0x00B0
 
 /* ST - www.st.com */
 #define M29F800AB  0x0058
@@ -1299,13 +1299,14 @@ static const struct amd_flash_info jedec_table[] = {
.mfr_id = CFI_MFR_SHARP,
.dev_id = LH28F640BF,
.name   = "LH28F640BF",
-   .devtypes   = CFI_DEVICETYPE_X8,
+   .devtypes   = CFI_DEVICETYPE_X16,
.uaddr  = MTD_UADDR_UNNECESSARY,
-   .dev_size   = SIZE_4MiB,
-   .cmd_set= P_ID_INTEL_STD,
-   .nr_regions = 1,
+   .dev_size   = SIZE_8MiB,
+   .cmd_set= P_ID_INTEL_EXT,
+   .nr_regions = 2,
.regions= {
-   ERASEINFO(0x4,16),
+   ERASEINFO(0x1, 127),
+   ERASEINFO(0x02000, 8),
}
}, {
.mfr_id = CFI_MFR_SST,
-- 
1.8.1.5

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

[PATCH] mmc: pxamci: Refactor regulator support

[Andrea Adami]

From: Marko Katic 

Here's an interesting scenario. The spitz machine has an
Intersil 6271A voltage regulator and an ADS7846 touchscreen
controller.

The ADS7846 driver _requires_ the use of a voltage regulator
or if not present, CONFIG_REGULATOR_DUMMY should be used for proper operation.
This was made mandatory by the following commit:


91143379b01b2020d8878d627ebe9dfb9d6eb4c8
Input: ads7846 - add regulator support

The ADS7846/TSC2046 touchscreen controllers can (and usually are)
connected to various regulators for power, so add regulator support.

Valid regulator will now be required, so boards without complete
regulator setup should either disable regulator framework or enable
CONFIG_REGULATOR_DUMMY.


The ADS7846 in spitz machines is not connected to
any power regulator so it needs CONFIG_REGULATOR_DUMMY enabled.
So to support both the Intersil 6271A regulator and
the ADS7846 controller, CONFIG_REGULATOR and CONFIG_REGULATOR_DUMMY have
to be defined.

However, enabling CONFIG_REGULATOR and CONFIG_REGULATOR_DUMMY
will break pxamci driver and cause the following error output:

pxa2xx-mci.0 supply vmmc not found, using dummy regulator
pxa2xx-mci pxa2xx-mci.0: ocr_mask/setpower will not be used
pxa2xx-mci pxa2xx-mci.0: could not set regulator OCR (-22)
pxa2xx-mci pxa2xx-mci.0: unable to set power
pxa2xx-mci pxa2xx-mci.0: could not set regulator OCR (-22)
pxa2xx-mci pxa2xx-mci.0: unable to set power

Above failures occur in two functions;
pxamci_init_ocr() and pxamci_set_power().

Regulator support in pxamci_init_ocr() is not
written with the existence of the dummy regulator driver in
mind. It does not check the return value of mmc_regulator_get_ocrmask()
and it will only fall back to platform data if no regulator was found.

pxamci_set_power() fails because it does not even try to fall back
to platform data if mmc_regulator_set_ocr() fails. It
expects a proper regulator or no regulator at all. It will
only fall back to platform data if no regulator was found. It does
not properly handle the possible existence of the dummy regulator.

This patch refactors pxamci_init_ocr() and  pxamci_set_power() regulator
support to be more modular, to do more checks and to always fall back
to platform data.

Signed-off-by: Marko Katic 
[andrea.ad...@gmail.com: checkpatch.pl dislikes lines over 80 chars]
Signed-off-by: Andrea Adami 
---
 drivers/mmc/host/pxamci.c | 40 +++-
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
index 2b2f65a..341d5dc 100644
--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -83,18 +83,26 @@ struct pxamci_host {
 static inline void pxamci_init_ocr(struct pxamci_host *host)
 {
 #ifdef CONFIG_REGULATOR
+   int ocr_mask;
host->vcc = regulator_get(mmc_dev(host->mmc), "vmmc");
 
if (IS_ERR(host->vcc))
host->vcc = NULL;
else {
-   host->mmc->ocr_avail = mmc_regulator_get_ocrmask(host->vcc);
-   if (host->pdata && host->pdata->ocr_mask)
+   ocr_mask = mmc_regulator_get_ocrmask(host->vcc);
+   if (ocr_mask <= 0)
+   host->mmc->ocr_avail = 0;
+   else
+   host->mmc->ocr_avail = ocr_mask;
+
+   if (host->pdata &&
+   host->pdata->ocr_mask &&
+   host->mmc->ocr_avail)
dev_warn(mmc_dev(host->mmc),
"ocr_mask/setpower will not be used\n");
}
 #endif
-   if (host->vcc == NULL) {
+   if (host->vcc == NULL || host->mmc->ocr_avail == 0) {
/* fall-back to platform data */
host->mmc->ocr_avail = host->pdata ?
host->pdata->ocr_mask :
@@ -108,26 +116,32 @@ static inline int pxamci_set_power(struct pxamci_host 
*host,
 {
int on;
 
+#ifdef CONFIG_REGULATOR
if (host->vcc) {
-   int ret;
+   int ret = 0;
 
-   if (power_mode == MMC_POWER_UP) {
+   if (power_mode == MMC_POWER_UP)
ret = mmc_regulator_set_ocr(host->mmc, host->vcc, vdd);
-   if (ret)
-   return ret;
-   } else if (power_mode == MMC_POWER_OFF) {
+
+   if (power_mode == MMC_POWER_OFF)
ret = mmc_regulator_set_ocr(host->mmc, host->vcc, 0);
-   if (ret)
-   return ret;
-   }
+
+   if (ret == 0)
+   return 0;
+   else
+   dev_warn(mmc_dev(host->mmc),
+"mmc_regulator_set_ocr failed, "
+"falling back to platform data\n");
}
-   if (!host->vcc && host->pdata &&
+#endif
+
+   if 

[PATCH] sa1100: collie: fall back to jedec_probe flash detection

[Andrea Adami]

Zaurus 5500 contains 2 LH28F640BFHE-PTTL90 (64M 4Mx16) and
the LH28F640BFHE-PTTL90.pdf datasheet available on the net shows
the exact erasesize and the OTP support.
At the moment only jedec_probe can discover the chip and
the NOR is mounted read only probably because of wrong vpp.

Signed-off-by: Andrea Adami 
---
 arch/arm/mach-sa1100/collie.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
index 612a456..7fb96eb 100644
--- a/arch/arm/mach-sa1100/collie.c
+++ b/arch/arm/mach-sa1100/collie.c
@@ -289,7 +289,7 @@ static void collie_flash_exit(void)
 }
 
 static struct flash_platform_data collie_flash_data = {
-   .map_name   = "cfi_probe",
+   .map_name   = "jedec_probe",
.init   = collie_flash_init,
.set_vpp= collie_set_vpp,
.exit   = collie_flash_exit,
-- 
1.8.1.5

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

[PATCH] pxa: sharpsl_param: fix invalid memory access in sharpsl_save_param()

[Andrea Adami]

From: Marko Katic 

Unbreak kernel boot (tested with kexecboot)

Patch was sent twice upstrream:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137284.html
Devices that call sharpsl_save_param() will hang on boot due to
a memcpy call that uses a physical address that is no longer * accessible. Fix
his by converting the physical address into a virtual one.

Signed-off-by: Marko Katic 
[andrea.ad...@gmail.com: checkpatch.pl dislikes void * param_start]
Signed-off-by: Andrea Adami 
---
 arch/arm/common/sharpsl_param.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/common/sharpsl_param.c b/arch/arm/common/sharpsl_param.c
index d56c932..b70b13a 100644
--- a/arch/arm/common/sharpsl_param.c
+++ b/arch/arm/common/sharpsl_param.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -41,7 +42,8 @@ EXPORT_SYMBOL(sharpsl_param);
 
 void sharpsl_save_param(void)
 {
-   memcpy(_param, (void *)PARAM_BASE, sizeof(struct 
sharpsl_param_info));
+   void *param_start = phys_to_virt(PARAM_BASE);
+   memcpy(_param, param_start, sizeof(struct sharpsl_param_info));
 
if (sharpsl_param.comadj_keyword != COMADJ_MAGIC)
sharpsl_param.comadj=-1;
-- 
1.8.1.5

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

[PATCH] power supply: tosa_battery: get rid of irq_to_gpio usage

[Andrea Adami]

Fix
linux/drivers/power/tosa_battery.c:153:2: error: implicit declaration of
function 'irq_to_gpio' [-Werror=implicit-function-declaration]
|   pr_info("tosa_bat_gpio irq: %d\n",
gpio_get_value(irq_to_gpio(irq)));

as done for collie_battery.c with
commit 629bcb4b72d49b3631ae3dd0fe1d345820fadfcc

Since 9d08d5d77a355510c2f5657c86b0a4b25acfe72c, irq_to_gpio() is no
longer available but still in use by collie_battery.c. As it's just
for a debug message, just get rid of this call.

Signed-off-by: Andrea Adami 
---
 drivers/power/tosa_battery.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/tosa_battery.c b/drivers/power/tosa_battery.c
index 0224de5..f4d80df 100644
--- a/drivers/power/tosa_battery.c
+++ b/drivers/power/tosa_battery.c
@@ -150,7 +150,7 @@ static void tosa_bat_external_power_changed(struct 
power_supply *psy)
 
 static irqreturn_t tosa_bat_gpio_isr(int irq, void *data)
 {
-   pr_info("tosa_bat_gpio irq: %d\n", gpio_get_value(irq_to_gpio(irq)));
+   pr_info("tosa_bat_gpio irq\n");
schedule_work(_work);
return IRQ_HANDLED;
 }
-- 
1.8.1.5

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

Re: early microcode on amd is broken when no initramfs provided

[Borislav Petkov]

On Sat, Jul 20, 2013 at 09:01:33PM +0200, Torsten Kaiser wrote:
> On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov  wrote:
> > On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
> >> config is attached
> >
> > Ok, I can reproduce the hang with your config but even with:
> >
> > $ grep MICROCODE .config
> > # CONFIG_MICROCODE is not set
> > # CONFIG_MICROCODE_INTEL_EARLY is not set
> > # CONFIG_MICROCODE_AMD_EARLY is not set
> >
> > which means, it cannot be microcode-related.
> >
> > And I'd bet if you wait a minute (yep, it should be exactly 60 seconds)
> > the boot would probably continue. And if so, this is that 60 sec delay
> > where the kernel tries to find firmware.
> >
> > Hmm...
> 
> I have the same problem: Booting 3.11-rc1 hangs after the line:
> ACPI: Executed 3 blocks of module-level executable AML code
> 
> I bisected it down to the early microcode changes:
> 757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading
> implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small
> fixup) completely fail to boot (No output beyond "Booting kernel") ,
> from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 ("Make
> find_ucode_in_initrd() __init") I'm seeing this hang.
> 
> Just turning CONFIG_MICROCODE_EARLY off solves the problem: The system
> now sucessfully boots 3.11-rc1.

Ok, I need to be able to reproduce that first - I wasn't that successful
with Johannes' setup.

So, can you please send .config and how you're loading your microcode?
Is it in the initrd or are you doing that later, how? Grub entry please.

Also, is it just plain v3.11-rc1 or with patches ontop?

Also, /proc/cpuinfo please.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio-mcp23s08: i2c: auto-select base if no DT match or platform data

[Linus Walleij]

On Fri, Jul 19, 2013 at 6:19 AM, Daniel M. Weeks  wrote:

> The call to gpiochip_add made by this driver is capable of auto-selecting a
> base if one is not provided. However, it was not called unless there was
> already a DT entry or platform data. This patch calls it even if the base is
> not already known so that gpiochip_add can attempt to find a usable base.
>
> Signed-off-by: Daniel M. Weeks 

Peter, Lars: you also contribute to this driver so can you folks have
a look at each others patches, e.g it'd be nice to have an ACK on this.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:willy.woo

[Li Wu]

http://paljornal.com/yl/xpilsio.dulhdbaeqo





willy.woo


7/20/2013 11:10:44 PM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND 0/1] AHCI: Optimize interrupt processing

[Nicholas A. Bellinger]

On Sat, 2013-07-20 at 09:48 -0500, Mike Christie wrote:
> On 07/19/2013 11:56 PM, Nicholas A. Bellinger wrote:
> > On Fri, 2013-07-19 at 14:01 -0700, Nicholas A. Bellinger wrote:
> >> On Fri, 2013-07-19 at 08:33 -0700, James Bottomley wrote:



> >>
> >> Indeed.  Looking into the bio_copy_kern() breakage next..
> >>
> > 
> > OK, after further investigation the root cause is a actually a missing
> > bio->bio_end_io() -> bio_copy_kern_endio() -> bio_put() from the
> > blk_end_sync_rq() callback path that scsi-mq REQ_TYPE_BLOCK_PC is
> > currently using.
> > 
> > Including the following patch into the scsi-mq working branch now, and
> > reverting the libata dma_alignment=0x03 hack.
> > 
> > Alexander, care to give this a try..?
> > 
> > --nab
> > 
> > diff --git a/block/blk-exec.c b/block/blk-exec.c
> > index 0761c89..70303d2 100644
> > --- a/block/blk-exec.c
> > +++ b/block/blk-exec.c
> > @@ -25,7 +25,10 @@ static void blk_end_sync_rq(struct request *rq, int 
> > error)
> > struct completion *waiting = rq->end_io_data;
> >  
> > rq->end_io_data = NULL;
> > -   if (!rq->q->mq_ops) {
> > +   if (rq->q->mq_ops) {
> > +   if (rq->bio)
> > +   bio_endio(rq->bio, error);
> > +   } else {
> > __blk_put_request(rq->q, rq);
> > }
> > 
> 
> 
> This does not handle requests with multiple bios, and for the mq stye
> passthrough insertion completions you actually want to call
> blk_mq_finish_request in scsi_execute. Same for all the other
> passthrough code in your scsi mq tree. That is your root bug. Instead of
> doing that though I think we want to have the block layer free the bios
> like before.
> 
> For the non mq calls, blk_end_request type of calls will complete the
> bios when blk_finish_request is called from that path. It will then call
> the rq end_io callback.
> 
> I think the blk mq code assumes if the end_io callack is set that the
> end_io function will do the bio cleanup. See __blk_mq_end_io. Also see
> how blk_mq_execute_rq calls blk_mq_finish_request for an example of how
> rq passthrough execution and cleanup is being done in the mq paths.
> 
> Now with the scsi mq changes, when blk_execute_rq_nowait calls
> blk_mq_insert_request it calls it with a old non mq style of end io
> function that does not complete the bios.
> 
> What about the attached only compile tested patch. The patch has the mq
> block code work like the non mq code for bio cleanups.
> 
> 

OK, so with your blk-mq patch in place to always call
blk_mq_finish_request() in blk_mq_complete_request() regardless of
rq->end_io, the preceding scsi_mq_end_request() can now simply call
blk_mq_end_io() for both BLOCK_RQ and FS request types.

diff --git a/drivers/scsi/scsi-mq.c b/drivers/scsi/scsi-mq.c
index 81b2633..f1d4789 100644
--- a/drivers/scsi/scsi-mq.c
+++ b/drivers/scsi/scsi-mq.c
@@ -93,19 +93,7 @@ struct scsi_cmnd *scsi_mq_end_request(struct scsi_cmnd *sc, 
int error,
 #endif
 
 //FIXME: Add proper blk_mq_end_io residual bytes + requeue
-   if (rq->end_io) {
-#if 0
-   printk("scsi_mq_end_request: Calling rq->end_io BLOCK_PC for"
-   " CDB: 0x%02x\n", sc->cmnd[0]);
-#endif
-   rq->end_io(rq, error);
-   } else {
-#if 0
-   printk("scsi_mq_end_request: Calling blk_mq_end_io for CDB: 
0x%02x\n",
-   sc->cmnd[0]);
-#endif
-   blk_mq_end_io(rq, error);
-   }
+   blk_mq_end_io(rq, error);
 //FIXME: Need to do equiv of scsi_next_command to kick hctx..?
 
return NULL;

Thanks for fixing up that bit of ugliness.  ;)

Jens, care to review+include Mike's change into your working branch..?

--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: [PATCH 01/15] drivers: phy: add generic PHY framework

[Greg KH]

On Sat, Jul 20, 2013 at 08:49:32AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Saturday 20 July 2013 05:20 AM, Greg KH wrote:
> >On Fri, Jul 19, 2013 at 12:06:01PM +0530, Kishon Vijay Abraham I wrote:
> >>Hi,
> >>
> >>On Friday 19 July 2013 11:59 AM, Greg KH wrote:
> >>>On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Friday 19 July 2013 11:13 AM, Greg KH wrote:
> >On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
> >>+   ret = dev_set_name(>dev, "%s.%d", dev_name(dev), id);
> >
> >Your naming is odd, no "phy" anywhere in it?  You rely on the sender 
> >to
> >never send a duplicate name.id pair?  Why not create your own ids 
> >based
> >on the number of phys in the system, like almost all other classes 
> >and
> >subsystems do?
> 
> hmm.. some PHY drivers use the id they provide to perform some of 
> their
> internal operation as in [1] (This is used only if a single PHY 
> provider
> implements multiple PHYS). Probably I'll add an option like 
> PLATFORM_DEVID_AUTO
> to give the PHY drivers an option to use auto id.
> 
> [1] ->
> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> >>>
> >>>No, who cares about the id?  No one outside of the phy core ever 
> >>>should,
> >>>because you pass back the only pointer that they really do care about,
> >>>if they need to do anything with the device.  Use that, and then you 
> >>>can
> >>
> >>hmm.. ok.
> >>
> >>>rip out all of the "search for a phy by a string" logic, as that's not
> >>
> >>Actually this is needed for non-dt boot case. In the case of dt boot, 
> >>we use a
> >>phandle by which the controller can get a reference to the phy. But in 
> >>the case
> >>of non-dt boot, the controller can get a reference to the phy only by 
> >>label.
> >
> >I don't understand.  They registered the phy, and got back a pointer to
> >it.  Why can't they save it in their local structure to use it again
> >later if needed?  They should never have to "ask" for the device, as the
> 
> One is a *PHY provider* driver which is a driver for some PHY device. 
> This will
> use phy_create to create the phy.
> The other is a *PHY consumer* driver which might be any controller driver 
> (can
> be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference 
> to the
> phy (by *phandle* in the case of dt boot and *label* in the case of 
> non-dt boot).
> >device id might be unknown if there are multiple devices in the system.
> 
> I agree with you on the device id part. That need not be known to the PHY 
> driver.
> >>>
> >>>How does a consumer know which "label" to use in a non-dt system if
> >>>there are multiple PHYs in the system?
> >>
> >>That should be passed using platform data.
> >
> >Ick, don't pass strings around, pass pointers.  If you have platform
> >data you can get to, then put the pointer there, don't use a "name".
> 
> I don't think I understood you here :-s We wont have phy pointer
> when we create the device for the controller no?(it'll be done in
> board file). Probably I'm missing something.

Why will you not have that pointer?  You can't rely on the "name" as the
device id will not match up, so you should be able to rely on the
pointer being in the structure that the board sets up, right?

Don't use names, especially as ids can, and will, change, that is going
to cause big problems.  Use pointers, this is C, we are supposed to be
doing that :)

thanks,

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

Re: [Ksummit-2013-discuss] Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)

[Daniel Phillips]

On 07/18/2013 03:54 PM, Sarah Sharp wrote:
> Let's shift this discussion away from the terms "abuse" and
> "professionalism" to "respect" and "civility".

Brilliant, and +1 for a session at KS. In the mean time, why don't we 
all try to demonstrate the real meaning of respect and civility, by 
practising it henceforth on LKML? KS ought to be about clarification, 
reinforcement and specific techniques, as opposed to the question of 
whether respect and civility are desirable in the first place. Nobody 
needs to wait for KS to learn the basic truth they already know in their 
heart.

Regards,

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

Re: [PATCH v9] ARM: clocksource: add support for MOXA ART SoCs

[Daniel Lezcano]

On 07/20/2013 10:45 PM, Linus Walleij wrote:
> On Wed, Jul 17, 2013 at 10:04 AM, Jonas Jensen  wrote:
> 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> #include 
> 
>> +#define TIMEREG_CR_1_ENABLEBIT(0)
> 
> Because BIT() comes from there. And we shall not rely on
> implicit #inclusion.

Hi Jonas,

as the patchset is already merged could you fix it with a separate patch ?

Thanks
  -- Daniel

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] open(2): document O_PATH

[Michael Kerrisk]

On 07/20/13 13:40, Al Viro wrote:
> On Thu, Mar 14, 2013 at 10:35:59AM +0100, Michael Kerrisk (man-pages) wrote:
>> Hello Al et al,
>>
>> Documenting O_PATH fell by the wayside last year
>> (http://thread.gmane.org/gmane.linux.man/2790) as I got distracted
>> with other tasks. A recent prod or two have reminded me restart this.
>> I have the following patch queued to document O_PATH.
>>
>> Could you please review. I've provided the O_PATH doc both as
>> formatted text, for ease of reviewing, and as a patch and entire file
>> (attached).
> 
> Seems to be mostly correct; the only thing missing is that F_GETFL is also
> allowed (and return value will contain O_PATH for such descriptors).  Had
> been there since the very beginning...

Thanks, Al. I have added that piece.

Cheers,

Michael

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

Re: [PATCH v4 3/3] gpio-tz1090: convert to use generic irqchip

[James Hogan]

On 20 July 2013 18:07, Linus Walleij  wrote:
> On Tue, Jun 25, 2013 at 4:27 PM, James Hogan  wrote:
>
>> Convert gpio-tz1090 driver to use generic irqchips. This allows the
>> irq_ack, irq_mask, and irq_unmask callbacks and associated helper
>> functions to be removed. Also switch to using irq_setup_alt_chip() in
>> the irq_set_type callback instead of using __irq_set_handler_locked().
>>
>> Signed-off-by: James Hogan 
>> Cc: Linus Walleij 
>> Cc: Grant Likely 
>> ---
>> This patch depends on the generic irqchip linear irqdomain work in
>> tip/irq/core.
>>
>> Changes in v4:
>
> Patch applied. Confirm that the infrastructure is now upstream
> pls, this is applied on top of v3.11-rc1.

Thanks Linus. Yes, the linear irq domain support in generic irqchip
was included in v3.11-rc1, specifically:
088f40b genirq: Generic chip: Add linear irq domain support
(and related commits)

I'll queue the corresponding arch/metag device tree changes.

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

Re: [PATCH 0/3] MSM gpio fixes

[Linus Walleij]

On Thu, Jul 18, 2013 at 10:07 PM, David Brown  wrote:

> Rohit sent these three fixes out on June 18.  I still need a
> devicetree ack for the first patch, and would like these to get pulled
> in for v3.11
>
> Rohit Vaswani (3):
>   ARM: msm: dts: Fix the gpio register address for msm8960
>   drivers: gpio: msm: Fix the error condition for reading ngpio

OK for these two...

>   ARM: msm: Consolidate gpiomux for older architectures

This does not look like a fix? Surely this can wait for v3.12?

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

Re: [PATCH v4 00/17] 64-bit friendly generic sched_clock()

[Linus Walleij]

On Fri, Jul 19, 2013 at 1:21 AM, Stephen Boyd  wrote:

> This patchset adds support for 64 bit counters in the generic
> sched_clock code and converts drivers over to use it. Based
> on v3.11-rc1.
>
> Changes since v3:

>   ocksource: dbx500-prcmu: Switch to sched_clock_register()

Fix subject.

>   clocksource: nomadik: Switch to sched_clock_register()

Apart from that Acked-by: Linus Walleij 
for these two drivers.

BTW: why are you not patching arch/arm/mach-u300/timer.c?
Please make sure to grep for all setup_sched_clock() if you're
going to do this.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: New device tree mailing list

[Hank Leininger]

On Sat, Jul 20, 2013 at 08:18:54PM +0100, Grant Likely wrote:
> On Sat, Jul 20, 2013 at 6:00 PM, Hank Leininger  wrote:
> >
> > I realize MARC didn't carry the old/original devicetree-discuss list at
> > ozlabs.  I'm pulling down the archives from that list now.  Should I
> > import them as 'devicetree-discuss' (historically accurate) or as
> > 'devicetree' (so they will appear seamless in MARC w/the new vger list's
> > traffic)?
> 
> As long as it doesn't cause any problems with duplicate messages for
> the next short little while, I would merge the two archives.

Sold!  Importing them now as 'devicetree'.  Because I grabbed them at
the same time as I subscribed to the new list, there shouldn't be any
overlap/duplicates.

Thanks,

Hank


signature.asc
Description: Digital signature

Re: [PATCH v9] ARM: clocksource: add support for MOXA ART SoCs

[Linus Walleij]

On Wed, Jul 17, 2013 at 10:04 AM, Jonas Jensen  wrote:

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

#include 

> +#define TIMEREG_CR_1_ENABLEBIT(0)

Because BIT() comes from there. And we shall not rely on
implicit #inclusion.

Apart from that:
Reviewed-by: Linus Walleij 

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: add GPIO support for F71882FG and F71889F

[Linus Walleij]

On Wed, Jul 17, 2013 at 12:00 PM, Simon Guinot
 wrote:

> This patch adds support for the GPIOs found on the Fintek super-I/O
> chips F71882FG and F71889F.
>
> A super-I/O is a legacy I/O controller embedded on x86 motherboards. It
> is used to connect the low-bandwidth devices. Among others functions the
> F71882FG/F71889F provides: a parallel port, two serial ports, a keyboard
> controller, an hardware monitoring controller and some GPIO pins.
>
> Note that this super-I/Os are embedded on some Atom-based LaCie NASes.
> The GPIOs are used to control the LEDs and the hard drive power.
>
> Signed-off-by: Simon Guinot 
> ---
> Linus, I am waiting for your feedback about the Super-I/O device
> detection. Then this part is unchanged since the previous version.
> Else I think I have addressed your other concerns.
>
> Changes since v1:
> - Enhance the commit message by describing what is a Super-I/O.
> - Use self-explanatory names for the GPIO register macros.
> - Add a comment to explain the platform device and driver registration.
> - Fix gpio_get when GPIO is configured in input mode. I only had
>   the hardware to check this mode recently...

This is mostly fine.

> +static int f7188x_gpio_probe(struct platform_device *pdev)
> +{
(...)
> +   platform_set_drvdata(pdev, data);
(...)
> +   platform_set_drvdata(pdev, NULL);
(...)
> +static int f7188x_gpio_remove(struct platform_device *pdev)
(...)
> +   platform_set_drvdata(pdev, NULL);

We don't need to set drvdata to NULL I think, there were
lots of patches addressing this last merge window by Jingoo Han,
see e.g. commit 1cdd8d52ecbedbce1cbac063aa5715810a228ab3
so please get rid of the NULL setters.

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

thermal / x86: Fix init error code path in package temperature driver

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The error code path of the x86 package temperature thermal driver's
initialization routine, pkg_temp_thermal_init(), makes an unbalanced
call to get_online_cpus(), which causes subsequent CPU offline
operations, and consequently system suspend, to permanently block
in cpu_hotplug_begin() on systems where get_core_online() returns
an error code.

Remove the extra get_online_cpus() to fix the problem (tested on
Toshiba Portege R500).

Signed-off-by: Rafael J. Wysocki 
---
 drivers/thermal/x86_pkg_temp_thermal.c |1 -
 1 file changed, 1 deletion(-)

Index: linux-pm/drivers/thermal/x86_pkg_temp_thermal.c
===
--- linux-pm.orig/drivers/thermal/x86_pkg_temp_thermal.c
+++ linux-pm/drivers/thermal/x86_pkg_temp_thermal.c
@@ -592,7 +592,6 @@ static int __init pkg_temp_thermal_init(
return 0;
 
 err_ret:
-   get_online_cpus();
for_each_online_cpu(i)
put_core_offline(i);
put_online_cpus();

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: udev: New default rule for autoloading kernel modules matching CPU modalias

[Rafael J. Wysocki]

On Saturday, July 20, 2013 02:34:58 PM Kay Sievers wrote:
> On Sat, Jul 20, 2013 at 1:47 PM, Kay Sievers  wrote:
> > On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki  wrote:
> >
> >> After a recent change present in 3.11-rc1 there is a driver, called 
> >> processor,
> >> that can be bound to the CPU devices whose sysfs directories are located 
> >> under
> >> /sys/devices/system/cpu/.  A side effect of this is that, after the driver 
> >> has
> >> been bound to those devices, the kernel adds DRIVER=processor to ENV for 
> >> CPU
> >> uevents and they don't match the default rule for autoloading modules 
> >> matching
> >> MODALIAS:
> >>
> >> DRIVER!="?*", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load 
> >> $env{MODALIAS}"
> >>
> >> any more.  However, there are some modules whose module aliases match 
> >> specific
> >> CPU features through the modalias string and those modules should be loaded
> >> automatically if a compatible CPU is present.  Yet, with the processor 
> >> driver
> >> bound to the CPU devices the above rule is not sufficient for that, so we 
> >> need
> >> a new default udev rule allowing those modules to be autoloaded even if the
> >> CPU devices have drivers.
> >>
> >> On my test systems I added the following rule for that:
> >>
> >> ACTION="add", SUBSYSTEM=="cpu", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod 
> >> load $env{MODALIAS}"
> >>
> >> in a separate file, but I'm not a udev expert, so I guess it may be done 
> >> in a
> >> better way.
> >>
> >> Can you please consider adding such a rule to the default set of udev 
> >> rules?
> >
> > The DRIVER!="?*" is an optimization which made a huge difference at
> > the time we called out to /sbin/modprobe from udev rules and all the
> > devices which already had a driver would not cause needless execution
> > of the rather expensive modprobe binary.
> >
> > This obviously can't do the right thing for the completely generic,
> > not bound to a driver-state, CPU modaliases when they have a driver
> > now. :)
> >
> > These days we load the entire kmod modalias database into the udev
> > process, and lookup what we need to load and load the module from
> > within the udev worker process. It could be, that the optimization is
> > not measurable on today's systems, if that's the case I'll remove it,
> > which would be the simplest and most future proof option. Otherwise
> > I'll add the CPU specific rule.
> >
> > I'll find that out and let you know.
> 
> I cannot see any measurable difference here that justifies that
> optimization, so I removed it:
>   
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=bf7f800f2b3e93ccd1229d4717166f3a4d3af72f

Many thanks!

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: livelock avoidance in sget()

[Greg KH]

Hi Al,

Is the patch below something that we need to worry about for 3.10 and
older kernels?  Or does the recent changes to the vfs in 3.11-rc1 make
it so that this can't be hit in older kernels?

thanks,

greg k-h

On Sat, Jul 20, 2013 at 07:34:27PM +, Linux Kernel Mailing List wrote:
> Gitweb: 
> http://git.kernel.org/linus/;a=commit;h=acfec9a5a892f98461f52ed5770de99a3e571ae2
> Commit: acfec9a5a892f98461f52ed5770de99a3e571ae2
> Parent: ba57ea64cb1820deb37637de0fdb107f0dc90089
> Author: Al Viro 
> AuthorDate: Sat Jul 20 03:13:55 2013 +0400
> Committer:  Al Viro 
> CommitDate: Sat Jul 20 04:58:58 2013 +0400
> 
> livelock avoidance in sget()
> 
> Eric Sandeen has found a nasty livelock in sget() - take a mount(2) about
> to fail.  The superblock is on ->fs_supers, ->s_umount is held exclusive,
> ->s_active is 1.  Along comes two more processes, trying to mount the same
> thing; sget() in each is picking that superblock, bumping ->s_count and
> trying to grab ->s_umount.  ->s_active is 3 now.  Original mount(2)
> finally gets to deactivate_locked_super() on failure; ->s_active is 2,
> superblock is still ->fs_supers because shutdown will *not* happen until
> ->s_active hits 0.  ->s_umount is dropped and now we have two processes
> chasing each other:
> s_active = 2, A acquired ->s_umount, B blocked
> A sees that the damn thing is stillborn, does deactivate_locked_super()
> s_active = 1, A drops ->s_umount, B gets it
> A restarts the search and finds the same superblock.  And bumps it 
> ->s_active.
> s_active = 2, B holds ->s_umount, A blocked on trying to get it
> ... and we are in the earlier situation with A and B switched places.
> 
> The root cause, of course, is that ->s_active should not grow until we'd
> got MS_BORN.  Then failing ->mount() will have deactivate_locked_super()
> shut the damn thing down.  Fortunately, it's easy to do - the key point
> is that grab_super() is called only for superblocks currently on 
> ->fs_supers,
> so it can bump ->s_count and grab ->s_umount first, then check MS_BORN and
> bump ->s_active; we must never increment ->s_count for superblocks past
> ->kill_sb(), but grab_super() is never called for those.
> 
> The bug is pretty old; we would've caught it by now, if not for accidental
> exclusion between sget() for block filesystems; the things like cgroup or
> e.g. mtd-based filesystems don't have anything of that sort, so they get
> bitten.  The right way to deal with that is obviously to fix sget()...
> 
> Signed-off-by: Al Viro 
> ---
>  fs/super.c |   25 ++---
>  1 files changed, 10 insertions(+), 15 deletions(-)
> 
> diff --git a/fs/super.c b/fs/super.c
> index 7465d43..68307c0 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -336,19 +336,19 @@ EXPORT_SYMBOL(deactivate_super);
>   *   and want to turn it into a full-blown active reference.  grab_super()
>   *   is called with sb_lock held and drops it.  Returns 1 in case of
>   *   success, 0 if we had failed (superblock contents was already dead or
> - *   dying when grab_super() had been called).
> + *   dying when grab_super() had been called).  Note that this is only
> + *   called for superblocks not in rundown mode (== ones still on ->fs_supers
> + *   of their type), so increment of ->s_count is OK here.
>   */
>  static int grab_super(struct super_block *s) __releases(sb_lock)
>  {
> - if (atomic_inc_not_zero(>s_active)) {
> - spin_unlock(_lock);
> - return 1;
> - }
> - /* it's going away */
>   s->s_count++;
>   spin_unlock(_lock);
> - /* wait for it to die */
>   down_write(>s_umount);
> + if ((s->s_flags & MS_BORN) && atomic_inc_not_zero(>s_active)) {
> + put_super(s);
> + return 1;
> + }
>   up_write(>s_umount);
>   put_super(s);
>   return 0;
> @@ -463,11 +463,6 @@ retry:
>   destroy_super(s);
>   s = NULL;
>   }
> - down_write(>s_umount);
> - if (unlikely(!(old->s_flags & MS_BORN))) {
> - deactivate_locked_super(old);
> - goto retry;
> - }
>   return old;
>   }
>   }
> @@ -660,10 +655,10 @@ restart:
>   if (hlist_unhashed(>s_instances))
>   continue;
>   if (sb->s_bdev == bdev) {
> - if (grab_super(sb)) /* drops sb_lock */
> - return sb;
> - else
> + if (!grab_super(sb))
>   goto restart;
> + up_write(>s_umount);
> + return sb;
>   }
>   }
>   spin_unlock(_lock);
> --
> To unsubscribe from this list: 

Re: [PATCH 2/3] gpio: add LP3943 I2C GPIO expander driver

[Linus Walleij]

I forgot one thing:

On Tue, Jul 16, 2013 at 4:38 AM, Kim, Milo  wrote:

> +static int lp3943_gpio_probe(struct platform_device *pdev)
> +{
> +   struct lp3943 *l = dev_get_drvdata(pdev->dev.parent);
> +   struct lp3943_gpio *lg;
> +   int ret;

This is where I want you to assign to a member of struct
lp3943 another u16 mask which tells which lines are
actually available for GPIO, and you should also add code to
make sure that lines that are not available fail gpio_request().

This configuration can probably be read out from the device
tree if you add the compatible node to the MFD cell when
registering it.

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

Re: [PATCH 2/3] gpio: add LP3943 I2C GPIO expander driver

[Linus Walleij]

On Tue, Jul 16, 2013 at 4:38 AM, Kim, Milo  wrote:

> +++ b/drivers/gpio/gpio-lp3943.c
> @@ -0,0 +1,224 @@
> +/*
> + * TI/National Semiconductor LP3943 GPIO driver
> + *
> + * Copyright (C) 2013 Texas Instruments
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

#include 

> +#define to_lp3943_gpio(_chip)  container_of(_chip, struct lp3943_gpio, chip)
> +
> +enum lp3943_gpios {
> +   LP3943_GPIO1,
> +   LP3943_GPIO2,
> +   LP3943_GPIO3,
> +   LP3943_GPIO4,
> +   LP3943_GPIO5,
> +   LP3943_GPIO6,
> +   LP3943_GPIO7,
> +   LP3943_GPIO8,
> +   LP3943_GPIO9,
> +   LP3943_GPIO10,
> +   LP3943_GPIO11,
> +   LP3943_GPIO12,
> +   LP3943_GPIO13,
> +   LP3943_GPIO14,
> +   LP3943_GPIO15,
> +   LP3943_GPIO16,
> +   LP3943_MAX_GPIO,
> +};
> +
> +struct lp3943_gpio {
> +   struct gpio_chip chip;
> +   struct lp3943 *l;
> +   bool is_input[LP3943_MAX_GPIO];

Please do this instead:
u16 is_input;


> +static int lp3943_gpio_direction_input(struct gpio_chip *chip, unsigned 
> offset)
> +{
> +   struct lp3943_gpio *lg = to_lp3943_gpio(chip);
> +   const struct lp3943_reg_cfg *mux = lg->l->mux_cfg;
> +   u8 addr;
> +   u8 mask;
> +   u8 shift;
> +
> +   lg->is_input[offset] = true;

So it would be:
lg->is_input |= BIT(offset);

> +   addr  = mux[offset].reg;
> +   mask  = mux[offset].mask;
> +   shift = mux[offset].shift;
> +
> +   return lp3943_update_bits(lg->l, addr, mask, LP3943_GPIO_IN << shift);
> +}
> +
> +static int lp3943_get_gpio_in_status(struct lp3943_gpio *lg,
> +   struct gpio_chip *chip, unsigned offset)
> +{
> +   u8 addr;
> +   u8 read;
> +   int err;
> +
> +   switch (offset) {
> +   case LP3943_GPIO1 ... LP3943_GPIO8:
> +   addr = LP3943_REG_GPIO_A;
> +   break;
> +   case LP3943_GPIO9 ... LP3943_GPIO16:
> +   addr = LP3943_REG_GPIO_B;
> +   offset = offset - 8;
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   err = lp3943_read_byte(lg->l, addr, );
> +   if (err)
> +   return err;
> +
> +   if (read & (1 << offset))
> +   return 1;
> +   else
> +   return 0;

Just:
return !!(read & BIT(offset));

> +}
> +
> +static int lp3943_get_gpio_out_status(struct lp3943_gpio *lg,
> +   struct gpio_chip *chip, unsigned offset)
> +{
> +   const struct lp3943_reg_cfg *mux = lg->l->mux_cfg;
> +   u8 addr  = mux[offset].reg;
> +   u8 mask  = mux[offset].mask;
> +   u8 shift = mux[offset].shift;
> +   u8 read;
> +   int err;
> +
> +   err = lp3943_read_byte(lg->l, addr, );
> +   if (err)
> +   return err;
> +
> +   read = (read & mask) >> shift;
> +
> +   if (read == LP3943_GPIO_OUT_HIGH)
> +   return 1;
> +   else if (read == LP3943_GPIO_OUT_LOW)
> +   return 0;
> +   else
> +   return -EINVAL;
> +}
> +
> +static int lp3943_gpio_get(struct gpio_chip *chip, unsigned offset)
> +{
> +   struct lp3943_gpio *lg = to_lp3943_gpio(chip);
> +
> +   /*
> +* Limitation:
> +*   LP3943 doesn't have the GPIO direction register. It provides
> +*   only input and output status registers.
> +*   So, direction info is required to handle the 'get' operation.
> +*   This variable is updated whenever the direction is changed and
> +*   it is used here.
> +*/
> +
> +   if (lg->is_input[offset])

if (lg->is_input & BIT(offset))

> +   return lp3943_get_gpio_in_status(lg, chip, offset);
> +   else
> +   return lp3943_get_gpio_out_status(lg, chip, offset);
> +}
> +
> +static void lp3943_gpio_set(struct gpio_chip *chip, unsigned offset, int 
> value)
> +{
> +   struct lp3943_gpio *lg = to_lp3943_gpio(chip);
> +   const struct lp3943_reg_cfg *mux = lg->l->mux_cfg;
> +   u8 addr;
> +   u8 mask;
> +   u8 shift;
> +   u8 data;
> +
> +   addr  = mux[offset].reg;
> +   mask  = mux[offset].mask;
> +   shift = mux[offset].shift;
> +
> +   if (value)
> +   data = LP3943_GPIO_OUT_HIGH;
> +   else
> +   data = LP3943_GPIO_OUT_LOW;
> +
> +   lp3943_update_bits(lg->l, addr, mask, data << shift);
> +}
> +
> +static int lp3943_gpio_direction_output(struct gpio_chip *chip, unsigned 
> offset,
> +   int value)
> +{
> +   struct lp3943_gpio *lg = to_lp3943_gpio(chip);
> +
> +   lp3943_gpio_set(chip, offset, value);
> +   lg->is_input[offset] 

Re: [PATCH] ASoC: generic: add simple card with devicetree support

[Daniel Mack]

Hi,

On 20.07.2013 19:25, Jean-Francois Moine wrote:
> This generic simple card driver uses DT values to instanciate an audio
> system in which the real work is done by the subdrivers (audio
> controller, audio codec and pcm/dma controller).
> 
> Signed-off-by: Jean-Francois Moine 
> ---

> diff --git a/sound/soc/generic/simple-dt-card.c 
> b/sound/soc/generic/simple-dt-card.c
> new file mode 100644

There is a simple-card driver in the tree already, and there were
several attempts to add DT bindings for it in the past - have you seen
that? Search for "ASoC: add simple-card DT support" in the archives ...


Daniel

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

Re: [PATCH 1/3] mfd: add LP3943 MFD driver

[Linus Walleij]

On Tue, Jul 16, 2013 at 4:38 AM, Kim, Milo  wrote:

This needs to be reviewed by the devicetree people.
Please break out the bindings separately and include
devicet...@vger.kernel.org on that review.

> +++ b/Documentation/devicetree/bindings/mfd/lp3943.txt
> @@ -0,0 +1,23 @@
> +Bindings for TI/National Semiconductor LP3943 Driver
> +
> +Required properties:
> +  - compatible: "ti,lp3943"
> +  - reg: 7bit I2C slave address. 0x60 ~ 0x67
> +
> +Optional properties:
> +  - ti,pwm0, ti,pwm1: Output channel definition for PWM port 0 and 1
> +  0 = invalid, 1 = LED0, 2 = LED 1, ... 16 = LED15
> +
> +Datasheet
> +  http://www.ti.com/lit/ds/snvs256b/snvs256b.pdf
> +
> +Application note: How to use LP3943 as a GPIO expander and PWM generator
> +  http://www.ti.com/lit/an/snva287a/snva287a.pdf

Do we usually put these things into bindings?

> +Example:
> +
> +   lp3943@60 {
> +   compatible = "ti,lp3943";
> +   reg = <0x60>;
> +   pwm1 = /bits/ 8 <2>;/* use LED1 output as PWM #1 */
> +   };

OK so there is a way to state which lines are used for PWM.

I think you should also specify which lines are used for GPIO,
and which lines are used for LEDs.

And I'd like the masks to be passed to each subdriver, so we
can avoid the scenario where one and the same line gets
used for GPIO, LED and PWM at the same time.

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

[GIT PATCH] Staging driver patches for 3.11-rc2

[Greg KH]

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ 
tags/staging-3.11-rc2

for you to fetch changes up to 78077256bc08348d587e318957ceb41fe4d4afae:

  Merge tag 'iio-fixes-for-3.11a' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus 
(2013-07-16 22:41:38 -0700)



Staging tree fixes for 3.11-rc2

Here are a few iio driver fixes for 3.11-rc2.  They are still spread
across drivers/iio and drivers/staging/iio so they are coming in through
this tree.

I've also removed the drivers/staging/csr/ driver as the developers who
originally sent it to me have moved on to other companies, and CSR still
will not send us the specs for the device, making the driver pretty much
obsolete and impossible to fix up.  Deleting it now prevents people from
sending in lots of tiny codingsyle fixes that will never go anywhere.

It also helps to offset the large lustre filesystem merge that happened
in 3.11-rc1 in the overall 3.11.0 diffstat. :)

Signed-off-by: Greg Kroah-Hartman 


Alexandre Belloni (2):
  iio: Fix iio_channel_has_info
  iio: inkern: fix iio_convert_raw_to_processed_unlocked

Greg Kroah-Hartman (2):
  staging: csr: remove driver
  Merge tag 'iio-fixes-for-3.11a' of git://git.kernel.org/.../jic23/iio 
into staging-linus

Jacek Anaszewski (1):
  iio: lps331ap: Fix wrong in_pressure_scale output value

Jonathan Cameron (1):
  iio:trigger: device_unregister->device_del to avoid double free

Marek Vasut (2):
  iio: mxs-lradc: Fix misuse of iio->trig
  iio: mxs-lradc: Remove useless check in read_raw

Peter Meerwald (1):
  iio staging: fix lis3l02dq, read error handling

Wei Yongjun (3):
  iio: dac: ad7303: fix error return code in ad7303_probe()
  iio: ti_am335x_adc: add missing .driver_module to struct iio_info
  staging:iio:ad7291: add missing .driver_module to struct iio_info

 drivers/iio/adc/ti_am335x_adc.c|1 +
 drivers/iio/dac/ad7303.c   |4 +-
 drivers/iio/industrialio-trigger.c |2 +-
 drivers/iio/inkern.c   |2 +-
 drivers/iio/pressure/st_pressure_core.c|6 +-
 drivers/staging/Kconfig|2 -
 drivers/staging/Makefile   |1 -
 drivers/staging/csr/Kconfig|9 -
 drivers/staging/csr/LICENSE.txt|   39 -
 drivers/staging/csr/Makefile   |   73 -
 drivers/staging/csr/bh.c   |  404 --
 drivers/staging/csr/csr_framework_ext.c|   40 -
 drivers/staging/csr/csr_framework_ext.h|   35 -
 drivers/staging/csr/csr_framework_ext_types.h  |   30 -
 drivers/staging/csr/csr_log.h  |  223 -
 drivers/staging/csr/csr_log_configure.h|   39 -
 drivers/staging/csr/csr_log_text.h |  124 -
 drivers/staging/csr/csr_macro.h|   39 -
 drivers/staging/csr/csr_msg_transport.h|   17 -
 drivers/staging/csr/csr_msgconv.c  |  291 -
 drivers/staging/csr/csr_msgconv.h  |   78 -
 drivers/staging/csr/csr_prim_defs.h|   55 -
 drivers/staging/csr/csr_result.h   |   17 -
 drivers/staging/csr/csr_sched.h|   85 -
 drivers/staging/csr/csr_sdio.h |  723 ---
 .../staging/csr/csr_serialize_primitive_types.c|  100 -
 drivers/staging/csr/csr_time.c |   33 -
 drivers/staging/csr/csr_time.h |   76 -
 drivers/staging/csr/csr_util.c |   15 -
 drivers/staging/csr/csr_wifi_common.h  |  101 -
 drivers/staging/csr/csr_wifi_fsm.h |  240 -
 drivers/staging/csr/csr_wifi_fsm_event.h   |   42 -
 drivers/staging/csr/csr_wifi_fsm_types.h   |  430 --
 drivers/staging/csr/csr_wifi_hip_card.h|  114 -
 drivers/staging/csr/csr_wifi_hip_card_sdio.c   | 4001 
 drivers/staging/csr/csr_wifi_hip_card_sdio.h   |  694 ---
 drivers/staging/csr/csr_wifi_hip_card_sdio_intr.c  | 2595 
 drivers/staging/csr/csr_wifi_hip_card_sdio_mem.c   | 1713 -
 drivers/staging/csr/csr_wifi_hip_chiphelper.c  |  793 ---
 drivers/staging/csr/csr_wifi_hip_chiphelper.h  |  407 --
 .../staging/csr/csr_wifi_hip_chiphelper_private.h  |  200 -
 drivers/staging/csr/csr_wifi_hip_conversions.h |   73 -
 drivers/staging/csr/csr_wifi_hip_download.c|  819 ---
 drivers/staging/csr/csr_wifi_hip_dump.c|  837 ---
 drivers/staging/csr/csr_wifi_hip_packing.c | 4804 ---
 

Re: [PATCH 0/3] LP3943 MFD driver for a GPIO expander and a PWM generator

[Linus Walleij]

On Sat, Jul 20, 2013 at 10:04 PM, Linus Walleij
 wrote:

> Do you have use cases not using it for LEDs but other thing or why
> do you want to model the 16 LED lines as GPIO lines?
> Why can't you just have a drivers/leds/* as for any other LED
> chip?

Bah forget this. Now I saw that application note in the GPIO
portion patch.

But don't you want a drivers/leds/* driver for this as well?

I imagine the MFD core should send a mask to GPIO and
LEDs drivers stating which lines can be used for GPIO and
which lines can be used for LEDs.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] LP3943 MFD driver for a GPIO expander and a PWM generator

[Linus Walleij]

On Tue, Jul 16, 2013 at 4:38 AM, Kim, Milo  wrote:

> LP3943 is an integrated device capable of driving 16 output channels.
> It supports a GPIO expander and a PWM generator.

But actually the data sheet describes it as a LED driver with PWM
chip.

Do you have use cases not using it for LEDs but other thing or why
do you want to model the 16 LED lines as GPIO lines?
Why can't you just have a drivers/leds/* as for any other LED
chip?

Atleast some good explanation of this needs to be found in the
patch text and also as comments in Kconfig and the code I think.

I'm just fearing that this is some way to satisfy a userspace that
wants to use the sysfs interface to GPIO to control LEDs and these
are much better off using the LED sysfs ABI.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] GPIO: gpio-twl6040: Remove support for legacy (pdata) mode

[Linus Walleij]

On Fri, Jul 12, 2013 at 1:30 PM, Peter Ujfalusi  wrote:

> TWL6040 is used only with OMAP4/5 SoCs and they can only boot in in DT mode.
> The support for pdata/legacy boot can be removed.
>
> Signed-off-by: Peter Ujfalusi 

OK patch applied.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: New device tree mailing list

[Grant Likely]

On Sat, Jul 20, 2013 at 6:00 PM, Hank Leininger  wrote:
> On Sat, Jul 20, 2013 at 06:28:19PM +0200, Linus Walleij wrote:
>> Hi MARC list archive folks,
>>
>> could you please start archiving the following recently addes VGER lists
>> at marc.info:
>>
>> These go into the "Linux" folder:
>> linux-gpio: http://vger.kernel.org/vger-lists.html#linux-gpio
>> linux-spi: http://vger.kernel.org/vger-lists.html#linux-spi
>>
>> This one goes into "Development" or "Misc" I guess:
>> devicetree: http://vger.kernel.org/vger-lists.html#devicetree
>
> Sure, I've just subscribed us to all three.  They'll show in 'Misc' once
> some traffic comes in, and then I'll (have to remember to) move them.
>
> I realize MARC didn't carry the old/original devicetree-discuss list at
> ozlabs.  I'm pulling down the archives from that list now.  Should I
> import them as 'devicetree-discuss' (historically accurate) or as
> 'devicetree' (so they will appear seamless in MARC w/the new vger list's
> traffic)?

As long as it doesn't cause any problems with duplicate messages for
the next short little while, I would merge the two archives.

Thanks Hank.

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

Greetings from George Daniels

[George Daniels]

Greetings from George Daniels

I am George Daniels, a Banker and credit system programmer (HSBC bank). 
I saw your email address while browsing through  the bank D.T.C Screen in my 
office 
yesterday so I decided to use this very chance to know you. I believe 
we should use every opportunity to know each other better. However, I am 
contacting you 
for obvious reason which you will understand. 

I am sending this mail just to know if this email address is OK, 
reply me back so that I will send  more details to you. 
I have a very important thing to discuss with you, I look forward to receiving 
your response at 
georgedani...@postino.net . Have a pleasant day.

George Daniels
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: early microcode on amd is broken when no initramfs provided

[Torsten Kaiser]

On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov  wrote:
> On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
>> config is attached
>
> Ok, I can reproduce the hang with your config but even with:
>
> $ grep MICROCODE .config
> # CONFIG_MICROCODE is not set
> # CONFIG_MICROCODE_INTEL_EARLY is not set
> # CONFIG_MICROCODE_AMD_EARLY is not set
>
> which means, it cannot be microcode-related.
>
> And I'd bet if you wait a minute (yep, it should be exactly 60 seconds)
> the boot would probably continue. And if so, this is that 60 sec delay
> where the kernel tries to find firmware.
>
> Hmm...

I have the same problem: Booting 3.11-rc1 hangs after the line:
ACPI: Executed 3 blocks of module-level executable AML code

I bisected it down to the early microcode changes:
757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading
implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small
fixup) completely fail to boot (No output beyond "Booting kernel") ,
from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 ("Make
find_ucode_in_initrd() __init") I'm seeing this hang.

Just turning CONFIG_MICROCODE_EARLY off solves the problem: The system
now sucessfully boots 3.11-rc1.

Trying to debug this I found the following hack to also solve the boot problem:
Removing the following two lines from collect_cpu_info_amd_early()
from arch/x86/kernel/microcode_amd_early.c:
   c->microcode = rev;
c->x86 = ((eax >> 8) & 0xf) + ((eax >> 20) & 0xff);

But I can't make sense out of that. And if I try to trace who updates
->x86 it get even more confusing.
Normaly only cpu_detect() seems to update cpuinfo_x86.x86 but now it
seems to fight with collect_cpu_info_amd_early().
On my system this happens:
(Output is always address of the struct cpuinfo_x86 -> value that gets
written into it)

Very early boot:
cpu_detect 81c8ba40 -> 16

BSP == CPU0 calls load_ucode_ap() via cpu_init():
collect_cpu_info_amd_early 880337c10fc0 -> 16
(That is the place I patched out to get the system to boot)

BSP == CPU0 via identify_boot_cpu():
cpu_detect 81c8ba40 -> 16

BSP == CPU0 stores boot_cpu_data in its per-cpu structure via
smp_store_boot_cpu_info():
smpboot: BSP: store 81c8ba40 in 880337c10fc0

smpboot starts activating the secondary CPUs: Each would in
start_secondary() first call load_ucode_ap() via cpu_init() and then
identidfy_secondary_cpu() via smp_callin():
collect_cpu_info_amd_early 880337c50fc0
smpboot: identify_sec_cpu:1/880337c50fc0
cpu_detect 880337c50fc0 -> 16

collect_cpu_info_amd_early 880337c90fc0
smpboot: identify_sec_cpu:2/880337c90fc0
cpu_detect 880337c90fc0 -> 16

collect_cpu_info_amd_early 880337cd0fc0
smpboot: identify_sec_cpu:3/880337cd0fc0
cpu_detect 880337cd0fc0 -> 16

collect_cpu_info_amd_early 880337d10fc0
smpboot: identify_sec_cpu:4/880337d10fc0
cpu_detect 880337d10fc0 -> 16

collect_cpu_info_amd_early 880337d50fc0
smpboot: identify_sec_cpu:5/880337d50fc0
cpu_detect 880337d50fc0 -> 16


It seems the code for updating 'struct cpuinfo_x86 *C' in
collect_cpu_info_amd_early() is useless, because it will be
overwritten first by smp_store_cpu_info() and then again by
identify_secondary_cpu(c) and wrong, because at that point the per-cpu
structure should not be used yet, as smp_store_cpu_info() did not run
yet.
But something else seems to be using the per-cpu structure of the BSP
between its cpu_init() and smp_store_boot_cpu_info().

And its cpu_has_amd_erratum(): It uses cpuinfo_x86.x86 do decide if it
need to fall back to boot_cpu_data, but because
collect_cpu_info_amd_early() has filled that field, but not
.x86_vendor (that is still 0 == X86_VENDOR_INTEL) the erratas are not
applied to the BSP and then something in ACPI gets stuck.

Does this diagnostic make sense / should I send a patch?

Torsten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] iio: mxs-lradc: add write_raw function to modify scale

[Marek Vasut]

Dear Jonathan Cameron,

> On 07/19/2013 05:22 PM, Hector Palacios wrote:
> > Dear Marek,
> > 
> > On 07/19/2013 06:17 PM, Marek Vasut wrote:
> >>> Here you have three entries per channel:
> >>> in_voltageX_raw-> the sample raw value
> >>> in_voltageX_scale-> the scale to multiply the raw value to get the
> >> 
> >> voltage
> >> 
> >>> in mV in_voltageX_scale_available -> lists the available scales of the
> >>> channel
> >>> 
> >>> For example for channel 0:
> >>> 
> >>> # cat in_voltage0_scale_available
> >>> 0.451660156 0.903320312(two scales available, first with divider by
> >>> two disabled, second with divider by two enabled)
> >>> 
> >>> # cat in_voltage0_scale
> >>> 0.451660156(divider by two is currently disabled)
> >>> 
> >>> # cat in_voltage0_raw(shows measured value)
> >>> 1000
> >>> 
> >>> If you multiply the value by the scale you get: 1000 * 0.451660156 =
> >>> 451.6 mV
> >>> 
> >>> # echo 0.903320312 > in_voltage0_scale(enables the divider by two)
> >> 
> >> Ok, so I have to remember this value : '0.903320312' in case I want to
> >> enable divide-by-two functionality?
> > 
> > No you don't. That's why there is a 'in_voltage_scale_available' that
> > lists the available values.
> > 
> >> H ... why would this interface not work:
> >> echo 2 > in_voltage0_scale
> >> 
> >> or
> >> 
> >> echo 1 > in_voltage0_scale
> > 
> > An easy thing like that is what I first submitted, but it was rejected
> > and I was told to use the scale_available descriptor instead, which is
> > the common interface the rest of drivers use.
> 
> This comes down to allowing us to have one generic predictable interface
> (which sometimes ends up looking uggly!).  The key thing is that if you
> are outputing using the _raw sysfs interfaces, the aim is to avoid doing
> nasty maths in kernel to get to 'standard' units such as mV.

OK, understood.

> Hence that scale attribute tells you what to apply to the value.  If you
> just wanted it to be 1 or 2 then the in_voltage0_raw value would have to
> be a long and nasty decimal.  Now we do have the option of
> in_voltage0_calibscale which would be applied internally to the value but
> it really isn't for this purpose (it's for devices with a 'trim' control)
> and you'd still have scale set to 0.903320312 or similar. Although they
> have meaning obviously, in this case 1 and 2 are little more than 'magic'
> numbers.
> 
> Note that when things are quite, I'm at least in theory working on a
> cleaner interface for these 'available' attributes that would also provide
> in kernel access for IIO consumers. Basically this will be another
> callback to get either the 'range' of pseudo continuous variables or the
> 'available' set for parameters like this.

Thanks for the explanation!

> Being lazy I'm happy to let someone else clean this corner up if they like?
> *looks hopeful*

Please don't look at me, I already am fully loaded with fixing my mess all 
around ;-/

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: compile error on 3.10.1

[Thomas Fjellstrom]

On Sat 20 July 2013 12:07:03 Thomas Fjellstrom wrote:
> On Sat 20 July 2013 11:02:10 you wrote:
> > On Sat, Jul 20, 2013 at 09:59:57AM -0600, Thomas Fjellstrom wrote:
> > > Hi, just trying to compile a vanilla kernel and building using
> > > allmodconfig and using oldconfig with the debian 3.10.1 config as a
> > > base.
> > 
> > > With the later config, I get the following:
> > Is this new to 3.10.1 and works fine for 3.10.0?
> 
> I'll check.
> 
> All I've tested so far is debian's 2.6.32, 3.9.8, 3.10.1, and a vanilla
> 3.10.1 (with allmodconfig and oldconfig+debian config).

I meant to say I only tried 3.10.1... I'm getting this and my last email 
confused a little.

Just tested the v3.10 tag from the stable repo and it exhibits the same 
problem.

> > >   CC [M]  drivers/net/wireless/ath/wil6210/debugfs.o
> > > 
> > > drivers/net/wireless/ath/wil6210/debugfs.c: In function
> > > âwil_print_ringâ:
> > > drivers/net/wireless/ath/wil6210/debugfs.c:163:11: error: pointer
> > > targets
> 
> in
> 
> > > passing argument 5 of âhex_dump_to_bufferâ differ in signedness [-
> > > Werror=pointer-sign]
> > > 
> > >false);
> > >^
> > > 
> > > In file included from include/linux/kernel.h:13:0,
> > > 
> > >  from include/linux/cache.h:4,
> > >  from include/linux/time.h:4,
> > >  from include/linux/stat.h:18,
> > >  from include/linux/module.h:10,
> > > 
> > >  from drivers/net/wireless/ath/wil6210/debugfs.c:17:
> > > include/linux/printk.h:361:13: note: expected âchar *â but argument is
> > > of
> 
> type
> 
> > > âunsigned char *â
> > > 
> > >  extern void hex_dump_to_buffer(const void *buf, size_t len,
> > >  
> > >  ^
> > > 
> > > drivers/net/wireless/ath/wil6210/debugfs.c: In function
> > > âwil_txdesc_debugfs_showâ:
> > > drivers/net/wireless/ath/wil6210/debugfs.c:429:10: error: pointer
> > > targets
> 
> in
> 
> > > passing argument 5 of âhex_dump_to_bufferâ differ in signedness [-
> > > Werror=pointer-sign]
> > > 
> > >   sizeof(printbuf), false);
> > >   ^
> > > 
> > > In file included from include/linux/kernel.h:13:0,
> > > 
> > >  from include/linux/cache.h:4,
> > >  from include/linux/time.h:4,
> > >  from include/linux/stat.h:18,
> > >  from include/linux/module.h:10,
> > > 
> > >  from drivers/net/wireless/ath/wil6210/debugfs.c:17:
> > > include/linux/printk.h:361:13: note: expected âchar *â but argument is
> > > of
> 
> type
> 
> > > âunsigned char *â
> > > 
> > >  extern void hex_dump_to_buffer(const void *buf, size_t len,
> > >  
> > >  ^
> > > 
> > > cc1: all warnings being treated as errors
> > > make[5]: *** [drivers/net/wireless/ath/wil6210/debugfs.o] Error 1
> > > make[4]: *** [drivers/net/wireless/ath/wil6210] Error 2
> > > make[3]: *** [drivers/net/wireless/ath] Error 2
> > > make[2]: *** [drivers/net/wireless] Error 2
> > > make[1]: *** [drivers/net] Error 2
> > > make: *** [drivers] Error 2
> > > 
> > > There are also a bunch of warnings, most of the ones I could catch are
> > > signedness related.
> > 
> > Care to send this to the atheros wireless developers?  I'm sure they
> > would like to know about it.
> 
> Can do.

Done.

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

[PATCH] staging: lustre: Fix typo in printk

[Masanari Iida]

Correct spelling typo in printk within staging/lustre

Signed-off-by: Masanari Iida 
---
 drivers/staging/lustre/lustre/llite/vvp_io.c | 2 +-
 drivers/staging/lustre/lustre/obdclass/genops.c  | 2 +-
 drivers/staging/lustre/lustre/obdecho/echo_client.c  | 2 +-
 drivers/staging/lustre/lustre/ptlrpc/gss/gss_krb5_mech.c | 6 +++---
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/vvp_io.c 
b/drivers/staging/lustre/lustre/llite/vvp_io.c
index eb964ac..8001f2d 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_io.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_io.c
@@ -968,7 +968,7 @@ static int vvp_io_commit_write(const struct lu_env *env,
LINVRNT(cl_page_is_vmlocked(env, pg));
LASSERT(vmpage->mapping->host == inode);
 
-   LU_OBJECT_HEADER(D_INODE, env, >co_lu, "commiting page write\n");
+   LU_OBJECT_HEADER(D_INODE, env, >co_lu, "committing page write\n");
CL_PAGE_HEADER(D_PAGE, env, pg, "committing: [%d, %d]\n", from, to);
 
/*
diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c 
b/drivers/staging/lustre/lustre/obdclass/genops.c
index d96876e..ea041a3 100644
--- a/drivers/staging/lustre/lustre/obdclass/genops.c
+++ b/drivers/staging/lustre/lustre/obdclass/genops.c
@@ -1484,7 +1484,7 @@ int obd_export_evict_by_uuid(struct obd_device *obd, 
const char *uuid)
CERROR("%s: can't disconnect %s: no exports found\n",
   obd->obd_name, uuid);
} else {
-   CWARN("%s: evicting %s at adminstrative request\n",
+   CWARN("%s: evicting %s at administrative request\n",
   obd->obd_name, doomed_exp->exp_client_uuid.uuid);
class_fail_export(doomed_exp);
class_export_put(doomed_exp);
diff --git a/drivers/staging/lustre/lustre/obdecho/echo_client.c 
b/drivers/staging/lustre/lustre/obdecho/echo_client.c
index 184195f..391878d 100644
--- a/drivers/staging/lustre/lustre/obdecho/echo_client.c
+++ b/drivers/staging/lustre/lustre/obdecho/echo_client.c
@@ -648,7 +648,7 @@ static int echo_site_init(const struct lu_env *env, struct 
echo_device *ed)
/* initialize site */
rc = cl_site_init(site, >ed_cl);
if (rc) {
-   CERROR("Cannot initilize site for echo client(%d)\n", rc);
+   CERROR("Cannot initialize site for echo client(%d)\n", rc);
return rc;
}
 
diff --git a/drivers/staging/lustre/lustre/ptlrpc/gss/gss_krb5_mech.c 
b/drivers/staging/lustre/lustre/ptlrpc/gss/gss_krb5_mech.c
index 4b28931..91da763 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/gss/gss_krb5_mech.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/gss/gss_krb5_mech.c
@@ -341,7 +341,7 @@ __u32 import_context_rfc1964(struct krb5_ctx *kctx, char 
*p, char *end)
if (p != end)
goto out_err;
 
-   CDEBUG(D_SEC, "succesfully imported rfc1964 context\n");
+   CDEBUG(D_SEC, "successfully imported rfc1964 context\n");
return 0;
 out_err:
return GSS_S_FAILURE;
@@ -403,7 +403,7 @@ __u32 import_context_rfc4121(struct krb5_ctx *kctx, char 
*p, char *end)
if (get_keyblock(, end, >kc_keyc, keysize))
goto out_err;
 
-   CDEBUG(D_SEC, "succesfully imported v2 context\n");
+   CDEBUG(D_SEC, "successfully imported v2 context\n");
return 0;
 out_err:
return GSS_S_FAILURE;
@@ -494,7 +494,7 @@ __u32 gss_copy_reverse_context_kerberos(struct gss_ctx 
*gctx,
goto out_err;
 
gctx_new->internal_ctx_id = knew;
-   CDEBUG(D_SEC, "succesfully copied reverse context\n");
+   CDEBUG(D_SEC, "successfully copied reverse context\n");
return GSS_S_COMPLETE;
 
 out_err:
-- 
1.8.3.3.820.ge3d4493

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dvb-usb: add another product id for "Elgato EyeTV SAT"

[Manuel Schönlaub]

From: Manuel Schönlaub 

There is another revision of "Elgato EyeTV SAT" working with this driver
but using a previously unknown product id.

Signed-off-by: Manuel Schönlaub 
---
drivers/media/dvb-core/dvb-usb-ids.h |1 +
drivers/media/usb/dvb-usb/az6027.c   |7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)

diff -upNr linux-3.10/drivers/media/dvb-core/dvb-usb-ids.h
linux-3.10-patched/drivers/media/dvb-core/dvb-usb-ids.h
--- linux-3.10/drivers/media/dvb-core/dvb-usb-ids.h 2013-07-01
00:13:29.0 +0200
+++ linux-3.10-patched/drivers/media/dvb-core/dvb-usb-ids.h 2013-07-20
18:01:23.573035824 +0200
@@ -353,6 +353,7 @@
 #define USB_PID_ELGATO_EYETV_DTT_2 0x003f
 #define USB_PID_ELGATO_EYETV_DTT_Dlx   0x0020
 #define USB_PID_ELGATO_EYETV_SAT   0x002a
+#define USB_PID_ELGATO_EYETV_SAT_CI0x0025
 #define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD0x5000
 #define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM0x5001
 #define USB_PID_FRIIO_WHITE0x0001
diff -upNr linux-3.10/drivers/media/usb/dvb-usb/az6027.c
linux-3.10-patched/drivers/media/usb/dvb-usb/az6027.c
--- linux-3.10/drivers/media/usb/dvb-usb/az6027.c   2013-07-01
00:13:29.0 +0200
+++ linux-3.10-patched/drivers/media/usb/dvb-usb/az6027.c   2013-07-20
18:31:47.622924602 +0200
@@ -1088,6 +1088,7 @@ static struct usb_device_id az6027_usb_t
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V1) },
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V2) },
{ USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT) },
+   { USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT_CI) },
{ },
 };
 
@@ -1136,7 +1137,7 @@ static struct dvb_usb_device_properties
 
.i2c_algo = _i2c_algo,
 
-   .num_device_descs = 6,
+   .num_device_descs = 7,
.devices = {
{
.name = "AZUREWAVE DVB-S/S2 USB2.0 (AZ6027)",
@@ -1162,6 +1163,10 @@ static struct dvb_usb_device_properties
.name = "Elgato EyeTV Sat",
.cold_ids = { _usb_table[5], NULL },
.warm_ids = { NULL },
+   }, {
+   .name = "Elgato EyeTV Sat",
+   .cold_ids = { _usb_table[6], NULL },
+   .warm_ids = { NULL },
},
{ 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: compile error on 3.10.1

[Thomas Fjellstrom]

On Sat 20 July 2013 11:02:10 you wrote:
> On Sat, Jul 20, 2013 at 09:59:57AM -0600, Thomas Fjellstrom wrote:
> > Hi, just trying to compile a vanilla kernel and building using
> > allmodconfig and using oldconfig with the debian 3.10.1 config as a base.
> > 
> > With the later config, I get the following:
> 
> Is this new to 3.10.1 and works fine for 3.10.0? 

I'll check.

All I've tested so far is debian's 2.6.32, 3.9.8, 3.10.1, and a vanilla 3.10.1 
(with allmodconfig and oldconfig+debian config).

> >   CC [M]  drivers/net/wireless/ath/wil6210/debugfs.o
> > drivers/net/wireless/ath/wil6210/debugfs.c: In function âwil_print_ringâ:
> > drivers/net/wireless/ath/wil6210/debugfs.c:163:11: error: pointer targets 
in 
> > passing argument 5 of âhex_dump_to_bufferâ differ in signedness [-
> > Werror=pointer-sign]
> >false);
> >^
> > In file included from include/linux/kernel.h:13:0,
> >  from include/linux/cache.h:4,
> >  from include/linux/time.h:4,
> >  from include/linux/stat.h:18,
> >  from include/linux/module.h:10,
> >  from drivers/net/wireless/ath/wil6210/debugfs.c:17:
> > include/linux/printk.h:361:13: note: expected âchar *â but argument is of 
type 
> > âunsigned char *â
> >  extern void hex_dump_to_buffer(const void *buf, size_t len,
> >  ^
> > drivers/net/wireless/ath/wil6210/debugfs.c: In function 
> > âwil_txdesc_debugfs_showâ:
> > drivers/net/wireless/ath/wil6210/debugfs.c:429:10: error: pointer targets 
in 
> > passing argument 5 of âhex_dump_to_bufferâ differ in signedness [-
> > Werror=pointer-sign]
> >   sizeof(printbuf), false);
> >   ^
> > In file included from include/linux/kernel.h:13:0,
> >  from include/linux/cache.h:4,
> >  from include/linux/time.h:4,
> >  from include/linux/stat.h:18,
> >  from include/linux/module.h:10,
> >  from drivers/net/wireless/ath/wil6210/debugfs.c:17:
> > include/linux/printk.h:361:13: note: expected âchar *â but argument is of 
type 
> > âunsigned char *â
> >  extern void hex_dump_to_buffer(const void *buf, size_t len,
> >  ^
> > cc1: all warnings being treated as errors
> > make[5]: *** [drivers/net/wireless/ath/wil6210/debugfs.o] Error 1
> > make[4]: *** [drivers/net/wireless/ath/wil6210] Error 2
> > make[3]: *** [drivers/net/wireless/ath] Error 2
> > make[2]: *** [drivers/net/wireless] Error 2
> > make[1]: *** [drivers/net] Error 2
> > make: *** [drivers] Error 2
> > 
> > There are also a bunch of warnings, most of the ones I could catch are
> > signedness related.
> 
> Care to send this to the atheros wireless developers?  I'm sure they
> would like to know about it.

Can do.

> greg k-h
-- 
Thomas Fjellstrom
tfjellst...@strangesoft.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ioatdma: silence GCC warnings

[Paul Bolle]

Building dma_v3.o triggers a GCC warning:
drivers/dma/ioat/dma_v3.c: In function ‘__ioat3_prep_pq16_lock’:
drivers/dma/ioat/dma_v3.c:264:11: warning: array subscript is below array 
bounds [-Warray-bounds]
drivers/dma/ioat/dma_v3.c:264:11: warning: array subscript is below array 
bounds [-Warray-bounds]

This warning is caused by pq16_set_src(). It uses "int idx" as an index
to an eight element array. Changing "idx" to "unsigned" silences this
warning. Apparently GCC can then determine that "idx" will never be
negative.

Signed-off-by: Paul Bolle 
---
0) v2: cut back to a one hunk change, as Dan suggested.

1) Still just compile tested.

 drivers/dma/ioat/dma_v3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/ioat/dma_v3.c b/drivers/dma/ioat/dma_v3.c
index b642e03..2bb4601 100644
--- a/drivers/dma/ioat/dma_v3.c
+++ b/drivers/dma/ioat/dma_v3.c
@@ -251,7 +251,7 @@ static bool is_bwd_noraid(struct pci_dev *pdev)
 }
 
 static void pq16_set_src(struct ioat_raw_descriptor *desc[3],
-   dma_addr_t addr, u32 offset, u8 coef, int idx)
+   dma_addr_t addr, u32 offset, u8 coef, unsigned idx)
 {
struct ioat_pq_descriptor *pq = (struct ioat_pq_descriptor *)desc[0];
struct ioat_pq16a_descriptor *pq16 =
-- 
1.8.1.4

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

Re: compile error on 3.10.1

[Greg KH]

On Sat, Jul 20, 2013 at 09:59:57AM -0600, Thomas Fjellstrom wrote:
> Hi, just trying to compile a vanilla kernel and building using
> allmodconfig and using oldconfig with the debian 3.10.1 config as a base.
> 
> With the later config, I get the following:

Is this new to 3.10.1 and works fine for 3.10.0? 

>   CC [M]  drivers/net/wireless/ath/wil6210/debugfs.o
> drivers/net/wireless/ath/wil6210/debugfs.c: In function âwil_print_ringâ:
> drivers/net/wireless/ath/wil6210/debugfs.c:163:11: error: pointer targets in 
> passing argument 5 of âhex_dump_to_bufferâ differ in signedness [-
> Werror=pointer-sign]
>false);
>^
> In file included from include/linux/kernel.h:13:0,
>  from include/linux/cache.h:4,
>  from include/linux/time.h:4,
>  from include/linux/stat.h:18,
>  from include/linux/module.h:10,
>  from drivers/net/wireless/ath/wil6210/debugfs.c:17:
> include/linux/printk.h:361:13: note: expected âchar *â but argument is of 
> type 
> âunsigned char *â
>  extern void hex_dump_to_buffer(const void *buf, size_t len,
>  ^
> drivers/net/wireless/ath/wil6210/debugfs.c: In function 
> âwil_txdesc_debugfs_showâ:
> drivers/net/wireless/ath/wil6210/debugfs.c:429:10: error: pointer targets in 
> passing argument 5 of âhex_dump_to_bufferâ differ in signedness [-
> Werror=pointer-sign]
>   sizeof(printbuf), false);
>   ^
> In file included from include/linux/kernel.h:13:0,
>  from include/linux/cache.h:4,
>  from include/linux/time.h:4,
>  from include/linux/stat.h:18,
>  from include/linux/module.h:10,
>  from drivers/net/wireless/ath/wil6210/debugfs.c:17:
> include/linux/printk.h:361:13: note: expected âchar *â but argument is of 
> type 
> âunsigned char *â
>  extern void hex_dump_to_buffer(const void *buf, size_t len,
>  ^
> cc1: all warnings being treated as errors
> make[5]: *** [drivers/net/wireless/ath/wil6210/debugfs.o] Error 1
> make[4]: *** [drivers/net/wireless/ath/wil6210] Error 2
> make[3]: *** [drivers/net/wireless/ath] Error 2
> make[2]: *** [drivers/net/wireless] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
> 
> There are also a bunch of warnings, most of the ones I could catch are
> signedness related.

Care to send this to the atheros wireless developers?  I'm sure they
would like to know about it.

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

[no subject]

[Mr.Jerry Smith]

 
DO YOU NEED A LOAN? EMAIL US NOW WITH AMOUNT NEEDED AS LOAN.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/12] drivers/tty/serial: don't use devm_pinctrl_get_select_default() in probe

[Greg KH]

On Sat, Jul 20, 2013 at 07:46:48PM +0200, Linus Walleij wrote:
> On Thu, Jul 11, 2013 at 9:40 AM, Nicolas Ferre  
> wrote:
> > On 10/07/2013 17:57, Wolfram Sang :
> >
> >> Since commit ab78029 (drivers/pinctrl: grab default handles from device
> >> core),
> >> we can rely on device core for setting the default pins. Compile tested
> >> only.
> >>
> >> Acked-by: Linus Walleij  (personally at LCE13)
> >> Signed-off-by: Wolfram Sang 
> >> ---
> >>   drivers/tty/serial/atmel_serial.c |8 
> >
> >
> > For atmel_serial.c:
> >
> > Acked-by: Nicolas Ferre 
> 
> Greg can you please apply this to the TTY tree if it looks
> OK to you?

Will do, thanks.

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

Re: [PATCH 03/12] drivers/misc: don't use devm_pinctrl_get_select_default() in probe

[Greg KH]

On Sat, Jul 20, 2013 at 07:45:42PM +0200, Linus Walleij wrote:
> On Thu, Jul 11, 2013 at 1:13 AM, Arnd Bergmann  wrote:
> > On Wednesday 10 July 2013, Wolfram Sang wrote:
> >> Since commit ab78029 (drivers/pinctrl: grab default handles from device 
> >> core),
> >> we can rely on device core for setting the default pins. Compile tested 
> >> only.
> >>
> >> Acked-by: Linus Walleij  (personally at LCE13)
> >> Signed-off-by: Wolfram Sang 
> >
> > Acked-by: Arnd Bergmann 
> 
> I think that the idea is to merge this through respective subsystem.
> Greg, can you take this into your misc-char tree?

Sure, will do.

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

Re: [PATCH 06/12] drivers/mtd/nand/gpmi-nand: don't use devm_pinctrl_get_select_default() in probe

[Linus Walleij]

On Wed, Jul 10, 2013 at 5:57 PM, Wolfram Sang  wrote:

> Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
> we can rely on device core for setting the default pins. Compile tested only.
>
> Acked-by: Linus Walleij  (personally at LCE13)
> Signed-off-by: Wolfram Sang 

Artem  if you're OK with this please carry it in the MTD tree.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/12] drivers/tty/serial: don't use devm_pinctrl_get_select_default() in probe

[Linus Walleij]

On Thu, Jul 11, 2013 at 9:40 AM, Nicolas Ferre  wrote:
> On 10/07/2013 17:57, Wolfram Sang :
>
>> Since commit ab78029 (drivers/pinctrl: grab default handles from device
>> core),
>> we can rely on device core for setting the default pins. Compile tested
>> only.
>>
>> Acked-by: Linus Walleij  (personally at LCE13)
>> Signed-off-by: Wolfram Sang 
>> ---
>>   drivers/tty/serial/atmel_serial.c |8 
>
>
> For atmel_serial.c:
>
> Acked-by: Nicolas Ferre 

Greg can you please apply this to the TTY tree if it looks
OK to you?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/12] drivers/misc: don't use devm_pinctrl_get_select_default() in probe

[Linus Walleij]

On Thu, Jul 11, 2013 at 1:13 AM, Arnd Bergmann  wrote:
> On Wednesday 10 July 2013, Wolfram Sang wrote:
>> Since commit ab78029 (drivers/pinctrl: grab default handles from device 
>> core),
>> we can rely on device core for setting the default pins. Compile tested only.
>>
>> Acked-by: Linus Walleij  (personally at LCE13)
>> Signed-off-by: Wolfram Sang 
>
> Acked-by: Arnd Bergmann 

I think that the idea is to merge this through respective subsystem.
Greg, can you take this into your misc-char tree?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] minnowboard: Add base platform driver for the MinnowBoard

[Linus Walleij]

On Thu, Jul 4, 2013 at 6:26 PM, Mark Brown  wrote:
> On Thu, Jun 27, 2013 at 10:43:38PM -0700, Darren Hart wrote:
>
>> minnow_hwid() just returns an int that the minnowboard platform driver
>> read from the GPIO. This seems like a proper abstraction to me. Do you
>> object to this one as well?
>
> We should really have a subsystem for this too - the general idea idea
> of identifying boards, fit options and so on by looking at things like
> GPIOs or numbers in flash is really common.

Would it then be a bus following the pattern we chiseled out for
the soc bus? (Greg, Lee & Arnd architectured this.)

There we needed a struct device * on an overarching level to
tie in the sysfs entries reading out the SoC properties. But
it would be the same thing with in-kernel accessors for these
properties.

So it would be the same pattern above with a board bus, in
DT syntax:

board {
 soc {
 };
};

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: generic: add simple card with devicetree support

[Jean-Francois Moine]

This generic simple card driver uses DT values to instanciate an audio
system in which the real work is done by the subdrivers (audio
controller, audio codec and pcm/dma controller).

Signed-off-by: Jean-Francois Moine 
---
 Documentation/devicetree/bindings/sound/simple-dt-card.txt |  18 
 sound/soc/generic/Kconfig |   7 ++
 sound/soc/generic/Makefile|   2 +
 sound/soc/generic/simple-dt-card.c| 137 

 4 files changed, 163 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/simple-dt-card.txt 
b/Documentation/devicetree/bindings/sound/simple-dt-card.txt
new file mode 100644
index 000..45f41cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/simple-dt-card.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for simple DT audio card
+
+Required properties:
+  - compatible: should be "linux,simple-dt-audio".
+  - audio-controller: phandle of the audio controller
+  - audio-codec: phandle of the audio codec
+  - platform-pcm-dma: phandle of the PCM/DMA controller
+  - codec-dai-name: name of the codec dai
+
+Example node:
+
+   sound {
+   compatible = "linux,simple-dt-audio";
+   audio-controller = <>;
+   audio-codec = <>;
+   platform-pcm-dma = <>;
+   codec-dai-name = "dit-hifi";
+   };
diff --git a/sound/soc/generic/Kconfig b/sound/soc/generic/Kconfig
index 610f612..e593224 100644
--- a/sound/soc/generic/Kconfig
+++ b/sound/soc/generic/Kconfig
@@ -2,3 +2,10 @@ config SND_SIMPLE_CARD
tristate "ASoC Simple sound card support"
help
  This option enables generic simple sound card support
+
+config SND_SIMPLE_DT_CARD
+   tristate "ASoC Simple sound card support (Flattened Device Tree)"
+   depends on OF
+   help
+ This option enables generic simple sound card support
+ using flattened device tree.
diff --git a/sound/soc/generic/Makefile b/sound/soc/generic/Makefile
index 9c3b246..65ddd3e 100644
--- a/sound/soc/generic/Makefile
+++ b/sound/soc/generic/Makefile
@@ -1,3 +1,5 @@
 snd-soc-simple-card-objs   := simple-card.o
+snd-soc-simple-dt-card-objs:= simple-dt-card.o
 
 obj-$(CONFIG_SND_SIMPLE_CARD)  += snd-soc-simple-card.o
+obj-$(CONFIG_SND_SIMPLE_DT_CARD) += snd-soc-simple-dt-card.o
diff --git a/sound/soc/generic/simple-dt-card.c 
b/sound/soc/generic/simple-dt-card.c
new file mode 100644
index 000..d373d68
--- /dev/null
+++ b/sound/soc/generic/simple-dt-card.c
@@ -0,0 +1,137 @@
+/*
+ * Simple DT defined sound card support
+ *
+ * Copyright (C) 2013 Jean-Francois Moine 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static int simple_dt_remove(struct platform_device *pdev)
+{
+   struct snd_soc_card *card = platform_get_drvdata(pdev);
+   struct snd_soc_dai_link *link;
+
+   snd_soc_unregister_card(card);
+   link = card->dai_link;
+   if (link) {
+   of_node_put((struct device_node *) link->platform_of_node);
+   of_node_put((struct device_node *) link->codec_of_node);
+   of_node_put((struct device_node *) link->cpu_of_node);
+   kfree(link);
+   }
+   kfree(card);
+   return 0;
+}
+
+static int simple_dt_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
+   struct snd_soc_card *card;
+   struct snd_soc_dai_link *link;
+   int ret;
+
+   if (!np) {
+   dev_err(dev, "no device-tree\n");
+   return -ENXIO;
+   }
+
+   card = kzalloc(sizeof *card, GFP_KERNEL);
+   if (!card) {
+   dev_err(dev, "unable to allocate soc card\n");
+   return -ENOMEM;
+   }
+   card->name = "Simple DT audio card";
+   card->owner = THIS_MODULE;
+   card->dev = dev;
+   platform_set_drvdata(pdev, card);
+
+   link = kzalloc(sizeof *link, GFP_KERNEL);
+   if (!link) {
+   dev_err(dev, "unable to allocate soc link\n");
+   ret = -ENOMEM;
+   goto err;
+   }
+   card->dai_link = link;
+   card->num_links = 1;
+
+   link->name = "Simple audio";
+   link->stream_name = "Playback";
+
+   link->cpu_of_node = of_parse_phandle(np, "audio-controller", 0);
+   if 

Re: [PATCH] mm: negative left shift count when PAGE_SHIFT > 20

[Jerry]

2013/7/20 Andrew Morton :
> On Fri, 19 Jul 2013 07:47:02 +0800 Jerry  wrote:
>
>> 2013/7/19 Andrew Morton :
>> > On Fri, 19 Jul 2013 00:56:12 +0800 Jerry  wrote:
>> >
>> >> When PAGE_SHIFT > 20, the result of "20 - PAGE_SHIFT" is negative. The
>> >> calculating here will generate an unexpected result. In addition, if
>> >> PAGE_SHIFT > 20, The memory size represented by numentries was already
>> >> integral multiple of 1MB.
>> >>
>> >
>> > If you tell me that you have a machine which has PAGE_SIZE=2MB and this
>> > was the only problem which prevented Linux from running on that machine
>> > then I'll apply the patch ;)
>> >
>>
>> Hi Morton:
>> I just "grep -rn "#define\s\+PAGE_SHIFT" arch/", and find the
>> PAGE_SHIFT in some architecture is very big.
>> such as the following in "arch/hexagon/include/asm/page.h"
>> 
>> #ifdef CONFIG_PAGE_SIZE_256KB
>> #define PAGE_SHIFT 18
>> #define HEXAGON_L1_PTE_SIZE __HVM_PDE_S_256KB
>> #endif
>>
>> #ifdef CONFIG_PAGE_SIZE_1MB
>> #define PAGE_SHIFT 20
>> #define HEXAGON_L1_PTE_SIZE __HVM_PDE_S_1MB
>> #endif
>> .
>
> Good heavens.
>
>> In my patch, I think compiler would optimize "if (20 > PAGE_SIZE)", it
>> won't generate any machine instruction. Just a guarantee.
>
> Well the existing code is a bit silly looking.  Why can't we just do
>
> /* round applicable memory size up to nearest megabyte */
> if (PAGE_SHIFT < 20)
> numentries = round_up(nr_kernel_pages, (1 << 20)/PAGE_SIZE);
>
> or similar?

Great. I have adjusted these code lines, and sent the latest one.

--
I love linux!!!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: negative left shift count when PAGE_SHIFT > 20

[Jerry Zhou]

When PAGE_SHIFT > 20, the result of "20 - PAGE_SHIFT" is negative. The
previous calculating here will generate an unexpected result. In
addition, if PAGE_SIZE >= 1MB, The memory size of "numentries" was
already integral multiple of 1MB.

Signed-off-by: Jerry Zhou 
---
 mm/page_alloc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b100255..7c469c6 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5745,9 +5745,10 @@ void *__init alloc_large_system_hash(const char 
*tablename,
if (!numentries) {
/* round applicable memory size up to nearest megabyte */
numentries = nr_kernel_pages;
-   numentries += (1UL << (20 - PAGE_SHIFT)) - 1;
-   numentries >>= 20 - PAGE_SHIFT;
-   numentries <<= 20 - PAGE_SHIFT;
+
+   /* It isn't necessary when PAGE_SIZE >= 1MB */
+   if (PAGE_SHIFT < 20)
+   numentries = round_up(numentries, (1<<20)/PAGE_SIZE);
 
/* limit to 1 bucket per 2^scale bytes of low memory */
if (scale > PAGE_SHIFT)
-- 
1.8.1.5

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

Re: New device tree mailing list

[Hank Leininger]

On Sat, Jul 20, 2013 at 06:28:19PM +0200, Linus Walleij wrote:
> Hi MARC list archive folks,
> 
> could you please start archiving the following recently addes VGER lists
> at marc.info:
> 
> These go into the "Linux" folder:
> linux-gpio: http://vger.kernel.org/vger-lists.html#linux-gpio
> linux-spi: http://vger.kernel.org/vger-lists.html#linux-spi
> 
> This one goes into "Development" or "Misc" I guess:
> devicetree: http://vger.kernel.org/vger-lists.html#devicetree

Sure, I've just subscribed us to all three.  They'll show in 'Misc' once
some traffic comes in, and then I'll (have to remember to) move them.

I realize MARC didn't carry the old/original devicetree-discuss list at
ozlabs.  I'm pulling down the archives from that list now.  Should I
import them as 'devicetree-discuss' (historically accurate) or as
'devicetree' (so they will appear seamless in MARC w/the new vger list's
traffic)?

AFAIK vger doesn't keep copies of old messages, but if any list-members
have mailspools of past traffic for linux-gpio and/or linux-spi, please
contact me directly and I'll import them.

Thanks,

-- 

Hank Leininger 
3C2A 4EEE ED36 D136 18F2  1B30 47A8 D14B E13E 9C6A


signature.asc
Description: Digital signature

Re: [PATCH v4 3/3] gpio-tz1090: convert to use generic irqchip

[Linus Walleij]

On Tue, Jun 25, 2013 at 4:27 PM, James Hogan  wrote:

> Convert gpio-tz1090 driver to use generic irqchips. This allows the
> irq_ack, irq_mask, and irq_unmask callbacks and associated helper
> functions to be removed. Also switch to using irq_setup_alt_chip() in
> the irq_set_type callback instead of using __irq_set_handler_locked().
>
> Signed-off-by: James Hogan 
> Cc: Linus Walleij 
> Cc: Grant Likely 
> ---
> This patch depends on the generic irqchip linear irqdomain work in
> tip/irq/core.
>
> Changes in v4:

Patch applied. Confirm that the infrastructure is now upstream
pls, this is applied on top of v3.11-rc1.

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

Re: [PATCH v4 2/3] gpio-tz1090-pdc: add TZ1090 PDC gpio driver

[Linus Walleij]

On Tue, Jun 25, 2013 at 4:27 PM, James Hogan  wrote:

> Add a GPIO driver for the low-power Powerdown Controller GPIOs in the
> TZ1090 SoC.
>
> The driver is instantiated by device tree and supports interrupts for
> the SysWake GPIOs only.
>
> Signed-off-by: James Hogan 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Rob Landley 
> Cc: Linus Walleij 
> Cc: linux-...@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> ---
> Changes in v4:

Patch applied.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Ben Hutchings]

On Fri, 2013-07-19 at 13:42 -0500, Felipe Contreras wrote:
> On Fri, Jul 19, 2013 at 7:08 AM, Ingo Molnar  wrote:
> >
> > * Felipe Contreras  wrote:
> 
> >> As Linus already pointed out, not everybody has to work with everybody.
> >
> > That's not the point though, the point is to potentially roughly double
> > the creative brain capacity of the Linux kernel project.
> 
> Unfortunately that's impossible; we all know there aren't as many
> women programmers as there are men.

In some countries, though not all.

But we also know (or should realise) that the gender ratio among
programmers in general is much less unbalanced than in some free
software communities including the Linux kernel developers.

> So there's absolutely *nothing*
> the Linux kernel can do to double the creative brain capacity of the
> Linux kernel project (at least with respect to women).
>
> At best that is a societal/academic/professional issue, not a Linux issue.
[...]

There is a broader societal issue, but that doesn't mean that there
isn't also a problem at the level of individual developer communities.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v4 1/3] gpio-tz1090: add TZ1090 gpio driver

[Linus Walleij]

On Tue, Jun 25, 2013 at 4:27 PM, James Hogan  wrote:

> Add a GPIO driver for the main GPIOs found in the TZ1090 (Comet) SoC.
> This doesn't include low-power GPIOs as they're controlled separately
> via the Powerdown Controller (PDC) registers.
>
> The driver is instantiated by device tree and supports interrupts for
> all GPIOs.
>
> Signed-off-by: James Hogan 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Rob Landley 
> Cc: Linus Walleij 
> Cc: linux-...@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> ---
> Changes in v4:

Patch applied now. It is better to not stress things and queue this for v3.12
now that the pinctrl portions are in for v3.11.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] RTC: Add an alarm disable quirk

[Borislav Petkov]

41c7f7424259f ("rtc: Disable the alarm in the hardware (v2)") added the
functionality to disable the RTC wake alarm when shutting down the box.

However, there are at least two b0rked BIOSes we know about:

https://bugzilla.novell.com/show_bug.cgi?id=812592
https://bugzilla.novell.com/show_bug.cgi?id=805740

where, when wakeup alarm is enabled in the BIOS, the machine reboots
automatically right after shutdown, regardless of what wakeup time is
programmed.

Bisecting the issue lead to this patch so disable its functionality with
a DMI quirk only for those boxes.

Signed-off-by: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: John Stultz 
Cc: Rabin Vincent 
---
 drivers/rtc/rtc-cmos.c | 40 +++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index be06d7150de5..906b45c644e1 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -34,11 +34,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
 #include 
@@ -377,6 +377,39 @@ static int cmos_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
return 0;
 }
 
+/*
+ * Do not disable RTC alarm on shutdown - workaround for b0rked BIOSes.
+ */
+static bool disable_alarm = true;
+
+static int __init clear_disable_alarm(const struct dmi_system_id *id)
+{
+   disable_alarm = false;
+   return 0;
+}
+
+static const struct dmi_system_id rtc_quirks[] __initconst = {
+   /* https://bugzilla.novell.com/show_bug.cgi?id=805740 */
+   {
+   .callback = clear_disable_alarm,
+   .ident= "IBM Truman",
+   .matches  = {
+   DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "4852570"),
+   },
+   },
+   /* https://bugzilla.novell.com/show_bug.cgi?id=812592 */
+   {
+   .callback = clear_disable_alarm,
+   .ident= "Gigabyte GA-990XA-UD3",
+   .matches  = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Gigabyte Technology Co., 
Ltd."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "GA-990XA-UD3"),
+   },
+   },
+   {}
+};
+
 static int cmos_alarm_irq_enable(struct device *dev, unsigned int enabled)
 {
struct cmos_rtc *cmos = dev_get_drvdata(dev);
@@ -385,6 +418,9 @@ static int cmos_alarm_irq_enable(struct device *dev, 
unsigned int enabled)
if (!is_valid_irq(cmos->irq))
return -EINVAL;
 
+   if (!disable_alarm)
+   return 0;
+
spin_lock_irqsave(_lock, flags);
 
if (enabled)
@@ -1172,6 +1208,8 @@ static int __init cmos_init(void)
platform_driver_registered = true;
}
 
+   dmi_check_system(rtc_quirks);
+
if (retval == 0)
return 0;
 
-- 
1.8.3

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 20/20] tty: Remove extra wakeup from pty write() path

[Peter Hurley]

On 06/15/2013 10:21 AM, Peter Hurley wrote:

Acquiring the write_wait queue spin lock now accounts for the largest
slice of cpu time on the tty write path. Two factors contribute to
this situation; a overly-pessimistic line discipline write loop which
_always_ sets up a wait loop even if i/o will immediately succeed, and
on ptys, a wakeup storm from reads and writes.

Writer wakeup does not need to be performed by the pty driver.
Firstly, since the actual i/o is performed within the write, the
line discipline write loop will continue while space remains in
the flip buffers. Secondly, when space becomes avail in the
line discipline receive buffer (and thus also in the flip buffers),
the pty unthrottle re-wakes the writer (non-flow-controlled line
disciplines unconditionally unthrottle the driver when data is
received). Thus, existing in-kernel i/o is guaranteed to advance.
Finally, writer wakeup occurs at the conclusion of the line discipline
write (in tty_write_unlock()). This guarantees that any user-space write
waiters are woken to continue additional i/o.


Greg,

I thought I should let you know I'm tracking down a bug/regression
related to this patch.

In certain unusual pty/ldisc configurations, i/o fails to make
forward progress. I still stand by my commit message above, so I'm
in the process of instrumenting the i/o path so I can uncover the
cause of the failure.

I would still recommend applying this patch to tty-next, as it
resolves a much more critical bug discussed here [1].

Doing a write_wakeup() from a driver .write() method is a no-no;
recursion is possible and results in a thread stack overrun.

Regards,
Peter Hurley

[1]
https://lkml.org/lkml/2013/7/1/308


Signed-off-by: Peter Hurley 
---
  drivers/tty/pty.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 0634dd9..b9bc5be 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -121,10 +121,8 @@ static int pty_write(struct tty_struct *tty, const 
unsigned char *buf, int c)
/* Stuff the data into the input queue of the other end */
c = tty_insert_flip_string(to->port, buf, c);
/* And shovel */
-   if (c) {
+   if (c)
tty_flip_buffer_push(to->port);
-   tty_wakeup(tty);
-   }
}
return c;
  }



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86 fixes for 3.11-rc2

[Borislav Petkov]

On Sat, Jul 20, 2013 at 10:47:58AM -0400, George Spelvin wrote:
> Borislav Petkov  wrote:
> > I don't think that matters because this is called only once on suspend.
> > Unless the cleaner assembly translates into a palpable speedup, which I
> > doubt.
> 
> I was thinking about code *size*, actually; I agree that speed is
> too small to measure.
> 
> Clean code (21 bytes):
>   4e:   b9 80 00 00 c0  mov$0xc080,%ecx
>   53:   0f 32   rdmsr  
>   55:   0f 30   wrmsr  
>   57:   31 f6   xor%esi,%esi
>   59:   85 f6   test   %esi,%esi
>   5b:   89 43 14mov%eax,0x14(%ebx)
>   5e:   89 53 18mov%edx,0x18(%ebx)
>   61:   75 04   jne67 
> 
> Ugly code (50 bytes):

Right, that would matter maybe partially if the code was executed very
often. In that case, the probability of it fitting in one cacheline is
higher depending on alignment, and, you'd possibly save yourself loading
a second cacheline.

If it is 29 bytes bigger, than we have a higher probability for using a
second cacheline.

But again, I highly doubt even that would be noticeable. Especially on
modern uarches with very aggressive and smart branch prediction.

And since this is being called only once, you won't notice the
difference even with perf and specific instruction cache counters
enabled.

But what do I know - I'm always open to surprising workloads! :-)

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: choose debug/uncompress.h include when uncompress debug is disabledo

[Arnd Bergmann]

On Thursday 18 July 2013, Stefano Stabellini wrote:
> > Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels)
> > supposed to be part of the multiplatform kernel stuff now?
> 
> Most of them, yes. However some of them, like exynos5250, are not yet.

It's just a matter of time. I had a patch for 3.10 to enable multiplatform
on exynos, but it missed both the 3.10 and 3.11 merge windows by a small
margin (for different reasons). We definitely want all ARMv7 platforms
to be multiplatform in the not too distant future.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/38] 3.9.11-stable review

[Greg Kroah-Hartman]

On Sat, Jul 20, 2013 at 04:34:41PM +, Shuah Khan wrote:
> On 07/19/2013 06:10 PM, Shuah Khan wrote:
> > On 07/19/2013 05:50 PM, Greg Kroah-Hartman wrote:
> >> On Fri, Jul 19, 2013 at 12:25:24PM -0700, Greg Kroah-Hartman wrote:
> >>> On Fri, Jul 19, 2013 at 04:45:25PM +, Shuah Khan wrote:
>  On 07/19/2013 09:34 AM, Greg Kroah-Hartman wrote:
> > ---
> > Note, this is the LAST 3.9-stable kernel release that I will be doing.
> > Please move to the 3.10-stable branch as soon as possible.
> > ---
> >
> > This is the start of the stable review cycle for the 3.9.11 release.
> > There are 38 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> 
>  Greg,
> 
>  Build failed with the following error:
> 
>   LD  ipc/built-in.o
>   CC [M]  fs/cifs/inode.o
>  fs/cifs/inode.c: In function ‘cifs_all_info_to_fattr’:
>  fs/cifs/inode.c:560:4: error: implicit declaration of function
>  ‘cifs_dbg’ [-Werror=implicit-function-declaration]
>  cc1: some warnings being treated as errors
>  make[2]: *** [fs/cifs/inode.o] Error 1
>  make[1]: *** [fs/cifs] Error 2
>  make: *** [fs] Error 2
>  make: *** Waiting for unfinished jobs
>   CC  security/selinux/hooks.o
> 
>  I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled.
>  cifs_dbg() is not defined.
> >>>
> >>> Ugh, I thought I fixed that one...  I did it for the 3.4 and other
> >>> trees, I'll go see what I did wrong...
> >>
> >> Ok, I've now fixed this, I don't know how it got through my tests, when
> >> I tried it again, it failed.  Before it wasn't, odd...
> >>
> >> Anyway, there is a new -rc2 kernel patch at:
> >>
> >> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc2.gz
> >>
> >> If you could test that out, I would appreciate it, to ensure I didn't do
> >> anything stupid with this one too.
> >>
> >> Ick, handling 4 kernels at once really takes its toll on me, this was
> >> not a good review cycle...
> >>
> >> thanks,
> >>
> >> greg k-h
> >>
> >
> > Greg,
> >
> > rc2 compiled on x86-64. I will run cross-compile tests and boot tests
> > later on today or tomorrow morning and report the results.
> >
> > -- Shuah
> >
> > Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
> > America (Silicon Valley) shuah...@samsung.com | (970) 672-0658
> >
> 
> 3.9.11-rc2 boot tests passed on my test systems and cross-compile tests 
> passed. No regressions in dmesgs.

Wonderful, thanks so much for testing and letting me know.

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

Re: [ipc,shm] BUG: lock held when returning to user space!

[Davidlohr Bueso]

On Sun, 2013-07-21 at 00:02 +0800, Xiaotian Feng wrote:
> On Sat, Jul 20, 2013 at 9:13 PM, Fengguang Wu  wrote:
> > Greetings,
> >
> > I got the below dmesg and the first bad commit is
> >
> > commit c5d0282a0405b0a81fa3390e4230e4cbb3ced7a2
> > Author: Davidlohr Bueso 
> > Date:   Fri Jul 19 09:56:58 2013 +1000
> >
> > ipc,shm: shorten critical region for shmat
> >
> > Similar to other system calls, acquire the kern_ipc_perm lock after 
> > doing
> > the initial permission and security checks.
> >
> > Signed-off-by: Davidlohr Bueso 
> > Tested-by: Sedat Dilek 
> > Cc: Rik van Riel 
> > Cc: Manfred Spraul 
> > Signed-off-by: Andrew Morton 
> >
> > [   20.702156]
> > [   20.702493] 
> > [   20.703511] [ BUG: lock held when returning to user space! ]
> > [   20.704532] 3.11.0-rc1-next-20130719 #50 Not tainted
> > [   20.705416] 
> > [   20.706425] trinity-child0/174 is leaving the kernel with locks still 
> > held!
> > [   20.707638] 1 lock held by trinity-child0/174:
> > [   20.708475]  #0:  (rcu_read_lock){.+.+..}, at: [] 
> > do_shmat+0xe1/0x500
> >
> 
> 
> ns = current->nsproxy->ipc_ns;
> - shp = shm_lock_check(ns, shmid);
> + rcu_read_lock();
> + shp = shm_obtain_object_check(ns, shmid);
> if (IS_ERR(shp)) {
> err = PTR_ERR(shp);
> goto out;
> 
> 
> If shm_obtain_object_check() failed, goto out will return with
> rcu_read_lock() held.  I think following patch should cure this.

Yep that should solve it, sorry about that. Sasha Levin sent out a fix
for it yesterday (offline).

Thanks,
Davidlohr

> 
> diff --git a/ipc/shm.c b/ipc/shm.c
> index 59f2194..cb2ceda 100644
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -1093,7 +1093,7 @@ long do_shmat(int shmid, char __user *shmaddr,
> int shmflg, ulong *raddr,
>   shp = shm_obtain_object_check(ns, shmid);
>   if (IS_ERR(shp)) {
>   err = PTR_ERR(shp);
> - goto out;
> + goto out_unlock;
>   }
> 
>   err = -EACCES;
> 
> 
> 
> 
> > git bisect start c1f631b9a68251007a6353041ae90f9f7dca771c 
> > d03792f9db9b892f494d3aa19d767ddf0365d1ff --
> > git bisect good 10a3f1f902465ae1320cc95a3284fd3697e05dd8  # 11:14 65+  
> > binfmt_elf.c: use get_random_int() to fix entropy depleting
> > git bisect  bad dac28788378838efb63e37a7eabd7729d97aba6b  # 11:32  0-  
> > dcache: remove dentries from LRU before putting on dispose list
> > git bisect good 3140b2ed6dfe5c9e5eca371c77ca85dca05321d4  # 11:50 65+  
> > ipc,shm: introduce shmctl_nolock
> > git bisect  bad 48a91248649fa3327bd8a31c114ee9149a07f3a7  # 12:04  0-  
> > staging/lustre/ldlm: convert to shrinkers to count/scan API
> > git bisect good 98b78126a51aa5d3ee6d5dae5768e0d16deeeaa3  # 12:14 65+  
> > ipc,shm: cleanup do_shmat pasta
> > git bisect  bad 36ccfd799cad33e2edd5c14ac8776b33e63d195b  # 12:14  0-  
> > ipc: rename ids->rw_mutex
> > git bisect  bad c5d0282a0405b0a81fa3390e4230e4cbb3ced7a2  # 12:14  0-  
> > ipc,shm: shorten critical region for shmat
> > git bisect good 98b78126a51aa5d3ee6d5dae5768e0d16deeeaa3  # 15:34195+  
> > ipc,shm: cleanup do_shmat pasta
> > git bisect  bad c1f631b9a68251007a6353041ae90f9f7dca771c  # 15:34  0-  
> > Add linux-next specific files for 20130719
> > git bisect good 709b465ee655387c4ec056383fa27f16c64f48db  # 18:21195+  
> > Revert "ipc,shm: shorten critical region for shmat"
> > git bisect good d471ce53b1fab60110e4e9f647a345cea31752de  # 18:44195+  
> > Merge branch 'for-linus' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml
> > git bisect  bad c1f631b9a68251007a6353041ae90f9f7dca771c  # 18:44  0-  
> > Add linux-next specific files for 20130719
> >
> > 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: [PATCH 1/2] zcache: staging: %s/ZCACHE/ZCACHE_OLD

[Greg KH]

On Sat, Jul 20, 2013 at 10:36:57PM +0800, Bob Liu wrote:
> Signed-off-by: Bob Liu 
> ---
>  drivers/staging/zcache/Kconfig  |   12 ++--
>  drivers/staging/zcache/Makefile |4 ++--
>  2 files changed, 8 insertions(+), 8 deletions(-)

If you are going to give up on the code, why not just delete it?  No
need to keep it around anymore, right?

thanks

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

Re: [PATCH v4] watchdog: Add MOXA ART watchdog driver

[Arnd Bergmann]

On Friday 19 July 2013, Jonas Jensen wrote:
> diff --git 
> a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt 
> b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> new file mode 100644
> index 000..5507f2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> @@ -0,0 +1,15 @@
> +MOXA ART Watchdog timer
> +
> +Required properties:
> +
> +- compatible : Should be "moxa,moxart-watchdog"
> +- reg : Should contain registers location and length
> +- clocks : Should contain phandle for the MOXA ART core clock "coreclk"
> +
> +Example:
> +
> +   watchdog: watchdog@9850 {
> +   compatible = "moxa,moxart-watchdog";
> +   reg = <0x9850 0x10>;
> +   clocks = <>;
> +   };

I think the property descriptions need to be clarified here:

* I think "should" makes no sense for the "compatible" property since it is
  required here, you probably mean "must", see 
http://www.ietf.org/rfc/rfc2119.txt. 

* for the clock, make sure that the description is from the point of view of
  the device you are describing, not from the perspective of the clock 
controller.
  The device should not make any assumptions about who provides a clock, only
  what it is used for, and it sounds like "coreclk" is an SoC-wide identifier,
  not the name of the clock input of the watchdog device. This is not as 
important
  as you don't define a "clock-names" property here, butsomething to keep in
  mind anyway.

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

[PATCH v5] x86, tboot: iomem fixes

[Qiaowei Ren]

Current code doesn't use specific interface to access I/O space.
So some potential bugs can be caused. We can fix this by using
specific API.

Signed-off-by: Qiaowei Ren 
---
 arch/x86/kernel/tboot.c |   18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 3ff42d2..4e149c7 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -468,7 +468,8 @@ struct sinit_mle_data {
 
 struct acpi_table_header *tboot_get_dmar_table(struct acpi_table_header 
*dmar_tbl)
 {
-   void *heap_base, *heap_ptr, *config;
+   void __iomem *heap_base, *heap_ptr, *config;
+   u32 dmar_tbl_off;
 
if (!tboot_enabled())
return dmar_tbl;
@@ -485,25 +486,26 @@ struct acpi_table_header *tboot_get_dmar_table(struct 
acpi_table_header *dmar_tb
return NULL;
 
/* now map TXT heap */
-   heap_base = ioremap(*(u64 *)(config + TXTCR_HEAP_BASE),
-   *(u64 *)(config + TXTCR_HEAP_SIZE));
+   heap_base = ioremap(readl(config + TXTCR_HEAP_BASE),
+   readl(config + TXTCR_HEAP_SIZE));
iounmap(config);
if (!heap_base)
return NULL;
 
/* walk heap to SinitMleData */
/* skip BiosData */
-   heap_ptr = heap_base + *(u64 *)heap_base;
+   heap_ptr = heap_base + readq(heap_base);
/* skip OsMleData */
-   heap_ptr += *(u64 *)heap_ptr;
+   heap_ptr += readq(heap_ptr);
/* skip OsSinitData */
-   heap_ptr += *(u64 *)heap_ptr;
+   heap_ptr += readq(heap_ptr);
/* now points to SinitMleDataSize; set to SinitMleData */
heap_ptr += sizeof(u64);
/* get addr of DMAR table */
+   dmar_tbl_off = readl(heap_ptr +
+   offsetof(struct sinit_mle_data, vtd_dmars_off));
dmar_tbl = (struct acpi_table_header *)(heap_ptr +
-  ((struct sinit_mle_data *)heap_ptr)->vtd_dmars_off -
-  sizeof(u64));
+   dmar_tbl_off - sizeof(u64));
 
/* don't unmap heap because dmar.c needs access to this */
 
-- 
1.7.9.5

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

Re: [PATCH] ext4: fix a bug when we try to open a file with O_TMPFILE flag

[Zheng Liu]

Hi Al,

On Sat, Jul 20, 2013 at 12:36:13AM +0100, Al Viro wrote:
> On Fri, Jul 19, 2013 at 08:14:05PM +0800, Zheng Liu wrote:
> > Hi Dave,
> > 
> > After applied this patch, the problem has been fixed in my own sand box.
> > But that would be great if you could give it a try.  I want to make sure
> > that this patch can fix the problem.  It looks like there has the same
> > problem in ext3.  So if this patch is fine, I will generate a patch for
> > ext3 file system.
> 
> Nice catch, and you have my ACK.  Which tree do you prefer that to go
> through?  vfs and ext4 are the obvious candidates...

Now ext4 tree has not yet rebased against 3.11-rcX.  So it seems that
vfs tree is better if we want to fix this bug in mainline kernel as soon
as possible.  This patch is against mainline kernel.  I think it should
be applied into vfs tree cleanly.  Please let me know if I need to rebase
it against vfs tree.  BTW, the patch for ext3 file system will be sent
out soon.  Please pick it up.

Thanks,
- Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/38] 3.9.11-stable review

[Shuah Khan]

On 07/19/2013 06:10 PM, Shuah Khan wrote:
> On 07/19/2013 05:50 PM, Greg Kroah-Hartman wrote:
>> On Fri, Jul 19, 2013 at 12:25:24PM -0700, Greg Kroah-Hartman wrote:
>>> On Fri, Jul 19, 2013 at 04:45:25PM +, Shuah Khan wrote:
 On 07/19/2013 09:34 AM, Greg Kroah-Hartman wrote:
> ---
> Note, this is the LAST 3.9-stable kernel release that I will be doing.
> Please move to the 3.10-stable branch as soon as possible.
> ---
>
> This is the start of the stable review cycle for the 3.9.11 release.
> There are 38 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

 Greg,

 Build failed with the following error:

  LD  ipc/built-in.o
  CC [M]  fs/cifs/inode.o
 fs/cifs/inode.c: In function ‘cifs_all_info_to_fattr’:
 fs/cifs/inode.c:560:4: error: implicit declaration of function
 ‘cifs_dbg’ [-Werror=implicit-function-declaration]
 cc1: some warnings being treated as errors
 make[2]: *** [fs/cifs/inode.o] Error 1
 make[1]: *** [fs/cifs] Error 2
 make: *** [fs] Error 2
 make: *** Waiting for unfinished jobs
  CC  security/selinux/hooks.o

 I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled.
 cifs_dbg() is not defined.
>>>
>>> Ugh, I thought I fixed that one...  I did it for the 3.4 and other
>>> trees, I'll go see what I did wrong...
>>
>> Ok, I've now fixed this, I don't know how it got through my tests, when
>> I tried it again, it failed.  Before it wasn't, odd...
>>
>> Anyway, there is a new -rc2 kernel patch at:
>>  kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc2.gz
>>
>> If you could test that out, I would appreciate it, to ensure I didn't do
>> anything stupid with this one too.
>>
>> Ick, handling 4 kernels at once really takes its toll on me, this was
>> not a good review cycle...
>>
>> thanks,
>>
>> greg k-h
>>
>
> Greg,
>
> rc2 compiled on x86-64. I will run cross-compile tests and boot tests
> later on today or tomorrow morning and report the results.
>
> -- Shuah
>
> Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
> America (Silicon Valley) shuah...@samsung.com | (970) 672-0658
>

3.9.11-rc2 boot tests passed on my test systems and cross-compile tests 
passed. No regressions in dmesgs.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research 
America (Silicon Valley) shuah...@samsung.com | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] MFD: ti_tscadc: ADC Clock check not required

[Zubair Lutfullah]

From: "Patil, Rachna" 

ADC is ideally expected to work at a frequency of 3MHz.
The present code had a check, which returned error if the frequency
went below the threshold  value. But since AM335x supports various
working frequencies, this check is not required.
Now the code just uses the internal ADC clock divider to set the ADC
frequency w.r.t the sys clock.

Signed-off-by: Patil, Rachna 
Signed-off-by: Zubair Lutfullah 
---
 drivers/mfd/ti_am335x_tscadc.c   |6 +-
 include/linux/mfd/ti_am335x_tscadc.h |1 -
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index d72001c..cd74d59 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -197,11 +197,7 @@ static int ti_tscadc_probe(struct platform_device 
*pdev)
clock_rate = clk_get_rate(clk);
clk_put(clk);
clk_value = clock_rate / ADC_CLK;
-   if (clk_value < MAX_CLK_DIV) {
-   dev_err(>dev, "clock input less than min clock 
requirement\n");
-   err = -EINVAL;
-   goto err_disable_clk;
-   }
+
/* TSCADC_CLKDIV needs to be configured to the value minus 1 */
clk_value = clk_value - 1;
tscadc_writel(tscadc, REG_CLKDIV, clk_value);
diff --git a/include/linux/mfd/ti_am335x_tscadc.h 
b/include/linux/mfd/ti_am335x_tscadc.h
index db1791b..25f2c61 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -121,7 +121,6 @@
 #define SEQ_STATUS BIT(5)
 
 #define ADC_CLK300
-#defineMAX_CLK_DIV 7
 #define TOTAL_STEPS16
 #define TOTAL_CHANNELS 8
 
-- 
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/