This patch allows building and compile-testing the i.MX
GPT driver also for ARM64. The delay_timer is only
supported on ARMv7.
Signed-off-by: Anson Huang
---
drivers/clocksource/Kconfig | 2 +-
drivers/clocksource/timer-imx-gpt.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
On Wed, Oct 17, 2018 at 07:03:30PM +0200, Vlastimil Babka wrote:
> On 10/17/18 3:58 PM, Mel Gorman wrote:
> > Again, as compaction is not guaranteed to find the pageblocks, it would
> > be important to consider whether a) that matters or b) find an
> > alternative way of keeping unmerged buddies
On Wed, 17 Oct 2018 16:59:51 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> Andy had some concerns about using regs_get_kernel_stack_nth() in a new
> function regs_get_kernel_argument() as if there's any error in the stack
> code, it could cause a bad memory access. To be on
* Thara Gopinath wrote:
> On 10/16/2018 03:33 AM, Ingo Molnar wrote:
> >
> > * Thara Gopinath wrote:
> >
> Regarding testing, basic build, boot and sanity testing have been
> performed on hikey960 mainline kernel with debian file system.
> Further aobench (An occlusion
/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is probe_err function introduced recently,
ie. if probe_err will be called with -EPROBE_DEFER
There is clock assignment in dtb for UART1, so setting
UART1 clock in clock driver is NOT necessary.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx7d.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index adb08f6..06c105d
On Thu 18-10-18 11:46:50, Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> > On (10/17/18 12:28), Michal Hocko wrote:
> > > > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > > > that patch is appropriate because that patch does not ratelimit
> > > >
> > > > "%s
On Wed, Oct 17, 2018 at 11:45:50AM +0200, David Hildenbrand wrote:
> Here you go ;)
>
> Reviewed-by: David Hildenbrand
thanks!
> I'm planning to look into the other patches as well, but I'll be busy
> with traveling and KVM forum the next 1.5 weeks.
No need to hurry, this can wait.
--
Oscar
Add tests to verify sealing memfds with the F_SEAL_FS_WRITE works as
expected.
Cc: dan...@google.com
Cc: minc...@kernel.org
Reviewed-by: John Stultz
Signed-off-by: Joel Fernandes (Google)
---
tools/testing/selftests/memfd/memfd_test.c | 74 ++
1 file changed, 74
Android uses ashmem for sharing memory regions. We are looking forward
to migrating all usecases of ashmem to memfd so that we can possibly
remove the ashmem driver in the future from staging while also
benefiting from using memfd and contributing to it. Note staging drivers
are also not ABI and
On Wed 17-10-18 12:59:18, David Rientjes wrote:
> On Wed, 17 Oct 2018, Michal Hocko wrote:
>
> > Do you know of any other userspace except your usecase? Is there
> > anything fundamental that would prevent a proper API adoption for you?
> >
>
> Yes, it would require us to go back in time and
Hi all,
News: I will not be doing linux-next releases next week. Unfortunately
this will probably be the first week of the merge window. :-(
Changes since 20181017:
The kvm tree gained a conflict against Linus' tree.
The kvm-arm tree gained a conflict against the kvm tree.
The scsi-mkp tree
Hi,
On 17.10.2018 19:30, Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 11:57:49AM +0300, Alexey Budankov wrote:
>> Hi,
>>
>> On 10.10.2018 13:45, Peter Zijlstra wrote:
>>
>>> -static bool perf_rotate_context(struct perf_cpu_context *cpuctx)
>>> +/*
>>> + * XXX somewhat completely buggered;
On Thu, Oct 18, 2018 at 8:48 AM Ingo Molnar wrote:
>
>
> * Thara Gopinath wrote:
>
> > On 10/16/2018 03:33 AM, Ingo Molnar wrote:
> > >
> > > * Thara Gopinath wrote:
> > >
> > Regarding testing, basic build, boot and sanity testing have been
> > performed on hikey960 mainline kernel
On Wed, Oct 17, 2018 at 11:59 PM, Joel Fernandes (Google)
wrote:
> Add tests to verify sealing memfds with the F_SEAL_FS_WRITE works as
> expected.
I messed the commit message it should be "F_SEAL_FUTURE_WRITE", but
otherwise this
patch itself is good and I'll resend it with the corrected commit
On 10/18/18 12:21 AM, Dave Hansen wrote:
> On 10/17/2018 04:32 AM, Pavel Machek wrote:
>>> Well, that depends. Do you care about PROT_NONE attacks as well? If not
>>> then no-swap would help you. But even then no-swap is rather theoretical
>>> attack on a physical host unless you allow an
On Wed, Oct 17, 2018 at 12:30:28PM -0600, Shuah Khan wrote:
> On 10/16/2018 11:03 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.15 release.
> > There are 135 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Wed, Oct 17, 2018 at 12:19:39PM -0700, Guenter Roeck wrote:
> On Tue, Oct 16, 2018 at 07:08:57PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.134 release.
> > There are 71 patches in this series, all will be posted as a response
> > to this one.
On Thu, Oct 18, 2018 at 07:43:02AM +0100, Jon Hunter wrote:
>
> On 16/10/2018 18:04, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.77 release.
> > There are 109 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Wed, Oct 17, 2018 at 5:49 PM, Dan Williams wrote:
> On Wed, Oct 17, 2018 at 5:29 PM Kees Cook wrote:
>>
>> When ramoops reserved a memory region in the kernel, it had an unhelpful
>> label of "persistent_memory". When reading /proc/iomem, it would be
>> repeated many times, did not hint that
On Wed, Oct 17, 2018 at 10:22 PM, Andreas Dilger wrote:
> On Oct 17, 2018, at 1:04 PM, Miklos Szeredi wrote:
>> So what's the point exactly?
>
> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
> to mask off flags that it doesn't currently understand.
And even there
On Thu, Oct 18, 2018 at 10:11 AM Suganath Prabu Subramani
wrote:
>
>
>
> On Wed, Oct 17, 2018 at 2:02 PM Andy Shevchenko
> wrote:
>>
>> On Wed, Oct 17, 2018 at 8:59 AM Suganath Prabu
>> wrote:
>> >
>> > This is to fix Sync cache and start stop command
>> > failures with DID_NO_CONNECT during
On 17/10/2018 10:47 PM, Nishad Kamdar wrote:
Use the gpiod interface for rdwr_pin, convert_pin and busy_pin
instead of the deprecated old non-descriptor interface.
Signed-off-by: Nishad Kamdar
---
Changes in v2:
- Correct the error messages as pin number being showed
has now been
On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote:
>
> On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the
> kernel. The P-Unit has a semaphore for the PMIC bus which we can take to
> block it from accessing the shared bus while the kernel wants to access it.
>
> Currently we
On Wed, Oct 17, 2018 at 1:24 PM Vitaly Kuznetsov wrote:
>
> It is possible to observe hung_task complaints when system goes to
> suspend-to-idle state:
>
> # echo freeze > /sys/power/state
>
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.001 seconds) done.
>
On Wed, Oct 17, 2018 at 03:49:39PM -0400, Steven Rostedt wrote:
>
> Linus (aka Greg),
>
> This fixes two bugs:
>
> - Fix size mismatch of tracepoint array
>
> - Have preemptirq test module use same clock source of the selftest
Now pulled, thanks.
greg k-h
On Thu, Oct 18, 2018 at 10:33 AM Rafael J. Wysocki wrote:
>
> On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote:
> >
> > On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the
> > kernel. The P-Unit has a semaphore for the PMIC bus which we can take to
> > block it from accessing
On Sun, Sep 23, 2018 at 04:45:10PM +0200, Hans de Goede wrote:
> Now that most of the special Bay- / Cherry-Trail bus lock handling has
> been moved to the iosf_mbi code we can simplify the remaining code a bit.
>
> Signed-off-by: Hans de Goede
Acked-by: Wolfram Sang
signature.asc
On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote:
> * Andreas Dilger:
>
>>> So what's the point exactly?
>>
>> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
>> to mask off flags that it doesn't currently understand. It doesn't make
>> much sense for
* Miklos Szeredi:
> On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote:
>> * Andreas Dilger:
>>
So what's the point exactly?
>>>
>>> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
>>> to mask off flags that it doesn't currently understand. It doesn't make
On 10/18/2018 09:28 AM, Phil Reid wrote:
[...]
>> + chip->rdwr_pin = devm_gpiod_get(_dev->dev, "rdwr", GPIOD_IN);
>> + if (IS_ERR(chip->rdwr_pin)) {
>> + ret = PTR_ERR(chip->rdwr_pin);
>> + dev_err(_dev->dev, "Failed to request rdwr GPIO: %d\n",
>> + ret);
>>
On Thu 18-10-18 01:15:13, Amir Goldstein wrote:
> On Wed, Oct 17, 2018 at 10:12 PM Miklos Szeredi wrote:
>
> > >> - STATX_ALL definition is unclear, can this change, or is it fixed?
> > >> If it's the former, than that's a backward compatibility nightmare.
> > >> If it's the latter, then what's
On Thu, Oct 18, 2018 at 9:39 AM, Florian Weimer wrote:
> * Miklos Szeredi:
>
>> On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote:
>>> * Andreas Dilger:
>>>
> So what's the point exactly?
Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
to mask
On Mon, Oct 15, 2018 at 5:09 PM Alexander Duyck
wrote:
>
> This patch is meant to try and consolidate all of the locking and unlocking
> of both the parent and device when attaching or removing a driver from a
> given device.
>
> To do that I first consolidated the lock pattern into two functions
* Jan Kara:
> On Thu 18-10-18 01:15:13, Amir Goldstein wrote:
>> FYI, I identified a similar anti-pattern in fanotify UAPI when I wanted to
>> add new flags and did not want to change the UAPI _ALL_ constants.
>> This is how we plan to solve it:
>>
From: Shun-Chih Yu
MediaTek Command-Queue DMA controller (CQDMA) on MT6765 SoC is dedicated
to memory-to-memory transfer through queue based descriptor management.
There are only 3 physical channels inside CQDMA, while the driver is
extended to support 32 virtual channels for multiple dma users
Changes since v2:
- fix build warning for kernel with DMA address in 32-bit
Changes since v1:
- remove unused macros, typos
- leverage ASYNC_TX_ENABLE_CHANNEL_SWITCH to maintain DMA descriptor list
Shun-Chih Yu (2):
dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller
From: Shun-Chih Yu
Document the devicetree bindings for MediaTek Command-Queue DMA controller
which could be found on MT6765 SoC or other similar Mediatek SoCs.
Signed-off-by: Shun-Chih Yu
Reviewed-by: Rob Herring
---
.../devicetree/bindings/dma/mtk-cqdma.txt | 31
* Rafael J. Wysocki wrote:
> > The only long term maintainable solution is to move all high level
> > cpufreq logic and policy handling code into kernel/sched/cpufreq*.c,
> > which has been done to a fair degree already in the past ~2 years - but
> > it's unclear to me to what extent this is
On 10/17/2018 9:41 PM, Doug Anderson wrote:
Hi,
On Tue, Oct 16, 2018 at 11:28 PM Vivek Gautam
wrote:
Hi Doug,
On 10/16/2018 10:29 PM, Doug Anderson wrote:
Hi,
On Mon, Oct 15, 2018 at 10:51 PM Vivek Gautam
wrote:
P.S.: While you are at it, can you please move 'ufs-qcom.txt'
to
On Wed, Oct 17, 2018 at 06:22:48PM -0700, Andy Lutomirski wrote:
>
> > On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
> >
> > It is sometimes beneficial to prevent preemption for very few
> > instructions, or prevent preemption for some instructions that precede
> > a branch (this latter case
On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
[...]
> and let's hear from MM people what they can suggest.
>
> Michal, Andrew, Johannes, any thoughts?
I have already stated my position. Let's not reinvent the wheel and use
the standard printk throttling. If there are cases where oom
Hi Balakrishna,
> This patch will prevent error messages splashing on console.
>
> [ 78.426697] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet
> for unknown connection handle 3804
> [ 78.436682] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet
> for unknown
Hi Balakrishna,
> This patch will prevent error messages splashing on console.
> [ 78.426697] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL
> packet for unknown connection handle 3804
> [ 78.436682] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL
Some SOCs in the i.MX6 family have a USB host controller that is
only capable of the HSIC interface and has no on-board PHY.
To be able to use these controllers, we need to add "usb-nop-xceiv"
dummy PHYs.
Signed-off-by: Frieder Schrempf
---
arch/arm/boot/dts/imx6qdl.dtsi | 14 ++
On 10/17/2018 06:24 PM, Thara Gopinath wrote:
> On 10/16/2018 01:11 PM, Vincent Guittot wrote:
>> Hi Lukasz,
>>
>> On Thu, 11 Oct 2018 at 13:10, Lukasz Luba wrote:
>>>
>>>
>>>
>>> On 10/10/2018 07:30 PM, Thara Gopinath wrote:
Hello Lukasz,
On 10/10/2018 11:35 AM, Lukasz Luba
On 10/18/2018 10:36 AM, Andy Shevchenko wrote:
On Thu, Oct 18, 2018 at 10:33 AM Rafael J. Wysocki wrote:
On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote:
On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the
kernel. The P-Unit has a semaphore for the PMIC bus which we
Cast *max_num_sg* to u64 in order to give the compiler complete
information about the proper arithmetic to use.
Notice that such variable is used in a context that expects an
expression of type u64 (64 bits, unsigned) and the following
expression is currently being evaluated using 32-bit
On Mon, Oct 15, 2018 at 05:15:47PM +0300, Jarkko Nikula wrote:
> On 10/11/2018 05:29 PM, Hans de Goede wrote:
> > Now that most of the special Bay- / Cherry-Trail bus lock handling has
> > been moved to the iosf_mbi code we can simplify the remaining code a bit.
> >
> > Signed-off-by: Hans de
I just noticed this in review. The get_register_interruptible() should
return zero on success but it instead returns the value that it read.
I looked at all the places that called this directly and they check for
negatives and treat greater than or equal to zero as success. This
function is
On Wed, Oct 17, 2018 at 10:15 PM Rob Herring wrote:
>
> On Fri, Oct 12, 2018 at 04:24:11PM +0200, Benjamin Tissoires wrote:
> > Some new touchpads IC are connected through PS/2 and I2C. On some of these
> > new IC, the I2C part doesn't have all of the information available.
> > We need to be able
Hi Vincent,
On 10/16/2018 07:11 PM, Vincent Guittot wrote:
> Hi Lukasz,
>
> On Thu, 11 Oct 2018 at 13:10, Lukasz Luba wrote:
>>
>>
>>
>> On 10/10/2018 07:30 PM, Thara Gopinath wrote:
>>> Hello Lukasz,
>>>
>>> On 10/10/2018 11:35 AM, Lukasz Luba wrote:
Hi Thara,
I have run it on
On 10/16/18 6:49 PM, Doug Ledford wrote:
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Gustavo A. R. Silva
>
> Thanks, applied to for-rc.
>
Thanks, Doug.
--
Gustavo
On (10/18/18 09:56), Michal Hocko wrote:
> On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
> [...]
> > and let's hear from MM people what they can suggest.
> >
> > Michal, Andrew, Johannes, any thoughts?
>
> I have already stated my position. Let's not reinvent the wheel and use
> the
On Thu, Oct 18, 2018 at 9:50 AM Ingo Molnar wrote:
>
>
> * Rafael J. Wysocki wrote:
>
> > > The only long term maintainable solution is to move all high level
> > > cpufreq logic and policy handling code into kernel/sched/cpufreq*.c,
> > > which has been done to a fair degree already in the past
On 10/18/18 8:48 AM, Aaron Lu wrote:
> On Wed, Oct 17, 2018 at 07:03:30PM +0200, Vlastimil Babka wrote:
>> On 10/17/18 3:58 PM, Mel Gorman wrote:
>>> Again, as compaction is not guaranteed to find the pageblocks, it would
>>> be important to consider whether a) that matters or b) find an
>>>
On 2018/10/13 下午6:19, Jonathan Cameron wrote:
On Fri, 12 Oct 2018 15:35:36 +0800
Song Qiang wrote:
PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with a MagI2C
interface.
Following functions are available:
-
From: Arnd Bergmann
When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():
arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array
On 16/10/18 16:03, Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 03:24:06PM +0200, Thomas Gleixner wrote:
> > It does reproduce here but with a kworker stall. Looking at the reproducer:
> >
> > *(uint32_t*)0x2000 = 0;
> > *(uint32_t*)0x2004 = 6;
> > *(uint64_t*)0x2008 = 0;
> >
On Thu, Oct 18, 2018 at 4:49 AM Guo Ren wrote:
>
> On Wed, Oct 17, 2018 at 05:18:49PM +0200, Arnd Bergmann wrote:
> > On Tue, Oct 16, 2018 at 5:02 AM Guo Ren wrote:
> > >
> > > This patch adds ELF definition and module relocate codes.
> > >
> > > Signed-off-by: Guo Ren
> > > Cc: Arnd Bergmann
On Thu, Oct 18, 2018 at 5:41 AM Guo Ren wrote:
>
> On Wed, Oct 17, 2018 at 05:44:17PM +0200, Arnd Bergmann wrote:
> > On Tue, Oct 16, 2018 at 5:33 AM Guo Ren wrote:
> > >
> > > Support dword access for get_user_size and redesign put_user_size with
> > > the same style of get_user_size. It's Ok
Hi,
On 18-10-18 09:29, Rafael J. Wysocki wrote:
On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote:
On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the
kernel. The P-Unit has a semaphore for the PMIC bus which we can take to
block it from accessing the shared bus while the
On Thu, Oct 18, 2018 at 6:11 AM Guo Ren wrote:
>
> On Wed, Oct 17, 2018 at 05:58:46PM +0200, Arnd Bergmann wrote:
> > On Tue, Oct 16, 2018 at 4:58 AM Guo Ren wrote:
> > >
> > > This is the 9th version patchset to add the Linux kernel port for
> > > C-SKY(csky) based on linux-4.19-rc3.
> > >
> >
Hi,
On 18-10-18 10:10, Benjamin Tissoires wrote:
On Wed, Oct 17, 2018 at 10:15 PM Rob Herring wrote:
On Fri, Oct 12, 2018 at 04:24:11PM +0200, Benjamin Tissoires wrote:
Some new touchpads IC are connected through PS/2 and I2C. On some of these
new IC, the I2C part doesn't have all of the
On Thu, Oct 18, 2018 at 8:26 AM, Amir Goldstein wrote:
> Can someone tell me what the expected behavior of a nested
> mutex_lock_interruptible(); ?
>
> Why does the reproducer only warn and not really deadlock.
> It is because that is considered the lesser evil?
> and obviously, then inner
Hi Joe,
On 10/18/2018 04:42 AM, Joe Perches wrote:
> On Wed, 2018-10-17 at 11:49 +0300, Stanimir Varbanov wrote:
>> On 10/08/2018 04:32 PM, Vikash Garodia wrote:
>>> Add routine to reset the ARM9 and brings it out of reset. Also
>>> abstract the Venus CPU state handling with a new function. This
On Thursday, October 18, 2018 10:34:57 AM CEST Hans de Goede wrote:
> Hi,
>
> On 18-10-18 09:29, Rafael J. Wysocki wrote:
> > On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote:
> >>
> >> On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the
> >> kernel. The P-Unit has a
On Thu, Oct 18, 2018 at 10:39 AM Hans de Goede wrote:
>
> Hi,
>
> On 18-10-18 10:10, Benjamin Tissoires wrote:
> > On Wed, Oct 17, 2018 at 10:15 PM Rob Herring wrote:
> >>
> >> On Fri, Oct 12, 2018 at 04:24:11PM +0200, Benjamin Tissoires wrote:
> >>> Some new touchpads IC are connected through
The document for how to add NDS32 PMU
in devicetree.
Signed-off-by: Nickhu
---
Documentation/devicetree/bindings/nds32/pmu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nds32/pmu.txt
diff --git
These two commit are perf supporting for nds32.
There are three perfomance counters in nds32, and
each of them can counts different events. You can
use 'perf list' to show the available events that
can be used.
Nickhu (5):
nds32: Perf porting
nds32: Fix bug in bitfield.h
nds32: Add perf
There two bitfield bug for perfomance counter
in bitfield.h:
PFM_CTL_offSEL1 21 --> 16
PFM_CTL_offSEL2 27 --> 22
This commit fix it.
Signed-off-by: Nickhu
---
arch/nds32/include/asm/bitfield.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
When there are multiple events map to the same counter, the counter
counts inaccurately. This is because each counter only counts one event
in the same time.
So when there are multiple events map to same counter, they have to take
turns in each context.
There are two solution:
1. Print the error
This is the commit that porting the perf for nds32.
Raw event:
The raw events start with 'r'.
Usage:
perf stat -e rXYZ ./app
X: the index of performance counter.
YZ: the index(convert to hexdecimal) of
The perf call-graph option can trace the callchain
between functions. This commit add the perf callchain
for nds32. There are kerenl callchain and user callchain.
The kerenl callchain can trace the function in kernel
space. There are two type for user callchain. One for the
'optimize for size'
HI,
On 18-10-18 10:38, Rafael J. Wysocki wrote:
On Thursday, October 18, 2018 10:34:57 AM CEST Hans de Goede wrote:
Hi,
On 18-10-18 09:29, Rafael J. Wysocki wrote:
On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote:
On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the
Hi,
On 18-10-18 10:44, Benjamin Tissoires wrote:
On Thu, Oct 18, 2018 at 10:39 AM Hans de Goede wrote:
Hi,
On 18-10-18 10:10, Benjamin Tissoires wrote:
On Wed, Oct 17, 2018 at 10:15 PM Rob Herring wrote:
On Fri, Oct 12, 2018 at 04:24:11PM +0200, Benjamin Tissoires wrote:
Some new
This patch set fixes some issues when setting one RTC alarm.
Baolin Wang (5):
rtc: sc27xx: Set wakeup capability before registering rtc device
rtc: sc27xx: Clear SPG value update interrupt status
rtc: sc27xx: Remove interrupts disable and clear in probe()
rtc: sc27xx: Add check to see if
The RTC interrupt enable register is not put in always-power-on region
supplied by VDDRTC, so we should check if we need enable the alarm
interrupt when system booting.
Signed-off-by: Baolin Wang
---
drivers/rtc/rtc-sc27xx.c | 33 +
1 file changed, 33
We should clear the SPG value update interrupt status once the SPG value
is updated successfully, in case incorrect status validation for next time.
Signed-off-by: Baolin Wang
---
drivers/rtc/rtc-sc27xx.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
When registering one RTC device, it will check to see if there is an
alarm already set in RTC hardware by reading RTC alarm, at this time
we should always read the normal alarm put in always-on region by
checking the rtc->registered flag.
Signed-off-by: Baolin Wang
---
drivers/rtc/rtc-sc27xx.c
Set wakeup capability before registering rtc device, in case the alarmtimer
can find one available rtc device.
Signed-off-by: Baolin Wang
---
drivers/rtc/rtc-sc27xx.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-sc27xx.c b/drivers/rtc/rtc-sc27xx.c
When registering one rtc device, it will check to see if there is an
alarm already set in rtc hardware by issuing __rtc_read_alarm(). So
we should not disable the RTC interrupts and clear the interrupts
status in probe() function.
Signed-off-by: Baolin Wang
---
drivers/rtc/rtc-sc27xx.c | 20
Hi Yang,
On 18/10/18 04:41, Yang Yingliang wrote:
> Hi, Marc
>
> On 2018/10/18 0:30, Marc Zyngier wrote:
>> On 16/10/18 10:15, Yang Yingliang wrote:
>>> Now with
>>> 5052875 ("irqchip/gic-v3: Add support for Message Based Interrupts as an
>>> MSI controller"),
>>> we can support MBIGEN to
Hi Icenowy,
Thank you for the patch.
On Thursday, 18 October 2018 10:33:27 EEST Icenowy Zheng wrote:
> From: Chen-Yu Tsai
>
> The panels shipped with Allwinner devices are very "generic", i.e.
> they do not have model numbers or reliable sources of information
> for the timings (that we know
The patches are about unaligned access handler. We fix some
bugs in unaligned access handler and add some kernel configs
for unaligned access handler. Then we add the kernel unaligned
access handled by software in handler.
Nickhu (3):
nds32: Fix instruction simulator bug for unaligned access
When the kernel configs of ftrace and frame pointer options are
choosed, the compiler option of kernel will incompatible.
Error message:
nds32le-linux-gcc: error: -pg and -fomit-frame-pointer are
incompatible
Signed-off-by: Nickhu
Signed-off-by: Zong Li
---
On Thu, Oct 18, 2018 at 02:16:47PM +0800, Teng Fei Fan wrote:
> This patch adds support for cacheinfo on 32bit ARMv8 platform.
> Add support for detecting cpu cache information cpu cache information
> via sysfs for 32bit armv8 platform. And export to sysfs then userspace
> can get from
According to my understanding, this config will optimize the code generate.
When there is an unaligned access happened, the load word instruction
still can be used if there is unaligned access support or the load byte
instruction is used. So this config need unaligned access support.
The error message:
=
util/symbol-elf.c:46:12: error: static declaration of 'elf_getphdrnum'
follows non-static declaration
static int elf_getphdrnum(Elf *elf, size_t *dst)
^~
In file included from
Fix gcc 8.0 compiler option incompatible When the kernel configs of
ftrace and frame pointer options are choosed.
Nickhu (1):
nds32: Fix gcc 8.0 compiler option incompatible.
arch/nds32/mm/Makefile | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--
2.17.0
Fix perf failed when compile with libelf.
Nickhu (1):
Perf: Compile failed when compile with libelf.
tools/perf/util/symbol-elf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.17.0
When emulating the 16 bits instructions, the mapping of general
purpose registers is not the same as 32 bits instructions.
Example:
'LWI450 r16, [r15]' 16-bit instruction will be decoded as
'1011010110001110', the target register field is decode as index=12.
As my colleague has encountered kernel panic when unaligned access
in kernel space. Here is the situation, the structure 'TP_STRUCT__entry':
TP_STRUCT__entry(
__field(u32,tb_id )
__field(int,err )
On Fri, Mar 16, 2018 at 12:26 AM Byungchul Park wrote:
>
> On 3/15/2018 9:41 PM, Peter Zijlstra wrote:
> > On Thu, Mar 15, 2018 at 11:31:57AM +0100, Daniel Vetter wrote:
> >> Is there any progress on getting cross-release enabled again?
> >
> > Not yet, I'm still fighting the meltdown/spectre
On Thu, Oct 18, 2018 at 10:34:00AM +0200, Arnd Bergmann wrote:
> On Thu, Oct 18, 2018 at 5:41 AM Guo Ren wrote:
> >
> > On Wed, Oct 17, 2018 at 05:44:17PM +0200, Arnd Bergmann wrote:
> > > On Tue, Oct 16, 2018 at 5:33 AM Guo Ren wrote:
> > > >
> > > > Support dword access for get_user_size and
From: pascal paillet
The stpmic1 pmic is able to manage an onkey button. It can be configured
to shut-down the power supplies on a long key-press with an adjustable
duration.
Signed-off-by: pascal paillet
Reviewed-by: Rob Herring
---
changes in v4:
* remove interrupt-parent description
*
From: pascal paillet
The stpmic1 PMIC embeds several regulators and switches with
different capabilities.
Signed-off-by: pascal paillet
---
changes in v4: nothing
drivers/regulator/Kconfig | 12 +
drivers/regulator/Makefile| 1 +
From: pascal paillet
stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10
regulators , 3 switches, a watchdog and an input for a power on key.
Signed-off-by: pascal paillet
---
changes in v4:
* remove interrupt-parent description
* pmic1@33 renamed to pmic@33
* fix indentation
From: pascal paillet
stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10
regulators , 3 switches, a watchdog and an input for a power on key.
Signed-off-by: pascal paillet
---
changes in v4:
* rename PONKEY_PU_ACTIVE to PONKEY_PU_INACTIVE
drivers/mfd/Kconfig | 13 ++
From: pascal paillet
The stpmic1 PMIC embeds a watchdog which is disabled by default. As soon
as the watchdog is started, it must be refreshed periodically otherwise
the PMIC goes off.
Signed-off-by: pascal paillet
---
changes in v4:
* fix stop watchdog function
* Kconfig: fix grammar issue
801 - 900 of 1550 matches
Mail list logo
