The pull request you sent on Sat, 17 Nov 2018 11:55:18 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> perf-urgent-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b53e27f618b58d50db72375eb8e1b6ddcef7cdb5
Thank you!
--
Deet-doot-dot, I
BLSP1 UART2 is used as debug uart on the EVB development board, define
pinmux state for the UART in the platform dtsi and pinconf state for it
in the board dts.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 14 ++
arch/arm64/boot/dts/qcom/qcs404.dtsi
The pull request you sent on Sat, 17 Nov 2018 11:57:57 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> sched-urgent-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/03582f338e39ed8f8e8451ef1ef04f060d785a87
Thank you!
--
Deet-doot-dot, I
Hello Thierry,
On Fri, Nov 16, 2018 at 01:24:45PM +0100, Thierry Reding wrote:
> On Fri, Nov 16, 2018 at 11:39:29AM +0100, Uwe Kleine-König wrote:
> > On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote:
> > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:
> > > > On
On Sun, Nov 18, 2018 at 11:44:19AM -0800, Daniel Colascione wrote:
> On Sun, Nov 18, 2018 at 11:05 AM, Aleksa Sarai wrote:
> > On 2018-11-18, Daniel Colascione wrote:
> >> > Here's my point: if we're really going to make a new API to manipulate
> >> > processes by their fd, I think we should have
Since v2.6.22 or so there has been reports [1] about OMAP MMC being
broken on OMAP15XX based hardware (OMAP5912 and OMAP310). The breakage
seems to have been caused by commit 46a6730e3ff9 ("mmc-omap: Fix
omap to use MMC_POWER_ON") that changed clock enabling to be done
on MMC_POWER_ON. This can hap
Hi Aaro,
CC Jarkko (from his last patch)
On Tue, Nov 6, 2018 at 11:29 PM Aaro Koskinen wrote:
> Jarkko's e-mail address hasn't worked for a long time. We still want
> to keep this driver working as it is critical for some of the OMAP boards.
> I use and test this driver frequently, so change mys
On Sun, Nov 18, 2018 at 3:55 PM Ard Biesheuvel
wrote:
>
> On Sat, 17 Nov 2018 at 23:47, Y Song wrote:
> >
> > On Sat, Nov 17, 2018 at 6:58 PM Ard Biesheuvel
> > wrote:
> > >
> > > All arch overrides of the __weak bpf_jit_free() amount to the same
> > > thing: the allocated memory was never mappe
On Sun, Nov 18, 2018 at 12:15 PM, Christian Brauner
wrote:
>> That is, I'm proposing an API that looks like this:
>>
>> int process_kill(int procfs_dfd, int signo, const union sigval value)
>
> I've started a second tree with process_signal(int procpid_dfd, int sig)
Thanks.
> instead of an ioctl
On Sun, Nov 18, 2018 at 9:21 PM Geert Uytterhoeven wrote:
> CC Jarkko (from his last patch)
Dropped. Apparently that address bounces, too.
> On Tue, Nov 6, 2018 at 11:29 PM Aaro Koskinen wrote:
> > Jarkko's e-mail address hasn't worked for a long time. We still want
> > to keep this driver work
> On Nov 18, 2018, at 12:44 PM, Daniel Colascione wrote:
>
>
> That is, I'm proposing an API that looks like this:
>
> int process_kill(int procfs_dfd, int signo, const union sigval value)
>
> If, later, process_kill were to *also* accept process-capability FDs,
> nothing would break.
Exc
On Sun, Nov 18, 2018 at 12:28 PM, Andy Lutomirski wrote:
>> That is, I'm proposing an API that looks like this:
>>
>> int process_kill(int procfs_dfd, int signo, const union sigval value)
>>
>> If, later, process_kill were to *also* accept process-capability FDs,
>> nothing would break.
>
> Except
This was marked for stable, and honestly, nowhere in the discussion
did I see any mention of just *how* bad the performance impact of this
was.
When performance goes down by 50% on some loads, people need to start
asking themselves whether it was worth it. It's apparently better to
just disable SM
On Sun, Nov 18, 2018 at 01:28:41PM -0700, Andy Lutomirski wrote:
>
>
> > On Nov 18, 2018, at 12:44 PM, Daniel Colascione wrote:
> >
>
> >
> > That is, I'm proposing an API that looks like this:
> >
> > int process_kill(int procfs_dfd, int signo, const union sigval value)
> >
> > If, later,
Why do we need to add new routines for these conditions. Why can't handle these
strings in array. For example you can define an array of strings for passed
unexpectedly etc. and the pass the string to appropriate ksft_* interface
instead of adding of these routines. Also it is hard to review th
Hi Schrempf,
Schrempf Frieder wrote on Thu, 8 Nov 2018
08:32:11 +:
> Add minimal support for the Toshiba TC58CVG2S0H SPI NAND chip.
>
> Signed-off-by: Frieder Schrempf
> ---
With "mtd: spinand:" as prefix, applied to nand/next.
Thanks,
Miquèl
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international
cooparation. I got your contact from a certain email database from your country
while i was looking for someone to handle a huge financial transaction for me
in confidence. Can you receive and invest on behalf of
On Sun, Nov 18, 2018 at 12:43 PM, Christian Brauner
wrote:
> On Sun, Nov 18, 2018 at 01:28:41PM -0700, Andy Lutomirski wrote:
>>
>>
>> > On Nov 18, 2018, at 12:44 PM, Daniel Colascione wrote:
>> >
>>
>> >
>> > That is, I'm proposing an API that looks like this:
>> >
>> > int process_kill(int proc
On Sun, Nov 18, 2018 at 12:54:10PM -0800, Daniel Colascione wrote:
> On Sun, Nov 18, 2018 at 12:43 PM, Christian Brauner
> wrote:
> > On Sun, Nov 18, 2018 at 01:28:41PM -0700, Andy Lutomirski wrote:
> >>
> >>
> >> > On Nov 18, 2018, at 12:44 PM, Daniel Colascione
> >> > wrote:
> >> >
> >>
> >> >
On Sun, Nov 18, 2018 at 10:23:36PM +0100, Christian Brauner wrote:
> On Sun, Nov 18, 2018 at 12:54:10PM -0800, Daniel Colascione wrote:
> > On Sun, Nov 18, 2018 at 12:43 PM, Christian Brauner
> > wrote:
> > > On Sun, Nov 18, 2018 at 01:28:41PM -0700, Andy Lutomirski wrote:
> > >>
> > >>
> > >> > O
On Sun, Nov 18, 2018 at 4:36 AM Tomer Maimon wrote:
>
> Fix uninitialized 'val' warning receive function, send function
> has been modify to be aligned with the receive function.
>
> Signed-off-by: Tomer Maimon
> ---
> drivers/spi/spi-npcm-pspi.c | 12 ++--
> 1 file changed, 6 insertions
On Sun, 18 Nov 2018, Linus Torvalds wrote:
> This was marked for stable, and honestly, nowhere in the discussion
> did I see any mention of just *how* bad the performance impact of this
> was.
Frankly, I ran some benchmarks myself, and am seeing very, very
varying/noisy results, which were rathe
Redefine binding for regulator-coupled-max-spread property in a way that
max-spread values are defined per regulator couple instead of defining
single max-spread for the whole group of coupled regulators.
With that change the following regulators coupling configuration will be
possible:
regA: reg
Hi,
This is a follow up to [0].
What's changed in v2:
- The "Use ww_mutex for regulators locking" patch compiles now for the
drivers that are touching "rdev's" mutex, in a result regulator_[un]lock()
functions are public now.
- Added new patch to the series ("Keep regulators-list lo
Wait/wound mutex shall be used in order to avoid lockups on locking of
coupled regulators.
Signed-off-by: Dmitry Osipenko
Suggested-by: Lucas Stach
---
drivers/regulator/core.c | 403 +++---
drivers/regulator/da9210-regulator.c | 4 +-
drivers/regulator/stpmi
It's unlikely that regulators may disappear/appear while regulators
debug-summary is being prepared, but let's be consistent and avoid that
situation.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/r
Check whether supply regulator is the couple to avoid infinite recursion
during of locking.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
ind
Add w2sg0004 compatible string since devices without wakeup
pins are now supported.
Signed-off-by: Andreas Kemnade
---
Documentation/devicetree/bindings/gnss/sirfstar.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gnss/sirfstar.txt
b/Documentation/devi
Devices might have a separate lna between antenna output of the gps
chip and the antenna which might have a separate supply
Signed-off-by: Andreas Kemnade
---
drivers/gnss/sirf.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gnss/sirf.c b/drivers/gnss/sirf.c
index
Add lna-supply property.
Signed-off-by: Andreas Kemnade
---
Documentation/devicetree/bindings/gnss/sirfstar.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gnss/sirfstar.txt
b/Documentation/devicetree/bindings/gnss/sirfstar.txt
index 1be7597ae884..96147
Some Wi2Wi devices do not have a wakeup output, so device state can
only be indirectly detected by looking whether there is communitcation
over the serial lines.
Additionally it checks for the initial state of the device during
probing to ensure it is off.
Timeout values need to be increased, becau
Here is another chapter of the story to get gta04 gnss power
management into the mainline kernel.
There is a w2sg0004 without wakeup line in there, so power state
can only be determined indirectly by looking at the serial data lines.
Then there as also an lna which needs to be powered for real gps
The api forbids writing data there otherwise. Prepare for the
serdev_open()/close() being a part of runtime pm.
Signed-off-by: Andreas Kemnade
---
drivers/gnss/sirf.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gnss/sirf.c b/drivers/gnss/sirf.c
in
On Sun, Nov 18, 2018 at 1:49 PM Jiri Kosina wrote:
>
> > So why do that STIBP slow-down by default when the people who *really*
> > care already disabled SMT?
>
> BTW for them, there is no impact at all.
Right. People who really care about security and are anal about it do
not see *any* advantage
I am in the military unit here in Afghanistan, we have some amount of funds
that we want to move out of the country. My partners and I need a good partner
someone we can trust. It is risk free and legal. Reply to this email:
hornbeckmajordennis...@gmail.com
Regards,Major Dennis Hornbeck.
On Sun, Nov 18, 2018 at 10:49:44PM +0100, Jiri Kosina wrote:
> odds are that people
> who don't care about spectrev2 already have 'nospectre_v2' on their
> command-line, so they are fine as well.
FWIW in our appliances, we never modify the boot loader's cmdline
in field, we only provide new kern
On 30.08.2018 21:54, Dmitry Osipenko wrote:
> Hello,
>
> This patch series fixes couple bugs in the memory self-refresh code.
> The EMC / MC state is properly restored after patches being applied,
> please review.
>
> Dmitry Osipenko (4):
> ARM: tegra: Fix missed EMC registers latching on resum
The only unusual thing last week was my travel - not any code issues.
That caused a few pulls to be delayed by a day or two, but nothing
else.
And now I'm back home, and 4.20-rc3 is out there.
The changes in rc3 are pretty tiny, which means that the statistics
look slightly different from the uys
The current value of ODEBUG_POOL_SIZE is not big enough for systems with
large number of CPUs with timer or/and workqueue objects because during
the early boot, timer objects needs the size equals to
No. CPUs x 2 (worker pool)
start_kernel
workqueue_init_early
init_worker_pool
init_ti
On Sun, 18 Nov 2018, Linus Torvalds wrote:
> > So, I think it's as theoretical as any other spectrev2 (only with the
> > extra "HT" condition added on top).
>
> What? No.
>
> It's *way* more theoretical than something like meltdown, which could
> be trivially used to get data from another protec
Aaro,
On Sun, Nov 18, 2018 at 10:19:19PM +0200, Aaro Koskinen wrote:
> Since v2.6.22 or so there has been reports [1] about OMAP MMC being
> broken on OMAP15XX based hardware (OMAP5912 and OMAP310). The breakage
> seems to have been caused by commit 46a6730e3ff9 ("mmc-omap: Fix
> omap to use MMC_P
On Sun, Nov 18, 2018 at 2:17 PM Jiri Kosina wrote:
> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
> given the existence of that?
I don't think the code needs to be reverted, but the *behavior* of
just unconditionally enabling STIBP needs to be reverted.
Because it was
On Sun, Nov 18, 2018 at 2:19 PM Jiri Kosina wrote:
> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
> given the existence of that? I think that if Tim's fixup makes it through
> (it's currently missing SECCOMP handling, but that is trivial to add on
> top), it might be th
On 11/18/2018 02:17 PM, Jiri Kosina wrote:
> On Sun, 18 Nov 2018, Linus Torvalds wrote:
>
>>> So, I think it's as theoretical as any other spectrev2 (only with the
>>> extra "HT" condition added on top).
>>
>> What? No.
>>
>> It's *way* more theoretical than something like meltdown, which could
>>
> On Nov 18, 2018, at 2:17 PM, Jiri Kosina wrote:
>
> It's probably not just browsers, but anything running JITed sandboxed
> code. So the most straightforward way might be the prctl() aproach, where
> userspace would claim "I do care about this, please fix it up for me". So
> prctl() + perh
* Ladislav Michl [181118 22:22]:
> Aaro,
>
> On Sun, Nov 18, 2018 at 10:19:19PM +0200, Aaro Koskinen wrote:
> > Since v2.6.22 or so there has been reports [1] about OMAP MMC being
> > broken on OMAP15XX based hardware (OMAP5912 and OMAP310). The breakage
> > seems to have been caused by commit 46
>
> Call tpm_chip_start() and tpm_chip_stop() in
>
> * tpm_try_get_ops() and tpm_put_ops()
> * tpm_chip_register()
> * tpm2_del_space()
>
> And remove these calls from tpm_transmit(). The core reason for this change
> is that in tpm_vtpm_proxy a locality change requires a virtual TPM command
On 11/18/2018 02:36 PM, Linus Torvalds wrote:
> On Sun, Nov 18, 2018 at 2:17 PM Jiri Kosina wrote:
>> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
>> given the existence of that?
>
> I don't think the code needs to be reverted, but the *behavior* of
> just unconditiona
On Fri, 2018-11-16 at 14:41 -0800, Dave Hansen wrote:
> On 11/16/18 2:12 AM, Oscar Salvador wrote:
> > Physical memory hotadd has to allocate a memmap (struct page array)
> > for
> > the newly added memory section. Currently, kmalloc is used for
> > those
> > allocations.
>
> Did you literally mea
On Sat, 17 Nov 2018, Jiri Kosina wrote:
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 81d1d5a..9c306e3 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-par
On Sun, 18 Nov 2018, Jiri Kosina wrote:
> It's probably not just browsers, but anything running JITed sandboxed
> code. So the most straightforward way might be the prctl() aproach, where
> userspace would claim "I do care about this, please fix it up for me". So
> prctl() + perhaps SECCOMP.
I
On 11/19/2018 6:00 AM, Linus Torvalds wrote:
On Sun, Nov 18, 2018 at 1:49 PM Jiri Kosina wrote:
So why do that STIBP slow-down by default when the people who *really*
care already disabled SMT?
BTW for them, there is no impact at all.
Right. People who really care about security and are a
On Sun, Nov 18, 2018 at 09:36:18AM +0200, Jarkko Sakkinen wrote:
On Fri, Nov 16, 2018 at 11:19:57AM -0500, Sasha Levin wrote:
On Fri, Nov 16, 2018 at 02:38:32PM +0200, Jarkko Sakkinen wrote:
> Always call tpm2_flush_space() on failure in tpm_try_transmit() so that
> the volatile memory of the TP
From: Daniel Robson
removed unneeded variable in shm_get_policy()
Signed-off-by: Daniel Robson
---
ipc/shm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/ipc/shm.c b/ipc/shm.c
index 0842411cb0e9..2cb493214108 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -461,11 +461,10
Linus Torvalds writes:
> On Sun, Nov 18, 2018 at 2:17 PM Jiri Kosina wrote:
>> Which gets us back to Tim's fixup patch. Do you still prefer the revert,
>> given the existence of that?
>
> I don't think the code needs to be reverted, but the *behavior* of
> just unconditionally enabling STIBP nee
> So my patchset and Jiri's patchset should probably be merged together, so the
> users have a choice of the behavior.
... or delay Jiri's patchkit until the scheduler can actually check
properly for the cases when it is really needed.
-Andi
On 2018-11-18, Daniel Colascione wrote:
> > The gist is to have file descriptors for processes which is obviously not a
> > new
> > idea. This has been done before in other OSes and it has been tried before
> > in
> > Linux [2], [3] (Thanks to Kees for pointing out these patches.). So I want
>
On 2018-11-18, Daniel Colascione wrote:
> On Sun, Nov 18, 2018 at 11:05 AM, Aleksa Sarai wrote:
> > On 2018-11-18, Daniel Colascione wrote:
> >> > Here's my point: if we're really going to make a new API to manipulate
> >> > processes by their fd, I think we should have at least a decent idea
>
On Sun, Nov 18, 2018 at 1:30 PM, Christian Brauner wrote:
> On Sun, Nov 18, 2018 at 10:23:36PM +0100, Christian Brauner wrote:
>> On Sun, Nov 18, 2018 at 12:54:10PM -0800, Daniel Colascione wrote:
>> > On Sun, Nov 18, 2018 at 12:43 PM, Christian Brauner
>> > wrote:
>> > > On Sun, Nov 18, 2018 at
On Sun, Nov 18, 2018 at 04:31:22PM -0800, Daniel Colascione wrote:
> On Sun, Nov 18, 2018 at 1:30 PM, Christian Brauner
> wrote:
> > On Sun, Nov 18, 2018 at 10:23:36PM +0100, Christian Brauner wrote:
> >> On Sun, Nov 18, 2018 at 12:54:10PM -0800, Daniel Colascione wrote:
> >> > On Sun, Nov 18, 20
We used to have a single swap address space with swp_entry_t.val
as its radix tree index. This is not the case anymore. Now Each
swp_type() has its own address space and should use swp_offset()
as radix tree index.
Signed-off-by: Yu Zhao
---
mm/shmem.c | 11 +++
1 file changed, 7 inserti
On Sun, Nov 18, 2018 at 4:09 PM, Aleksa Sarai wrote:
> On 2018-11-18, Daniel Colascione wrote:
>> On Sun, Nov 18, 2018 at 11:05 AM, Aleksa Sarai wrote:
>> > On 2018-11-18, Daniel Colascione wrote:
>> >> > Here's my point: if we're really going to make a new API to manipulate
>> >> > processes b
Hi,
Here is the series of patches the initial support for SC2000(M10V) of
Milbeaut SoCs. "M10V" is the internal name of SC2000, so commonly used in
source code.
SC2000 is a SoC of the Milbeaut series. equipped with a DSP optimized for
computer vision. It also features advanced functionalities suc
This adds the basic M10V SoC support under arch/arm.
Since all cores are activated in the custom bootloader before booting
linux, it is necessary to wait for sub-cores using the trampoline area.
Signed-off-by: Sugaya Taichi
---
arch/arm/Kconfig | 2 +
arch/arm/Makefile
Add DT bindings document for Milbeaut trampoline.
Signed-off-by: Sugaya Taichi
---
.../devicetree/bindings/soc/socionext/socionext,m10v.txt | 12
1 file changed, 12 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
diff --git
Add Milbeaut M10V timer using 32bit timer in peripheral.
Signed-off-by: Sugaya Taichi
---
drivers/clocksource/Kconfig | 8 +++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-m10v.c | 146 +++
3 files changed, 155 insertions(+)
crea
Add Milbeaut M10V clock ( including PLL ) control.
Signed-off-by: Sugaya Taichi
---
drivers/clk/Makefile | 1 +
drivers/clk/clk-m10v.c | 671 +
2 files changed, 672 insertions(+)
create mode 100644 drivers/clk/clk-m10v.c
diff --git a/drivers/
Add DT bindings document for Milbeaut M10V pinctrl.
Signed-off-by: Sugaya Taichi
---
.../pinctrl/socionext,milbeaut-pinctrl.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/socionext,milbeaut-pinctrl.txt
dif
This patch adds the minimal defconfig for the Milbeaut M10V.
Signed-off-by: Sugaya Taichi
---
arch/arm/configs/milbeaut_m10v_defconfig | 364 +++
1 file changed, 364 insertions(+)
create mode 100644 arch/arm/configs/milbeaut_m10v_defconfig
diff --git a/arch/arm/conf
Add DT bindings document for Milbeaut M10V serial.
Signed-off-by: Sugaya Taichi
---
.../devicetree/bindings/serial/milbeaut-uart.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/milbeaut-uart.txt
diff --git a/Docume
Add DT bindings document for Milbeaut clock.
Signed-off-by: Sugaya Taichi
---
.../devicetree/bindings/clock/milbeaut-clock.txt | 93 ++
1 file changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/milbeaut-clock.txt
diff --git a/Documentatio
Add devicetree for Milbeaut M10V SoC and M10V Evaluation board.
Signed-off-by: Sugaya Taichi
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/milbeaut-m10v-evb.dts | 35 +++
arch/arm/boot/dts/milbeaut-m10v-evb.dtsi | 17 ++
arch/arm/boot/dts/milbeaut-m10v.dtsi | 510
Add Milbeaut M10V serial control.
Signed-off-by: Sugaya Taichi
---
drivers/tty/serial/Kconfig | 24 ++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/m10v_usio.c | 605 +++
include/uapi/linux/serial_core.h | 3 +
4 files changed, 633 i
Add Milbeaut M10V pinctrl.
The M10V has the pins that can be used GPIOs or take multiple other
functions.
Signed-off-by: Sugaya Taichi
---
drivers/pinctrl/Kconfig| 9 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-m10v.c | 765
Add entry to MAINTAINERS for Milbeaut that supported minimal drivers.
Signed-off-by: Sugaya Taichi
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0abecc5..31dd29f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1782,6 +1782,15 @@ F:
Add DT bindings document for Milbeaut M10V timer.
Signed-off-by: Sugaya Taichi
---
.../bindings/timer/socionext,milbeaut-timer.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
diff --gi
Add Milbeaut M10V earlyprintk.
Signed-off-by: Sugaya Taichi
---
arch/arm/Kconfig.debug| 12 ++--
arch/arm/include/debug/milbeaut.S | 25 +
2 files changed, 35 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/include/debug/milbeaut.S
diff --g
On Sun, Nov 18, 2018 at 11:02:19PM +0800, Yafang Shao wrote:
> On Sun, Nov 18, 2018 at 8:13 PM Matthew Wilcox wrote:
> > Did you check the before/after code generation with this patch applied?
>
> Yes, I did.
> My oompiler is gcc-4.8.5, a litte old, and with CONFIG_CC_OPTIMIZE_FOR_SIZE
> on.
> >
Hi, Bjorn,
Would you please help to review and pull these two quirk patches to
your branch if there is no problem?
Thanks.
Shunyong.
On 2018/11/7 15:24, Yang, Shunyong wrote:
> The HXT SD4800 PCI controller does not set the Command Completed
> bit unless writes to the Slot Command register chan
We used to have a single swap address space with swp_entry_t.val
as its radix tree index. This is not the case anymore. Now Each
swp_type() has its own address space and should use swp_offset()
as radix tree index.
Signed-off-by: Yu Zhao
---
mm/shmem.c | 11 +++
1 file changed, 7 inserti
On Sun, Nov 18, 2018 at 4:08 PM, Aleksa Sarai wrote:
> On 2018-11-18, Daniel Colascione wrote:
>> > The gist is to have file descriptors for processes which is obviously not
>> > a new
>> > idea. This has been done before in other OSes and it has been tried before
>> > in
>> > Linux [2], [3] (T
On Sun, Nov 18, 2018 at 4:53 PM, Daniel Colascione wrote:
>> Sure, I'd propose that ptrace_may_access() is what we should use for
>> operation permission checks.
>
> The tricky part is that ptrace_may_access takes a struct task. We want
> logic that's *like* ptrace_may_access, but that works posth
The functions that implement arch_gettimeoffset are re-used by
new clocksource drivers in subsequent patches.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
---
arch/m68k/Kconfig | 1 -
arch/m68k/amiga/config.c| 3 ---
arch/m68k/atari/config.c| 2 --
arch/m68k/bvme6000/conf
This series removes "select ARCH_USES_GETTIMEOFFSET" from arch/m68k
and converts users of arch_gettimeoffset to the clocksource API.
Various bugs are fixed along the way.
Those platforms which do not actually implement arch_gettimeoffset
(apollo, q40, sun3, sun3x) use the "jiffies" clocksource by
Reading the timer counter races with timer overflow (and the
corresponding interrupt). This is resolved by reading the overflow
register and taking this value into account. The interrupt handler
must clear the overflow register when it eventually executes.
Suggested-by: Thomas Gleixner
Signed-off
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
---
Changed since v1:
- Moved clk_total access to within the irq lock.
---
arch/m68k/bvme6000/config.c | 52 +++--
1 file cha
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Normally the MFP timer C interrupt flag would be used to check for
timer counter wrap-around. Unfortunately, that flag gets cleared by the
MFP itself (due to automatic EOI mode). This means that
mfp_timer_c_hand
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
---
Changed since v1:
- Moved clk_total access to within the irq lock.
---
arch/m68k/mvme16x/config.c | 39 +++---
1 file cha
Some platforms execute their timer handler with the interrupt priority
level below 6. That means the handler could be interrupted by another
driver and this could lead to re-entry of the timer core.
Avoid this by use of local_irq_save/restore for timer interrupt dispatch.
This provides mutual excl
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
---
Changed since v1:
- Moved clk_total access to within the irq lock.
- Use type u32 for tick counter.
---
arch/m68k/include/asm/mvme147hw.h | 1 -
arch/m
Reading the timer counter races with timer overflow (and the
corresponding interrupt). This is resolved by reading the overflow
register and taking this value into account. The interrupt handler
must clear the overflow register when it eventually executes.
Suggested-by: Thomas Gleixner
Signed-off
hp300_gettimeoffset() never checks the timer interrupt flag and will
fail to notice when the timer counter gets reloaded. That means the
clock could jump backwards.
Remove this code and leave this platform on the 'jiffies' clocksource.
Note that this amounts to a regression in clock precision. How
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
Tested-by: Stan Johnson
---
Changed since v1:
- Moved clk_total access to within the irq lock.
- Use type u32 for tick counter.
---
arch/m68k/mac/via.c | 4
This resolves some bugs that affect VIA timer counter accesses.
Avoid lost interrupts caused by reading the counter low byte register.
Make allowance for the fact that the counter will be decremented to
0x before being reloaded.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Finn Thai
Signed-off-by: Finn Thain
---
arch/m68k/include/asm/macints.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/m68k/include/asm/macints.h b/arch/m68k/include/asm/macints.h
index cddb2d3ea49b..4da172bd048c 100644
--- a/arch/m68k/include/asm/macints.h
+++ b/arch/m68k/include/asm/macints.h
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
---
Changed since v1:
- Moved clk_total access to within the irq lock.
---
arch/m68k/amiga/config.c | 43
1 file cha
These dummy implementations are no better than
default_arch_gettimeoffset() so remove them.
Signed-off-by: Finn Thain
---
arch/m68k/apollo/config.c | 7 ---
arch/m68k/q40/config.c| 9 -
arch/m68k/sun3/config.c | 2 --
arch/m68k/sun3/intersil.c | 7 ---
arch/m68k/sun3x/confi
On Sun, Nov 18, 2018 at 12:32 PM Daniel Colascione wrote:
>
> On Sun, Nov 18, 2018 at 12:28 PM, Andy Lutomirski wrote:
> >> That is, I'm proposing an API that looks like this:
> >>
> >> int process_kill(int procfs_dfd, int signo, const union sigval value)
> >>
> >> If, later, process_kill were to
Investment funding opportunity
Email: 1045579...@qq.com
Good day,
My name is Thoon Yan. Do you have any project that needs funding? I
wish to invite you to a special Investment Funding opportunity. All I
need to know is if I can trust you to partner with me in a funding
opportunity. If inter
On 11/16/2018 09:21 PM, Keith Busch wrote:
> On Fri, Nov 16, 2018 at 11:57:58AM +0530, Anshuman Khandual wrote:
>> On 11/15/2018 04:19 AM, Keith Busch wrote:
>>> This series provides a new sysfs representation for heterogeneous
>>> system memory.
>>>
>>> The previous series that was specific to
101 - 200 of 277 matches
Mail list logo
