On Thu, Jul 11, 2013 at 02:42:54PM -0700, Linus Torvalds wrote:
> On Wed, Jul 3, 2013 at 5:29 AM, Al Viro wrote:
> > Assorted f_pos race fixes, making do_splice_direct() safe to
> > call with i_mutex on parent, O_TMPFILE support, Jeff's locks.c series,
> > ->d_hash/->d_compare calling
(2013/07/12 5:26), Jiri Kosina wrote:
> Make jump labels use text_poke_bp() for text patching instead of
> text_poke_smp(), avoiding the need for stop_machine().
>
> Signed-off-by: Jiri Kosina
> ---
> Changes:
>
> - unchanged since v1, patch 1/2 is the one being updated
>
>
Eric Van Hensbergen writes:
> The following changes since commit 2315cb14010c4cb0eb7c1d19fcf90475e4688207:
>
> 9p: Add rest of 9p files to MAINTAINERS entry (2013-05-28 13:47:58 -0500)
>
> are available in the git repository at:
>
>
>
On 07/10/2013 12:48 AM, Scott Wood wrote:
On 07/05/2013 01:27:05 AM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this
patch add
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
On Friday 12 July 2013 05:30 AM, Jingoo Han wrote:
> On Thursday, July 11, 2013 5:55 PM, Kishon Vijay Abraham I wrote:
>> On Thursday 11 July 2013 11:19 AM, Jingoo Han wrote:
>>> Exynos PCIe IP consists of Synopsys specific part and Exynos
>>> specific part. Only core block is a Synopsys
On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
> >
> > I'm sitting on top of over 170 more patches that have been marked for
> > the stable releases right now that are not included in this set of
> >
On 07/09/2013 05:25:53 AM, David Howells wrote:
Geert Uytterhoeven wrote:
> The #include added to include/uapi/linux/netlink.h
causes
> the uClibc build to go:
>
> In file included from include/linux/kernel.h:4,
> from include/linux/netlink.h:4,
> from
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
Acked-by: Nishanth Menon
---
cc to linux-pm with Nishanth Menon's ACK
---
drivers/power/avs/smartreflex.c | 4 +---
1 file changed, 1
Add pfuze100 regulator driver.
Signed-off-by: Robin Gong
---
.../devicetree/bindings/regulator/pfuze100.txt | 113 +
drivers/regulator/Kconfig |7 +
drivers/regulator/Makefile |1 +
drivers/regulator/pfuze100-regulator.c
On Fri, Jul 12, 2013 at 3:34 AM, Sylwester Nawrocki
wrote:
> On 07/11/2013 07:09 PM, Prabhakar Lad wrote:
> [...]
>
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
new file mode 100644
index
I'm attempting to jump into the thread from here:
http://markmail.org/message/zqbhcuc2gnxji3s7
I'm experiencing the same issue as described in the thread. I'm
currently running kernel 3.9.6, but have had the issue for some time.
I attempted to go through the debugging requested by Takashi Iwai
Geert Uytterhoeven writes:
> If NO_DMA=y:
>
> drivers/built-in.o: In function `ath10k_skb_unmap':
> drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to
> `dma_unmap_single'
> drivers/built-in.o: In function `ath10k_skb_map':
> drivers/net/wireless/ath/ath10k/core.h:83: undefined
Add pfuze100 regulator driver.
Signed-off-by: Robin Gong
---
.../devicetree/bindings/regulator/pfuze100.txt | 113 +
drivers/regulator/Kconfig |7 +
drivers/regulator/Makefile |1 +
drivers/regulator/pfuze100-regulator.c
Hi Sylwester,
On Fri, Jul 12, 2013 at 2:45 AM, Sylwester Nawrocki
wrote:
> On 07/11/2013 01:41 PM, Prabhakar Lad wrote:
> [...]
>
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index aa59639..1a54530 100644
---
Hi all,
Changes since 20130711:
The arm-current tree gained a conflict against Linus' tree.
The akpm tree lost some patches that turned up elsewhere and gained a
conflict against the xfs tree.
I have created today's
2013/7/9 Xiong Zhou :
> From: Xiong Zhou
>
> Add head file for reboot type stuff to fix this:
> error: ‘reboot_type’ undeclared (first use in this function)
> error: ‘BOOT_KBD’ undeclared (first use in this function)
>
> Signed-off-by: Xiong Zhou
> ---
> arch/x86/platform/ce4100/ce4100.c |1
2013/6/28 Randy Dunlap :
> On 06/18/13 18:09, Xiong Zhou wrote:
>> 2013/6/18 Randy Dunlap :
>>> On 06/18/13 06:04, Ben Hutchings wrote:
On Tue, 2013-06-18 at 17:21 +0800, Xiong Zhou wrote:
> From: Xiong Zhou
>
> Fix randconfig build failure for Amilo x86 platform driver.
>
On Fri, Jul 12, 2013 at 04:36:00AM +0100, Ben Hutchings wrote:
> On Thu, 2013-07-11 at 15:20 -0700, Greg Kroah-Hartman wrote:
> > 3.0-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Greg Kroah-Hartman
> >
> > commit
2013/7/10 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
> ---
>
On Thu, Jul 11, 2013 at 12:18 PM, Don Dutile wrote:
> On 07/11/2013 04:09 PM, Bjorn Helgaas wrote:
>>
>> On Thu, Jul 11, 2013 at 3:51 AM, Don Dutile wrote:
>>>
>>> On 07/11/2013 05:43 AM, Yijing Wang wrote:
Introduce PCIe Ext Capability Device Serial Number support,
so we can
On Thu, 2013-07-11 at 15:20 -0700, Greg Kroah-Hartman wrote:
> 3.0-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Greg Kroah-Hartman
>
> commit 7b175c46720f8e6b92801bb634c93d1016f80c62 upstream.
>
> This hopefully will help point
On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
>
> > In any case, I've been very conservative in _not_ pushing bug fixes to
> > Linus after -rc3 (unless they are fixing a regression or the bug fix
> > is
Add a new device tree enabled pinctrl driver for
Qualcomm MSM SoC's. This driver provides an extensible
framework to interface all MSM's that use a TLMM pinmux,
with the pinctrl subsytem.
This driver is split into two parts: the pinctrl interface
and the TLMM version specific implementation. The
On 2013/7/12 8:50, Theodore Ts'o wrote:
> On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
>>
>> I'm sitting on top of over 170 more patches that have been marked for
>> the stable releases right now that are not included in this set of
>> releases. The fact that there
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
fs/xfs/xfs_qm.h between commit 92f8ff73f186 ("xfs: Add pquota fields
where gquota is used") from the xfs tree and commit "xfs: convert dquot
cache lru to list_lru" from the akpm tree.
I fixed it up (see below) and can carry
From: Chun-Yi Lee
Per PKCS1 spec, the EMSA-PKCS1-v1_5 encoded message is leading by 0x00 0x01 in
its first 2 bytes. The leading zero byte is suppressed by MPI so we pass a
pointer to the _preceding_ byte to RSA_verify() in original code, but it has
risk for the byte is not zero because it's not
On 07/12/2013 10:38 AM, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 09:58 +0800, Chen Gang wrote:
>> On 07/12/2013 09:41 AM, Steven Rostedt wrote:
>>> On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
>>>
> Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
> use
On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> In any case, I've been very conservative in _not_ pushing bug fixes to
> Linus after -rc3 (unless they are fixing a regression or the bug fix
> is super-serious); I'd much rather have them cook in the ext4 tree
> where they can get
Hi, Takao
On 07/12/2013 10:39 AM, Takao Indoh wrote:
> Hi Dave,
>
> (2013/07/12 11:04), Dave Young wrote:
>> Hi, Takao
>>
>> I know you are working on the PCIE resetting patches for the iommu kdump
>> issue.
>>
>> You explicitly excluded the graphic card in your patch. I have some
>> questions
On 2013/7/12 2:18, Don Dutile wrote:
> On 07/11/2013 04:09 PM, Bjorn Helgaas wrote:
>> On Thu, Jul 11, 2013 at 3:51 AM, Don Dutile wrote:
>>> On 07/11/2013 05:43 AM, Yijing Wang wrote:
Introduce PCIe Ext Capability Device Serial Number support,
so we can use the unique device
(2013/07/12 5:26), Jiri Kosina wrote:
> Introduce a method for run-time instrucntion patching on a live SMP kernel
> based on int3 breakpoint, completely avoiding the need for stop_machine().
>
> The way this is achieved:
>
> - add a int3 trap to the address that will be patched
> -
Just saw this during boot after an unclean shutdown. It hung afterwards.
[ 97.162665] XFS: Assertion failed: xfs_dir2_sf_lookup(args) == ENOENT, file:
fs/xfs/xfs_dir2_sf.c, line: 358
[ 97.164646] [ cut here ]
[ 97.165312] kernel BUG at fs/xfs/xfs_message.c:108!
[
Hi Dave,
(2013/07/12 11:04), Dave Young wrote:
> Hi, Takao
>
> I know you are working on the PCIE resetting patches for the iommu kdump
> issue.
>
> You explicitly excluded the graphic card in your patch. I have some
> questions about this. Why can't we reset the graphic card like other
> pcie
On Fri, 2013-07-12 at 09:58 +0800, Chen Gang wrote:
> On 07/12/2013 09:41 AM, Steven Rostedt wrote:
> > On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
> >
> >> > Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
> >> > use '__init', so not waste memory keeping them
>> }
>>>
>>> + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DSN);
>>> + if (!pos)
>>> + return 0;
>>> +
>>> + pci_read_config_dword(dev, pos + 4,);
>>> + pci_read_config_dword(dev, pos + 8,);
>>> + sn = ((u64)hi<< 32) | lo;
>>
>> See comment below:
Hi Bjorn,
Thanks for your suggestions. I will try to find more information.
ZhenHua
On 07/11/2013 12:12 AM, Bjorn Helgaas wrote:
On Wed, Jul 10, 2013 at 12:23 AM, ZhenHua wrote:
Hi Bjorn,
On the system that this bug happens, an MCA event is generated while kernel
crashed:
On 2013/7/11 22:33, Paul Bolle wrote:
> On Thu, 2013-07-11 at 17:43 +0800, Yijing Wang wrote:
> [...]
>> diff --git a/drivers/pci/hotplug/pciehp_core.c
>> b/drivers/pci/hotplug/pciehp_core.c
>> index 1542735..f2eb214 100644
>> --- a/drivers/pci/hotplug/pciehp_core.c
>> +++
On 07/11/2013 07:47 PM, Bartlomiej Zolnierkiewicz wrote:
[snip]
>
> Michael's patch also works for me. Thanks to everyone involved!
> (My only nitpick for the patch is that ->queue_stop can be made bool.)
>
> Reported-and-Tested-by: Bartlomiej Zolnierkiewicz
>
> I think that it would also be
On Mon, Jul 8, 2013 at 6:25 AM, Linda Walsh wrote:
> Also am seeing this for the first time:
>
> (don't know, but seems unlikely to be related to
> https://patchwork.kernel.org/patch/87359/
> Yet it is the only hit I found for the same message.
>
>
> Looks like it's back to a more stable 3.9.8...
>> ---
>> drivers/pci/hotplug/pciehp_core.c |9 ++---
>> 1 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pci/hotplug/pciehp_core.c
>> b/drivers/pci/hotplug/pciehp_core.c
>> index 7d72c5e..1542735 100644
>> --- a/drivers/pci/hotplug/pciehp_core.c
>> +++
On Thu, 2013-07-11 at 17:33 -0700, Greg Kroah-Hartman wrote:
> On Thu, Jul 11, 2013 at 08:24:33PM -0400, Paul Gortmaker wrote:
> > On Thu, Jul 11, 2013 at 6:11 PM, Greg Kroah-Hartman
> > wrote:
> > > This is the start of the stable review cycle for the 3.4.53 release.
> > > There are 11 patches
On Thu, 2013-07-11 at 22:26 +0200, Jiri Kosina wrote:
> Make jump labels use text_poke_bp() for text patching instead of
> text_poke_smp(), avoiding the need for stop_machine().
>
> Signed-off-by: Jiri Kosina
> ---
> Changes:
>
> - unchanged since v1, patch 1/2 is the one being updated
>
>
On Thu, 11 Jul 2013 10:41:53 +0300
Gleb Natapov wrote:
> On Wed, Jul 10, 2013 at 10:49:56PM +0900, Takuya Yoshikawa wrote:
> > On Wed, 10 Jul 2013 11:24:39 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > On x86, kvm_arch_create_memslot assumes that rmap/lpage_info for the
> > > slot are zeroed
On Fri, 2013-07-12 at 00:31 +0200, Jiri Kosina wrote:
> On Thu, 11 Jul 2013, H. Peter Anvin wrote:
>
> > > synchronization after replacing "all but first" instructions should not
> > > be necessary (on Intel hardware), as the syncing after the subsequent
> > > patching of the first byte provides
On Thu, 2013-07-11 at 22:26 +0200, Jiri Kosina wrote:
Nitpick, and Joe Perches mentioned this earlier too. The below should be
in kerneldoc format. That is:
/**
* text_poke_bp() -- update instructions on live kernel on SMP
> +/*
> + * text_poke_bp() -- update instructions on live kernel on
Currently, when free_all_bootmem() calls __free_pages_memory(), the
number of contiguous pages that __free_pages_memory() passes to the
buddy allocator is limited to BITS_PER_LONG. In order to be able to
free only the first page of a 2MiB chunk, we need that to be increased
to PTRS_PER_PMD.
We have been working on this since we returned from shutdown and have
something to discuss now. We restricted ourselves to 2MiB initialization
to keep the patch set a little smaller and more clear.
First, I think I want to propose getting rid of the page flag. If I knew
of a concrete way to
As part of initializing struct page's in 2MiB chunks, we noticed that
at the end of free_all_bootmem(), there was nothing which had forced
the reserved/allocated 4KiB pages to be initialized.
This helper function will be used for that expansion.
Signed-off-by: Robin Holt
Signed-off-by: Nate
Hi, Takao
I know you are working on the PCIE resetting patches for the iommu kdump
issue.
You explicitly excluded the graphic card in your patch. I have some
questions about this. Why can't we reset the graphic card like other
pcie devices?
We have problems, if 1st kernel is in kms mode kdump
Currently, memmap_init_zone() has all the smarts for initializing a
single page. When we convert to initializing pages in a 2MiB chunk,
we will need to do this equivalent work from two separate places
so we are breaking out a helper function.
Signed-off-by: Robin Holt
Signed-off-by: Nate Zimmer
During boot of large memory machines, a significant portion of boot
is spent initializing the struct page array. The vast majority of
those pages are not referenced during boot.
Change this over to only initializing the pages when they are
actually allocated.
Besides the advantage of boot
On 07/12/2013 09:41 AM, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
>
>> > Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
>> > use '__init', so not waste memory keeping them around ?
> Yeah, they should all be set to __init, but that's
>>
> [...]
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 0fd1f15..10d190b 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -342,6 +342,7 @@ struct pci_dev {
>> struct list_head msi_list;
>> struct kset *msi_kset;
>> #endif
>> +u64 sn;
On 2013/7/11 22:19, Paul Bolle wrote:
> On Thu, 2013-07-11 at 17:43 +0800, Yijing Wang wrote:
>> v1->v2: Modify pci_get_dsn to pci_device_serial_number,
>> power off slot before remove the old device during resume to avoid
>> old .remove() method to touch new hardware.
>>
On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote:
> Maybe the pendulum has swung too far in the direction of holding back
> changes and trying to avoid the risk of introducing regressions;
> perhaps this would be a good topic to discuss at the Kernel Summit.
Bah, I sent out a similar email
On Thu, 2013-07-11 at 15:44 -0700, Greg Kroah-Hartman wrote:
> > For .10 I had to start making a list of "shit that's broken that there's
> > an outstanding patch for" and nagging people to send them week after week.
> > Every time I reported a new bug I'd hit, I'd have to explain I wasn't
> >
On 2013/7/11 18:19, Paul Bolle wrote:
> Yijing,
>
> On Thu, 2013-07-11 at 11:55 +0800, Yijing Wang wrote:
>> Can you provide the lspci -vvv and lspci - info messages ?
>> I want to confirm your hardware information which cause your resume error.
>> You can get these messages in any kernel
On Thu, Jul 11, 2013 at 12:28:48PM +0100, Andy Whitcroft wrote:
> Commit bd86298e60b8 introduced a new optimisation for callers who needed
> only the ext4 group number and not the block offset within. It hand
> calculates the group number from the block in the common case, falling
> back to the
On Fri, Jul 12, 2013 at 2:47 AM, Randy Dunlap wrote:
> On 07/10/13 21:17, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20130710:
>>
>
>
> on x86_64:
>
> # CONFIG_USB_GADGET is not set
>
> ERROR: "usb_gadget_map_request" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> ERROR:
On Thu, 11 Jul 2013, Michal Hocko wrote:
> On Thu 11-07-13 12:26:34, Dave Chinner wrote:
> > On Wed, Jul 10, 2013 at 10:06:05AM +0200, Michal Hocko wrote:
> > > On Wed 10-07-13 12:31:39, Dave Chinner wrote:
> > > [...]
> > > > > 20761 [] xlog_grant_head_wait+0xdd/0x1a0 [xfs]
> > > > > []
On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
> Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
> use '__init', so not waste memory keeping them around ?
Yeah, they should all be set to __init, but that's pretty low on the
totem poll, as distros don't enable
Hi Don,
Thanks for your review and comments very much!
>> +dev->sn = pci_device_serial_number(dev);
>> +
> Finally, 'the comment below':
> I know you were following Bjorn's suggestion, which I thought
> was an improvement, but why not do above assignment in
> pci_device_serial_number() ?
On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote:
> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
> > Drilling down the work items ahead of a real mainline push is high on
> > priority list for discussion.
> >
> > The parties to be included in such a discussion are:
> >
On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote:
> On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
> >
> > I'm sitting on top of over 170 more patches that have been marked for
> > the stable releases right now that are not included in this set of
> > releases.
Hi Alasdair,
On Thu, 11 Jul 2013 14:55:22 +0100 Alasdair G Kergon wrote:
>
> On Thu, Jul 11, 2013 at 04:20:40PM +1000, Stephen Rothwell wrote:
> > Alistair, is there some reason that you cannot maintain some relatively
> > stable git tree for me to fetch (instead of the quilt series).
>
>
Hi Mike,
On Thu, 11 Jul 2013 09:35:11 -0400 Mike Snitzer wrote:
>
> I'll be transitioning in to maintain device mapper (for 3.12). Alasdair
> will be helping me as needed but ultimately the plan is for me to be the
> one sending DM changes upstream in the future. I will maintain a
> kernel.org
On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote:
> Drilling down the work items ahead of a real mainline push is high on
> priority list for discussion.
>
> The parties to be included in such a discussion are:
>
> - Jens Axboe (blk-mq author)
> - James Bottomley (scsi
(2013/07/12 1:46), Steven Rostedt wrote:
> On Thu, 2013-07-11 at 09:31 -0700, H. Peter Anvin wrote:
>
>> The current code assumes that one of the two code sequences is a NOP,
>> and therefore that jumping over the region is legal. This does not
>> allow for transitioning one active code sequence
Unfortunately, I'm no longer to spend the time needed on maintainership.
It is time for me to step aside and pass maintainership to other
engineers. I'm not disappearing from Linux development, but it would be
irresponsible for me to hold onto a job that I am unable to do.
GPIO and SPI are in
(2013/07/11 19:51), Jiri Kosina wrote:
>>> + * - update all but the first byte of the patched range
>>> + * - sync cores
>>> + * - replalace the first byte (int3) by the first byte of
>>> + * replacing opcode
>>> + * - sync cores
>>> + *
>>> + * Note: must be called under text_mutex.
>>> + */
On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
>
> I'm sitting on top of over 170 more patches that have been marked for
> the stable releases right now that are not included in this set of
> releases. The fact that there are this many patches for stable stuff
> that
On Friday, July 12, 2013 6:46 AM, Julius Werner wrote:
>
> Hi Jingoo,
>
> Yeah, I followed that discussion back then, but it seems to have
> stalled a little (at least the HSIC patches haven't been picked up in
> any kernel.org repo yet to my knowledge).
>
> The problem is that I think these
On Fri, 12 Jul 2013 10:27:59 +1000 Stephen Rothwell
wrote:
>
> As Paul said, new material should not enter linux-next until after -rc1
> is released. In fact, every time Linus opens a merge window, I send an
> email to lkml and the linux-next list saying just that. I also often add
> that
Hi Russell,
Today's linux-next merge of the arm-current tree got a conflict in
arch/arm/mm/init.c between commit dbe67df4ba78 ("mm: enhance
free_reserved_area() to support poisoning memory with zero") from Linus'
tree and commit 319e0b4f02f7 ("ARM: mm: fix boot on SA1110 Assabet") from
the
On Thu, Jul 11, 2013 at 08:24:33PM -0400, Paul Gortmaker wrote:
> On Thu, Jul 11, 2013 at 6:11 PM, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 3.4.53 release.
> > There are 11 patches in this series, all will be posted as a response
> > to this one. If
Hi Jean,
On Thu, 11 Jul 2013 19:17:52 -0400 Paul Gortmaker
wrote:
>
> On Thu, Jul 11, 2013 at 3:39 AM, Jean Delvare wrote:
> >
> > FWIW I would have accepted the patch even if it was not trivial and it
> > would have gone in linux-next just the same. The only difference is
> > whether I
On Thu, Jul 11, 2013 at 6:11 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 3.4.53 release.
> There are 11 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.
>
>
(2013/07/11 1:47), Toshi Kani wrote:
> device->driver_data needs to be cleared when releasing its data,
> mem_device, in an error path of acpi_memory_device_add().
>
> Signed-off-by: Toshi Kani
> ---
Reviewed-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
> drivers/acpi/acpi_memhotplug.c
From: Wolfram Sang
Date: Wed, 10 Jul 2013 16:57:43 +0100
> 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
From: Wolfram Sang
Date: Wed, 10 Jul 2013 16:57:42 +0100
> 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
From: Wolfram Sang
Date: Wed, 10 Jul 2013 16:57:44 +0100
> 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
Hello,
I would like to attend the 2013 Kernel Summit.
At the summit, I would like to discuss scsi-mq, a high performance SCSI
initiator prototype that utilizes the next-generation blk-mq effort by
Jens Axboe. The long-term goal is a path to move beyond the
long-standing small block random I/O
From: Hayes Wang
Date: Mon, 8 Jul 2013 10:41:21 +0800
> Base on cdc_ether, add the mii functions for RTL8152 and RTL8153.
> The RTL8152 and RTL8153 support ECM mode which use the driver of
> cdc_ether. Add the mii functions. Then, the basic PHY access is
> possible.
>
> Signed-off-by: Hayes
From: Mika Westerberg
There is no need for a temporary variable and all the tricks with
ternary operators in acpiphp_get_(latch)|(adapter)_status(). Change
those functions to be a bit more straightforward.
[rjw: Changelog]
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Mika Westerberg
From: Mika Westerberg
Drop some unused symbols from acpiphp.h and redefine SLOT_ENABLED
(which is the only slot flag now) as 1.
[rjw: Redefinition of SLOT_ENABLED, changelog]
Signed-off-by: Mika Westerberg
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Rafael J. Wysocki
---
From: Rafael J. Wysocki
Do not acquire bridge_mutex around the addition of a slot to its
bridge's list of slots and arount the addition of a function to
its slot's list of functions, because that doesn't help anything
right now (those lists are walked without any locking anyway).
However,
From: Kirill A. Shutemov
Subject:
The current implementation of acpiphp_check_bridge() is pretty dumb:
- It enables a slot if it's not enabled and the slot status is
ACPI_STA_ALL.
- It disables a slot if it's enabled and the slot status is not
ACPI_STA_ALL.
This behavior is not
From: Rafael J. Wysocki
Notice that functions enable_device() and disable_device() cannot
fail and their return values are ignored in the majority of places,
so redefine them as void and use the opportunity to change their
names to enable_slot() and disable_slot(), respectively, which much
From: Rafael J. Wysocki
Modify handle_hotplug_event() to avoid queing up the execution of
handle_hotplug_event_work_fn() as a work item on kacpi_hotplug_wq
for non-hotplug events, such as ACPI_NOTIFY_DEVICE_WAKE. Move
the code printing diagnostic messages for those events into
From: Rafael J. Wysocki
The ACPI-based PCI hotplug (acpiphp) core code need not and really
should not execute _PS0 and _PS3 directly for devices it handles.
First of all, it is not necessary to put devices into D3 after
acpi_bus_trim() has walked through them, because
acpi_device_unregister()
From: Kirill A. Shutemov
Currently, enable_device() checks the return value of pci_scan_slot()
and returns immediately if that's 0 (meaning that no new functions
have been found in the slot). However, if one of the functions in
the slot is a bridge, some new devices may appear below it even if
From: Rafael J. Wysocki
To avoid chasing more pointers than necessary in some situations,
move the bridge pointer from struct acpiphp_slot to struct
acpiphp_func (and call it 'parent') and add a bus pointer to
struct acpiphp_slot.
Signed-off-by: Rafael J. Wysocki
---
From: Rafael J. Wysocki
The acpiphp_bus_trim() and acpiphp_bus_add() functions need not
return error codes that are never checked, so redefine them and
simplify them a bit.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 52 +
1
From: Kirill A. Shutemov
With Thunderbolt you can daisy chain devices: connect new devices to
an already plugged one. In that case the "hotplug slot" is already
enabled, but we still want to look for new PCI devices behind it.
Reuse enable_device() to scan for new PCI devices on enabled slots
From: Rafael J. Wysocki
The handle field in struct acpiphp_bridge is only used by
acpiphp_enumerate_slots(), but in that function the local handle
variable can be used instead, so make that happen and drop handle
from struct acpiphp_bridge.
Signed-off-by: Rafael J. Wysocki
---
From: Rafael J. Wysocki
Since there has to be a struct acpiphp_func object for every struct
acpiphp_context created by register_slot(), the struct acpiphp_func
one can be embedded into the struct acpiphp_context one, which allows
some code simplifications to be made.
Signed-off-by: Rafael J.
From: Rafael J. Wysocki
The only bridge flag used by the ACPI-based PCI hotplug (ACPIPHP)
code is BRIDGE_HAS_EJ0, but it is only used by the event handling
function hotplug_event() and if that flag is set, the corresponding
function flag FUNC_HAS_EJ0 is set as well, so that bridge flag is
From: Rafael J. Wysocki
The ACPI handle stored in struct acpiphp_func is also stored in the
struct acpiphp_context object containing it and it is trivial to get
from a struct acpiphp_func pointer to the handle field of the outer
struct acpiphp_context.
Hence, the handle field of struct
From: Rafael J. Wysocki
Since the func pointer in struct acpiphp_context can always be used
instead of the func pointer in struct acpiphp_bridge, drop the
latter.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp.h |2 --
drivers/pci/hotplug/acpiphp_glue.c |3 +--
From: Rafael J. Wysocki
It is not necessary to use per-bridge slot count fields just in
order to label slots for devices without _SUN, so use a common
static slot_count variable for this purpose and drop the nr_slots
field from struct acpiphp_bridge.
Signed-off-by: Rafael J. Wysocki
---
1 - 100 of 1458 matches
Mail list logo
