If failure occurs after called read_lock(), need call read_unlock() too.
It can fail in multiple position, so add new tag 'fail_lock' for it
(also can let 'if' only content one jump statement).
Signed-off-by: Chen Gang
---
kernel/exit.c |8 ++--
1 files changed, 6 insertions(+), 2
I do it all the time.
JAM/STAPL seems to me to be more used for exotic connections to serial flash
for persistent programming.
Jason Gunthorpe wrote:
>On Fri, Oct 04, 2013 at 09:00:28PM -0700, H. Peter Anvin wrote:
>
>> Every FPGA toolchain I know of has a way to emit JAM/STAPL bytecode
>>
On Fri, Oct 04, 2013 at 09:00:28PM -0700, H. Peter Anvin wrote:
> Every FPGA toolchain I know of has a way to emit JAM/STAPL bytecode
> files... and a fair number of programming scenarios need them.
Yes, but now you are talking about JTAG.
JTAG is a very different problem than configuring over
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/wan/hostess_sv11.c | 2 +-
drivers/net/wan/sealevel.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/irda/bfin_sir.c | 4 ++--
drivers/net/irda/donauboe.c | 4 ++--
drivers/net/irda/sh_irda.c | 2 +-
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/hamradio/yam.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/yam.c
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/hamradio/scc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/scc.c
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-gemini/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-gemini/time.c
Every FPGA toolchain I know of has a way to emit JAM/STAPL bytecode files...
and a fair number of programming scenarios need them.
Jason Gunthorpe wrote:
>On Fri, Oct 04, 2013 at 04:33:41PM -0700, Greg Kroah-Hartman wrote:
>
>> > I agree that the firmware interface makes sense when the use of
Michael Ellerman [mich...@ellerman.id.au] wrote:
| On Tue, Oct 01, 2013 at 05:15:07PM -0700, Sukadev Bhattiprolu wrote:
| > perf_mem_data_src is an union that is initialized via the ->val field
| > and accessed via the bitmap fields. For this to work on big endian
| > platforms, we also need a
On 10/05/2013 11:52 AM, Alexey Kardashevskiy wrote:
> On 05.10.2013 2:05, Alex Williamson wrote:
>> On Fri, 2013-10-04 at 22:24 +1000, Alexey Kardashevskiy wrote:
>>> This is a very rough change set required for ppc64 to use this KVM device.
>>>
>>> vfio_rm.c is a piece of code which is going to
On Fri, Oct 04, 2013 at 08:52:53PM -0400, Steven Rostedt wrote:
> On Fri, 4 Oct 2013 14:39:46 -0700
> Andi Kleen wrote:
>
> > From: Andi Kleen
> >
> > UPROBES need the perf events code, so add a dependency
> > from PERF_EVENTS to UPROBES.
>
> Can you please be a bit more specific on what
On Fri, Oct 04, 2013 at 08:52:10PM -0400, Dave Jones wrote:
> WARNING: CPU: 3 PID: 26128 at fs/attr.c:178 notify_change+0x34d/0x360()
> Modules linked in: dlci 8021q garp sctp snd_seq_dummy bridge stp tun fuse
> rfcomm hidp ipt_ULOG nfc caif_socket caif af_802154 phonet af_rxrpc bnep
> bluetooth
Hi Linus,
Here's a fix for v3.12. We merged what was intended to be an MMCONFIG
cleanup, but in fact, for systems without _CBA (which is almost
everything), it broke extended config space for domain 0 and it
broke all config space for other domains. This reverts the change.
Bjorn
The
Programs have been known to test for empty directories by attempting
to remove them. To keep from violating the principle of least
surprise don't let directories the caller can see with someting
mounted on them be deleted.
With a little luck this may prevent commands stupid commands
like rm -rf
On Sat, Oct 05, 2013 at 10:24:23AM +0800, Shawn Guo wrote:
> On Mon, Sep 30, 2013 at 02:04:51PM +0200, Thierry Reding wrote:
> > The IS_ERR() macro is defined in the linux/err.h header file, so include
> > it explicitly.
>
> Hmm, I can not find IS_ERR() in arch/arm/mach-imx/cpu.c
Sorry, I did
On Mon, Sep 30, 2013 at 02:04:51PM +0200, Thierry Reding wrote:
> The IS_ERR() macro is defined in the linux/err.h header file, so include
> it explicitly.
Hmm, I can not find IS_ERR() in arch/arm/mach-imx/cpu.c
Shawn
> Signed-off-by: Thierry Reding
> ---
> arch/arm/mach-imx/cpu.c | 2 +-
> 1
From: Fabio Estevam
Fix the following sparse warnings:
drivers/irqchip/irq-gic.c:651:6: warning: symbol 'gic_raise_softirq' was not
declared. Should it be static?
drivers/irqchip/irq-gic.c:831:29: warning: symbol 'gic_irq_domain_ops' was not
declared. Should it be static?
From: Fabio Estevam
Fix the following sparse warning:
kernel/irq/irqdomain.c:468:14: warning: symbol 'irq_create_of_mapping' was not
declared. Should it be static?
Signed-off-by: Fabio Estevam
---
kernel/irq/irqdomain.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Mon, 2013-09-23 at 12:14 -0600, Jason Gunthorpe wrote:
> TPM drivers should not call dev_set_drvdata (or aliases), only the core
> code is allowed to call dev_set_drvdata, and it does it during
> tpm_register_hardware.
>
> These extra sets are harmless, but are an anti-pattern that many
On 10/04/2013 10:04 AM, Olof Johansson wrote:
On Fri, Oct 4, 2013 at 6:44 AM, Guenter Roeck wrote:
On 10/03/2013 10:41 PM, Olof Johansson wrote:
On Thu, Oct 3, 2013 at 10:23 PM, Guenter Roeck wrote:
On 10/03/2013 06:02 PM, Mark Brown wrote:
Hi all,
Better late than never I've uploaded
Hello,
I need to discuss with you about George. Please contact me immediately.
Mr. Zhu
--
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
ebied...@xmission.com (Eric W. Biederman) writes:
> I just noticed that Al's latest vfs changes posted yesterday mean I need
> to rebase and possibly respin these patches, as all of the locking and
> interesting bits of the dcache have changed. I don't think the
> conflicts would be fun to
On 05.10.2013 2:05, Alex Williamson wrote:
> On Fri, 2013-10-04 at 22:24 +1000, Alexey Kardashevskiy wrote:
>> This is a very rough change set required for ppc64 to use this KVM device.
>>
>> vfio_rm.c is a piece of code which is going to be called from the realmode
>> (MMU off),
>> and I will
On Mon, 2013-09-23 at 12:14 -0600, Jason Gunthorpe wrote:
> misc_open sets the file->private_date to the misc_dev when calling
> open. We can use container_of to go from the misc_dev back to the
> tpm_chip.
>
> Future clean ups will move tpm_open into a new file and this change
> means we do not
On Fri, Oct 04, 2013 at 06:25:00PM -0700, Linus Torvalds wrote:
> Any splice user has better have a fallback to a read/write loop anyway, so
> I think the default of trying to splice was likely a bad decision.
Ummm... Point.
> That said, you're right that it's a big change. And maybe we don't
This is to inform you that,You have won a prize money of
(USD$800,000,00 United state dollars)
For the year of 2013 Lottery promotion which is
organized by MTN Who wants to be a Millionaire,
MTN only collects all the email addresses of the final winner of the
MTN on line lottery we only
On Fri, 4 Oct 2013 14:39:46 -0700
Andi Kleen wrote:
> From: Andi Kleen
>
> UPROBES need the perf events code, so add a dependency
> from PERF_EVENTS to UPROBES.
Can you please be a bit more specific on what uprobes requires of perf?
That is, what part of the perf events code is needed, and
WARNING: CPU: 3 PID: 26128 at fs/attr.c:178 notify_change+0x34d/0x360()
Modules linked in: dlci 8021q garp sctp snd_seq_dummy bridge stp tun fuse
rfcomm hidp ipt_ULOG nfc caif_socket caif af_802154 phonet af_rxrpc bnep
bluetooth rfkill can_bcm can_raw can llc2 pppoe pppox ppp_generic slhc irda
On Fri, Oct 04, 2013 at 04:27:35PM -0700, Linus Torvalds wrote:
> On Thu, Oct 3, 2013 at 11:56 AM, Al Viro wrote:
> >
> > Note, BTW, that splice to /proc//attr/ is broken.
> > proc_pid_attr_write() is *not* supposed to allow partial writes at all.
> > Frankly, I'd consider adding a
Andy Lutomirski writes:
> On Fri, Oct 4, 2013 at 3:55 PM, Eric W. Biederman
> wrote:
>> Andy Lutomirski writes:
>>
>>> On Fri, Oct 4, 2013 at 12:41 PM, Djalal Harouni wrote:
On Fri, Oct 04, 2013 at 12:32:09PM -0700, Andy Lutomirski wrote:
> On Fri, Oct 4, 2013 at 12:27 PM, Djalal
On Fri, Oct 04, 2013 at 03:02:32PM -0700, Paul E. McKenney wrote:
> On Fri, Oct 04, 2013 at 02:25:06PM -0700, Paul E. McKenney wrote:
> > On Fri, Oct 04, 2013 at 08:52:39PM +0200, Peter Zijlstra wrote:
> > > On Fri, Oct 04, 2013 at 10:09:54AM -0700, Paul E. McKenney wrote:
> > > > On Fri, Oct 04,
On Fri, Oct 4, 2013 at 4:58 PM, Andy Lutomirski wrote:
>
> How hard would it be to also add RENAME_NOREPLACE that fails if the
> destination already exists?
Trivial. And I agree that that should be a good flag to have.
Linus
--
To unsubscribe from this list: send the line
Linus Torvalds writes:
> On Fri, Oct 4, 2013 at 3:41 PM, Eric W. Biederman
> wrote:
>>
>> After thinking about it removing the restrictions on mount points
>> appears safe, because it is just plain dumb to have a mount point
>> in a directory that is not restricted to root only modifications.
On 10/01/2013 09:00 AM, Miklos Szeredi wrote:
> This series adds a new syscall, renameat2(), which is the same as renameat()
> but
> with a flags argument. Internally i_op->reaname2() is also added, which can
> later be merged with ->rename() but is kept separately for now, since this
> would
>
On Fri, Oct 4, 2013 at 3:11 PM, Bjorn Helgaas wrote:
> On Thu, Oct 3, 2013 at 7:18 PM, Hedi Berriche wrote:
> It's regrettable that the code is so subtle. The obvious thing to do
> would be to check for _CBA, and if it doesn't exist, look for an MCFG
> entry. But for various historical
On 10/04/2013 04:33 PM, Greg Kroah-Hartman wrote:
>
> Ideally I thought this would be just like "firmware", you dump the file
> to the FPGA, it validates it and away you go with a new image running in
> the chip.
>
> But, it sounds like this is much more complicated, so much so that
> configfs
On Fri, Oct 04, 2013 at 04:33:41PM -0700, Greg Kroah-Hartman wrote:
> > I agree that the firmware interface makes sense when the use of the
> > FPGA is an implementation detail in a fixed hardware configuration,
> > but that is a fairly restricted use case all things considered.
>
> Ideally I
04.10.2013 10:06, Olivier Langlois kirjoitti:
> Anssi,
>
> Your patch has been applied on 3.11.3
OK.
>>
>> I'm especially interested in testers with:
>>
>> - Older codecs other than 0x1002aa01. My best guess still is that the
>> new code works on them as well.
>> o On these I'd like to know
On Fri, Oct 04, 2013 at 11:12:13AM -0700, H. Peter Anvin wrote:
> On 10/04/2013 10:44 AM, Michal Simek wrote:
> >
> > If you look at it in general I believe that there is wide range of
> > applications which just contain one bitstream per fpga and the
> > bitstream is replaced by newer version
On Thu, Oct 3, 2013 at 11:56 AM, Al Viro wrote:
>
> Note, BTW, that splice to /proc//attr/ is broken.
> proc_pid_attr_write() is *not* supposed to allow partial writes at all.
> Frankly, I'd consider adding a ->splice_write() instance that would
> simply return -EINVAL there...
That sounds like
On Fri, 04 Oct 2013 15:14:22 -0700
Joe Perches wrote:
> Isn't LIMIT1/WINDOW1 used as ull anyway?
> It doesn't hurt to show that the value is also ull.
sure, I will make that change in the next set.
thanks,
Jacob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Fri, Oct 4, 2013 at 3:41 PM, Eric W. Biederman wrote:
>
> After thinking about it removing the restrictions on mount points
> appears safe, because it is just plain dumb to have a mount point
> in a directory that is not restricted to root only modifications.
>
> This is a change in user
On Friday 04 October 2013, Srinivas Pandruvada wrote:
>On 10/04/2013 01:22 PM, Gene Heskett wrote:
[and snipped]
>>> >> patch or patch-set in general?
>>
>> Not that my relatively untrained eyes can spot.
>>
>>> This change added powercap directory to the kernel build. Is something
>>> wrong
On Fri, Oct 4, 2013 at 3:59 PM, Andy Lutomirski wrote:
>
> I'd really like a solution where there are no read or write
> implementations in the entire kernel that check permissions. Failing
> that, just getting it for procfs would be nice. (uid_map, etc will
> probably need to be revoked on
On Fri, Oct 4, 2013 at 3:55 PM, Eric W. Biederman wrote:
> Andy Lutomirski writes:
>
>> On Fri, Oct 4, 2013 at 12:41 PM, Djalal Harouni wrote:
>>> On Fri, Oct 04, 2013 at 12:32:09PM -0700, Andy Lutomirski wrote:
On Fri, Oct 4, 2013 at 12:27 PM, Djalal Harouni wrote:
>
> So sorry
(Ron replied separately with kernel versions and usb_modeswitch versions.)
Ron, it appears that while Tumbleweed upgraded the kernel version, it
didn't upgrade the usb_modeswitch version. You probably need a newer
version to support that device. I just checked
dear friend and partner,
Greetings to you my Dear Beloved, I know contacting you Via Internet is not a
good medium as i know it has been greatly Abused but I still see it as the
easiest means of communication.
I am happy to know you, but God knows you better and he knows why he has
From: Joseph Myers
The e500 SPE floating-point emulation code for the rounding modes
rounding to positive or negative infinity (which may not be
implemented in hardware) tries to avoid emulating rounding if the
result was inexact. However, it tests inexactness using the sticky
bit with the
Andy Lutomirski writes:
> On Fri, Oct 4, 2013 at 12:41 PM, Djalal Harouni wrote:
>> On Fri, Oct 04, 2013 at 12:32:09PM -0700, Andy Lutomirski wrote:
>>> On Fri, Oct 4, 2013 at 12:27 PM, Djalal Harouni wrote:
>>> > So sorry Andy, I don't follow what you are describing.
>>>
>>> And what
Any comments on this proposed feature and implementation? Apparently
it's also useful for server systems.
Thanks,
Zoran
On 20 September 2013 15:15, Zoran Markovic wrote:
> This patch implements a generic CPU hotplug cooling device. The
> implementation scales down the number of running CPUs when
From: Joseph Myers
The e500 SPE floating-point emulation code clears existing exceptions
(__FPU_FPSCR &= ~FP_EX_MASK;) before ORing in the exceptions from the
emulated operation. However, these exception bits are the "sticky",
cumulative exception bits, and should only be cleared by the user
With the introduction of mount namespaces and bind mounts it because
possible to access files and directories that in other locations in
were used as mount points. Especially with mount namespaces has
become very confusing why rm -rf somedir return -EBUSY because some
directory is mounted
Signed-off-by: Eric W. Biederman
---
fs/mount.h |1 +
fs/namespace.c | 24
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/fs/mount.h b/fs/mount.h
index e4342b8dfab1..7a6a2bb3f290 100644
--- a/fs/mount.h
+++ b/fs/mount.h
@@ -79,6 +79,7 @@
Signed-off-by: Eric W. Biederman
---
fs/mount.h |2 ++
fs/namespace.c |5 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/fs/mount.h b/fs/mount.h
index 64a858143ff9..e4342b8dfab1 100644
--- a/fs/mount.h
+++ b/fs/mount.h
@@ -21,6 +21,7 @@ struct mnt_pcp {
struct
This patchset is an attempt to address two problems:
1) Not all modifications to the filesystems happen through the vfs and
since the vfs can not cope with a mount point being unlinked or
renamed filesystems whose modifications that do not come through the
vfs are required to lie.
2)
Hi Greg,
On 10/04/2013 03:30 PM, David Cohen wrote:
If USB_FUNCTIONFS is selected without USB_FUNCTIONFS_ETH and
USB_FUNCTIONFS_RNIS, u_ether.h won't be included and then
USB_ETHERNET_MODULE_PARAMAETERS macro won't be available causing the
following warning compilation:
> -Original Message-
> From: James Bottomley [mailto:jbottom...@parallels.com]
> Sent: Friday, October 04, 2013 3:31 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com; h...@infradead.org;
>
On Fri, Oct 04, 2013 at 09:24:15AM +0200, Boris BREZILLON wrote:
> Add watchdog specific config for kizbox board.
>
> Signed-off-by: Boris BREZILLON
Acked-by: Guenter Roeck
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Fri, Oct 04, 2013 at 09:24:14AM +0200, Boris BREZILLON wrote:
> Set default watchdog options in every SoC compatible with the sam9 watchdog.
>
> Signed-off-by: Boris BREZILLON
Acked-by: Guenter Roeck
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Fri, 2013-10-04 at 22:01 +, KY Srinivasan wrote:
>
> > -Original Message-
> > From: James Bottomley [mailto:jbottom...@parallels.com]
> > Sent: Friday, October 04, 2013 2:42 PM
> > To: KY Srinivasan
> > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> >
On Fri, Oct 04, 2013 at 09:24:12AM +0200, Boris BREZILLON wrote:
> The at91sam9 watchdog timer can only be configured once, and the current
> implementation tries to configure it in a static way:
> - 2 seconds timeout
> - wdt restart every 500ms
>
> If the timer has already been configured with
On Fri, Oct 04, 2013 at 09:24:13AM +0200, Boris BREZILLON wrote:
> Add new at91sam9 watchdog properties to the documentation.
>
> Signed-off-by: Boris BREZILLON
Acked-by: Guenter Roeck
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Fri, Oct 04, 2013 at 02:39:48PM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> As suggested by Ingo.
>
> Make HW_BREAKPOINTS a config option. HW_BREAKPOINTS depends
> on perf. This allows disabling PERF_EVENTS for systems that
> don't need it (e.g. anything not used for development)
>
>
If USB_FUNCTIONFS is selected without USB_FUNCTIONFS_ETH and
USB_FUNCTIONFS_RNIS, u_ether.h won't be included and then
USB_ETHERNET_MODULE_PARAMAETERS macro won't be available causing the
following warning compilation:
drivers/usb/gadget/g_ffs.c:81:1: warning: data definition has no type or
> -Original Message-
> From: James Bottomley [mailto:jbottom...@parallels.com]
> Sent: Friday, October 04, 2013 2:42 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com; h...@infradead.org;
>
Hello Eduardo,
I have rebased my work on the top of yours and tried out the new way of
registering the thermal zone.The new method is certainly making
things easier for me to create a new thermal zone device driver. But I
have some questions and I hope to hear back from you before I
On Fri, Oct 4, 2013 at 12:41 PM, Djalal Harouni wrote:
> On Fri, Oct 04, 2013 at 12:32:09PM -0700, Andy Lutomirski wrote:
>> On Fri, Oct 4, 2013 at 12:27 PM, Djalal Harouni wrote:
>> > On Fri, Oct 04, 2013 at 12:16:26PM -0700, Andy Lutomirski wrote:
>> >> On Fri, Oct 4, 2013 at 12:11 PM, Djalal
On Fri, 2013-10-04 at 13:12 -0700, Jacob Pan wrote:
> On Fri, 04 Oct 2013 11:07:45 -0700
> Joe Perches wrote:
>
> > On Fri, 2013-10-04 at 09:36 -0700, Srinivas Pandruvada wrote:
> > > The Intel Running Average Power Limit(RAPL) technology provides
> > > platform software with the ability to
On Thu, Oct 3, 2013 at 7:18 PM, Hedi Berriche wrote:
> Chaps,
>
> The following failure was encountered on hardware that does *not*
> implement a _CBA method which is AFAICT (and confirmed to me by BIOS
> chaps) optional.
_CBA is definitely optional.
> [1.230647] PCI: MMCONFIG for domain
On 10/04/2013 03:03 PM, David Cohen wrote:
On 10/04/2013 02:51 PM, Greg KH wrote:
On Fri, Oct 04, 2013 at 02:48:46PM -0700, David Cohen wrote:
Due to lack of "u_ether.h" header file, g_ffs.c compiles with following
warning:
It does? In what tree/branch/release is this happening?
This is
On Fri, Oct 04, 2013 at 02:25:06PM -0700, Paul E. McKenney wrote:
> On Fri, Oct 04, 2013 at 08:52:39PM +0200, Peter Zijlstra wrote:
> > On Fri, Oct 04, 2013 at 10:09:54AM -0700, Paul E. McKenney wrote:
> > > On Fri, Oct 04, 2013 at 06:50:44PM +0200, Peter Zijlstra wrote:
> > > > On Fri, Oct 04,
Am Freitag, 4. Oktober 2013, 21:17:36 schrieb Stefan Berger:
> On 10/04/2013 01:08 PM, Jason Gunthorpe wrote:
> > On Mon, Sep 30, 2013 at 05:09:51PM -0500, Joel Schopp wrote:
> >>> So far, nobody I have talked to has offered any strong opinions on
> >>> what locality should be used or how it
On 10/04/2013 02:51 PM, Greg KH wrote:
On Fri, Oct 04, 2013 at 02:48:46PM -0700, David Cohen wrote:
Due to lack of "u_ether.h" header file, g_ffs.c compiles with following
warning:
It does? In what tree/branch/release is this happening?
This is intended for Linus' 3.12-rc3. Haven't checked
On Fri, Oct 04, 2013 at 02:48:46PM -0700, David Cohen wrote:
> Due to lack of "u_ether.h" header file, g_ffs.c compiles with following
> warning:
It does? In what tree/branch/release is this happening?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Due to lack of "u_ether.h" header file, g_ffs.c compiles with following
warning:
drivers/usb/gadget/g_ffs.c:81:1: warning: data definition has no type or
storage class [enabled by default]
drivers/usb/gadget/g_ffs.c:81:1: warning: type defaults to ‘int’ in
declaration of
On Fri, 2013-10-04 at 12:38 -0700, K. Y. Srinivasan wrote:
> Rather than having a separate constant for specifying the timeout on FLUSH
> operations, use the basic I/O timeout value that is already configurable
> on a per target basis to derive the FLUSH timeout. Looking at the current
>
From: Andi Kleen
__get_ibs_caps is used by both oprofile and perf events.
This causes oprofile to be dependent on perf.
__get_ibs_caps is actually only a few lines, so we can
easily move that to the standard AMD CPU initialization
file.
It will be always compiled in this way, but it's far
From: Andi Kleen
UPROBES need the perf events code, so add a dependency
from PERF_EVENTS to UPROBES.
Cc: rost...@goodmis.org
Signed-off-by: Andi Kleen
---
kernel/trace/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index
This patchkit allows to disable perf events on x86. Requires
various changes to avoid dependencies.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
From: Andi Kleen
Add some ifdefs to support compiling without CONFIG_HW_BREAKPOINTS.
HW_BREAKPOINTS pulls in all of perf, and presumably there are
some use cases where people want to debug without perf.
The standard software breakpoints still work of course.
Cc: jason.wes...@windriver.com
From: Andi Kleen
Add ifdefs on CONFIG_HW_BREAKPOINTS to the hardware
break point code in x86 ptrace.c. This prepares
this file for being able to disable HW_BREAKPOINTS.
The only debug register that needs to be handled
without break points is DR6, so do that in a simple
separate function without
From: Andi Kleen
As suggested by Ingo.
Make HW_BREAKPOINTS a config option. HW_BREAKPOINTS depends
on perf. This allows disabling PERF_EVENTS for systems that
don't need it (e.g. anything not used for development)
Disabling PERF_EVENTS saves over 700k of kernel text (~5% of my config)
and
From: Andi Kleen
Now that oprofile doesn't need the AMD IBS perf code anymore, we can
make that code dependent on PERF_EVENTS and AMD CPU support,
instead of unconditionally compiling it in.
Cc: b...@suse.de
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/Makefile | 5 -
1 file changed,
From: Andi Kleen
The AMD_GART driver was made EXPERT/EMBEDDED a long time
ago to avoid unbootable 64bit systems with 32bit only devices.
This was before swiotlb was there, which does the job
of this fallback today. SWIOTLB is always on, so systems
should always boot.
The drawback is that every
On Fri, 2013-10-04 at 10:29 +0200, Alexander Gordeev wrote:
> On Thu, Oct 03, 2013 at 11:49:45PM +0100, Ben Hutchings wrote:
> > On Wed, 2013-10-02 at 12:48 +0200, Alexander Gordeev wrote:
> > > This update converts pci_enable_msix() and pci_enable_msi_block()
> > > interfaces to canonical kernel
On Fri, Oct 04, 2013 at 09:32:03PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 04, 2013 at 08:46:14PM +0200, Oleg Nesterov wrote:
> > Hello.
> >
> > On top of Peter's "[PATCH 0/3] Optimize the cpu hotplug locking"
> > series.
> >
> > It seems that Paul and Peter agree with 1-3, and they are
On Fri, Oct 04, 2013 at 08:52:39PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 04, 2013 at 10:09:54AM -0700, Paul E. McKenney wrote:
> > On Fri, Oct 04, 2013 at 06:50:44PM +0200, Peter Zijlstra wrote:
> > > On Fri, Oct 04, 2013 at 09:03:52AM -0700, Paul E. McKenney wrote:
> > > > The problem
On Fri, Oct 4, 2013 at 9:02 AM, David Quigley wrote:
> Why is this an LSM and not something further up in the VFS? Why not make a
> sysctl for this and place it further up in the VFS? Has it already been
> rejected from there? If so why not include it in the things covered by Yama?
> From a code
On 10/04/2013 07:49 AM, Christoph Hellwig wrote:
> The first two patches make blk-mq work fine again for me in a KVM VM,
> the others make sure that consumers don't have to care if the underlying queue
> uses blk-mq or not and remove some code at the same time.
Thanks Christoph, applied.
--
On Fri, Oct 04, 2013 at 01:49:13PM -0700, Linus Torvalds wrote:
> That would get ugly.
>
> However, I don't think we actually really need to do that. We had a
> similar situation with d_revalidate() passing inode pointers etc
> totally unnecessarily. Yes, the filesystem needs to use
While merging the drm-intel tree into -next there were conflicts in
drivers/gpu/drm/i915/intel_dp.c between 0cc4b69960 (drm/i915: Mask LPSP
to get PSR working even with Power Well in use by audio) in the drm tree
and 18b5992c37 (drm/i915: Calculate PSR register offsets from base +
gen) from the
On 10/04/2013 04:44 AM, Mark Brown wrote:
> From: Mark Brown
>
> This helps people spot if they have missed a supply from a device tree or
> equivalent data structure.
>
> Suggested-by: Stephen Warren
Oh, well I was going to ack it, but I guess there's no point since I
suggested it:-)
--
To
On 10/04/2013 01:22 PM, Gene Heskett wrote:
On Friday 04 October 2013, Srinivas Pandruvada wrote:
On 10/04/2013 12:24 PM, Gene Heskett wrote:
On Friday 04 October 2013, Srinivas Pandruvada wrote:
Added changes to Makefile and Kconfig to include in driver build.
Signed-off-by: Srinivas
On 10/03/2013 08:06 AM, Laxman Dewangan wrote:
> The device tree binding of Palmas regulator driver says as:
>
> palmas_pmis {
> compatible = "ti,palmas-pmic";
> ...
> regulators {
> ...
> }
> };
>
> In this "regulators" subnode is expected to be part of
On Fri, Oct 04, 2013 at 12:35:45PM -0700, Mike Turquette wrote:
> The best solution is to have a driver claim the clock with clk_get and
> enable it with clk_prepare_enable. I gave more detail in my reply to
> Laxman.
Yeah, definitely - though with regulators we did find that there were
some
[-cc extra folks]
On Tue, Sep 24, 2013 at 2:39 PM, Bjorn Helgaas wrote:
> On Mon, Sep 09, 2013 at 09:13:06PM +0800, Yijing Wang wrote:
>> Refactor qib_tune_pcie_caps() function, use pcie_set_mps()
>> and pcie_get_mps() to simply code. Because pci core caches
>> the "PCI-E Max Payload Size
On Mon, Sep 30, 2013 at 8:56 AM, Marciniszyn, Mike
wrote:
>>
>> Is something like the following what you had in mind? If so, I can
>> just queue it up. Otherwise, I'll wait for Yijing to post a v2 patch.
>>
>>
>> IB/qib: Use pcie_set_mps() and pcie_get_mps() to simplify code
>>
>> From: Yijing
On Fri, Oct 4, 2013 at 1:15 PM, Al Viro wrote:
>
> Just a couple of days ago you'd been complaining about filesystems exposure
> to rcuwalk details and now you propose to increase the contact surface
> by one more method? OK...\
.. anything for a really critical path.
> For one thing, that
[-cc unrelated folks, +cc Alex, Christian]
On Mon, Sep 9, 2013 at 7:13 AM, Yijing Wang wrote:
> Use pcie_get_readrq() and pcie_set_readrq() functions to simplify code.
>
> Signed-off-by: Yijing Wang
I believe the following patch is correct, and I'd be happy to merge it
via the PCI tree along
1 - 100 of 1048 matches
Mail list logo
