* [PATCH 2/5] ARM: dts: exynos: add pinctrl config for midas keys
From: Krzysztof Kozlowski @ 2018-07-23 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-3-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:50PM +1000, Simon Shields wrote:
> This pins are externally pulled up, and so we should explicitly
> configure them to disable the SoC-internal pull-downs. Previously
> we relied on the bootloader doing this in order to allow the buttons
> to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] ARM: dts: exynos: add pinctrl config for midas keys
From: Krzysztof Kozlowski @ 2018-07-23 17:12 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Rob Herring, Mark Rutland, Kukjin Kim,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20180721125128.31498-3-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:50PM +1000, Simon Shields wrote:
> This pins are externally pulled up, and so we should explicitly
> configure them to disable the SoC-internal pull-downs. Previously
> we relied on the bootloader doing this in order to allow the buttons
> to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/5] ARM: dts: exynos: add max77693 pinctrl config for midas
From: Krzysztof Kozlowski @ 2018-07-23 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-2-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:49PM +1000, Simon Shields wrote:
> Currently, we assume that the bootloader has correctly configured
> the interrupt pin for max77693. This might not actually be the case -
> so it's better to configure it explicitly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] ARM: dts: exynos: add max77693 pinctrl config for midas
From: Krzysztof Kozlowski @ 2018-07-23 17:12 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Rob Herring, Mark Rutland, Kukjin Kim,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20180721125128.31498-2-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:49PM +1000, Simon Shields wrote:
> Currently, we assume that the bootloader has correctly configured
> the interrupt pin for max77693. This might not actually be the case -
> so it's better to configure it explicitly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 00/15] xen/arm: Bunch of clean-up/improvement
From: Julien Grall @ 2018-07-23 17:12 UTC (permalink / raw)
To: xen-devel; +Cc: sstabellini
In-Reply-To: <20180716172712.20294-1-julien.grall@arm.com>
Ping?
Cheers,
On 16/07/18 18:26, Julien Grall wrote:
> Hi all,
>
> This is patch series is a bunch of clean-up/improvement I collected while
> working on the P2M and trap subsystems.
>
> Cheers,
>
> Julien Grall (15):
> xen/arm: cpregs: Allow HSR_CPREG* to receive more than 1 parameter
> xen/arm: cpregs: Fix typo in the documentation of TTBCR
> xen/arm: Introduce helpers to clear/flags flags in HCR_EL2
> xen/arm: p2m: Reduce the locking section in get_page_from_gva
> xen/arm: p2m: Limit call to mem access code use in get_page_from_gva
> xen/arm: Rework lpae_mapping
> xen/arm: Rework lpae_table
> xen/arm: Rename lpae_valid to lpae_is_valid
> xen/arm: guest_walk: Use lpae_is_mapping to simplify the code
> xen/arm: Introduce helpers to get/set an MFN from/to an LPAE entry
> xen/arm: Allow lpae_is_{table, mapping} helpers to work on invalid
> entry
> xen/arm: p2m: Rename ret to mfn in p2m_lookup
> xen/arm: p2m: Introduce a new variable removing_mapping in
> __p2m_set_entry
> xen/arm: guest_walk_tables: Switch the return to bool
> xen/arm: traps: Move the implementation of GUEST_BUG_ON in traps.h
>
> xen/arch/arm/guest_walk.c | 54 +++++++++----------
> xen/arch/arm/mem_access.c | 2 +-
> xen/arch/arm/mm.c | 18 +++----
> xen/arch/arm/p2m.c | 110 ++++++++++++++++++++++++---------------
> xen/arch/arm/traps.c | 27 +---------
> xen/include/asm-arm/cpregs.h | 6 +--
> xen/include/asm-arm/guest_walk.h | 8 +--
> xen/include/asm-arm/lpae.h | 27 +++++-----
> xen/include/asm-arm/processor.h | 18 +++++++
> xen/include/asm-arm/traps.h | 24 +++++++++
> 10 files changed, 168 insertions(+), 126 deletions(-)
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v2 10/12] sched/core: uclamp: use TG's clamps to restrict Task's clamps
From: Suren Baghdasaryan @ 2018-07-23 17:11 UTC (permalink / raw)
To: Patrick Bellasi
Cc: linux-kernel, linux-pm, Ingo Molnar, Peter Zijlstra, Tejun Heo,
Rafael J . Wysocki, Viresh Kumar, Vincent Guittot, Paul Turner,
Dietmar Eggemann, Morten Rasmussen, Juri Lelli, Todd Kjos,
Joel Fernandes, Steve Muckle
In-Reply-To: <20180723154025.GF2683@e110439-lin>
On Mon, Jul 23, 2018 at 8:40 AM, Patrick Bellasi
<patrick.bellasi@arm.com> wrote:
> On 21-Jul 20:05, Suren Baghdasaryan wrote:
>> On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
>> <patrick.bellasi@arm.com> wrote:
>> > When a task's util_clamp value is configured via sched_setattr(2), this
>> > value has to be properly accounted in the corresponding clamp group
>> > every time the task is enqueued and dequeued. When cgroups are also in
>> > use, per-task clamp values have to be aggregated to those of the CPU's
>> > controller's Task Group (TG) in which the task is currently living.
>> >
>> > Let's update uclamp_cpu_get() to provide aggregation between the task
>> > and the TG clamp values. Every time a task is enqueued, it will be
>> > accounted in the clamp_group which defines the smaller clamp between the
>> > task specific value and its TG value.
>>
>> So choosing smallest for both UCLAMP_MIN and UCLAMP_MAX means the
>> least boosted value and the most clamped value between syscall and TG
>> will be used.
>
> Right
>
>> My understanding is that boost means "at least this much" and clamp
>> means "at most this much".
>
> Right
>
>> So to satisfy both TG and syscall requirements I think you would
>> need to choose the largest value for UCLAMP_MIN and the smallest one
>> for UCLAMP_MAX, meaning the most boosted and most clamped range.
>> Current implementation choses the least boosted value, so
>> effectively one of the UCLAMP_MIN requirements (either from TG or
>> from syscall) are being ignored... Could you please clarify why
>> this choice is made?
>
> The TG values are always used to specify a _restriction_ on
> task-specific values.
>
> Thus, if you look or example at the CPU mask for a task, you can have
> a task with affinity to CPUs 0-1, currently running on a cgroup with
> cpuset.cpus=0... then the task can run only on CPU 0 (althought its
> affinity includes CPU1 too).
>
> Same we do here: if a task has util_min=10, but it's running in a
> cgroup with cpu.util_min=0, then it will not be boosted.
>
> IOW, this allows to implement a "nice" policy at task level, where a
> task (via syscall) can decide to be less boosted with respect to its
> group but never more boosted. The same task can also decide to be more
> clamped, but not less clamped then its current group.
>
The fact that boost means "at least this much" to me seems like we can
safely choose higher CPU bandwidth (as long as it's lower than
UCLAMP_MAX) but from your description sounds like TG's UCLAMP_MIN
means "at most this much boost" and it's not safe to use CPU bandwidth
higher than TG's UCLAMP_MIN. So instead of specifying min CPU
bandwidth for a task it specifies the max allowed boost. Seems like a
discrepancy to me but maybe there are compelling usecases when this
behavior is necessary? In that case would be good to spell them out to
explain why this choice is made.
> [...]
>
>> > @@ -982,18 +989,30 @@ static inline void uclamp_cpu_get_id(struct task_struct *p,
>> > int clamp_value;
>> > int group_id;
>> >
>> > - /* No task specific clamp values: nothing to do */
>> > group_id = p->uclamp[clamp_id].group_id;
>> > + clamp_value = p->uclamp[clamp_id].value;
>> > +#ifdef CONFIG_UCLAMP_TASK_GROUP
>> > + /* Use TG's clamp value to limit task specific values */
>> > + if (group_id == UCLAMP_NONE ||
>> > + clamp_value >= task_group(p)->uclamp[clamp_id].value) {
>>
>> Not a big deal but do you need to override if (clamp_value ==
>> task_group(p)->uclamp[clamp_id].value)? Maybe:
>> - clamp_value >= task_group(p)->uclamp[clamp_id].value) {
>> + clamp_value > task_group(p)->uclamp[clamp_id].value) {
>
> Good point, yes... the override is not really changing anything here.
> Will fix this!
>
>> > + clamp_value = task_group(p)->uclamp[clamp_id].value;
>> > + group_id = task_group(p)->uclamp[clamp_id].group_id;
>> > + }
>> > +#else
>> > + /* No task specific clamp values: nothing to do */
>> > if (group_id == UCLAMP_NONE)
>> > return;
>> > +#endif
>> >
>> > /* Reference count the task into its current group_id */
>> > uc_grp = &rq->uclamp.group[clamp_id][0];
>> > uc_grp[group_id].tasks += 1;
>> >
>> > + /* Track the effective clamp group */
>> > + p->uclamp_group_id[clamp_id] = group_id;
>> > +
>> > /* Force clamp update on idle exit */
>> > uc_cpu = &rq->uclamp;
>> > - clamp_value = p->uclamp[clamp_id].value;
>> > if (unlikely(uc_cpu->flags & UCLAMP_FLAG_IDLE)) {
>> > if (clamp_id == UCLAMP_MAX)
>> > uc_cpu->flags &= ~UCLAMP_FLAG_IDLE;
>
> [...]
>
> --
> #include <best/regards.h>
>
> Patrick Bellasi
^ permalink raw reply
* [Intel-wired-lan] [jkirsher/next-queue PATCH 2/2] ixgbe: Refactor queue disable logic to take completion time into account
From: Alexander Duyck @ 2018-07-23 17:10 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <ab26e694-6c7c-7e70-42f3-646939708ee2@oracle.com>
On Mon, Jul 23, 2018 at 9:34 AM, Shannon Nelson
<shannon.nelson@oracle.com> wrote:
> On 7/20/2018 3:29 PM, Alexander Duyck wrote:
>>
>> This change is meant to allow us to take completion time into account when
>> disabling queues. Previously we were just working with hard coded values
>> for how long we should wait. This worked fine for the standard case where
>> completion timeout was operating in the 50us to 50ms range, however on
>> platforms that have higher completion timeout times this was resulting in
>> Rx queues disable messages being displayed as we weren't waiting long
>> enough for outstanding Rx DMA completions.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> ---
>
>
> [...]
>
>
>> +
>> +void ixgbe_disable_tx(struct ixgbe_adapter *adapter)
>> +{
>> + unsigned long wait_delay, delay_interval;
>> + struct ixgbe_hw *hw = &adapter->hw;
>> + int i, wait_loop;
>> + u32 txdctl;
>> +
>> + if (ixgbe_removed(hw->hw_addr))
>> + return;
>> +
>> + /* disable all enabled Tx queues */
>> + for (i = 0; i < adapter->num_tx_queues; i++) {
>> + struct ixgbe_ring *ring = adapter->tx_ring[i];
>> + u8 reg_idx = ring->reg_idx;
>> +
>> + IXGBE_WRITE_REG(hw, IXGBE_TXDCTL(reg_idx),
>> IXGBE_TXDCTL_SWFLSH);
>> + }
>> +
>> + /* disable all enabled XDP Tx queues */
>> + for (i = 0; i < adapter->num_xdp_queues; i++) {
>> + struct ixgbe_ring *ring = adapter->xdp_ring[i];
>> + u8 reg_idx = ring->reg_idx;
>> +
>> + IXGBE_WRITE_REG(hw, IXGBE_TXDCTL(reg_idx),
>> IXGBE_TXDCTL_SWFLSH);
>> + }
>> +
>> + /* If the link is now up there shouldn't be much in the way of
>
>
> I think you mean "not" up rather than "now" up, which has the opposite
> meaning and could be a bit confusing.
Yeah, that is a typo.
>
>> + * pending transactions. Those that are left will be flushed out
>> + * when the reset logic goes through the flush sequence to clean
>> out
>> + * the pending Tx transactions.
>> + */
>> + if (!(IXGBE_READ_REG(hw, IXGBE_LINKS) & IXGBE_LINKS_UP))
>> + goto dma_engine_disable;
>> +
>> + /* Determine our minimum delay interval. We will increase this
>> value
>> + * with each subsequent test. This way if the device returns
>> quickly
>> + * we should spend as little time as possible waiting, however as
>> + * the time increases we will wait for larger periods of time.
>> + *
>> + * The trick here is that we increase the interval using the
>> + * following pattern: 1x 3x 5x 7x 9x 11x 13x 15x 17x 19x. The
>> result
>> + * of that wait is that it totals up to 100x whatever interval we
>> + * choose. Since our minimum wait is 100us we can just divide the
>> + * total timeout by 100 to get our minimum delay interval.
>> + */
>> + delay_interval = ixgbe_get_completion_timeout(adapter) / 100;
>> +
>> + wait_loop = IXGBE_MAX_RX_DESC_POLL;
>> + wait_delay = delay_interval;
>> +
>> + while (wait_loop--) {
>> + usleep_range(wait_delay, wait_delay + 10);
>> + wait_delay += delay_interval * 2;
>> + txdctl = 0;
>> +
>> + /* OR together the reading of all the active TXDCTL
>> registers,
>> + * and then test the result. We need the disable to
>> complete
>> + * before we start freeing the memory and invalidating the
>> + * DMA mappings.
>> + */
>> + for (i = 0; i < adapter->num_tx_queues; i++) {
>> + struct ixgbe_ring *ring = adapter->tx_ring[i];
>> + u8 reg_idx = ring->reg_idx;
>> +
>> + txdctl |= IXGBE_READ_REG(hw,
>> IXGBE_TXDCTL(reg_idx));
>> + }
>> + for (i = 0; i < adapter->num_xdp_queues; i++) {
>> + struct ixgbe_ring *ring = adapter->xdp_ring[i];
>> + u8 reg_idx = ring->reg_idx;
>> +
>> + txdctl |= IXGBE_READ_REG(hw,
>> IXGBE_TXDCTL(reg_idx));
>> + }
>> +
>> + if (!(txdctl & IXGBE_TXDCTL_ENABLE))
>> + goto dma_engine_disable;
>> + }
>> +
>> + e_err(drv,
>> + "TXDCTL.ENABLE for one or more queues not cleared within the
>> polling period\n");
>> +
>> +dma_engine_disable:
>> + /* Disable the Tx DMA engine on 82599 and later MAC */
>> + switch (hw->mac.type) {
>> + case ixgbe_mac_82599EB:
>> + case ixgbe_mac_X540:
>> + case ixgbe_mac_X550:
>> + case ixgbe_mac_X550EM_x:
>> + case ixgbe_mac_x550em_a:
>> + IXGBE_WRITE_REG(hw, IXGBE_DMATXCTL,
>> + (IXGBE_READ_REG(hw, IXGBE_DMATXCTL) &
>> + ~IXGBE_DMATXCTL_TE));
>> + /* fall through */
>> + default:
>> + break;
>> + }
>
>
> Picky bike-shed thoughts: I realize you're just moving the previously
> existing code, but with the comment "... and later MAC" I would think the
> translation to code puts all the later MACs into the default and have the
> WRITE_REG() as the default action. This would make it default to the
> correct action for any new MACs if someone forgot to fix up this part of the
> code.
>
> switch (hw->mac.type) {
> case ixgbe_mac_82598EB:
> break;
>
> case ixgbe_mac_82599EB:
> case ixgbe_mac_X540:
> case ixgbe_mac_X550:
> case ixgbe_mac_X550EM_x:
> case ixgbe_mac_x550em_a:
> default:
> IXGBE_WRITE_REG(hw, IXGBE_DMATXCTL,
> (IXGBE_READ_REG(hw, IXGBE_DMATXCTL) &
> ~IXGBE_DMATXCTL_TE));
> break;
> }
>
> Or even simpler,
>
> if (hw->mac.type != ixgbe_mac_82598EB)
> IXGBE_WRITE_REG(hw, IXGBE_DMATXCTL,
> (IXGBE_READ_REG(hw, IXGBE_DMATXCTL) &
> ~IXGBE_DMATXCTL_TE));
>
> Okay, I'll stop now.
>
> Cheers,
> sln
Yeah, for now I will probably leave the code as is, but this is
something that could be updated int he future. Either that or you are
always free to submit a patch.. :-)
- Alex
^ permalink raw reply
* Applied "regmap: sccb: fix typo and sort headers alphabetically" to the regmap tree
From: Mark Brown @ 2018-07-23 17:10 UTC (permalink / raw)
To: Akinobu Mita; +Cc: Wolfram Sang, Mark Brown, linux-kernel
The patch
regmap: sccb: fix typo and sort headers alphabetically
has been applied to the regmap tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 75eb3a67a29e9f87c07c8bd184a7ed4274a58ef0 Mon Sep 17 00:00:00 2001
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Mon, 23 Jul 2018 00:45:46 +0900
Subject: [PATCH] regmap: sccb: fix typo and sort headers alphabetically
Fix typos 's/wit/with/' in the comments and sort headers alphabetically
in order to avoid duplicate includes in future.
Fixes: bcf7eac3d97f ("regmap: add SCCB support")
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/base/regmap/regmap-sccb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/base/regmap/regmap-sccb.c b/drivers/base/regmap/regmap-sccb.c
index b6eb876ea819..597042e2d009 100644
--- a/drivers/base/regmap/regmap-sccb.c
+++ b/drivers/base/regmap/regmap-sccb.c
@@ -1,9 +1,9 @@
// SPDX-License-Identifier: GPL-2.0
// Register map access API - SCCB support
-#include <linux/regmap.h>
#include <linux/i2c.h>
#include <linux/module.h>
+#include <linux/regmap.h>
#include "internal.h"
@@ -29,7 +29,7 @@ static bool sccb_is_available(struct i2c_adapter *adap)
/**
* regmap_sccb_read - Read data from SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
* @reg: Register to be read from
* @val: Pointer to store read value
*
@@ -65,7 +65,7 @@ static int regmap_sccb_read(void *context, unsigned int reg, unsigned int *val)
/**
* regmap_sccb_write - Write data to SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
* @reg: Register to write to
* @val: Value to be written
*
--
2.18.0
^ permalink raw reply related
* [PATCH v2] hvm/altp2m: Clarify the proper way to extend the altp2m interface
From: George Dunlap @ 2018-07-23 17:09 UTC (permalink / raw)
To: xen-devel
Cc: Lars Kurth, Stefano Stabellini, Wei Liu, Razvan Cojocaru,
Andrew Cooper, Adrian Pop, Tim Deegan, George Dunlap,
Julien Grall, Jan Beulich, Tamas K Lengyel, Ian Jackson
The altp2m functionality was originally envisioned to be used in
several different configurations, one of which was a single in-guest
agent that had full operational control of altp2m. This required the
single hypercall to be an HVMOP rather than a DOMCTL, since HVM guests
are not allowed to make DOMCTLs. Access to this HVMOP is controlled
by a per-domain HVM_PARAM, and defaults to 'off'.
Exposing the altp2m functionality to the guest was controversial at
the time, but was ultimately accepted. The fact that altp2m is an
HVMOP rather than a DOMCTL has caused some problems, however, for
those moving forward trying to extend the interface: Extending the
interface even for the 'external' use case now means extending an
HVMOP, which implicitly extends the surface of attack for the
'internal' use case as well. The result has been that every addition
to this interface has also been controversial.
Settle the controversy once and for all by documenting 1) the purpose
of the altp2m interface, and 2) how to extend it. In particular:
* Specify that the fully in-guest agent is a target use case
* Specify that all extensions to altp2m functionality should be subops
of the HVMOP hypercall
* Specify that new subops should be enabled in ALTP2M_mixed mode by
default, but that this mode has not been evaluated for safety.
Hopefully this will allow the altp2m interface to be developed further
without unnecessary controversy.
Further discussion:
As far as I can tell there are three possible solutions to this
controversy.
A. Remove the 'internal' functionality as a target by converting the
current HVMOP into a DOMCTL.
B. Have two hypercalls -- an HVMOP which contains functionality
expected to be used by the 'internal' agent, and a DOMCTL for
functionality which is expected to be used only be the 'external'
agent.
C. Agree to add all new subops to the current hypercall (HVMOP), even
if we're not sure if they should be exposed to the guest.
I think A is a terrible idea. Having a single in-guest agent is a
reasonable design choice, and apparently it was even implemented at
some point; we should make it straightforward for someone in the
future to pick up the work if they want to.
I think B is also a bad idea. The people extending it at the moment
are primarily concerned with the 'external' use case. There is nobody
around to represent whether new functionality should end up in the
HVMOP or the DOMCTL, which means that by default it will end up in the
DOMCTL. If it is discovered, afterwards, that the new operations
*would* be safe and useful for the 'internal' use case, then we will
either have to duplicate them inside the HVMOP (which would be
terrible) or move the operation from the DOMCTL to the HVMOP (which
would make coding an agent against several versions a mess).
It just makes more sense to have all the altp2m operations in a single
place, and a simple way to control whether they're available to the
'internal' use case or not. As such, I am proposing 'C'.
Even within that, we have several options as far as what to do with
the current interface:
C1: Audit the current subops and make a blacklist of subops not
suitable for exposure to the guest. Future subops should be on the
blacklist unless they have been evaluated as safe for exposure.
C2: Don't blacklist the current subops, but require that all future
subops be blacklisted unless they have been evaluated as safe for
exposure.
C3: Don't blacklist current or future subops for the present; just
document that they need to be evaluated (and some potentially
blacklisted) before being exposed to a guest in a safety-critical
environment.
C1 would be ideal, but there's nobody at present to do the work.
Given that, C3 has been seen as the best solution in discussion.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v1:
- Patch description: clarify that HVM guest can't make domctls
- No blacklist for the 'internal' use case; instead document its risk
- Move more of the discussion into the commit message.
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien.grall@arm.com>
CC: Tamas K Lengyel <tamas.lengyel@zentific.com>
CC: Razvan Cojocaru <rcojocaru@bitdefender.com>
CC: Adrian Pop <apop@bitdefender.com>
CC: Lars Kurth <lars.kurth@citrix.com>
---
xen/arch/x86/hvm/hvm.c | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 1816faa9b3..84eed1f4bc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4467,6 +4467,37 @@ static int hvmop_get_param(
return rc;
}
+/*
+ * altp2m operations are envisioned as being used in several different
+ * modes:
+ *
+ * - external: All control and decisions are made by an external agent
+ * running domain 0.
+ *
+ * - internal: altp2m operations are used exclusively by an in-guest
+ * agent to protect itself from the guest kernel and in-guest
+ * attackers.
+ *
+ * - coordinated: An in-guest agent handles #VE and VMFUNCs locally,
+ * but makes requests of an agent running outside the domain for
+ * bigger changes (such as modifying altp2m entires).
+ *
+ * This corresponds to the three values for HVM_PARAM_ALTP2M
+ * (external, mixed, limited). All three models have advantages and
+ * disadvantages.
+ *
+ * Normally hypercalls made by a program in domain 0 in order to
+ * control a guest would be DOMCTLs rather than HVMOPs. But in order
+ * to properly enable the 'internal' use case, as well as to avoid
+ * fragmentation, all altp2m subops should come under this single
+ * HVMOP.
+ *
+ * Note that 'internal' mode (HVM_PARAM_ALTP2M == XEN_ALTP2M_mixed)
+ * has not been evaluated for safety from a security perspective.
+ * Before using this mode in a security-critical environment, each
+ * subop should be evaluated for safety, with unsafe subops
+ * blacklisted in xsm_hvm_altp2mhvm_op().
+ */
static int do_altp2m_op(
XEN_GUEST_HANDLE_PARAM(void) arg)
{
--
2.18.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Applied "regmap: sccb: fix typo and sort headers alphabetically" to the regmap tree
From: Mark Brown @ 2018-07-23 17:09 UTC (permalink / raw)
To: Akinobu Mita; +Cc: Wolfram Sang, Mark Brown, linux-kernel
The patch
regmap: sccb: fix typo and sort headers alphabetically
has been applied to the regmap tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 75eb3a67a29e9f87c07c8bd184a7ed4274a58ef0 Mon Sep 17 00:00:00 2001
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Mon, 23 Jul 2018 00:45:46 +0900
Subject: [PATCH] regmap: sccb: fix typo and sort headers alphabetically
Fix typos 's/wit/with/' in the comments and sort headers alphabetically
in order to avoid duplicate includes in future.
Fixes: bcf7eac3d97f ("regmap: add SCCB support")
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/base/regmap/regmap-sccb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/base/regmap/regmap-sccb.c b/drivers/base/regmap/regmap-sccb.c
index b6eb876ea819..597042e2d009 100644
--- a/drivers/base/regmap/regmap-sccb.c
+++ b/drivers/base/regmap/regmap-sccb.c
@@ -1,9 +1,9 @@
// SPDX-License-Identifier: GPL-2.0
// Register map access API - SCCB support
-#include <linux/regmap.h>
#include <linux/i2c.h>
#include <linux/module.h>
+#include <linux/regmap.h>
#include "internal.h"
@@ -29,7 +29,7 @@ static bool sccb_is_available(struct i2c_adapter *adap)
/**
* regmap_sccb_read - Read data from SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
* @reg: Register to be read from
* @val: Pointer to store read value
*
@@ -65,7 +65,7 @@ static int regmap_sccb_read(void *context, unsigned int reg, unsigned int *val)
/**
* regmap_sccb_write - Write data to SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
* @reg: Register to write to
* @val: Value to be written
*
--
2.18.0
^ permalink raw reply related
* Re: [PATCH] firmware: vpd: Fix section enabled flag on vpd_section_destroy
From: Dmitry Torokhov @ 2018-07-23 17:09 UTC (permalink / raw)
To: Anton Vasilyev
Cc: Greg Kroah-Hartman, Guenter Roeck, Samuel Holland, Pan Bian,
linux-kernel, ldv-project
In-Reply-To: <20180723164857.24460-1-vasilyev@ispras.ru>
On Mon, Jul 23, 2018 at 07:48:57PM +0300, Anton Vasilyev wrote:
> static struct ro_vpd and rw_vpd are initialized by vpd_sections_init()
> in vpd_probe() based on header's ro and rw sizes.
> In vpd_remove() vpd_section_destroy() performs deinitialization based
> on enabled flag, which is set to true by vpd_sections_init().
> This leads to call of vpd_section_destroy() on already destroyed section
> for probe-release-probe-release sequence if first probe performs
> ro_vpd initialization and second probe does not initialize it.
>
> The patch adds changing enabled flag on vpd_section_destroy.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
Good find.
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/firmware/google/vpd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/firmware/google/vpd.c b/drivers/firmware/google/vpd.c
> index e9db895916c3..5347c17c7108 100644
> --- a/drivers/firmware/google/vpd.c
> +++ b/drivers/firmware/google/vpd.c
> @@ -246,6 +246,7 @@ static int vpd_section_destroy(struct vpd_section *sec)
> sysfs_remove_bin_file(vpd_kobj, &sec->bin_attr);
> kfree(sec->raw_name);
> memunmap(sec->baseaddr);
> + sec->enabled = false;
> }
>
> return 0;
> --
> 2.18.0
>
Thanks.
--
Dmitry
^ permalink raw reply
* UBIFS: Shrinking in place
From: Martin Vuille @ 2018-07-23 17:08 UTC (permalink / raw)
To: linux-mtd
I need to shrink an existing UBIFS filesystem "in place" as a
prelude to shrinking the underlying UBI volume.
Back in 2010 (http://lists.infradead.org/pipermail/linux-mtd/2010-January/028667.html)
it was stated on this list that this is not supported.
Wondering whether anything has changed since then?
If still not supported, I would like to consider undertaking
that work, and I'm looking for some guidance how best to
approach it.
MV
^ permalink raw reply
* Applied "regmap: sccb: fix typo and sort headers alphabetically" to the regmap tree
From: Mark Brown @ 2018-07-23 17:08 UTC (permalink / raw)
To: Akinobu Mita; +Cc: Wolfram Sang, Mark Brown, linux-kernel
The patch
regmap: sccb: fix typo and sort headers alphabetically
has been applied to the regmap tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 75eb3a67a29e9f87c07c8bd184a7ed4274a58ef0 Mon Sep 17 00:00:00 2001
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Mon, 23 Jul 2018 00:45:46 +0900
Subject: [PATCH] regmap: sccb: fix typo and sort headers alphabetically
Fix typos 's/wit/with/' in the comments and sort headers alphabetically
in order to avoid duplicate includes in future.
Fixes: bcf7eac3d97f ("regmap: add SCCB support")
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/base/regmap/regmap-sccb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/base/regmap/regmap-sccb.c b/drivers/base/regmap/regmap-sccb.c
index b6eb876ea819..597042e2d009 100644
--- a/drivers/base/regmap/regmap-sccb.c
+++ b/drivers/base/regmap/regmap-sccb.c
@@ -1,9 +1,9 @@
// SPDX-License-Identifier: GPL-2.0
// Register map access API - SCCB support
-#include <linux/regmap.h>
#include <linux/i2c.h>
#include <linux/module.h>
+#include <linux/regmap.h>
#include "internal.h"
@@ -29,7 +29,7 @@ static bool sccb_is_available(struct i2c_adapter *adap)
/**
* regmap_sccb_read - Read data from SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
* @reg: Register to be read from
* @val: Pointer to store read value
*
@@ -65,7 +65,7 @@ static int regmap_sccb_read(void *context, unsigned int reg, unsigned int *val)
/**
* regmap_sccb_write - Write data to SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
* @reg: Register to write to
* @val: Value to be written
*
--
2.18.0
^ permalink raw reply related
* Re: [PATCH] drm/atomic: Check old_plane_state->crtc in drm_atomic_helper_async_check()
From: Eric Anholt @ 2018-07-23 17:07 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, dri-devel; +Cc: Boris Brezillon
In-Reply-To: <20180723134354.26298-1-boris.brezillon@bootlin.com>
[-- Attachment #1.1: Type: text/plain, Size: 646 bytes --]
Boris Brezillon <boris.brezillon@bootlin.com> writes:
> Async plane update is supposed to work only when updating the FB or FB
> position of an already enabled plane. That does not apply to requests
> where the plane was previously disabled or assigned to a different
> CTRC.
>
> Check old_plane_state->crtc value to make sure async plane update is
> allowed.
>
> Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane update")
> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
I don't think any driver I've worked on would want an async flip of a
plane between CRTCs.
Reviewed-by: Eric Anholt <eric@anholt.net>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 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
* Applied "regmap: sccb: fix typo and sort headers alphabetically" to the regmap tree
From: Mark Brown @ 2018-07-23 17:06 UTC (permalink / raw)
To: Akinobu Mita; +Cc: Wolfram Sang, Mark Brown, linux-kernel
The patch
regmap: sccb: fix typo and sort headers alphabetically
has been applied to the regmap tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 75eb3a67a29e9f87c07c8bd184a7ed4274a58ef0 Mon Sep 17 00:00:00 2001
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Mon, 23 Jul 2018 00:45:46 +0900
Subject: [PATCH] regmap: sccb: fix typo and sort headers alphabetically
Fix typos 's/wit/with/' in the comments and sort headers alphabetically
in order to avoid duplicate includes in future.
Fixes: bcf7eac3d97f ("regmap: add SCCB support")
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/base/regmap/regmap-sccb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/base/regmap/regmap-sccb.c b/drivers/base/regmap/regmap-sccb.c
index b6eb876ea819..597042e2d009 100644
--- a/drivers/base/regmap/regmap-sccb.c
+++ b/drivers/base/regmap/regmap-sccb.c
@@ -1,9 +1,9 @@
// SPDX-License-Identifier: GPL-2.0
// Register map access API - SCCB support
-#include <linux/regmap.h>
#include <linux/i2c.h>
#include <linux/module.h>
+#include <linux/regmap.h>
#include "internal.h"
@@ -29,7 +29,7 @@ static bool sccb_is_available(struct i2c_adapter *adap)
/**
* regmap_sccb_read - Read data from SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
* @reg: Register to be read from
* @val: Pointer to store read value
*
@@ -65,7 +65,7 @@ static int regmap_sccb_read(void *context, unsigned int reg, unsigned int *val)
/**
* regmap_sccb_write - Write data to SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
* @reg: Register to write to
* @val: Value to be written
*
--
2.18.0
^ permalink raw reply related
* [PATCH] scsi: mptfusion: Fix potential Spectre v1
From: Gustavo A. R. Silva @ 2018-07-23 17:06 UTC (permalink / raw)
To: Sathya Prakash, Chaitra P B, Suganath Prabu Subramani
Cc: MPT-FusionLinux.pdl, linux-scsi, linux-kernel,
Gustavo A. R. Silva
port can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/message/fusion/mptctl.c:1360 mptctl_getiocinfo() warn:
potential spectre issue 'ioc->pfacts'
Fix this by sanitizing port before using it to index ioc->pfacts
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/message/fusion/mptctl.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/message/fusion/mptctl.c b/drivers/message/fusion/mptctl.c
index 4470630..6751a40 100644
--- a/drivers/message/fusion/mptctl.c
+++ b/drivers/message/fusion/mptctl.c
@@ -66,6 +66,9 @@
#include <scsi/scsi_host.h>
#include <scsi/scsi_tcq.h>
+/* Hardening for Spectre-v1 */
+#include <linux/nospec.h>
+
#define COPYRIGHT "Copyright (c) 1999-2008 LSI Corporation"
#define MODULEAUTHOR "LSI Corporation"
#include "mptbase.h"
@@ -1306,7 +1309,7 @@ mptctl_getiocinfo (unsigned long arg, unsigned int data_size)
kfree(karg);
return -EINVAL;
}
- port = karg->hdr.port;
+ port = array_index_nospec(karg->hdr.port, 2);
karg->port = port;
pdev = (struct pci_dev *) ioc->pcidev;
--
2.7.4
^ permalink raw reply related
* [Amlogic 64-bit DT updates for v4.19, round 2 (redo)
From: Kevin Hilman @ 2018-07-23 17:06 UTC (permalink / raw)
To: linux-arm-kernel
[ fixes the original round 2 by removing the unnecessary (and wrong)
merge of v4.18-rc5.]
Olof, Arnd,
A second round of DT updates for Amlogic, directly on top of the redo of
the first one.
This includes a merge of a branch already queued in the clk tree because
of the dependency on clock headers used in the DT changes here..
Kevin
The following changes since commit 89803e8b26569bdf5798f8745a4c708bf9360ee6:
ARM64: dts: meson-axg: add pdm pins (2018-07-20 08:18:37 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2-1
for you to fetch changes up to aaa080fa7e0f01f7cd8eb22a7385a4d8106c7478:
ARM64: dts: meson-gxl: add support for the Oranth Tanix TX3 Mini (2018-07-20 09:02:22 -0700)
----------------------------------------------------------------
Amlogic 64-bit DT changes for v4.19, round 2
- new SoC: S905W
- new boards: based on S905W: Amlogic P281, Oranth Tanix TX3 Mini
- AXG: add DT for new audio clock controller
----------------------------------------------------------------
Jerome Brunet (3):
dt-bindings: clock: add meson axg audio clock controller bindings
clk: meson: expose GEN_CLK clkid
ARM64: dts: meson-axg: add the audio clock controller
Kevin Hilman (1):
Merge tag 'meson-clk-dt-for-v4.19' of https://github.com/BayLibre/clk-meson into v4.19/dt64-2
Martin Blumenstingl (5):
dt-bindings: add vendor prefix for Shenzhen Oranth Technology Co., Ltd.
dt-bindings: arm: amlogic: Add support for GXL S905W and the P281 board
dt-bindings: arm: amlogic: Add support for the Oranth Tanix TX3 Mini
ARM64: dts: meson-gxl: add support for the S905W SoC and the P281 board
ARM64: dts: meson-gxl: add support for the Oranth Tanix TX3 Mini
Yixun Lan (1):
clk: meson-axg: add pcie and mipi clock bindings
Documentation/devicetree/bindings/arm/amlogic.txt | 7 ++
.../bindings/clock/amlogic,axg-audio-clkc.txt | 56 +++++++++++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm64/boot/dts/amlogic/Makefile | 2 +
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 36 +++++++++
.../boot/dts/amlogic/meson-gxl-s905w-p281.dts | 22 +++++
.../boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts | 22 +++++
include/dt-bindings/clock/axg-audio-clkc.h | 94 ++++++++++++++++++++++
include/dt-bindings/clock/axg-clkc.h | 4 +
include/dt-bindings/clock/gxbb-clkc.h | 1 +
10 files changed, 245 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905w-p281.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts
create mode 100644 include/dt-bindings/clock/axg-audio-clkc.h
^ permalink raw reply
* [Amlogic 64-bit DT updates for v4.19, round 2 (redo)
From: Kevin Hilman @ 2018-07-23 17:06 UTC (permalink / raw)
To: linus-amlogic
[ fixes the original round 2 by removing the unnecessary (and wrong)
merge of v4.18-rc5.]
Olof, Arnd,
A second round of DT updates for Amlogic, directly on top of the redo of
the first one.
This includes a merge of a branch already queued in the clk tree because
of the dependency on clock headers used in the DT changes here..
Kevin
The following changes since commit 89803e8b26569bdf5798f8745a4c708bf9360ee6:
ARM64: dts: meson-axg: add pdm pins (2018-07-20 08:18:37 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2-1
for you to fetch changes up to aaa080fa7e0f01f7cd8eb22a7385a4d8106c7478:
ARM64: dts: meson-gxl: add support for the Oranth Tanix TX3 Mini (2018-07-20 09:02:22 -0700)
----------------------------------------------------------------
Amlogic 64-bit DT changes for v4.19, round 2
- new SoC: S905W
- new boards: based on S905W: Amlogic P281, Oranth Tanix TX3 Mini
- AXG: add DT for new audio clock controller
----------------------------------------------------------------
Jerome Brunet (3):
dt-bindings: clock: add meson axg audio clock controller bindings
clk: meson: expose GEN_CLK clkid
ARM64: dts: meson-axg: add the audio clock controller
Kevin Hilman (1):
Merge tag 'meson-clk-dt-for-v4.19' of https://github.com/BayLibre/clk-meson into v4.19/dt64-2
Martin Blumenstingl (5):
dt-bindings: add vendor prefix for Shenzhen Oranth Technology Co., Ltd.
dt-bindings: arm: amlogic: Add support for GXL S905W and the P281 board
dt-bindings: arm: amlogic: Add support for the Oranth Tanix TX3 Mini
ARM64: dts: meson-gxl: add support for the S905W SoC and the P281 board
ARM64: dts: meson-gxl: add support for the Oranth Tanix TX3 Mini
Yixun Lan (1):
clk: meson-axg: add pcie and mipi clock bindings
Documentation/devicetree/bindings/arm/amlogic.txt | 7 ++
.../bindings/clock/amlogic,axg-audio-clkc.txt | 56 +++++++++++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm64/boot/dts/amlogic/Makefile | 2 +
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 36 +++++++++
.../boot/dts/amlogic/meson-gxl-s905w-p281.dts | 22 +++++
.../boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts | 22 +++++
include/dt-bindings/clock/axg-audio-clkc.h | 94 ++++++++++++++++++++++
include/dt-bindings/clock/axg-clkc.h | 4 +
include/dt-bindings/clock/gxbb-clkc.h | 1 +
10 files changed, 245 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905w-p281.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts
create mode 100644 include/dt-bindings/clock/axg-audio-clkc.h
^ permalink raw reply
* [PATCH] drm/nouveau/drm/nouveau: Fix runtime PM leak in nv50_disp_atomic_commit()
From: Lyude Paul @ 2018-07-23 17:06 UTC (permalink / raw)
To: gregkh; +Cc: stable, bskeggs, David Airlie, dri-devel, nouveau, linux-kernel
In-Reply-To: <153227750090101@kroah.com>
commit e5d54f1935722f83df7619f3978f774c2b802cd8 upstream
A CRTC being enabled doesn't mean it's on! It doesn't even necessarily
mean it's being used. This fixes runtime PM leaks on the P50 I've got
next to me.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
---
drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c
index 2b3ccd850750..bc5c4f2402b4 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4198,7 +4198,7 @@ nv50_disp_atomic_commit(struct drm_device *dev,
nv50_disp_atomic_commit_tail(state);
drm_for_each_crtc(crtc, dev) {
- if (crtc->state->enable) {
+ if (crtc->state->active) {
if (!drm->have_disp_power_ref) {
drm->have_disp_power_ref = true;
return 0;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] arm64, kaslr: export offset in VMCOREINFO ELF notes
From: James Morse @ 2018-07-23 17:05 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: linux-arm-kernel, Linux Kernel Mailing List, kexec mailing list,
Bhupesh SHARMA, AKASHI Takahiro, Ard Biesheuvel, Will Deacon,
Mark Rutland, Catalin Marinas, linux-mips
In-Reply-To: <CACi5LpOa-BMRSTShS019DDv7MoxNfpnnsqjwR3z13GZC49NrSA@mail.gmail.com>
Hi Bhupesh,
(CC: +mips list, looks like mips is missing vmcore's KERNELOFFSET too.
Start of this thread: https://lkml.org/lkml/2018/7/18/951 )
On 19/07/18 15:55, Bhupesh Sharma wrote:
> On Thu, Jul 19, 2018 at 5:01 PM, James Morse <james.morse@arm.com> wrote:
>> On 18/07/18 22:37, Bhupesh Sharma wrote:
>>> Include KASLR offset in VMCOREINFO ELF notes to assist in debugging.
>>>
>>> makedumpfile user-space utility will need fixup to use this KASLR offset
>>> to work with cases where we need to find a way to translate symbol
>>> address from vmlinux to kernel run time address in case of KASLR boot on
>>> arm64.
>>
>> You need the kernel VA for a symbol. Isn't this what kallsyms is for?
>> | root@frikadeller:~# cat /proc/kallsyms | grep swapper_pg_dir
>> | ffff5404610d0000 B swapper_pg_dir
> Its already used by other archs like x86_64.
> Its just that we are enabling this feature for arm64 now that the
> KASLR boot cases are more widely seen on arm64 boards (as newer EFI
> firmware implementations are available which support EFI_RNG_PROTOCOL
> and hence KASLR boot).
>
> And we want existing user-space application(s) to work similarly on
> arm64 distributions as they work historically on other archs like
> x86_64 (in most cases the user-space user is not even aware, if he is
> developing for or using an underlying hardware which is arm64 or
> x86_64)
Aha, so its ABI. This is the information that should be in the commit message as
it describes why this patch should be merged.
... Ideally core code would do this, that way this information won't be missed
when an architecture adds KASLR support.
But mips has CONFIG_RANDOMIZE_BASE, and doesn't provide kaslr_offset(),
and x86 always provides this value, not just if CONFIG_RANDOMIZE_BASE is
selected. I can't see a way to do this without touching all three architectures.
(we can try and tidy it up once its clear whether mips needs this too)
I think the patch is fine, but could you re-post it with a commit message that
describes that vmcore parsing in user-space already expects this value in the
notes. We're providing it for portability of those existing tools with x86.
>> I picked swapper_pg_dir, but you could use any of the vmcore:SYMBOL() addresses
>> to work out this offset. (you should expect the kernel to rename these symbols
>> at a whim).
>>
>
> Perhaps you missed what the above makedumpfile command was doing, so
> let me summarize again:
Yes, I glossed over it, all that seemed relevant is you are trying to find the
kernel-va of a symbol from the value in the vmlinux.
> as it breaks the
> existing user-space use-cases and the .conf file can be user-defined
> (and hence he can pick any symbol/functions
My suggestion was you can calculate the offset between the link-time and
run-time address from information you already have. You just need one of each.
This would be better as its independent of how the kernel does the relocation.
But, this is irrelevant as 'KERNELOFFSET=' is already an ABI string.
> which might not even be present in 'kallsyms').
Eh? How can that happen? I thought even modules had their symbols added to kallsyms.
Thanks,
James
^ permalink raw reply
* [PATCH] arm64, kaslr: export offset in VMCOREINFO ELF notes
From: James Morse @ 2018-07-23 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpOa-BMRSTShS019DDv7MoxNfpnnsqjwR3z13GZC49NrSA@mail.gmail.com>
Hi Bhupesh,
(CC: +mips list, looks like mips is missing vmcore's KERNELOFFSET too.
Start of this thread: https://lkml.org/lkml/2018/7/18/951 )
On 19/07/18 15:55, Bhupesh Sharma wrote:
> On Thu, Jul 19, 2018 at 5:01 PM, James Morse <james.morse@arm.com> wrote:
>> On 18/07/18 22:37, Bhupesh Sharma wrote:
>>> Include KASLR offset in VMCOREINFO ELF notes to assist in debugging.
>>>
>>> makedumpfile user-space utility will need fixup to use this KASLR offset
>>> to work with cases where we need to find a way to translate symbol
>>> address from vmlinux to kernel run time address in case of KASLR boot on
>>> arm64.
>>
>> You need the kernel VA for a symbol. Isn't this what kallsyms is for?
>> | root at frikadeller:~# cat /proc/kallsyms | grep swapper_pg_dir
>> | ffff5404610d0000 B swapper_pg_dir
> Its already used by other archs like x86_64.
> Its just that we are enabling this feature for arm64 now that the
> KASLR boot cases are more widely seen on arm64 boards (as newer EFI
> firmware implementations are available which support EFI_RNG_PROTOCOL
> and hence KASLR boot).
>
> And we want existing user-space application(s) to work similarly on
> arm64 distributions as they work historically on other archs like
> x86_64 (in most cases the user-space user is not even aware, if he is
> developing for or using an underlying hardware which is arm64 or
> x86_64)
Aha, so its ABI. This is the information that should be in the commit message as
it describes why this patch should be merged.
... Ideally core code would do this, that way this information won't be missed
when an architecture adds KASLR support.
But mips has CONFIG_RANDOMIZE_BASE, and doesn't provide kaslr_offset(),
and x86 always provides this value, not just if CONFIG_RANDOMIZE_BASE is
selected. I can't see a way to do this without touching all three architectures.
(we can try and tidy it up once its clear whether mips needs this too)
I think the patch is fine, but could you re-post it with a commit message that
describes that vmcore parsing in user-space already expects this value in the
notes. We're providing it for portability of those existing tools with x86.
>> I picked swapper_pg_dir, but you could use any of the vmcore:SYMBOL() addresses
>> to work out this offset. (you should expect the kernel to rename these symbols
>> at a whim).
>>
>
> Perhaps you missed what the above makedumpfile command was doing, so
> let me summarize again:
Yes, I glossed over it, all that seemed relevant is you are trying to find the
kernel-va of a symbol from the value in the vmlinux.
> as it breaks the
> existing user-space use-cases and the .conf file can be user-defined
> (and hence he can pick any symbol/functions
My suggestion was you can calculate the offset between the link-time and
run-time address from information you already have. You just need one of each.
This would be better as its independent of how the kernel does the relocation.
But, this is irrelevant as 'KERNELOFFSET=' is already an ABI string.
> which might not even be present in 'kallsyms').
Eh? How can that happen? I thought even modules had their symbols added to kallsyms.
Thanks,
James
^ permalink raw reply
* Re: [PATCH] arm64, kaslr: export offset in VMCOREINFO ELF notes
From: James Morse @ 2018-07-23 17:05 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Mark Rutland, linux-mips, Ard Biesheuvel, Will Deacon,
kexec mailing list, Linux Kernel Mailing List, AKASHI Takahiro,
Catalin Marinas, Bhupesh SHARMA, linux-arm-kernel
In-Reply-To: <CACi5LpOa-BMRSTShS019DDv7MoxNfpnnsqjwR3z13GZC49NrSA@mail.gmail.com>
Hi Bhupesh,
(CC: +mips list, looks like mips is missing vmcore's KERNELOFFSET too.
Start of this thread: https://lkml.org/lkml/2018/7/18/951 )
On 19/07/18 15:55, Bhupesh Sharma wrote:
> On Thu, Jul 19, 2018 at 5:01 PM, James Morse <james.morse@arm.com> wrote:
>> On 18/07/18 22:37, Bhupesh Sharma wrote:
>>> Include KASLR offset in VMCOREINFO ELF notes to assist in debugging.
>>>
>>> makedumpfile user-space utility will need fixup to use this KASLR offset
>>> to work with cases where we need to find a way to translate symbol
>>> address from vmlinux to kernel run time address in case of KASLR boot on
>>> arm64.
>>
>> You need the kernel VA for a symbol. Isn't this what kallsyms is for?
>> | root@frikadeller:~# cat /proc/kallsyms | grep swapper_pg_dir
>> | ffff5404610d0000 B swapper_pg_dir
> Its already used by other archs like x86_64.
> Its just that we are enabling this feature for arm64 now that the
> KASLR boot cases are more widely seen on arm64 boards (as newer EFI
> firmware implementations are available which support EFI_RNG_PROTOCOL
> and hence KASLR boot).
>
> And we want existing user-space application(s) to work similarly on
> arm64 distributions as they work historically on other archs like
> x86_64 (in most cases the user-space user is not even aware, if he is
> developing for or using an underlying hardware which is arm64 or
> x86_64)
Aha, so its ABI. This is the information that should be in the commit message as
it describes why this patch should be merged.
... Ideally core code would do this, that way this information won't be missed
when an architecture adds KASLR support.
But mips has CONFIG_RANDOMIZE_BASE, and doesn't provide kaslr_offset(),
and x86 always provides this value, not just if CONFIG_RANDOMIZE_BASE is
selected. I can't see a way to do this without touching all three architectures.
(we can try and tidy it up once its clear whether mips needs this too)
I think the patch is fine, but could you re-post it with a commit message that
describes that vmcore parsing in user-space already expects this value in the
notes. We're providing it for portability of those existing tools with x86.
>> I picked swapper_pg_dir, but you could use any of the vmcore:SYMBOL() addresses
>> to work out this offset. (you should expect the kernel to rename these symbols
>> at a whim).
>>
>
> Perhaps you missed what the above makedumpfile command was doing, so
> let me summarize again:
Yes, I glossed over it, all that seemed relevant is you are trying to find the
kernel-va of a symbol from the value in the vmlinux.
> as it breaks the
> existing user-space use-cases and the .conf file can be user-defined
> (and hence he can pick any symbol/functions
My suggestion was you can calculate the offset between the link-time and
run-time address from information you already have. You just need one of each.
This would be better as its independent of how the kernel does the relocation.
But, this is irrelevant as 'KERNELOFFSET=' is already an ABI string.
> which might not even be present in 'kallsyms').
Eh? How can that happen? I thought even modules had their symbols added to kallsyms.
Thanks,
James
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 40/40] target/mips: Add definition of nanoMIPS I7200 CPU
From: Richard Henderson @ 2018-07-23 17:05 UTC (permalink / raw)
To: Stefan Markovic, qemu-devel
Cc: laurent, riku.voipio, philippe.mathieu.daude, aurelien, amarkovic,
smarkovic, pjovanovic, pburton
In-Reply-To: <1532004912-13899-41-git-send-email-stefan.markovic@rt-rk.com>
On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> + .insn_flags = CPU_NANOMIPS32 | ASE_MICROMIPS | ASE_DSP | ASE_DSPR2 |
> + ASE_MT,
See my comments for 27/40.
r~
^ permalink raw reply
* ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/icp: Add Interrupt Support
From: Patchwork @ 2018-07-23 17:05 UTC (permalink / raw)
To: Srivatsa, Anusha; +Cc: intel-gfx
In-Reply-To: <1529530565-8985-1-git-send-email-anusha.srivatsa@intel.com>
== Series Details ==
Series: series starting with [1/2] drm/i915/icp: Add Interrupt Support
URL : https://patchwork.freedesktop.org/series/45124/
State : failure
== Summary ==
Applying: drm/i915/icp: Add Interrupt Support
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/i915_irq.c
M drivers/gpu/drm/i915/i915_reg.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_reg.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_reg.h
Auto-merging drivers/gpu/drm/i915/i915_irq.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_irq.c
error: Failed to merge in the changes.
Patch failed at 0001 drm/i915/icp: Add Interrupt Support
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9375/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] drm/amdgpu: Don't warn on destroying a pinned BO
From: Alex Deucher @ 2018-07-23 17:05 UTC (permalink / raw)
To: Michel Dänzer; +Cc: amd-gfx list
In-Reply-To: <b39b0ced-3a54-b18c-0e90-e829b21afd17-otUistvHUpPR7s880joybQ@public.gmane.org>
On Mon, Jul 23, 2018 at 12:50 PM, Michel Dänzer <michel@daenzer.net> wrote:
> On 2018-07-19 05:39 PM, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daenzer@amd.com>
>>
>> The warning turned out to be not so useful, as BO destruction tends to
>> be deferred to a workqueue.
>>
>> Also, we should be preventing any damage from this now, so not really
>> important anymore to fix code doing this.
>>
>> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index b12526ce1a9d..3010f0136de9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -89,7 +89,7 @@ static void amdgpu_ttm_bo_destroy(struct ttm_buffer_object *tbo)
>> struct amdgpu_device *adev = amdgpu_ttm_adev(tbo->bdev);
>> struct amdgpu_bo *bo = ttm_to_amdgpu_bo(tbo);
>>
>> - if (WARN_ON_ONCE(bo->pin_count > 0))
>> + if (bo->pin_count > 0)
>> amdgpu_bo_subtract_pin_size(bo);
>>
>> if (bo->kfd_bo)
>>
>
> Any feedback?
Acked-by: Alex Deucher <alexander.deucher@amd.com>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ 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.