From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64.
Rename some timespec to timespec64 in time.c and related references.
Cc: Thomas Gle
From: Badhri Jagan Sridharan
The timer_start event now shows whether the timer is
deferrable in case of a low-res timer. The debug_activate
function now includes deferrable flag while calling
trace_timer_start event.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Acked-by: Steven Rostedt
Signed-off-by:
On 5/13/2015 8:04 PM, Benson Leung wrote:
> On Tue, May 12, 2015 at 10:23 AM, Rhyland Klein wrote:
>> From: Bill Huang
>>
>> Add logic which (if specified for a pll) can verify that a PLL is set
>> to the proper default value and if not can set it. This can be
>> specified per PLL as each will ha
From: Xunlei Pang
Now we have all the read_boot_clock64() for all implementations,
it's time to remove read_boot_clock() completely from the kernel.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Xunlei Pang
Signed-off-by: John Stultz
---
include/linux/timekeeping.h | 1 -
kernel/time/
On Fri, 15 May 2015, Thomas Gleixner wrote:
On Mon, 11 May 2015, Vikas Shivappa wrote:
Signed-off-by: Vikas Shivappa
Conflicts:
arch/x86/kernel/cpu/perf_event_intel_cqm.c
And that's interesting for what?
Will remove this, fixed some conflicts as this code changes both cqm and c
From: Harald Geyer
This patch series introduces a new function
u32 ktime_get_resolution_ns(void)
which allows to clean up some driver code.
In particular the IIO subsystem has a function to provide timestamps for
events but no means to get their resolution. So currently the dht11 driver
tries to
From: Xunlei Pang
On 32-bit systems, timespec64_add_ns() calls __iter_div_u64_rem()
which needs match64.h, and we want to include time64.h in some
cases.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Xunlei Pang
Signed-off-by: John Stultz
---
include/linux/time64.h | 1 +
1 file change
Hey Thomas, Ingo,
Just wanted to send you my current queue of items that I
have pending for tip/timers/core for 4.2
Let me know if you have any concerns or objections.
thanks
-john
Cc: Thomas Gleixner
Cc: Ingo Molnar
Badhri Jagan Sridharan (1):
tracing: timer: Add deferrable flag to timer
On 05/20/15 07:54, Masanari Iida wrote:
> This patch fix spelling typo inv various part of sources.
>
> Signed-off-by: Masanari Iida
> ---
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> drivers/crypto/img-hash.c | 2 +-
> drivers/input/touchscreen/ili210x.c
On 5/13/2015 8:25 PM, Benson Leung wrote:
> On Tue, May 12, 2015 at 10:24 AM, Rhyland Klein wrote:
>> +static void pll_clk_start_ss(struct tegra_clk_pll *pll)
>> +{
>> + if (pll->params->defaults_set && pll->params->ssc_ctrl_en_mask) {
>
> Is there any reason you're checking for the existen
On Wed, May 20, 2015 at 06:07:44PM +0200, Geert Uytterhoeven wrote:
> Add the "jedec" vendor prefix for the "JEDEC Solid State Technology
> Association" (formerly known as the "Joint Electron Device Engineering
> Council"), which is already in use in several bindings.
>
> Signed-off-by: Geert Uytt
On 5/14/2015 4:23 PM, Benson Leung wrote:
> On Tue, May 12, 2015 at 10:24 AM, Rhyland Klein wrote:
>> +static int _p_div_to_hw(struct clk_hw *hw, u8 p_div)
>> +{
>> + struct tegra_clk_pll *pll = to_clk_pll(hw);
>> + struct pdiv_map *p_tohw = pll->params->pdiv_tohw;
>> +
>> + if (
On 5/20/2015 5:47 AM, Jim Lin wrote:
> On 05/13/2015 01:24 AM, Rhyland Klein wrote:
>> diff --git a/drivers/clk/tegra/clk-tegra210.c
>> b/drivers/clk/tegra/clk-tegra210.c
>> new file mode 100644
>> index ..7f25e60e4d48
>> --- /dev/null
>> +++ b/drivers/clk/tegra/clk-tegra210.c
>>
>> +
On 5/18/2015 7:03 AM, Bill Huang wrote:
> This fixes bug in tegra_clk_register_pllss() which mistakenly assume the
> iddq register is the PLL base address.
>
> Signed-off-by: Bill Huang
> ---
> drivers/clk/tegra/clk-pll.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> d
On Wed, May 20, 2015 at 05:49:07PM +0200, Wolfram Sang wrote:
> On Wed, May 20, 2015 at 08:57:00PM +0530, Sudip Mukherjee wrote:
> > Modify i2c-parport driver to use the new parallel port device model.
> >
> > Tested-by: Jean Delvare
> > Signed-off-by: Sudip Mukherjee
> > ---
>
> In general:
>
* Krzysztof Kozlowski [150427 05:52]:
> The irq_domain_ops are not modified by the driver and the irqdomain core
> code accepts pointer to a const data.
>
> Signed-off-by: Krzysztof Kozlowski
Applying into omap-for-v4.2/cleanup thanks.
Tony
> ---
> arch/arm/mach-omap2/omap-wakeupgen.c | 2 +-
* Alexander Kuleshov [150317 03:46]:
> provides macros for console log level, let's use it
> instead of numbers.
>
> Signed-off-by: Alexander Kuleshov
Applying into omap-for-v4.2/cleanup thanks.
Tony
> ---
> arch/arm/mach-omap2/serial.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
* Andrey Skvortsov [150510 14:29]:
> According to the technical reference manual for AM35xx system
> controller module (SCM) PADCONFS core registers are divided in two
> regions: 0x48002030..0x48002268 and 0x480025d8..0x480025FC.
> First region is the same for all omap3 SoC and is described in oma
Hi,
Just for completeness,
> On 20 May 2015, at 14:16, Jens Wiklander wrote:
>
> Hi,
>
> On Mon, May 18, 2015 at 02:18:50PM +0100, Mark Rutland wrote:
>> Hi,
>>
>> On Fri, May 15, 2015 at 07:34:27AM +0100, Jens Wiklander wrote:
>
[…]
>>
>> I'm also very concerned that the interface exposed
On Wed, May 20, 2015 at 9:59 AM, Elliott, Robert (Server Storage)
wrote:
>
>
>
> > -Original Message-
> > From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf
> > Of Dan Williams
> > Sent: Tuesday, April 28, 2015 1:25 PM
> > To: linux-nvd...@lists.01.org
> > Cc: Neil Bro
> -Original Message-
> From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf
> Of Dan Williams
> Sent: Tuesday, April 28, 2015 1:25 PM
> To: linux-nvd...@lists.01.org
> Cc: Neil Brown; Greg KH; linux-kernel@vger.kernel.org
> Subject: [Linux-nvdimm] [PATCH v2 07/20] libnd
On Wed, May 20, 2015 at 9:25 AM, Josh Poimboeuf wrote:
> On Wed, May 20, 2015 at 09:03:37AM -0700, Andy Lutomirski wrote:
>>
>> I've never quite understood what the '?' means.
>
> It basically means "here's a function address we found on the stack,
> which may or may not have been called." It's n
On 20.05.2015 14:53, Antoine Tenart wrote:
The BG2Q SoC has two SPI controllers. Add the corresponding nodes.
Signed-off-by: Antoine Tenart
---
Based on top of the Berlin clock rework series.
arch/arm/boot/dts/berlin2q.dtsi | 38 ++
1 file changed, 38 in
On 05/20/15 17:37, Alex Deucher wrote:
> On Tue, May 19, 2015 at 6:03 PM, Malte Schröder wrote:
>> Hi,
>> with 4.1-rc display-port on my Tahiti XT stopped working. I used the
>> firmware from http://people.freedesktop.org/~agd5f/radeon_ucode/ as of
>> today.
>> Note: the display is an Asus PB278,
Hi Evgeniy,
On Wed, May 20, 2015 at 10:26:20AM +0300, Evgeniy Dushistov wrote:
> At current state ads7846 driver ignore GPIO_ACTIVE_LOW,
> GPIO_ACTIVE_HIGH flags in such dts expression:
> pendown-gpio = <&gpio5 5 GPIO_ACTIVE_HIGH>;
>
> In times of usage arch/arm/.. you can handle this
> by get_pe
On 15-05-20 09:41:21, Andy Lutomirski wrote:
> On Wed, May 20, 2015 at 9:21 AM, Petko Manolov wrote:
> > On 15-05-20 08:56:21, Andy Lutomirski wrote:
> >>
> >> Would it make more sense to permit X.509 chains to be loaded into the
> >> keyring
> >> instead if we actually need that feature? IOW, l
On Wed, May 20, 2015 at 11:25:37AM -0500, Josh Poimboeuf wrote:
> > I've never quite understood what the '?' means.
>
> It basically means "here's a function address we found on the stack,
> which may or may not have been called." It's needed because stack
> walking isn't currently 100% reliable.
Srikar,
sorry for delay, vacation.
On 05/13, Srikar Dronamraju wrote:
>
> > No. I don't think arch_uretprobe_is_alive() above can work for powerpc,
> > at least the same way.
> >
> > The problem is, when the function is called, the ret-addr is not pushed
> > on stack. If it was, then arch_uretpro
On 2015/05/18, 3:21 PM, "Dan Carpenter" wrote:
>On Mon, May 18, 2015 at 08:34:51PM +0200, Adrian Remonda wrote:
>> Fixed sparse warning: context imbalance in 'nrs_resource_put_safe' -
>> 'different lock contexts for basic block' by releasing the lock on each
>> iteration of the for loop.
>>
>
>T
On Mon, May 18, 2015 at 05:46:31AM +0100, Vaneet Narang wrote:
> EP-2DAD0AFA905A4ACB804C4F82A001242F
>
> On Wed, May 13, 2015 at 06:24:06AM +0100, Maninder Singh wrote:
> >> EP-2DAD0AFA905A4ACB804C4F82A001242F
> >>
> >> Subject: [PATCH 1/1] hw_breakpoint.c :cpu hotplug handling
> >>
> >> This pa
On Wed, May 20, 2015 at 02:31:59PM +0200, Robert Richter wrote:
> On 20.05.15 13:22:13, Marc Zyngier wrote:
> > On Tue, 12 May 2015 18:24:16 +0100
> > Will Deacon wrote:
> > > On Tue, May 12, 2015 at 05:20:49PM +0100, Robert Richter wrote:
> > > > On 12.05.15 13:30:57, Will Deacon wrote:
>
> > >
To make general-purpose kexec (not just kdump) possible for Hyper-V guests
we need to perform some additional cleanup before starting new kernel (see
[PATCH 2/3] for the detailed description).
Know limitations: kexec with balloned out memory is not possible as the
newly loaded kernel doesn't know
At the very late stage of kexec a driver (which are not being unloaded) can
try to post a message or signal an event. This will crash the kernel as we
already did hv_cleanup() and the hypercall page is NULL.
Move all common (between 32 and 64 bit code) declarations to the beginning
of the do_hyper
On 15-05-20 17:24:46, One Thousand Gnomes wrote:
>
> More to the point why do you want to sign firmware files ? Leaving aside the
> fact that someone will produce a device with GPLv3 firmware just to p*ss you
> off there's the rather more relevant fact that firmware for devices on a so
> called
We already have hv_synic_free() which frees all per-cpu pages for all
CPUs, let's remove the hv_synic_free_cpu() call from hv_synic_cleanup()
so it will be possible to do separate cleanup (writing to MSRs) and final
freeing. This is going to be used to assist kexec.
Signed-off-by: Vitaly Kuznetsov
When general-purpose kexec (not kdump) is being performed in Hyper-V guest
the newly booted kernel fails with an MCE error coming from the host. It
is the same error which was fixed in the "Drivers: hv: vmbus: Implement
the protocol for tearing down vmbus state" commit - monitor pages remain
specia
On Wed, May 20, 2015 at 12:27:34AM -0700, Greg Kroah-Hartman wrote:
> On Mon, Mar 30, 2015 at 04:20:10PM -0700, Dmitry Torokhov wrote:
> > From: "Luis R. Rodriguez"
> >
> > Folks wishing to test enabling async probe for all built-in drivers
> > and/or for all modules can use
> > __DEBUG__kernel_f
On Tue, May 19, 2015 at 9:37 PM, Joe Perches wrote:
> Use the generic mechanism to declare a bitmap instead of unsigned long.
>
> Signed-off-by: Joe Perches
Applied to my -next tree. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Wed, May 20, 2015 at 12:24:21PM -0400, Johannes Weiner wrote:
> >
> > Low thread counts get a small boost but it's within noise as memcg overhead
> > does not dominate. It's not obvious at all at higher thread counts as other
> > factors cause more problems. The overall breakdown of CPU usage l
On Wed, May 20, 2015 at 9:21 AM, Petko Manolov wrote:
> On 15-05-20 08:56:21, Andy Lutomirski wrote:
>>
>> Would it make more sense to permit X.509 chains to be loaded into the keyring
>> instead if we actually need that feature? IOW, let userspace (or early
>> initramfs stuff) extend our keyring
On Wed, May 20, 2015 at 9:25 AM, Josh Poimboeuf wrote:
> On Wed, May 20, 2015 at 09:03:37AM -0700, Andy Lutomirski wrote:
>> On Wed, May 20, 2015 at 7:48 AM, Ingo Molnar wrote:
>> > Yeah, so many of these seem to be 'leaf only' functions: functions
>> > that don't ever call functions themselves.
On Mon, Apr 20, 2015 at 04:19:44PM -0400, David Long wrote:
> Add support for basic kernel probes(kprobes) and jump probes
> (jprobes) for ARM64.
>
> Kprobes utilizes software breakpoint and single step debug
> exceptions supported on ARM v8.
>
> A software breakpoint is placed at the probe addre
On Wed, 20 May 2015 17:46:44 +0200
Richard Weinberger wrote:
> On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee
> wrote:
> > Lets give the parport subsystem a proper name and start
> > maintaining the files.
>
> Excuse me, but usually someone takes over the maintainer role after
> proving that
On 5/20/15 9:05 AM, Andy Lutomirski wrote:
What causes the stack pointer to be right? Is there some reason that
the stack pointer is the same no matter where you are in the generated
code?
that's why I said 'it's _roughly_ expressed in C' this way.
Stack pointer doesn't change. It uses the s
On Wed, May 20, 2015 at 06:08:02PM +0200, Peter Zijlstra wrote:
> @@ -2062,6 +2081,22 @@ intel_get_excl_constraints(struct cpu_hw_events *cpuc,
> struct perf_event *event,
>*/
>
> /*
> + * Do not allow scheduling of more than max_alloc_cntrs
> + * which is set to half the
On Wed, 2015-05-20 at 17:46 +0200, Richard Weinberger wrote:
> On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee
> wrote:
> > Lets give the parport subsystem a proper name and start
> > maintaining the files.
>
> Excuse me, but usually someone takes over the maintainer role after
> proving that he
On Wed, May 20, 2015 at 09:03:37AM -0700, Andy Lutomirski wrote:
> On Wed, May 20, 2015 at 7:48 AM, Ingo Molnar wrote:
> > Yeah, so many of these seem to be 'leaf only' functions: functions
> > that don't ever call functions themselves.
> >
> > So lets assume we always have CONFIG_FRAME_POINTERS=y
On Wed, 20 May 2015 09:04:26 -0500
Seth Forshee wrote:
> On Tue, May 19, 2015 at 10:02:32PM +0200, Luis R. Rodriguez wrote:
> > This begs the question on how we'd manage keys for firmware signing on
> > linux-firmare. Since the keys are x509 keys we need a CA. Based on some
> > initial
> > discu
On Wed, May 20, 2015 at 03:52:09PM +0200, Peter Zijlstra wrote:
> On Wed, May 20, 2015 at 11:28:42AM +0200, Peter Zijlstra wrote:
>
> > ---
> >
> > c02cdbf60b51b8d98a49185535f5d527a2965142 is the first bad commit
> > commit c02cdbf60b51b8d98a49185535f5d527a2965142
> > Author: Stephane Eranian
>
On Wed, May 20, 2015 at 01:50:45PM +0100, Mel Gorman wrote:
> memcg was reported years ago to have significant overhead when unused. It
> has improved but it's still the case that users that have no knowledge of
> memcg pay a small performance penalty.
>
> This patch adds a Kconfig that controls wh
On 05/20/2015 07:44 AM, Jan Kara wrote:
> On Tue 19-05-15 13:33:31, David Lang wrote:
>> On Tue, 19 May 2015, Daniel Phillips wrote:
>>
I understand that Tux3 may avoid these issues due to some other mechanisms
it internally has but if page forking should get into mm subsystem, the
On 15-05-20 08:56:21, Andy Lutomirski wrote:
>
> Would it make more sense to permit X.509 chains to be loaded into the keyring
> instead if we actually need that feature? IOW, let userspace (or early
> initramfs stuff) extend our keyring trust to intermediate certs that validly
> chain to alre
On Wed, May 20, 2015 at 02:57:36PM +0200, Lorenzo Nava wrote:
> so probably currently is impossible to allocate a contiguous cachable
> DMA memory. You can't use CMA, and the only functions which allow you
> to use it are not compatible with sync functions.
> Do you think the problem is the CMA des
From: André Hentschel
Since commit a4780adeefd042482f624f5e0d577bf9cdcbb760 the user writeable TLS
register on ARM is preserved per thread.
This patch does it analogous to the ARM patch, but for compat mode on ARM64.
Signed-off-by: André Hentschel
Cc: Will Deacon
Cc: Catalin Marinas
---
Thi
Am Mittwoch, 20. Mai 2015, 11:06:42 schrieb Theodore Ts'o:
Hi Theodore,
As a side note to this discussion, may I ask why entropy_total is used for
checking against the threshold value and not entropy_count?
The reason for my question is the following: until a DRNG (in the worst case,
nonblocki
Hi Arnd, Philipp,
2015-05-13 21:11 GMT+02:00 Arnd Bergmann :
> Ideally the binding should follow closely what is documented
> in the data sheet.
>
Daniel and myself would like your opinion about this binding:
rcc: rcc@40023800 {
#reset-cells = <1>;
#clock-cells = <2>;
compatible = "s
On 05/20/2015 04:55 PM, Ingo Molnar wrote:
* Arnaldo Carvalho de Melo wrote:
Em Wed, May 20, 2015 at 03:29:37PM +0200, Martin Liška escreveu:
On 05/20/2015 03:17 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, May 20, 2015 at 03:07:39PM +0200, Martin Liška escreveu:
Currently, GCC optimizes -O
On Wed, May 20, 2015 at 11:29:23AM -0400, Johannes Weiner wrote:
> On Wed, May 20, 2015 at 01:50:44PM +0100, Mel Gorman wrote:
> > Historically memcg overhead was high even if memcg was unused. This has
> > improved a lot but it still showed up in a profile summary as being a
> > problem.
> >
> >
Clock rates are stored in an unsigned long field, but ->determine_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.
Change ->determine_rate() prototype to
On Wed, May 20, 2015 at 10:51:56AM -0500, Josh Poimboeuf wrote:
> On Wed, May 20, 2015 at 04:48:10PM +0200, Ingo Molnar wrote:
> > Yeah, so many of these seem to be 'leaf only' functions: functions
> > that don't ever call functions themselves.
>
> Yeah, good observation.
>
> > So lets assume we
On 15-05-19 17:22:59, Luis R. Rodriguez wrote:
>
> I have a series of reasons find IMA unsuitable for the current goals at hand:
>
> 1) IMA is a pretty big kitchen sink, we want this to work well for
> even embedded systems, or architectures that do not have or require
> TPMs
No, it isn't. I'v
Using dso__data_fd() in multi-thread environment is not safe since
returned fd can be closed and/or reused anytime. So convert it to the
dso__data_get/put_fd() pair to protect the access with lock.
The original dso__data_fd() is deprecated and kept only for testing.
Cc: Adrian Hunter
Signed-off
On Wed, May 20, 2015 at 05:26:07PM +0200, Peter Zijlstra wrote:
> Except of course that ->event_init() likes to do an allocation :/
>
> Needs to be fixed differently.
So this puts the lock in the x86 code, it seems to build and run.
But my brain is fried after staring at this pmu scheduling code
It seems that the dso__data_fd() was needed to find a binary type
since open in data_file_size() alone used to fail. But as it can open
the dso fine now, the dso__data_fd() can go away.
Cc: Adrian Hunter
Signed-off-by: Namhyung Kim
---
tools/perf/util/dso.c | 6 --
1 file changed, 6 deleti
On Wed, May 20, 2015 at 05:25:34PM +0200, Peter Zijlstra wrote:
> >
> > OK, so if you have the watchdog enabled, that's 1 event, and having a
> > max of 2 GP events, adding another 2 events is fail.
>
> Hmm, so we count all events, including those scheduled on fixed purpose
> counters.
>
> Lemm
Add the "jedec" vendor prefix for the "JEDEC Solid State Technology
Association" (formerly known as the "Joint Electron Device Engineering
Council"), which is already in use in several bindings.
Signed-off-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1
On Wed, May 20, 2015 at 04:55:58PM +0100, One Thousand Gnomes wrote:
> > That's not what appears to be happening here though: the MWAITX will
> > return after the timeout.
> >
> > Which isn't really useful unless we use it to drive timers.
>
> What about things like mdelay() ?
It has an upper l
On Wed, 2015-05-20 at 18:04 +0200, Borislav Petkov wrote:
> On Wed, May 20, 2015 at 09:02:23AM -0600, Toshi Kani wrote:
> > Boris, can you update the patch,
>
> Done.
Thanks!
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
2015-05-20 16:03 GMT+02:00 Sascha Hauer :
> On Tue, May 19, 2015 at 01:06:10PM +0200, Matthias Brugger wrote:
>> 2015-05-19 12:30 GMT+02:00 Sascha Hauer :
>> >
>> > I'll check for errors next round. However, I cannot bail out in this
>> > case since once pm_genpd_init() is called the domain cannot
When dso__data_read_offset/addr() is called without prior
dso__data_fd() (or other functions which call it internally), it
failed to open dso in data_file_size() since its binary type was not
identified.
However calling dso__data_fd() in dso__data_read_offset() will hurt
performance as it grabs a
On Tue, May 19, 2015 at 5:14 PM, Alexei Starovoitov wrote:
> On 5/19/15 5:11 PM, Andy Lutomirski wrote:
>>
>> On Tue, May 19, 2015 at 4:59 PM, Alexei Starovoitov
>> wrote:
>>>
>>> bpf_tail_call() arguments:
>>> ctx - context pointer
>>> jmp_table - one of BPF_MAP_TYPE_PROG_ARRAY maps used as the
From: Michal Kubecek
Date: Mon, 18 May 2015 20:53:50 +0200 (CEST)
> (1) When adding a nexthop of a multipath route fails (e.g. because of a
> conflict with an existing route), we are supposed to delete nexthops
> already added. However, currently we try to also delete all nexthops we
> haven't ev
On Wed, May 20, 2015 at 7:48 AM, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
>> On Wed, May 20, 2015 at 12:33:39PM +0200, Ingo Molnar wrote:
>> >
>> > * Josh Poimboeuf wrote:
>> >
>> > > In discussions around the live kernel patching consistency model RFC
>> > > [1], Peter and Ingo correctl
On Wed, May 20, 2015 at 09:02:23AM -0600, Toshi Kani wrote:
> Boris, can you update the patch,
Done.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
On Mon, May 18, 2015 at 9:10 PM, Vinod Koul wrote:
> On Wed, May 13, 2015 at 06:35:55PM +, Williams, Dan J wrote:
>> [ adding willy (yes, need to fix my scripts), and dmaengine folks]
>>
>> Jens, Christoph,
>>
>> I've rebased this patch series block/for-next. With commit 84be456f883c
>> "remo
Driver for the on chip RTC found on Cortina's SoC Gemini.
Signed-off-by: Hans Ulli Kroll
---
MAINTAINERS | 1 +
drivers/rtc/Kconfig | 11 +++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-gemini.c | 190 +++
4 files changed, 20
On Wed, May 20, 2015 at 6:14 AM, David Howells wrote:
> Andy Lutomirski wrote:
>
>> > enum pkey_id_type {
>> > PKEY_ID_PGP,/* OpenPGP generated key ID */
>> > PKEY_ID_X509, /* X.509 arbitrary subjectKeyIdentifier */
>> > + PKEY_ID_PKCS7, /* Signature in
On Wed, May 20, 2015 at 08:57:00PM +0530, Sudip Mukherjee wrote:
> Modify i2c-parport driver to use the new parallel port device model.
>
> Tested-by: Jean Delvare
> Signed-off-by: Sudip Mukherjee
> ---
In general:
Acked-by: Wolfram Sang
> static struct parport_driver i2c_parport_driver = {
On Wed, May 20, 2015 at 6:36 AM, David Howells wrote:
> Andy Lutomirski wrote:
>
>> I think this is way more complicated than it has to be. Can't we look up
>> certificates by their subjectPublicKeyInfo?
>
> I want to be able to handle an X.509 chain to a root key that we have in the
> kernel.
> That's not what appears to be happening here though: the MWAITX will
> return after the timeout.
>
> Which isn't really useful unless we use it to drive timers.
What about things like mdelay() ?
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
On 20/05/2015 6:34 p.m., Namhyung Kim wrote:
On Wed, May 20, 2015 at 11:33:09AM +0300, Adrian Hunter wrote:
On 20/05/15 09:34, Namhyung Kim wrote:
Using dso__data_fd() in multi-thread environment is not safe since
returned fd can be closed and/or reused anytime. So convert it to the
dso__data_
On 05/20/2015 04:46 PM, Will Deacon wrote:
> I'm not sure... you'd require the compiler to perform static analysis of
> loops to determine the state of the machine when they exit (if they exit!)
> in order to show whether or not a dependency is carried to subsequent
> operations. If it can't prove
Hi Pratyush,
sorry for delay, vacation.
On 05/18, Pratyush Anand wrote:
> Hi Oleg,
>
> On Monday 04 May 2015 06:19 PM, Oleg Nesterov wrote:
>> +bool __weak arch_uretprobe_is_alive(struct arch_uretprobe *auret, struct
>> pt_regs *regs)
>> +{
>> +return true;
>> +}
>
> IIUC, then this function
On Wed, May 20, 2015 at 04:48:10PM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > On Wed, May 20, 2015 at 12:33:39PM +0200, Ingo Molnar wrote:
> > >
> > > * Josh Poimboeuf wrote:
> > >
> > > > In discussions around the live kernel patching consistency model RFC
> > > > [1], Peter
changes from v1
v2:
- usage of readl/write
- spaces around *
- line wrapping at open parenthesis.
- add MAINTANERS for driver
v3:
- spaces around * (again)
- line wrapping at open parenthesis (again)
- add depends on ARCH_GEMINI found by Paul
v4:
- COMPILE_TEST requested by Arnd
- some typos found
On 15-05-19 19:10:07, Andy Lutomirski wrote:
> On Tue, May 19, 2015 at 7:05 PM, Mimi Zohar wrote:
> >
> > Perhaps you're referring to EVM?
>
> I don't know. I also couldn't figure out what IMA was and what EVM was.
Try reading this:
http://sourceforge.net/p/linux-ima/wiki/Home/
A little outda
On 2015/5/20 23:40, Thomas Gleixner wrote:
> On Wed, 20 May 2015, Jiang Liu wrote:
>> /* Chained IRQ handler for IPU error interrupt */
>> -static void ipu_irq_err(unsigned int irq, struct irq_desc *desc)
>> +static void ipu_irq_err(struct irq_desc *desc)
>> {
>> +unsigned int irq = irq_desc_
Luis R. Rodriguez wrote:
> This begs the question on how we'd manage keys for firmware signing on
> linux-firmare. Since the keys are x509 keys we need a CA. Based on some
> initial discussions it would seem we'd need the Linux Foundation to create a
> key, this would be embedded in the kernel an
On Wed, May 20, 2015 at 04:08:58PM +0100, David Howells wrote:
> Seth Forshee wrote:
>
> > > This begs the question on how we'd manage keys for firmware signing on
> > > linux-firmare. Since the keys are x509 keys we need a CA. Based on some
> > > initial discussions it would seem we'd need the L
On Wed, 20 May 2015, Jiang Liu wrote:
> On 2015/5/20 23:28, Thomas Gleixner wrote:
> > On Wed, 20 May 2015, Jiang Liu wrote:
> >> -static void locomo_handler(unsigned int irq, struct irq_desc *desc)
> >> +static void locomo_handler(struct irq_desc *desc)
> >> {
> >>struct locomo *lchip = irq_
On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee
wrote:
> Lets give the parport subsystem a proper name and start
> maintaining the files.
Excuse me, but usually someone takes over the maintainer role after
proving that he
cares for a sub system for a certain period of time.
Or did I miss somethi
On Wed, May 20, 2015 at 08:56:59PM +0530, Sudip Mukherjee wrote:
> As of now i2c-parport was connecting to all the available parallel
> ports. Lets limit that to maximum of 4 instances and at the same time
> define which instance connects to which parallel port.
>
> Tested-by: Jean Delvare
> Sign
Paul E. McKenney wrote:
> Ah, I was assuming between x and z. David, what was your intent? ;-)
Clarification.
David
--
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/m
2015-05-20 09:07+0200, Paolo Bonzini:
> On 19/05/2015 20:28, Radim Krčmář wrote:
>>> The regular and SMM address spaces are not hierarchical. As soon as you
>>> put a PCI resource underneath SMRAM---which is exactly what happens for
>>> legacy VRAM at 0xa---they can be completely different. N
On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote:
> On Wed, May 20, 2015 at 12:47:45PM +0100, Will Deacon wrote:
> > On Wed, May 20, 2015 at 03:41:48AM +0100, Paul E. McKenney wrote:
> > > If a pointer is part of a dependency chain, and if the values
> > > added to or subtracted
On Thu, Apr 30, 2015 at 1:52 PM, Jisheng Zhang wrote:
> Most transactions' type are cfg0 and MEM, so the Current iATU usage is not
> balanced, iATU0 is hot while iATU1 is rarely used. This patch refactors
> the iATU usage: iATU0 for cfg and IO, iATU1 for MEM. This allocation
> ideas comes from Min
On Wed, May 20, 2015 at 05:30:14PM +0200, Ard Biesheuvel wrote:
>
> However, it's quite a can of worms you're opening here. Speed is
> easily quantified, and it may even be feasible to introduce some kind
> of boottime benchmark to select the fastest implementation available
> (like already exists
On Wed, 20 May 2015, Jiang Liu wrote:
> /* Chained IRQ handler for IPU error interrupt */
> -static void ipu_irq_err(unsigned int irq, struct irq_desc *desc)
> +static void ipu_irq_err(struct irq_desc *desc)
> {
> + unsigned int irq = irq_desc_to_irq(desc);
Why initializing? It's overwritten
On Wed, 20 May 2015, Jiang Liu wrote:
> Now most IRQ flow handlers make no use of the first parameter 'irq'.
> And for those who do make use of 'irq', we could easily get the irq
> number through irq_desc->irq_data->irq. So kill the first parameter
> 'irq' of irq_flow_handler_t.
>
> To ease rev
On Tuesday 19 May 2015 16:00:09 Nicolas Ferre wrote:
> Second batch of DT changes for 4.2:
> - sama5d4: more peripherals: usarts, uarts, spi, pioD access
> - sama5d3: phy address for gmac
> - change NFC register map
> - regulator additions for the sd/mmc
>
Pulled into next/dt, thanks!
Ar
501 - 600 of 1172 matches
Mail list logo
