* Re: [PATCH RESEND] kthread, tracing: Don't expose half-written comm when creating kthreads
From: Snild Dolkow @ 2018-07-23 14:23 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, Ingo Molnar, Jens Axboe, Tejun Heo,
Greg Kroah-Hartman, Linus Torvalds, Peter Enderborg,
Yoshitaka Seto, Oleksiy Avramchenko, KOSAKI Motohiro, John Stultz
In-Reply-To: <20180723095550.08203a24@gandalf.local.home>
On 07/23/2018 03:55 PM, Steven Rostedt wrote:
> Can you add a comment here stating something to the affect of:
> /* task is now visible to other tasks */
>
> -- Steve
Sure, but isn't that a bit misleading? It will have been visible since
some unknown point in time between waking up kthreadd and the return of
wait_for_completion(); we're not the ones making it visible.
//Snild
^ permalink raw reply
* [PATCH] clk: fix apss cpu overclocking
From: John Crispin @ 2018-07-23 14:23 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Andy Gross, David Brown
Cc: linux-arm-msm, linux-soc, linux-clk, Christian Lamparter,
Christian Lamparter, John Crispin
From: Christian Lamparter <chunkeey@googlemail.com>
There's an interaction issue between the clk changes:"
clk: qcom: ipq4019: Add the apss cpu pll divider clock node
clk: qcom: ipq4019: remove fixed clocks and add pll clocks
" and the cpufreq-dt.
cpufreq-dt is now spamming the kernel-log with the following:
[ 1099.190658] cpu cpu0: dev_pm_opp_set_rate: failed to find current OPP
for freq 761142857 (-34)
This only happens on certain devices like the Compex WPJ428
and AVM FritzBox!4040. However, other devices like the Asus
RT-AC58U and Meraki MR33 work just fine.
The issue stem from the fact that all higher CPU-Clocks
are achieved by switching the clock-parent to the P_DDRPLLAPSS
(ddrpllapss). Which is set by Qualcomm's proprietary bootcode
as part of the DDR calibration.
For example, the FB4040 uses 256 MiB Nanya NT5CC128M16IP clocked
at round 533 MHz (ddrpllsdcc = 190285714 Hz).
whereas the 128 MiB Nanya NT5CC64M16GP-DI in the ASUS RT-AC58U is
clocked at a slightly higher 537 MHz ( ddrpllsdcc = 192000000 Hz).
This patch attempts to fix the issue by modifying
clk_cpu_div_round_rate(), clk_cpu_div_set_rate(), clk_cpu_div_recalc_rate()
to use a new qcom_find_freq_close() function, which returns the closest
matching frequency, instead of the next higher. This way, the SoC in
the FB4040 (with its max clock speed of 710.4 MHz) will no longer
try to overclock to 761 MHz.
Fixes: d83dcacea18 ("clk: qcom: ipq4019: Add the apss cpu pll divider clock node")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: John Crispin <john@phrozen.org>
---
drivers/clk/qcom/gcc-ipq4019.c | 34 +++++++++++++++++++++++++++++++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index 46cb256b4aa2..4ec43f7d2e52 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -1253,6 +1253,29 @@ static const struct clk_fepll_vco gcc_fepll_vco = {
.reg = 0x2f020,
};
+
+const struct freq_tbl *qcom_find_freq_close(const struct freq_tbl *f,
+ unsigned long rate)
+{
+ const struct freq_tbl *last = NULL;
+
+ for ( ; f->freq; f++) {
+ if (rate == f->freq)
+ return f;
+
+ if (f->freq > rate) {
+ if (!last ||
+ (f->freq - rate) < (rate - last->freq))
+ return f;
+ else
+ return last;
+ }
+ last = f;
+ }
+
+ return last;
+}
+
/*
* Round rate function for APSS CPU PLL Clock divider.
* It looks up the frequency table and returns the next higher frequency
@@ -1265,7 +1288,7 @@ static long clk_cpu_div_round_rate(struct clk_hw *hw, unsigned long rate,
struct clk_hw *p_hw;
const struct freq_tbl *f;
- f = qcom_find_freq(pll->freq_tbl, rate);
+ f = qcom_find_freq_close(pll->freq_tbl, rate);
if (!f)
return -EINVAL;
@@ -1288,7 +1311,7 @@ static int clk_cpu_div_set_rate(struct clk_hw *hw, unsigned long rate,
u32 mask;
int ret;
- f = qcom_find_freq(pll->freq_tbl, rate);
+ f = qcom_find_freq_close(pll->freq_tbl, rate);
if (!f)
return -EINVAL;
@@ -1315,6 +1338,7 @@ static unsigned long
clk_cpu_div_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
+ const struct freq_tbl *f;
struct clk_fepll *pll = to_clk_fepll(hw);
u32 cdiv, pre_div;
u64 rate;
@@ -1335,7 +1359,11 @@ clk_cpu_div_recalc_rate(struct clk_hw *hw,
rate = clk_fepll_vco_calc_rate(pll, parent_rate) * 2;
do_div(rate, pre_div);
- return rate;
+ f = qcom_find_freq_close(pll->freq_tbl, rate);
+ if (!f)
+ return rate;
+
+ return f->freq;
};
static const struct clk_ops clk_regmap_cpu_div_ops = {
--
2.11.0
^ permalink raw reply related
* [Bug 107341] [CI][BAT] igt@amdgpu/amd_prime@amd-to-i915 - fail - Failed assertion: __vgem_fence_signal(fd, fence) == 0 due to setup time taking longer than 10s
From: bugzilla-daemon @ 2018-07-23 14:22 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-107341-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 377 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=107341
Martin Peres <martin.peres@free.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Whiteboard| |ReadyForDev
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Bug 107341] [CI][BAT] igt@amdgpu/amd_prime@amd-to-i915 - fail - Failed assertion: __vgem_fence_signal(fd, fence) == 0 due to setup time taking longer than 10s
From: bugzilla-daemon @ 2018-07-23 14:22 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1206 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=107341
Bug ID: 107341
Summary: [CI][BAT] igt@amdgpu/amd_prime@amd-to-i915 - fail -
Failed assertion: __vgem_fence_signal(fd, fence) == 0
due to setup time taking longer than 10s
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: IGT
Assignee: dri-devel@lists.freedesktop.org
Reporter: martin.peres@free.fr
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4519/fi-kbl-8809g/igt@amdgpu_amd_prime@amd-to-i915.html
(amd_prime:4831) igt_vgem-CRITICAL: Test assertion failure function
vgem_fence_signal, file ../lib/igt_vgem.c:193:
(amd_prime:4831) igt_vgem-CRITICAL: Failed assertion: __vgem_fence_signal(fd,
fence) == 0
(amd_prime:4831) igt_vgem-CRITICAL: error: -110 != 0
Subtest amd-to-i915 failed.
Chris already commented that "We need to tune the setup to run within 10s or
use a sw_sync fence instead of a vgem plug."
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2718 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH bpf] xdp: add NULL pointer check in __xdp_return()
From: Taehee Yoo @ 2018-07-23 13:21 UTC (permalink / raw)
To: Björn Töpel
Cc: Martin KaFai Lau, Daniel Borkmann, ast, Björn Töpel,
Jesper Dangaard Brouer, Netdev
In-Reply-To: <CAJ+HfNiq=PNRz_Y8NJYuz=f33dmbu4nLM432ktBzPXTOSSTsMQ@mail.gmail.com>
2018-07-23 18:41 GMT+09:00 Björn Töpel <bjorn.topel@gmail.com>:
> Den lör 21 juli 2018 kl 14:58 skrev Taehee Yoo <ap420073@gmail.com>:
>>
>> 2018-07-21 2:18 GMT+09:00 Martin KaFai Lau <kafai@fb.com>:
>> > On Sat, Jul 21, 2018 at 01:04:45AM +0900, Taehee Yoo wrote:
>> >> rhashtable_lookup() can return NULL. so that NULL pointer
>> >> check routine should be added.
>> >>
>> >> Fixes: 02b55e5657c3 ("xdp: add MEM_TYPE_ZERO_COPY")
>> >> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
>> >> ---
>> >> net/core/xdp.c | 3 ++-
>> >> 1 file changed, 2 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/net/core/xdp.c b/net/core/xdp.c
>> >> index 9d1f220..1c12bc7 100644
>> >> --- a/net/core/xdp.c
>> >> +++ b/net/core/xdp.c
>> >> @@ -345,7 +345,8 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
>> >> rcu_read_lock();
>> >> /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
>> >> xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
>> >> - xa->zc_alloc->free(xa->zc_alloc, handle);
>> >> + if (xa)
>> >> + xa->zc_alloc->free(xa->zc_alloc, handle);
>> > hmm...It is not clear to me the "!xa" case don't have to be handled?
>>
>> Thank you for reviewing!
>>
>> Returning NULL pointer is bug case such as calling after use
>> xdp_rxq_info_unreg().
>> so that, I think it can't handle at that moment.
>> we can make __xdp_return to add WARN_ON_ONCE() or
>> add return error code to driver.
>> But I'm not sure if these is useful information.
>>
>> I might have misunderstood scenario of MEM_TYPE_ZERO_COPY
>> because there is no use case of MEM_TYPE_ZERO_COPY yet.
>>
>
> Taehee, again, sorry for the slow response and thanks for patch!
>
> If xa is NULL, the driver has a buggy/broken implementation. What
> would be a proper way of dealing with this? BUG?
>
Thank you for reviewing!
I would like to add WARN_ON_ONCE. because code writers can
get opportunity for debugging this in runtime. also I think this bug
doesn't make critical side effect.
Thanks!
>
> Björn
>
>> Thanks!
>>
>> >
>> >> rcu_read_unlock();
>> >> default:
>> >> /* Not possible, checked in xdp_rxq_info_reg_mem_model() */
>> >> --
>> >> 2.9.3
>> >>
^ permalink raw reply
* Re: [PATCH] x86/spec-ctrl: Fix the parsing of xpti= on fixed Intel hardware
From: Juergen Gross @ 2018-07-23 14:22 UTC (permalink / raw)
To: Andrew Cooper, Xen-devel
Cc: Sergey Dyasli, Wei Liu, Jan Beulich, Roger Pau Monné
In-Reply-To: <1532353682-28335-1-git-send-email-andrew.cooper3@citrix.com>
On 23/07/18 15:48, Andrew Cooper wrote:
> The calls to xpti_init_default() in parse_xpti() are buggy. The CPUID data
> hasn't been fetched that early, and boot_cpu_has(X86_FEATURE_ARCH_CAPS) will
> always evaluate false.
>
> As a result, the default case won't disable XPTI on Intel hardware which
> advertises ARCH_CAPABILITIES_RDCL_NO.
>
> Simplify parse_xpti() to solely the setting of opt_xpti according to the
> passed string, and have init_speculation_mitigations() call
> xpti_init_default() if appropiate. Drop the force parameter, and pass caps
> instead, to avoid redundant re-reading of MSR_ARCH_CAPS.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] serial: 8250_ingenic: Add support for the JZ4725B SoC
From: Rob Herring @ 2018-07-23 14:22 UTC (permalink / raw)
To: Paul Cercueil
Cc: Greg Kroah-Hartman, Mark Rutland, Jiri Slaby,
open list:SERIAL DRIVERS, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <1532113088.2309.0@smtp.crapouillou.net>
On Fri, Jul 20, 2018 at 12:58 PM Paul Cercueil <paul@crapouillou.net> wrote:
>
> Hi Rob,
>
> Le ven. 20 juil. 2018 à 17:30, Rob Herring <robh@kernel.org> a écrit :
> > On Fri, Jul 13, 2018 at 04:38:40PM +0200, Paul Cercueil wrote:
> >> The UART in the jz4725b works just like in the other JZ SoCs, so
> >> this
> >> commit simply adds a new compatible string.
> >>
> >> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> >> ---
> >> Documentation/devicetree/bindings/serial/ingenic,uart.txt | 1 +
> >> drivers/tty/serial/8250/8250_ingenic.c | 5 +++++
> >> 2 files changed, 6 insertions(+)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/serial/ingenic,uart.txt
> >> b/Documentation/devicetree/bindings/serial/ingenic,uart.txt
> >> index c3c6406d5cfe..a0b34fd3b602 100644
> >> --- a/Documentation/devicetree/bindings/serial/ingenic,uart.txt
> >> +++ b/Documentation/devicetree/bindings/serial/ingenic,uart.txt
> >> @@ -3,6 +3,7 @@
> >> Required properties:
> >> - compatible : One of:
> >> - "ingenic,jz4740-uart",
> >> + - "ingenic,jz4725b-uart",
> >> - "ingenic,jz4760-uart",
> >> - "ingenic,jz4770-uart",
> >> - "ingenic,jz4775-uart",
> >> diff --git a/drivers/tty/serial/8250/8250_ingenic.c
> >> b/drivers/tty/serial/8250/8250_ingenic.c
> >> index 15a8c8dfa92b..760266559a5a 100644
> >> --- a/drivers/tty/serial/8250/8250_ingenic.c
> >> +++ b/drivers/tty/serial/8250/8250_ingenic.c
> >> @@ -133,6 +133,10 @@ EARLYCON_DECLARE(jz4740_uart,
> >> ingenic_early_console_setup);
> >> OF_EARLYCON_DECLARE(jz4740_uart, "ingenic,jz4740-uart",
> >> ingenic_early_console_setup);
> >>
> >> +EARLYCON_DECLARE(jz4725b_uart, ingenic_early_console_setup);
> >> +OF_EARLYCON_DECLARE(jz4725b_uart, "ingenic,jz4725b-uart",
> >> + ingenic_early_console_setup);
> >> +
> >
> > This shouldn't be necessary. Looks like it should be compatible with
> > ingenic,jz4740-uart.
> >
> >> EARLYCON_DECLARE(jz4770_uart, ingenic_early_console_setup);
> >> OF_EARLYCON_DECLARE(jz4770_uart, "ingenic,jz4770-uart",
> >> ingenic_early_console_setup);
> >> @@ -330,6 +334,7 @@ static const struct ingenic_uart_config
> >> jz4780_uart_config = {
> >>
> >> static const struct of_device_id of_match[] = {
> >> { .compatible = "ingenic,jz4740-uart", .data =
> >> &jz4740_uart_config },
> >> + { .compatible = "ingenic,jz4725b-uart", .data =
> >> &jz4740_uart_config },
> >
> > And this too.
>
> Well, I'm confused, the driver already uses multiple compatible strings
> for SoCs that
> work the exact same, so that was wrong?
Not wrong, but not necessary. Given that the data was the same was the
clue telling me that they should be compatible.
Rob
^ permalink raw reply
* Re: [PATCH] Btrfs: fix btrfs_write_inode() vs delayed iput deadlock
From: David Sterba @ 2018-07-23 13:20 UTC (permalink / raw)
To: Omar Sandoval; +Cc: linux-btrfs, kernel-team, David Sterba
In-Reply-To: <d0e0a0ac06a6479fd305c170cb64a33f3b16ff93.1532112361.git.osandov@fb.com>
On Fri, Jul 20, 2018 at 11:46:10AM -0700, Omar Sandoval wrote:
> From: Josef Bacik <jbacik@fb.com>
>
> We recently ran into the following deadlock involving
> btrfs_write_inode():
>
> [ +0.005066] __schedule+0x38e/0x8c0
> [ +0.007144] schedule+0x36/0x80
> [ +0.006447] bit_wait+0x11/0x60
> [ +0.006446] __wait_on_bit+0xbe/0x110
> [ +0.007487] ? bit_wait_io+0x60/0x60
> [ +0.007319] __inode_wait_for_writeback+0x96/0xc0
> [ +0.009568] ? autoremove_wake_function+0x40/0x40
> [ +0.009565] inode_wait_for_writeback+0x21/0x30
> [ +0.009224] evict+0xb0/0x190
> [ +0.006099] iput+0x1a8/0x210
> [ +0.006103] btrfs_run_delayed_iputs+0x73/0xc0
> [ +0.009047] btrfs_commit_transaction+0x799/0x8c0
> [ +0.009567] btrfs_write_inode+0x81/0xb0
> [ +0.008008] __writeback_single_inode+0x267/0x320
> [ +0.009569] writeback_sb_inodes+0x25b/0x4e0
> [ +0.008702] wb_writeback+0x102/0x2d0
> [ +0.007487] wb_workfn+0xa4/0x310
> [ +0.006794] ? wb_workfn+0xa4/0x310
> [ +0.007143] process_one_work+0x150/0x410
> [ +0.008179] worker_thread+0x6d/0x520
> [ +0.007490] kthread+0x12c/0x160
> [ +0.006620] ? put_pwq_unlocked+0x80/0x80
> [ +0.008185] ? kthread_park+0xa0/0xa0
> [ +0.007484] ? do_syscall_64+0x53/0x150
> [ +0.007837] ret_from_fork+0x29/0x40
>
> Writeback calls btrfs_write_inode(), which calls
> btrfs_commit_transaction(), which calls btrfs_run_delayed_iputs(). If
> iput() is called on that same inode, evict() will wait for writeback
> forever.
>
> btrfs_write_inode() was originally added way back in 4730a4bc5bf3
> ("btrfs_dirty_inode") to support O_SYNC writes. However, ->write_inode()
> hasn't been used for O_SYNC since 148f948ba877 ("vfs: Introduce new
> helpers for syncing after writing to O_SYNC file or IS_SYNC inode"), so
> btrfs_write_inode() is actually unnecessary (and leads to a bunch of
> unnecessary commits). Get rid of it, which also gets rid of the
> deadlock.
>
> Signed-off-by: Josef Bacik <jbacik@fb.com>
> [Omar: new commit message]
> Signed-off-by: Omar Sandoval <osandov@fb.com>
Thank, added to current 4.19 queue and I'll add tags for stable.
^ permalink raw reply
* [PATCH] firewire: init_ohci1394_dma: Replace mdelay with msleep
From: Jia-Ju Bai @ 2018-07-23 14:21 UTC (permalink / raw)
To: stefanr; +Cc: linux1394-devel, linux-kernel, Jia-Ju Bai
init_ohci1394_wait_for_busresets() and
init_ohci1394_reset_and_init_dma() are never called in atomic context.
They call mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/firewire/init_ohci1394_dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firewire/init_ohci1394_dma.c b/drivers/firewire/init_ohci1394_dma.c
index 2cc89ce745c9..6b5a3c12f715 100644
--- a/drivers/firewire/init_ohci1394_dma.c
+++ b/drivers/firewire/init_ohci1394_dma.c
@@ -192,7 +192,7 @@ static inline void __init init_ohci1394_wait_for_busresets(struct ohci *ohci)
int i, events;
for (i = 0; i < 9; i++) {
- mdelay(200);
+ msleep(200);
events = reg_read(ohci, OHCI1394_IntEventSet);
if (events & OHCI1394_busReset)
reg_write(ohci, OHCI1394_IntEventClear,
@@ -228,7 +228,7 @@ static inline void __init init_ohci1394_reset_and_init_dma(struct ohci *ohci)
reg_write(ohci, OHCI1394_IntEventClear, 0xffffffff);
reg_write(ohci, OHCI1394_IntMaskClear, 0xffffffff);
- mdelay(50); /* Wait 50msec to make sure we have full link enabled */
+ msleep(50); /* Wait 50msec to make sure we have full link enabled */
init_ohci1394_initialize(ohci);
/*
--
2.17.0
^ permalink raw reply related
* [Bug 106707] [CI] igt@gem_exec_schedule@deep-* - fail - Failed assertion: __vgem_fence_signal(fd, fence) == 0
From: bugzilla-daemon @ 2018-07-23 14:20 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-106707-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 1320 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=106707
--- Comment #9 from Martin Peres <martin.peres@free.fr> ---
(In reply to Chris Wilson from comment #8)
> (In reply to Martin Peres from comment #7)
> > (In reply to Chris Wilson from comment #6)
> > > (In reply to Martin Peres from comment #5)
> > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4519/fi-kbl-8809g/
> > > > igt@amdgpu_amd_prime@amd-to-i915.html
> > > >
> > > > (amd_prime:4831) igt_vgem-CRITICAL: Test assertion failure function
> > > > vgem_fence_signal, file ../lib/igt_vgem.c:193:
> > > > (amd_prime:4831) igt_vgem-CRITICAL: Failed assertion:
> > > > __vgem_fence_signal(fd, fence) == 0
> > > > (amd_prime:4831) igt_vgem-CRITICAL: error: -110 != 0
> > > > Subtest amd-to-i915 failed.
> > >
> > > Not a common problem. These are individual test setups that are just too
> > > slow on CI.
> >
> > Not sure I understand your explanation. Can you rephrase?
> >
> > Also, what would you suggest I do for this issue? Should I create a new bug?
>
> It's a separate issue for the amdgpu_amd_prime test. We need to tune the
> setup to run within 10s or use a sw_sync fence instead of a vgem plug.
Thanks! I will create a new IGT bug then :)
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2736 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] rtc: jz4740: Add support for the JZ4725B, JZ4760, JZ4770
From: Paul Cercueil @ 2018-07-23 14:20 UTC (permalink / raw)
To: Rob Herring
Cc: Alexandre Belloni, Alessandro Zummo, Mark Rutland,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqKrJC7v79L89PCP-hihYLSNjp05xMxQQaVZPLPk26MuHw@mail.gmail.com>
Hi,
Le lun. 23 juil. 2018 à 16:18, Rob Herring <robh@kernel.org> a écrit :
> On Fri, Jul 20, 2018 at 1:04 PM Paul Cercueil <paul@crapouillou.net>
> wrote:
>>
>> Hi,
>>
>> Le ven. 20 juil. 2018 à 17:39, Rob Herring <robh@kernel.org> a
>> écrit :
>> > On Sat, Jul 14, 2018 at 03:50:08PM +0200, Paul Cercueil wrote:
>> >>
>> >>
>> >> Le sam. 14 juil. 2018 à 15:32, Alexandre Belloni
>> >> <alexandre.belloni@bootlin.com> a écrit :
>> >> > On 14/07/2018 15:25:33+0200, Paul Cercueil wrote:
>> >> > > Hi Alexandre,
>> >> > >
>> >> > > Le sam. 14 juil. 2018 à 15:19, Alexandre Belloni
>> >> > > <alexandre.belloni@bootlin.com> a écrit :
>> >> > > > Hello,
>> >> > > >
>> >> > > > On 13/07/2018 17:14:24+0200, Paul Cercueil wrote:
>> >> > > > > The RTC in the JZ4725B works just like the one in the
>> >> JZ4740.
>> >> > > > >
>> >> > > > > The RTC in the JZ4760 and JZ4770 work just like the
>> one
>> >> in the
>> >> > > > > JZ4780.
>> >> > > > >
>> >> > > > > Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> >> > > > > ---
>> >> > > > >
>> >> Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
>> >> > > | 3
>> >> > > > > +++
>> >> > > > > drivers/rtc/rtc-jz4740.c
>> >> > > | 11
>> >> > > > > ++++++++++-
>> >> > > > > 2 files changed, 13 insertions(+), 1 deletion(-)
>> >> > > > >
>> >> > > > > diff --git
>> >> > > > >
>> >> a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
>> >> > > > >
>> >> b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
>> >> > > > > index 41c7ae18fd7b..a9e821de84f2 100644
>> >> > > > > ---
>> >> > >
>> a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
>> >> > > > > +++
>> >> > >
>> b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
>> >> > > > > @@ -4,6 +4,9 @@ Required properties:
>> >> > > > >
>> >> > > > > - compatible: One of:
>> >> > > > > - "ingenic,jz4740-rtc" - for use with the JZ4740
>> SoC
>> >> > > > > + - "ingenic,jz4725b-rtc" - for use with the JZ4725B
>> SoC
>> >> > > > > + - "ingenic,jz4760-rtc" - for use with the JZ4760
>> SoC
>> >> > > > > + - "ingenic,jz4770-rtc" - for use with the JZ4770
>> SoC
>> >> > > > > - "ingenic,jz4780-rtc" - for use with the JZ4780
>> SoC
>> >> > > > > - reg: Address range of rtc register set
>> >> > > > > - interrupts: IRQ number for the alarm interrupt
>> >> > > > > diff --git a/drivers/rtc/rtc-jz4740.c
>> >> > > b/drivers/rtc/rtc-jz4740.c
>> >> > > > > index d0a891777f44..1c867e3a0ea5 100644
>> >> > > > > --- a/drivers/rtc/rtc-jz4740.c
>> >> > > > > +++ b/drivers/rtc/rtc-jz4740.c
>> >> > > > > @@ -54,6 +54,9 @@
>> >> > > > >
>> >> > > > > enum jz4740_rtc_type {
>> >> > > > > ID_JZ4740,
>> >> > > > > + ID_JZ4725B,
>> >> > > > > + ID_JZ4760,
>> >> > > > > + ID_JZ4770,
>> >> > > >
>> >> > > > I wouldn't introduce those ids unless there are handling
>> >> > > differences at
>> >> > > > some point.
>> >> > >
>> >> > > Well there are handling differences, see below.
>> >> > >
>> >> > > > > ID_JZ4780,
>> >> > > > > };
>> >> > > > >
>> >> > > > > @@ -114,7 +117,7 @@ static inline int
>> >> > > jz4740_rtc_reg_write(struct
>> >> > > > > jz4740_rtc *rtc, size_t reg,
>> >> > > > > {
>> >> > > > > int ret = 0;
>> >> > > > >
>> >> > > > > - if (rtc->type >= ID_JZ4780)
>> >> > > > > + if (rtc->type >= ID_JZ4760)
>> >> > > >
>> >> > > > This would avoid that change (and the test would
>> preferably
>> >> be
>> >> > > > (rtc->type == ID_JZ4780))
>> >> > >
>> >> > > That branch should be taken if the SoC is JZ4760, JZ4770 or
>> >> JZ4780.
>> >> > > It should not be taken if the SoC is JZ4740 or JZ4725B.
>> >> >
>> >> > Sure but you can achieve that with only 2 ids...
>> >> >
>> >> > >
>> >> > > > > ret = jz4780_rtc_enable_write(rtc);
>> >> > > > > if (ret == 0)
>> >> > > > > ret = jz4740_rtc_wait_write_ready(rtc);
>> >> > > > > @@ -300,6 +303,9 @@ static void
>> jz4740_rtc_power_off(void)
>> >> > > > >
>> >> > > > > static const struct of_device_id
>> jz4740_rtc_of_match[] =
>> >> {
>> >> > > > > { .compatible = "ingenic,jz4740-rtc", .data = (void
>> >> > > *)ID_JZ4740 },
>> >> > > > > + { .compatible = "ingenic,jz4725b-rtc", .data = (void
>> >> > > *)ID_JZ4725B
>> >> > > > > },
>> >> > > > > + { .compatible = "ingenic,jz4760-rtc", .data = (void
>> >> > > *)ID_JZ4760 },
>> >> > > > > + { .compatible = "ingenic,jz4770-rtc", .data = (void
>> >> > > *)ID_JZ4770 },
>> >> >
>> >> > By doing the correct mapping here e.g:
>> >> >
>> >> > { .compatible = "ingenic,jz4725b-rtc", .data = (void
>> *)ID_JZ4740
>> >> },
>> >>
>> >> Not very pretty and future-proof if you ask me...
>> >
>> > Looks to me like this can be handled entirely in DT without driver
>> > changes like the other patches. Correct usage of compatible
>> strings is
>> > what gives you future-proofing. And no driver change is better
>> than
>> > needless changing.
>>
>> If I make e.g. the jz4760 and jz4770 use the jz4780 compatible
>> string,
>> but
>> then I want to implement a new feature that only exists on the
>> jz4780,
>> how
>> can I do it without breaking everything?
>
> You specify both:
>
> compatible = "ingenic,jz4760-rtc", "ingenic,jz4780-rtc";
>
> You match on the less specific compatible until you have features or
> bugs to handle for the more specific compatible. In your case, you
> would have to start matching on the 4760 and 4770 and not support the
> feature for those. A bit backwards from normal, but would still work.
Right, I didn't think about that.
Thanks!
>> > It may look a bit wierd if 4780 is the fallback for 4770, but if
>> the
>> > 4780 is older, then that actually makes sense.
>>
>> The 4770 is older than the 4780.
>
> As I said, it's weird, but it will all still work. You could fix this
> if you want. It would only matter if you had a old dtb with a new
> kernel and care about that case working.
>
> Rob
^ permalink raw reply
* Re: [PATCH] ethdev: move sanity checks to non-debug paths
From: Ananyev, Konstantin @ 2018-07-23 14:19 UTC (permalink / raw)
To: Matan Azrad, Aaron Conole
Cc: dev@dpdk.org, Yigit, Ferruh, Marcelo Leitner, Shahaf Shuler,
Ori Kam, Thomas Monjalon
In-Reply-To: <VI1PR0501MB2608D052D6902CB52C4952AED2560@VI1PR0501MB2608.eurprd05.prod.outlook.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Matan Azrad
> Sent: Monday, July 23, 2018 1:14 PM
> To: Aaron Conole <aconole@redhat.com>
> Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>; Marcelo Leitner <mleitner@redhat.com>; Shahaf Shuler
> <shahafs@mellanox.com>; Ori Kam <orika@mellanox.com>; Thomas Monjalon <thomas@monjalon.net>
> Subject: Re: [dpdk-dev] [PATCH] ethdev: move sanity checks to non-debug paths
>
>
> Hi Aaron
> From: Aaron Conole
> > Sent: Monday, July 23, 2018 2:52 PM
> > To: Matan Azrad <matan@mellanox.com>
> > Cc: dev@dpdk.org; Ferruh Yigit <ferruh.yigit@intel.com>; Marcelo Leitner
> > <mleitner@redhat.com>; Shahaf Shuler <shahafs@mellanox.com>; Ori Kam
> > <orika@mellanox.com>; Thomas Monjalon <thomas@monjalon.net>
> > Subject: Re: [dpdk-dev] [PATCH] ethdev: move sanity checks to non-debug paths
> >
> > Matan Azrad <matan@mellanox.com> writes:
> >
> > > Hi Aaron
> > >
> > > From: Aaron Conole
> > >> These checks would have prevented a reported crash in the field. If
> > >> a user builds without ETHDEV_DEBUG, it should make their application
> > >> more stable, not less.
> > >>
> > >> Many of these functions immediately dereference arrays based on the
> > >> passed in values, so the sanity checks are quite important.
> > >>
> > >
> > > These functions are datapath functions.
> > > Do you really want to add more 3 checks + calculations per each burst call?
> > > Did you check the performance impact?
> > > I think that performance numbers must be added for the discussion of this
> > patch.
> >
> > I'll dig up performance numbers - but performance doesn't mean anything if
> > the application isn't running any longer due to crash.
>
> Yes, I understand your point, but think about that, if we are going to defend each user mistake it will cost a lot.
> For example in Tx path, Adding checks for each mbuf pointer and mbuf data validity will be very expensive.
>
> I think the best way is to check the common user mistakes in DEBUG mode to help for application debugging and that's it.
+1
The problem is that user provided an invalid input parameters.
Adding just extra checks inside data-path functions wouldn't solve it.
Konstantin
>
> > >> The logs are left as DEBUG only.
> > >>
> > >> Cc: Marcelo Leitner <mleitner@redhat.com>
> > >> Signed-off-by: Aaron Conole <aconole@redhat.com>
> > >> ---
> > >> lib/librte_ethdev/rte_ethdev.h | 29 +++++++++++++----------------
> > >> 1 file changed, 13 insertions(+), 16 deletions(-)
> > >>
> > >> diff --git a/lib/librte_ethdev/rte_ethdev.h
> > >> b/lib/librte_ethdev/rte_ethdev.h index f5f593b31..bfd6a3406 100644
> > >> --- a/lib/librte_ethdev/rte_ethdev.h
> > >> +++ b/lib/librte_ethdev/rte_ethdev.h
> > >> @@ -3805,15 +3805,16 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t
> > >> queue_id,
> > >> struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > >> uint16_t nb_rx;
> > >>
> > >> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> > >> RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
> > >>
> > >> if (queue_id >= dev->data->nb_rx_queues) {
> > >> +#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n",
> > queue_id);
> > >> +#endif
> > >> return 0;
> > >> }
> > >> -#endif
> > >> +
> > >> nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
> > >> rx_pkts, nb_pkts);
> > >>
> > >> @@ -3928,14 +3929,12 @@ rte_eth_rx_descriptor_status(uint16_t
> > >> port_id, uint16_t queue_id,
> > >> struct rte_eth_dev *dev;
> > >> void *rxq;
> > >>
> > >> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); -#endif
> > >> dev = &rte_eth_devices[port_id];
> > >> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> +
> > >> if (queue_id >= dev->data->nb_rx_queues)
> > >> return -ENODEV;
> > >> -#endif
> > >> +
> > >> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_descriptor_status, -
> > >> ENOTSUP);
> > >> rxq = dev->data->rx_queues[queue_id];
> > >>
> > >> @@ -3985,14 +3984,12 @@ static inline int
> > >> rte_eth_tx_descriptor_status(uint16_t port_id,
> > >> struct rte_eth_dev *dev;
> > >> void *txq;
> > >>
> > >> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); -#endif
> > >> dev = &rte_eth_devices[port_id];
> > >> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> +
> > >> if (queue_id >= dev->data->nb_tx_queues)
> > >> return -ENODEV;
> > >> -#endif
> > >> +
> > >> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_descriptor_status, -
> > >> ENOTSUP);
> > >> txq = dev->data->tx_queues[queue_id];
> > >>
> > >> @@ -4071,15 +4068,15 @@ rte_eth_tx_burst(uint16_t port_id, uint16_t
> > >> queue_id, {
> > >> struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > >>
> > >> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> > >> RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
> > >>
> > >> if (queue_id >= dev->data->nb_tx_queues) {
> > >> +#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
> > queue_id);
> > >> +#endif
> > >> return 0;
> > >> }
> > >> -#endif
> > >>
> > >> #ifdef RTE_ETHDEV_RXTX_CALLBACKS
> > >> struct rte_eth_rxtx_callback *cb = dev->pre_tx_burst_cbs[queue_id];
> > >> @@ -4160,23 +4157,23 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t
> > >> queue_id, {
> > >> struct rte_eth_dev *dev;
> > >>
> > >> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> if (!rte_eth_dev_is_valid_port(port_id)) {
> > >> +#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
> > >> +#endif
> > >> rte_errno = -EINVAL;
> > >> return 0;
> > >> }
> > >> -#endif
> > >>
> > >> dev = &rte_eth_devices[port_id];
> > >>
> > >> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> if (queue_id >= dev->data->nb_tx_queues) {
> > >> +#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > >> RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
> > queue_id);
> > >> +#endif
> > >> rte_errno = -EINVAL;
> > >> return 0;
> > >> }
> > >> -#endif
> > >>
> > >> if (!dev->tx_pkt_prepare)
> > >> return nb_pkts;
> > >> --
> > >> 2.14.3
^ permalink raw reply
* [PATCH v4 02/20] virtio: pci-legacy: Validate queue pfn
From: Michael S. Tsirkin @ 2018-07-23 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db295a96-cf1e-9e8b-9b29-5882084781e1@arm.com>
On Mon, Jul 23, 2018 at 01:54:10PM +0100, Marc Zyngier wrote:
> On 23/07/18 10:44, Suzuki K Poulose wrote:
> > On 07/22/2018 04:53 PM, Michael S. Tsirkin wrote:
> >> On Wed, Jul 18, 2018 at 10:18:45AM +0100, Suzuki K Poulose wrote:
> >>> Legacy PCI over virtio uses a 32bit PFN for the queue. If the
> >>> queue pfn is too large to fit in 32bits, which we could hit on
> >>> arm64 systems with 52bit physical addresses (even with 64K page
> >>> size), we simply miss out a proper link to the other side of
> >>> the queue.
> >>>
> >>> Add a check to validate the PFN, rather than silently breaking
> >>> the devices.
> >>>
> >>> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> >>> Cc: Jason Wang <jasowang@redhat.com>
> >>> Cc: Marc Zyngier <marc.zyngier@arm.com>
> >>> Cc: Christoffer Dall <cdall@kernel.org>
> >>> Cc: Peter Maydel <peter.maydell@linaro.org>
> >>> Cc: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> >>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >>
> >> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> >
> >
> > Michael,
> >
> > Thanks.
> >
> >>
> >> I assume this will be merged through some other tree.
> >>
> >
> >
> > As such these two virtio patches do not have any code dependencies with
> > the rest of the series. So, if you could pick this up it should be fine.
> > Otherwise, may be Marc can push it with the rest of the series.
> >
> > Marc,
> >
> > Are you OK with that ?
>
> Given that these two patches completely independent, I think their
> natural path should be the virtio tree. But if Michael doesn't want to
> pick them, I'll do it as part of this series.
>
> Thanks,
>
> M.
It's ok, I can pick them up.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH 1/5] misc: rtsx_usb: Use USB remote wakeup signaling for card insertion detection
From: Alan Stern @ 2018-07-23 14:19 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: arnd, gregkh, ulf.hansson, bauer.chen, ricky_wu, linux-kernel,
linux-usb
In-Reply-To: <20180723102744.15140-2-kai.heng.feng@canonical.com>
On Mon, 23 Jul 2018, Kai-Heng Feng wrote:
> Although rtsx_usb doesn't support card removal detection, card insertion
> will resume rtsx_usb by USB remote wakeup signaling.
>
> When rtsx_usb gets resumed, also resumes its child devices,
> rtsx_usb_sdmmc and rtsx_usb_ms, to notify them there's a card in its
> slot.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> drivers/misc/cardreader/rtsx_usb.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/misc/cardreader/rtsx_usb.c b/drivers/misc/cardreader/rtsx_usb.c
> index b97903ff1a72..fed83453e5c5 100644
> --- a/drivers/misc/cardreader/rtsx_usb.c
> +++ b/drivers/misc/cardreader/rtsx_usb.c
> @@ -723,8 +723,20 @@ static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t message)
> return 0;
> }
>
> +static int rtsx_usb_resume_child(struct device *dev, void *data)
> +{
> + /* No need to wake up self again */
> + if (dev == data)
> + return 0;
Is this test actually needed? device_for_each_child() won't enumerate
the device it is called for, only that device's children.
> +
> + dev_dbg(dev, "%s called\n", __func__);
Not necessary. People can use ftrace if they want this information.
Alan Stern
> + pm_request_resume(dev);
> + return 0;
> +}
> +
> static int rtsx_usb_resume(struct usb_interface *intf)
> {
> + device_for_each_child(&intf->dev, &intf->dev, rtsx_usb_resume_child);
> return 0;
> }
>
> @@ -734,6 +746,7 @@ static int rtsx_usb_reset_resume(struct usb_interface *intf)
> (struct rtsx_ucr *)usb_get_intfdata(intf);
>
> rtsx_usb_reset_chip(ucr);
> + device_for_each_child(&intf->dev, &intf->dev, rtsx_usb_resume_child);
> return 0;
> }
>
>
^ permalink raw reply
* [1/5] misc: rtsx_usb: Use USB remote wakeup signaling for card insertion detection
From: Alan Stern @ 2018-07-23 14:19 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: arnd, gregkh, ulf.hansson, bauer.chen, ricky_wu, linux-kernel,
linux-usb
On Mon, 23 Jul 2018, Kai-Heng Feng wrote:
> Although rtsx_usb doesn't support card removal detection, card insertion
> will resume rtsx_usb by USB remote wakeup signaling.
>
> When rtsx_usb gets resumed, also resumes its child devices,
> rtsx_usb_sdmmc and rtsx_usb_ms, to notify them there's a card in its
> slot.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> drivers/misc/cardreader/rtsx_usb.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/misc/cardreader/rtsx_usb.c b/drivers/misc/cardreader/rtsx_usb.c
> index b97903ff1a72..fed83453e5c5 100644
> --- a/drivers/misc/cardreader/rtsx_usb.c
> +++ b/drivers/misc/cardreader/rtsx_usb.c
> @@ -723,8 +723,20 @@ static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t message)
> return 0;
> }
>
> +static int rtsx_usb_resume_child(struct device *dev, void *data)
> +{
> + /* No need to wake up self again */
> + if (dev == data)
> + return 0;
Is this test actually needed? device_for_each_child() won't enumerate
the device it is called for, only that device's children.
> +
> + dev_dbg(dev, "%s called\n", __func__);
Not necessary. People can use ftrace if they want this information.
Alan Stern
> + pm_request_resume(dev);
> + return 0;
> +}
> +
> static int rtsx_usb_resume(struct usb_interface *intf)
> {
> + device_for_each_child(&intf->dev, &intf->dev, rtsx_usb_resume_child);
> return 0;
> }
>
> @@ -734,6 +746,7 @@ static int rtsx_usb_reset_resume(struct usb_interface *intf)
> (struct rtsx_ucr *)usb_get_intfdata(intf);
>
> rtsx_usb_reset_chip(ucr);
> + device_for_each_child(&intf->dev, &intf->dev, rtsx_usb_resume_child);
> return 0;
> }
>
>
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Bug 106707] [CI] igt@gem_exec_schedule@deep-* - fail - Failed assertion: __vgem_fence_signal(fd, fence) == 0
From: bugzilla-daemon @ 2018-07-23 14:19 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-106707-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 608 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=106707
Chris Wilson <chris@chris-wilson.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|DRM/Intel |IGT
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
|sktop.org |.org
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org |
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1588 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] v3: btrfs-progs: Introduce 'btrfs inspect-internal dump-csum' option
From: Lakshmipathi.G @ 2018-07-23 13:16 UTC (permalink / raw)
To: linux-btrfs; +Cc: suy.fnst, lakshmipathi.g
Print csum for a given file on stdout.
Sample usage:
btrfs inspect-internal dump-csum /btrfs/50gbfile /dev/sda4
Signed-off-by: Lakshmipathi.G <Lakshmipathi.Ganapathi@collabora.co.uk>
---
Makefile | 2 +-
cmds-inspect-dump-csum.c | 239 +++++++++++++++++++++++++++++++++++++++++++++++
cmds-inspect-dump-csum.h | 22 +++++
cmds-inspect.c | 3 +
4 files changed, 265 insertions(+), 1 deletion(-)
create mode 100644 cmds-inspect-dump-csum.c
create mode 100644 cmds-inspect-dump-csum.h
diff --git a/Makefile b/Makefile
index 544410e6..8ad28012 100644
--- a/Makefile
+++ b/Makefile
@@ -122,7 +122,7 @@ cmds_objects = cmds-subvolume.o cmds-filesystem.o cmds-device.o cmds-scrub.o \
cmds-quota.o cmds-qgroup.o cmds-replace.o check/main.o \
cmds-restore.o cmds-rescue.o chunk-recover.o super-recover.o \
cmds-property.o cmds-fi-usage.o cmds-inspect-dump-tree.o \
- cmds-inspect-dump-super.o cmds-inspect-tree-stats.o cmds-fi-du.o \
+ cmds-inspect-dump-super.o cmds-inspect-tree-stats.o cmds-fi-du.o cmds-inspect-dump-csum.o \
mkfs/common.o check/mode-common.o check/mode-lowmem.o
libbtrfs_objects = send-stream.o send-utils.o kernel-lib/rbtree.o btrfs-list.o \
kernel-lib/crc32c.o messages.o \
diff --git a/cmds-inspect-dump-csum.c b/cmds-inspect-dump-csum.c
new file mode 100644
index 00000000..06dba368
--- /dev/null
+++ b/cmds-inspect-dump-csum.c
@@ -0,0 +1,239 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include "kerncompat.h"
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <sys/stat.h>
+#include <ctype.h>
+#include <uuid/uuid.h>
+#include <errno.h>
+#include <getopt.h>
+
+#include "ctree.h"
+#include "disk-io.h"
+#include "print-tree.h"
+#include "transaction.h"
+#include "list.h"
+#include "utils.h"
+#include "commands.h"
+#include "crc32c.h"
+#include "cmds-inspect-dump-csum.h"
+#include "help.h"
+#include "volumes.h"
+
+
+const char * const cmd_inspect_dump_csum_usage[] = {
+ "btrfs inspect-internal dump-csum <path/to/file> <device>",
+ "Get csums for the given file.",
+ NULL
+};
+
+int btrfs_lookup_csums(struct btrfs_trans_handle *trans, struct btrfs_root *root,
+ struct btrfs_path *path, u64 bytenr, int cow, int total_csums)
+{
+ int ret;
+ int i;
+ int start_pos = 0;
+ struct btrfs_key file_key;
+ struct btrfs_key found_key;
+ struct btrfs_csum_item *item;
+ struct extent_buffer *leaf;
+ u64 csum_offset = 0;
+ u16 csum_size =
+ btrfs_super_csum_size(root->fs_info->super_copy);
+ int csums_in_item = 0;
+ unsigned int tree_csum = 0;
+ int pending_csums = total_csums;
+ static int cnt=1;
+
+ file_key.objectid = BTRFS_EXTENT_CSUM_OBJECTID;
+ file_key.offset = bytenr;
+ file_key.type = BTRFS_EXTENT_CSUM_KEY;
+ ret = btrfs_search_slot(trans, root, &file_key, path, 0, cow);
+ if (ret < 0)
+ goto fail;
+ while(1){
+ leaf = path->nodes[0];
+ if (ret > 0) {
+ ret = 1;
+ if (path->slots[0] == 0)
+ goto fail;
+ path->slots[0]--;
+ btrfs_item_key_to_cpu(leaf, &found_key, path->slots[0]);
+ if (found_key.type != BTRFS_EXTENT_CSUM_KEY){
+ fprintf(stderr, "\nInvalid key found.");
+ goto fail;
+ }
+
+ csum_offset = ((bytenr - found_key.offset) / root->fs_info->sectorsize) * csum_size;
+ csums_in_item = btrfs_item_size_nr(leaf, path->slots[0]);
+ csums_in_item /= csum_size;
+ csums_in_item -= ( bytenr - found_key.offset ) / root->fs_info->sectorsize;
+ start_pos=csum_offset;
+ }
+ if (path->slots[0] >= btrfs_header_nritems(leaf)) {
+ if (pending_csums > 0){
+ ret = btrfs_next_leaf(root, path);
+ if (ret == 0)
+ continue;
+ }
+ }
+ item = btrfs_item_ptr(leaf, path->slots[0], struct btrfs_csum_item);
+ btrfs_item_key_to_cpu(leaf, &found_key, path->slots[0]);
+ if (!ret){
+ start_pos=0;
+ csum_offset = ( bytenr - found_key.offset ) / root->fs_info->sectorsize;
+ csums_in_item = btrfs_item_size_nr(leaf, path->slots[0]);
+ csums_in_item /= csum_size;
+ }
+ if (csums_in_item > pending_csums){
+ //possibly,some other csums on this item.
+ for(i = 0; i < pending_csums; i++, cnt++){
+ read_extent_buffer(leaf, &tree_csum,
+ (unsigned long)item + ((i*4)+start_pos) , csum_size);
+ fprintf(stdout, "%x ", tree_csum);
+ if (cnt % 8 == 0)
+ fprintf(stdout, "\n");
+ }
+ pending_csums = 0;
+ return 0;
+ }else{
+ for(i = 0; i < csums_in_item; i++, cnt++){
+ read_extent_buffer(leaf, &tree_csum,
+ (unsigned long)item+((i*4)+start_pos), csum_size);
+ fprintf(stdout, "%x ", tree_csum);
+ if (cnt % 8 == 0)
+ fprintf(stdout, "\n");
+ }
+ }
+ pending_csums -= csums_in_item;
+ ret = 0;
+ if (pending_csums > 0){
+ path->slots[0]++;
+
+ }else
+ return 0;
+ }
+fail:
+ fprintf(stderr, "btrfs_lookup_csums search failed.");
+ if (ret > 0)
+ ret = -ENOENT;
+ return ret;
+}
+
+int btrfs_lookup_extent(struct btrfs_fs_info *info, struct btrfs_path *path,
+ u64 ino, int cow){
+ struct btrfs_key key;
+ struct btrfs_key found_key;
+ struct btrfs_file_extent_item *fi;
+ struct extent_buffer *leaf;
+ struct btrfs_root *fs_root;
+ int ret = -1;
+ int slot;
+ int total_csums = 0;
+ u64 bytenr;
+ u64 itemnum = 0;
+ struct btrfs_path *path1 = NULL;
+
+ fs_root = info->fs_root;
+ key.objectid = ino;
+ key.type = BTRFS_EXTENT_DATA_KEY;
+ key.offset = 0;
+ ret = btrfs_search_slot(NULL,fs_root,&key,path,0,0);
+
+ if(ret < 0)
+ goto error;
+
+ if (ret > 1){
+ fprintf(stderr, "Unable to find the entry");
+ return ret;
+ }
+
+ while(1){
+ leaf = path->nodes[0];
+ slot = path->slots[0];
+ if (slot >= btrfs_header_nritems(leaf)){
+ ret = btrfs_next_leaf(fs_root, path);
+ if (ret == 0)
+ continue;
+ if (ret < 0)
+ goto error;
+ }
+ btrfs_item_key_to_cpu(leaf, &found_key, slot);
+ if (found_key.type != BTRFS_EXTENT_DATA_KEY){
+ btrfs_release_path(path);
+ return -EINVAL;
+ }
+
+ fi = btrfs_item_ptr(leaf, slot, struct btrfs_file_extent_item);
+ bytenr = btrfs_file_extent_disk_bytenr(leaf, fi);
+ total_csums=(btrfs_file_extent_num_bytes(leaf, fi) / 1024) / 4;
+ path->slots[0]++;
+ itemnum++;
+ path1 = btrfs_alloc_path();
+ ret = btrfs_lookup_csums(NULL,info->csum_root, path1, bytenr, 0,
+ total_csums);
+ btrfs_release_path(path1);
+ if (ret) {
+ fprintf(stderr, "\n Error: btrfs_lookup_csum");
+ return 1;
+ }
+ }
+
+error:
+ btrfs_release_path(path);
+ return ret;
+}
+
+int cmd_inspect_dump_csum(int argc, char **argv)
+{
+ struct btrfs_fs_info *info;
+ int ret;
+ struct btrfs_path path;
+ struct stat st;
+ char *filename;
+
+ if (check_argc_exact(argc, 3))
+ usage(cmd_inspect_dump_csum_usage);
+
+ filename = argv[1];
+ info = open_ctree_fs_info(argv[2], 0, 0, 0, OPEN_CTREE_PARTIAL);
+ if (!info) {
+ fprintf(stderr, "unable to open %s\n", argv[2]);
+ exit(1);
+ }
+
+ ret = stat(filename, &st);
+ if (ret < 0) {
+ fprintf(stderr, "unable to open %s\n", filename);
+ exit(1);
+ }
+
+ if(st.st_size < 1024){
+ fprintf(stderr, "file less than 1KB.abort%lu", (st.st_size ));
+ exit(1);
+ }
+
+ btrfs_init_path(&path);
+ ret = btrfs_lookup_extent(info, &path, st.st_ino, 0);
+ ret = close_ctree(info->fs_root);
+ btrfs_close_all_devices();
+
+ return ret;
+}
diff --git a/cmds-inspect-dump-csum.h b/cmds-inspect-dump-csum.h
new file mode 100644
index 00000000..338fa67d
--- /dev/null
+++ b/cmds-inspect-dump-csum.h
@@ -0,0 +1,22 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ *
+ * Authors: Lakshmipathi.G <lakshmipathi.ganapathi@collabora.co.uk>
+ */
+
+
+int cmd_inspect_dump_csum(int argc, char **argv);
+
+extern const char * const cmd_inspect_dump_csum_usage[];
diff --git a/cmds-inspect.c b/cmds-inspect.c
index afd7fe48..c0d59c6d 100644
--- a/cmds-inspect.c
+++ b/cmds-inspect.c
@@ -32,6 +32,7 @@
#include "commands.h"
#include "btrfs-list.h"
#include "help.h"
+#include "cmds-inspect-dump-csum.h"
static const char * const inspect_cmd_group_usage[] = {
"btrfs inspect-internal <command> <args>",
@@ -647,6 +648,8 @@ const struct cmd_group inspect_cmd_group = {
cmd_inspect_dump_super_usage, NULL, 0 },
{ "tree-stats", cmd_inspect_tree_stats,
cmd_inspect_tree_stats_usage, NULL, 0 },
+ { "dump-csum", cmd_inspect_dump_csum,
+ cmd_inspect_dump_csum_usage, NULL, 0 },
NULL_CMD_STRUCT
}
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] rtc: jz4740: Add support for the JZ4725B, JZ4760, JZ4770
From: Rob Herring @ 2018-07-23 14:18 UTC (permalink / raw)
To: Paul Cercueil
Cc: Alexandre Belloni, Alessandro Zummo, Mark Rutland,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <1532113439.2309.1@smtp.crapouillou.net>
On Fri, Jul 20, 2018 at 1:04 PM Paul Cercueil <paul@crapouillou.net> wrote:
>
> Hi,
>
> Le ven. 20 juil. 2018 à 17:39, Rob Herring <robh@kernel.org> a écrit :
> > On Sat, Jul 14, 2018 at 03:50:08PM +0200, Paul Cercueil wrote:
> >>
> >>
> >> Le sam. 14 juil. 2018 à 15:32, Alexandre Belloni
> >> <alexandre.belloni@bootlin.com> a écrit :
> >> > On 14/07/2018 15:25:33+0200, Paul Cercueil wrote:
> >> > > Hi Alexandre,
> >> > >
> >> > > Le sam. 14 juil. 2018 à 15:19, Alexandre Belloni
> >> > > <alexandre.belloni@bootlin.com> a écrit :
> >> > > > Hello,
> >> > > >
> >> > > > On 13/07/2018 17:14:24+0200, Paul Cercueil wrote:
> >> > > > > The RTC in the JZ4725B works just like the one in the
> >> JZ4740.
> >> > > > >
> >> > > > > The RTC in the JZ4760 and JZ4770 work just like the one
> >> in the
> >> > > > > JZ4780.
> >> > > > >
> >> > > > > Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> >> > > > > ---
> >> > > > >
> >> Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> >> > > | 3
> >> > > > > +++
> >> > > > > drivers/rtc/rtc-jz4740.c
> >> > > | 11
> >> > > > > ++++++++++-
> >> > > > > 2 files changed, 13 insertions(+), 1 deletion(-)
> >> > > > >
> >> > > > > diff --git
> >> > > > >
> >> a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> >> > > > >
> >> b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> >> > > > > index 41c7ae18fd7b..a9e821de84f2 100644
> >> > > > > ---
> >> > > a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> >> > > > > +++
> >> > > b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> >> > > > > @@ -4,6 +4,9 @@ Required properties:
> >> > > > >
> >> > > > > - compatible: One of:
> >> > > > > - "ingenic,jz4740-rtc" - for use with the JZ4740 SoC
> >> > > > > + - "ingenic,jz4725b-rtc" - for use with the JZ4725B SoC
> >> > > > > + - "ingenic,jz4760-rtc" - for use with the JZ4760 SoC
> >> > > > > + - "ingenic,jz4770-rtc" - for use with the JZ4770 SoC
> >> > > > > - "ingenic,jz4780-rtc" - for use with the JZ4780 SoC
> >> > > > > - reg: Address range of rtc register set
> >> > > > > - interrupts: IRQ number for the alarm interrupt
> >> > > > > diff --git a/drivers/rtc/rtc-jz4740.c
> >> > > b/drivers/rtc/rtc-jz4740.c
> >> > > > > index d0a891777f44..1c867e3a0ea5 100644
> >> > > > > --- a/drivers/rtc/rtc-jz4740.c
> >> > > > > +++ b/drivers/rtc/rtc-jz4740.c
> >> > > > > @@ -54,6 +54,9 @@
> >> > > > >
> >> > > > > enum jz4740_rtc_type {
> >> > > > > ID_JZ4740,
> >> > > > > + ID_JZ4725B,
> >> > > > > + ID_JZ4760,
> >> > > > > + ID_JZ4770,
> >> > > >
> >> > > > I wouldn't introduce those ids unless there are handling
> >> > > differences at
> >> > > > some point.
> >> > >
> >> > > Well there are handling differences, see below.
> >> > >
> >> > > > > ID_JZ4780,
> >> > > > > };
> >> > > > >
> >> > > > > @@ -114,7 +117,7 @@ static inline int
> >> > > jz4740_rtc_reg_write(struct
> >> > > > > jz4740_rtc *rtc, size_t reg,
> >> > > > > {
> >> > > > > int ret = 0;
> >> > > > >
> >> > > > > - if (rtc->type >= ID_JZ4780)
> >> > > > > + if (rtc->type >= ID_JZ4760)
> >> > > >
> >> > > > This would avoid that change (and the test would preferably
> >> be
> >> > > > (rtc->type == ID_JZ4780))
> >> > >
> >> > > That branch should be taken if the SoC is JZ4760, JZ4770 or
> >> JZ4780.
> >> > > It should not be taken if the SoC is JZ4740 or JZ4725B.
> >> >
> >> > Sure but you can achieve that with only 2 ids...
> >> >
> >> > >
> >> > > > > ret = jz4780_rtc_enable_write(rtc);
> >> > > > > if (ret == 0)
> >> > > > > ret = jz4740_rtc_wait_write_ready(rtc);
> >> > > > > @@ -300,6 +303,9 @@ static void jz4740_rtc_power_off(void)
> >> > > > >
> >> > > > > static const struct of_device_id jz4740_rtc_of_match[] =
> >> {
> >> > > > > { .compatible = "ingenic,jz4740-rtc", .data = (void
> >> > > *)ID_JZ4740 },
> >> > > > > + { .compatible = "ingenic,jz4725b-rtc", .data = (void
> >> > > *)ID_JZ4725B
> >> > > > > },
> >> > > > > + { .compatible = "ingenic,jz4760-rtc", .data = (void
> >> > > *)ID_JZ4760 },
> >> > > > > + { .compatible = "ingenic,jz4770-rtc", .data = (void
> >> > > *)ID_JZ4770 },
> >> >
> >> > By doing the correct mapping here e.g:
> >> >
> >> > { .compatible = "ingenic,jz4725b-rtc", .data = (void *)ID_JZ4740
> >> },
> >>
> >> Not very pretty and future-proof if you ask me...
> >
> > Looks to me like this can be handled entirely in DT without driver
> > changes like the other patches. Correct usage of compatible strings is
> > what gives you future-proofing. And no driver change is better than
> > needless changing.
>
> If I make e.g. the jz4760 and jz4770 use the jz4780 compatible string,
> but
> then I want to implement a new feature that only exists on the jz4780,
> how
> can I do it without breaking everything?
You specify both:
compatible = "ingenic,jz4760-rtc", "ingenic,jz4780-rtc";
You match on the less specific compatible until you have features or
bugs to handle for the more specific compatible. In your case, you
would have to start matching on the 4760 and 4770 and not support the
feature for those. A bit backwards from normal, but would still work.
> > It may look a bit wierd if 4780 is the fallback for 4770, but if the
> > 4780 is older, then that actually makes sense.
>
> The 4770 is older than the 4780.
As I said, it's weird, but it will all still work. You could fix this
if you want. It would only matter if you had a old dtb with a new
kernel and care about that case working.
Rob
^ permalink raw reply
* Re: [PATCH] power: supply: bq27xxx: Update comments
From: Andrew F. Davis @ 2018-07-23 14:18 UTC (permalink / raw)
To: Liu Xiang; +Cc: pali.rohar, sre, linux-pm, linux-kernel, liuxiang_1999
In-Reply-To: <1532253504-17563-1-git-send-email-liu.xiang6@zte.com.cn>
On 07/22/2018 04:58 AM, Liu Xiang wrote:
> The URL of bq27441-g1 and bq27426 are missing and bq27520-g4 is duplicated.
>
> Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn>
> ---
Acked-by: Andrew F. Davis <afd@ti.com>
> drivers/power/supply/bq27xxx_battery.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
> index d44ed8e..f022e1b 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -26,7 +26,6 @@
> * http://www.ti.com/product/bq27510-g1
> * http://www.ti.com/product/bq27510-g2
> * http://www.ti.com/product/bq27510-g3
> - * http://www.ti.com/product/bq27520-g4
> * http://www.ti.com/product/bq27520-g1
> * http://www.ti.com/product/bq27520-g2
> * http://www.ti.com/product/bq27520-g3
> @@ -40,7 +39,9 @@
> * http://www.ti.com/product/bq27545-g1
> * http://www.ti.com/product/bq27421-g1
> * http://www.ti.com/product/bq27425-g1
> + * http://www.ti.com/product/bq27426
> * http://www.ti.com/product/bq27411-g1
> + * http://www.ti.com/product/bq27441-g1
> * http://www.ti.com/product/bq27621-g1
> */
>
>
^ permalink raw reply
* Re: [PATCH] power: supply: bq27xxx: Update comments
From: Andrew F. Davis @ 2018-07-23 14:18 UTC (permalink / raw)
To: Liu Xiang; +Cc: pali.rohar, sre, linux-pm, linux-kernel, liuxiang_1999
In-Reply-To: <1532253504-17563-1-git-send-email-liu.xiang6@zte.com.cn>
On 07/22/2018 04:58 AM, Liu Xiang wrote:
> The URL of bq27441-g1 and bq27426 are missing and bq27520-g4 is duplicated.
>
> Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn>
> ---
Acked-by: Andrew F. Davis <afd@ti.com>
> drivers/power/supply/bq27xxx_battery.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
> index d44ed8e..f022e1b 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -26,7 +26,6 @@
> * http://www.ti.com/product/bq27510-g1
> * http://www.ti.com/product/bq27510-g2
> * http://www.ti.com/product/bq27510-g3
> - * http://www.ti.com/product/bq27520-g4
> * http://www.ti.com/product/bq27520-g1
> * http://www.ti.com/product/bq27520-g2
> * http://www.ti.com/product/bq27520-g3
> @@ -40,7 +39,9 @@
> * http://www.ti.com/product/bq27545-g1
> * http://www.ti.com/product/bq27421-g1
> * http://www.ti.com/product/bq27425-g1
> + * http://www.ti.com/product/bq27426
> * http://www.ti.com/product/bq27411-g1
> + * http://www.ti.com/product/bq27441-g1
> * http://www.ti.com/product/bq27621-g1
> */
>
>
^ permalink raw reply
* Re: [PATCH] drm/atomic: Initialize variables in drm_atomic_helper_async_check() to make gcc happy
From: Boris Brezillon @ 2018-07-23 14:17 UTC (permalink / raw)
To: Sean Paul; +Cc: David Airlie, dri-devel
In-Reply-To: <20180723140925.GI20359@art_vandelay>
On Mon, 23 Jul 2018 10:09:25 -0400
Sean Paul <seanpaul@chromium.org> wrote:
> On Mon, Jul 23, 2018 at 03:59:02PM +0200, Boris Brezillon wrote:
> > drm_atomic_helper_async_check() declares the plane, old_plane_state and
> > new_plane_state variables to iterate over all planes of the atomic
> > state and make sure only one plane is enabled.
> >
> > Unfortunately gcc is not smart enough to figure out that the check on
> > n_planes is enough to guarantee that plane, new_plane_state and
> > old_plane_state are initialized.
> >
> > Explicitly initialized those variables to NULL to make gcc happy.
^ initialize
And I forgot to add
Cc: stable@vger.kernel.com
Will send a v2 soon.
>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>
Thanks for the review.
>
> >
> > Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane update")
> > Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index f7ccfebd3ca8..80be74df7ba6 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1538,8 +1538,9 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
> > {
> > struct drm_crtc *crtc;
> > struct drm_crtc_state *crtc_state;
> > - struct drm_plane *plane;
> > - struct drm_plane_state *old_plane_state, *new_plane_state;
> > + struct drm_plane *plane = NULL;
> > + struct drm_plane_state *old_plane_state = NULL;
> > + struct drm_plane_state *new_plane_state = NULL;
> > const struct drm_plane_helper_funcs *funcs;
> > int i, n_planes = 0;
> >
> > --
> > 2.14.1
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: cgroup-aware OOM killer, how to move forward
From: Michal Hocko @ 2018-07-23 14:17 UTC (permalink / raw)
To: Roman Gushchin, hannes, tj; +Cc: David Rientjes, linux-mm, akpm, gthelen
In-Reply-To: <20180719170543.GA21770@castle.DHCP.thefacebook.com>
On Thu 19-07-18 10:05:47, Roman Gushchin wrote:
> On Thu, Jul 19, 2018 at 09:38:43AM +0200, Michal Hocko wrote:
> > On Wed 18-07-18 08:28:50, Roman Gushchin wrote:
> > > On Wed, Jul 18, 2018 at 10:12:30AM +0200, Michal Hocko wrote:
> > > > On Tue 17-07-18 13:06:42, Roman Gushchin wrote:
> > > > > On Tue, Jul 17, 2018 at 09:49:46PM +0200, Michal Hocko wrote:
> > > > > > On Tue 17-07-18 10:38:45, Roman Gushchin wrote:
> > > > > > [...]
> > > > > > > Let me show my proposal on examples. Let's say we have the following hierarchy,
> > > > > > > and the biggest process (or the process with highest oom_score_adj) is in D.
> > > > > > >
> > > > > > > /
> > > > > > > |
> > > > > > > A
> > > > > > > |
> > > > > > > B
> > > > > > > / \
> > > > > > > C D
> > > > > > >
> > > > > > > Let's look at different examples and intended behavior:
> > > > > > > 1) system-wide OOM
> > > > > > > - default settings: the biggest process is killed
> > > > > > > - D/memory.group_oom=1: all processes in D are killed
> > > > > > > - A/memory.group_oom=1: all processes in A are killed
> > > > > > > 2) memcg oom in B
> > > > > > > - default settings: the biggest process is killed
> > > > > > > - A/memory.group_oom=1: the biggest process is killed
> > > > > >
> > > > > > Huh? Why would you even consider A here when the oom is below it?
> > > > > > /me confused
> > > > >
> > > > > I do not.
> > > > > This is exactly a counter-example: A's memory.group_oom
> > > > > is not considered at all in this case,
> > > > > because A is above ooming cgroup.
> > > >
> > > > OK, it confused me.
> > > >
> > > > > >
> > > > > > > - B/memory.group_oom=1: all processes in B are killed
> > > > > >
> > > > > > - B/memory.group_oom=0 &&
> > > > > > > - D/memory.group_oom=1: all processes in D are killed
> > > > > >
> > > > > > What about?
> > > > > > - B/memory.group_oom=1 && D/memory.group_oom=0
> > > > >
> > > > > All tasks in B are killed.
> > > >
> > > > so essentially find a task, traverse the memcg hierarchy from the
> > > > victim's memcg up to the oom root as long as memcg.group_oom = 1?
> > > > If the resulting memcg.group_oom == 1 then kill the whole sub tree.
> > > > Right?
> > >
> > > Yes.
> > >
> > > >
> > > > > Group_oom set to 1 means that the workload can't tolerate
> > > > > killing of a random process, so in this case it's better
> > > > > to guarantee consistency for B.
> > > >
> > > > OK, but then if D itself is OOM then we do not care about consistency
> > > > all of the sudden? I have hard time to think about a sensible usecase.
> > >
> > > I mean if traversing the hierarchy up to the oom root we meet
> > > a memcg with group_oom set to 0, we shouldn't stop traversing.
> >
> > Well, I am still fighting with the semantic of group, no-group, group
> > configuration. Why does it make any sense? In other words when can we
> > consider a cgroup to be a indivisible workload for one oom context while
> > it is fine to lose head or arm from another?
>
> Hm, so the question is should we traverse up to the OOMing cgroup,
> or up to the first cgroup with memory.group_oom=0?
>
> I looked at an example, and it *might* be the latter is better,
> especially if we'll make the default value inheritable.
>
> Let's say we have a sub-tree with a workload and some control stuff.
> Workload is tolerable to OOM's (we can handle it in userspace, for
> example), but the control stuff is not.
> Then it probably makes no sense to kill the entire sub-tree,
> if a task in C has to be killed. But makes perfect sense if we
> have to kill a task in B.
>
> /
> |
> A, delegated sub-tree, group_oom=1
> / \
> B C, workload, group_oom=0
> ^
> some control stuff here, group_oom=1
>
> Does this makes sense?
I am not sure. If you are going to delegate then you are basically
losing control of the group_oom at A-level. Is this good? What if I
_want_ to tear down the whole thing if it starts misbehaving because I
do not trust it?
The more I think about it the more I am concluding that we should start
with a more contrained model and require that once parent is
group_oom == 1 then children have to as well. If we ever find a usecase
to require a different scheme we can weaker it later. We cannot do that
other way around.
Tejun, Johannes what do you think about that?
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [Qemu-devel] [PULL 0/2] Linux user for 3.0 patches
From: Peter Maydell @ 2018-07-23 14:15 UTC (permalink / raw)
To: Laurent Vivier; +Cc: QEMU Developers, Riku Voipio
In-Reply-To: <20180723125624.18863-1-laurent@vivier.eu>
On 23 July 2018 at 13:56, Laurent Vivier <laurent@vivier.eu> wrote:
> The following changes since commit 5b3ecd3d941a0ae8a8cfbba5ab8139b2bf104822:
>
> Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180719' into staging (2018-07-20 11:08:33 +0100)
>
> are available in the Git repository at:
>
> git://github.com/vivier/qemu.git tags/linux-user-for-3.0-pull-request
>
> for you to fetch changes up to fa97e38eed3bbdbc322d94092ca49450e724fff1:
>
> linux-user/ppc: Implement swapcontext syscall (2018-07-22 21:33:45 +0200)
>
> ----------------------------------------------------------------
> Some ppc/ppc64 fixes:
> - we can run now most of the targets on a ppc64 host with 64kB pages
> - add swapcontext syscall to run tests/test-coroutine in
> debian-powerpc-user-cross
>
> ----------------------------------------------------------------
Applied, thanks.
-- PMM
^ permalink raw reply
* Re: [PATCH 2/2] merge-recursive: preserve skip_worktree bit when necessary
From: Ben Peart @ 2018-07-23 14:14 UTC (permalink / raw)
To: Elijah Newren, git; +Cc: gitster, benpeart, kewillf
In-Reply-To: <20180721063428.20518-3-newren@gmail.com>
<snip>
> merge-recursive.c | 16 ++++++++++++++++
> t/t3507-cherry-pick-conflict.sh | 2 +-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 113c1d696..fd74bca17 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -3069,10 +3069,26 @@ static int merge_content(struct merge_options *o,
> if (mfi.clean &&
> was_tracked_and_matches(o, path, &mfi.oid, mfi.mode) &&
> !df_conflict_remains) {
> + int pos;
> + struct cache_entry *ce;
> +
> output(o, 3, _("Skipped %s (merged same as existing)"), path);
> if (add_cacheinfo(o, mfi.mode, &mfi.oid, path,
> 0, (!o->call_depth && !is_dirty), 0))
> return -1;
> + /*
> + * However, add_cacheinfo() will delete the old cache entry
> + * and add a new one. We need to copy over any skip_worktree
> + * flag to avoid making the file appear as if it were
> + * deleted by the user.
> + */
nit - I find it a little odd to start a comment with "However" as if you
are continuing a conversation.
> + pos = index_name_pos(&o->orig_index, path, strlen(path));
> + ce = o->orig_index.cache[pos];
> + if (ce_skip_worktree(ce)) {
> + pos = index_name_pos(&the_index, path, strlen(path));
> + ce = the_index.cache[pos];
> + ce->ce_flags |= CE_SKIP_WORKTREE;
> + }
> return mfi.clean;
> }
>
> diff --git a/t/t3507-cherry-pick-conflict.sh b/t/t3507-cherry-pick-conflict.sh
> index 25fac490d..9b1456a7c 100755
> --- a/t/t3507-cherry-pick-conflict.sh
> +++ b/t/t3507-cherry-pick-conflict.sh
> @@ -392,7 +392,7 @@ test_expect_success 'commit --amend -s places the sign-off at the right place' '
> test_cmp expect actual
> '
>
> -test_expect_failure 'failed cherry-pick with sparse-checkout' '
> +test_expect_success 'failed cherry-pick with sparse-checkout' '
> pristine_detach initial &&
> git config core.sparseCheckout true &&
> echo /unrelated >.git/info/sparse-checkout &&
>
Thanks Elijah, I can verify this fixes the problem with the preferred
solution (ie it preserves the skip-worktree bit). As such, this is:
Reviewed-by: Ben Peart <benpeart@microsoft.com>
That said, I would propose the test be updated to include a specific
test for the skip-worktree bit so that if a future patch reverts to the
old behavior of clearing the skip-worktree bit and writing out the file
to the working directory, we do it explicitly instead of by accident.
diff --git a/t/t3507-cherry-pick-conflict.sh
b/t/t3507-cherry-pick-conflict.sh
index 9b1456a7c3..bc8863ff36 100755
--- a/t/t3507-cherry-pick-conflict.sh
+++ b/t/t3507-cherry-pick-conflict.sh
@@ -392,17 +392,17 @@ test_expect_success 'commit --amend -s places the
sign-off at the right place' '
test_cmp expect actual
'
-test_expect_success 'failed cherry-pick with sparse-checkout' '
+test_expect_success 'cherry-pick preserves sparse-checkout' '
pristine_detach initial &&
git config core.sparseCheckout true &&
echo /unrelated >.git/info/sparse-checkout &&
git read-tree --reset -u HEAD &&
test_must_fail git cherry-pick -Xours picked>actual &&
+ test "$(git ls-files -t foo)" = "S foo" &&
test_i18ngrep ! "Changes not staged for commit:" actual &&
echo "/*" >.git/info/sparse-checkout &&
git read-tree --reset -u HEAD &&
git config core.sparseCheckout false &&
rm .git/info/sparse-checkout
'
test_done
^ permalink raw reply related
* Re: [PATCH] perf/x86/intel: Fix unwind errors from PEBS entries (mk-II)
From: Peter Zijlstra @ 2018-07-23 14:14 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Ingo Molnar, Prashant Bhole, linux-kernel
In-Reply-To: <20180723133006.7mkzrdeaa4jo56md@treble>
On Mon, Jul 23, 2018 at 08:30:06AM -0500, Josh Poimboeuf wrote:
> On Thu, Jul 19, 2018 at 11:19:54PM +0200, Peter Zijlstra wrote:
> > --- a/include/uapi/linux/perf_event.h
> > +++ b/include/uapi/linux/perf_event.h
> > @@ -143,6 +143,8 @@ enum perf_event_sample_format {
> > PERF_SAMPLE_PHYS_ADDR = 1U << 19,
> >
> > PERF_SAMPLE_MAX = 1U << 20, /* non-ABI */
> > +
> > + __PERF_SAMPLE_CALLCHAIN_EARLY = 1UL << 63,
>
> Given the kbuild test robot errors for building on 32-bit, looks like
> the 63 needs to be changed to 31 so it fits in an int?
I made it 1ULL << 63. The actual field (perf_event_attr::sample_type is
u64).
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.