(a) not clear why the max is SKB_MAX_ALLOC in the first place (this is
PAGE_SIZE << 2, ie. 16K on x86), while lo mtu is 64k
(b) hmm, if we're not redirecting, then exceeding the ingress device's
mtu doesn't seem to be a problem.
Indeed AFAIK this can already happen, some devices will round mtu up
From: Colin Ian King
Pointer info is being assigned twice, once at the start of the function
and secondly when it is just about to be accessed. Remove the redundant
initialization and keep the original assignment to info that is close
to the memcpy that uses it.
Addresses-Coverity: ("Unused valu
Em Thu, Apr 30, 2020 at 09:38:34PM +0800, Jin, Yao escreveu:
> Hi John, Jiri,
>
> On 4/30/2020 7:48 PM, John Garry wrote:
> > On 30/04/2020 12:15, Jiri Olsa wrote:
> >
> > +
> >
> > > On Thu, Apr 30, 2020 at 09:54:18AM +0100, John Garry wrote:
> > > > On 30/04/2020 09:45, Jiri Olsa wrote:
> > >
On Thu 07-05-20 09:33:01, Shakeel Butt wrote:
[...]
> @@ -2600,8 +2596,23 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t
> gfp_mask,
> schedule_work(&memcg->high_work);
> break;
> }
> -
> -Original Message-
> From: Mimi Zohar [mailto:zo...@linux.ibm.com]
> On Thu, 2020-05-07 at 07:53 +, Roberto Sassu wrote:
> > > -Original Message-
> > > From: Mimi Zohar [mailto:zo...@linux.ibm.com]
> > > Sent: Wednesday, May 6, 2020 11:10 PM
> > > To: Roberto Sassu ;
> david.s
Em Thu, May 07, 2020 at 11:28:57AM -0500, Paul A. Clarke escreveu:
> From: "Paul A. Clarke"
>
> The metric definition is too long for the current value of EXPR_MAX_OTHER.
> Increase the value EXPR_MAX_OTHER sufficiently to allow
> 'lsu_other_stall_cpi' to build properly.
I already have a patch f
On 5/5/20 3:44 PM, Thomas Gleixner wrote:
From: Thomas Gleixner
Convert the IRET exception handler to IDTENTRY_SW. This is slightly
different than the conversions of hardware exceptions as the IRET exception
is invoked via an exception table when IRET faults. So it just uses the
IDTENTRY_SW m
On Thu, May 7, 2020 at 1:03 AM Haitao Huang
wrote:
>
> On Wed, 06 May 2020 17:14:22 -0500, Sean Christopherson
> wrote:
>
> > On Wed, May 06, 2020 at 05:42:42PM -0400, Nathaniel McCallum wrote:
> >> Tested on Enarx. This requires a patch[0] for v29 support.
> >>
> >> Tested-by: Nathaniel McCallum
On Thu, 7 May 2020 08:55:32 +0800
Lu Baolu wrote:
> When a PASID is used for SVA by the device, it's possible that the
> PASID entry is cleared before the device flushes all ongoing DMA
> requests. The IOMMU should ignore the non-recoverable faults caused
> by these requests.
Perhaps be more spe
In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures
to a kernel buffer without touching areas for disabled xfeatures. However,
those uninitialized areas may contain random data, which is then written to
the core dump file and can be read by a non-privileged user.
Fix it by
On Thu, 7 May 2020 at 18:26, Arnd Bergmann wrote:
>
> Clang does not allow -fsanitize-coverage=trace-{pc,cmp} together
> with -fsanitize=bounds or with ubsan:
>
> clang: error: argument unused during compilation:
> '-fsanitize-coverage=trace-pc' [-Werror,-Wunused-command-line-argument]
> clang: e
On 5/7/20 9:49 AM, Yu-cheng Yu wrote:
> In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures
> to a kernel buffer without touching areas for disabled xfeatures. However,
> those uninitialized areas may contain random data, which is then written to
> the core dump file and can
On Thu, 7 May 2020 11:25:01 +0200 Bartosz Golaszewski wrote:
> śr., 6 maj 2020 o 19:12 Jakub Kicinski napisał(a):
> >
> > On Wed, 6 May 2020 08:39:47 +0200 Bartosz Golaszewski wrote:
> > > wt., 5 maj 2020 o 19:31 Jakub Kicinski napisał(a):
> > > >
> > > > On Tue, 5 May 2020 16:02:25 +0200 Ba
On 2020-05-07 09:49:04 [-0700], Yu-cheng Yu wrote:
> In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures
> to a kernel buffer without touching areas for disabled xfeatures. However,
> those uninitialized areas may contain random data, which is then written to
> the core dump
Em Thu, May 07, 2020 at 11:28:58AM -0500, Paul A. Clarke escreveu:
> From: "Paul A. Clarke"
>
> Add the following metrics to the POWER9 'cpi_breakdown' metricgroup:
> - ict_noslot_br_mpred_cpi
> - ict_noslot_br_mpred_icmiss_cpi
> - ict_noslot_cyc_other_cpi
> - ict_noslot_disp_held_cpi
> - ict_nos
On Thu, 2020-05-07 at 11:12 -0500, Himanshu Madhani wrote:
> I do not have access to my @marvell.com email ID anymore.
> Lets map my new email address correctly in .mailmap
Bad patch subject, this is a .mailmap patch.
Maybe [PATCH] .mailmap: Update address of Himanshu Madhani
> Signed-off-by: Hi
On Thu, 2020-05-07 at 08:55 -0700, Dave Hansen wrote:
> On 4/29/20 3:07 PM, Yu-cheng Yu wrote:
> > +config X86_INTEL_SHADOW_STACK_USER
> > + prompt "Intel Shadow Stacks for user-mode"
> > + def_bool n
> > + depends on CPU_SUP_INTEL && X86_64
> > + depends on AS_HAS_SHADOW_STACK
> > + sele
On Thu, May 7, 2020 at 9:47 AM Michal Hocko wrote:
>
> On Thu 07-05-20 09:33:01, Shakeel Butt wrote:
> [...]
> > @@ -2600,8 +2596,23 @@ static int try_charge(struct mem_cgroup *memcg,
> > gfp_t gfp_mask,
> > schedule_work(&memcg->high_work);
> >
On Wed, May 06, 2020 at 05:55:35PM -0700, Andrew Morton wrote:
> On Wed, 6 May 2020 17:42:40 -0700 "Paul E. McKenney"
> wrote:
>
> > This commit adds a shrinker so as to inform RCU when memory is scarce.
> > RCU responds by shifting into the same fast and inefficient mode that is
> > used in the
On 5/3/2020 5:34 PM, Rajendra Nayak wrote:
geni spi needs to express a perforamnce state requirement on CX
depending on the frequency of the clock rates. Use OPP table from
DT to register with OPP framework and use dev_pm_opp_set_rate() to
set the clk/perf state.
Signed-off-by: Rajendra Nayak
Em Thu, May 07, 2020 at 11:32:53AM +0300, Alexey Budankov escreveu:
>
> On 06.05.2020 23:21, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 06, 2020 at 09:19:22PM +0300, Alexey Budankov escreveu:
> >>
> >> Implement functions of initialization, finalization and processing
> >> of control commands
czw., 7 maj 2020 o 15:16 Andrew Lunn napisał(a):
>
> On Thu, May 07, 2020 at 12:50:15PM +0200, Bartosz Golaszewski wrote:
> > czw., 7 maj 2020 o 11:46 Mark-MC.Lee napisał(a):
> > >
> > > Hi Bartosz:
> > > I think the naming of this driver and its Kconfig option is too generic
> > > that will con
Em Thu, May 07, 2020 at 11:58:45AM +0300, Alexey Budankov escreveu:
>
> On 06.05.2020 23:23, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 06, 2020 at 09:29:05PM +0300, Alexey Budankov escreveu:
> >>
> >> Implement handling of 'enable' and 'disable' control commands
> >> coming from control file
czw., 7 maj 2020 o 18:53 Jakub Kicinski napisał(a):
>
> On Thu, 7 May 2020 11:25:01 +0200 Bartosz Golaszewski wrote:
> > śr., 6 maj 2020 o 19:12 Jakub Kicinski napisał(a):
> > >
> > > On Wed, 6 May 2020 08:39:47 +0200 Bartosz Golaszewski wrote:
> > > > wt., 5 maj 2020 o 19:31 Jakub Kicinski napi
Thomas Gleixner writes:
> Thomas Gleixner writes:
>> Alexandre Chartre writes:
>>> On 5/5/20 3:41 PM, Thomas Gleixner wrote:
- /*
- * User mode is traced as though IRQs are on, and the interrupt
- * gate turned them off.
- */
- TRACE_IRQS_OFF
-
movq
I've put all raw-gadget fixes in a series, please ignore the previous
patches.
I've dropped the patches that change the ABI for now (those need more
testing anyway).
Changes in v3:
- Dropped ABI breaking changes for .
- A few more comment fixes for uapi headers.
- Updated documentation.
Andrey K
Fix typo "trasferred" => "transferred".
Don't call USB requests URBs.
Fix comment style.
Signed-off-by: Andrey Konovalov
---
include/uapi/linux/usb/raw_gadget.h | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/uapi/linux/usb/raw_gadget.h
b/in
Raw Gadget is currently unable to stall/halt/wedge gadget endpoints,
which is required for proper emulation of certain USB classes.
This patch adds a few more ioctls:
- USB_RAW_IOCTL_EP0_STALL allows to stall control endpoint #0 when
there's a pending setup request for it.
- USB_RAW_IOCTL_SET/C
They must return the number of bytes transferred during the data stage.
Fixes: 068fbff4f860 ("usb: raw-gadget: Fix copy_to/from_user() checks")
Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
Signed-off-by: Andrey Konovalov
---
drivers/usb/gadget/legacy/raw_gadget.c | 8 ++--
1
Currently automatic gadget endpoint selection based on required features
doesn't work. Raw Gadget tries iterating over the list of available
endpoints and finding one that has the right direction and transfer type.
Unfortunately selecting arbitrary gadget endpoints (even if they satisfy
feature req
Mention the issue with fixed UDC addresses.
Links external examples and test suite.
Add more implmenetation details and potential improvements.
Signed-off-by: Andrey Konovalov
---
Documentation/usb/raw-gadget.rst | 30 --
1 file changed, 28 insertions(+), 2 deletion
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de
correo electrónico. Para revalidar su buzón de corre
On Thu, May 07, 2020 at 01:00:06PM -0400, Johannes Weiner wrote:
> On Wed, May 06, 2020 at 05:55:35PM -0700, Andrew Morton wrote:
> > On Wed, 6 May 2020 17:42:40 -0700 "Paul E. McKenney"
> > wrote:
> >
> > > This commit adds a shrinker so as to inform RCU when memory is scarce.
> > > RCU respond
On 5/7/20 11:57 AM, Joe Perches wrote:
On Thu, 2020-05-07 at 11:12 -0500, Himanshu Madhani wrote:
I do not have access to my @marvell.com email ID anymore.
Lets map my new email address correctly in .mailmap
Bad patch subject, this is a .mailmap patch.
Maybe [PATCH] .mailmap: Update addres
On Thu, 2020-05-07 at 09:52 -0700, Dave Hansen wrote:
> On 5/7/20 9:49 AM, Yu-cheng Yu wrote:
> > In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures
> > to a kernel buffer without touching areas for disabled xfeatures. However,
> > those uninitialized areas may contain rand
On Thu, 2020-05-07 at 18:56 +0200, Sebastian Andrzej Siewior wrote:
> On 2020-05-07 09:49:04 [-0700], Yu-cheng Yu wrote:
> > In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures
> > to a kernel buffer without touching areas for disabled xfeatures. However,
> > those uninitial
The MHI bus supports a standardized hardware reset, which is known as the
"SoC Reset". This reset is similar to the reset sysfs for PCI devices -
a hardware mechanism to reset the state back to square one.
The MHI SoC Reset is described in the spec as a reset of last resort. If
some unrecoverabl
Alexandre Chartre writes:
> On 5/5/20 3:43 PM, Thomas Gleixner wrote:
>> Traps enable interrupts conditionally but rely on the ASM return code to
>> disable them again. That results in redundant interrupt disable and trace
>> calls.
>>
>> Make the trap handlers disable interrupts before returnin
On Wed, May 06, 2020 at 10:40:19AM -0700, Paul E. McKenney wrote:
> On Wed, May 06, 2020 at 12:22:37PM -0400, Qian Cai wrote:
> > == call_rcu() leaks ==
> > Another issue that might be relevant is that it seems sometimes,
> > kmemleak will give a lot of false positives (hundreds) because the
> > me
On Wed, May 06, 2020 at 12:22:37PM -0400, Qian Cai wrote:
> What do you think about adding some aux call traces for kmemleak in
> general? For example, if the tracking object is a task struct, it
> would save call traces for the first and last call of both
> get_task_struct() and put_task_struct().
Hi!
On Thu, Apr 30, 2020 at 02:06:20PM +, Swapnil Kashinath Jakhade wrote:
> Thank you so much for reviewing the patch. Please see inline reply below.
>
> > -Original Message-
> > From: Maxime Ripard
> > Sent: Wednesday, April 29, 2020 5:58 PM
> > To: Yuti Suresh Amonkar
> > Cc: lin
While preparing the driver for upstream this detail was missed.
If not asserted during the initialization process, devices connected on
the bus will not be made aware of the internal reset happening. This,
potentially resulting in unexpected behavior.
Fixes: c0452137034b ("PCI: brcmstb: Add Broad
On 7/05/20 7:15 pm, Veerabhadrarao Badiganti wrote:
> From: Sarthak Garg
>
> Consider the following stack trace
>
> -001|raw_spin_lock_irqsave
> -002|mmc_blk_cqe_complete_rq
> -003|__blk_mq_complete_request(inline)
> -003|blk_mq_complete_request(rq)
> -004|mmc_cqe_timed_out(inline)
> -004|mmc_mq
On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道：
> >
> > Hi,
> >
> > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > > Hi Maxime,
> > >
> > > Thanks for your V2 patch series! I'm testing it.
> > >
> > > This patch series
On Thu, May 7, 2020 at 9:48 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Thu, May 07, 2020 at 11:28:57AM -0500, Paul A. Clarke escreveu:
> > From: "Paul A. Clarke"
> >
> > The metric definition is too long for the current value of EXPR_MAX_OTHER.
> > Increase the value EXPR_MAX_OTHER sufficiently to
On 5/5/20 3:49 PM, Thomas Gleixner wrote:
From: Peter Zijlstra
DR6/7 should be handled before nmi_enter() is invoked and restore after
nmi_exit() to minimize the exposure.
Split it out into helper inlines and bring it into the correct order.
Signed-off-by: Peter Zijlstra
Signed-off-by: Tho
We need sysclk6_ck enabled early as it is needed by l4_ls and system
timers early on boot. This removes the dependency of system timers to
the interconnect related code that can be then probed later on when
suitable at module_init time.
Cc: linux-...@vger.kernel.org
Cc: Grygorii Strashko
Cc: Mich
This allows us to move the SoCs to probe system timers one SoC
at at time. As arch/arm/mach-omap2/timer.c will be eventually gone,
let's just add omap_init_time_of() to board-generic.c directly.
Cc: Grygorii Strashko
Cc: Keerthy
Cc: Lokesh Vutla
Cc: Rob Herring
Cc: Tero Kristo
Signed-off-by:
On Thu, 2020-05-07 at 12:08 -0500, himanshu.madh...@oracle.com wrote:
>
> On 5/7/20 11:57 AM, Joe Perches wrote:
> > On Thu, 2020-05-07 at 11:12 -0500, Himanshu Madhani wrote:
> > > I do not have access to my @marvell.com email ID anymore.
> > > Lets map my new email address correctly in .mailmap
Some early omap3 boards use timer12 for system timer, but for secure
SoCs like on n900 it's not accessible. Likely we will be configuring
unavailable devices for other SoCs too based on runtime SoC detection,
so let's use a switch to start with.
Cc: Grygorii Strashko
Cc: Keerthy
Cc: Lokesh Vutla
Hi all,
Here's v3 series to udpate omaps to use drivers/clocksource timers for
the 32k counter and dmtimer, and to remove the old legacy platform code.
Please review and test.
I've updated the timer-ti-dm-systimer.c patch based on the comments from
Daniel and Rob, and added support for selecting
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on th
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on th
We can move the TI dmtimer clockevent and clocksource to live under
drivers/clocksource if we rely only on the clock framework, and handle
the module configuration directly in the clocksource driver based on the
device tree data.
This removes the early dependency with system timers to the intercon
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on th
As timers no longer need legacy quirk handling, let's move them to
the CONFIG_DEBUG section to make it easier to see which drivers still
need more work.
Let's also add detection for few more older timer revisions while at
it as that makes CONFIG_DEBUG output easier to read with proper names.
Cc:
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on th
Let's allow probing the 32k counter directly based on devicetree data to
prepare for dropping the related legacy platform code. Let's only do this
if the parent node is compatible with ti-sysc to make sure we have the
related devicetree data available.
Let's also show the 32k counter information b
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on th
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on th
We can now init system timers using the dmtimer and 32k counter
based on only devicetree data and drivers/clocksource timers.
Let's configure the clocksource and clockevent, and drop the old
unused platform data.
As we're just dropping platform data, and the early platform data
init is based on th
On Thu, May 7, 2020 at 9:46 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Thu, Apr 30, 2020 at 09:38:34PM +0800, Jin, Yao escreveu:
> > Hi John, Jiri,
> >
> > On 4/30/2020 7:48 PM, John Garry wrote:
> > > On 30/04/2020 12:15, Jiri Olsa wrote:
> > >
> > > +
> > >
> > > > On Thu, Apr 30, 2020 at 09:54:1
With dmtimer and 32k counter being initialized based on devicetree data,
we can just drop the old timer code.
This still leaves the omap5 and dra7 realtime_counter_init() that
depend on the smc calls and control module platform code for the dra7
quirk init.
Cc: Grygorii Strashko
Cc: Keerthy
Cc:
On Thu, 7 May 2020, Randy Dunlap wrote:
> > Changes since 20200505:
> >
>
>
> on i386 or x86_64:
>
> ERROR: modpost: "usb_hid_driver" [drivers/hid/hid-asus.ko] undefined!
> or
> (when builtin:)
> ld: drivers/hid/hid-asus.o: in function `asus_probe':
> hid-asus.c:(.text+0x60f): undefined refere
On Fri, 8 May 2020 00:50:28 +0900
Masami Hiramatsu wrote:
> > > Yes, I need Tom's review for this change. As far as I can test, this
> > > fixes the test failure. If this isn't acceptable, we can use "alias
> > > echo=echo"
> > > for this test case.
> > >
> >
> > I still don't see how changi
I do not have access to my @marvell.com email ID anymore.
Lets map my new email address correctly in .mailmap
Signed-off-by: Himanshu Madhani
---
Changes from v1
- Update patch subject line to reflect .mailmap changes.
---
.mailmap | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.mailmap
On Thu, May 7, 2020 at 4:26 PM Jeremy Linton wrote:
> On 5/5/20 8:29 AM, Calvin Johnson wrote:
> > + if (sscanf(cp, "ethernet-phy-id%4x.%4x",
> > +&upper, &lower) == 2) {
> > + *phy_id = ((upper & 0x) << 16) | (lower & 0x);
> > +
On 5/7/20 12:23 PM, Joe Perches wrote:
On Thu, 2020-05-07 at 12:08 -0500, himanshu.madh...@oracle.com wrote:
On 5/7/20 11:57 AM, Joe Perches wrote:
On Thu, 2020-05-07 at 11:12 -0500, Himanshu Madhani wrote:
I do not have access to my @marvell.com email ID anymore.
Lets map my new email addre
On Thu, 07 May 2020 12:17:36 +0100
Valentin Schneider wrote:
> On 07/05/20 12:06, Jason Yan wrote:
> > Fix the following coccicheck warning:
> >
> > kernel/sched/fair.c:9375:9-10: WARNING: return of 0/1 in function
> > 'voluntary_active_balance' with return type bool
> >
>
> It's perfectly saf
> On May 7, 2020, at 1:16 PM, Catalin Marinas wrote:
>
> I don't mind adding additional tracking info if it helps with debugging.
> But if it's for improving false positives, I'd prefer to look deeper
> into figure out why the pointer reference graph tracking failed.
No, the task struct leaks
On Thu, May 07, 2020 at 10:09:03AM -0700, Paul E. McKenney wrote:
> On Thu, May 07, 2020 at 01:00:06PM -0400, Johannes Weiner wrote:
> > On Wed, May 06, 2020 at 05:55:35PM -0700, Andrew Morton wrote:
> > > On Wed, 6 May 2020 17:42:40 -0700 "Paul E. McKenney"
> > > wrote:
> > >
> > > > This commi
On Thu, 7 May 2020 13:28:28 -0400
Steven Rostedt wrote:
> > It's perfectly safe to return 0/1 in a boolean function; that said seeing
> > as this is the second attempt at "fixing" this I'm tempted to say we should
> > pick it up...
> >
>
> Actually, I disagree. We should push back on the chec
v7 - Cleanup ehci-brcm.c as requested by Greg Kroah-Hartman.
- Split out Makefile re-order change into a separate commit.
v6 - Remove "contains:" from compatible section of
brcm,bcm7445-ehci.yaml as requested by Rob Herring.
v5 - Use devm_platform_get_and_ioremap_resource() in ehci-brcm.c
> >
> > Please see full log here:
> > ftp://vps418301.ovh.net/incoming/include_mm_h_output.txt
> >
> > I can fix it by adding the kvfree() declaration to the rcutiny.h also:
> > extern void kvfree(const void *addr);
> >
> > what seems wired to me? Also it can be fixed if i move it to the tiny.c
Add DT bindings for Broadcom STB USB EHCI and XHCI drivers.
NOTE: The OHCI driver is not included because it uses the generic
platform driver.
Signed-off-by: Al Cooper
Reviewed-by: Rob Herring
---
.../bindings/usb/brcm,bcm7445-ehci.yaml | 59 +++
.../devicetree/bind
Add a new EHCI driver for Broadcom STB SoC's. A new EHCI driver
was created instead of adding support to the existing ehci platform
driver because of the code required to workaround bugs in the EHCI
controller. The primary workround is for a bug where the Core
violates the SOF interval between the
Add the build system changes needed to get the Broadcom STB XHCI,
EHCI and OHCI functionality working. The OHCI support does not
require anything unique to Broadcom so the standard ohci-platform
driver is being used. Also update MAINTAINERS.
Signed-off-by: Al Cooper
---
MAINTAINERS
Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
devices and OHCI handles <2.0 devices. Currently the Makefile
has XHCI linking at the bottom which will result in the XHIC driver
initalizing after the EHCI and OHCI drive
Add support for Broadcom STB SoC's to the xhci platform driver
Signed-off-by: Al Cooper
Acked-by: Mathias Nyman
---
drivers/usb/host/xhci-plat.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1d4f6f85f0fe..44406d
The pull request you sent on Thu, 7 May 2020 07:53:32 -0400:
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8c16ec94dc767a4d8c48149d646e8c835512cf8f
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
The pull request you sent on Thu, 7 May 2020 17:31:10 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6e7f2eacf09811d092c1b41263108ac7fe0d089d
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Thu, 7 May 2020 18:16:28 +0200:
> git://git.infradead.org/users/hch/configfs.git tags/configfs-for-5.7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/de268ccb42d6ec5475ec5a5e60723b665d6e0af2
Thank you!
--
Deet-doot-dot, I am a bot.
https
On Tue, May 5, 2020 at 7:13 AM Thomas Gleixner wrote:
>
> Make sure task_work runs before any kind of userspace -- very much
> including signals -- is invoked.
I certainly approve of the change, but anything that fundamentally
relies on this makes me uneasy. I'll keep an eye out for potential
pr
Hi Maxime,
Am 24.04.20 um 17:35 schrieb Maxime Ripard:
> Now that the driver is ready for it, let's bring in the HDMI controllers
> variants for the BCM2711.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 276 +-
> drivers/gpu/drm/vc4/vc4_hdmi.h
On Thu, May 07, 2020 at 06:10:23PM +0200, Peter Zijlstra wrote:
> Thomas would very much like objtool to understand and generate correct
> ORC unwind information for the minimal stack swizzle sequence:
>
> mov %rsp, (%[ts])
> mov %[ts], %rsp
> ...
> pop %rsp
>
> This seque
From: "Steven Rostedt (VMware)"
x86_64 lazily maps in the vmalloc pages, and the way this works with per_cpu
areas can be complex, to say the least. Mappings may happen at boot up, and
if nothing synchronizes the page tables, those page mappings may not be
synced till they are used. This causes i
…
> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
…
> @@ -1359,6 +1359,8 @@ static int wcn36xx_probe(struct platform_device *pdev)
> out_unmap:
> iounmap(wcn->ccu_base);
> iounmap(wcn->dxe_base);
> +out_channel:
> + rpmsg_destroy_ept(wcn->smd_channel);
> out_wq:
> ieee80211_
From: Zou Wei
Fix the following sparse warning:
kernel/trace/trace.c:950:6: warning: symbol 'tracing_snapshot_instance_cond'
was not declared. Should it be static?
Link:
http://lkml.kernel.org/r/1587614905-48692-1-git-send-email-zou_...@huawei.com
Reported-by: Hulk Robot
Signed-off-by: Zou W
From: Masami Hiramatsu
Fix boottime kprobe events to use API correctly for
multiple events.
For example, when we set a multiprobe kprobe events in
bootconfig like below,
ftrace.event.kprobes.myevent {
probes = "vfs_read $arg1 $arg2", "vfs_write $arg1 $arg2"
}
This cause an error;
From: "Steven Rostedt (VMware)"
Running on a slower machine, it is possible that the preempt delay kernel
thread may still be executing if the module was immediately removed after
added, and this can cause the kernel to crash as the kernel thread might be
executing after its code has been removed
From: Wei Yang
As the example below shows, DECLARE_EVENT_CLASS() is used instead of
DEFINE_EVENT_CLASS().
Link: http://lkml.kernel.org/r/20200428214959.11259-1-richard.weiy...@gmail.com
Signed-off-by: Wei Yang
Signed-off-by: Steven Rostedt (VMware)
---
samples/trace_events/trace-events-sampl
From: Masami Hiramatsu
Reject the new event which has NULL location for kprobes.
For kprobes, user must specify at least the location.
Link:
http://lkml.kernel.org/r/158779376597.6082.1411212055469099461.stgit@devnote2
Cc: Tom Zanussi
Cc: Ingo Molnar
Cc: sta...@vger.kernel.org
Fixes: 2a588dd
From: Masami Hiramatsu
If there is a bootconfig data in the tail of initrd/initramfs,
initrd image sanity check caused an error while decompression
stage as follows.
[0.883882] Unpacking initramfs...
[2.696429] Initramfs unpacking failed: invalid magic at start of compressed
archive
Th
Masami Hiramatsu (4):
bootconfig: Fix to remove bootconfig data from initrd while boot
tracing/kprobes: Fix a double initialization typo
tracing/boottime: Fix kprobe event API usage
tracing/kprobes: Reject new event if loc is NULL
Steven Rostedt (VMware) (2):
tracing:
From: Masami Hiramatsu
Fix a typo that resulted in an unnecessary double
initialization to addr.
Link:
http://lkml.kernel.org/r/158779374968.6082.2337484008464939919.stgit@devnote2
Cc: Tom Zanussi
Cc: Ingo Molnar
Cc: sta...@vger.kernel.org
Fixes: c7411a1a126f ("tracing/kprobe: Check whether
From: Yiwei Zhang
This change updates the improper comment for the 'size' attribute in the
tracepoint definition. Most gfx drivers pre-fault in physical pages
instead of making virtual allocations. So we drop the 'Virtual' keyword
here and leave this to the implementations.
Link: http://lkml.ker
On 07/05/20 18:38, Peter Xu wrote:
> On Thu, May 07, 2020 at 06:21:18PM +0200, Paolo Bonzini wrote:
>> On 07/05/20 18:18, Peter Xu wrote:
if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
- vcpu->run->debug.arch.dr6 = vcpu->arch.dr6;
+ vcp
Hi!
> R-Car/RZ-G2x SoC's, this also extends the epf framework to handle multiple
> windows
> supported by the controller for mapping PCI address locally.
>
> Note:
> The cadence/rockchip/designware endpoint drivers are build tested only.
>
> Changes for v9 (Re-spun this series as there were mi
Hi!
> > it uses its own memory and CPUs + its virtio-vsock emulated device for
> > communication with the primary VM.
> >
> > The memory and CPUs are carved out of the primary VM, they are dedicated
> > for the enclave. The Nitro hypervisor running on the host ensures memory
> > and CPU isolation
On Tue 2020-04-21 17:36:18, Daniele Alessandrelli wrote:
> From: Daniele Alessandrelli
>
> Keem Bay bootloader sets up a temporary Isolated Memory Region (IMR) to
> protect itself during pre-Linux boot.
What kind of bootloader is the SoC using? Sounds like bootloader responsibility
to me...
901 - 1000 of 1862 matches
Mail list logo
