Hi Mark,
On Wed, Jul 15, 2015 at 10:50 PM, Mark Rutland wrote:
>
> On Wed, Jul 15, 2015 at 01:22:55PM +0100, Wendy Liang wrote:
> > Add documentation about the ZynqMP RPU remoteproc driver
> > DTS bindings.
> >
> > Signed-off-by: Jason Wu
> > Signed-off-by: Wendy Liang
> > ---
> > .../bindings
On Mon, 2015-07-13 at 11:35 -0400, Mike Snitzer wrote:
> I will do additional review to answer 1 and 2 above. And Jeff Moyer
> told me he'd test the patchset on one of his testbeds.
Hi Jeff,
FYI, here is a fix for patch 1.
Or you can pull from my tree.
https://git.kernel.org/cgit/linux/kernel/gi
* Nishanth Menon [150715 06:44]:
> On 07/15/2015 01:26 AM, Tony Lindgren wrote:
> > * Nishanth Menon [150622 08:14]:
> >> DRA7 uses OMAP5 IO table at the moment. This is purely spurious since
> >> the OMAP5 and DRA7 register maps are different in many aspects.
> >>
> >> AM57xx/DRA7 TRM Reference:
On Thu, Jul 16, 2015 at 5:44 AM, Masahiro Yamada
wrote:
> 2015-07-15 23:15 GMT+09:00 Linus Walleij :
>>> + for (i = 0; i < chip->ngpio; i += UNIPHIER_GPIO_PORTS_PER_BANK) {
>>> + bank = i / UNIPHIER_GPIO_PORTS_PER_BANK;
>>> + shift = i % BITS_PER_LONG;
>>> +
On Wed 15-07-15 15:44:36, David Rientjes wrote:
> OOM notifiers exist to give one last chance at reclaiming memory before
> the oom killer does its work.
>
> Thus, they don't actually belong in the oom killer proper, but rather in
> the page allocator where reclaim is invoked.
Why this is not nee
Use kprobe_blackpoint for blacklisting .entry.text and .kprobees.text
instead of arch_within_kprobe_blacklist. This also makes them visible
via (debugfs)/kprobes/blacklist.
Signed-off-by: Masami Hiramatsu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Ananth N Mavinakayanahalli
On Thu, Jul 16, 2015 at 08:02:03AM +0200, Stephane Eranian wrote:
> Been running it for a couple of hours, so far so good. I will let it
> run all night.
Thanks!
> > ---
> > arch/x86/kernel/cpu/perf_event_intel_ds.c | 29
> > +
> > 1 file changed, 13 insertions(+), 1
Fix typo s/CONFIG_TRANSPARENT_HUGEPAGES/CONFIG_TRANSPARENT_HUGEPAGE/
in #endif comment introduced by commit 2b26a9206d6a ("dax: add huge page
fault support").
Signed-off-by: Valentin Rothberg
---
fs/dax.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/dax.c b/fs/dax.c
ind
On Wed, Jul 15, 2015 at 05:32:13PM -0700, David Miller wrote:
> From: Clemens Gruber
> Date: Thu, 16 Jul 2015 02:04:04 +0200
>
> > This reverts commit 6c3e921b18edca290099adfddde8a50236bf2d80.
> >
> > The change did break ethernet support on the i.MX6Q and possibly also on
> > other platforms: T
Hello --
Your message was tagged as spam by an automated testing program.
Unless we receive a reply to this notice, the message will be set aside and
will not be seen or acted on by anyone.
Therefore, please reply to this message as soon as possible.
If you did not send any mail to an email ad
To blacklist the functions in a module (e.g. user-defined
kprobe handler and the functions invoked from it), expand
blacklist support for modules.
With this change, users can use NOKPROBE_SYMBOL() macro in
their own modules.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: "Dav
Hi,
Here is a series of patches of kprobe blacklist enhancement
which I sent 1 yrs ago (with some performance improvements).
I've decided to split these patches from performance improvement
patches because it is easy to review/merge.
These 3 patches add NOKPROBE_SYMBOL() support for modules and
Use NOKPROBE_SYMBOL() to protect handlers from kprobes
in sample modules.
Signed-off-by: Masami Hiramatsu
Ananth N Mavinakayanahalli
---
samples/kprobes/jprobe_example.c|1 +
samples/kprobes/kprobe_example.c|3 +++
samples/kprobes/kretprobe_example.c |2 ++
3 files changed,
On Thu, 2015-07-16 at 14:54 +0800, Daniel Kurtz wrote:
> On Thu, Jul 16, 2015 at 1:38 PM, YH Huang wrote:
> > On Wed, 2015-07-15 at 23:59 +0800, YH Huang wrote:
> >> On Mon, 2015-07-13 at 18:19 +0800, Daniel Kurtz wrote:
> >> > On Mon, Jul 13, 2015 at 5:04 PM, YH Huang wrote:
> >> > > Add display
On Thu, Jun 18, 2015 at 05:47:47PM +0530, Sudip Mukherjee wrote:
> allmodconfig build fails with the error:
> invalid use of undefined type 'struct kprobe_ctlblk'
>
> just declared the two basic structures after checking the struct in other
> architectures.
Gentle ping.
On Wed 15-07-15 13:57:11, Andrew Morton wrote:
> On Wed, 15 Jul 2015 13:14:41 +0200 Michal Hocko wrote:
>
> > mem_cgroup structure is defined in mm/memcontrol.c currently which
> > means that the code outside of this file has to use external API even
> > for trivial access stuff.
> >
> > This pa
On Tue, Jul 14, 2015 at 4:40 AM, Masahiro Yamada
wrote:
> The core support for the pinctrl drivers for all the UniPhier SoCs.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - drop vogus THIS_MODULE because this file is always built-in
> - drop vogus "include because this file
On 07/16/2015 05:20 AM, Tejun Heo wrote:
On Wed, Jul 01, 2015 at 11:16:54AM +0800, Tang Chen wrote:
...
- /* and there's no empty block */
- if (bi->start >= bi->end)
+ /* and there's no empty or non-exist block */
+ if (bi->start >= bi->e
On Tue, Jul 14, 2015 at 4:40 AM, Masahiro Yamada
wrote:
> Add pin configuration and pinmux support for UniPhier PH1-LD4 SoC.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - sort groups and funcs alphabetically
> - add missing "emmc_dat8" group
> - add i2c pin-mux settings
>
On Wed 15-07-15 20:19:20, Oleg Nesterov wrote:
> On 07/15, Jan Kara wrote:
> > So I'm also in favor of Oleg's approach
> > as well. We just have to wait until he fixes the outstanding issues with
> > his code.
>
> Yes. I'll try to make the working version, hopefully this week.
>
> But,
>
> > Dav
On Wed 15-07-15 08:01:05, Joe Perches wrote:
> On Wed, 2015-07-15 at 12:26 +0200, Jan Kara wrote:
> > I have created this patch set which removes ext3 driver (and some related
> > support
> > code) from the kernel. See changelog of patch 2/3 for more details.
>
> It'd be nice if you regenerate 2/
On Tue, Jul 14, 2015 at 4:40 AM, Masahiro Yamada
wrote:
> Add pin configuration and pinmux support for UniPhier PH1-Pro4 SoC.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - sort groups and funcs alphabetically
> - add i2c pin-mux settings
> - sort members of platform_drive
Hi Mark,
> > > > What is stacked mode?
> > > > -
> > > > ZynqMP GQSPI controller supports stacked mode with following
> > > functionalities:
> > > > 1) The Generic Quad-SPI controller also supports two SPI flash memories
> > > >in a shared bus arrangement to reduce IO pin c
On Tue, Jul 14, 2015 at 4:40 AM, Masahiro Yamada
wrote:
> Add pin configuration and pinmux support for UniPhier PH1-sLD8 SoC.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - sort groups and funcs alphabetically
> - add i2c pin-mux settings
> - sort members of platform_drive
On Thu, Jul 16, 2015 at 12:15 AM, Peter Zijlstra wrote:
> On Thu, Jul 16, 2015 at 08:02:03AM +0200, Stephane Eranian wrote:
>> Been running it for a couple of hours, so far so good. I will let it
>> run all night.
>
> Thanks!
>
Well, it died on NHM in the same function despite your patch. Need to
On 07/16/2015 12:26 AM, Jan Kara wrote:
> So Dave's patches would go in only in the next merge window anyway so we
> still have like two-three weeks to decide which patchset to take. If you
> think it will take you longer, then merging Dave's patches makes some sense
> although I personally don't t
On Tue, Jul 14, 2015 at 4:40 AM, Masahiro Yamada
wrote:
> Add pin configuration and pinmux support for UniPhier PH1-Pro5 SoC.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - sort groups and funcs alphabetically
> - add i2c pin-mux settings
> - sort members of platform_drive
On Thursday 16 July 2015 03:02:03 Rafael J. Wysocki wrote:
> On Sunday, June 21, 2015 01:20:32 PM Pali Rohár wrote:
> > To prevent race conditions on userspace processes with I/O some taks must be
> > called after processes are freezed. This patch adds new events which are
> > delivered by pm_notif
On Tue, Jul 14, 2015 at 4:40 AM, Masahiro Yamada
wrote:
> Add pin configuration and pinmux support for UniPhier ProXstream2
> SoC.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - sort groups and funcs alphabetically
> - add i2c pin-mux settings
> - sort members of platform_
Hi Linus,
2015-07-16 16:07 GMT+09:00 Linus Walleij :
> On Thu, Jul 16, 2015 at 5:44 AM, Masahiro Yamada
> wrote:
>> 2015-07-15 23:15 GMT+09:00 Linus Walleij :
>
+ for (i = 0; i < chip->ngpio; i += UNIPHIER_GPIO_PORTS_PER_BANK) {
+ bank = i / UNIPHIER_GPIO_PORTS_PER
On Tue, Jul 14, 2015 at 4:40 AM, Masahiro Yamada
wrote:
> Add pin configuration and pinmux support for UniPhier PH1-LD6b SoC.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - sort groups and funcs alphabetically
> - add i2c pin-mux settings
> - sort members of platform_drive
Hi Stefan,
On Wednesday 15 July 2015 18:06:26 Stefan Wahren wrote:
> [...]
> > ---
>
> changelog for v2?
:) follows. Will send v3 which also contains the missing newline fix.
Thanks,
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solut
On Thu, Jul 9, 2015 at 3:55 AM, Masahiro Yamada
wrote:
> Kbuild should descend into drivers/pinctrl/ only when CONFIG_PINCTRL
> is enabled because everything under that directory depends on
> CONFIG_PINCTRL.
>
> We can avoid the conditional, ifeq ($(CONFIG_OF),y) ... endif.
>
> Signed-off-by: Mas
On 15/07/15 19:57, David Daney wrote:
> On 07/15/2015 10:12 AM, Marc Zyngier wrote:
>> On 15/07/15 17:54, David Daney wrote:
>>> From: David Daney
>>>
>>> Needed to map SPI interrupt sources.
>>>
>>> Signed-off-by: David Daney
>>> ---
>>> drivers/irqchip/irq-gic-v3.c | 5 +
>>> inclu
On Wed, Jul 15, 2015 at 01:30:14PM +0200, Ingo Molnar wrote:
> did you rebase a tree from Boris?
Yep, he did. We decided to do so because the fixes missed 4.2 and for
4.3 a clean rebase is just fine.
> Also, please send all patches as part of the submission so that I can
> comment on individual p
Whenever the UART device driver gets closed from userland, the driver
disables the UART unit and then stops its clock to save power.
The bit which disabled the UART unit is described as:
"UART Enable. If this bit is set to 1, the UART is enabled. Data
transmission and reception occurs for the
Fix spaces before comma and indentation.
Signed-off-by: Guillaume Bienkowski
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 42 +--
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl818
On Thu, Jul 16, 2015 at 9:35 AM, Masahiro Yamada
wrote:
> 2015-07-16 16:07 GMT+09:00 Linus Walleij :
>>> ngpio == 248 for some SoCs,
>>> and ngpio == 136 for some, etc.
>>
>> That is the wrong way to handle different SoC. That should be handled
>> by different compatible strings, and then you sel
From: "Chen, Gong"
Printing in MCE context is a no-no, currently, as printk is not
NMI-safe. If some of the notifiers on the MCE chain call do so, we may
deadlock. In order to avoid that, delay printk() to process context
where it is safe to do so.
[Tony: Folded in subsequent patch from Boris fo
From: Ashok Raj
Remove unused function declarations.
Signed-off-by: Ashok Raj
Cc: Tony Luck
Cc: linux-edac
Cc: x86-ml
Link:
http://lkml.kernel.org/r/1435621095-4802-1-git-send-email-ashok@intel.com
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/mce.h | 4
1 file changed,
Hi,
- Original Message -
> On Wed, Jul 15, 2015 at 05:30:50PM +0200, Levente Kurusa wrote:
> > Even if the signal was handled using signal(2) the message
> > would be printed. Fix that by checking whether the signal
> > is handled.
>
> Why?
One of the reasons is that arm64 prints the sam
From: "Chen, Gong"
printk() is not safe to use in MCE context. Add a lockless memory
allocator pool to save error records in MCE context. Those records will
be issued later, in a printk-safe context. The idea is inspired by
the APEI/GHES driver.
We're very conservative and allocate only two page
From: "Chen, Gong"
An MCE is a rare event. Therefore, there's no need to have per-CPU
instances of both normal and IRQ workqueues. Make them both global.
[Tony: Folded in subsequent patch from Rui/Boris/Tony for early boot logging]
Signed-off-by: Chen, Gong
Link:
http://lkml.kernel.org/r/1432
From: Ashok Raj
kexec could boot a kernel that could be legacy with no knowledge of
LMCE. Hence we should make sure we clear LMCE optin before kexec reboot.
Signed-off-by: Ashok Raj
Cc: Andy Lutomirski
Cc: Aravind Gopalakrishnan
Cc: Oleg Nesterov
Cc: Tony Luck
Cc: linux-edac
Cc: x86-ml
Li
From: "Chen, Gong"
Use unified genpool to save Action Optional error events and put Action
Optional error handling in the same notification chain as MCE error
decoding.
[Tony: Folded in subsequent patch from Boris for early boot logging]
Signed-off-by: Chen, Gong
Link:
http://lkml.kernel.org/
This used to flush out MCEs logged during early boot and which were in
the MCA registers from a previous system run. No need for that now,
since we're moving to a genpool.
Signed-off-by: Borislav Petkov
Suggested-by: Tony Luck
---
arch/x86/include/asm/mce.h | 2 +-
arch/x86/kernel/cpu/mc
2015-07-02 9:42 GMT+09:00 Chanwoo Choi :
> This patch add CPU clock configuration data and instantiate the CPU clock type
> for Exynos3250 to support Samsung specific cpu-clock type.
>
> Cc: Sylwester Nawrocki
> Cc: Tomasz Figa
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> Reviewed-
Hi Linus,
2015-07-16 16:42 GMT+09:00 Linus Walleij :
> On Thu, Jul 16, 2015 at 9:35 AM, Masahiro Yamada
> wrote:
>> 2015-07-16 16:07 GMT+09:00 Linus Walleij :
>
ngpio == 248 for some SoCs,
and ngpio == 136 for some, etc.
>>>
>>> That is the wrong way to handle different SoC. That should
On Wed, Jul 15, 2015 at 08:52:51AM +0530, Maninder Singh wrote:
> dev_kfree_skb checks for NULL pointer itself,
> Thus no need of explicit NULL check.
>
I hate these patches. I have told Markus to stop sending them but he
has issues so now I only complain when they introduce a bug. There was
on
From: "zilong.liu"
Remove key.h which is included twice in crypto_fname.c
Signed-off-by: zilong.liu
---
fs/ext4/crypto_fname.c |1 -
1 file changed, 1 deletion(-)
diff --git a/fs/ext4/crypto_fname.c b/fs/ext4/crypto_fname.c
index 7dc4eb5..4c11768 100644
--- a/fs/ext4/crypto_fname.c
+++ b/
Hi Bjorn,
On 07/15/2015 10:02 PM, Bjorn Andersson wrote:
The Qualcomm PM8941 WLED block is used for backlight and should therefor
be in the backlight framework and not in the LED framework. This moves
the driver and adapts to the backlight api instead.
Signed-off-by: Bjorn Andersson
---
.../
The On-Chip-Controller(OCC) can throttle cpu frequency by reducing the
max allowed frequency for that chip if the chip exceeds its power or
temperature limits. As Pmax capping is a chip level condition report
this throttling behavior at chip level and also do not set the global
'throttled' on Pmax
On wo, 2015-07-15 at 11:15 +0800, Xing Zheng wrote:
> --- /dev/null
> +++ b/sound/soc/rockchip/rockchip_max98090.c
> +#define DRV_NAME "rockchip-snd-max98090"
> +static const struct of_device_id rockchip_max98090_of_match[] = {
> + { .compatible = "rockchip,rockchip-audio-max98090", },
> +
From: Borislav Petkov
A certain number of patch levels of applied microcode should not be
overwritten by the microcode loader, otherwise bad things will happen.
Check those and abort update if the current core has one of those final
patch levels applied by the BIOS. 32-bit needs special handling
From: Borislav Petkov
Pave the way for checking the current patch level of the microcode in a
core. We want to be able to do stuff depending on the patch level - in
this case decide whether to update or not. But that will be added in a
later patch; here we do not introduce any functionality chang
From: Borislav Petkov
Hi,
here are two microcode loader changes for making certain patch levels
applied by the firmware, final.
Please apply, thanks.
Borislav Petkov (2):
x86/microcode/amd: Extract current patch level read to a function
x86/microcode/amd: Do not overwrite final patch level
This patchset intends to add frequency throttle reporting mechanism
to powernv-cpufreq driver when OCC throttles the frequency. OCC is an
On-Chip-Controller which takes care of the power and thermal safety of
the chip. The CPU frequency can be throttled during an OCC reset or
when OCC tries to limi
Add OPAL_MSG_OCC message definition to opal_message_type to receive
OCC events like reset, load and throttled. Host performance can be
affected when OCC is reset or OCC throttles the max Pstate.
We can register to opal_message_notifier to receive OPAL_MSG_OCC type
of message and report it to the us
OCC is an On-Chip-Controller which takes care of power and thermal
safety of the chip. During runtime due to power failure or
overtemperature the OCC may throttle the frequencies of the CPUs to
remain within the power budget.
We want the cpufreq driver to be aware of such situations to be able
to
From: Byungchul Park
hello paul,
can i ask you something?
when a sched entity is both waken and migrated, it looks being decayed twice.
did you do it on purpose?
or am i missing something? :(
thanks,
byungchul
--->8---
>From 793c963d0b29977a0f6f9330291a9ea469cc54f0 Mon
This takes a stab at sizing the xsave buffer so that it will work for
AVX-512 systems. The logic is explained in the comment.
Cc: Linus Torvalds
Cc: Ingo Molnar
Cc: Linux Kernel Mailing List
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Fenghua Yu
Cc: "H. Peter Anvin"
Cc: leg Nesterov
Cc:
This is _very_ lightly tested. Just RFC for now. The fallback
code is not tested at all because I'm hitting another bug.
--
The recent x86 FPU rework changed a dynamic allocation to a
static one. But, the static one is undersized and we overrun it,
corrupting memory in some cases.
This patch
Re-evaluate the chip's throttled state on recieving OCC_THROTTLE
notification by executing *throttle_check() on any one of the cpu on
the chip. This is a sanity check to verify if we were indeed
throttled/unthrottled after receiving OCC_THROTTLE notification.
We cannot call *throttle_check() direc
If frequency is throttled due to OCC reset then cpus will be in Psafe
frequency, so restore the frequency on all cpus to policy->cur when
OCCs are active again. And if frequency is throttled due to Pmax
capping then restore the frequency of all the cpus in the chip on
unthrottling.
Signed-off-by:
On a reset cycle of OCC, although the system retires from safe
frequency state the local pstate is not restored to Pmin or last
requested pstate. Now if the cpufreq governor initiates a pstate
change, the local pstate will be in Psafe and we will be reporting a
false positive when we are not thrott
Hi Arnd,
Ok, I will remove the #ifdef in the next version.
Thanks.
Hi All,
Is there any others comments?
Thanks for your review.
Best Regards,
Yuan Yao
On Wednesday, July 15, 2015 10:55 PM Arnd wrote:
> On Wednesday 15 July 2015 10:29:55 Yao Yuan wrote:
> > Hi Arnd,
> >
> > Thanks for your revi
On Mon, Jun 22, 2015 at 5:12 PM, Dan Carpenter wrote:
> We were allocating enough space because sizeof("-grp") and
> sizeof("-mux") are both equal to 5 but in the snprintf() we only allowed
> for 4 characters so the last 'p' and 'x' characters were truncated.
>
> The allocate and sprintf can be d
On Mon, Jun 22, 2015 at 5:13 PM, Dan Carpenter wrote:
> Checkpatch.pl complains about these:
>
> WARNING: Possible unnecessary 'out of memory' message
>
> The messages use a little extra RAM and they add a few extra lines of
> code. We're probably never going to hit these out of memory situation
On (06/20/15 18:25), Julia Lawall wrote:
> > On (06/17/15 16:14), David Rientjes wrote:
> > [..]
> > > >
> > > > Signed-off-by: Sergey Senozhatsky
> > > > Reported-by: Andrew Morton
> > > > LKML-reference: https://lkml.org/lkml/2015/6/8/583
> > >
> > > Acked-by: David Rientjes
> > >
> > > kme
From: Joerg Roedel
The XR17V35X UART needs the ECB bit set in its XR_EFR
register to enable access to IER [7:5], ISR [5:4], FCR[5:4],
MCR[7:5], and MSR [7:0].
Also reset the IER register to mask interrupts after access
to all bits of this register has been enabled.
This makes my 8-port XR17V35X
On wo, 2015-07-15 at 09:54 -0700, David Daney wrote:
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> +config PCI_THUNDER_PEM
> + bool
Do you expect other symbols to select this symbol in the future? Because
at this moment PCI_THUNDER_PEM is merely an alias for PCI_THUNDER.
From: Joerg Roedel
Hi,
here is the second version of my patches to fix the
MAX_PHANDLE_ARGS limitation for the arm-smmu driver. On my
AMD Seattle system the max value of 16 is not enough to
initialize the SMMU, as the device tree node has an entry
with 25 phandle args (possible are up to 128). T
From: Krzysztof Kozlowski Sent: Thursday, July 16,
2015 2:56 PM
> To: Duan Fugang-B38611
> Cc: Kamal Mostafa; linux-kernel@vger.kernel.org; sta...@vger.kernel.org;
> kernel-t...@lists.ubuntu.com; daniel.lezc...@linaro.org; Damian Eppel;
> kyungmin.p...@samsung.com; kg...@kernel.org; Thomas Gleixn
From: Joerg Roedel
The function of_parse_phandle_with_args() can only handle 16
args, but there are systems that require more (25 in my
case). So use the newly introduced function
of_parse_phandle_with_var_args() instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/arm-smmu.c | 23 ++
From: Joerg Roedel
The main use of MAX_PHANDLE_ARGS is to define the number of
args elements in 'struct of_phandle_args'. This struct is
often declared on the stack and thus it is impractical to
increase MAX_PHANDLE_ARGS again and again.
To handle situations where more than MAX_PHANDLE_ARGS
elem
On Wed, Jun 24, 2015 at 4:54 PM, Grygorii Strashko
wrote:
> From: Grygorii Strashko
>
> Add missed spin_unlock_irqrestore in omap_gpio_irq_type when
> omap_set_gpio_triggering() is failed.
>
> It fixes static checker warning:
>
> drivers/gpio/gpio-omap.c:523 omap_gpio_irq_type()
>
在 2015/7/8 18:44, Thomas Gleixner 写道:
> On Wed, 8 Jul 2015, majun (F) wrote:
>> 在 2015/7/6 20:33, Thomas Gleixner 写道:
>>> Care to explain what this does? It seems for some nodes you cannot
>>> write the msi message. So how is that supposed to work? How is that
>>> interrupt controlled (mask/unmas
在 2015/7/8 23:30, Marc Zyngier 写道:
> Hi,
>
> Aside from all the comments Thomas had, the following aspect is worrying
> me a bit:
>
> On 06/07/15 08:09, Ma Jun wrote:
>> This patch contains the mbigen interrupt controller driver.
>
> [...]
>
>> +static int mbigen_set_type(struct irq_data *d,
phyBOARD-WEGA-AM335x represents a direct soldered
combination of a phyCORE-AM335x SoM and carrier board.
Different kind of SoM options can be connected to
the wega carrier board. So we created a separate
wega dtsi file. The final dts contains the actual
SoM on the carrier board.
WEGA carrier boar
在 2015/7/8 21:40, Mark Rutland 写道:
> On Mon, Jul 06, 2015 at 08:09:08AM +0100, Ma Jun wrote:
[...]
>> +
>> +Mbigen means: message based interrupt generator.
>> +
>> +MBI is kind of msi interrupt only used on Non-PCI devices.
>> +
>> +To reduce the wired interrupt number connected to GIC,
>> +Hisi
phyCORE-AM335x is a SoM (System on Module) containing
a AM335x SOC. The module can be connected to different
carrier boards.
Some hardware parts are configurable on the phyCORE-AM335x.
So they are disabled on default in this som dtsi file.
They will be enabled in the board dts files, when populate
On 07/15/2015 11:08 PM, Stephen Boyd wrote:
Sparse complains about these structures missing static, but they
also don't look to be used. Remove them.
drivers/clk/ti/clk-3xxx.c:74:30: warning: symbol
'clkhwops_omap3430es2_ssi_wait' was not declared. Should it be static?
drivers/clk/ti/clk-3xxx.c
On 07/15/2015 11:08 PM, Stephen Boyd wrote:
Some cleanups for the TI clk driver move.
Stephen Boyd (4):
clk: ti: Check kzalloc() for failures
clk: ti: Mark ti_clk_features static
clk: ti: clk-3xxx: Remove unused structures
clk: ti: Force pointer to be __iomem
drivers/clk/ti/clk-3x
在 2015/7/8 23:16, Marc Zyngier 写道:
> On 08/07/15 05:21, majun (F) wrote:
>> Hi Thomas:
>>
[...]
+
+ nid = GET_NODE_NUM(d->hwirq);
+ ret = get_mbigen_node_type(nid);
+ if (ret)
+ return 0;
>>>
>>> Care to explain what this does? It seems for some nodes you cann
On Thu, Jun 25, 2015 at 5:18 PM, Grygorii Strashko
wrote:
> The spinlock 'slock' is used now to protect pcf857x_irq() from itself
> which is unnecessary (especially after switching to use threaded
> IRQs). Hence, remove it and use mutex to protect device data in IRQ
> handler.
>
> Cc: Geert Uytte
Hi Dan,
>I hate these patches. I have told Markus to stop sending them but he
>has issues so now I only complain when they introduce a bug. There was
>one bug I have missed because it was a benchmark regression and I knew
>it was theoretically possible but I didn't know the code well enough to
>
This patchset includes 3 parts.
-
1st part:
Includes 13 upstream commits. They are recommended by Nigel Croxon
since he back ported this feature to rhel7. This 13 back ports
works for all ARCHs except of s390 since it always broke s390n kdump.
c2c1b08 fs/proc/v
On 16 July 2015 at 02:41, Rafael J. Wysocki wrote:
> On Wednesday, July 15, 2015 02:47:50 PM Alan Stern wrote:
>> On Wed, 15 Jul 2015, Tomeu Vizoso wrote:
>>
>> > If a suitable prepare callback cannot be found for a given device and
>> > its driver has no PM callbacks at all, assume that it can go
Resolves: bz1236437
https://bugzilla.redhat.com/show_bug.cgi?id=1236437
Brew build:
https://brewweb.devel.redhat.com/taskinfo?taskID=9499237
This is back ported from upstream. This commit relies on commit
"vmcore: prevent PT_NOTE p_memsz overflow during header update".
commit c4082f36fa3eeb5d4fa
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream. There are small format conflicts.
commit f2bdacdd597d8d05c3d5f5d36273084f7ef7e6f5
Author: HATAYAMA Daisuke
Date: Wed Jul 3 15:02:14 2013 -0700
vmcore: allocate buffer for ELF headers
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream directly.
commit c2c1b089b44b783bd50fae4bccaa6f367f92e492
Author: Zhang Yanfei
Date: Wed Feb 27 17:03:17 2013 -0800
fs/proc/vmcore.c: put if tests in the top of the while loop to redu
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream.
commit 0692dedcf64bf3cdcfb9f6a51c70d49c8db351d2
Author: Vitaly Kuznetsov
Date: Fri Aug 8 14:22:05 2014 -0700
fs/proc/vmcore.c:mmap_vmcore: skip non-ram pages reported by hypervisors
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream.
commit 23df79da8eb97757e39af7625665c1c5cecc610b
Author: Jan Willeke
Date: Wed Sep 11 14:24:52 2013 -0700
s390/vmcore: implement remap_oldmem_pfn_range for s390
Introduce the s39
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream.
commit 9cb218131de1c59dca9063b2efe876f053f316af
Author: Michael Holzheu
Date: Wed Sep 11 14:24:51 2013 -0700
vmcore: introduce remap_oldmem_pfn_range()
For zfcpdump we can't map
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream. It need be edited manually since
several irrelevant commits are not back ported.
commit 191a2fa0a8d2bbb64c98f9b1976fcb37ee5eae6b
Author: Michael Holzheu
Date: Thu Jul 18 12:18:27 2013 +02
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream.
commit 5a74953ff56aa870d6913ef4d81934f5c620c59d
Author: Michael Holzheu
Date: Thu Jul 18 12:17:57 2013 +0200
s390/kdump: Disable mmap for s390
The kdump mmap patch series (git c
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream. Conflict exists since
commit 73296bc611cee009f3be6b451e827d1425b9c10f is not back ported.
commit 83086978c63afd7c73e1c173c84aeab184c1e916
Author: HATAYAMA Daisuke
Date: Wed Jul 3 15:02:23
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream.
commit ef9e78fd2753213ea01d77f7a76a9cb6ad0f50a7
Author: HATAYAMA Daisuke
Date: Wed Jul 3 15:02:21 2013 -0700
vmcore: allow user process to remap ELF note segment buffer
Now ELF
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream.
commit 591ff71664e764a3806e341370f3c758cb2e7e3c
Author: HATAYAMA Daisuke
Date: Wed Jul 3 15:02:22 2013 -0700
vmcore: calculate vmcore file size from buffer size and total size of
vm
Resolves: bz1097904
https://bugzilla.redhat.com/show_bug.cgi?id=1097904
This is back ported from upstream.
commit 087350c9dcf1b38c597b31d7761f7366e2866e6b
Author: HATAYAMA Daisuke
Date: Wed Jul 3 15:02:19 2013 -0700
vmcore: allocate ELF note segment in the 2nd kernel vmalloc memory
T
1 - 100 of 994 matches
Mail list logo
