On 12/14/2013 06:24 PM, Greg Kroah-Hartman wrote:
> On Fri, Dec 13, 2013 at 01:42:05PM -0700, Bjorn Helgaas wrote:
>> [+cc Greg]
>>
>> On Fri, Dec 13, 2013 at 12:22 PM, Levente Kurusa wrote:
>>> Hi,
>>>
>>> This is just the beginning of patchset-set that aims to fix possible
>>> problems caused
Signed-off-by: Bjorn Andersson
---
drivers/pinctrl/pinctrl-msm.c | 76 ++---
1 file changed, 26 insertions(+), 50 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c
index 322bc0a..c1a3053 100644
---
Make the bitmaps part of the msm_pinctrl allocation instead of
separately allocating them.
Signed-off-by: Bjorn Andersson
---
drivers/pinctrl/pinctrl-msm.c | 32 +---
1 file changed, 5 insertions(+), 27 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-msm.c
Use the more specific form 8974 for the compatible to reduce the
risk of future mishaps.
Signed-off-by: Bjorn Andersson
---
...sm8x74-pinctrl.txt => qcom,msm8974-pinctrl.txt} |4 ++--
drivers/pinctrl/pinctrl-msm8x74.c |2 +-
2 files changed, 3 insertions(+), 3
Various fixes based on feedback from Stephen Boyd and kbuild test robot
Bjorn Andersson (4):
pinctrl-msm: Fix spelling misstakes and missing consts
pinctrl-msm: Tidy up error handling
pinctrl-msm: Remove separate allocation of bitmaps
pinctrl-msm: Rename compatible to be more specific
Signed-off-by: Bjorn Andersson
---
drivers/pinctrl/pinctrl-msm.c | 14 +++---
drivers/pinctrl/pinctrl-msm8x74.c |4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c
index 28b90ab..322bc0a 100644
Quoting Rashika Kheria (2013-12-13 23:46:06)
> This patch fixes the build break introduced by 3e1e4a5f. The mentioned
> commit id makes the changes in file "include/linux/mfd/samsung/core.h"
> by changing the members of structure sec_pmic_dev.
>
> The patch replaces "regmap" with "regmap_pmic"
Клиентскиe базы Email:tsemnolutskytsemnol...@gmail.com skype: rwer.wqerq ICQ:
446444644 Собeрeм для Вac koнтakты тoльko Baших потенциальныx клиентов
нecкoльko дecятkoв тысяч мeнee чeм за сутkи
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Block a bunch of threads on a futex and requeue them on another, N at a time.
This program is particularly useful to measure the latency of nthread requeues
without waking up any tasks -- thus mimicking a regular futex_wait.
An example run:
$ perf bench futex requeue -r 100 -t 64
Run summary
This patchset adds three programs that stress and measure different futex
operations: (i) uaddr hashing, (ii) wakeups and (iii) requeuing/waiting.
More details and usage examples in each individual patch, along with parameter
descriptions in the code.
While the previous effort
Block a bunch of threads on a futex and wake them up, N at a time.
This program is particularly useful to measure the latency of nthread wakeups
in non-error situations: all waiters are queued and all wake calls wakeup
one or more tasks. An example run:
$ perf bench futex -t 512 -r 100
Run
Introduce futexes to perf-bench and add a program that stresses
and measures the kernel's implementation of the hash table.
This is a multi-threaded program that simply measures the amount
of failed futex wait calls - we only want to deal with the hashing
overhead, so a negative return of
On Sat, Dec 14, 2013 at 12:33 AM, Jonas Jensen wrote:
> Add a generic (dtsi) include file for MOXA ART SoCs.
>
> Also add a file for UC-7112-LX.
>
> Signed-off-by: Jonas Jensen
> ---
> Documentation/devicetree/bindings/arm/moxart.txt | 12 +++
> arch/arm/boot/dts/Makefile
1) Revert CHECKSUM_COMPLETE optimization in pskb_trim_rcsum(), I can't figure
out why it breaks things.
2) Fix comparison in netfilter ipset's hash_netnet4_data_equal(), it was
basically doing "x == x", from Dave Jones.
3) Freescale FEC driver was DMA mapping the wrong number of bytes,
On Thu, Dec 12, 2013 at 11:56 AM, Andreas Noever
wrote:
> On Thu, Dec 12, 2013 at 1:21 AM, Yinghai Lu wrote:
>> On Wed, Dec 11, 2013 at 3:37 PM, Andreas Noever
>> wrote:
>>
>>> If I could get Linux to assign enough resources (bus numbers for now)
>>> then I could drop the acpi_osi parameter and
Hi Linus,
The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
for you to fetch changes up to
On Sun, Dec 15, 2013 at 1:23 AM, Tom Gundersen wrote:
>> Also, did you consider the opposite, that is making hwdb call libpci
>> to resolve PCI IDs? What are the downsides?
>
> Well, part of the reason for introducing the hwdb was to avoid libpci for
> performance reasons (I added Kay in cc who
From: Josh Triplett
Date: Sat, 14 Dec 2013 19:41:49 -0800
> On Sat, Dec 14, 2013 at 10:26:58PM -0500, David Miller wrote:
>> From: Rashika Kheria
>> Date: Sat, 14 Dec 2013 17:55:42 +0530
>>
>> > This patch declares the prototype for the function sbni_probe() in file
>> > sbni.c.
>> >
>> >
XBEGIN, XEND, XABORT, XTEST to enable kernel to explore the value of
Restricted Transactional Memory that can be found on your haswell laptop and
following up offerings see Chapter 12.3.3 Using HLE or RTM for lock Elision
of 64-ia-32-architectures-optimization-manual.pdf July 2013
Tested-by:
On Sat, Dec 14, 2013 at 10:26:58PM -0500, David Miller wrote:
> From: Rashika Kheria
> Date: Sat, 14 Dec 2013 17:55:42 +0530
>
> > This patch declares the prototype for the function sbni_probe() in file
> > sbni.c.
> >
> > Thus, it also removes the following warning in wan/sbni.c:
> >
From: Daniel Tang
Signed-off-by: Daniel Tang
---
.../devicetree/bindings/usb/ci-hdrc-zevio.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt
diff --git
From: Daniel Tang
Signed-off-by: Daniel Tang
---
arch/arm/boot/dts/nspire.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
index a22ffe6..012c6d1 100644
--- a/arch/arm/boot/dts/nspire.dtsi
+++
From: Daniel Tang
The USB controller in TI-NSPIRE calculators (LSI Zevio SoC) are based off either
Freescale's USB OTG controller or the USB controller found in the IMX233, both
of which are Chipidea compatible.
This patch adds a device tree binding for the controller.
Signed-off-by: Daniel
From: Christian Kujau
Date: Sat, 14 Dec 2013 16:40:39 -0800 (PST)
> And sure enough, today's 3.13-rc3 with only that commit reverted boots
> just fine on this PowerBook G4 system.
It's reverted in my 'net' tree, that tree simple hasn't been pushed to
Linus just yet, please be patient.
--
To
From: Mark Salter
Date: Sat, 14 Dec 2013 11:59:33 -0500
> Architectures which might use an i8042 for serial IO to keyboard,
> mouse, etc should select ARCH_MIGHT_HAVE_PC_SERIO.
>
> Signed-off-by: Mark Salter
Acked-by: David S. Miller
--
To unsubscribe from this list: send the line
From: Rashika Kheria
Date: Sat, 14 Dec 2013 17:55:42 +0530
> This patch declares the prototype for the function sbni_probe() in file
> sbni.c.
>
> Thus, it also removes the following warning in wan/sbni.c:
> drivers/net/wan/sbni.c:224:12: warning: no previous prototype for
> ‘sbni_probe’
On Sunday 15 December 2013, Sergei Ianovich wrote:
> On Sun, 2013-12-15 at 01:53 +0100, Arnd Bergmann wrote:
> > On Saturday 14 December 2013, Sergei Ianovich wrote:
> > Unfortunately I don't have a good way to judge the tradeoffs without
> > understanding more about the design of the hardware.
Tomasz,
Thanks for reviewing. I'll fix the patch description and style problems.
Regards,
Alex
On Sun, Dec 15, 2013 at 2:57 AM, Tomasz Figa wrote:
> Hi Alex,
>
> On Friday 15 of November 2013 21:09:29 Alex Ling wrote:
>> Add a minimal board dts file for EXYNOS4412 based FriendlyARM's
>>
On Sat, Dec 14, 2013 at 04:55:59PM -0500, George Spelvin wrote:
>
> What's critical for the input hash is that seed additions don't cancel
> each other. That is, XORing in some new seed material doesn't hit
> the same bits as older seed material. What's key is not exactly that
> additions
On Sun, 2013-12-15 at 01:53 +0100, Arnd Bergmann wrote:
> On Saturday 14 December 2013, Sergei Ianovich wrote:
> > There are basically 2 options: one-for-all mfd device and one-for-one
> > device drivers.
> >
> > MFD
> > pros:
> > * easy to add into the tree (one file)
> > * easy config (one
On Sun, 2013-12-15 at 01:19 +0100, Michal Malý wrote:
> diff --git a/drivers/input/ff-memless-next.c b/drivers/input/ff-memless-next.c
[]
> +static inline s32 mlnx_clamp_level(const s32 level)
> +{
> + return (level > 0x7fff) ? 0x7fff : ((level < -0x7fff) ? -0x7fff :
> level);
This brings the logic that determines "min" and "reserved" next to
the closely related logic that uses it, in account(), and reduces
the number of different points involved in communicating "min" and
"reserved" from one place to the other.
This will be particularly helpful in the next commit,
We've used random_read_wakeup_bits for two quite different purposes
that may be best with different values. The minimum number of bits
to wake up a blocked /dev/random reader has long been 64 by
default, and users may want to keep it there. The minimum number
of bits in a seed for /dev/urandom
In the earlier commit "random: direct all routine input via input pool",
we made sure that input comes in large reseeds which should be big
enough to prevent an attacker from brute-forcing any one of them.
This is important because a succession of small reseeds, if
interspersed with output an
A 128-bit seed provides reasonable security. We don't consider
ourselves initialized until we get a seed which we estimate has
entropy min_reseed_bits, by default 128. Our entropy estimates
are generally conservative (see e.g. the empirical analysis in
http://eprint.iacr.org/2012/251.pdf), but
Until then, we need all the entropy we can get. The "min_bytes"
logic takes care of making these reseeds catastrophic, and
reserving entropy for /dev/random isn't a priority in early boot.
Signed-off-by: Greg Price
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Early in boot, we really want to make sure the nonblocking pool (for
/dev/urandom and the kernel's own use) gets an adequate amount of
entropy ASAP. Anyone reading /dev/random is prepared to wait
potentially a long time anyway, so delaying them a little bit more at
boot until /dev/urandom is
The account() function serves two purposes: it decides how many
bytes of data we allow ourselves to extract from a pool (and as a
corollary how much to debit that pool's entropy estimate), and
when the extraction is for the purpose of transferring to another
pool it also decides how many bits of
Early in boot, we want to get /dev/urandom (and the kernel's
internal randomness source) adequately seeded ASAP. If we're
desperately short of entropy and are asked to produce output,
we're better off getting, say, 16 bits now and 32 bits next time
rather than holding out for a whole 64-bit
While booting, our priority is to get the nonblocking pool (which
supplies /dev/urandom and the kernel's internal randomness
consumption) initialized soon. If someone reads from /dev/random,
let them wait until we've either done that, or have enough entropy
to serve them and also do that.
This
We're using and updating the entropy_total field for different
purposes on input_pool and nonblocking_pool, only one of which
matches the name. This makes it hard to understand what the field
means.
Separate the computation on input_pool, which is of entropy since
the last auto-push, from the
This lets us control when the nonblocking pool is reseeded from
input, even early in boot. Our normal reseed mechanisms then
ensure that the input is used in "catastrophic reseeds",
high-entropy blobs added all at once with no possibility of output
between one part of the input and another. If
When extracting from the input pool to feed one of the output
pools, extracting more bytes can't hurt the reseed, and it can
help if there happens to be more entropy than we estimated. We
deliberately try to be conservative in our estimates -- for
example, mixing in the cycle counter on each
Negative numbers and size_t don't mix. When the total entropy
available was less than 'reserved', we would fail to enforce any limit
at all. Fix that. We never care how negative have_bytes - reserved
is, so just flatten it to zero if negative.
This behavior entered in 987cd8c30 "random:
This overflow is harmless except to think about, but it's best
to fix it. If userspace does a giant read from /dev/urandom,
bigger than INT_MAX, then that size gets passed straight
through extract_entropy_user and xfer_secondary_pool to
_xfer_secondary_pool as nbytes, and we would store it into
Hi Ted, hi all,
This series reworks the way we handle reseeding the nonblocking pool,
which supplies /dev/urandom and the kernel's internal randomness
needs. The most important change is to make sure that the input
entropy always comes in large chunks, what we've called a
"catastrophic reseed",
> My basic problem is
>
> __tda18271_write_regs: [1-0060|M] ERROR: idx = 0x0, len = 39, i2c_transfer
> returned: -32
>
> where it attaches lgdt3305 before tda18271. Do you know a similar patch
> that could help me?
It's a totally different issue. The problem with the US Exeter has to
do with
On Saturday 14 December 2013, Sergei Ianovich wrote:
> On Sat, 2013-12-14 at 22:03 +0100, Arnd Bergmann wrote:
> > On Friday 13 December 2013, Sergei Ianovich wrote:
> > > I've also decided not to create a single mfd device for
> > > machine-specific devices. Instead each type is supported by a
On Fri, 13 Dec 2013, Henrique de Moraes Holschuh wrote:
> 2. This change has unintended side-effects that ought to be at least
> documented:
>
> In "allow downgrade" mode, should you send a microcode pack with several
> microcodes to the kernel, and more than one of them might apply to the
>
Hi,
"ff-memless-next" driver is an extended modification of the original ff-memless
driver. Unlike ff-memless, ff-memless-next targets only "serious" FFB devices
such as racing wheels and hi(ish)-end joysticks with FFB actuators instead of
simple rumble motors. Modifications in ff-memless-next
Hi,
"ff-memless-next" driver is an extended modification of the original ff-memless
driver. Unlike ff-memless, ff-memless-next targets only "serious" FFB devices
such as racing wheels and hi(ish)-end joysticks with FFB actuators instead of
simple rumble motors. Modifications in ff-memless-next
On Saturday 14 December 2013, Guenter Roeck wrote:
> Hmm ... not sure I agree. I don't see a problem with something like
> "arm,moxart-reboot".
> There are already vexpress-reboot and xgene-reboot properties which do pretty
> much
> the same.
>
> Actually, you don't even need that; the reset
On 13/12/13 06:06, Theodore Ts'o wrote:
> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
>> From: Vegard Nossum
>>
>> The idea is simple -- since different kernel versions are vulnerable to
>> different root exploits, hackers most likely try multiple exploits before
>>
Quoting Alex Elder (2013-12-04 07:33:35)
> + return true;
> +}
> +
> +/* A bit position must be less than the number of bits in a 32-bit
> register. */
Hi Alex,
The patch is corrupt at line 634 and several other places below. Did
you edit it manually? I'm happy with the series after
[ usual CCs added ]
On Sun, 15 Dec 2013, Kharlamov Alexey wrote:
> New USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A070 constant was added to existing
> workaround module, so RITMIX ROM-316 mouse can now work.
>
> Signed-off-by: Alexey Kharlamov
>
> ---
>
> Tested and patched on linux-3.13-rc3
Hi
On Saturday 14 December 2013, Sergei Ianovich wrote:
> On Sat, 2013-12-14 at 20:06 +0100, Arnd Bergmann wrote:
> > On Friday 13 December 2013, Sergei Ianovich wrote:
> > > Non-dts implementation supply required DMA channel numbers as
> > > IORESOURCE_DMA. However, there is was no way to get them
On 14/12/13 03:24 AM, Mauro Carvalho Chehab wrote:
> Em Fri, 13 Dec 2013 22:19:39 +0100
> Frederik Himpe escreveu:
>
>> [My excuses for multiposting, it seems gmane does not permit posting to all
>> the relevant lists]
>>
>> Since upgrading my system from Linux 3.12 to 3.12.3, my PCTV Systems
>>
On Sat, Dec 14, 2013 at 02:21:36PM -0800, Colin Cross wrote:
> On Sat, Dec 14, 2013 at 1:44 PM, Greg KH wrote:
> > On Sat, Dec 14, 2013 at 01:10:38PM -0800, Colin Cross wrote:
> >> On Sat, Dec 14, 2013 at 8:52 AM, Greg KH
> >> wrote:
> >> > On Fri, Dec 13, 2013 at 02:23:35PM -0800, John Stultz
On Sat, Dec 14, 2013 at 2:19 PM, John Stultz wrote:
> On 12/14/2013 01:48 PM, Greg KH wrote:
>> On Sat, Dec 14, 2013 at 12:06:45PM -0800, John Stultz wrote:
>>> ION doesn't export the proper symbols for it to be a module. This
>>> causes build issues when ION is configured as a module.
>>>
>>>
On Sat, 2013-12-14 at 21:59 +0100, Arnd Bergmann wrote:
> Have you checked that the nsleep definition actually does the
> right thing here? 450 nanoseconds must be close the latency
> you get from calling schedule_hrtimeout(). I'd suggest using
> either ndelay() or usleep_range() instead,
> -Original Message-
> From: Josh Triplett [mailto:j...@joshtriplett.org]
> Sent: Saturday, December 14, 2013 12:57 PM
> To: Rashika Kheria
> Cc: linux-kernel@vger.kernel.org; KY Srinivasan; Haiyang Zhang;
> de...@linuxdriverproject.org
> Subject: Re: [PATCH] drivers: hv: Mark the
On Sat, Dec 14, 2013 at 1:44 PM, Greg KH wrote:
> On Sat, Dec 14, 2013 at 01:10:38PM -0800, Colin Cross wrote:
>> On Sat, Dec 14, 2013 at 8:52 AM, Greg KH wrote:
>> > On Fri, Dec 13, 2013 at 02:23:35PM -0800, John Stultz wrote:
>> >> + idev->debug_root = debugfs_create_dir("ion", NULL);
>>
On 12/14/2013 01:48 PM, Greg KH wrote:
> On Sat, Dec 14, 2013 at 12:06:45PM -0800, John Stultz wrote:
>> ION doesn't export the proper symbols for it to be a module. This
>> causes build issues when ION is configured as a module.
>>
>> Since Andorid kernels rarely use modules (I think recent
On Sat, Dec 14, 2013 at 11:01 PM, Greg KH wrote:
> On Thu, Dec 12, 2013 at 12:37:50AM +0100, Andreas Noever wrote:
>>
>> If I could get Linux to assign enough resources (bus numbers for now)
>> then I could drop the acpi_osi parameter and make thunderbolt work
>> after suspend... So, is there an
On Thu, Dec 12, 2013 at 12:37:50AM +0100, Andreas Noever wrote:
>
> If I could get Linux to assign enough resources (bus numbers for now)
> then I could drop the acpi_osi parameter and make thunderbolt work
> after suspend... So, is there an easy way to fix this? (Quirks,
> reconfiguring bus
> The mixing function doesn't have to be a good quality PRNG, since
> that's not its function. One of the things that is highly desirable,
> though, is that it "smears" recently mixed in data across the entire
> pool as quickly as possible. The above algorithm is more efficient
> because it only
On Sat, 2013-12-14 at 22:03 +0100, Arnd Bergmann wrote:
> On Friday 13 December 2013, Sergei Ianovich wrote:
> > I've also decided not to create a single mfd device for
> > machine-specific devices. Instead each type is supported by a separate
> > driver in respective subsystem. It was tempting to
On Sat, Dec 14, 2013 at 12:06:45PM -0800, John Stultz wrote:
> ION doesn't export the proper symbols for it to be a module. This
> causes build issues when ION is configured as a module.
>
> Since Andorid kernels rarely use modules (I think recent policy
> requires no modules?), go ahead and set
On Sat, Dec 14, 2013 at 01:10:38PM -0800, Colin Cross wrote:
> On Sat, Dec 14, 2013 at 8:52 AM, Greg KH wrote:
> > On Fri, Dec 13, 2013 at 02:23:35PM -0800, John Stultz wrote:
> >> + idev->debug_root = debugfs_create_dir("ion", NULL);
> >> + if (IS_ERR_OR_NULL(idev->debug_root))
> >> +
On Sat, Dec 14, 2013 at 12:56:57PM -0800, Josh Triplett wrote:
> On Sat, Dec 14, 2013 at 05:15:34PM +0300, Dan Carpenter wrote:
> > On Sat, Dec 14, 2013 at 06:56:10PM +0530, Rashika Kheria wrote:
> > > This patch marks the function of_reset_simple_xlate() and
> > > devm_reset_control_put() as
On Sat, Dec 14, 2013 at 07:40:21PM +0530, Rashika Kheria wrote:
> This patch marks the function ahci_port_intr() and
> ahci_hw_port_interrupt() as static in libahci.c because they are not
> used outside this file.
>
> Thus, it also eliminates the following warnings in libahci.c:
>
Hi.
On 15/12/13 07:36, Tejun Heo wrote:
On Sat, Dec 14, 2013 at 03:31:21PM -0500, Tejun Heo wrote:
So, all this is about hibernation? Does that mean that it's safe to
unfreeze before invoking resume? ie. we currently do,
freeze
suspend devs
resume devs
On Sat, Dec 14, 2013 at 8:52 AM, Greg KH wrote:
> On Fri, Dec 13, 2013 at 02:23:35PM -0800, John Stultz wrote:
>> + idev->debug_root = debugfs_create_dir("ion", NULL);
>> + if (IS_ERR_OR_NULL(idev->debug_root))
>> + pr_err("ion: failed to create debug files.\n");
>
> There's
On Friday 13 December 2013, Sergei Ianovich wrote:
> Fixed most review requirements. Details in respective patches.
>
> I've completely met the requirement for using dmaengine-based DMA
> in patch v2-03/16. Tests showed new DMA was underperforming. It added
> on top of a pre-existing problem with
On Sat, Dec 14, 2013 at 06:46:31PM +0530, Rashika Kheria wrote:
> This patch marks the function sdhci_disable_irq_wakeups() as static in
> host/sdhci.c because it is not used outside this file.
>
> Thus, it also eliminates the following warning in host/sdhci.c:
> drivers/mmc/host/sdhci.c:2553:6:
On Friday 13 December 2013, Sergei Ianovich wrote:
> +void nsleep(unsigned long nanosec)
> +{
> + ktime_t t = ns_to_ktime(nanosec);
> + long state = current->state;
> +
> + __set_current_state(TASK_UNINTERRUPTIBLE);
> + schedule_hrtimeout(, HRTIMER_MODE_REL);
> +
On Sat, Dec 14, 2013 at 06:50:56PM +0530, Rashika Kheria wrote:
> This patch marks the function pnp_build_option() as static in resource.c
> because it is not used outside this file.
>
> Thus, it also eliminates the following warning in resource.c:
> drivers/pnp/resource.c:34:20: warning: no
On Sat, Dec 14, 2013 at 07:14:36PM +0530, Rashika Kheria wrote:
> This patch marks the function dca_common_get_tag() as static in
> dca-core.c because it is not used outside this file.
>
> Thus, it also eliminates the following warning in dca-core.c:
> drivers/dca/dca-core.c:273:4: warning: no
On Sat, Dec 14, 2013 at 07:08:22PM +0530, Rashika Kheria wrote:
> This patch includes appropriate header file cyttsp4_core.h in
> touchscreen/cyttsp_i2c_common.c because functions
> cyttsp_i2c_read_block_data() and cyttsp_i2c_write_block_data()
> have their prototype declaration in cyttsp4_core.h.
On Sat, Dec 14, 2013 at 07:00:06PM +0530, Rashika Kheria wrote:
> This patch marks the function hv_synic_free_cpu() as static in hv.c
> because it is not used outside this file.
>
> Thus, it also eliminates the following warning in hv.c:
> drivers/hv/hv.c:304:6: warning: no previous prototype for
On Sat, Dec 14, 2013 at 05:15:34PM +0300, Dan Carpenter wrote:
> On Sat, Dec 14, 2013 at 06:56:10PM +0530, Rashika Kheria wrote:
> > This patch marks the function of_reset_simple_xlate() and
> > devm_reset_control_put() as static in core.c because it is not used
> > outside this file.
> >
> >
In all three cases, new_inode_pseudo(), iget_locked() and iget5_locked(),
we own the new inode exclusively at this point and therefore taking
->i_lock to protect ->i_state/->i_hash against concurrent access is superfluous.
Signed-off-by: Richard Weinberger
---
fs/inode.c | 6 --
1 file
On Sat, Dec 14, 2013 at 07:21:48PM +0530, Rashika Kheria wrote:
> This patch includes appropriate header file compat_ioctl.h in
> agp/frontend.c because functions agp_find_mem_by_key(),
> agp_create_segment(), agp_find_private(), agp_free_memory_wrap(),
> agp_allocate_memory_wrap(),
Done: https://bugzilla.kernel.org/show_bug.cgi?id=67001
On Fri, Dec 13, 2013 at 6:09 PM, Bjorn Helgaas wrote:
> On Thu, Dec 12, 2013 at 12:56 PM, Andreas Noever
> wrote:
>> On Thu, Dec 12, 2013 at 1:21 AM, Yinghai Lu wrote:
>>> On Wed, Dec 11, 2013 at 3:37 PM, Andreas Noever
>>> wrote:
>>>
On Sat, Dec 14, 2013 at 07:40:21PM +0530, Rashika Kheria wrote:
> This patch marks the function ahci_port_intr() and
> ahci_hw_port_interrupt() as static in libahci.c because they are not
> used outside this file.
>
> Thus, it also eliminates the following warnings in libahci.c:
>
On Sat, Dec 14, 2013 at 07:38:08PM +0530, Rashika Kheria wrote:
> This patch marks the function ahci_init_interrupts() as static in ahci.c
> because it is not used outside this file.
>
> Thus, it also eliminates the following warning in ahci.c:
> drivers/ata/ahci.c:1099:5: warning: no previous
On Sat, Dec 14, 2013 at 06:37:18PM +0530, Rashika Kheria wrote:
> This patch marks the function memstick_debug_get_tpc_name() as static in
> host/r592.c because it is not used outside this file.
>
> Thus, it also eliminates the following warning in host/r592.c:
>
On Sat, Dec 14, 2013 at 06:29:29PM +0530, Rashika Kheria wrote:
> This patch marks the function btree_insert_fn() as static in
> bcache/btree.c because it is not used outside this file.
>
> Thus, it also eliminates the following warning in bcache/btree.c:
> drivers/md/bcache/btree.c:2220:5:
On Sat, Dec 14, 2013 at 11:47:10PM +0530, Rashika Kheria wrote:
> My gcc version is 4.6.3. You can trigger these warnings by adding
> -Wmissing-prototypes to KBUILD_CFLAGS in the top-level Makefile, and
Actually, you don't even have to do that - you only need to build with
W=1:
make W=1
On Sat, Dec 14, 2013 at 03:31:21PM -0500, Tejun Heo wrote:
> So, all this is about hibernation? Does that mean that it's safe to
> unfreeze before invoking resume? ie. we currently do,
>
> freeze
> suspend devs
> resume devs
> unfreeze
>
> If we can just do,
>
>
On Sat, Dec 14, 2013 at 06:23:10PM +0530, Rashika Kheria wrote:
> This patch removes the function rio_remove_sysfs_dev_files() in
> rio-sysfs.c because it is unused.
>
> Thus, it also eliminates the following warning in rio-sysfs.c:
> drivers/rapidio/rio-sysfs.c:295:6: warning: no previous
On Sat, Dec 14, 2013 at 06:20:29PM +0530, Rashika Kheria wrote:
> This patch includes the header file linux/rio_drv.h in rio-driver.c
> because functions rio_dev_get(), rio_dev_put(), rio_register_driver()
> and rio_unregister_driver() have their prototype declarations in
> linux/rio_drv.h.
>
>
On Sat, Dec 14, 2013 at 06:16:28PM +0530, Rashika Kheria wrote:
> This patch includes appropriate header file linux/rio_drv.h in
> rio-access.c because functions __rio_local_read_config_8,
> __rio_local_read_config_16, __rio_local_read_config_32,
> __rio_local_write_config_8,
On Sat, Dec 14, 2013 at 05:55:42PM +0530, Rashika Kheria wrote:
> This patch declares the prototype for the function sbni_probe() in file
> sbni.c.
>
> Thus, it also removes the following warning in wan/sbni.c:
> drivers/net/wan/sbni.c:224:12: warning: no previous prototype for
> ‘sbni_probe’
Hello, Nigel.
On Sat, Dec 14, 2013 at 10:15:21AM +1100, Nigel Cunningham wrote:
> My understanding is that the point is ensuring that - particularly
> in the case of hibernation - we don't cause filesystem corruption by
> writing one thing while writing the image and then doing something
> else
On Sat, Dec 14, 2013 at 07:32:09PM +0530, Rashika Kheria wrote:
> This patch marks the function get_mci_for_node_id() as static in
> sb_edac.c because it is not used outside this file.
>
> Thus, it also eliminates the following warning in sb_edac.c:
> drivers/edac/sb_edac.c:918:22: warning: no
On Sat, Dec 14, 2013 at 07:30:11PM +0530, Rashika Kheria wrote:
> This patch marks the function edac_create_debug_nodes() as static in
> edac_mc_sysfs.c because it is not used outside this file.
>
> Thus, it also eliminates the following warning in edac_mc_sysfs.c:
>
On Sat, Dec 14, 2013 at 07:28:24PM +0530, Rashika Kheria wrote:
> This patch marks the function amd64_decode_bus_error() as static in
> amd64_edac.c because it is not used outside this file.
>
> Thus, it also eliminates the following warning in amd64_edac.c:
> drivers/edac/amd64_edac.c:2038:6:
OK, here's an updated version that reuses evsel and hopefully doesn't leak
memory like the previous patch I posted.
"perf list" listing of hardware events doesn't work on older ARM devices.
The change enabling event detection:
commit b41f1cec91c37eeea6fdb15effbfa24ea0a5536b
Author: Namhyung
On Sat, Dec 14, 2013 at 06:42:14PM +0530, Rashika Kheria wrote:
> This patch marks the function _c4iw_write_mem_dma() as static in
> hw/cxgb4/mem.c because it is not used outside this file.
>
> Thus, it also eliminates the following warning in hw/cxgb4/mem.c:
>
1 - 100 of 518 matches
Mail list logo
