The helper is identical to the existing cgroup_task_count()
except it doesn't take the css_set_lock by itself, assuming
that the caller does.
Also, move cgroup_task_count() implementation into
kernel/cgroup/cgroup.c, as there is nothing specific to cgroup v1.
Signed-off-by: Roman Gushchin
Cc: Te
Cgroup v1 implements the freezer controller, which provides an ability
to stop the workload in a cgroup and temporarily free up some
resources (cpu, io, network bandwidth and, potentially, memory)
for some other tasks. Cgroup v2 lacks this functionality.
This patch implements freezer for cgroup v2
This patchset implements freezer for cgroup v2.
It provides similar functionality as v1 freezer, but the interface
conforms to the cgroup v2 interface design principles, and it
provides a better user experience: tasks can be killed, ptrace works,
there is no separate controller, which has to be en
Freezer.c will contain an implementation of cgroup v2 freezer,
so let's rename the v1 freezer to avoid naming conflicts.
Signed-off-by: Roman Gushchin
Cc: Tejun Heo
Cc: kernel-t...@fb.com
---
kernel/cgroup/Makefile| 2 +-
kernel/cgroup/{freezer.c => legacy_freezer.c} | 0
Describe cgroup v2 freezer interface in the cgroup v2 admin guide.
Signed-off-by: Roman Gushchin
Reviewed-by: Mike Rapoport
Cc: Tejun Heo
Cc: linux-...@vger.kernel.org
Cc: kernel-t...@fb.com
---
Documentation/admin-guide/cgroup-v2.rst | 27 +
1 file changed, 27 insertio
The number of descendant cgroups and the number of dying
descendant cgroups are currently synchronized using the cgroup_mutex.
The number of descendant cgroups will be required by the cgroup v2
freezer, which will use it to determine if a cgroup is frozen
(depending on total number of descendants
If the cgroup destruction races with an exit() of a belonging
process(es), cg_kill_all() may fail. It's not a good reason to make
cg_destroy() fail and leave the cgroup in place, potentially causing
next test runs to fail.
Signed-off-by: Roman Gushchin
Cc: Shuah Khan
Cc: Tejun Heo
Cc: kernel-t.
This patch implements 8 tests for the freezer controller for
cgroup v2:
1) a simple test, which aims to freeze and unfreeze a cgroup with 100
processes
2) a more complicated tree test, which creates a hierarchy of cgroups,
puts some processes in some cgroups, and tries to freeze and unfreeze
differ
Thanks for posting this patchset Peter. Based on the patch titled, "sched: A
quick and dirty cgroup tagging interface," I believe cgroups are used to
define co-scheduling groups in this implementation.
Chrome OS engineers (kerr...@google.com, mpden...@google.com, and
pal...@google.com) are conside
On 2019-02-18, Petr Mladek wrote:
>> The printk subsystem needs to be able to query the size of the ring
>> buffer, seek to specific entries within the ring buffer, and track
>> if records could not be stored in the ring buffer.
>>
>> diff --git a/lib/printk_ringbuffer.c b/lib/printk_ringbuffer.c
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
From: Colin King
Date: Tue, 19 Feb 2019 14:21:20 +
> From: Colin Ian King
>
> Passing the struct ptp_clock_info caps by parameter is passing over 130 bytes
> of data by value on the stack. Optimize this by passing it by reference
> instead.
> Also shinks the object code size:
>
> Before:
On Tue, Feb 19, 2019 at 01:57:14PM -0800, Alexander Duyck wrote:
> On Tue, Feb 19, 2019 at 10:32 AM David Hildenbrand wrote:
> >
> > >>> This essentially just ends up being another trade-off of CPU versus
> > >>> memory though. Assuming we aren't using THP we are going to take a
> > >>> penalty in
From: Kai-Heng Feng
Date: Tue, 19 Feb 2019 23:45:29 +0800
> Another platform requires even longer delay to make the device work
> correctly after S3.
>
> So increase the delay to 300ms.
>
> BugLink: https://bugs.launchpad.net/bugs/1798921
>
> Cc: sta...@vger.kernel.org
Please do not CC: stabl
On Tue, 2019-02-19 at 22:49 +0100, Arnd Bergmann wrote:
> Building an arm64 allmodconfig kernel with clang results in over 140 warnings
> about overly large stack frames, the worst ones being:
>
> drivers/gpu/drm/panel/panel-sitronix-st7789v.c:196:12: error: stack frame size
> of 20224 bytes in fu
On 2/18/19 11:57 AM, Cornelia Huck wrote:
On Mon, 18 Feb 2019 11:35:45 -0500
Tony Krowiak wrote:
On 2/18/19 7:01 AM, Cornelia Huck wrote:
On Fri, 15 Feb 2019 16:59:33 -0500
Tony Krowiak wrote:
On 2/15/19 4:11 AM, Cornelia Huck wrote:
On Thu, 14 Feb 2019 13:30:59 -0500
Tony Krowiak wro
On Tue, Feb 19, 2019 at 11:47:12AM +0530, Anshuman Khandual wrote:
> + Matthew Wilcox
>
> On 02/19/2019 11:02 AM, Yu Zhao wrote:
> > On Tue, Feb 19, 2019 at 09:51:01AM +0530, Anshuman Khandual wrote:
> >>
> >>
> >> On 02/19/2019 04:43 AM, Yu Zhao wrote:
> >>> For pte page, use pgtable_page_ctor();
Hi all,
In commit
a968b5e9d587 ("net: dsa: qca8k: Enable delay for RGMII_ID mode")
Fixes tag
Fixes: 40269aa9f40a ("net: dsa: qca8k: disable delay for RGMII mode")
has these problem(s):
- Target SHA1 does not exist
Did you mean:
Fixes: 5ecdd77c61c8 ("net: dsa: qca8k: disable delay fo
Hi Marc,
On Tue, 19 Feb 2019 21:15:35 + Marc Zyngier wrote:
>
> Thanks for the heads up. I've just fixed the tree and pushed it out
> again.
Excellent, thanks.
--
Cheers,
Stephen Rothwell
pgp0W6UQNmYnJ.pgp
Description: OpenPGP digital signature
1) Fix suspend and resume in mt76x0u USB driver, from Stanislaw Gruszka.
2) Missing memory barriers in xsk, from Magnus Karlsson.
3) rhashtable fixes in mac80211 from Herbert Xu.
4) 32-bit MIPS eBPF JIT fixes from Paul Burton.
5) Fix for_each_netdev_feature() on big endian, from Hauke Mehrten
On 2/19/19 2:50 PM, Pierre Morel wrote:
On 18/02/2019 23:42, Cornelia Huck wrote:
On Mon, 18 Feb 2019 19:29:10 +0100
Pierre Morel wrote:
On 15/02/2019 23:02, Tony Krowiak wrote:
On 2/14/19 8:51 AM, Pierre Morel wrote:
+/*
+ * handle_pqap: Handling pqap interception
+ * @vcpu: the vcpu hav
>> I can't follow. We are talking about something as simple as a minimum
>> page granularity here that can easily be configured. Nothing that
>> screams for different implementations. But I get your point, we could
>> tune for different architectures.
>
> I was thinking about the guest side of t
On Mon, Feb 18, 2019 at 03:01:42PM +0800, Huang, Ying wrote:
> From: Huang Ying
>
> When swapin is performed, after getting the swap entry information from
> the page table, system will swap in the swap entry, without any lock held
> to prevent the swap device from being swapoff. This may cause
+ Evgenii, Kostya for KASAN
On Tue, Feb 19, 2019 at 2:17 PM Qian Cai wrote:
>
> On Tue, 2019-02-19 at 22:49 +0100, Arnd Bergmann wrote:
> > Building an arm64 allmodconfig kernel with clang results in over 140
> > warnings
> > about overly large stack frames, the worst ones being:
> >
> > drivers
On 2/19/19 2:50 PM, Pierre Morel wrote:
On 18/02/2019 23:42, Cornelia Huck wrote:
On Mon, 18 Feb 2019 19:29:10 +0100
Pierre Morel wrote:
On 15/02/2019 23:02, Tony Krowiak wrote:
On 2/14/19 8:51 AM, Pierre Morel wrote:
+/*
+ * handle_pqap: Handling pqap interception
+ * @vcpu: the vcpu hav
Fixes to inline comments, documentation, script usage.
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Paul E. McKenney"
Cc: Akira Yokosawa
Cc: Daniel Lustig
Andrea Parri (2):
tools/memory-m
Use "herd7" in each such reference.
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Paul E. McKenney"
Cc: Akira Yokosawa
Cc: Daniel Lustig
---
tools/memory-model/l
The comment should say "Sometimes" for the result.
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Paul E. McKenney"
Cc: Akira Yokosawa
Cc: Daniel Lustig
---
tools
Remove this subtle (and, AFAICT, unused) ordering: we can add it back,
if necessary, but let us not encourage people to rely on this thing.
For example, the following "exists" clause can be satisfied with this
change:
C dep-rfi
{ }
P0(int *x, int *y)
{
WRITE_ONCE(*x, 1);
smp_sto
Trond Myklebust wrote:
> Do we really need a new system call to set up containers? That would
> force changes to all existing orchestration software.
No, it wouldn't. Nothing in my patches forces existing orchestration software
to change, unless it wants to use the new facilities - then it woul
On Thu, Feb 07, 2019 at 03:35:29PM -0800, Eric Biggers wrote:
> On Thu, Jan 10, 2019 at 12:27:46PM -0800, Eric Biggers wrote:
> > On Wed, Nov 28, 2018 at 03:19:41PM -0800, Eric Biggers wrote:
> > > On Fri, Nov 02, 2018 at 06:58:54PM -0700, Eric Biggers wrote:
> > > > From: Eric Biggers
> > > >
>
James Bottomley wrote:
> I thought we got agreement years ago that containers don't exist in
> Linux as a single entity: they're currently a collection of cgroups and
> namespaces some of which may and some of which may not be local to the
> entity the orchestration system thinks of as a "contain
On Thu, Feb 07, 2019 at 03:35:09PM -0800, Eric Biggers wrote:
> On Mon, Jan 14, 2019 at 07:37:16PM -0800, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Align the payload of "user" and "logon" keys so that users of the
> > keyrings service can access it as a struct that requires more than
> >
Eric W. Biederman wrote:
> > + c->id = atomic64_inc_return(&container_id_counter);
>
> This id is not in a namespace, and it doesn't have enough bits
> of entropy to be globally unique. Not that 64bit is enough
> to have a chance at being globablly unique.
It's in a container, so it doesn't
[+cc Darren Hart, Andy Shevchenko]
Hi Lubo,
On Mon, Feb 11, 2019 at 12:37:19PM +0100, Lubomir Rintel wrote:
> perhaps the message slipped through the cracks? I'm happy to do
> whatever is needed to get the patch set into 5.1, but it seems I
> need some help and clarifications.
The following patc
Eric W. Biederman wrote:
> > Further attempts to fork into the container will be rejected.
>
> There are no technical reasons to disallow this, and may good practical
> reasons to allow this.
Fair enough; that can be done. Could even emulate /sbin/request-key upcalling
that way, with the manage
Hi,
On Thu, Jan 10, 2019 at 06:58:43PM +0100, Lubomir Rintel wrote:
> With the recent changes to the driver and addition of OLPC XO-1.75 EC
> driver it is possible to use this driver on ARM-based XO laptops as
> well.
>
> Signed-off-by: Lubomir Rintel
> ---
This looks simple enough to not cause
On Fri, Feb 15, 2019 at 12:54 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-02-14 13:37:22)
> > diff --git a/kunit/test-test.c b/kunit/test-test.c
> > index 0b4ad6690310d..bb34431398526 100644
> > --- a/kunit/test-test.c
> > +++ b/kunit/test-test.c
> [...]
> > +
> > +#define KUNIT_RESOU
Eric W. Biederman wrote:
> In fact if you take care to use a path that starts with '/' the normal
> dirfd based operations work just fine.
If the path starts with '/', dirfd is ignored. And there's an error in my
patch description - it should be:
mkdirat(cfd, "fred", 0755);
David
On Fri, Feb 15, 2019 at 1:01 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-02-14 13:37:14)
> > @@ -104,6 +167,7 @@ struct kunit {
> > const char *name; /* Read only after initialization! */
> > spinlock_t lock; /* Gaurds all mutable test state. */
> > bool succes
From: Rafael J. Wysocki
In cpufreq_update_policy(), instead of updating new_policy.cur
separately, which is kind of confusing, because cpufreq_set_policy()
doesn't take that value into account directly anyway, make the copy
of the existing policy after calling cpufreq_update_current_freq().
No i
Hi,
There are a few things related to cpufreq_set_policy() and
cpufreq_update_policy()
that increase the level of confusion thereof quite unnecessarily, so this series
attempts to clean them up. Please refer to the patch changelogs for details.
Please let me know if you see any problems with th
From: Rafael J. Wysocki
The invocation of the ->setpolicy() cpufreq driver callback should
be equivalent to calling cpufreq_governor_limits(policy) for drivers
with internal governors, but in fact it isn't so, because the
temporary new_policy object is passed to it instead of the updated
policy.
From: Rafael J. Wysocki
Remove the redundant "cpufreq:" prefix from two debug messages in
cpufreq_set_policy().
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/cpufreq.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===
From: Rafael J. Wysocki
Add kerneldoc comments describing cpufreq_set_policy() and
cpufreq_update_policy() as they have not been properly documented
so far and they really need to be documented.
While at it, fix white space around the cpufreq_set_policy() header.
Signed-off-by: Rafael J. Wysock
A release candidate Git v2.21.0-rc2 is now available for testing
at the usual places. It is comprised of 474 non-merge commits
since v2.20.0, contributed by 61 people, 16 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following pu
Hi,
On Tue, Feb 19, 2019 at 10:55:37AM -0600, Andrew F. Davis wrote:
> On 2/18/19 12:59 AM, Arthur Demchenkov wrote:
> > The flags were just read by bq27xxx_battery_update(),
> > no need to read them again.
> >
> > Signed-off-by: Arthur Demchenkov
> > ---
>
> Nothing obviously wrong with this p
On 2/18/19 12:53 AM, Alexey Brodkin wrote:
> So are you OK with this patch or something should be done before applying?
Or your original patch was
+#ifdef CONFIG_ARC_HAS_LL64
+#define ARCH_SLAB_MINALIGN 8
+#endif
I don't think this issue is related to LL64 at all. A long long on ARC could be
On Sun, Feb 17, 2019 at 1:08 AM Yong Wu wrote:
>
> The protect memory setting is a little different in the different SoCs.
> In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault
> protect) shift bit is normally 4 while it shift 5 bits only in the
> mt8173. This patch delete the c
On Sun, Feb 17, 2019 at 1:06 AM Yong Wu wrote:
>
> This patch adds decriptions for mt8183 IOMMU and SMI.
>
> mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which
> uses ARM Short-Descriptor translation table format.
>
> The mt8183 M4U-SMI HW diagram is as below:
>
>
On Sun, Feb 17, 2019 at 1:08 AM Yong Wu wrote:
>
> Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address
> range) register while mt2712 have. Move it into the plat_data.
>
> Signed-off-by: Yong Wu
Reviewed-by: Evan Green
On Sun, Feb 17, 2019 at 1:08 AM Yong Wu wrote:
>
> In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while it is
> REG_MMU_CTRL in the other SoCs, and the bits meaning is completely
> different with the REG_MMU_STANDARD_AXI_MODE.
>
> This patch moves this property to plat_data, it's also a p
On Sun, Feb 17, 2019 at 1:09 AM Yong Wu wrote:
>
> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
> mmu0 or mmu1 to balance the bandwidth via the smi-common register
> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>
> In mt8183, For better performance, we switch larb1/2/5/7
On Sun, Feb 17, 2019 at 1:08 AM Yong Wu wrote:
>
> The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> the ARM Short-descriptor like mt8173, and most of the HW registers
> are the same.
>
> Here list main differences between mt8183 and mt8173/mt2712:
> 1) mt8183 has only one M4U
On Fri, Feb 15, 2019 at 6:35 PM Frank Rowand wrote:
>
> On 2/15/19 6:18 PM, Frank Rowand wrote:
> > On 2/15/19 4:46 PM, Brendan Higgins wrote:
> >> UML supports enabling OF, and is useful for running the device tree
> >> tests, so add support for unflattening device tree blobs so we can
> >> actua
On Sun, Feb 17, 2019 at 1:07 AM Yong Wu wrote:
>
> MediaTek extend the arm v7s descriptor to support the dram over 4GB.
>
> In the mt2712 and mt8173, it's called "4GB mode", the physical address
> is from 0x4000_ to 0x1_3fff_, but from EMI point of view, it
> is remapped to high address fr
On Sun, Feb 17, 2019 at 1:09 AM Yong Wu wrote:
>
> The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
> It's no need to parse it again in SMI driver. Only clean some codes.
> This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
> and mt8183.
>
> After this patch, t
On Mon, Feb 11, 2019 at 03:38:59PM +0100, Petr Mladek wrote:
> On Mon 2019-02-11 13:50:35, Andrea Parri wrote:
> > Hi Michael,
> >
> >
> > On Thu, Feb 07, 2019 at 11:46:29PM +1100, Michael Ellerman wrote:
> > > Arch code can set a "dump stack arch description string" which is
> > > displayed with
On Sun, Feb 17, 2019 at 1:09 AM Yong Wu wrote:
>
> This patch only rename the variable name from enable_4GB to
> dram_is_4gb for readable.
>
> Signed-off-by: Yong Wu
Nice, this is clearer.
Reviewed-by: Evan Green
On Sun, Feb 17, 2019 at 1:09 AM Yong Wu wrote:
>
> In the 4GB mode, the physical address is remapped,
>
> Here is the detailed remap relationship.
> CPU PA ->HW PA
> 0x4000_ 0x1_4000_ (Add bit32)
> 0x8000_ 0x1_8000_ ...
> 0xc000_ 0x1_c000_
Eric W. Biederman wrote:
> So you missed the main mailing lists for discussion of this kind of
> thing
Yeah, sorry about that. I was primarily aiming it at Trond and Steve as I'd
like to consider how to go about interpolating request_key() into NFS and CIFS
so that they can make use of the key-
Hi,
On Fri, Feb 08, 2019 at 04:24:35PM +0100, Alexandre Belloni wrote:
> On 06/02/2019 19:12:21+0100, Nicolas Ferre wrote:
> > Add support for additional reset causes and the proper compatibility
> > string for sam9x60 SoC. The restart function is the same as the samx7.
> >
> > Signed-off-by: Nic
On 2/18/19 1:27 AM, Michal Hocko wrote:
> On Sat 16-02-19 21:31:12, Jingxiangfeng wrote:
>> From: Jing Xiangfeng
>>
>> We can use the following command to dynamically allocate huge pages:
>> echo NR_HUGEPAGES > /proc/sys/vm/nr_hugepages
>> The count in __nr_hugepages_store_common() is parsed
On Wed, Feb 20, 2019 at 5:09 AM Mattias Jacobsson <2...@mok.nu> wrote:
>
> Hi Masahiro,
>
> On 2019-02-18, Masahiro Yamada wrote:
> > Hi Mattias,
> >
> > On Thu, Feb 7, 2019 at 9:31 PM Mattias Jacobsson <2...@mok.nu> wrote:
> > >
> > > The size of the variable alias provided to do_entry functions a
Hey Matt,
Did you intend that xa_release doesn't work on allocating arrays:
xa_init_flags(&xa, XA_FLAGS_ALLOC);
xa_reserve(&xa, 0, GFP_KERNEL);
WARN_ON(xa_empty(&xa));
xa_release(&xa, 0);
WARN_ON(!xa_empty(&xa));
Triggers the second WARN_ON.
If FLAGS_ALL
UML supports enabling OF, and is useful for running the device tree
tests, so add support for unflattening device tree blobs so we can
actually use it.
Signed-off-by: Brendan Higgins
---
drivers/of/unittest.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/of/unittest.c b/drivers
On Fri, Feb 15, 2019 at 04:07:33PM +, David Howells wrote:
> ==
> FUTURE DEVELOPMENT
> ==
>
> (1) Setting up the container.
>
> A container would be created with, say:
>
> int cfd = container_create("fred", CONTAINER_NEW_EMPTY_FS_NS);
>
...
>
On Mon, Feb 18, 2019 at 11:32 PM Borislav Petkov wrote:
>
> On Mon, Feb 18, 2019 at 06:10:57PM +0900, Masahiro Yamada wrote:
> > Could you send v2 as I suggested?
> > Your commit log describes your motivation perfectly.
> >
> > (I lost the applicable patch because
> > I just modified the code loca
Hi Mauro,
It seems most (if not all) of the commits in the v4l-dvb-next tree are
also in the v4l-dvb tree and are now causing lots of conflicts when I
merge them both. Please clean it up.
--
Cheers,
Stephen Rothwell
pgpsRe5JlxQKk.pgp
Description: OpenPGP digital signature
On Tue, Feb 19, 2019 at 05:31:10PM +, Julien Grall wrote:
> Hi all,
>
> I have been looking at using Linux RT in Dom0. Once the guest is started,
> the console is ending to have a lot of warning (see trace below).
>
> After some investigation, this is because the irq handler will now be
> th
The ycbcr2rgb and inverse rgb2ycbcr tables define the BT.601 Y'CbCr
encoding coefficients.
The rgb2ycbcr table specifically describes the BT.601 encoding from
full range RGB to full range YUV. Add table comments to make this more
clear.
The ycbcr2rgb inverse table describes encoding YUV limited r
Add support for Rec.709 encoding and inverse encoding.
The determination of the CSC coefficients based on the input/output
colorspace parameters are moved to a new function calc_csc_coeffs().
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v5:
- moved API changes to a pre
Only providing the input and output RGB/YUV space to the IC task init
functions is not sufficient. To fully characterize a colorspace
conversion, the colorspace (chromaticities), Y'CbCr encoding standard,
and quantization also need to be specified.
Define a 'struct ipu_ic_colorspace' that includes
Add support for the following conversions:
- YUV full-range to YUV limited-range
- YUV limited-range to YUV full-range
- YUV limited-range to RGB full-range
- RGB full-range to YUV limited-range
The last two conversions require operating on the YUV full-range
encoding and inverse encoding coeffic
The saturation bit was being set at bit 9 in the second 32-bit word
of the TPMEM CSC. This isn't correct, the saturation bit is bit 42,
which is bit 10 of the second word.
Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")
Signed-off-by: Steve Longerbeam
Cc: sta...@vger.kernel.org
--
On Fri, 2019-02-15 at 11:43 -0800, Dan Williams wrote:
> Changes since v1: [1]
> * Fix the root poll interval support to avoid a infinite loop condition
> when the polling is faster than the ARS completion.
> * Move the introduction of scrub_flags earlier in the series and
> introduce ARS_POLL
The colorimetry parameters need to be tested at both sink and source
pads. Specifically, for prpencvf, the IC only supports RGB full-range
quantization at input and output.
Fix this by cleaning up imx_media_fill_default_mbus_fields(), renaming
to imx_media_try_colorimetry(), and call it at both si
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601
encoding, so allow both, for pipelines that route through the IC.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v5:
- rebased this patch on top of repurposing the function to
imx_media_try_color
Em Wed, 20 Feb 2019 10:57:03 +1100
Stephen Rothwell escreveu:
> Hi Mauro,
>
> It seems most (if not all) of the commits in the v4l-dvb-next tree are
> also in the v4l-dvb tree and are now causing lots of conflicts when I
> merge them both. Please clean it up.
>
Yeah, it had some branches that
On Tue, Feb 19, 2019 at 07:38:10PM +0100, Jonas Rabenstein wrote:
> Whenever a callchain shall be printed search for each address whether
> inline information is available and add those symbols to the output
> if symbol_conf.inline_name is enabled.
>
> Signed-off-by: Jonas Rabenstein
> ---
> too
On 2/18/19 6:42 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.175 release.
There are 143 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 2/18/19 6:42 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.24 release.
There are 85 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 2/18/19 6:42 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.20.11 release.
There are 92 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 2/18/19 6:42 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.135 release.
There are 108 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be mad
On 2/18/19 6:43 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.102 release.
There are 62 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 2/18/19 6:43 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.159 release.
There are 58 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
Hi Mauro,
On Tue, 19 Feb 2019 21:10:33 -0300 Mauro Carvalho Chehab
wrote:
>
> Yeah, it had some branches that got already merged.
>
> Just updated it to be in sync with v4l-dvb tree.
>
> Sorry for the mess.
No worries and thanks.
--
Cheers,
Stephen Rothwell
pgp8aAePpaHMj.pgp
Description:
The pull request you sent on Tue, 19 Feb 2019 14:33:26 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git refs/heads/master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/40e196a906d969fd10d885c692d2674b3d657006
Thank you!
--
Deet-doot-dot, I
Hi Avri,
> A kind reminder.
It's expired from patchwork so now is an excellent time to repost.
Generally speaking, resubmitting patches is superior to pinging. While I
personally dig through the archives to revisit older patches, I can
almost guarantee that no other potential reviewers will do
On Tue, Feb 19, 2019 at 2:43 PM Nick Desaulniers
wrote:
>
> + Evgenii, Kostya for KASAN
>
> On Tue, Feb 19, 2019 at 2:17 PM Qian Cai wrote:
> >
> > On Tue, 2019-02-19 at 22:49 +0100, Arnd Bergmann wrote:
> > > Building an arm64 allmodconfig kernel with clang results in over 140
> > > warnings
>
> -Original Message-
> From: Chen, Rong A
> Sent: Sunday, February 17, 2019 5:36 PM
> To: Moore, Robert
> Cc: Wysocki, Rafael J ; Schmauss, Erik
> ; LKML ; Linus
> Torvalds ; l...@01.org
> Subject: [LKP] [ACPICA] 4c1379d7bb: reaim.jobs_per_min -2.8% regression
>
> Greeting,
>
> FYI, we
On 2/19/19 2:52 AM, Eugeniy Paltsev wrote:
> Signed-off-by: Eugeniy Paltsev
> ---
> NOTE:
> Even if this patch have no logical dependency with gpu-enabling-patch
> (http://patchwork.ozlabs.org/patch/1034722/)
> gpu-enabling-patch should be applied first to avoid rebasing.
Can you pester the
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
tools/testing/selftests/bpf/test_progs.c
between commit:
f6be4d16039b ("selftests/bpf: make sure signal interrupts BPF_PROG_TEST_RUN")
from the bpf tree and commits:
bf0f0fd93945 ("selftests/bpf: add simple BPF_PRO
On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> tools/testing/selftests/bpf/test_progs.c
>
> between commit:
>
> f6be4d16039b ("selftests/bpf: make sure signal interrupts
> BPF_PROG_TEST_RUN")
Ouch.
Hello,
Re: Business proposition for you.
I have a client in Russia who will like to invest with your
company. My client is willing to invest $10 Million to $50
million. Can I have your company website to show to my client
your company so that they will check and decide if they will
invest th
On Tue, Feb 19, 2019 at 4:41 PM Alexei Starovoitov
wrote:
>
> On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > Today's linux-next merge of the net-next tree got a conflict in:
> >
> > tools/testing/selftests/bpf/test_progs.c
> >
> > between commit:
> >
> > f6
On Sun, 2019-02-17 at 08:30 +0200, Avri Altman wrote:
> Those are no longer in use since commit 242f9dcb8ba6
> ("block: unify request timeout handling").
Reviewed-by: Bart Van Assche
Hi all,
Commits
f180bf12ac06 ("drm/nouveau/svm: new ioctl to migrate process memory to GPU
memory")
5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM")
are missing a Signed-off-by from their committer.
--
Cheers,
Stephen Rothwell
pgpCFDdYfJh58.pgp
Description: OpenPGP digit
Several recent exploits have used direct calls to the native_write_cr4()
function to disable SMEP and SMAP before then continuing their exploits
using userspace memory access. This pins bits of cr4 so that they cannot
be changed through a common function. This is not intended to be general
ROP prot
Hello,
Greetings,
I represent business group in Middle East looking for projects to
fund; we seek any business that will guaranty a safe and secure
return on investments. Alternative powers, movies, start up
companies etc. We are also looking for commercial building
projects, hotels, casino
701 - 800 of 1032 matches
Mail list logo
