Quoting Sugaya, Taichi (2018-12-04 00:26:16)
> On 2018/11/30 17:31, Stephen Boyd wrote:
> > Quoting Sugaya Taichi (2018-11-18 17:01:12)
> >> +void __init m10v_clk_mux_setup(struct device_node *node)
> >> +{
> >> + const char *clk_name = node->name;
> >> + struct clk_init_data init;
>
From: Bartosz Golaszewski
I'm working on an MFD driver (and its accompanying drivers in various
subsystems) for a simple low-power PMIC which exposes a single GPIO
line. It has a couple of interrupts all bunched together in two
registers and all of them but the one for GPIO are controlled by
Quoting Masahiro Yamada (2018-12-04 03:03:53)
> Hi Stephen,
>
>
> On Fri, Nov 30, 2018 at 5:31 PM Stephen Boyd wrote:
> >
> > Quoting Sugaya Taichi (2018-11-18 17:01:12)
> > > Add Milbeaut M10V clock ( including PLL ) control.
> >
> > Please give some more details here.
> >
> > >
> > >
Hi Boris,
On 04/12/18 00:38, vitor wrote:
Hi Boris,
On 03/12/18 10:07, Boris Brezillon wrote:
Hi Vitor,
On Mon, 26 Nov 2018 09:45:14 +0100
Boris Brezillon wrote:
Follow the naming scheme introduced by the Cadence driver to keep
things
consistent.
Signed-off-by: Boris Brezillon
---
From: Rafael J. Wysocki
The venerable menu governor does some thigns that are quite
questionable in my view.
First, it includes timer wakeups in the pattern detection data and
mixes them up with wakeups from other sources which in some cases
causes it to expect what essentially would be a timer
On Mon, Dec 03, 2018 at 11:30:45AM +0100, Andreas Brauchli wrote:
> From: Andreas Brauchli
>
> On Sat, 1 Dec 2018 15:58:57 +, Jonathan Cameron wrote:
> > On Sun, 25 Nov 2018 20:05:09 +0100
> > Tomasz Duszynski wrote:
> >
> > > On Sun, Nov 25, 2018 at 08:56:59AM +, Jonathan Cameron wrote:
On 12/4/18 10:49 AM, Jerome Glisse wrote:
> Policy is same kind of story, this email is long enough now :) But
> i can write one down if you want.
Yes, please. I'd love to see the code.
We'll do the same on the "HMAT" side and we can compare notes.
On Tue, Dec 4, 2018 at 8:17 AM Sean Christopherson
wrote:
>
> Once upon a time, vdso2c aggressively stripped data from the vDSO
> image when generating the final userspace image. This included
> stripping the .altinstructions and .altinstr_replacement sections.
> Eventually, the stripping
On Tue 04 Dec 07:13 PST 2018, Jeffrey Hugo wrote:
> The current list of defined resets is incomplete compared to what the
> hardware implements. Enumerate the remaining resets according to the
> hardware documentation.
>
> Signed-off-by: Jeffrey Hugo
Acked-by: Bjorn Andersson
Regards,
Bjorn
jgli...@redhat.com writes:
> +
> +To help with forward compatibility each object as a version value and
> +it is mandatory for user space to only use target or initiator with
> +version supported by the user space. For instance if user space only
> +knows about what version 1 means and sees a
Quoting Neil Armstrong (2018-12-04 04:58:39)
> Makes the following sparse warnings silent:
> drivers/clk/meson/vid-pll-div.c:58:26: warning: symbol '_get_table_val' was
> not declared. Should it be static?
> drivers/clk/meson/gxbb.c:1585:12: warning: symbol 'gxbb_vid_pll_parent_names'
> was not
On Mon, 5 Nov 2018 18:00:15 +0900
Masami Hiramatsu wrote:
> Add a busy check loop in cleanup_all_probes() before
> trying to remove all events in uprobe_events as same as
> kprobe_events does.
>
> Without this change, writing null to uprobe_events will
> try to remove events but if one of them
On Mon, Oct 29, 2018 at 1:19 PM Suman Anna wrote:
>
> Hi Loic,
>
> On 10/24/18 10:14 AM, Loic PALLARDY wrote:
> > Hi Suman,
> >
> >> -Original Message-
> >> From: Suman Anna
> >> Sent: mercredi 24 octobre 2018 02:14
> >> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> >>
Hello
On 12/04/2018 11:59 AM, Dan Murphy wrote:
> Adding binding documentation for Texas Instruments ADS124S08
> and ADS124S06 ADC.
>
> S08 is a 12 channel ADC
> S06 is a 6 channel ADC
>
> Datesheet can be found here:
> http://www.ti.com/lit/gpn/ads124s08
>
> Signed-off-by: Dan Murphy
> ---
>
On Tue, 4 Dec 2018 at 18:26, Steven Rostedt wrote:
>
> On Tue, 4 Dec 2018 11:12:43 +
> Will Deacon wrote:
>
> > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > > index 8ef9fc226037..42e89397778b 100644
> > > --- a/kernel/trace/ftrace.c
> > > +++ b/kernel/trace/ftrace.c
> > >
On Tue, Dec 04, 2018 at 09:06:59AM -0800, Andi Kleen wrote:
> jgli...@redhat.com writes:
>
> > +
> > +To help with forward compatibility each object as a version value and
> > +it is mandatory for user space to only use target or initiator with
> > +version supported by the user space. For
On Tue, Dec 04, 2018 at 10:22:39AM -0800, Sean Christopherson wrote:
> On Tue, Dec 04, 2018 at 08:17:40AM -0800, Sean Christopherson wrote:
> > At one point the vDSO image was manually stripped down by vdso2c in an
> > attempt to minimize the size of the image mapped into userspace. Part
> > of
On Fri, Nov 30, 2018 at 10:29:14AM +0800, Chao Fan wrote:
> Oh, thanks, will change it
> char val[19];
And make that 19 a define.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Function returns -1 on error and the return type
should be int.
Signed-off-by: Akshu Agrawal
---
include/sound/soc.h | 2 +-
sound/soc/soc-io.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 8ec1de8..591d743 100644
---
Quoting Jerome Brunet (2018-12-04 08:34:03)
> clk_mux_val_to_index() is meant to be used by .get_parent(), which
> returns a u8, so when the value provided does not map to any valid index,
> it is not a good idea to return a negative error value.
>
> Instead, return num_parents which we know is
On Tue, Dec 04, 2018 at 10:02:55AM -0800, Dave Hansen wrote:
> On 12/3/18 3:34 PM, jgli...@redhat.com wrote:
> > This means that it is no longer sufficient to consider a flat view
> > for each node in a system but for maximum performance we need to
> > account for all of this new memory but also
On Mon, 5 Nov 2018 18:04:29 +0900
Masami Hiramatsu wrote:
> Remove trace_add_event_call() and trace_remove_event_call()
> functions since those are not used anymore.
>
> Signed-off-by: Masami Hiramatsu
Hi Masami,
I've applied the series locally (need to test it) except for this
patch.
On Tue, Dec 4, 2018 at 4:46 PM Rafael J. Wysocki wrote:
>
> On Tue, Dec 4, 2018 at 2:15 AM Frank Lee wrote:
> >
> > On Mon, Dec 3, 2018 at 5:14 PM Rafael J. Wysocki wrote:
> > >
> > > On Fri, Nov 30, 2018 at 3:26 PM Yangtao Li wrote:
> > > >
> > > > In a function whose return type is void,
From: john.hubb...@gmail.com
> Sent: 04 December 2018 00:17
>
> Summary: I'd like these two patches to go into the next convenient cycle.
> I *think* that means 4.21.
>
> Details
>
> At the Linux Plumbers Conference, we talked about this approach [1], and
> the primary lingering concern was
I've let the JSON maintainers know.
-Andi
The patch
spi: add support for octal mode I/O data transfer
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
On Tue, 4 Dec 2018 16:32:35 +0900
Namhyung Kim wrote:
> > +++ b/tools/lib/traceevent/libtraceevent.pc.template
> > @@ -0,0 +1,10 @@
> > +prefix=INSTALL_PREFIX
> > +libdir=${prefix}/lib64
>
> Don't we care 32-bit systems anymore? :)
No we don't ;-)
But, I guess because some people still do,
stable-rc/linux-4.14.y boot: 120 boots: 0 failed, 118 passed with 2 offline
(v4.14.85-147-g2bfd08691add)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.85-147-g2bfd08691add/
Full Build Summary:
Introduce the TI ADS124S08 and the ADS124S06 ADC
devices from TI. The ADS124S08 is the 12 channel ADC
and the ADS124S06 is the 6 channel ADC device
These devices share a common datasheet:
http://www.ti.com/lit/gpn/ads124s08
Signed-off-by: Dan Murphy
---
drivers/iio/adc/Kconfig| 10 +
Quoting Jerome Brunet (2018-12-04 08:32:57)
> This reverts commit 2430a94d1e719b7b4af2a65b781a4c036eb22e64.
>
> From the original commit message:
> It turned out a problem because there are some single-parent clocks
> that implement .get_parent() callback and return non-zero index.
> The
On Mon, Nov 12, 2018 at 11:57:12AM +, Julien Thierry wrote:
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 5f4d9ac..66344cd 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -897,13 +897,17 @@ bool arm64_is_fatal_ras_serror(struct
On 04/12/18 17:51, Catalin Marinas wrote:
> On Mon, Nov 12, 2018 at 11:57:06AM +, Julien Thierry wrote:
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 8dc9dde..e495360 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -35,6 +35,7 @@
On Tue, Dec 04, 2018 at 08:17:40AM -0800, Sean Christopherson wrote:
> At one point the vDSO image was manually stripped down by vdso2c in an
> attempt to minimize the size of the image mapped into userspace. Part
> of that stripping process involved building a fake section table so as
> not to
Quoting Kamil Konieczny (2018-12-04 08:52:48)
> +
> +static const unsigned long imem_clk_regs[] __initconst = {
> + ENABLE_ACLK_IMEM,
> + ENABLE_ACLK_IMEM_INT_MEM,
> + ENABLE_ACLK_IMEM_SSS,
> + ENABLE_ACLK_IMEM_SLIMSSS,
> + ENABLE_ACLK_IMEM_RTIC,
> +
On Thu, Nov 29 2018 at 10:50 -0700, Ulf Hansson wrote:
Introduce a new PSCI DT helper function, psci_dt_attach_cpu(), which takes
a CPU number as an in-parameter and attaches the CPU's struct device to its
corresponding PM domain. Additionally, the helper prepares the CPU to be
power managed via
On Tue, Dec 4, 2018 at 10:04 AM Loic PALLARDY wrote:
>
>
>
> > -Original Message-
> > From: Wendy Liang
> > Sent: mardi 4 décembre 2018 18:57
> > To: Suman Anna
> > Cc: Loic PALLARDY ; Bjorn Andersson
> > ; Ohad Ben-Cohen ;
> > linux-remotep...@vger.kernel.org; Linux Kernel Mailing List
On Tue, Dec 4, 2018 at 10:29 AM Sean Christopherson
wrote:
>
> On Tue, Dec 04, 2018 at 10:22:39AM -0800, Sean Christopherson wrote:
> > On Tue, Dec 04, 2018 at 08:17:40AM -0800, Sean Christopherson wrote:
> > > At one point the vDSO image was manually stripped down by vdso2c in an
> > > attempt
On 12/04/2018 09:20 AM, Linus Torvalds wrote:
>> STIBP
>> ^
>> Implementations of STIBP on existing Core-family processors (where STIBP
>> functionality was added through a microcode update) work by disabling
>> branch predictors that both:
>>
>> 1. Contain indirect branch predictions for
On Tue, Dec 04, 2018 at 12:23:08PM -0500, Jason Baron wrote:
>
>
> On 12/3/18 6:02 AM, Roman Penyaev wrote:
> > Hi all,
> >
> > The goal of this patch is to reduce contention of ep_poll_callback() which
> > can be called concurrently from different CPUs in case of high events
> > rates and many
stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 117 passed with 2 offline, 1
untried/unknown (v4.19.6-140-g987a6da5152c)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.6-140-g987a6da5152c/
Full Build Summary:
On Fri, Nov 30, 2018 at 10:59:08AM +0200, Matti Vaittinen wrote:
> IRQ handling is implemented so that each sub block has own
> status/ack/mask registers and then there is one main status
> register. When any of the sub blocks gets unmasked IRQ,
> corresponding 'main status register' bit is set
On Mon, Dec 3, 2018 at 5:38 PM Tim Chen wrote:
>
> To make the usage of STIBP and its working principles clear,
> here are some additional explanations of STIBP from our Intel
> HW architects. This should also help answer some of the questions
> from Thomas and others on STIBP's usages with IBPB
The patch
regulator: Allow regulator nodes to contain their own init data
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
regulator: Factor out location of init data OF node
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
On Tue, 4 Dec 2018 11:12:43 +
Will Deacon wrote:
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index 8ef9fc226037..42e89397778b 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -2393,11 +2393,14 @@ void __weak ftrace_replace_code(int enable)
From: Joerg Roedel
Replace the dev->iommu_group check with a proper function
call that better reprensents its purpose.
Cc: Mathias Nyman
Signed-off-by: Joerg Roedel
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c
On Mon, Nov 12, 2018 at 11:57:01AM +, Julien Thierry wrote:
> diff --git a/arch/arm64/include/asm/irqflags.h
> b/arch/arm64/include/asm/irqflags.h
> index 24692ed..e0a32e4 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -18,7 +18,27 @@
>
>
Em Tue, Dec 04, 2018 at 09:16:32AM -0800, Andi Kleen escreveu:
>
> I've let the JSON maintainers know.
Thanks!
- Arnaldo
On Tue, Dec 4, 2018 at 6:58 PM Frank Lee wrote:
> $ git br -r
> origin/HEAD -> origin/master
> origin/fixes
> origin/for-next
> origin/master
> origin/review-andy
> $ git remote set-branches --add origin for-next
> $ git br -vv
> * for-next 651022382c7f [origin/for-next] Linux 4.20-rc1
Currently we do USB configuration only if the host mode (CONFIG_USB)
is enabled. But it should be done also in the case of device-only setups,
so change the condition to CONFIG_USB_SUPPORT. This allows to use
omap_udc on Palm Tungsten E.
Signed-off-by: Aaro Koskinen
---
Add initial MMC configuration for Palm Tungsten E to allow using a proper
rootfs on the device. This still assumes the bootloader enabling the MMC,
and that the card is always present and writeable.
Signed-off-by: Aaro Koskinen
---
arch/arm/mach-omap1/board-palmte.c | 29
On 12/3/18 3:34 PM, jgli...@redhat.com wrote:
> This means that it is no longer sufficient to consider a flat view
> for each node in a system but for maximum performance we need to
> account for all of this new memory but also for system topology.
> This is why this proposal is unlike the HMAT
On Tue 04-12-18 09:31:11, Linus Torvalds wrote:
> On Tue, Dec 4, 2018 at 1:58 AM Michal Hocko wrote:
> >
> > AFAIU both suspend and hibernation require the system to enter quiescent
> > state with no task potentially interfering with suspended devices. And
> > in this particular case those
On Tue, 4 Dec 2018 19:07:16 +0100
Anders Roxell wrote:
> > > > + schedulable = !irqs_disabled() & !preempt_count();
> > >
> > > Looks suspiciously like a bitwise preemptible() to me!
> >
> > Ah, thanks. Yeah, that should have been &&. But what did you expect.
> > I didn't even compile
On Tue, Dec 4, 2018 at 10:24 AM Jerome Glisse wrote:
>
> On Tue, Dec 04, 2018 at 09:06:59AM -0800, Andi Kleen wrote:
> > jgli...@redhat.com writes:
> >
> > > +
> > > +To help with forward compatibility each object as a version value and
> > > +it is mandatory for user space to only use target or
Failed i2c transaction can lead to failure in reg read or write.
Need to have error check for each read write operation.
Signed-off-by: Akshu Agrawal
---
sound/soc/codecs/da7219.c | 323 +++---
sound/soc/codecs/da7219.h | 2 +-
2 files changed, 247
On Sat, Dec 01, 2018 at 02:05:39PM +0800, Chao Fan wrote:
> >I built your whole patchset and got the error.
> >The error depends on CONFIG_MODVERSIONS.
> >If CONFIG_MODVERSIONS=y, you will get the build error.
>
> Hi Masa,
>
> Thanks, after that, I got the error.
> About your solution, it can
> static const char * const spectre_v2_user_strings[] = {
> [SPECTRE_V2_USER_NONE] = "User space: Vulnerable",
> [SPECTRE_V2_USER_STRICT]= "User space: Mitigation: STIBP
> protection",
> [SPECTRE_V2_USER_PRCTL] = "User space: Mitigation: STIBP via
>
On 12/03/2018 07:28 PM, Bart Van Assche wrote:
> The next patch in this series uses the class name in code that
> detects lock class use-after-free. Hence retain the class name for
> lock classes that are being freed.
>
> Cc: Peter Zijlstra
> Cc: Waiman Long
> Cc: Johannes Berg
> Signed-off-by:
On Tue, Dec 04, 2018 at 10:31:17AM -0800, Dan Williams wrote:
> On Tue, Dec 4, 2018 at 10:24 AM Jerome Glisse wrote:
> >
> > On Tue, Dec 04, 2018 at 09:06:59AM -0800, Andi Kleen wrote:
> > > jgli...@redhat.com writes:
> > >
> > > > +
> > > > +To help with forward compatibility each object as a
There was a bug in reset signal generation in ssd1307fb OLED driver.
The display needs an active-low reset signal but the driver produced
the correct sequence only if the GPIO used for reset was specified as
GPIO_ACTIVE_HIGH.
Now as the OLED driver is fixed it is also necessarry to implement
a
> -5.3. Disabling
> +5.3. Replacing
> +--
> +
> +All enabled patches might get replaced by a cumulative patch that
> +has the .replace flag set.
> +
> +Once the new patch is enabled and the 'transition" finishes then
> +all the functions (struct klp_func) associated with the replaced
On Tue 2018-12-04 06:10:40, Tetsuo Handa wrote:
> On 2018/12/04 0:06, Petr Mladek wrote:
> >> If we modify print_time(), I think that the leading spaces inserted by
> >> "%5lu"
> >> makes little sense, for "%5lu" is too small for systems with uptime >=
> >> 1.16 days
> >> and parsers after all
On Mon, 2018-12-03 at 21:17 +0200, Andy Shevchenko wrote:
> On Mon, Dec 3, 2018 at 9:04 PM Takashi Iwai wrote:
> > On Mon, 03 Dec 2018 19:53:39 +0100,
> > Ayman Bagabas wrote:
> > > + if (code == 0x80) {
> > > + acpi_status status;
> > > + acpi_handle handle;
> > > +
Now, Linux uses the irq_affinity_desc to convey information.
As Kashyap and Sumit reported, in MSI/-x subsystem, the pre/post vectors
may be used to some extra reply queues for performance.
https://marc.info/?l=linux-kernel=153543887027997=2
Their affinities are not NULL, but, they should be
Get back to us, it is highly important. Mr.Ahmed Yaki
This reverts commit 3aa2177e47878f7e7616da8a2050c44f22301b6e.
That commit triggered a new WARN when unloading the module (see at the
end of the commit message). When a class_dev is embedded in a structure
then that class_dev is the thing that controls the lifetime of that
structure, for that
Hi Andy,
On Tue, Dec 4, 2018 at 5:12 PM Andy Shevchenko
wrote:
> On Tue, Dec 04, 2018 at 02:30:28PM +0100, Petr Mladek wrote:
> > On Thu 2018-11-29 12:59:40, Andy Shevchenko wrote:
> > > There are users which print time and date represented by content of
> > > struct rtc_time in human readable
While the dma-direct code is (relatively) clean and simple we actually
have to use the swiotlb ops for the mapping on many architectures due
to devices with addressing limits. Instead of keeping two
implementations around this commit allows the dma-direct
implementation to call the swiotlb bounce
We can use DMA_MAPPING_ERROR instead, which already maps to the same
value.
Signed-off-by: Christoph Hellwig
---
drivers/xen/swiotlb-xen.c | 4 ++--
include/linux/swiotlb.h | 3 ---
kernel/dma/swiotlb.c | 4 ++--
3 files changed, 4 insertions(+), 7 deletions(-)
diff --git
Only report report a DMA addressability report once to avoid spewing the
kernel log with repeated message. Also provide a stack trace to make it
easy to find the actual caller that caused the problem.
Last but not least move the actual check into the fast path and only
leave the error reporting
At one point the vDSO image was manually stripped down by vdso2c in an
attempt to minimize the size of the image mapped into userspace. Part
of that stripping process involved building a fake section table so as
not to break userspace processes that parse the section table. Memory
for the fake
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
> On 12/4/18 10:42 AM, Vivek Goyal wrote:
> > On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
> > > On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
> > >
> > > > Having said that, this still create little anomaly
Hi Konrad and others,
can you review this series? It merges the swiotlb support into the
DMA direct ops so that we don't have to duplicate the dma mapping logic
in multiple places.
Note that this is based on the dma_mapping_error series for which I'd
still like to collect a few more reviews, so
On Tue, Dec 04, 2018 at 09:13:33PM +0530, Aneesh Kumar K.V wrote:
> Keith Busch writes:
> >
> > Indeed, that particular example is out of scope for this series. The
> > first objective is to aid a process running in node B's CPUs to allocate
> > memory in B1. Anything that crosses QPI are their
The reset-active-low property has been removed brom the binding a while
ago. So remove it from the examples as well.
Fixes: 519b4db ("fbdev: ssd1307fb: Remove reset-active-low from the DT binding
document")
Signed-off-by: Michal Vokáč
---
Documentation/devicetree/bindings/display/ssd1307fb.txt
Hi all,
this is my third attempt to fix the ssd1307fb OLED driver reset. In the
second attempt [1] Rob suggested to take different aproach. That is to
apply what was originaly part of the first round and eventually merged
but reverted later on [2][3].
Next step is to apply a fixup for the single
The reset signal of the SSD1306 OLED display is actually active-low.
Adapt the DT to reflect the real world.
Signed-off-by: Michal Vokáč
---
arch/arm/boot/dts/imx28-cfa10036.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts
The SSD130x OLED display reset signal is active low. Now the reset
sequence is implemented in such a way that users are forced to
define reset-gpios as GPIO_ACTIVE_HIGH in DT to make the reset work.
Do not hard code the active-low sequence into the driver but instead
allow the user to specify the
On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote:
> On 12/4/18 8:32 AM, Miklos Szeredi wrote:
> > On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
> > >
> > > On 11/29/18 4:03 PM, Stephen Smalley wrote:
> > > > On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> > > > > On Thu,
On 12/4/18 10:15 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote:
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 4:32 PM Stephen Smalley wrote:
> Ok, I concede the point. Not sure what that means though for v4.20.
I have the revert queued up for v4.20 as that's the safest.
Don't let that stop the discussion, though, I'd especially like to
hear the arguments from the Android side.
On 2018/12/03 15:51:27 -0800, Paul E. McKenney wrote:
> On Tue, Dec 04, 2018 at 08:28:03AM +0900, Akira Yokosawa wrote:
>> On 2018/12/03 15:04:11 -0800, Paul E. McKenney wrote:
>>> Hello, Ingo!
>>>
>>> This series contains updates to the Linux kernel's formal memory model
>>> in
On 12/4/18 9:45 AM, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley wrote:
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
My proposed sequence would be
a) check task's creds against overlay inode, fail -> return fail, otherwise:
b) check mounter's creds against lower
stable-rc/linux-4.9.y boot: 108 boots: 0 failed, 107 passed with 1 offline
(v4.9.142-51-gd453b6576ba5)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.142-51-gd453b6576ba5/
Full Build Summary:
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
Having said that, this still create little anomaly when mknod to client
is not allowed on context label. So a device file, which is on
On Thu, 29 Nov 2018, Petr Mladek wrote:
> User documentation for the atomic replace feature. It makes it easier
> to maintain livepatches using so-called cumulative patches.
>
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
M
Remove pieces of the vDSO's fake section table mechanism that were left
behind when the vDSO build process reverted to using "objdump -S" to
strip the userspace image.
One of the removed pieces is a 0x340 byte reservation (for 64-bit) in
the .rodata section. Trimming that fat drops the current
Once upon a time, vdso2c aggressively stripped data from the vDSO
image when generating the final userspace image. This included
stripping the .altinstructions and .altinstr_replacement sections.
Eventually, the stripping process reverted to "objdump -S" and no
longer removed the aforementioned
clk_mux_val_to_index() is meant to be used by .get_parent(), which
returns a u8, so when the value provided does not map to any valid index,
it is not a good idea to return a negative error value.
Instead, return num_parents which we know is an invalid index and let
CCF deal with it.
Fixes:
On 12/4/18 11:17 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
Having said that, this still
On Tue, 4 Dec 2018 10:41:22 -0300
Arnaldo Carvalho de Melo wrote:
> Em Mon, Dec 03, 2018 at 11:22:00AM +0100, Ingo Molnar escreveu:
> > Go over the tools/ files that are maintained in Arnaldo's tree and
> > fix common typos: half of them were in comments, the other half
> > in JSON files.
>
>
Add the clock input helper function. Several amlogic clock controllers
will now be registering bypass clock input. Instead of copying this
code in every of them, let's make an helper function for it
Signed-off-by: Jerome Brunet
---
drivers/clk/meson/Makefile| 2 +-
On Wed, Dec 5, 2018 at 12:18 AM Andy Shevchenko
wrote:
>
> On Tue, Dec 4, 2018 at 5:30 PM Frank Lee wrote:
> > On Tue, Dec 4, 2018 at 8:40 PM Andy Shevchenko
> > wrote:
> > > On Tue, Dec 4, 2018 at 5:59 AM Frank Lee wrote:
> > > > On Tue, Dec 4, 2018 at 3:09 AM Andy Shevchenko
> > > > wrote:
The current list of defined resets is incomplete compared to what the
hardware implements. Enumerate the remaining resets according to the
hardware documentation.
Signed-off-by: Jeffrey Hugo
---
Based upon "Merge branch 'clk-qcom-8998-resets' into clk-next" to hopefully
avoid any merge
On Wed, Nov 28, 2018 at 01:04:26PM +0900, Kunihiko Hayashi wrote:
[...]
> +static void uniphier_pcie_irq_ack(struct irq_data *d)
> +{
> + struct pcie_port *pp = irq_data_get_irq_chip_data(d);
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct uniphier_pcie_priv *priv =
Now, Linux just spreads the interrupt affinity info by a cpumask pointer
and mark it as managed interrupt if its cpumask is not NULL.
if there are some other info should be passed, this design is not good
to expand, adding new arguments is the most staightforward method, But
this will break many
Now, Spreading the interrupt affinity info by a cpumask pointer is not
enough, meets a problem[1] and hard to expand in the future.
Fix it by:
+---+
| |
| struct cpumask *affinity |
|
In case of irq_default_affinity != cpu_possible_mask, setting the affinity
for the pre/post vectors to irq_default_affinity is a breakage.
Just set the pre/post vectors to cpu_possible_mask and be done with it.
Suggested-by: Thomas Gleixner
Signed-off-by: Dou Liyang
---
kernel/irq/affinity.c
On Tue, Dec 4, 2018 at 8:07 AM Guenter Roeck wrote:
>
> On Tue, Dec 4, 2018 at 7:58 AM Enric Balletbo i Serra
> wrote:
> >
> > This reverts commit 3aa2177e47878f7e7616da8a2050c44f22301b6e.
> >
> > That commit triggered a new WARN when unloading the module (see at the
> > end of the commit
601 - 700 of 2258 matches
Mail list logo
