Re: [PATCH v10 03/27] timer: Export next wakeup time of a CPU
On Fri, 11 Jan 2019 at 12:07, Rafael J. Wysocki wrote:
>
> On Thursday, November 29, 2018 6:46:36 PM CET Ulf Hansson wrote:
> > From: Lina Iyer
> >
> > Knowing the sleep duration of CPUs, is known to be needed while selecting
> > the most energy efficient idle state for a CPU or a group of CPUs.
> >
> > However, to be able to compute the sleep duration, we need to know at what
> > time the next expected wakeup is for the CPU. Therefore, let's export this
> > information via a new function, tick_nohz_get_next_wakeup(). Following
> > changes make use of it.
> >
> > Cc: Thomas Gleixner
> > Cc: Daniel Lezcano
> > Cc: Lina Iyer
> > Cc: Frederic Weisbecker
> > Cc: Ingo Molnar
> > Signed-off-by: Lina Iyer
> > Co-developed-by: Ulf Hansson
> > Signed-off-by: Ulf Hansson
> > ---
> >
> > Changes in v10:
> > - Updated function header of tick_nohz_get_next_wakeup().
> >
> > ---
> > include/linux/tick.h | 8
> > kernel/time/tick-sched.c | 13 +
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/include/linux/tick.h b/include/linux/tick.h
> > index 55388ab45fd4..e48f6b26b425 100644
> > --- a/include/linux/tick.h
> > +++ b/include/linux/tick.h
> > @@ -125,6 +125,7 @@ extern bool tick_nohz_idle_got_tick(void);
> > extern ktime_t tick_nohz_get_sleep_length(ktime_t *delta_next);
> > extern unsigned long tick_nohz_get_idle_calls(void);
> > extern unsigned long tick_nohz_get_idle_calls_cpu(int cpu);
> > +extern ktime_t tick_nohz_get_next_wakeup(int cpu);
> > extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
> > extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
> >
> > @@ -151,6 +152,13 @@ static inline ktime_t
> > tick_nohz_get_sleep_length(ktime_t *delta_next)
> > *delta_next = TICK_NSEC;
> > return *delta_next;
> > }
> > +
> > +static inline ktime_t tick_nohz_get_next_wakeup(int cpu)
> > +{
> > + /* Next wake up is the tick period, assume it starts now */
> > + return ktime_add(ktime_get(), TICK_NSEC);
> > +}
> > +
> > static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) { return -1; }
> > static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return
> > -1; }
> >
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index 69e673b88474..7a9166506503 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -1089,6 +1089,19 @@ unsigned long tick_nohz_get_idle_calls(void)
> > return ts->idle_calls;
> > }
> >
> > +/**
> > + * tick_nohz_get_next_wakeup - return the next wake up of the CPU
> > + * @cpu: the particular CPU to get next wake up for
> > + *
> > + * Called for idle CPUs only.
> > + */
> > +ktime_t tick_nohz_get_next_wakeup(int cpu)
> > +{
> > + struct clock_event_device *dev = per_cpu(tick_cpu_device.evtdev, cpu);
> > +
> > + return dev->next_event;
> > +}
> > +
> > static void tick_nohz_account_idle_ticks(struct tick_sched *ts)
> > {
> > #ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
> >
>
> Well, I have concerns regarding this one.
>
> I don't believe it is valid to call this new function for non-idle CPUs and
> the kerneldoc kind of says so, but the next patch doesn't actually prevent
> it from being called for a non-idle CPU (at the time it is called in there
> the target CPU may not be idle any more AFAICS).
You are correct, but let me clarify things.
We are calling this new API from the new genpd governor, which may
have a cpumask indicating there is more than one CPU attached to its
PM domain+sub-PM domains. In other words, we may call the API for
another CPU than the one we are executing on.
When the new genpd governor is called, all CPUs in the cpumask of the
genpd in question, are already runtime suspended and will remain so
throughout the decisions made by the governor.
However, because of the race condition, which needs to be manged by
the genpd backend driver and its corresponding FW, one of the CPU in
the genpd cpumask could potentially wake up from idle when the genpd
governor runs. However, as a part of exiting from idle, that CPU needs
to wait for the call to pm_runtime_get_sync() to return before
completing the exit patch of idle. This also means waiting for the
genpd governor to finish.
The point is, no matter what decision the governor takes under these
circumstances, the genpd backend driver and its FW must manage this
race condition during the last man standing. For PSCI OSI mode, it
means that if a cluster idle state is suggested by Linux during these
circumstances, it must be prevented and aborted.
>
> In principle, the cpuidle core can store this value, say in struct
> cpuidle_device of the given CPU, and expose a helper to access it from
> genpd, but that would be extra overhead totally unnecessary on everthing
> that doesn't use genpd for cpuidle.
>
> So maybe the driver could store it in its ->enter callback? After all,
> the driver knows that genpd is going to be used later.
This would work, but
[PATCH] pwm: Add MediaTek MT8183 display PWM driver support
Use the mtk_pwm_data struction to define different registers
and add MT8183 specific register operations, such as MT8183
have commit register, needs to enable double buffer
before writing register, and needs to select commit mode
and use PWM_PERIOD/PWM_HIGH_WIDTH.
Signed-off-by: Jitao Shi
---
drivers/pwm/pwm-mtk-disp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 893940d45f0d..15803c71fe80 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -277,10 +277,21 @@ static const struct mtk_pwm_data mt8173_pwm_data = {
.commit_mask = 0x1,
};
+static const struct mtk_pwm_data mt8183_pwm_data = {
+ .enable_mask = BIT(0),
+ .con0 = 0x18,
+ .con0_sel = 0x0,
+ .con1 = 0x1c,
+ .has_commit = false,
+ .bls_debug = 0x80,
+ .bls_debug_mask = 0x3,
+};
+
static const struct of_device_id mtk_disp_pwm_of_match[] = {
{ .compatible = "mediatek,mt2701-disp-pwm", .data = _pwm_data},
{ .compatible = "mediatek,mt6595-disp-pwm", .data = _pwm_data},
{ .compatible = "mediatek,mt8173-disp-pwm", .data = _pwm_data},
+ { .compatible = "mediatek,mt8183-disp-pwm", .data = _pwm_data},
{ }
};
MODULE_DEVICE_TABLE(of, mtk_disp_pwm_of_match);
--
2.12.5
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Tue, Jan 15, 2019 at 10:34 PM Dominique Martinet wrote: > > There is a difference with your previous patch though, that used to list no > page in core when it didn't know; this patch lists pages as in core when it > refuses to tell. I don't think that's very important, though. Is there a reason not to return -EPERM in this case? > > If anything, the 0400 user-owner file might be a problem in some edge > case (e.g. if you're preloading git directories, many objects are 0444); > should we *also* check ownership?... Yes, this seems valuable. Some databases with immutable files (e.g. git, as you've mentioned) conceivably operate this way. Josh
Re: [PATCH] arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region
On Wed, 16 Jan 2019 at 04:37, Yueyi Li wrote:
>
> OK, thanks. But seems this mail be ignored, do i need re-sent the patch?
>
> On 2018/12/26 21:49, Ard Biesheuvel wrote:
> > On Tue, 25 Dec 2018 at 03:30, Yueyi Li wrote:
> >> Hi Ard,
> >>
> >>
> >> On 2018/12/24 17:45, Ard Biesheuvel wrote:
> >>> Does the following change fix your issue as well?
> >>>
> >>> index 9b432d9fcada..9dcf0ff75a11 100644
> >>> --- a/arch/arm64/mm/init.c
> >>> +++ b/arch/arm64/mm/init.c
> >>> @@ -447,7 +447,7 @@ void __init arm64_memblock_init(void)
> >>>* memory spans, randomize the linear region as well.
> >>>*/
> >>> if (memstart_offset_seed > 0 && range >=
> >>> ARM64_MEMSTART_ALIGN) {
> >>> - range = range / ARM64_MEMSTART_ALIGN + 1;
> >>> + range /= ARM64_MEMSTART_ALIGN;
> >>> memstart_addr -= ARM64_MEMSTART_ALIGN *
> >>>((range *
> >>> memstart_offset_seed) >> 16);
> >>> }
> >> Yes, it can fix this also. I just think modify the first *range*
> >> calculation would be easier to grasp, what do you think?
> >>
> > I don't think there is a difference, to be honest, but I will leave it
> > up to the maintainers to decide which approach they prefer.
>
No it has been merged already. It is in v5.0-rc2 I think.
Re: [PATCH v3] xen: Fix x86 sched_clock() interface for xen
On 16/01/2019 01:24, Hans van Kranenburg wrote:
> Hi,
>
> On 1/14/19 1:44 PM, Juergen Gross wrote:
>> Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable'
>> sched_clock() interface") broke Xen guest time handling across
>> migration:
>>
>> [ 187.249951] Freezing user space processes ... (elapsed 0.001 seconds)
>> done.
>> [ 187.251137] OOM killer disabled.
>> [ 187.251137] Freezing remaining freezable tasks ... (elapsed 0.001
>> seconds) done.
>> [ 187.252299] suspending xenstore...
>> [ 187.266987] xen:grant_table: Grant tables using version 1 layout
>> [18446743811.706476] OOM killer enabled.
>> [18446743811.706478] Restarting tasks ... done.
>> [18446743811.720505] Setting capacity to 16777216
>>
>> Fix that by setting xen_sched_clock_offset at resume time to ensure a
>> monotonic clock value.
>>
>> [...]
>
> With v3 of the patch, I see the time jump in one log line happen, but
> only when using PVH.
>
> [ 49.486453] Freezing user space processes ... (elapsed 0.002 seconds)
> done.
> [ 49.488743] OOM killer disabled.
> [ 49.488764] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds) done.
> [ 49.491117] suspending xenstore...
> [2000731.388722] xen:events: Xen HVM callback vector for event delivery
> is enabled
> [ 49.491750] xen:grant_table: Grant tables using version 1 layout
> [ 49.810722] OOM killer enabled.
> [ 49.810744] Restarting tasks ... done.
> [ 49.856263] Setting capacity to 6291456
> [ 50.006002] Setting capacity to 10485760
>
> If I start as PV, it never seems to happen.
>
> Up to you to decide how important this is. :)
We could do something like below. Boris?
Juergen
---
diff --git a/arch/x86/xen/suspend_hvm.c b/arch/x86/xen/suspend_hvm.c
index e666b614cf6d..088f3a6b4be9 100644
--- a/arch/x86/xen/suspend_hvm.c
+++ b/arch/x86/xen/suspend_hvm.c
@@ -13,6 +13,6 @@ void xen_hvm_post_suspend(int suspend_cancelled)
xen_hvm_init_shared_info();
xen_vcpu_restore();
}
- xen_callback_vector();
+ xen_callback_vector(true);
xen_unplug_emulated_devices();
}
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 0e60bd918695..ba293fda3265 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -55,7 +55,7 @@ void xen_enable_sysenter(void);
void xen_enable_syscall(void);
void xen_vcpu_restore(void);
-void xen_callback_vector(void);
+void xen_callback_vector(bool silent);
void xen_hvm_init_shared_info(void);
void xen_unplug_emulated_devices(void);
diff --git a/drivers/xen/events/events_base.c
b/drivers/xen/events/events_base.c
index 93194f3e7540..8d8d50bea215 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1637,7 +1637,7 @@ EXPORT_SYMBOL_GPL(xen_set_callback_via);
/* Vector callbacks are better than PCI interrupts to receive event
* channel notifications because we can receive vector callbacks on any
* vcpu and we don't need PCI support or APIC interactions. */
-void xen_callback_vector(void)
+void xen_callback_vector(bool silent)
{
int rc;
uint64_t callback_via;
@@ -1650,13 +1650,14 @@ void xen_callback_vector(void)
xen_have_vector_callback = 0;
return;
}
- pr_info("Xen HVM callback vector for event delivery is
enabled\n");
+ if (!silent)
+ pr_info("Xen HVM callback vector for event
delivery is enabled\n");
alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
xen_hvm_callback_vector);
}
}
#else
-void xen_callback_vector(void) {}
+void xen_callback_vector(bool silent) {}
#endif
#undef MODULE_PARAM_PREFIX
@@ -1692,7 +1693,7 @@ void __init xen_init_IRQ(void)
pci_xen_initial_domain();
}
if (xen_feature(XENFEAT_hvm_callback_vector))
- xen_callback_vector();
+ xen_callback_vector(false);
if (xen_hvm_domain()) {
native_init_IRQ();
Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM
On Wed, 16 Jan 2019 at 08:36, Koenig, Christian wrote: > > Am 16.01.19 um 01:33 schrieb Benjamin Herrenschmidt: > > On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote: > As far as I know Power doesn't really supports un-cached memory at all, > except for a very very old and odd configuration with AGP. > >>> Hopefully Michael/Ben can elaborate here, but I was under the (possibly > >>> mistaken) impression that mismatched attributes could cause a > >>> machine-check > >>> on Power. > >> That's what I've always been told, but I can't actually find where it's > >> documented, I'll keep searching. > >> > >> But you're right that mixing cached / uncached is not really supported, > >> and probably results in a machine check or worse. > > .. or worse :) It could checkstop. > > Not sure if that would be so bad, it would at least give us a clear > indicator that something is wrong instead of silently corrupting data. > > > It's also my understanding that on ARM v7 and above, it's technically > > forbidden to map the same physical page with both cached and non-cached > > mappings, since the cached one could prefetch (or speculatively load), > > thus creating collisions and inconsistencies. Am I wrong here ? > > No, but you answer the wrong question. > > See we don't want to have different mappings of cached and non-cached on > the CPU, but rather want to know if a snooped DMA from the PCIe counts > as cached access as well. > > As far as I know on x86 it doesn't, so when you have an un-cached page > you can still access it with a snooping DMA read/write operation and > don't cause trouble. > I think it is the other way around. The question is, on an otherwise cache coherent device, whether the NoSnoop attribute set by the GPU propagates all the way to the bus so that it bypasses the caches. On x86, we can tolerate if this is not the case, since uncached memory accesses by the CPU snoop the caches as well. On other architectures, uncached accesses go straight to main memory, so if the device wrote anything to the caches we won't see it. So to use this optimization, you have to either be 100% sure that NoSnoop is implemented correctly, or have a x86 CPU. > > The old hack of using non-cached mapping to avoid snoop cost in AGP and > > others is just that ... an ugly and horrible hacks that should have > > never eventuated, when the search for performance pushes HW people into > > utter insanity :) > > Well I agree that un-cached system memory makes things much more > complicated for a questionable gain. > > But fact is we now have to deal with the mess, so no point in > complaining about it to much :) > Indeed. I wonder if we should just disable it altogether unless CONFIG_X86=y
Re: [PATCH v2] drm/i915: Pass down rc in intel_encoder->compute_config()
On Tue, 15 Jan 2019, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the potential to hit a normal modeset
> deadlock. However, because ->compute_config() only returns a bool this
> means we can't return -EDEADLK when we need to drop locks and try again
> which means we end up just failing the atomic check permanently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Changes since v1:
> * Add some newlines
> * Return only -EINVAL from hsw_crt_compute_config()
> * Propogate return code from intel_dp_compute_dsc_params()
> * Change all of the intel_dp_compute_link_config*() variants
> * Don't miss if (hdmi_port_clock_valid()) branch in
> intel_hdmi_compute_config()
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 8 ++--
> drivers/gpu/drm/i915/intel_crt.c | 35 +++---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +--
> drivers/gpu/drm/i915/intel_display.c | 11 +++--
> drivers/gpu/drm/i915/intel_dp.c | 71 +++-
> drivers/gpu/drm/i915/intel_dp_mst.c | 12 ++---
> drivers/gpu/drm/i915/intel_drv.h | 18 +++
> drivers/gpu/drm/i915/intel_dvo.c | 11 +++--
> drivers/gpu/drm/i915/intel_hdmi.c| 14 +++---
> drivers/gpu/drm/i915/intel_lvds.c| 12 ++---
> drivers/gpu/drm/i915/intel_sdvo.c| 14 +++---
> drivers/gpu/drm/i915/intel_tv.c | 8 ++--
> drivers/gpu/drm/i915/vlv_dsi.c | 14 +++---
> 13 files changed, 122 insertions(+), 112 deletions(-)
Despite being an all i915 patch, this got applied to drm-misc-next,
causing conflicts where there really should have been none. :(
I am tempted to suggest reverting and re-applying to drm-intel, because
it will take weeks to sync both to drm-next and backmerge, and applying
further work on top in drm-intel will just cause more trouble.
Other ideas?
BR,
Jani.
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index f3a5f03646ce..355b48d1c937 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> }
>
> -static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int gen11_dsi_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> base);
> @@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct
> intel_encoder *encoder,
> pipe_config->clock_set = true;
> pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
>
> - return true;
> + return 0;
> }
>
> static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 33bd2addcbdd..081c333f30d2 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -345,51 +345,52 @@ intel_crt_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static bool intel_crt_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int intel_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> _config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> - return true;
> +
> + return 0;
> }
>
> -static bool pch_crt_compute_config(struct intel_encoder *encoder,
> -struct intel_crtc_state *pipe_config,
> -struct drm_connector_state *conn_state)
>
Re: linux-next: manual merge of the block tree with the fscrypt tree
On Tue, Jan 15, 2019 at 08:17:36PM -0700, Jens Axboe wrote:
> On 1/15/19 8:13 PM, Ming Lei wrote:
> > On Tue, Jan 15, 2019 at 07:55:39PM -0700, Jens Axboe wrote:
> >> On 1/15/19 7:25 PM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Today's linux-next merge of the block tree got a conflict in:
> >>>
> >>> fs/ext4/readpage.c
> >>>
> >>> between commit:
> >>>
> >>> acc9eb0a6073 ("ext4: add fs-verity read support")
> >>>
> >>> from the fscrypt tree and commit:
> >>>
> >>> eb754eb2a953 ("block: allow bio_for_each_segment_all() to iterate over
> >>> multi-page bvec")
> >>>
> >>> from the block tree.
> >>>
> >>> I fixed it up (see below - the former moved the code modified by the
> >>> latter) and can carry the fix as necessary. This is now fixed as far as
> >>> linux-next is concerned, but any non trivial conflicts should be mentioned
> >>> to your upstream maintainer when your tree is submitted for merging.
> >>> You may also want to consider cooperating with the maintainer of the
> >>> conflicting tree to minimise any particularly complex conflicts.
> >>
> >> Ming, I'm pulling this, I thought we agreed none of these bullshit
> >> renames? The fact that a patch looks like this:
> >>
> >> - for_each_bvec(bv, (it)->bvecs, __cur_iter, __cur_iter)
> >>\
> >> + for_each_segment(bv, (it)->bvecs, __cur_iter, __cur_iter)
> >>\
> >>
> >> is SUPER annoying and does NOTHING but to cause merge conflicts.
> >>
> >> Resend it without that.
> >
> > We need to differentiate 'segment' with 'bvec' in bvec helpers, which is
> > usually seldom used by drivers. For example, only two in-tree users(ceph,
> > iov_iter).
> > That is why I rename it, and seems Christoph prefers to do it too.
>
> If you want to do a rename, then we do it after. I don't want to deal with
> weeks and weeks of fallout from this. Write a rename script that we can
> then run at the end of the next merge window. You're going to be playing
> catch-up until that happens if we go the current route, and honestly
> I'm not at all interested in the fallout from that.
>
> I know exactly what will happen until 5.1-rc opens, and what my tree will
> look like from having to deal with this. And then I know exactly what Linus
> is going to say, and I can't even argue against it, since he'll be totally
> right.
>
> Hence it's not going to happen this way.
I can remove the renaming in patch 'block: rename bvec helpers', but
change on bio_for_each_segment_all() is inevitable, and it is still an
API change, so merge conflict can't avoid too.
Thanks,
Ming
Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM
Am 16.01.19 um 01:33 schrieb Benjamin Herrenschmidt: > On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote: As far as I know Power doesn't really supports un-cached memory at all, except for a very very old and odd configuration with AGP. >>> Hopefully Michael/Ben can elaborate here, but I was under the (possibly >>> mistaken) impression that mismatched attributes could cause a machine-check >>> on Power. >> That's what I've always been told, but I can't actually find where it's >> documented, I'll keep searching. >> >> But you're right that mixing cached / uncached is not really supported, >> and probably results in a machine check or worse. > .. or worse :) It could checkstop. Not sure if that would be so bad, it would at least give us a clear indicator that something is wrong instead of silently corrupting data. > It's also my understanding that on ARM v7 and above, it's technically > forbidden to map the same physical page with both cached and non-cached > mappings, since the cached one could prefetch (or speculatively load), > thus creating collisions and inconsistencies. Am I wrong here ? No, but you answer the wrong question. See we don't want to have different mappings of cached and non-cached on the CPU, but rather want to know if a snooped DMA from the PCIe counts as cached access as well. As far as I know on x86 it doesn't, so when you have an un-cached page you can still access it with a snooping DMA read/write operation and don't cause trouble. > The old hack of using non-cached mapping to avoid snoop cost in AGP and > others is just that ... an ugly and horrible hacks that should have > never eventuated, when the search for performance pushes HW people into > utter insanity :) Well I agree that un-cached system memory makes things much more complicated for a questionable gain. But fact is we now have to deal with the mess, so no point in complaining about it to much :) Cheers, Christian. > > Cheers, > Ben. > > >
Re: [PATCH v15 5/6] x86/boot: Parse SRAT address from RSDP and store immovable memory
On Mon, Jan 7, 2019 at 11:24 AM Chao Fan wrote:
>
> +
> +/* Determine RSDP, based on acpi_os_get_root_pointer(). */
> +static acpi_physical_address get_rsdp_addr(void)
> +{
> + acpi_physical_address pa;
> +
> + pa = get_acpi_rsdp();
> +
> + if (!pa)
> + pa = efi_get_rsdp_addr();
> +
> + if (!pa)
> + pa = bios_get_rsdp_addr();
> +
> + return pa;
> +}
acpi_rsdp might be provided by boot_params.acpi_rsdp_addr too,
it's introduced in ae7e1238e68f2a for Xen PVH guest and later move to
boot_params in e6e094e053af,
kexec could use it to pass RSDP to second kernel as well. Please check
it as well make sure it always works.
> +
> +/* Compute SRAT address from RSDP. */
> +static struct acpi_table_header *get_acpi_srat_table(void)
> +{
> + acpi_physical_address acpi_table;
> + acpi_physical_address root_table;
> + struct acpi_table_header *header;
> + struct acpi_table_rsdp *rsdp;
> + u32 num_entries;
> + char arg[10];
> + u8 *entry;
> + u32 size;
> + u32 len;
> +
> + rsdp = (struct acpi_table_rsdp *)(long)get_rsdp_addr();
> + if (!rsdp)
> + return NULL;
> +
> + /* Get RSDT or XSDT from RSDP. */
> + if (!(cmdline_find_option("acpi", arg, sizeof(arg)) == 4 &&
> + !strncmp(arg, "rsdt", 4)) &&
> + rsdp->xsdt_physical_address &&
> + rsdp->revision > 1) {
> + root_table = rsdp->xsdt_physical_address;
> + size = ACPI_XSDT_ENTRY_SIZE;
> + } else {
> + root_table = rsdp->rsdt_physical_address;
> + size = ACPI_RSDT_ENTRY_SIZE;
> + }
> +
> + /* Get ACPI root table from RSDT or XSDT.*/
> + if (!root_table)
> + return NULL;
> + header = (struct acpi_table_header *)(long)root_table;
> +
> + len = header->length;
> + if (len < sizeof(struct acpi_table_header) + size)
> + return NULL;
> +
> + num_entries = (u32)((len - sizeof(struct acpi_table_header)) / size);
> + entry = ACPI_ADD_PTR(u8, header, sizeof(struct acpi_table_header));
> +
> + while (num_entries--) {
> + u64 address64;
> +
> + if (size == ACPI_RSDT_ENTRY_SIZE)
> + acpi_table = *ACPI_CAST_PTR(u32, entry);
> + else {
> + address64 = *(u64 *)entry;
> + acpi_table = address64;
> + }
> +
> + if (acpi_table) {
> + header = (struct acpi_table_header *)(long)acpi_table;
> +
> + if (ACPI_COMPARE_NAME(header->signature,
> ACPI_SIG_SRAT))
> + return header;
> + }
> + entry += size;
> + }
> + return NULL;
> +}
> +
> +/*
> + * According to ACPI table, filter the immovable memory regions
> + * and store them in immovable_mem[].
> + */
> +void get_immovable_mem(void)
> +{
> + struct acpi_table_header *table_header;
> + struct acpi_subtable_header *table;
> + struct acpi_srat_mem_affinity *ma;
> + char arg[MAX_ACPI_ARG_LENGTH];
> + unsigned long table_end;
> + int i = 0;
> +
> + if (cmdline_find_option("acpi", arg, sizeof(arg)) == 3 &&
> + !strncmp(arg, "off", 3))
> + return;
> +
> + table_header = get_acpi_srat_table();
> + if (!table_header)
> + return;
> +
> + table_end = (unsigned long)table_header + table_header->length;
> + table = (struct acpi_subtable_header *)
> + ((unsigned long)table_header + sizeof(struct
> acpi_table_srat));
> +
> + while (((unsigned long)table) +
> + sizeof(struct acpi_subtable_header) < table_end) {
> + if (table->type == ACPI_SRAT_TYPE_MEMORY_AFFINITY) {
> + ma = (struct acpi_srat_mem_affinity *)table;
> + if (!(ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE)) {
> + immovable_mem[i].start = ma->base_address;
> + immovable_mem[i].size = ma->length;
> + i++;
> + }
> +
> + if (i >= MAX_NUMNODES*2) {
> + debug_putstr("Too many immovable memory
> regions, aborting.\n");
> + return;
> + }
> + }
> + table = (struct acpi_subtable_header *)
> + ((unsigned long)table + table->length);
> + }
> + num_immovable_mem = i;
> +}
> diff --git a/arch/x86/boot/compressed/kaslr.c
> b/arch/x86/boot/compressed/kaslr.c
> index 9ed9709d9947..b251572e77af 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -87,10 +87,6 @@ static unsigned long get_boot_seed(void)
> #define KASLR_COMPRESSED_BOOT
>
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
Am 16.01.19 um 08:09 schrieb Thomas Hellstrom: > On Tue, 2019-01-15 at 21:58 +0100, h...@lst.de wrote: >> On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote: >>> Thomas is correct that the interface you propose here doesn't work >>> at >>> all for GPUs. >>> >>> The kernel driver is not informed of flush/sync, but rather just >>> setups >>> coherent mappings between system memory and devices. >>> >>> In other words you have an array of struct pages and need to map >>> that to >>> a specific device and so create dma_addresses for the mappings. >> If you want a coherent mapping you need to use dma_alloc_coherent >> and dma_mmap_coherent and you are done, that is not the problem. >> That actually is one of the vmgfx modes, so I don't understand what >> problem we are trying to solve if you don't actually want a non- >> coherent mapping. > For vmwgfx, not making dma_alloc_coherent default has a couple of > reasons: > 1) Memory is associated with a struct device. It has not been clear > that it is exportable to other devices. > 2) There seems to be restrictions in the system pages allowable. GPUs > generally prefer highmem pages but dma_alloc_coherent returns a virtual > address implying GFP_KERNEL? While not used by vmwgfx, TTM typically > prefers HIGHMEM pages to facilitate caching mode switching without > having to touch the kernel map. > 3) Historically we had APIs to allow coherent access to user-space > defined pages. That has gone away not but the infrastructure was built > around it. > > dma_mmap_coherent isn't use because as the data moves between system > memory, swap and VRAM, PTEs of user-space mappings are adjusted > accordingly, meaning user-space doesn't have to unmap when an operation > is initiated that might mean the data is moved. To summarize once more: We have an array of struct pages and want to coherently map that to a device. If that is not possible because of whatever reason we want to get an error code or even not load the driver from the beginning. > > >> Although last time I had that discussion with Daniel Vetter >> I was under the impressions that GPUs really wanted non-coherent >> mappings. > Intel historically has done things a bit differently. And it's also > possible that embedded platforms and ARM prefer this mode of operation, > but I haven't caught up on that discussion. > >> But if you want a coherent mapping you can't go to a struct page, >> because on many systems you can't just map arbitrary memory as >> uncachable. It might either come from very special limited pools, >> or might need other magic applied to it so that it is not visible >> in the normal direct mapping, or at least not access through it. > > The TTM subsystem has been relied on to provide coherent memory with > the option to switch caching mode of pages. But only on selected and > well tested platforms. On other platforms we simply do not load, and > that's fine for now. > > But as mentioned multiple times, to make GPU drivers more compliant, > we'd really want that > > bool dma_streaming_is_coherent(const struct device *) > > API to help us decide when to load or not. Yes, please. Christian. > > Thanks, > Thomas > > > > > > >
Re: [PATCH] staging: comedi: Removed not necessary braces for single block
"interesting" email name you used here :) Please fix up, it has to match the signed-off-by line. I fixed and resent the patch again. --- Jitendra
[PATCH v3] arm64: dts: qcom: sdm845: Expand soc bus address range
DMA addresses for devices on the soc bus must be constrained to the 36
address bits that the bus provides. When no IOMMU is present then this
is easy--DMA addresses are just physical addresses and physical
addresses are (by definition) within the address bits of the bus. When
an IOMMU is present, however, DMA addresses are virtual addresses.
Despite these addresses being virtual, however, they are still
constrained by the 36 address bits of the bus.
Unless dma-ranges is specified, which causes bus_dma_mask to be set, DMA
allocations for devices on the platform_bus will use all 48 address bits
available by the ARM SMMU. Causing addresses to be truncated on the bus.
This patch increases the #size-cells to 2, in order to be able to define
dma-ranges describe the 36 bit DMA capability of the bus, and bumps
While touching all reg properties, addresses are padded to 8 digits.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Actually include the changes from the rebase
Changes since v1:
- Update commit message per discussion with Doug
- Updated "ranges"
- Rebased ontop of a few additional patches from the mailing list
arch/arm64/boot/dts/qcom/sdm845.dtsi | 299 ++-
1 file changed, 150 insertions(+), 149 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c98b1937353b..fc01b1c93fe4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -346,14 +346,15 @@
};
soc: soc {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0 0 0x>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0 0 0 0 0x10 0>;
+ dma-ranges = <0 0 0 0 0x10 0>;
compatible = "simple-bus";
gcc: clock-controller@10 {
compatible = "qcom,gcc-sdm845";
- reg = <0x10 0x1f>;
+ reg = <0 0x0010 0 0x1f>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
@@ -361,7 +362,7 @@
qfprom@784000 {
compatible = "qcom,qfprom";
- reg = <0x784000 0x8ff>;
+ reg = <0 0x00784000 0 0x8ff>;
#address-cells = <1>;
#size-cells = <1>;
@@ -378,25 +379,25 @@
rng: rng@793000 {
compatible = "qcom,prng-ee";
- reg = <0x00793000 0x1000>;
+ reg = <0 0x00793000 0 0x1000>;
clocks = < GCC_PRNG_AHB_CLK>;
clock-names = "core";
};
qupv3_id_0: geniqup@8c {
compatible = "qcom,geni-se-qup";
- reg = <0x8c 0x6000>;
+ reg = <0 0x008c 0 0x6000>;
clock-names = "m-ahb", "s-ahb";
clocks = < GCC_QUPV3_WRAP_0_M_AHB_CLK>,
< GCC_QUPV3_WRAP_0_S_AHB_CLK>;
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;
ranges;
status = "disabled";
i2c0: i2c@88 {
compatible = "qcom,geni-i2c";
- reg = <0x88 0x4000>;
+ reg = <0 0x0088 0 0x4000>;
clock-names = "se";
clocks = < GCC_QUPV3_WRAP0_S0_CLK>;
pinctrl-names = "default";
@@ -409,7 +410,7 @@
spi0: spi@88 {
compatible = "qcom,geni-spi";
- reg = <0x88 0x4000>;
+ reg = <0 0x0088 0 0x4000>;
clock-names = "se";
clocks = < GCC_QUPV3_WRAP0_S0_CLK>;
pinctrl-names = "default";
@@ -422,7 +423,7 @@
uart0: serial@88 {
compatible = "qcom,geni-uart";
- reg = <0x88 0x4000>;
+ reg = <0 0x0088 0 0x4000>;
clock-names = "se";
clocks = < GCC_QUPV3_WRAP0_S0_CLK>;
pinctrl-names = "default";
@@ -433,7 +434,7 @@
i2c1: i2c@884000 {
compatible = "qcom,geni-i2c";
- reg = <0x884000 0x4000>;
+ reg = <0 0x00884000
Re: [PATCH net-next] mlxsw: spectrum_nve: Use struct_size() in kzalloc()
On Tue, Jan 15, 2019 at 05:14:29PM -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo),
> GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Ido Schimmel
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Tue, 2019-01-15 at 21:58 +0100, h...@lst.de wrote: > On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote: > > Thomas is correct that the interface you propose here doesn't work > > at > > all for GPUs. > > > > The kernel driver is not informed of flush/sync, but rather just > > setups > > coherent mappings between system memory and devices. > > > > In other words you have an array of struct pages and need to map > > that to > > a specific device and so create dma_addresses for the mappings. > > If you want a coherent mapping you need to use dma_alloc_coherent > and dma_mmap_coherent and you are done, that is not the problem. > That actually is one of the vmgfx modes, so I don't understand what > problem we are trying to solve if you don't actually want a non- > coherent mapping. For vmwgfx, not making dma_alloc_coherent default has a couple of reasons: 1) Memory is associated with a struct device. It has not been clear that it is exportable to other devices. 2) There seems to be restrictions in the system pages allowable. GPUs generally prefer highmem pages but dma_alloc_coherent returns a virtual address implying GFP_KERNEL? While not used by vmwgfx, TTM typically prefers HIGHMEM pages to facilitate caching mode switching without having to touch the kernel map. 3) Historically we had APIs to allow coherent access to user-space defined pages. That has gone away not but the infrastructure was built around it. dma_mmap_coherent isn't use because as the data moves between system memory, swap and VRAM, PTEs of user-space mappings are adjusted accordingly, meaning user-space doesn't have to unmap when an operation is initiated that might mean the data is moved. > Although last time I had that discussion with Daniel Vetter > I was under the impressions that GPUs really wanted non-coherent > mappings. Intel historically has done things a bit differently. And it's also possible that embedded platforms and ARM prefer this mode of operation, but I haven't caught up on that discussion. > > But if you want a coherent mapping you can't go to a struct page, > because on many systems you can't just map arbitrary memory as > uncachable. It might either come from very special limited pools, > or might need other magic applied to it so that it is not visible > in the normal direct mapping, or at least not access through it. The TTM subsystem has been relied on to provide coherent memory with the option to switch caching mode of pages. But only on selected and well tested platforms. On other platforms we simply do not load, and that's fine for now. But as mentioned multiple times, to make GPU drivers more compliant, we'd really want that bool dma_streaming_is_coherent(const struct device *) API to help us decide when to load or not. Thanks, Thomas
Re: [PATCH V2] mm: Introduce GFP_PGTABLE
Le 16/01/2019 à 07:21, Anshuman Khandual a écrit :
All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
__GFP_ZERO) and using it for allocating page table pages. This causes some
code duplication which can be easily avoided. GFP_KERNEL allocated and
cleared out pages (__GFP_ZERO) are required for page tables on any given
architecture. This creates a new generic GFP flag flag which can be used
for any page table page allocation. Does not cause any functional change.
GFP_PGTABLE is being added into include/asm-generic/pgtable.h which is the
generic page tabe header just to prevent it's potential misuse as a general
allocation flag if included in include/linux/gfp.h.
Signed-off-by: Anshuman Khandual
---
Build tested on arm, arm64, powerpc, powerpc64le and x86.
Boot tested on arm64 and x86.
Changes in V2:
- Moved GFP_PGTABLE into include/asm-generic/pgtable.h
- On X86 added __GFP_ACCOUNT into GFP_PGTABLE at various places
- Replaced possible flags on riscv and nds32 with GFP_PGTABLE
Could also replace the flags in
arch/powerpc/include/asm/nohash/64/pgalloc.h with GFP_PGTABLE in
pte_alloc_one_kernel() and pte_alloc_one()
Christophe
Original V1: https://lkml.org/lkml/2019/1/12/54
arch/arm/include/asm/pgalloc.h | 8 +++-
arch/arm/mm/mmu.c| 2 +-
arch/arm64/include/asm/pgalloc.h | 9 -
arch/arm64/mm/mmu.c | 2 +-
arch/arm64/mm/pgd.c | 4 ++--
arch/nds32/include/asm/pgalloc.h | 3 +--
arch/powerpc/include/asm/book3s/64/pgalloc.h | 6 +++---
arch/powerpc/include/asm/pgalloc.h | 2 --
arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
arch/powerpc/mm/pgtable-frag.c | 4 ++--
arch/riscv/include/asm/pgalloc.h | 8 +++-
arch/sh/mm/pgtable.c | 6 ++
arch/unicore32/include/asm/pgalloc.h | 6 ++
arch/x86/kernel/espfix_64.c | 6 ++
arch/x86/mm/pgtable.c| 15 +++
include/asm-generic/pgtable.h| 2 ++
virt/kvm/arm/mmu.c | 2 +-
17 files changed, 37 insertions(+), 50 deletions(-)
diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
index 17ab72f..72be6f5 100644
--- a/arch/arm/include/asm/pgalloc.h
+++ b/arch/arm/include/asm/pgalloc.h
@@ -57,8 +57,6 @@ static inline void pud_populate(struct mm_struct *mm, pud_t
*pud, pmd_t *pmd)
extern pgd_t *pgd_alloc(struct mm_struct *mm);
extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
-#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO)
-
static inline void clean_pte_table(pte_t *pte)
{
clean_dcache_area(pte + PTE_HWTABLE_PTRS, PTE_HWTABLE_SIZE);
@@ -85,7 +83,7 @@ pte_alloc_one_kernel(struct mm_struct *mm)
{
pte_t *pte;
- pte = (pte_t *)__get_free_page(PGALLOC_GFP);
+ pte = (pte_t *)__get_free_page(GFP_PGTABLE);
if (pte)
clean_pte_table(pte);
@@ -98,9 +96,9 @@ pte_alloc_one(struct mm_struct *mm)
struct page *pte;
#ifdef CONFIG_HIGHPTE
- pte = alloc_pages(PGALLOC_GFP | __GFP_HIGHMEM, 0);
+ pte = alloc_pages(GFP_PGTABLE | __GFP_HIGHMEM, 0);
#else
- pte = alloc_pages(PGALLOC_GFP, 0);
+ pte = alloc_pages(GFP_PGTABLE, 0);
#endif
if (!pte)
return NULL;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5cc1cc..6d47784 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -733,7 +733,7 @@ static void __init *early_alloc(unsigned long sz)
static void *__init late_alloc(unsigned long sz)
{
- void *ptr = (void *)__get_free_pages(PGALLOC_GFP, get_order(sz));
+ void *ptr = (void *)__get_free_pages(GFP_PGTABLE, get_order(sz));
if (!ptr || !pgtable_page_ctor(virt_to_page(ptr)))
BUG();
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 52fa47c..d5c75bf 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,14 +26,13 @@
#define check_pgt_cache() do { } while (0)
-#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO)
#define PGD_SIZE (PTRS_PER_PGD * sizeof(pgd_t))
#if CONFIG_PGTABLE_LEVELS > 2
static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
{
- return (pmd_t *)__get_free_page(PGALLOC_GFP);
+ return (pmd_t *)__get_free_page(GFP_PGTABLE);
}
static inline void pmd_free(struct mm_struct *mm, pmd_t *pmdp)
@@ -62,7 +61,7 @@ static inline void __pud_populate(pud_t *pudp, phys_addr_t
pmdp, pudval_t prot)
static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
{
- return (pud_t *)__get_free_page(PGALLOC_GFP);
+ return (pud_t *)__get_free_page(GFP_PGTABLE);
}
static inline void pud_free(struct mm_struct *mm, pud_t *pudp)
@@ -93,7 +92,7
Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
On Wed, Jan 16, 2019 at 7:10 AM Borislav Petkov wrote:
> > +#ifdef CONFIG_ACPI
> > + /* Setup ACPI RSDP pointer in case EFI is not available in second
> > kernel */
> > + if (!acpi_disabled && (!efi_enabled(EFI_RUNTIME_SERVICES) ||
> > efi_enabled(EFI_OLD_MEMMAP))) {
> > + /* Copied from acpi_os_get_root_pointer accordingly */
> > + params->acpi_rsdp_addr = boot_params.acpi_rsdp_addr;
> > + if (!params->acpi_rsdp_addr) {
> > + if (efi_enabled(EFI_CONFIG_TABLES)) {
> > + if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> > + params->acpi_rsdp_addr = efi.acpi20;
> > + else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> > + params->acpi_rsdp_addr = efi.acpi;
> > + } else if
> > (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
> > +
> > acpi_find_root_pointer(>acpi_rsdp_addr);
> > + }
> > + }
> > + if (!params->acpi_rsdp_addr)
> > + pr_warn("RSDP is not available for second kernel\n");
> > + }
> > #endif
>
> Amazing the amount of ACPI RDSP parsing and fiddling patches flying
> around these days...
>
> In any case, this needs to be synchronized with:
>
> https://lkml.kernel.org/r/20190107032243.25324-1-fanc.f...@cn.fujitsu.com
>
> and checked whether the above can be used instead of sprinkling of ACPI
> parsing code left and right.
>
> Thx.
Hi thanks for the suggestion.
I didn't see a way to reuse things in that patch series, situation is
different, in that patch it needs to get RSDP in very early boot stage
so it did everything from scratch, in this patch kexec_file_load need
to get RSDP too, but everything is well setup so things are a lot
easier, just read from current boot_prams, efi and fallback to
acpi_find_root_pointer should be good.
And that patch series also need to consider boot_params.acpi_rsdp_addr
value, or it won't work if the system is rebooted with kexec, efi is
disabled and acpi_rsdp is provided by boot_params (Xen PVH guests also
need to get acpi_rsdp from boot_params according to commit message of
ae7e1238e68f2a472a125673ab506d49158c1889). Will add some comment and
discuss.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
--
Best Regards,
Kairui Song
RE: [PATCH 1/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset
Hi, On 16, 2019 14:48 Ran Wang wrote: > It seems the preface patch (0/2) failed to be accepted by patchwork (could anyone tell me how to generate it properly with some sommand?), I paste its content here for your reference : This to fix USB enumeration compatibility issue found on DWC3 (host mode) IP only. Some pre-discussion mails can be referred from: https://lkml.org/lkml/2018/11/23/387 https://lkml.org/lkml/2018/11/22/683 As to the workaround, I know programming xhci register in DWC3 dirver (probe function) is not good from perspective of SW stack, but it seems to be the only place to fix this real existing problem (test result show that doing this in xhci-plat.c or xhci.c would not hlep on this kind of failure). If who have better idea, please let me know, thanks in advanced. Ran Wang (2): dt-bindings: Add workaround for host mode VBUS glitch when boot dwc3 core driver: Add avoiding vbus glitch happen during xhci reset Documentation/devicetree/bindings/usb/dwc3.txt |3 +++ drivers/usb/dwc3/core.c | 47 +++ drivers/usb/dwc3/core.h | 10 +- 3 files changed, 60 insertions(+), 0 deletions(-) > When DWC3 is set to host mode by programming register DWC3_GCTL, VUBS > (or its control signal) will on immediately on related Root Hub ports. > Then the VUBS will be de-asserted for a little while during xhci reset > (conducted by xhci driver) for a little while and back to normal. > > This VBUS glitch might cause some USB devices emuration fail if kernel boot > with them connected. One SW workaround which can fix this is to program > all PORTSC[PP] to 0 to turn off VBUS immediately after setting host mode in > DWC3 driver(per signal measurement result, it will be too late to do it in > xhci-plat.c or xhci.c). > > Signed-off-by: Ran Wang > --- > Documentation/devicetree/bindings/usb/dwc3.txt |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt > b/Documentation/devicetree/bindings/usb/dwc3.txt > index 8e5265e..dadb530 100644 > --- a/Documentation/devicetree/bindings/usb/dwc3.txt > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt > @@ -106,6 +106,9 @@ Optional properties: > When just one value, which means INCRX burst > mode enabled. When > more than one value, which means undefined length > INCR burst type > enabled. The values can be 1, 4, 8, 16, 32, 64, 128 > and 256. > + - snps,avoid-vbus-glitch-when-set-host: Power off all Root Hub ports > immediately > + after setting host mode to avoid vbus (negative) > glitch happen in later > + xhci reset. And the vbus will back to 5V automatically > when reset done. > > - in addition all properties from usb-xhci.txt from the current directory > are > supported as well > -- > 1.7.1 Regards, Ran
Re: [PATCH v3] memcg: schedule high reclaim for remote memcgs on high_work
On Tue 15-01-19 11:38:23, Shakeel Butt wrote: > On Mon, Jan 14, 2019 at 11:25 PM Michal Hocko wrote: > > > > On Mon 14-01-19 12:18:07, Shakeel Butt wrote: > > > On Sun, Jan 13, 2019 at 10:34 AM Michal Hocko wrote: > > > > > > > > On Fri 11-01-19 14:54:32, Shakeel Butt wrote: > > > > > Hi Johannes, > > > > > > > > > > On Fri, Jan 11, 2019 at 12:59 PM Johannes Weiner > > > > > wrote: > > > > > > > > > > > > Hi Shakeel, > > > > > > > > > > > > On Thu, Jan 10, 2019 at 09:44:32AM -0800, Shakeel Butt wrote: > > > > > > > If a memcg is over high limit, memory reclaim is scheduled to run > > > > > > > on > > > > > > > return-to-userland. However it is assumed that the memcg is the > > > > > > > current > > > > > > > process's memcg. With remote memcg charging for kmem or swapping > > > > > > > in a > > > > > > > page charged to remote memcg, current process can trigger reclaim > > > > > > > on > > > > > > > remote memcg. So, schduling reclaim on return-to-userland for > > > > > > > remote > > > > > > > memcgs will ignore the high reclaim altogether. So, record the > > > > > > > memcg > > > > > > > needing high reclaim and trigger high reclaim for that memcg on > > > > > > > return-to-userland. However if the memcg is already recorded for > > > > > > > high > > > > > > > reclaim and the recorded memcg is not the descendant of the the > > > > > > > memcg > > > > > > > needing high reclaim, punt the high reclaim to the work queue. > > > > > > > > > > > > The idea behind remote charging is that the thread allocating the > > > > > > memory is not responsible for that memory, but a different cgroup > > > > > > is. Why would the same thread then have to work off any high excess > > > > > > this could produce in that unrelated group? > > > > > > > > > > > > Say you have a inotify/dnotify listener that is restricted in its > > > > > > memory use - now everybody sending notification events from outside > > > > > > that listener's group would get throttled on a cgroup over which it > > > > > > has no control. That sounds like a recipe for priority inversions. > > > > > > > > > > > > It seems to me we should only do reclaim-on-return when current is > > > > > > in > > > > > > the ill-behaved cgroup, and punt everything else - interrupts and > > > > > > remote charges - to the workqueue. > > > > > > > > > > This is what v1 of this patch was doing but Michal suggested to do > > > > > what this version is doing. Michal's argument was that the current is > > > > > already charging and maybe reclaiming a remote memcg then why not do > > > > > the high excess reclaim as well. > > > > > > > > Johannes has a good point about the priority inversion problems which I > > > > haven't thought about. > > > > > > > > > Personally I don't have any strong opinion either way. What I actually > > > > > wanted was to punt this high reclaim to some process in that remote > > > > > memcg. However I didn't explore much on that direction thinking if > > > > > that complexity is worth it. Maybe I should at least explore it, so, > > > > > we can compare the solutions. What do you think? > > > > > > > > My question would be whether we really care all that much. Do we know of > > > > workloads which would generate a large high limit excess? > > > > > > > > > > The current semantics of memory.high is that it can be breached under > > > extreme conditions. However any workload where memory.high is used and > > > a lot of remote memcg charging happens (inotify/dnotify example given > > > by Johannes or swapping in tmpfs file or shared memory region) the > > > memory.high breach will become common. > > > > This is exactly what I am asking about. Is this something that can > > happen easily? Remote charges on themselves should be rare, no? > > > > At the moment, for kmem we can do remote charging for fanotify, > inotify and buffer_head and for anon pages we can do remote charging > on swap in. Now based on the workload's cgroup setup the remote > charging can be very frequent or rare. > > At Google, remote charging is very frequent but since we are still on > cgroup-v1 and do not use memory.high, the issue this patch is fixing > is not observed. However for the adoption of cgroup-v2, this fix is > needed. Adding some numbers into the changelog would be really valuable to judge the urgency and the scale of the problem. If we are going via kworker then it is also important to evaluate what kind of effect on the system this has. How big of the excess can we get? Why don't those memcgs resolve the excess by themselves on the first direct charge? Is it possible that kworkers simply swamp the system with many parallel memcgs with remote charges? In other words we need deeper analysis of the problem and the solution. -- Michal Hocko SUSE Labs
Re: [PATCH 4.20 00/57] 4.20.3-stable review
On Tue, Jan 15, 2019 at 07:00:59PM -0700, shuah wrote: > On 1/15/19 9:35 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.20.3 release. > > There are 57 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jan 17 15:48:32 UTC 2019. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.20.3-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.20.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH V2] mm: Introduce GFP_PGTABLE
On Wed 16-01-19 11:51:32, Anshuman Khandual wrote:
> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
> __GFP_ZERO) and using it for allocating page table pages. This causes some
> code duplication which can be easily avoided. GFP_KERNEL allocated and
> cleared out pages (__GFP_ZERO) are required for page tables on any given
> architecture. This creates a new generic GFP flag flag which can be used
> for any page table page allocation. Does not cause any functional change.
>
> GFP_PGTABLE is being added into include/asm-generic/pgtable.h which is the
> generic page tabe header just to prevent it's potential misuse as a general
> allocation flag if included in include/linux/gfp.h.
I haven't reviewed the patch yet but I am wondering whether this is
really worth it without going all the way down to unify the common code
and remove much more code duplication. Or is this not possible for some
reason?
> Signed-off-by: Anshuman Khandual
> ---
> Build tested on arm, arm64, powerpc, powerpc64le and x86.
> Boot tested on arm64 and x86.
>
> Changes in V2:
>
> - Moved GFP_PGTABLE into include/asm-generic/pgtable.h
> - On X86 added __GFP_ACCOUNT into GFP_PGTABLE at various places
> - Replaced possible flags on riscv and nds32 with GFP_PGTABLE
>
> Original V1: https://lkml.org/lkml/2019/1/12/54
>
> arch/arm/include/asm/pgalloc.h | 8 +++-
> arch/arm/mm/mmu.c| 2 +-
> arch/arm64/include/asm/pgalloc.h | 9 -
> arch/arm64/mm/mmu.c | 2 +-
> arch/arm64/mm/pgd.c | 4 ++--
> arch/nds32/include/asm/pgalloc.h | 3 +--
> arch/powerpc/include/asm/book3s/64/pgalloc.h | 6 +++---
> arch/powerpc/include/asm/pgalloc.h | 2 --
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
> arch/powerpc/mm/pgtable-frag.c | 4 ++--
> arch/riscv/include/asm/pgalloc.h | 8 +++-
> arch/sh/mm/pgtable.c | 6 ++
> arch/unicore32/include/asm/pgalloc.h | 6 ++
> arch/x86/kernel/espfix_64.c | 6 ++
> arch/x86/mm/pgtable.c| 15 +++
> include/asm-generic/pgtable.h| 2 ++
> virt/kvm/arm/mmu.c | 2 +-
> 17 files changed, 37 insertions(+), 50 deletions(-)
>
> diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
> index 17ab72f..72be6f5 100644
> --- a/arch/arm/include/asm/pgalloc.h
> +++ b/arch/arm/include/asm/pgalloc.h
> @@ -57,8 +57,6 @@ static inline void pud_populate(struct mm_struct *mm, pud_t
> *pud, pmd_t *pmd)
> extern pgd_t *pgd_alloc(struct mm_struct *mm);
> extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
>
> -#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO)
> -
> static inline void clean_pte_table(pte_t *pte)
> {
> clean_dcache_area(pte + PTE_HWTABLE_PTRS, PTE_HWTABLE_SIZE);
> @@ -85,7 +83,7 @@ pte_alloc_one_kernel(struct mm_struct *mm)
> {
> pte_t *pte;
>
> - pte = (pte_t *)__get_free_page(PGALLOC_GFP);
> + pte = (pte_t *)__get_free_page(GFP_PGTABLE);
> if (pte)
> clean_pte_table(pte);
>
> @@ -98,9 +96,9 @@ pte_alloc_one(struct mm_struct *mm)
> struct page *pte;
>
> #ifdef CONFIG_HIGHPTE
> - pte = alloc_pages(PGALLOC_GFP | __GFP_HIGHMEM, 0);
> + pte = alloc_pages(GFP_PGTABLE | __GFP_HIGHMEM, 0);
> #else
> - pte = alloc_pages(PGALLOC_GFP, 0);
> + pte = alloc_pages(GFP_PGTABLE, 0);
> #endif
> if (!pte)
> return NULL;
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index f5cc1cc..6d47784 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -733,7 +733,7 @@ static void __init *early_alloc(unsigned long sz)
>
> static void *__init late_alloc(unsigned long sz)
> {
> - void *ptr = (void *)__get_free_pages(PGALLOC_GFP, get_order(sz));
> + void *ptr = (void *)__get_free_pages(GFP_PGTABLE, get_order(sz));
>
> if (!ptr || !pgtable_page_ctor(virt_to_page(ptr)))
> BUG();
> diff --git a/arch/arm64/include/asm/pgalloc.h
> b/arch/arm64/include/asm/pgalloc.h
> index 52fa47c..d5c75bf 100644
> --- a/arch/arm64/include/asm/pgalloc.h
> +++ b/arch/arm64/include/asm/pgalloc.h
> @@ -26,14 +26,13 @@
>
> #define check_pgt_cache()do { } while (0)
>
> -#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO)
> #define PGD_SIZE (PTRS_PER_PGD * sizeof(pgd_t))
>
> #if CONFIG_PGTABLE_LEVELS > 2
>
> static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
> {
> - return (pmd_t *)__get_free_page(PGALLOC_GFP);
> + return (pmd_t *)__get_free_page(GFP_PGTABLE);
> }
>
> static inline void pmd_free(struct mm_struct *mm, pmd_t *pmdp)
> @@ -62,7 +61,7 @@ static inline void __pud_populate(pud_t *pudp, phys_addr_t
> pmdp, pudval_t prot)
>
> static inline pud_t *pud_alloc_one(struct mm_struct *mm,
Re: [PATCH V2] mm: Introduce GFP_PGTABLE
On Wed, Jan 16, 2019 at 11:51:32AM +0530, Anshuman Khandual wrote:
> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
> __GFP_ZERO) and using it for allocating page table pages. This causes some
> code duplication which can be easily avoided. GFP_KERNEL allocated and
> cleared out pages (__GFP_ZERO) are required for page tables on any given
> architecture. This creates a new generic GFP flag flag which can be used
> for any page table page allocation. Does not cause any functional change.
>
> GFP_PGTABLE is being added into include/asm-generic/pgtable.h which is the
> generic page tabe header just to prevent it's potential misuse as a general
> allocation flag if included in include/linux/gfp.h.
>
> Signed-off-by: Anshuman Khandual
> ---
> Build tested on arm, arm64, powerpc, powerpc64le and x86.
> Boot tested on arm64 and x86.
>
> Changes in V2:
>
> - Moved GFP_PGTABLE into include/asm-generic/pgtable.h
> - On X86 added __GFP_ACCOUNT into GFP_PGTABLE at various places
> - Replaced possible flags on riscv and nds32 with GFP_PGTABLE
>
> Original V1: https://lkml.org/lkml/2019/1/12/54
>
> arch/arm/include/asm/pgalloc.h | 8 +++-
> arch/arm/mm/mmu.c| 2 +-
> arch/arm64/include/asm/pgalloc.h | 9 -
> arch/arm64/mm/mmu.c | 2 +-
> arch/arm64/mm/pgd.c | 4 ++--
> arch/nds32/include/asm/pgalloc.h | 3 +--
> arch/powerpc/include/asm/book3s/64/pgalloc.h | 6 +++---
> arch/powerpc/include/asm/pgalloc.h | 2 --
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
> arch/powerpc/mm/pgtable-frag.c | 4 ++--
> arch/riscv/include/asm/pgalloc.h | 8 +++-
> arch/sh/mm/pgtable.c | 6 ++
> arch/unicore32/include/asm/pgalloc.h | 6 ++
> arch/x86/kernel/espfix_64.c | 6 ++
> arch/x86/mm/pgtable.c| 15 +++
> include/asm-generic/pgtable.h| 2 ++
> virt/kvm/arm/mmu.c | 2 +-
> 17 files changed, 37 insertions(+), 50 deletions(-)
I wonder, what about the other arches? Do they use different GFP flags?
> diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
> index 17ab72f..72be6f5 100644
> --- a/arch/arm/include/asm/pgalloc.h
> +++ b/arch/arm/include/asm/pgalloc.h
> @@ -57,8 +57,6 @@ static inline void pud_populate(struct mm_struct *mm, pud_t
> *pud, pmd_t *pmd)
> extern pgd_t *pgd_alloc(struct mm_struct *mm);
> extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
>
> -#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO)
> -
> static inline void clean_pte_table(pte_t *pte)
> {
> clean_dcache_area(pte + PTE_HWTABLE_PTRS, PTE_HWTABLE_SIZE);
> @@ -85,7 +83,7 @@ pte_alloc_one_kernel(struct mm_struct *mm)
> {
> pte_t *pte;
>
> - pte = (pte_t *)__get_free_page(PGALLOC_GFP);
> + pte = (pte_t *)__get_free_page(GFP_PGTABLE);
> if (pte)
> clean_pte_table(pte);
>
> @@ -98,9 +96,9 @@ pte_alloc_one(struct mm_struct *mm)
> struct page *pte;
>
> #ifdef CONFIG_HIGHPTE
> - pte = alloc_pages(PGALLOC_GFP | __GFP_HIGHMEM, 0);
> + pte = alloc_pages(GFP_PGTABLE | __GFP_HIGHMEM, 0);
> #else
> - pte = alloc_pages(PGALLOC_GFP, 0);
> + pte = alloc_pages(GFP_PGTABLE, 0);
> #endif
> if (!pte)
> return NULL;
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index f5cc1cc..6d47784 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -733,7 +733,7 @@ static void __init *early_alloc(unsigned long sz)
>
> static void *__init late_alloc(unsigned long sz)
> {
> - void *ptr = (void *)__get_free_pages(PGALLOC_GFP, get_order(sz));
> + void *ptr = (void *)__get_free_pages(GFP_PGTABLE, get_order(sz));
>
> if (!ptr || !pgtable_page_ctor(virt_to_page(ptr)))
> BUG();
> diff --git a/arch/arm64/include/asm/pgalloc.h
> b/arch/arm64/include/asm/pgalloc.h
> index 52fa47c..d5c75bf 100644
> --- a/arch/arm64/include/asm/pgalloc.h
> +++ b/arch/arm64/include/asm/pgalloc.h
> @@ -26,14 +26,13 @@
>
> #define check_pgt_cache()do { } while (0)
>
> -#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO)
> #define PGD_SIZE (PTRS_PER_PGD * sizeof(pgd_t))
>
> #if CONFIG_PGTABLE_LEVELS > 2
>
> static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
> {
> - return (pmd_t *)__get_free_page(PGALLOC_GFP);
> + return (pmd_t *)__get_free_page(GFP_PGTABLE);
> }
>
> static inline void pmd_free(struct mm_struct *mm, pmd_t *pmdp)
> @@ -62,7 +61,7 @@ static inline void __pud_populate(pud_t *pudp, phys_addr_t
> pmdp, pudval_t prot)
>
> static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
> {
> - return (pud_t *)__get_free_page(PGALLOC_GFP);
> + return (pud_t *)__get_free_page(GFP_PGTABLE);
> }
>
>
Re: [PATCH v2 00/15] powerpc/32s: Use BATs/LTLBs for STRICT_KERNEL_RWX
Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit :
On Tue, Jan 15, 2019 at 07:51:01AM +0100, Christophe Leroy wrote:
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
[...]
I've checked it patch-by-patch now (with STRICT_KERNEL_RWX):
- patches 1 and 2 build and boot fine
- patches 3 to 6 build, but fail to boot with this error:
The bug is in patch 2, mmu_mapin_ram() should return base instead of
returning 0 when __map_without_bats is set.
Indeed, with this change, I can boot up to patch 11.
- patches 12 to 15 build but fail to boot with this error:
Thats the one we need to really understand.
Do you have modules ? If so, can you try without ?
I don't use any modules in my test setup, but I have module support
enabled. Disabling CONFIG_MODULES makes no difference, as far as I can
see (I get the same backtrace with memblock_alloc_base+0x34/0x44).
[0.00] [c0f1ff30] [c00280f0] panic+0x144/0x324 (unreliable)
[0.00] [c0f1ff90] [c0c18a34] memblock_alloc_base+0x34/0x44
[0.00] [c0f1ffa0] [c0c071e0] MMU_init_hw+0xcc/0x300
[0.00] [c0f1ffd0] [c0c06554] MMU_init+0x12c/0x198
[0.00] [c0f1fff0] [c0003418] start_here+0x40/0x78
With a few printks[1], I traced this error, and got the following
result:
[0.00] __memblock_find_range_top_down(1000:180, 10:10,
, 0)
[0.00] __memblock_find_range_top_down: in loop, 1000:13f0
[0.00] __memblock_find_range_top_down: in loop, 179962d:180
[0.00] __memblock_find_range_top_down: in loop, 1676000:17987a0
[0.00] __memblock_find_range_top_down: nothing found :(
The limit of 0x180 comes from setup_initial_memory_limit, which only
considers the first memblock, but the second memblock starts at 256MiB,
so it wouldn't be usable anyway, according to the comment in
setup_initial_memory_limit.
Yes, initial_bats() in head_32.S sets one 256Mb BAT for initial booting:
/*
* On 601, we use 3 BATs to map up to 24M of RAM at _PAGE_OFFSET
* (we keep one for debugging) and on others, we use one 256M BAT.
*/
initial_bats:
lis r11,PAGE_OFFSET@h
mfspr r9,SPRN_PVR
rlwinm r9,r9,16,16,31 /* r9 = 1 for 601, 4 for 604 */
cmpwi 0,r9,1
bne 4f
...
4: tophys(r8,r11)
#ifdef CONFIG_SMP
ori r8,r8,0x12 /* R/W access, M=1 */
#else
ori r8,r8,2 /* R/W access */
#endif /* CONFIG_SMP */
ori r11,r11,BL_256M<<2|0x2/* set up BAT registers for 604 */
mtspr SPRN_DBAT0L,r8 /* N.B. 6xx (not 601) have valid */
mtspr SPRN_DBAT0U,r11 /* bit in upper BAT register */
mtspr SPRN_IBAT0L,r8
mtspr SPRN_IBAT0U,r11
isync
blr
Thinning the kernel down a bit actually makes it boot again. Ooops...!
Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to
fail the hash table allocation, but there may have been other factors
involved (I'm not sure exactly). Sorry for the confusion!
Ok, that must be the reason. Thanks for testing.
What about the following modification which maps a second 256Mb BAT,
does it helps ?
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index c2f564690778..ea574596de37 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -1160,6 +1160,14 @@ initial_bats:
mtspr SPRN_DBAT0U,r11 /* bit in upper BAT register */
mtspr SPRN_IBAT0L,r8
mtspr SPRN_IBAT0U,r11
+#ifdef CONFIG_WII
+ addis r11,r11,0x1000@h
+ addis r8,r8,0x1000@h
+ mtspr SPRN_DBAT2L,r8
+ mtspr SPRN_DBAT2U,r11
+ mtspr SPRN_IBAT2L,r8
+ mtspr SPRN_IBAT2U,r11
+#endif
isync
blr
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index 3f4193201ee7..a334fd5210a8 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -259,6 +259,8 @@ void setup_initial_memory_limit(phys_addr_t
first_memblock_base,
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
memblock_set_current_limit(min_t(u64, first_memblock_size,
0x0100));
+ else if (IS_ENABLED(CONFIG_WII))
+ memblock_set_current_limit(min_t(u64, first_memblock_size,
0x2000));
else /* Anything else has 256M mapped */
memblock_set_current_limit(min_t(u64, first_memblock_size,
0x1000));
}
Christophe
Jonathan
[1]:
diff --git a/mm/memblock.c b/mm/memblock.c
index 022d4cbb3618..66d588e08487 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -215,8 +215,11 @@ __memblock_find_range_top_down(phys_addr_t start,
phys_addr_t end,
phys_addr_t this_start, this_end, cand;
u64 i;
+ printk("%s(%x:%x, %x:%x, %x, %x)\n", __func__, start, end, size, align, nid, flags);
+
Re: [PATCH] staging: rtl8723bs: Fix build error with Clang when inlining is disabled
On Wed, Jan 16, 2019 at 07:42:02AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 11:03:02PM -0700, Nathan Chancellor wrote:
> > When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
> > '-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
> > Clang failed at the modpost stage:
> >
> > ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> > undefined!
> > ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
> > ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> > undefined!
> >
> > These functions were marked as extern inline, meaning that if inlining
> > doesn't happen, the function will be undefined, as it is above.
> >
> > This happens to work with GCC because the '-fno-inline-functions' option
> > respects the __inline attribute so all instances of these functions are
> > inlined as expected and the definition doesn't actually matter. However,
> > with Clang and '-fno-inline-functions', a function has to be marked with
> > the __always_inline attribute to be considered for inlining, which none
> > of these functions are. Clang tries to find the symbol definition
> > elsewhere as it was told and fails, which trickles down to modpost.
> >
> > To make sure that this code compiles regardless of compiler and make the
> > intention of the code clearer, use 'static __always_inline' to ensure
> > that these functions are always inlined. Some alternative solutions
> > included 'extern __always_inline' or converting these functions to
> > macros (so the preprocessor deals with them) but I would argue this is
> > the more "standard" solution.
> >
> > Signed-off-by: Nathan Chancellor
> > ---
> > drivers/staging/rtl8723bs/include/ieee80211.h | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8723bs/include/ieee80211.h
> > b/drivers/staging/rtl8723bs/include/ieee80211.h
> > index bcc8dfa8e672..959e822315b5 100644
> > --- a/drivers/staging/rtl8723bs/include/ieee80211.h
> > +++ b/drivers/staging/rtl8723bs/include/ieee80211.h
> > @@ -850,18 +850,18 @@ enum ieee80211_state {
> > #define IP_FMT "%pI4"
> > #define IP_ARG(x) (x)
> >
> > -extern __inline int is_multicast_mac_addr(const u8 *addr)
> > +static __always_inline int is_multicast_mac_addr(const u8 *addr)
>
> Ick, really? This is in a .h file, the .c file sees this, so why isn't
> clang picking it up? Worst case it just makes it a "normal" function
> and doesn't inline it, right?
>
As I understand it, the meaning of 'extern inline' is basically use this
defintion when inlining, otherwise use one from a different file or
translation unit. See commit d0a8d9378d16 ("x86/paravirt: Make
native_save_fl() extern inline"). These functions don't have any other
declaration/definition so when they aren't inlined, they don't exist.
> How about just replacing "extern" with "static", that should solve this,
> adding "__always_inline" everywhere is not going to be fun and doesn't
> make any sense.
>
Yes, that would work (and what I originally tested). My assumption with
the code is that it was intended for this function to always be inlined
but if you'd rather it just be 'static', I am happy to send a v2!
> thanks,
>
> greg k-h
Thanks for the quick reply and review,
Nathan
Re: [PATCH -next] binderfs: fix error return code in binderfs_fill_super()
On Wed, Jan 16, 2019 at 07:28:26AM +0100, Christian Brauner wrote:
> On Wed, Jan 16, 2019 at 07:25:46AM +0100, Christian Brauner wrote:
> > On Wed, Jan 16, 2019 at 03:01:04AM +, Wei Yongjun wrote:
> > > Fix to return a negative error code -ENOMEM from the new_inode() and
> > > d_make_root() error handling cases instead of 0, as done elsewhere in
> > > this function.
> > >
> > > Fixes: 3ad20fe393b3 ("binder: implement binderfs")
>
> This Fixes tag is technically wrong since this codepath was introduced
> by a commit that is still sitting in Greg's char-misc-linus branch. Not
> sure how to handle that though. Might just leave it.
Use the git commit id of the patch in that branch, it is not going to
change as I do not rebase that branch.
thanks,
greg k-h
[PATCH] mm/page_alloc: check return value of memblock_alloc_node_nopanic()
There are two early memory allocations that use
memblock_alloc_node_nopanic() and do not check its return value.
While this happens very early during boot and chances that the allocation
will fail are diminishing, it is still worth to have proper checks for the
allocation errors.
Signed-off-by: Mike Rapoport
---
mm/page_alloc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d295c9bc01a8..7801accbe02a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6376,10 +6376,14 @@ static void __ref setup_usemap(struct pglist_data
*pgdat,
{
unsigned long usemapsize = usemap_size(zone_start_pfn, zonesize);
zone->pageblock_flags = NULL;
- if (usemapsize)
+ if (usemapsize) {
zone->pageblock_flags =
memblock_alloc_node_nopanic(usemapsize,
pgdat->node_id);
+ if (!zone->pageblock_flags)
+ panic("Failed to allocate %ld bytes for zone %s
pageblock flags\n",
+ usemapsize, zone->name);
+ }
}
#else
static inline void setup_usemap(struct pglist_data *pgdat, struct zone *zone,
@@ -6609,6 +6613,9 @@ static void __ref alloc_node_mem_map(struct pglist_data
*pgdat)
end = ALIGN(end, MAX_ORDER_NR_PAGES);
size = (end - start) * sizeof(struct page);
map = memblock_alloc_node_nopanic(size, pgdat->node_id);
+ if (!map)
+ panic("Failed to allocate %ld bytes for memory map\n",
+ size);
pgdat->node_mem_map = map + offset;
}
pr_debug("%s: node %d, pgdat %08lx, node_mem_map %08lx\n",
--
2.7.4
Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
On 01/16/19 at 01:09pm, Kairui Song wrote:
> On Wed, Jan 16, 2019 at 11:32 AM Dave Young wrote:
> >
> > On 01/16/19 at 12:10am, Borislav Petkov wrote:
> > > On Tue, Jan 15, 2019 at 05:58:34PM +0800, Kairui Song wrote:
> > > > When efi=noruntime or efi=oldmap is used, EFI services won't be
> > > > available
> > > > in the second kernel, therefore the second kernel will not be able to
> > > > get
> > > > the ACPI RSDP address from firmware by calling EFI services and won't
> > > > boot. Previously we are expecting the user to set the acpi_rsdp=
> > > > on kernel command line for second kernel as there was no way to pass
> > > > RSDP
> > > > address to second kernel.
> > > >
> > > > After commit e6e094e053af ('x86/acpi, x86/boot: Take RSDP address from
> > > > boot params if available'), now it's possible to set an acpi_rsdp_addr
> > > > parameter in the boot_params passed to second kernel, this commit make
> > > > use of it, detect and set the RSDP address when it's required for second
> > > > kernel to boot.
> > > >
> > > > Tested with an EFI enabled KVM VM with efi=noruntime.
> > > >
> > > > Suggested-by: Dave Young
> > > > Signed-off-by: Kairui Song
> > > > ---
> > > > arch/x86/kernel/kexec-bzimage64.c | 21 +
> > > > drivers/acpi/acpica/tbxfroot.c| 3 +--
> > > > include/acpi/acpixf.h | 2 +-
> > > > 3 files changed, 23 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/arch/x86/kernel/kexec-bzimage64.c
> > > > b/arch/x86/kernel/kexec-bzimage64.c
> > > > index 53917a3ebf94..0a90dcbd041f 100644
> > > > --- a/arch/x86/kernel/kexec-bzimage64.c
> > > > +++ b/arch/x86/kernel/kexec-bzimage64.c
> > > > @@ -20,6 +20,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #include
> > > > #include
> > > > @@ -255,8 +256,28 @@ setup_boot_parameters(struct kimage *image, struct
> > > > boot_params *params,
> > > > /* Setup EFI state */
> > > > setup_efi_state(params, params_load_addr, efi_map_offset,
> > > > efi_map_sz,
> > > > efi_setup_data_offset);
> > > > +
> > > > +#ifdef CONFIG_ACPI
> > > > + /* Setup ACPI RSDP pointer in case EFI is not available in second
> > > > kernel */
> > > > + if (!acpi_disabled && (!efi_enabled(EFI_RUNTIME_SERVICES) ||
> > > > efi_enabled(EFI_OLD_MEMMAP))) {
> > > > + /* Copied from acpi_os_get_root_pointer accordingly */
> > > > + params->acpi_rsdp_addr = boot_params.acpi_rsdp_addr;
> > > > + if (!params->acpi_rsdp_addr) {
> > > > + if (efi_enabled(EFI_CONFIG_TABLES)) {
> > > > + if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> > > > + params->acpi_rsdp_addr = efi.acpi20;
> > > > + else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> > > > + params->acpi_rsdp_addr = efi.acpi;
> > > > + } else if
> > > > (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
> > > > +
> > > > acpi_find_root_pointer(>acpi_rsdp_addr);
> > > > + }
> > > > + }
> > > > + if (!params->acpi_rsdp_addr)
> > > > + pr_warn("RSDP is not available for second
> > > > kernel\n");
> > > > + }
> > > > #endif
> > >
> > > Amazing the amount of ACPI RDSP parsing and fiddling patches flying
> > > around these days...
> > >
> > > In any case, this needs to be synchronized with:
> > >
> > > https://lkml.kernel.org/r/20190107032243.25324-1-fanc.f...@cn.fujitsu.com
> > >
> > > and checked whether the above can be used instead of sprinkling of ACPI
> > > parsing code left and right.
> >
> > Both Baoquan and Chao are cced for comments.
> > The above KASLR patches seems some early code to parsing acpi, but I think
> > in this
> > patch just call acpi function to get the root pointer no need to add the
> > duplicate logic of if/else/else if.
> >
> > Kairui, do you have any reason for the checking? Is there some simple
> > acpi function to just return the root pointer?
>
> Hi, I'm afraid that would require moving multiple structure and
> function out of .init,
> acpi_os_get_root_pointer is an ideal function to do the job, but it's
> in .init and (on x86) it will call x86_init.acpi.get_root_pointer (by
> calling acpi_arch_get_root_pointer) which will also be freed after
> init, unless I change the x86_init, move they out of .init which is
> not a good idea.
>
> Maybe I could split acpi_os_get_root_pointer into two, one gets freed
> after init, one for later use. But the "acpi_rsdp_addr" trick only
> works for x86, and this would change more common acpi driver code so
> not sure if a good idea.
Can the acpi root pointer be saved after initialized? If that is good
then a new function to get it would be easier. But need opinion from
acpi people.
Thanks
Dave
[PATCH v2] arm64: dts: qcom: sdm845: Expand soc bus address range
DMA addresses for devices on the soc bus must be constrained to the 36
address bits that the bus provides. When no IOMMU is present then this
is easy--DMA addresses are just physical addresses and physical
addresses are (by definition) within the address bits of the bus. When
an IOMMU is present, however, DMA addresses are virtual addresses.
Despite these addresses being virtual, however, they are still
constrained by the 36 address bits of the bus.
Unless dma-ranges is specified, which causes bus_dma_mask to be set, DMA
allocations for devices on the platform_bus will use all 48 address bits
available by the ARM SMMU. Causing addresses to be truncated on the bus.
This patch increases the #size-cells to 2, in order to be able to define
dma-ranges describe the 36 bit DMA capability of the bus, and bumps
While touching all reg properties, addresses are padded to 8 digits.
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Update commit message per discussion with Doug
- Updated "ranges"
- Rebased ontop of a few additional patches from the mailing list
arch/arm64/boot/dts/qcom/sdm845.dtsi | 265 ++-
1 file changed, 133 insertions(+), 132 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index b5dc7c0e9d5a..56dd4ea5fd12 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -339,14 +339,15 @@
};
soc: soc {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0 0 0x>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0 0 0 0 0x10 0>;
+ dma-ranges = <0 0 0 0 0x10 0>;
compatible = "simple-bus";
gcc: clock-controller@10 {
compatible = "qcom,gcc-sdm845";
- reg = <0x10 0x1f>;
+ reg = <0 0x0010 0 0x1f>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
@@ -354,7 +355,7 @@
qfprom@784000 {
compatible = "qcom,qfprom";
- reg = <0x784000 0x8ff>;
+ reg = <0 0x00784000 0 0x8ff>;
#address-cells = <1>;
#size-cells = <1>;
@@ -371,25 +372,25 @@
rng: rng@793000 {
compatible = "qcom,prng-ee";
- reg = <0x00793000 0x1000>;
+ reg = <0 0x00793000 0 0x1000>;
clocks = < GCC_PRNG_AHB_CLK>;
clock-names = "core";
};
qupv3_id_0: geniqup@8c {
compatible = "qcom,geni-se-qup";
- reg = <0x8c 0x6000>;
+ reg = <0 0x008c 0 0x6000>;
clock-names = "m-ahb", "s-ahb";
clocks = < GCC_QUPV3_WRAP_0_M_AHB_CLK>,
< GCC_QUPV3_WRAP_0_S_AHB_CLK>;
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;
ranges;
status = "disabled";
i2c0: i2c@88 {
compatible = "qcom,geni-i2c";
- reg = <0x88 0x4000>;
+ reg = <0 0x0088 0 0x4000>;
clock-names = "se";
clocks = < GCC_QUPV3_WRAP0_S0_CLK>;
pinctrl-names = "default";
@@ -402,7 +403,7 @@
spi0: spi@88 {
compatible = "qcom,geni-spi";
- reg = <0x88 0x4000>;
+ reg = <0 0x0088 0 0x4000>;
clock-names = "se";
clocks = < GCC_QUPV3_WRAP0_S0_CLK>;
pinctrl-names = "default";
@@ -415,7 +416,7 @@
uart0: serial@88 {
compatible = "qcom,geni-uart";
- reg = <0x88 0x4000>;
+ reg = <0 0x0088 0 0x4000>;
clock-names = "se";
clocks = < GCC_QUPV3_WRAP0_S0_CLK>;
pinctrl-names = "default";
@@ -426,7 +427,7 @@
i2c1: i2c@884000 {
compatible = "qcom,geni-i2c";
- reg = <0x884000 0x4000>;
+ reg = <0 0x00884000 0 0x4000>;
clock-names = "se";
[PATCH v5] staging: Mediatek: Use individual config flags in Makefile
These drivers can be useful on other MT76xx SoCs, which have compatible peripherals. The drivers were selectable in Kconfig, but they were quietly excluded from the build because the SOC_MT7621 chip was not selected. So, make the Makefiles use the same flags as Kconfig for these drivers. mt7621-dma and mt7621-dts are left alone because they truly do require that SoC. I have personally confirmed that the mt7621-spi driver works on the MT7688, which was what prompted this change. Cc: linux-kernel@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: NeilBrown Cc: sergio.paracuel...@gmail.com Signed-off-by: George Hilliard --- Changelog: v2: - Also make the change for skipped/forgotten drivers such as mt7621-eth v3..v4: - Rebase against staging-testing - Also make the change for new PCIe PHY driver - Slightly change commit wording v5: - Fix dependency issue in mt7621-mmc/Kconfig; it now needs to explicitly depend on RALINK because SOC_MT7621 is not required now - Remove check for nonexistent config MTD_NAND_RALINK from mt7621-mmc/Kconfig drivers/staging/Makefile| 14 +++--- drivers/staging/mt7621-mmc/Kconfig | 2 +- drivers/staging/mt7621-pci-phy/Makefile | 2 +- drivers/staging/mt7621-pci/Makefile | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 4d563ed0bc79..cc5530cc996b 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -41,14 +41,14 @@ obj-$(CONFIG_GREYBUS) += greybus/ obj-$(CONFIG_BCM2835_VCHIQ)+= vc04_services/ obj-$(CONFIG_DRM_VBOXVIDEO)+= vboxvideo/ obj-$(CONFIG_PI433)+= pi433/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pci/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pci-phy/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pinctrl/ -obj-$(CONFIG_SOC_MT7621) += mt7621-spi/ +obj-$(CONFIG_PCI_MT7621) += mt7621-pci/ +obj-$(CONFIG_PCI_MT7621_PHY) += mt7621-pci-phy/ +obj-$(CONFIG_PINCTRL_RT2880) += mt7621-pinctrl/ +obj-$(CONFIG_SPI_MT7621) += mt7621-spi/ obj-$(CONFIG_SOC_MT7621) += mt7621-dma/ -obj-$(CONFIG_SOC_MT7621) += ralink-gdma/ -obj-$(CONFIG_SOC_MT7621) += mt7621-mmc/ -obj-$(CONFIG_SOC_MT7621) += mt7621-eth/ +obj-$(CONFIG_DMA_RALINK) += ralink-gdma/ +obj-$(CONFIG_MTK_MMC) += mt7621-mmc/ +obj-$(CONFIG_NET_MEDIATEK_SOC_STAGING) += mt7621-eth/ obj-$(CONFIG_SOC_MT7621) += mt7621-dts/ obj-$(CONFIG_STAGING_GASKET_FRAMEWORK) += gasket/ obj-$(CONFIG_XIL_AXIS_FIFO)+= axis-fifo/ diff --git a/drivers/staging/mt7621-mmc/Kconfig b/drivers/staging/mt7621-mmc/Kconfig index c6dfe8c637dc..1eb79cd6e22f 100644 --- a/drivers/staging/mt7621-mmc/Kconfig +++ b/drivers/staging/mt7621-mmc/Kconfig @@ -1,6 +1,6 @@ config MTK_MMC tristate "MTK SD/MMC" - depends on !MTD_NAND_RALINK && MMC + depends on RALINK && MMC config MTK_AEE_KDUMP bool "MTK AEE KDUMP" diff --git a/drivers/staging/mt7621-pci-phy/Makefile b/drivers/staging/mt7621-pci-phy/Makefile index 2b82ccfc28c6..a970056f05c1 100644 --- a/drivers/staging/mt7621-pci-phy/Makefile +++ b/drivers/staging/mt7621-pci-phy/Makefile @@ -1 +1 @@ -obj-$(CONFIG_SOC_MT7621) += pci-mt7621-phy.o +obj-$(CONFIG_PCI_MT7621_PHY) += pci-mt7621-phy.o diff --git a/drivers/staging/mt7621-pci/Makefile b/drivers/staging/mt7621-pci/Makefile index 607b84bedcc3..d4655a726b61 100644 --- a/drivers/staging/mt7621-pci/Makefile +++ b/drivers/staging/mt7621-pci/Makefile @@ -1 +1 @@ -obj-$(CONFIG_SOC_MT7621) += pci-mt7621.o +obj-$(CONFIG_PCI_MT7621) += pci-mt7621.o -- 2.20.1
[PATCH 1/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset
When DWC3 is set to host mode by programming register DWC3_GCTL, VUBS (or its control signal) will on immediately on related Root Hub ports. Then the VUBS will be de-asserted for a little while during xhci reset (conducted by xhci driver) for a little while and back to normal. This VBUS glitch might cause some USB devices emuration fail if kernel boot with them connected. One SW workaround which can fix this is to program all PORTSC[PP] to 0 to turn off VBUS immediately after setting host mode in DWC3 driver(per signal measurement result, it will be too late to do it in xhci-plat.c or xhci.c). Signed-off-by: Ran Wang --- Documentation/devicetree/bindings/usb/dwc3.txt |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 8e5265e..dadb530 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -106,6 +106,9 @@ Optional properties: When just one value, which means INCRX burst mode enabled. When more than one value, which means undefined length INCR burst type enabled. The values can be 1, 4, 8, 16, 32, 64, 128 and 256. + - snps,avoid-vbus-glitch-when-set-host: Power off all Root Hub ports immediately + after setting host mode to avoid vbus (negative) glitch happen in later + xhci reset. And the vbus will back to 5V automatically when reset done. - in addition all properties from usb-xhci.txt from the current directory are supported as well -- 1.7.1
[PATCH 2/2] usb: dwc3: Add workaround for host mode VBUS glitch when boot
When DWC3 is set to host mode by programming register DWC3_GCTL, VUBS
(or its control signal) will be turned on immediately on related Root Hub
ports. Then, the VUBS is turned off for a little while(15us) when do xhci
reset (conducted by xhci driver) and back to normal finally, we can
observed a negative glitch of related signal from scope.
This VBUS glitch might cause some USB devices enumeration fail if kernel
boot with them connected. Such as LS1012AFWRY/LS1043ARDB/LX2160AQDS
/LS1088ARDB with Kingston 16GB USB2.0/Kingston USB3.0/JetFlash Transcend
4GB USB2.0 drives. The fail cases include enumerated as full-speed device
or report wrong device descriptor, etc.
One SW workaround which can fix this is to program all xhci PORTSC[PP]
to 0 to turn off VBUS immediately after setting host mode in DWC3 driver
(per signal measurement result, it will be too late to do it in
xhci-plat.c or xhci.c). Then, after xhci reset complete in xhci driver,
PORTSC[PP]s' value will back to 1 automatically and VBUS on at that time,
no glitch happen and normal enumeration process has no impact.
Signed-off-by: Ran Wang
---
drivers/usb/dwc3/core.c | 47 +++
drivers/usb/dwc3/core.h | 10 +-
2 files changed, 56 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a1b126f..1508397 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -100,6 +100,41 @@ static int dwc3_get_dr_mode(struct dwc3 *dwc)
return 0;
}
+/*
+ * dwc3_power_of_all_roothub_ports - Power off all Root hub ports
+ * @dwc3: Pointer to our controller context structure
+ */
+static void dwc3_power_off_all_roothub_ports(struct dwc3 *dwc)
+{
+ int i, port_num;
+ u32 reg, op_regs_base, offset;
+ void __iomem*xhci_regs;
+
+ /* xhci regs is not mapped yet, do it temperary here */
+ if (dwc->xhci_resources[0].start) {
+ xhci_regs = ioremap(dwc->xhci_resources[0].start,
+ DWC3_XHCI_REGS_END);
+ if (IS_ERR(xhci_regs)) {
+ dev_err(dwc->dev, "Failed to ioremap xhci_regs\n");
+ return;
+ }
+
+ op_regs_base = HC_LENGTH(readl(xhci_regs));
+ reg = readl(xhci_regs + XHCI_HCSPARAMS1);
+ port_num = HCS_MAX_PORTS(reg);
+
+ for (i = 1; i <= port_num; i++) {
+ offset = op_regs_base + XHCI_PORTSC_BASE + 0x10*(i-1);
+ reg = readl(xhci_regs + offset);
+ reg &= ~PORT_POWER;
+ writel(reg, xhci_regs + offset);
+ }
+
+ iounmap(xhci_regs);
+ } else
+ dev_err(dwc->dev, "xhci base reg invalid\n");
+}
+
void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
{
u32 reg;
@@ -109,6 +144,15 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
reg |= DWC3_GCTL_PRTCAPDIR(mode);
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+ /*
+* We have to power off all Root hub ports immediately after DWC3 set
+* to host mode to avoid VBUS glitch happen when xhci get reset later.
+*/
+ if (dwc->avoid_vbus_glitch_when_set_host) {
+ if (mode == DWC3_GCTL_PRTCAP_HOST)
+ dwc3_power_off_all_roothub_ports(dwc);
+ }
+
dwc->current_dr_role = mode;
}
@@ -1306,6 +1350,9 @@ static void dwc3_get_properties(struct dwc3 *dwc)
dwc->dis_metastability_quirk = device_property_read_bool(dev,
"snps,dis_metastability_quirk");
+ dwc->avoid_vbus_glitch_when_set_host = device_property_read_bool(dev,
+ "snps,avoid-vbus-glitch-when-set-host");
+
dwc->lpm_nyet_threshold = lpm_nyet_threshold;
dwc->tx_de_emphasis = tx_de_emphasis;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index df87641..691093b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -606,6 +606,14 @@
#define DWC3_OSTS_VBUSVLD BIT(1)
#define DWC3_OSTS_CONIDSTS BIT(0)
+/* Partial XHCI Register and Bit fields for quirk */
+#define XHCI_HCSPARAMS10x4
+#define XHCI_PORTSC_BASE 0x400
+#define PORT_POWER (1 << 9)
+#define HCS_MAX_PORTS(p) (((p) >> 24) & 0x7f)
+#define XHCI_HC_LENGTH(p) (((p)>>00)&0x00ff)
+#define HC_LENGTH(p) XHCI_HC_LENGTH(p)
+
/* Structures */
struct dwc3_trb;
@@ -1209,6 +1217,7 @@ struct dwc3 {
unsignedtx_de_emphasis:2;
unsigneddis_metastability_quirk:1;
+ unsignedavoid_vbus_glitch_when_set_host:1;
u16 imod_interval;
};
@@ -1217,7 +1226,6 @@ struct dwc3 {
#define INCRX_UNDEF_LENGTH_BURST_MODE 1
#define work_to_dwc(w) (container_of((w), struct dwc3,
[PATCH 0/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset
This to fix USB enumeration compatibility issue found on DWC3 (host mode) IP only. Some pre-discussion mails can be referred from: https://lkml.org/lkml/2018/11/23/387 https://lkml.org/lkml/2018/11/22/683 As to the workaround, I know programming xhci register in DWC3 dirver (probe function) is not good from perspective of SW stack, but it seems to be the only place to fix this real existing problem (test result show that doing this in xhci-plat.c or xhci.c would not hlep on this kind of failure). If who have better idea, please let me know, thanks in advanced. Ran Wang (2): dt-bindings: Add workaround for host mode VBUS glitch when boot dwc3 core driver: Add avoiding vbus glitch happen during xhci reset Documentation/devicetree/bindings/usb/dwc3.txt |3 +++ drivers/usb/dwc3/core.c | 47 +++ drivers/usb/dwc3/core.h | 10 +- 3 files changed, 60 insertions(+), 0 deletions(-) -- 1.7.1
RE: [RESEND] arm64: defconfig: Add i.MX8MQ boot necessary configs
Hi Abel, > -Original Message- > From: Abel Vesa > Sent: Saturday, January 12, 2019 6:05 PM > Subject: [RESEND] arm64: defconfig: Add i.MX8MQ boot necessary configs > > Enable all the i.MX8MQ configs necessary to boot. > > Signed-off-by: Abel Vesa Would you rebase and resend with GPCV2 support added? Regards Dong Aisheng > --- > arch/arm64/configs/defconfig | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 0478ef9..e1d875a 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -43,6 +43,7 @@ CONFIG_ARCH_HISI=y > CONFIG_ARCH_MEDIATEK=y > CONFIG_ARCH_MESON=y > CONFIG_ARCH_MVEBU=y > +CONFIG_ARCH_MXC=y > CONFIG_ARCH_QCOM=y > CONFIG_ARCH_RENESAS=y > CONFIG_ARCH_R8A774A1=y > @@ -245,6 +246,7 @@ CONFIG_NET_XGENE=y > CONFIG_ATL1C=m > CONFIG_MACB=y > CONFIG_THUNDER_NIC_PF=y > +CONFIG_FEC=y > CONFIG_HIX5HD2_GMAC=y > CONFIG_HNS_DSAF=y > CONFIG_HNS_ENET=y > @@ -319,6 +321,8 @@ CONFIG_SERIAL_MESON_CONSOLE=y > CONFIG_SERIAL_SAMSUNG=y CONFIG_SERIAL_SAMSUNG_CONSOLE=y > CONFIG_SERIAL_TEGRA=y > +CONFIG_SERIAL_IMX=y > +CONFIG_SERIAL_IMX_CONSOLE=y > CONFIG_SERIAL_SH_SCI=y > CONFIG_SERIAL_MSM=y > CONFIG_SERIAL_MSM_CONSOLE=y > @@ -365,6 +369,7 @@ CONFIG_SPI_SPIDEV=m > CONFIG_SPMI=y > CONFIG_PINCTRL_SINGLE=y > CONFIG_PINCTRL_MAX77620=y > +CONFIG_PINCTRL_IMX8MQ=y > CONFIG_PINCTRL_IPQ8074=y > CONFIG_PINCTRL_MSM8916=y > CONFIG_PINCTRL_MSM8994=y > @@ -617,6 +622,7 @@ CONFIG_COMMON_CLK_RK808=y > CONFIG_COMMON_CLK_SCPI=y CONFIG_COMMON_CLK_CS2000_CP=y > CONFIG_COMMON_CLK_S2MPS11=y > +CONFIG_CLK_IMX8MQ=y > CONFIG_CLK_QORIQ=y > CONFIG_COMMON_CLK_PWM=y > CONFIG_TI_SCI_CLK=y > -- > 2.7.4
Re: [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent
On 1/16/19 8:36 AM, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019 at 07:30:02AM +0100, Gerd Hoffmann wrote:
>>Hi,
>>
>>> + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
>>> + DMA_BIDIRECTIONAL)) {
>>> + ret = -EFAULT;
>>> + goto fail_free_sgt;
>>> + }
>> Hmm, so it seems the arm guys could not come up with a suggestion how to
>> solve that one in a better way. Ok, lets go with this then.
>>
>> But didn't we agree that this deserves a comment exmplaining the purpose
>> of the dma_map_sg() call is to flush caches and that there is no actual
>> DMA happening here?
> Using a dma mapping call to flush caches is complete no-go. But the
> real question is why you'd even want to flush cashes if you do not
> want a dma mapping?
>
> This whole issue keeps getting more and more confusing.
Well, I don't really do DMA here, but instead the buffers in
question are shared with other Xen domain, so effectively it
could be thought of some sort of DMA here, where the "device" is
that remote domain. If the buffers are not flushed then the
remote part sees some inconsistency which in my case results
in artifacts on screen while displaying the buffers.
When buffers are allocated via DMA API then there are no artifacts;
if buffers are allocated with shmem + DMA mapping then there are no
artifacts as well.
The only offending use-case is when I use shmem backed buffers,
but do not flush them
Re: [PATCH v12 00/16] tracing: Hist trigger snapshot and onchange additions
Hi Tom,
On Tue, Jan 15, 2019 at 04:05:44PM -0600, Tom Zanussi wrote:
> From: Tom Zanussi
>
> Hi,
>
> This is v12 of the hist trigger snapshot and onchange additions
> patchset.
>
> It addresses some comments from Namhyung regarding the 'tracing: Add
> alternative synthetic event trace action syntax' patch to remove
> parens and change the documentation to emphasize the trace() form of
> the synthetic event generation command.
I got below from the following test:
# echo 'hist:key=comm:p=prio:onchange($p).snapshot()' > \
events/sched/sched_waking/trigger
# echo 1 > snapshot
Thanks,
Namhyung
[ 2217.403818] BUG: sleeping function called from invalid context at
arch/x86/mm/fault.c:1369
[ 2217.406394] in_atomic(): 0, irqs_disabled(): 1, pid: 65, name: sh
[ 2217.406394] 3 locks held by sh/65:
[ 2217.406394] #0: 6082fdb2 (sb_writers#5){.+.+}, at:
vfs_write+0x109/0x130
[ 2217.406394] #1: 3e4def73 (trace_types_lock){+.+.}, at:
tracing_snapshot_write+0x93/0x170
[ 2217.406394] #2: 50fd4c4a (>mmap_sem){}, at:
__do_page_fault+0x19a/0x4e0
[ 2217.406394] irq event stamp: 173368
[ 2217.406394] hardirqs last enabled at (173367): []
_raw_spin_unlock_irq+0x29/0x40
[ 2217.406394] hardirqs last disabled at (173368): []
tracing_snapshot_write+0xf2/0x170
[ 2217.406394] softirqs last enabled at (173258): []
__do_softirq+0x288/0x47c
[ 2217.406394] softirqs last disabled at (173253): []
irq_exit+0x62/0xa0
[ 2217.406394] CPU: 0 PID: 65 Comm: sh Not tainted 4.20.0-rc3+ #259
[ 2217.406394] Call Trace:
[ 2217.406394] dump_stack+0x67/0x90
[ 2217.406394] ___might_sleep.cold.5+0x9f/0xb1
[ 2217.406394] __do_page_fault+0x1b7/0x4e0
[ 2217.406394] page_fault+0x1e/0x30
[ 2217.406394] RIP: 0010:cond_snapshot_update+0x26/0xa0
[ 2217.406394] Code: ff ff 66 90 55 48 89 e5 41 55 41 54 53 48 8b 87 c8 16 00
00 48 8b 18 48 83 e4 f0 48 85 db 74 20 48 8b 43 50 49 89 f4 48 8b 3b <48> 8b 36
48 8b 80 e0 00 00 00 e8 1b 43 6e 00 41 89 c5 84 c0 75 11
[ 2217.406394] RSP: 0018:c9163dc0 EFLAGS: 00010082
[ 2217.406394] RAX: 88803dc07000 RBX: 88803df7b720 RCX: 8888e408
[ 2217.406394] RDX: RSI: RDI: 0078
[ 2217.406394] RBP: c9163de0 R08: R09: 0001
[ 2217.406394] R10: c9163e18 R11: 0002 R12:
[ 2217.406394] R13: R14: c9163f08 R15:
[ 2217.406394] update_max_tr+0x82/0xe0
[ 2217.406394] tracing_snapshot_write+0x15c/0x170
[ 2217.406394] __vfs_write+0x36/0x180
[ 2217.406394] ? rcu_read_lock_sched_held+0x76/0x80
[ 2217.406394] ? rcu_sync_lockdep_assert+0x2e/0x60
[ 2217.406394] ? __sb_start_write+0x14c/0x1b0
[ 2217.406394] ? vfs_write+0x109/0x130
[ 2217.406394] vfs_write+0xb7/0x130
[ 2217.406394] ksys_write+0x52/0xc0
[ 2217.406394] do_syscall_64+0x50/0x180
[ 2217.406394] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 2217.406394] RIP: 0033:0x7f9bc3170818
[ 2217.406394] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3
0f 1e fa 48 8d 05 25 6d 0d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
[ 2217.406394] RSP: 002b:7ffdef643888 EFLAGS: 0246 ORIG_RAX:
0001
[ 2217.406394] RAX: ffda RBX: 0002 RCX: 7f9bc3170818
[ 2217.406394] RDX: 0002 RSI: 5651d6bf0db0 RDI: 0001
[ 2217.406394] RBP: 5651d6bf0db0 R08: 000a R09: 7ffdef643410
[ 2217.406394] R10: 000a R11: 0246 R12: 7f9bc32435c0
[ 2217.406394] R13: 0002 R14: 7f9bc323e5c0 R15: 0002
[ 2217.406394] BUG: unable to handle kernel NULL pointer dereference at
[ 2217.406394] PGD 0 P4D 0
[ 2217.406394] Oops: [#1] SMP PTI
[ 2217.406394] CPU: 0 PID: 65 Comm: sh Tainted: GW 4.20.0-rc3+
#259
[ 2217.406394] RIP: 0010:cond_snapshot_update+0x26/0xa0
[ 2217.406394] Code: ff ff 66 90 55 48 89 e5 41 55 41 54 53 48 8b 87 c8 16 00
00 48 8b 18 48 83 e4 f0 48 85 db 74 20 48 8b 43 50 49 89 f4 48 8b 3b <48> 8b 36
48 8b 80 e0 00 00 00 e8 1b 43 6e 00 41 89 c5 84 c0 75 11
[ 2217.406394] RSP: 0018:c9163dc0 EFLAGS: 00010082
[ 2217.406394] RAX: 88803dc07000 RBX: 88803df7b720 RCX: 8888e408
[ 2217.406394] RDX: RSI: RDI: 0078
[ 2217.406394] RBP: c9163de0 R08: R09: 0001
[ 2217.406394] R10: c9163e18 R11: 0002 R12:
[ 2217.406394] R13: R14: c9163f08 R15:
[ 2217.406394] FS: 7f9bc3013b80() GS:88803e40()
knlGS:
[ 2217.406394] CS: 0010 DS: ES: CR0: 80050033
[ 2217.406394] CR2: CR3: 3d138001 CR4: 00060eb0
[ 2217.406394] Call Trace:
[ 2217.406394] update_max_tr+0x82/0xe0
[
Re: [PATCH] staging: rtl8723bs: Fix build error with Clang when inlining is disabled
On Tue, Jan 15, 2019 at 11:03:02PM -0700, Nathan Chancellor wrote:
> When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
> '-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
> Clang failed at the modpost stage:
>
> ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> undefined!
> ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
> ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> undefined!
>
> These functions were marked as extern inline, meaning that if inlining
> doesn't happen, the function will be undefined, as it is above.
>
> This happens to work with GCC because the '-fno-inline-functions' option
> respects the __inline attribute so all instances of these functions are
> inlined as expected and the definition doesn't actually matter. However,
> with Clang and '-fno-inline-functions', a function has to be marked with
> the __always_inline attribute to be considered for inlining, which none
> of these functions are. Clang tries to find the symbol definition
> elsewhere as it was told and fails, which trickles down to modpost.
>
> To make sure that this code compiles regardless of compiler and make the
> intention of the code clearer, use 'static __always_inline' to ensure
> that these functions are always inlined. Some alternative solutions
> included 'extern __always_inline' or converting these functions to
> macros (so the preprocessor deals with them) but I would argue this is
> the more "standard" solution.
>
> Signed-off-by: Nathan Chancellor
> ---
> drivers/staging/rtl8723bs/include/ieee80211.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/include/ieee80211.h
> b/drivers/staging/rtl8723bs/include/ieee80211.h
> index bcc8dfa8e672..959e822315b5 100644
> --- a/drivers/staging/rtl8723bs/include/ieee80211.h
> +++ b/drivers/staging/rtl8723bs/include/ieee80211.h
> @@ -850,18 +850,18 @@ enum ieee80211_state {
> #define IP_FMT "%pI4"
> #define IP_ARG(x) (x)
>
> -extern __inline int is_multicast_mac_addr(const u8 *addr)
> +static __always_inline int is_multicast_mac_addr(const u8 *addr)
Ick, really? This is in a .h file, the .c file sees this, so why isn't
clang picking it up? Worst case it just makes it a "normal" function
and doesn't inline it, right?
How about just replacing "extern" with "static", that should solve this,
adding "__always_inline" everywhere is not going to be fun and doesn't
make any sense.
thanks,
greg k-h
linux-next: Tree for Jan 16
Hi all, Changes since 20190115: The vfs tree still had its build failure for which I applied a patch. The drm-misc tree gained conflicts against the drm-intel tree. The mali-dp tree still had its failure for which I applied a merge fix patch. The block tree gained a conflict against the fscrypt tree and build failures for which I applied 2 merge fix patches and a fix patch. Non-merge commits (relative to Linus' tree): 1975 2069 files changed, 67760 insertions(+), 30784 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 295 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (7939f8beecf1 Merge tag 'trace-v5.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging fixes/master (0ce4e20ca4ea x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (beedd844b014 openrisc: remove unneeded code in arch/openrisc/Makefile) Merging arc-current/for-curr (5fac3149be6f ARC: adjust memblock_reserve of kernel memory) Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential uninitialized return) Merging arm64-fixes/for-next/fixes (279667212ab2 arm64: kexec_file: return successfully even if kaslr-seed doesn't exist) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (7bea7ac0ca01 powerpc/syscalls: Fix syscall tracing) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (7939f8beecf1 Merge tag 'trace-v5.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging bpf/master (86edaed37963 bpf: libbpf: retry loading program on EAGAIN) Merging ipsec/master (35e6103861a3 xfrm: refine validation of template and selector families) Merging netfilter/master (2314e879747e netfilter: nft_flow_offload: fix checking method of conntrack helper) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (bfeffd155283 Linux 5.0-rc1) Merging mac80211/master (1d51b4b1d3f2 Merge tag 'm68k-for-v4.20-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k) Merging rdma-fixes/for-rc (d6f4a21f309d RDMA/uverbs: Mark ioctl responses with UVERBS_ATTR_F_VALID_OUTPUT) Merging sound-current/for-linus (687ae9e287b3 ASoC: intel: skl: Fix display power regression) Merging sound-asoc-fixes/for-linus (906e2be2ce0e Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (b3ffce399349 Merge branch 'regmap-5.0' into regmap-linus) Merging regulator-fixes/for-linus (b4c4aa249eff Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (dd14aa37977c Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (2e8cb2cf1bd6 PCI: Fix PCI kconfig menu organization) Merging driver-core.current/driver-core-linus (1c7fc5cbc339 Linux 5.0-rc2) Merging tty.current/tty-linus (1c7fc5cbc339 Linux 5.0-rc2) Merging usb.current/usb-linus (1c7fc5cbc339 Linux 5.0-rc2) Merging usb-gadget-fixes/fixes (4a995e3496de usb: dwc2: gadget: Fix Remote Wakeup interrupt bit clearing
Re: [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent
On 1/16/19 8:30 AM, Gerd Hoffmann wrote:
>Hi,
>
>> +if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
>> +DMA_BIDIRECTIONAL)) {
>> +ret = -EFAULT;
>> +goto fail_free_sgt;
>> +}
> Hmm, so it seems the arm guys could not come up with a suggestion how to
> solve that one in a better way. Ok, lets go with this then.
>
> But didn't we agree that this deserves a comment exmplaining the purpose
> of the dma_map_sg() call is to flush caches and that there is no actual
> DMA happening here?
My bad, will add the comment
> cheers,
>Gerd
>
Thank you,
Oleksandr
Re: [PATCH 4.20 14/57] CIFS: Do not hide EINTR after sending network packets
On Tue, Jan 15, 2019 at 07:22:38PM +, Pavel Shilovskiy wrote: > Hi Greg, > > I am wondering if it is possible to include exact stable kernel > version (e.g. 4.20.3 in this case) in the email. This would help to > quickly understand which kernel version should be installed in order > to get the fix. Given that this is not in a released kernel yet, it's hard to give you a final version :) We have had times when a stable release happens while a -rc is out for review due to special circumstances, so you couldn't always rely on my email for this, as well as the fact that sometimes we drop patches from -rc releases before they are in a real release, so such an email would lie and confuse people. Just watch the kernel releases, and use git to see what commit is in what release, it's not that difficult. Especially as you are going to want to track this across multiple stable releases, so any guess I might provide here isn't going to help you out much. greg k-h
Re: [PATCH 3/9] drm/mediatek: using different flags of clk for HDMI phy
Hi, Chunhui:
On Fri, 2019-01-04 at 15:03 +0800, chunhui dai wrote:
> The parent rate of hdmi phy had set by DPI driver.
The difference of DPI driver in MT8173 and MT2701 is
static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con = 0xe0,
};
static const struct mtk_dpi_conf mt2701_conf = {
.cal_factor = mt2701_calculate_factor,
.reg_h_fre_con = 0xb0,
.edge_sel_en = true,
};
Which one influence the phy setting?
Regards,
CK
> We should not set or change the parent rate of MT2701 hdmi phy,
> as a result we should remove the flags of "CLK_SET_RATE_PARENT"
> from the clock of MT2701 hdmi phy.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 13 +
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
> drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 1 +
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index 79e737d..c0a9cf5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -109,13 +109,11 @@ static int mtk_hdmi_phy_power_off(struct phy *phy)
> return NULL;
> }
>
> -static void mtk_hdmi_phy_clk_get_ops(struct mtk_hdmi_phy *hdmi_phy,
> - const struct clk_ops **ops)
> +static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
> + struct clk_init_data *clk_init)
> {
> - if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_clk_ops)
> - *ops = hdmi_phy->conf->hdmi_phy_clk_ops;
> - else
> - dev_err(hdmi_phy->dev, "Failed to get clk ops of phy\n");
> + clk_init->flags = hdmi_phy->conf->flags;
> + clk_init->ops = hdmi_phy->conf->hdmi_phy_clk_ops;
> }
>
> static int mtk_hdmi_phy_probe(struct platform_device *pdev)
> @@ -128,7 +126,6 @@ static int mtk_hdmi_phy_probe(struct platform_device
> *pdev)
> struct clk_init_data clk_init = {
> .num_parents = 1,
> .parent_names = (const char * const *)_clk_name,
> - .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
> };
>
> struct phy *phy;
> @@ -166,7 +163,7 @@ static int mtk_hdmi_phy_probe(struct platform_device
> *pdev)
> hdmi_phy->dev = dev;
> hdmi_phy->conf =
> (struct mtk_hdmi_phy_conf *)of_device_get_match_data(dev);
> - mtk_hdmi_phy_clk_get_ops(hdmi_phy, _init.ops);
> + mtk_hdmi_phy_clk_get_data(hdmi_phy, _init);
> hdmi_phy->pll_hw.init = _init;
> hdmi_phy->pll = devm_clk_register(dev, _phy->pll_hw);
> if (IS_ERR(hdmi_phy->pll)) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index fdad8b1..446e2ac 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -21,6 +21,7 @@
>
> struct mtk_hdmi_phy_conf {
> bool tz_disabled;
> + unsigned long flags;
> const struct clk_ops *hdmi_phy_clk_ops;
> void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index 68b124f..a28a32d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -248,6 +248,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
> *hdmi_phy)
>
> struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
> .tz_disabled = true,
> + .flags = CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_GATE,
> .hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
> .hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
> .hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> index cb23c1e..63dde42 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> @@ -317,6 +317,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
> *hdmi_phy)
> }
>
> struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf = {
> + .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
> .hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
> .hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
> .hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
Re: [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent
On Wed, Jan 16, 2019 at 07:30:02AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
> > + DMA_BIDIRECTIONAL)) {
> > + ret = -EFAULT;
> > + goto fail_free_sgt;
> > + }
>
> Hmm, so it seems the arm guys could not come up with a suggestion how to
> solve that one in a better way. Ok, lets go with this then.
>
> But didn't we agree that this deserves a comment exmplaining the purpose
> of the dma_map_sg() call is to flush caches and that there is no actual
> DMA happening here?
Using a dma mapping call to flush caches is complete no-go. But the
real question is why you'd even want to flush cashes if you do not
want a dma mapping?
This whole issue keeps getting more and more confusing.
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
Linus Torvalds wrote on Wed, Jan 16, 2019:
> Anybody willing to test the above patch instead? And replace the
>
>|| capable(CAP_SYS_ADMIN)
>
> check with something like
>
>|| inode_permission(inode, MAY_WRITE) == 0
>
> instead?
>
> (This is obviously after you've reverted the "only check mmap
> residency" patch..)
That seems to work on an x86_64 vm.
I've tested with the attached patch:
- root can lookup pages on any file I tried;
- user can lookup page on file it owns, assuming it can write to it
(e.g. it won't work on a 0400 file you own)
- user cannot lookup pages on e.g. /lib64/libc-2.28.so
There is a difference with your previous patch though, that used to list
no page in core when it didn't know; this patch lists pages as in core
when it refuses to tell. I don't think that's very important, though.
If anything, the 0400 user-owner file might be a problem in some edge
case (e.g. if you're preloading git directories, many objects are 0444);
should we *also* check ownership?...
--
Dominique
mm/mincore.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/mm/mincore.c b/mm/mincore.c
index 218099b5ed31..11ed7064f4eb 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -169,6 +169,13 @@ static int mincore_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
return 0;
}
+static inline bool can_do_mincore(struct vm_area_struct *vma)
+{
+ return vma_is_anonymous(vma)
+ || (vma->vm_file && (vma->vm_file->f_mode & FMODE_WRITE))
+ || inode_permission(file_inode(vma->vm_file), MAY_WRITE) == 0;
+}
+
/*
* Do a chunk of "sys_mincore()". We've already checked
* all the arguments, we hold the mmap semaphore: we should
@@ -189,8 +196,13 @@ static long do_mincore(unsigned long addr, unsigned long pages, unsigned char *v
vma = find_vma(current->mm, addr);
if (!vma || addr < vma->vm_start)
return -ENOMEM;
- mincore_walk.mm = vma->vm_mm;
end = min(vma->vm_end, addr + (pages << PAGE_SHIFT));
+ if (!can_do_mincore(vma)) {
+ unsigned long pages = (end - addr) >> PAGE_SHIFT;
+ memset(vec, 1, pages);
+ return pages;
+ }
+ mincore_walk.mm = vma->vm_mm;
err = walk_page_range(addr, end, _walk);
if (err < 0)
return err;
Re: linux-next: Fixes tag needs some work in the nfs-anna tree
On Wed, 16 Jan 2019 00:38:11 +0100,
Paul Gortmaker wrote:
>
> [Re: linux-next: Fixes tag needs some work in the nfs-anna tree] On
> 15/01/2019 (Tue 23:12) Takashi Iwai wrote:
>
> > On Tue, 15 Jan 2019 22:41:21 +0100,
> > Chuck Lever wrote:
> > >
> > > Hi Stephen-
> > >
> > > On Jan 15, 2019, at 4:38 PM, Stephen Rothwell
> > > wrote:
> > >
> > > > [I am experimenting with checking the Fixes tags in commits in
> > > > linux-next.
> > > > Please let me know if you think I am being too strict.]
> > > >
> > > > Hi all,
> > > >
> > > > Commit
> > > >
> > > > deaa5c96c2f7 ("SUNRPC: Address Kerberos performance/behavior
> > > > regression")
> > > >
> > > > has problem with this Fixes tag:
> > > >
> > > > Fixes: 918f3c1fe83c ("SUNRPC: Improve latency for interactive ... ")
> > > >
> > > > The subject should match the subject of the fixed commit.
> > > >
> > > > --
> > > > Cheers,
> > > > Stephen Rothwell
> > >
> > > I shortened the commit title so that the Fixes: line is shorter than 68
> > > characters. I can leave these titles alone if that's preferred.
> >
> > I've sometimes shorted the subject like the above, too, as I find a
> > too long text annoying. Maybe the partial string matching should
> > suffice, especially when it ends with "..." ?
>
> The problem is consistency. Perhaps you shorten at four words. A
> person searches with five words or 70 chars - they never see your commit.
What's the reason to search for words instead of commit ID?
> The idea of consistency across the "Fixes:" tags is to allow a level of
> automated processing so that the creators of the stable releases can do
> a lot less manual hands-on processing. They have enough work to do.
Yes, I know, but the important point for stable pick-up is the
correctness of the commit ID, no?
I can understand the need for validity check of the Fixes tag,
especially to check whether the given commit ID is really correct, in
linux-next stage. But this can be verified even with a partial string
match.
thanks,
Takashi
Re: [PATCH v2] dt-bindings: net: dsa: ksz9477: fix indentation for switch spi bindings
From: Sergio Paracuellos Date: Sun, 13 Jan 2019 09:56:48 +0100 > Switch bindings for spi managed mode are using spaces instead of tabs. > Fix them to get a file with a proper kernel indentation style. > > Reviewed-by: Florian Fainelli > Signed-off-by: Sergio Paracuellos > --- > Changes in v2: > - Rebase onto net-next > - Collect previous Reviewed-by tags Applied.
Re: [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent
Hi,
> + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
> + DMA_BIDIRECTIONAL)) {
> + ret = -EFAULT;
> + goto fail_free_sgt;
> + }
Hmm, so it seems the arm guys could not come up with a suggestion how to
solve that one in a better way. Ok, lets go with this then.
But didn't we agree that this deserves a comment exmplaining the purpose
of the dma_map_sg() call is to flush caches and that there is no actual
DMA happening here?
cheers,
Gerd
Re: [PATCH net] net: phy: meson-gxl: Use the genphy_soft_reset callback
From: Timotej Lazar
Date: Sun, 13 Jan 2019 01:22:55 +0100
> Since the referenced commit, Ethernet fails to come up at boot on the
> board meson-gxl-s905x-libretech-cc. Fix this by re-enabling the
> genphy_soft_reset callback for the Amlogic Meson GXL PHY driver.
>
> Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
> Signed-off-by: Timotej Lazar
Applied and queued up for -stable.
Re: [PATCH -next] binderfs: fix error return code in binderfs_fill_super()
On Wed, Jan 16, 2019 at 07:25:46AM +0100, Christian Brauner wrote:
> On Wed, Jan 16, 2019 at 03:01:04AM +, Wei Yongjun wrote:
> > Fix to return a negative error code -ENOMEM from the new_inode() and
> > d_make_root() error handling cases instead of 0, as done elsewhere in
> > this function.
> >
> > Fixes: 3ad20fe393b3 ("binder: implement binderfs")
This Fixes tag is technically wrong since this codepath was introduced
by a commit that is still sitting in Greg's char-misc-linus branch. Not
sure how to handle that though. Might just leave it.
> > Signed-off-by: Wei Yongjun
> > ---
> > drivers/android/binderfs.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> > index 9518e2e..2bf4b2b 100644
> > --- a/drivers/android/binderfs.c
> > +++ b/drivers/android/binderfs.c
> > @@ -519,8 +519,10 @@ static int binderfs_fill_super(struct super_block *sb,
> > void *data, int silent)
> > sb->s_fs_info = info;
> >
> > inode = new_inode(sb);
> > - if (!inode)
> > + if (!inode) {
> > + ret = -ENOMEM;
>
> Hey, thanks for the patch. Just a nit:
> can you please just do?
>
> ret = -ENOMEM;
> inode = new_inode(sb);
>
> This is more consistent with how we do it everywhere else and let's us
> avoid shoving ret = -ENOMEM into two places.
>
> Thanks!
> Christian
>
> > goto err_without_dentry;
> > + }
> >
> > inode->i_ino = FIRST_INODE;
> > inode->i_fop = _dir_operations;
> > @@ -530,8 +532,10 @@ static int binderfs_fill_super(struct super_block *sb,
> > void *data, int silent)
> > set_nlink(inode, 2);
> >
> > sb->s_root = d_make_root(inode);
> > - if (!sb->s_root)
> > + if (!sb->s_root) {
> > + ret = -ENOMEM;
> > goto err_without_dentry;
> > + }
> >
> > ret = binderfs_binder_ctl_create(sb);
> > if (ret)
> >
> >
> >
Re: [PATCH -next] binderfs: fix error return code in binderfs_fill_super()
On Wed, Jan 16, 2019 at 03:01:04AM +, Wei Yongjun wrote:
> Fix to return a negative error code -ENOMEM from the new_inode() and
> d_make_root() error handling cases instead of 0, as done elsewhere in
> this function.
>
> Fixes: 3ad20fe393b3 ("binder: implement binderfs")
> Signed-off-by: Wei Yongjun
> ---
> drivers/android/binderfs.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> index 9518e2e..2bf4b2b 100644
> --- a/drivers/android/binderfs.c
> +++ b/drivers/android/binderfs.c
> @@ -519,8 +519,10 @@ static int binderfs_fill_super(struct super_block *sb,
> void *data, int silent)
> sb->s_fs_info = info;
>
> inode = new_inode(sb);
> - if (!inode)
> + if (!inode) {
> + ret = -ENOMEM;
Hey, thanks for the patch. Just a nit:
can you please just do?
ret = -ENOMEM;
inode = new_inode(sb);
This is more consistent with how we do it everywhere else and let's us
avoid shoving ret = -ENOMEM into two places.
Thanks!
Christian
> goto err_without_dentry;
> + }
>
> inode->i_ino = FIRST_INODE;
> inode->i_fop = _dir_operations;
> @@ -530,8 +532,10 @@ static int binderfs_fill_super(struct super_block *sb,
> void *data, int silent)
> set_nlink(inode, 2);
>
> sb->s_root = d_make_root(inode);
> - if (!sb->s_root)
> + if (!sb->s_root) {
> + ret = -ENOMEM;
> goto err_without_dentry;
> + }
>
> ret = binderfs_binder_ctl_create(sb);
> if (ret)
>
>
>
Re: Fix 80d20d35af1e ("nohz: Fix local_timer_softirq_pending()") may have revealed another problem
On Fri, Dec 28, 2018 at 12:11:12AM +0100, Heiner Kallweit wrote: > > # tracer: nop > # > # _-=> irqs-off > # / _=> need-resched > #| / _---=> hardirq/softirq > #|| / _--=> preempt-depth > #||| / delay > # TASK-PID CPU# TIMESTAMP FUNCTION > # | | | | | > -0 [001] d.h2 1479.099092: softirq_raise: vec=1 > [action=TIMER] > -0 [001] d.h2 1479.099098: softirq_raise: vec=9 > [action=RCU] > -0 [001] d.h2 1479.099106: softirq_raise: vec=7 > [action=SCHED] > -0 [001] ..s2 1479.099114: softirq_entry: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.099120: softirq_exit: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.099121: softirq_entry: vec=7 > [action=SCHED] > -0 [001] ..s2 1479.099134: softirq_exit: vec=7 > [action=SCHED] > -0 [001] ..s2 1479.099135: softirq_entry: vec=9 > [action=RCU] > -0 [001] ..s2 1479.099141: softirq_exit: vec=9 > [action=RCU] > -0 [001] d.h2 1479.100094: softirq_raise: vec=9 > [action=RCU] > -0 [001] ..s2 1479.100109: softirq_entry: vec=9 > [action=RCU] > -0 [001] ..s2 1479.100116: softirq_exit: vec=9 > [action=RCU] > -0 [001] d.h2 1479.101091: softirq_raise: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.101113: softirq_entry: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.101118: softirq_exit: vec=1 > [action=TIMER] > -0 [001] d.h2 1479.102094: softirq_raise: vec=9 > [action=RCU] > -0 [001] ..s2 1479.102114: softirq_entry: vec=9 > [action=RCU] > -0 [001] ..s2 1479.102121: softirq_exit: vec=9 > [action=RCU] > -0 [001] d.h2 1479.103091: softirq_raise: vec=1 > [action=TIMER] > -0 [001] d.h2 1479.103097: softirq_raise: vec=9 > [action=RCU] > -0 [001] d.h2 1479.103105: softirq_raise: vec=7 > [action=SCHED] > -0 [001] ..s2 1479.103114: softirq_entry: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.103118: softirq_exit: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.103119: softirq_entry: vec=7 > [action=SCHED] > -0 [001] ..s2 1479.103131: softirq_exit: vec=7 > [action=SCHED] > -0 [001] ..s2 1479.103132: softirq_entry: vec=9 > [action=RCU] > -0 [001] ..s2 1479.103138: softirq_exit: vec=9 > [action=RCU] > -0 [001] d.h2 1479.105092: softirq_raise: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.105115: softirq_entry: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.105119: softirq_exit: vec=1 > [action=TIMER] > -0 [001] d.h2 1479.106092: softirq_raise: vec=9 > [action=RCU] > -0 [001] ..s2 1479.106112: softirq_entry: vec=9 > [action=RCU] > -0 [001] .Ns2 1479.106144: softirq_exit: vec=9 > [action=RCU] > cpuhp/1-13[001] d..2 1479.106279: timer_cancel: > timer=09a25653 > -0 [001] d.h2 1479.106965: softirq_raise: vec=1 > [action=TIMER] > -0 [001] d.h2 1479.106969: softirq_raise: vec=9 > [action=RCU] > -0 [001] d.h2 1479.106974: softirq_raise: vec=7 > [action=SCHED] > -0 [001] ..s2 1479.106981: softirq_entry: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.106984: softirq_exit: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.106985: softirq_entry: vec=7 > [action=SCHED] > -0 [001] ..s2 1479.106994: softirq_exit: vec=7 > [action=SCHED] > -0 [001] ..s2 1479.106995: softirq_entry: vec=9 > [action=RCU] > -0 [001] ..s2 1479.106999: softirq_exit: vec=9 > [action=RCU] > -0 [001] d.h2 1479.107996: softirq_raise: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.108010: softirq_entry: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.108014: softirq_exit: vec=1 > [action=TIMER] > -0 [001] d.h2 1479.109009: softirq_raise: vec=1 > [action=TIMER] > -0 [001] d.h2 1479.109013: softirq_raise: vec=9 > [action=RCU] > -0 [001] ..s2 1479.109024: softirq_entry: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.109028: softirq_exit: vec=1 > [action=TIMER] > -0 [001] ..s2 1479.109028: softirq_entry: vec=9 > [action=RCU] > -0 [001] ..s2 1479.109033: softirq_exit: vec=9 > [action=RCU] > -0 [001] d.h2 1479.110013: softirq_raise: vec=9 > [action=RCU] > -0 [001] ..s2 1479.110033: softirq_entry: vec=9 > [action=RCU] > -0 [001] ..s2 1479.110040: softirq_exit: vec=9 > [action=RCU] > -0 [001]
[PATCH V2] mm: Introduce GFP_PGTABLE
All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
__GFP_ZERO) and using it for allocating page table pages. This causes some
code duplication which can be easily avoided. GFP_KERNEL allocated and
cleared out pages (__GFP_ZERO) are required for page tables on any given
architecture. This creates a new generic GFP flag flag which can be used
for any page table page allocation. Does not cause any functional change.
GFP_PGTABLE is being added into include/asm-generic/pgtable.h which is the
generic page tabe header just to prevent it's potential misuse as a general
allocation flag if included in include/linux/gfp.h.
Signed-off-by: Anshuman Khandual
---
Build tested on arm, arm64, powerpc, powerpc64le and x86.
Boot tested on arm64 and x86.
Changes in V2:
- Moved GFP_PGTABLE into include/asm-generic/pgtable.h
- On X86 added __GFP_ACCOUNT into GFP_PGTABLE at various places
- Replaced possible flags on riscv and nds32 with GFP_PGTABLE
Original V1: https://lkml.org/lkml/2019/1/12/54
arch/arm/include/asm/pgalloc.h | 8 +++-
arch/arm/mm/mmu.c| 2 +-
arch/arm64/include/asm/pgalloc.h | 9 -
arch/arm64/mm/mmu.c | 2 +-
arch/arm64/mm/pgd.c | 4 ++--
arch/nds32/include/asm/pgalloc.h | 3 +--
arch/powerpc/include/asm/book3s/64/pgalloc.h | 6 +++---
arch/powerpc/include/asm/pgalloc.h | 2 --
arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
arch/powerpc/mm/pgtable-frag.c | 4 ++--
arch/riscv/include/asm/pgalloc.h | 8 +++-
arch/sh/mm/pgtable.c | 6 ++
arch/unicore32/include/asm/pgalloc.h | 6 ++
arch/x86/kernel/espfix_64.c | 6 ++
arch/x86/mm/pgtable.c| 15 +++
include/asm-generic/pgtable.h| 2 ++
virt/kvm/arm/mmu.c | 2 +-
17 files changed, 37 insertions(+), 50 deletions(-)
diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
index 17ab72f..72be6f5 100644
--- a/arch/arm/include/asm/pgalloc.h
+++ b/arch/arm/include/asm/pgalloc.h
@@ -57,8 +57,6 @@ static inline void pud_populate(struct mm_struct *mm, pud_t
*pud, pmd_t *pmd)
extern pgd_t *pgd_alloc(struct mm_struct *mm);
extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
-#define PGALLOC_GFP(GFP_KERNEL | __GFP_ZERO)
-
static inline void clean_pte_table(pte_t *pte)
{
clean_dcache_area(pte + PTE_HWTABLE_PTRS, PTE_HWTABLE_SIZE);
@@ -85,7 +83,7 @@ pte_alloc_one_kernel(struct mm_struct *mm)
{
pte_t *pte;
- pte = (pte_t *)__get_free_page(PGALLOC_GFP);
+ pte = (pte_t *)__get_free_page(GFP_PGTABLE);
if (pte)
clean_pte_table(pte);
@@ -98,9 +96,9 @@ pte_alloc_one(struct mm_struct *mm)
struct page *pte;
#ifdef CONFIG_HIGHPTE
- pte = alloc_pages(PGALLOC_GFP | __GFP_HIGHMEM, 0);
+ pte = alloc_pages(GFP_PGTABLE | __GFP_HIGHMEM, 0);
#else
- pte = alloc_pages(PGALLOC_GFP, 0);
+ pte = alloc_pages(GFP_PGTABLE, 0);
#endif
if (!pte)
return NULL;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5cc1cc..6d47784 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -733,7 +733,7 @@ static void __init *early_alloc(unsigned long sz)
static void *__init late_alloc(unsigned long sz)
{
- void *ptr = (void *)__get_free_pages(PGALLOC_GFP, get_order(sz));
+ void *ptr = (void *)__get_free_pages(GFP_PGTABLE, get_order(sz));
if (!ptr || !pgtable_page_ctor(virt_to_page(ptr)))
BUG();
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 52fa47c..d5c75bf 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,14 +26,13 @@
#define check_pgt_cache() do { } while (0)
-#define PGALLOC_GFP(GFP_KERNEL | __GFP_ZERO)
#define PGD_SIZE (PTRS_PER_PGD * sizeof(pgd_t))
#if CONFIG_PGTABLE_LEVELS > 2
static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
{
- return (pmd_t *)__get_free_page(PGALLOC_GFP);
+ return (pmd_t *)__get_free_page(GFP_PGTABLE);
}
static inline void pmd_free(struct mm_struct *mm, pmd_t *pmdp)
@@ -62,7 +61,7 @@ static inline void __pud_populate(pud_t *pudp, phys_addr_t
pmdp, pudval_t prot)
static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
{
- return (pud_t *)__get_free_page(PGALLOC_GFP);
+ return (pud_t *)__get_free_page(GFP_PGTABLE);
}
static inline void pud_free(struct mm_struct *mm, pud_t *pudp)
@@ -93,7 +92,7 @@ extern void pgd_free(struct mm_struct *mm, pgd_t *pgdp);
static inline pte_t *
pte_alloc_one_kernel(struct mm_struct *mm)
{
- return (pte_t *)__get_free_page(PGALLOC_GFP);
+ return (pte_t *)__get_free_page(GFP_PGTABLE);
}
Re: [PATCH v7 2/5] mtd: spi-nor: add octal read flag for flash mt35xu512aba
On 01/15/2019 12:05 PM, Yogesh Narayan Gaur wrote:
> Add octal read flag for flash mt35xu512aba.
> This flash, mt35xu512aba, is only complaint to SFDP JESD216B and does
> not seem to support newer JESD216C standard that provides auto
> detection of Octal mode capabilities and opcodes. Therefore, this
> capability is manually added using new SPI_NOR_OCTAL_READ flag.
>
> Signed-off-by: Vignesh R
> Signed-off-by: Yogesh Narayan Gaur
Reviewed-by: Tudor Ambarus
> ---
> drivers/mtd/spi-nor/spi-nor.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 872d70722672..53a3bcc6a55b 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -1877,7 +1877,8 @@ static const struct flash_info spi_nor_ids[] = {
> /* Micron */
> {
> "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512,
> - SECT_4K | USE_FSR | SPI_NOR_4B_OPCODES)
> + SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
> + SPI_NOR_4B_OPCODES)
> },
>
> /* PMC */
>
Re: [alsa-devel] [PATCH v3 3/3] ASoC: cros_ec_codec: Add codec driver for Cros EC
On Wed, Dec 26, 2018 at 03:03:19PM +0800, Cheng-Yi Chiang wrote:
> Add a codec driver to control ChromeOS EC codec.
>
> Use EC Host command to enable/disable I2S recording and control other
> configurations.
>
> Signed-off-by: Cheng-Yi Chiang
> ---
> Changes in v3:
> 1.remove cros_ec_codec.h.
> 2.Fix error code overriding in
> set_i2s_config
> set_i2s_sample_depth
> set_bclk
> get_ec_mic_gain
> set_ec_mic_gain
> enable_i2s
> 3.Fix missing return code in cros_ec_i2s_set_dai_fmt.
> 4.Simplify return code in cros_ec_i2s_hw_params and mic_gain_put.
> 5.Remove useless debug message in cros_ec_codec_platform_probe.
>
> MAINTAINERS | 2 +
> sound/soc/codecs/Kconfig | 8 +
> sound/soc/codecs/Makefile| 2 +
> sound/soc/codecs/cros_ec_codec.c | 454 +++
> 4 files changed, 466 insertions(+)
> create mode 100644 sound/soc/codecs/cros_ec_codec.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 05e1922624e58..d66f80f3252d7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3638,8 +3638,10 @@ F: drivers/platform/chrome/
>
> CHROMEOS EC CODEC DRIVER
> M: Cheng-Yi Chiang
> +R: Enric Balletbo i Serra
> S: Maintained
> F: Documentation/devicetree/bindings/sound/google,cros-ec-codec.txt
> +F: sound/soc/codecs/cros_ec_codec.*
>
> CIRRUS LOGIC AUDIO CODEC DRIVERS
> M: Brian Austin
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index 87cb9c51e6f5a..0b36428159b71 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -50,6 +50,7 @@ config SND_SOC_ALL_CODECS
> select SND_SOC_BT_SCO
> select SND_SOC_BD28623
> select SND_SOC_CQ0093VC
> + select SND_SOC_CROS_EC_CODEC
This unconditionally selects SND_SOC_CROS_EC_CODEC, but SND_SOC_CROS_EC_CODEC
depends on MFD_CROS_EC. This is missing an "if MFD_CROS_EC" qualifier.
> select SND_SOC_CS35L32 if I2C
> select SND_SOC_CS35L33 if I2C
> select SND_SOC_CS35L34 if I2C
> @@ -457,6 +458,13 @@ config SND_SOC_CPCAP
> config SND_SOC_CQ0093VC
> tristate
>
> +config SND_SOC_CROS_EC_CODEC
> + tristate "codec driver for ChromeOS EC"
> + depends on MFD_CROS_EC
> + help
> + If you say yes here you will get support for the
> + ChromeOS Embedded Controller's Audio Codec.
> +
> config SND_SOC_CS35L32
> tristate "Cirrus Logic CS35L32 CODEC"
> depends on I2C
> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
> index 9bb3346fab2fe..3cfd8f5f61705 100644
> --- a/sound/soc/codecs/Makefile
> +++ b/sound/soc/codecs/Makefile
> @@ -42,6 +42,7 @@ snd-soc-bd28623-objs := bd28623.o
> snd-soc-bt-sco-objs := bt-sco.o
> snd-soc-cpcap-objs := cpcap.o
> snd-soc-cq93vc-objs := cq93vc.o
> +snd-soc-cros-ec-codec-objs := cros_ec_codec.o
> snd-soc-cs35l32-objs := cs35l32.o
> snd-soc-cs35l33-objs := cs35l33.o
> snd-soc-cs35l34-objs := cs35l34.o
> @@ -310,6 +311,7 @@ obj-$(CONFIG_SND_SOC_BD28623) += snd-soc-bd28623.o
> obj-$(CONFIG_SND_SOC_BT_SCO) += snd-soc-bt-sco.o
> obj-$(CONFIG_SND_SOC_CQ0093VC) += snd-soc-cq93vc.o
> obj-$(CONFIG_SND_SOC_CPCAP) += snd-soc-cpcap.o
> +obj-$(CONFIG_SND_SOC_CROS_EC_CODEC) += snd-soc-cros-ec-codec.o
> obj-$(CONFIG_SND_SOC_CS35L32)+= snd-soc-cs35l32.o
> obj-$(CONFIG_SND_SOC_CS35L33)+= snd-soc-cs35l33.o
> obj-$(CONFIG_SND_SOC_CS35L34)+= snd-soc-cs35l34.o
> diff --git a/sound/soc/codecs/cros_ec_codec.c
> b/sound/soc/codecs/cros_ec_codec.c
> new file mode 100644
> index 0..85ea23f4b681c
> --- /dev/null
> +++ b/sound/soc/codecs/cros_ec_codec.c
> @@ -0,0 +1,454 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for ChromeOS Embedded Controller codec.
> + *
> + * This driver uses the cros-ec interface to communicate with the ChromeOS
> + * EC for audio function.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_GAIN 43
Is there some reason for this magic number ? What does it reflect ?
> +
> +#define DRV_NAME "cros-ec-codec"
> +
> +/**
> + * struct cros_ec_codec_data - ChromeOS EC codec driver data.
> + * @dev: Device structure used in sysfs.
> + * @ec_device: cros_ec_device structure to talk to the physical device.
> + * @component: Pointer to the component.
> + */
> +struct cros_ec_codec_data {
> + struct device *dev;
> + struct cros_ec_device *ec_device;
> + struct snd_soc_component *component;
> +};
> +
> +static const DECLARE_TLV_DB_SCALE(ec_mic_gain_tlv, 0, 100, 0);
> +/*
> + * Wrapper for EC command.
> + */
> +static int ec_command(struct snd_soc_component *component, int version,
> + int command, u8 *outdata, int outsize,
> + u8 *indata, int insize)
> +{
> + struct cros_ec_codec_data *codec_data =
> + snd_soc_component_get_drvdata(component);
> +
[PATCH] mtd: spinand: Add support for all Toshiba Memory products
Add device table for Toshiba Memory products.
Also, generalize OOB layout structure and function names.
Signed-off-by: Yoshio Furuyama
---
drivers/mtd/nand/spi/toshiba.c | 79 +---
1 file changed, 65 insertions(+), 14 deletions(-)
diff --git a/drivers/mtd/nand/spi/toshiba.c b/drivers/mtd/nand/spi/toshiba.c
index 0812655..0916962 100644
--- a/drivers/mtd/nand/spi/toshiba.c
+++ b/drivers/mtd/nand/spi/toshiba.c
@@ -25,19 +25,19 @@ static SPINAND_OP_VARIANTS(write_cache_variants,
static SPINAND_OP_VARIANTS(update_cache_variants,
SPINAND_PROG_LOAD(false, 0, NULL, 0));
-static int tc58cvg2s0h_ooblayout_ecc(struct mtd_info *mtd, int section,
+static int tc58cxgxsx_ooblayout_ecc(struct mtd_info *mtd, int section,
struct mtd_oob_region *region)
{
- if (section > 7)
+ if (section > 0)
return -ERANGE;
- region->offset = 128 + 16 * section;
- region->length = 16;
+ region->offset = mtd->oobsize / 2;
+ region->length = mtd->oobsize / 2;
return 0;
}
-static int tc58cvg2s0h_ooblayout_free(struct mtd_info *mtd, int section,
+static int tc58cxgxsx_ooblayout_free(struct mtd_info *mtd, int section,
struct mtd_oob_region *region)
{
if (section > 0)
@@ -45,17 +45,17 @@ static int tc58cvg2s0h_ooblayout_free(struct mtd_info *mtd,
int section,
/* 2 bytes reserved for BBM */
region->offset = 2;
- region->length = 126;
+ region->length = mtd->oobsize / 2 - 2;
return 0;
}
-static const struct mtd_ooblayout_ops tc58cvg2s0h_ooblayout = {
- .ecc = tc58cvg2s0h_ooblayout_ecc,
- .free = tc58cvg2s0h_ooblayout_free,
+static const struct mtd_ooblayout_ops tc58cxgxsx_ooblayout = {
+ .ecc = tc58cxgxsx_ooblayout_ecc,
+ .free = tc58cxgxsx_ooblayout_free,
};
-static int tc58cvg2s0h_ecc_get_status(struct spinand_device *spinand,
+static int tc58cxgxsx_ecc_get_status(struct spinand_device *spinand,
u8 status)
{
struct nand_device *nand = spinand_to_nand(spinand);
@@ -94,15 +94,66 @@ static int tc58cvg2s0h_ecc_get_status(struct spinand_device
*spinand,
}
static const struct spinand_info toshiba_spinand_table[] = {
- SPINAND_INFO("TC58CVG2S0H", 0xCD,
+ /* 3.3V 1Gb */
+ SPINAND_INFO("TC58CVG0S3", 0xC2,
+NAND_MEMORG(1, 2048, 128, 64, 1024, 1, 1, 1),
+NAND_ECCREQ(8, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout,
+tc58cxgxsx_ecc_get_status)),
+ /* 3.3V 2Gb */
+ SPINAND_INFO("TC58CVG1S3", 0xCB,
+NAND_MEMORG(1, 2048, 128, 64, 2048, 1, 1, 1),
+NAND_ECCREQ(8, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout,
+tc58cxgxsx_ecc_get_status)),
+ /* 3.3V 4Gb */
+ SPINAND_INFO("TC58CVG2S0", 0xCD,
+NAND_MEMORG(1, 4096, 256, 64, 2048, 1, 1, 1),
+NAND_ECCREQ(8, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout,
+tc58cxgxsx_ecc_get_status)),
+ /* 1.8V 1Gb */
+ SPINAND_INFO("TC58CYG0S3", 0xB2,
+NAND_MEMORG(1, 2048, 128, 64, 1024, 1, 1, 1),
+NAND_ECCREQ(8, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout,
+tc58cxgxsx_ecc_get_status)),
+ /* 1.8V 2Gb */
+ SPINAND_INFO("TC58CYG1S3", 0xBB,
+NAND_MEMORG(1, 2048, 128, 64, 2048, 1, 1, 1),
+NAND_ECCREQ(8, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout,
+tc58cxgxsx_ecc_get_status)),
+ /* 1.8V 4Gb */
+ SPINAND_INFO("TC58CYG2S0", 0xBD,
NAND_MEMORG(1,
Re: [PATCH] arm64: dts: sdm845: Add lpasscc node
On Wed 05 Dec 00:00 PST 2018, Taniya Das wrote:
> This adds the low pass audio clock controller node to sdm845 based on
> the example in the bindings.
>
Applying this causes my MTP to reboot as clk_disable_unused() tries to
disable "lpass_qdsp6ss_core_clk". Am I missing something?
Regards,
Bjorn
> Signed-off-by: Taniya Das
> ---
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 4 +++-
> arch/arm64/boot/dts/qcom/sdm845.dtsi| 8
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> index b3def03..cf73f3c 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -346,7 +346,9 @@
> {
> protected-clocks = ,
> ,
> -;
> +,
> +,
> +;
> };
>
> {
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 1419b00..a3db089 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -7,6 +7,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1264,6 +1265,13 @@
> #power-domain-cells = <1>;
> };
>
> + lpasscc: clock-controller@17014000 {
> + compatible = "qcom,sdm845-lpasscc";
> + reg = <0x17014000 0x1f004>, <0x1730 0x200>;
> + reg-names = "cc", "qdsp6ss";
> + #clock-cells = <1>;
> + };
> +
> tsens0: thermal-sensor@c263000 {
> compatible = "qcom,sdm845-tsens", "qcom,tsens-v2";
> reg = <0xc263000 0x1ff>, /* TM */
> --
> Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
> of the Code Aurora Forum, hosted by the Linux Foundation.
>
Re: [PATCH v2 3/3] mtd: spi-nor: mtk-quadspi: rename config to a common one
On 01/16/2019 04:12 AM, Ryder Lee wrote: > The quadspi is a generic communication interface which could be shared > with other MediaTek SoCs. Hence rename it to a common one. > > Signed-off-by: Ryder Lee Reviewed-by: Tudor Ambarus > --- > Changes since v2: > -rebase to v5.0-rc1. > -sort the config in an alphabetical order. > > Changes since v1: none. > --- > drivers/mtd/spi-nor/Kconfig | 16 > drivers/mtd/spi-nor/Makefile | 2 +- > 2 files changed, 9 insertions(+), 9 deletions(-) > > diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig > index 44fe801..414e887 100644 > --- a/drivers/mtd/spi-nor/Kconfig > +++ b/drivers/mtd/spi-nor/Kconfig > @@ -7,14 +7,6 @@ menuconfig MTD_SPI_NOR > > if MTD_SPI_NOR > > -config MTD_MT81xx_NOR > - tristate "Mediatek MT81xx SPI NOR flash controller" > - depends on HAS_IOMEM > - help > - This enables access to SPI NOR flash, using MT81xx SPI NOR flash > - controller. This controller does not support generic SPI BUS, it only > - supports SPI NOR Flash. > - > config MTD_SPI_NOR_USE_4K_SECTORS > bool "Use small 4096 B erase sectors" > default y > @@ -66,6 +58,14 @@ config SPI_HISI_SFC > help > This enables support for hisilicon SPI-NOR flash controller. > > +config SPI_MTK_QUADSPI > + tristate "MediaTek Quad SPI controller" > + depends on HAS_IOMEM > + help > + This enables support for the Quad SPI controller in master mode. > + This controller does not support generic SPI. It only supports > + SPI NOR. > + > config SPI_NXP_SPIFI > tristate "NXP SPI Flash Interface (SPIFI)" > depends on OF && (ARCH_LPC18XX || COMPILE_TEST) > diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile > index a552efd..4e4d400 100644 > --- a/drivers/mtd/spi-nor/Makefile > +++ b/drivers/mtd/spi-nor/Makefile > @@ -4,7 +4,7 @@ obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o > obj-$(CONFIG_SPI_CADENCE_QUADSPI)+= cadence-quadspi.o > obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o > obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o > -obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o > +obj-$(CONFIG_SPI_MTK_QUADSPI)+= mtk-quadspi.o > obj-$(CONFIG_SPI_NXP_SPIFI) += nxp-spifi.o > obj-$(CONFIG_SPI_INTEL_SPI) += intel-spi.o > obj-$(CONFIG_SPI_INTEL_SPI_PCI) += intel-spi-pci.o >
Re: [PATCH v2 2/3] mtd: spi-nor: mtk-quadspi: add SNOR_HWCAPS_READ to spi_nor_hwcaps mask
On 01/16/2019 04:12 AM, Ryder Lee wrote:
> From: Guochun Mao
>
> SNOR_HWCAPS_READ should be supported by this controller, so add this
> flag to spi_nor_hwcaps mask.
>
> Signed-off-by: Guochun Mao
> Signed-off-by: Ryder Lee
Reviewed-by: Tudor Ambarus
> ---
> Changes since v2: Revise commit msg.
> Changes since v1: none.
> ---
> drivers/mtd/spi-nor/mtk-quadspi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
> b/drivers/mtd/spi-nor/mtk-quadspi.c
> index 5442993..d9eed68 100644
> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> @@ -431,7 +431,8 @@ static int mtk_nor_init(struct mtk_nor *mtk_nor,
> struct device_node *flash_node)
> {
> const struct spi_nor_hwcaps hwcaps = {
> - .mask = SNOR_HWCAPS_READ_FAST |
> + .mask = SNOR_HWCAPS_READ |
> + SNOR_HWCAPS_READ_FAST |
> SNOR_HWCAPS_READ_1_1_2 |
> SNOR_HWCAPS_PP,
> };
>
[PATCH] staging: rtl8723bs: Fix build error with Clang when inlining is disabled
When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
'-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
Clang failed at the modpost stage:
ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
These functions were marked as extern inline, meaning that if inlining
doesn't happen, the function will be undefined, as it is above.
This happens to work with GCC because the '-fno-inline-functions' option
respects the __inline attribute so all instances of these functions are
inlined as expected and the definition doesn't actually matter. However,
with Clang and '-fno-inline-functions', a function has to be marked with
the __always_inline attribute to be considered for inlining, which none
of these functions are. Clang tries to find the symbol definition
elsewhere as it was told and fails, which trickles down to modpost.
To make sure that this code compiles regardless of compiler and make the
intention of the code clearer, use 'static __always_inline' to ensure
that these functions are always inlined. Some alternative solutions
included 'extern __always_inline' or converting these functions to
macros (so the preprocessor deals with them) but I would argue this is
the more "standard" solution.
Signed-off-by: Nathan Chancellor
---
drivers/staging/rtl8723bs/include/ieee80211.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/ieee80211.h
b/drivers/staging/rtl8723bs/include/ieee80211.h
index bcc8dfa8e672..959e822315b5 100644
--- a/drivers/staging/rtl8723bs/include/ieee80211.h
+++ b/drivers/staging/rtl8723bs/include/ieee80211.h
@@ -850,18 +850,18 @@ enum ieee80211_state {
#define IP_FMT "%pI4"
#define IP_ARG(x) (x)
-extern __inline int is_multicast_mac_addr(const u8 *addr)
+static __always_inline int is_multicast_mac_addr(const u8 *addr)
{
return ((addr[0] != 0xff) && (0x01 & addr[0]));
}
-extern __inline int is_broadcast_mac_addr(const u8 *addr)
+static __always_inline int is_broadcast_mac_addr(const u8 *addr)
{
return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) &&
\
(addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff));
}
-extern __inline int is_zero_mac_addr(const u8 *addr)
+static __always_inline int is_zero_mac_addr(const u8 *addr)
{
return ((addr[0] == 0x00) && (addr[1] == 0x00) && (addr[2] == 0x00) &&
\
(addr[3] == 0x00) && (addr[4] == 0x00) && (addr[5] == 0x00));
--
2.20.1
Re: [GIT PULL] SELinux fixes for v5.0 (#1)
The pull request you sent on Tue, 15 Jan 2019 17:24:58 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git > tags/selinux-pr-20190115 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/47bfa6d9dc8c060bf56554a465c9031e286d2f80 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Wed, Jan 16, 2019 at 5:46 PM Dominique Martinet wrote: > > "Being owner or has cap" (whichever cap) is probably OK. > On the other hand, writeability check makes more sense in general - > could we somehow check if the user has write access to the file instead > of checking if it currently is opened read-write? That's likely the best option. We could say "is it open for write, or _could_ we open it for writing?" It's a slightly annoying special case, and I'd have preferred to avoid it, but it doesn't sound *compilcated*. I'm on the road, but I did send out this: https://lore.kernel.org/lkml/CAHk-=wif_9nvnhjiyxhzj80_wub0p7cxnbvxkjzz-r1u0oz...@mail.gmail.com/ originally. The "let's try to only do the mmap residency" was the optimistic "maybe we can just get rid of this complexity entirely" version.. Anybody willing to test the above patch instead? And replace the || capable(CAP_SYS_ADMIN) check with something like || inode_permission(inode, MAY_WRITE) == 0 instead? (This is obviously after you've reverted the "only check mmap residency" patch..) Linus
Re: [PATCH v11 0/9] Add power domain driver for corners on msm8996/sdm845
On Wed 09 Jan 22:33 PST 2019, Viresh Kumar wrote: > +Rafael > > On 10-01-19, 09:32, Rajendra Nayak wrote: > > Changes in v11: > > * Updated opp-level binding description based on feedback > > from Viresh > > * Other minor fixups in 'PATCH 2/9' > > > Documentation/devicetree/bindings/opp/opp.txt | 3 + > > .../devicetree/bindings/power/qcom,rpmpd.txt | 145 +++ > > arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 ++ > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 51 +++ > > drivers/opp/core.c| 18 + > > drivers/opp/of.c | 2 + > > drivers/opp/opp.h | 2 + > > drivers/soc/qcom/Kconfig | 18 + > > drivers/soc/qcom/Makefile | 2 + > > drivers/soc/qcom/rpmhpd.c | 402 ++ > > drivers/soc/qcom/rpmpd.c | 317 ++ > > include/dt-bindings/power/qcom-rpmpd.h| 39 ++ > > include/linux/pm_opp.h| 7 + > > 13 files changed, 1040 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt > > create mode 100644 drivers/soc/qcom/rpmhpd.c > > create mode 100644 drivers/soc/qcom/rpmpd.c > > create mode 100644 include/dt-bindings/power/qcom-rpmpd.h > > Rafael/Ulf: Who should pick this series ? Should I take this via OPP > tree ? > Given that the weight of the patches lies in arm-soc area it could be favourable to just take them that way, with the one opp-patch carrying your (Rafael's?) ack. If you prefer otherwise, I suggest that we take patch 6 and 8 (the two dts patches) through arm-soc and you merge the rest in your tree. Regards, Bjorn
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Wed, Jan 16, 2019 at 4:54 PM Linus Torvalds wrote: > > On Wed, Jan 16, 2019 at 11:45 AM Dave Chinner wrote: > > > > I'm assuming that you can invalidate the page cache reliably by a > > means that does not repeated require probing to detect invalidation > > has occurred. I've mentioned one method in this discussion > > already... > > Yes. And it was made clear to you that it was a bug in xfs dio and > what the right thing to do was. Side note: I actually think we *do* the right thing. Even for xfs. I couldn't find the alleged place that invalidates the page cache on dio reads. The *generic* dio code only does it for writes (which is correct and fine). And maybe xfs has some extra invalidation, but I don't see it. So I actually hope your "you can use direct-io read to do directed invalidating of the page cache" isn't true. I admittedly did *not* try to delve very deeply into it, but the invalidates I found looked correct. The generic code does it for writes, and at least ext4 does the "writeback and wait" for reads. There *does* seem to be a 'invalidate_inode_pages2_range()' call in iomap_dio_rw(). That has a *comment* that says it only is for writes, but it looks to me like it would trigger for reads too. Just a plain bug/oversight? Or me misreading things. So yes, maybe xfs does that "invalidate on read", but it really seems to be just a bug. If the xfs people insist on keeping the bug, fine (looks like gfs2 and xfs are the only users), but it seems kind of sad. Linus
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
Linus Torvalds wrote on Wed, Jan 16, 2019: > *Very* few people want to run their databases as root. In the case of happycache, this isn't the database doing the dump/restore, but a separate process that could have the cap - it's better if we can do without though, and from his readme he runs as user cassandra in the /var/lib/cassandra directory for example so that'd match the file owner. For pgfincore, it's a postgres extension so the main process does it - but it does have files open as write as well as being the owner. > Jiri's original patch kind of acknowledged that by making the new test > be conditional, and off by default. So then it's a "only do this for > lockdown mode, because normal people won't find it acceptable". > > And I'm not a huge fan of that approach. If you don't protect normal > people, then what's the point, really? I agree with that. "Being owner or has cap" (whichever cap) is probably OK. On the other hand, writeability check makes more sense in general - could we somehow check if the user has write access to the file instead of checking if it currently is opened read-write? -- Dominique
Re: [PATCH -next] LSM: Make some functions static
Pls ignore this duplicated patch.
On 2019/1/16 13:33, YueHaibing wrote:
> Fix the follow sparse warning:
>
> security/security.c:533:5: warning: symbol 'lsm_task_alloc' was not declared.
> Should it be static?
> security/security.c:554:5: warning: symbol 'lsm_ipc_alloc' was not declared.
> Should it be static?
> security/security.c:575:5: warning: symbol 'lsm_msg_msg_alloc' was not
> declared. Should it be static?
>
> Signed-off-by: YueHaibing
> ---
> security/security.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/security/security.c b/security/security.c
> index 9a98c52..750d3f3 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -530,7 +530,7 @@ int lsm_inode_alloc(struct inode *inode)
> *
> * Returns 0, or -ENOMEM if memory can't be allocated.
> */
> -int lsm_task_alloc(struct task_struct *task)
> +static int lsm_task_alloc(struct task_struct *task)
> {
> if (blob_sizes.lbs_task == 0) {
> task->security = NULL;
> @@ -551,7 +551,7 @@ int lsm_task_alloc(struct task_struct *task)
> *
> * Returns 0, or -ENOMEM if memory can't be allocated.
> */
> -int lsm_ipc_alloc(struct kern_ipc_perm *kip)
> +static int lsm_ipc_alloc(struct kern_ipc_perm *kip)
> {
> if (blob_sizes.lbs_ipc == 0) {
> kip->security = NULL;
> @@ -572,7 +572,7 @@ int lsm_ipc_alloc(struct kern_ipc_perm *kip)
> *
> * Returns 0, or -ENOMEM if memory can't be allocated.
> */
> -int lsm_msg_msg_alloc(struct msg_msg *mp)
> +static int lsm_msg_msg_alloc(struct msg_msg *mp)
> {
> if (blob_sizes.lbs_msg_msg == 0) {
> mp->security = NULL;
>
[PATCH -next] LSM: Make some functions static
Fix the follow sparse warning:
security/security.c:533:5: warning: symbol 'lsm_task_alloc' was not declared.
Should it be static?
security/security.c:554:5: warning: symbol 'lsm_ipc_alloc' was not declared.
Should it be static?
security/security.c:575:5: warning: symbol 'lsm_msg_msg_alloc' was not
declared. Should it be static?
Signed-off-by: YueHaibing
---
security/security.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/security/security.c b/security/security.c
index 9a98c52..750d3f3 100644
--- a/security/security.c
+++ b/security/security.c
@@ -530,7 +530,7 @@ int lsm_inode_alloc(struct inode *inode)
*
* Returns 0, or -ENOMEM if memory can't be allocated.
*/
-int lsm_task_alloc(struct task_struct *task)
+static int lsm_task_alloc(struct task_struct *task)
{
if (blob_sizes.lbs_task == 0) {
task->security = NULL;
@@ -551,7 +551,7 @@ int lsm_task_alloc(struct task_struct *task)
*
* Returns 0, or -ENOMEM if memory can't be allocated.
*/
-int lsm_ipc_alloc(struct kern_ipc_perm *kip)
+static int lsm_ipc_alloc(struct kern_ipc_perm *kip)
{
if (blob_sizes.lbs_ipc == 0) {
kip->security = NULL;
@@ -572,7 +572,7 @@ int lsm_ipc_alloc(struct kern_ipc_perm *kip)
*
* Returns 0, or -ENOMEM if memory can't be allocated.
*/
-int lsm_msg_msg_alloc(struct msg_msg *mp)
+static int lsm_msg_msg_alloc(struct msg_msg *mp)
{
if (blob_sizes.lbs_msg_msg == 0) {
mp->security = NULL;
--
2.7.0
[PATCH -next] soc: bcm: bcm2835-pm: Make local symbol static
Fixes the following sparse warning:
drivers/soc/bcm/bcm2835-power.c:556:32: warning:
symbol 'bcm2835_reset_ops' was not declared. Should it be static?
Fixes: 670c672608a1 ("soc: bcm: bcm2835-pm: Add support for power domains under
a new binding.")
Signed-off-by: Wei Yongjun
---
drivers/soc/bcm/bcm2835-power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/bcm/bcm2835-power.c b/drivers/soc/bcm/bcm2835-power.c
index 4841295..9351349 100644
--- a/drivers/soc/bcm/bcm2835-power.c
+++ b/drivers/soc/bcm/bcm2835-power.c
@@ -553,7 +553,7 @@ static int bcm2835_reset_status(struct reset_controller_dev
*rcdev,
}
}
-const struct reset_control_ops bcm2835_reset_ops = {
+static const struct reset_control_ops bcm2835_reset_ops = {
.reset = bcm2835_reset_reset,
.status = bcm2835_reset_status,
};
Re: [PATCH net] Revert "rxrpc: Allow failed client calls to be retried"
From: David Howells Date: Thu, 10 Jan 2019 16:59:13 + > The changes introduced to allow rxrpc calls to be retried creates an issue > when it comes to refcounting afs_call structs. The problem is that when > rxrpc_send_data() queues the last packet for an asynchronous call, the > following sequence can occur: ... > Synchronising the clean up after rxrpc_kernel_send_data() returns an error > with the asynchronous cleanup is then tricky to get right. > > Mostly revert commit c038a58ccfd6704d4d7d60ed3d6a0fca13cf13a4. The two API > functions the original commit added aren't currently used. This makes > rxrpc_kernel_send_data() always return successfully if it queued the data > it was given. > > Note that this doesn't affect synchronous calls since their Rx notification > function merely pokes a wait queue and does not refcounting. The > asynchronous call notification function *has* to do refcounting and pass a > ref over the work item to avoid the need to sync the workqueue in call > cleanup. > > Signed-off-by: David Howells Applied.
Re: [PATCH -next] drm/vmwgfx: Remove set but not used variable 'srf'
Yue,
Thanks,
Reviewed-by: Thomas Hellstrom
Will include in the next -next pull.
/Thomas
On Wed, 2019-01-16 at 01:55 +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c: In function
> 'vmw_hw_surface_destroy':
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:335:22: warning:
> variable 'srf' set but not used [-Wunused-but-set-variable]
>
> It never used since commit 543831cfc976 ï¼^"drm/vmwgfx: Break out
> surface and
> context management to separate files")
>
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index 80a01cd..3b6976e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -332,7 +332,6 @@ static void vmw_hw_surface_destroy(struct
> vmw_resource *res)
> {
>
> struct vmw_private *dev_priv = res->dev_priv;
> - struct vmw_surface *srf;
> void *cmd;
>
> if (res->func->destroy == vmw_gb_surface_destroy) {
> @@ -359,7 +358,6 @@ static void vmw_hw_surface_destroy(struct
> vmw_resource *res)
>*/
>
> mutex_lock(_priv->cmdbuf_mutex);
> - srf = vmw_res_to_srf(res);
> dev_priv->used_memory_size -= res->backup_size;
> mutex_unlock(_priv->cmdbuf_mutex);
> }
>
>
>
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Wed, Jan 16, 2019 at 5:25 PM Andy Lutomirski wrote: > > Something like CAP_DAC_READ_SEARCH might not be crazy. I agree that it would work. In fact' it's what Jiri's patch basically did. Except Jiri used CAP_SYS_ADMIN instead. But that then basically limits it to root (or root-like with capability masks), which is quite likely to not work in practice all that well. That's why I wanted to find alternatives. *Very* few people want to run their databases as root. Jiri's original patch kind of acknowledged that by making the new test be conditional, and off by default. So then it's a "only do this for lockdown mode, because normal people won't find it acceptable". And I'm not a huge fan of that approach. If you don't protect normal people, then what's the point, really? Linus
[PATCH] ipmi: fix use-after-free of user->release_barrier.rda
When we do the following test, we got oops in ipmi_msghandler driver
while((1))
do
service ipmievd restart & service ipmievd restart
done
---
[ 294.230186] Unable to handle kernel paging request at virtual address
803fea6ea008
[ 294.230188] Mem abort info:
[ 294.230190] ESR = 0x9604
[ 294.230191] Exception class = DABT (current EL), IL = 32 bits
[ 294.230193] SET = 0, FnV = 0
[ 294.230194] EA = 0, S1PTW = 0
[ 294.230195] Data abort info:
[ 294.230196] ISV = 0, ISS = 0x0004
[ 294.230197] CM = 0, WnR = 0
[ 294.230199] user pgtable: 4k pages, 48-bit VAs, pgdp = a1c1b75a
[ 294.230201] [803fea6ea008] pgd=
[ 294.230204] Internal error: Oops: 9604 [#1] SMP
[ 294.235211] Modules linked in: nls_utf8 isofs rpcrdma ib_iser ib_srpt
target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_umad rdma_cm
ib_cm iw_cm dm_mirror dm_region_hash dm_log dm_mod aes_ce_blk crypto_simd
cryptd aes_ce_cipher ghash_ce sha2_ce ses sha256_arm64 sha1_ce hibmc_drm
hisi_sas_v2_hw enclosure sg hisi_sas_main sbsa_gwdt ip_tables mlx5_ib ib_uverbs
marvell ib_core mlx5_core ixgbe ipmi_si mdio hns_dsaf ipmi_devintf
ipmi_msghandler hns_enet_drv hns_mdio
[ 294.277745] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted
5.0.0-rc2+ #113
[ 294.285511] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.37
11/21/2017
[ 294.292835] pstate: 8005 (Nzcv daif -PAN -UAO)
[ 294.297695] pc : __srcu_read_lock+0x38/0x58
[ 294.301940] lr : acquire_ipmi_user+0x2c/0x70 [ipmi_msghandler]
[ 294.307853] sp : 1001bc80
[ 294.311208] x29: 1001bc80 x28: 117e5000
[ 294.316594] x27: x26: dead0100
[ 294.321980] x25: dead0200 x24: 803f6bd06800
[ 294.327366] x23: x22:
[ 294.332752] x21: 1001bd04 x20: 80df33d19018
[ 294.338137] x19: 80df33d19018 x18:
[ 294.343523] x17: x16:
[ 294.348908] x15: x14: 0002
[ 294.354293] x13: x12:
[ 294.359679] x11: x10: 0010
[ 294.365065] x9 : x8 : 0004
[ 294.370451] x7 : x6 : 80df34558678
[ 294.375836] x5 : 000c x4 :
[ 294.381221] x3 : 0001 x2 : 803fea6ea000
[ 294.386607] x1 : 803fea6ea008 x0 : 0001
[ 294.391994] Process swapper/3 (pid: 0, stack limit = 0x83087293)
[ 294.398791] Call trace:
[ 294.401266] __srcu_read_lock+0x38/0x58
[ 294.405154] acquire_ipmi_user+0x2c/0x70 [ipmi_msghandler]
[ 294.410716] deliver_response+0x80/0xf8 [ipmi_msghandler]
[ 294.416189] deliver_local_response+0x28/0x68 [ipmi_msghandler]
[ 294.422193] handle_one_recv_msg+0x158/0xcf8 [ipmi_msghandler]
[ 294.432050] handle_new_recv_msgs+0xc0/0x210 [ipmi_msghandler]
[ 294.441984] smi_recv_tasklet+0x8c/0x158 [ipmi_msghandler]
[ 294.451618] tasklet_action_common.isra.5+0x88/0x138
[ 294.460661] tasklet_action+0x2c/0x38
[ 294.468191] __do_softirq+0x120/0x2f8
[ 294.475561] irq_exit+0x134/0x140
[ 294.482445] __handle_domain_irq+0x6c/0xc0
[ 294.489954] gic_handle_irq+0xb8/0x178
[ 294.497037] el1_irq+0xb0/0x140
[ 294.503381] arch_cpu_idle+0x34/0x1a8
[ 294.510096] do_idle+0x1d4/0x290
[ 294.516322] cpu_startup_entry+0x28/0x30
[ 294.523230] secondary_start_kernel+0x184/0x1d0
[ 294.530657] Code: d538d082 d2800023 8b010c81 8b020021 (c85f7c25)
[ 294.539746] ---[ end trace 8a7a880dee570b29 ]---
[ 294.547341] Kernel panic - not syncing: Fatal exception in interrupt
[ 294.556837] SMP: stopping secondary CPUs
[ 294.563996] Kernel Offset: disabled
[ 294.570515] CPU features: 0x002,21006008
[ 294.577638] Memory Limit: none
[ 294.587178] Starting crashdump kernel...
[ 294.594314] Bye!
Because the user->release_barrier.rda is freed in ipmi_destroy_user(), but
the refcount is not zero, when acquire_ipmi_user() uses
user->release_barrier.rda
in __srcu_read_lock(), it causes oops.
Fix this by calling cleanup_srcu_struct() when the refcount is zero.
Fixes: e86ee2d44b44 ("ipmi: Rework locking and shutdown for hot remove")
Cc: sta...@vger.kernel.org
Signed-off-by: Yang Yingliang
---
drivers/char/ipmi/ipmi_msghandler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/ipmi/ipmi_msghandler.c
b/drivers/char/ipmi/ipmi_msghandler.c
index a74ce88..6c26533 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -1183,6 +1183,7 @@ int ipmi_get_smi_info(int if_num, struct ipmi_smi_info
*data)
static void free_user(struct kref *ref)
{
struct ipmi_user *user = container_of(ref, struct ipmi_user, refcount);
+ cleanup_srcu_struct(>release_barrier);
kfree(user);
}
@@ -1259,7 +1260,6 @@ int ipmi_destroy_user(struct
[PATCH] m68k: Add -ffreestanding to CFLAGS
This patch fixes a build failure when using GCC 8.1: /usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock': block/partitions/ldm.c:153: undefined reference to `strcmp' This is caused by a new optimization which effectively replaces a strncmp() call with a strcmp() call. This affects a number of strncmp() call sites in the kernel. The entire class of optimizations is avoided with -fno-builtin, which gets enabled by -ffreestanding. This may avoid possible future build failures in case new optimizations appear in future compilers. I haven't done any performance measurements with this patch but I did count the function calls in a defconfig build. For example, there are now 23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the other libc functions is smaller. If this harms performance we can tackle that regression by optimizing the call sites, ideally using semantic patches. That way, clang and ICC builds might benfit too. Cc: sta...@vger.kernel.org Reference: https://marc.info/?l=linux-m68k=15451481644=2 Signed-off-by: Finn Thain --- arch/m68k/Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index 997c9f20ea0f..0a99c276d9a4 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -58,7 +58,8 @@ cpuflags-$(CONFIG_M5206e) := $(call cc-option,-mcpu=5206e,-m5200) cpuflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200) KBUILD_AFLAGS += $(cpuflags-y) -KBUILD_CFLAGS += $(cpuflags-y) -pipe +KBUILD_CFLAGS += $(cpuflags-y) + ifdef CONFIG_MMU # without -fno-strength-reduce the 53c7xx.c driver fails ;-( KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2 @@ -69,6 +70,8 @@ KBUILD_CFLAGS += -D__uClinux__ KBUILD_AFLAGS += -D__uClinux__ endif +KBUILD_CFLAGS += -pipe -ffreestanding + KBUILD_LDFLAGS := -m m68kelf KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds -- 2.19.2
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
> On Jan 15, 2019, at 9:00 PM, Linus Torvalds > wrote: > >> On Wed, Jan 16, 2019 at 12:42 PM Josh Snyder wrote: >> >> For Netflix, losing accurate information from the mincore syscall would >> lengthen database cluster maintenance operations from days to months. We >> rely on cross-process mincore to migrate the contents of a page cache from >> machine to machine, and across reboots. > > Ok, this is the kind of feedback we need, and means I guess we can't > just use the mapping existence for mincore. > > The two other ways that we considered were: > > (a) owner of the file gets to know cache information for that file. > > (b) having the fd opened *writably* gets you cache residency information. > > Sadly, taking a look at happycache, you open the file read-only, so > (b) doesn't work. > > Judging just from the source code, I can't tell how the user ownership > works. Any input on that? > > And if you're not the owner of the file, do you have another > suggestion for that "Yes, I have the right to see what's in-core for > this file". Because the problem is literally that if it's some random > read-only system file, the kernel shouldn't leak access patterns to > it.. > > Something like CAP_DAC_READ_SEARCH might not be crazy.
Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
On Wed, Jan 16, 2019 at 11:32 AM Dave Young wrote:
>
> On 01/16/19 at 12:10am, Borislav Petkov wrote:
> > On Tue, Jan 15, 2019 at 05:58:34PM +0800, Kairui Song wrote:
> > > When efi=noruntime or efi=oldmap is used, EFI services won't be available
> > > in the second kernel, therefore the second kernel will not be able to get
> > > the ACPI RSDP address from firmware by calling EFI services and won't
> > > boot. Previously we are expecting the user to set the acpi_rsdp=
> > > on kernel command line for second kernel as there was no way to pass RSDP
> > > address to second kernel.
> > >
> > > After commit e6e094e053af ('x86/acpi, x86/boot: Take RSDP address from
> > > boot params if available'), now it's possible to set an acpi_rsdp_addr
> > > parameter in the boot_params passed to second kernel, this commit make
> > > use of it, detect and set the RSDP address when it's required for second
> > > kernel to boot.
> > >
> > > Tested with an EFI enabled KVM VM with efi=noruntime.
> > >
> > > Suggested-by: Dave Young
> > > Signed-off-by: Kairui Song
> > > ---
> > > arch/x86/kernel/kexec-bzimage64.c | 21 +
> > > drivers/acpi/acpica/tbxfroot.c| 3 +--
> > > include/acpi/acpixf.h | 2 +-
> > > 3 files changed, 23 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/x86/kernel/kexec-bzimage64.c
> > > b/arch/x86/kernel/kexec-bzimage64.c
> > > index 53917a3ebf94..0a90dcbd041f 100644
> > > --- a/arch/x86/kernel/kexec-bzimage64.c
> > > +++ b/arch/x86/kernel/kexec-bzimage64.c
> > > @@ -20,6 +20,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > > #include
> > > @@ -255,8 +256,28 @@ setup_boot_parameters(struct kimage *image, struct
> > > boot_params *params,
> > > /* Setup EFI state */
> > > setup_efi_state(params, params_load_addr, efi_map_offset, efi_map_sz,
> > > efi_setup_data_offset);
> > > +
> > > +#ifdef CONFIG_ACPI
> > > + /* Setup ACPI RSDP pointer in case EFI is not available in second
> > > kernel */
> > > + if (!acpi_disabled && (!efi_enabled(EFI_RUNTIME_SERVICES) ||
> > > efi_enabled(EFI_OLD_MEMMAP))) {
> > > + /* Copied from acpi_os_get_root_pointer accordingly */
> > > + params->acpi_rsdp_addr = boot_params.acpi_rsdp_addr;
> > > + if (!params->acpi_rsdp_addr) {
> > > + if (efi_enabled(EFI_CONFIG_TABLES)) {
> > > + if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> > > + params->acpi_rsdp_addr = efi.acpi20;
> > > + else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> > > + params->acpi_rsdp_addr = efi.acpi;
> > > + } else if
> > > (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
> > > +
> > > acpi_find_root_pointer(>acpi_rsdp_addr);
> > > + }
> > > + }
> > > + if (!params->acpi_rsdp_addr)
> > > + pr_warn("RSDP is not available for second kernel\n");
> > > + }
> > > #endif
> >
> > Amazing the amount of ACPI RDSP parsing and fiddling patches flying
> > around these days...
> >
> > In any case, this needs to be synchronized with:
> >
> > https://lkml.kernel.org/r/20190107032243.25324-1-fanc.f...@cn.fujitsu.com
> >
> > and checked whether the above can be used instead of sprinkling of ACPI
> > parsing code left and right.
>
> Both Baoquan and Chao are cced for comments.
> The above KASLR patches seems some early code to parsing acpi, but I think in
> this
> patch just call acpi function to get the root pointer no need to add the
> duplicate logic of if/else/else if.
>
> Kairui, do you have any reason for the checking? Is there some simple
> acpi function to just return the root pointer?
Hi, I'm afraid that would require moving multiple structure and
function out of .init,
acpi_os_get_root_pointer is an ideal function to do the job, but it's
in .init and (on x86) it will call x86_init.acpi.get_root_pointer (by
calling acpi_arch_get_root_pointer) which will also be freed after
init, unless I change the x86_init, move they out of .init which is
not a good idea.
Maybe I could split acpi_os_get_root_pointer into two, one gets freed
after init, one for later use. But the "acpi_rsdp_addr" trick only
works for x86, and this would change more common acpi driver code so
not sure if a good idea.
>
> >
> > Thx.
> >
> > --
> > Regards/Gruss,
> > Boris.
> >
> > Good mailing practices for 400: avoid top-posting and trim the reply.
>
> Thanks
> Dave
--
Best Regards,
Kairui Song
[PATCH 0/3] Remove self-implemented queue of Mediatek cmdq
Mediatek mailbox controller implement its own data queue rather than using mailbox framework's queue. This series let the framework provide abort function and Mediatek mailbox controller implement the abort-function, so it could use framework's queue. The reason that Mediatek mailbox controller has to implement its own queue: One client of Mediatek mailbox controller is display driver. When a cursor is moving, display continuously update the register related to the cursor. Display hardware has a limitation that register should be updated in the vblank period which is a small interval. In tradition, display hardware would trigger an interrupt when vblank start, and driver could update register in this irq handler. But the interrupt handler has the risk that it could be delayed by some reason so the handler may be postponed out of this vblank interval. In order to reduce the risk, display driver use GCE hardware to write register. If a cursor move 3 times before vblank, display driver would send 3 messages sequentially to mailbox controller. If the controller use framework's queue, controller just receive the first message and the others is queued in framework. The first message could be executed exactly in vblank interval but the other messages are sent to controller when controller notify framework tx_done in interrupt handler. The interrupt may be postponed by some reason this is what we worried. So Mediatek mailbox controller has to implement its own queue to make sure that all message execute in vblank interval. The reason that abort-function could let Mediatek mailbox controller use framework's queue: The primary concept is to let display driver send at most one message to mailbox controller. When it need to send the second message before the first message is done, it should abort the first message and then send the second message which should merge the first message. For other client driver, it could still send multiple messages into framework's queue. CK Hu (3): mailbox: Add ability for clients to abort data in channel mailbox: mediatek: Implement abort_data function. mailbox: mediatek: Remove busylist drivers/mailbox/mailbox.c | 23 +++ drivers/mailbox/mtk-cmdq-mailbox.c | 281 +++-- include/linux/mailbox_client.h | 1 + include/linux/mailbox_controller.h | 4 + 4 files changed, 90 insertions(+), 219 deletions(-) -- 2.18.0
[PATCH 2/3] mailbox: mediatek: Implement abort_data function.
For client driver which need to reorganize the command buffer, it could
use this function to abort the sent but not executed command buffer.
Signed-off-by: CK Hu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 40 ++
1 file changed, 40 insertions(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 22811784dc7d..f2219f263ef6 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -417,6 +417,45 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan,
void *data)
return 0;
}
+static void cmdq_mbox_abort_data(struct mbox_chan *chan)
+{
+ struct cmdq_thread *thread = (struct cmdq_thread *)chan->con_priv;
+ struct cmdq *cmdq = dev_get_drvdata(chan->mbox->dev);
+ struct cmdq_task *task, *tmp;
+ unsigned long flags;
+ u32 enable;
+
+ spin_lock_irqsave(>chan->lock, flags);
+ if (list_empty(>task_busy_list))
+ goto out;
+
+ WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
+ if (!cmdq_thread_is_in_wfe(thread))
+ goto wait;
+
+ list_for_each_entry_safe(task, tmp, >task_busy_list,
+list_entry) {
+ list_del(>list_entry);
+ kfree(task);
+ }
+
+ cmdq_thread_resume(thread);
+ cmdq_thread_disable(cmdq, thread);
+ clk_disable(cmdq->clock);
+
+out:
+ spin_unlock_irqrestore(>chan->lock, flags);
+ return;
+
+wait:
+ cmdq_thread_resume(thread);
+ spin_unlock_irqrestore(>chan->lock, flags);
+ if (readl_poll_timeout_atomic(thread->base + CMDQ_THR_ENABLE_TASK,
+ enable, !enable, 1, 20))
+ dev_err(cmdq->mbox.dev, "Fail to wait GCE thread 0x%x done\n",
+ (u32)(thread->base - cmdq->base));
+}
+
static int cmdq_mbox_startup(struct mbox_chan *chan)
{
return 0;
@@ -427,6 +466,7 @@ static void cmdq_mbox_shutdown(struct mbox_chan *chan)
}
static const struct mbox_chan_ops cmdq_mbox_chan_ops = {
+ .abort_data = cmdq_mbox_abort_data,
.send_data = cmdq_mbox_send_data,
.startup = cmdq_mbox_startup,
.shutdown = cmdq_mbox_shutdown,
--
2.18.1
[PATCH 3/3] mailbox: mediatek: Remove busylist
After implement abort_data, controller need not to implement its own
queue. Remove busylist because it's useless.
Signed-off-by: CK Hu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 255 -
1 file changed, 29 insertions(+), 226 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index f2219f263ef6..45c59f677ecb 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -16,9 +16,7 @@
#include
#include
-#define CMDQ_OP_CODE_MASK (0xff << CMDQ_OP_CODE_SHIFT)
#define CMDQ_IRQ_MASK 0x
-#define CMDQ_NUM_CMD(t)(t->cmd_buf_size /
CMDQ_INST_SIZE)
#define CMDQ_CURR_IRQ_STATUS 0x10
#define CMDQ_THR_SLOT_CYCLES 0x30
@@ -47,22 +45,10 @@
#define CMDQ_THR_IRQ_EN(CMDQ_THR_IRQ_ERROR |
CMDQ_THR_IRQ_DONE)
#define CMDQ_THR_IS_WAITINGBIT(31)
-#define CMDQ_JUMP_BY_OFFSET0x1000
-#define CMDQ_JUMP_BY_PA0x1001
-
struct cmdq_thread {
struct mbox_chan*chan;
void __iomem*base;
- struct list_headtask_busy_list;
u32 priority;
- boolatomic_exec;
-};
-
-struct cmdq_task {
- struct cmdq *cmdq;
- struct list_headlist_entry;
- dma_addr_t pa_base;
- struct cmdq_thread *thread;
struct cmdq_pkt *pkt; /* the packet sent from mailbox client */
};
@@ -130,171 +116,47 @@ static void cmdq_thread_disable(struct cmdq *cmdq,
struct cmdq_thread *thread)
writel(CMDQ_THR_DISABLED, thread->base + CMDQ_THR_ENABLE_TASK);
}
-/* notify GCE to re-fetch commands by setting GCE thread PC */
-static void cmdq_thread_invalidate_fetched_data(struct cmdq_thread *thread)
-{
- writel(readl(thread->base + CMDQ_THR_CURR_ADDR),
- thread->base + CMDQ_THR_CURR_ADDR);
-}
-
-static void cmdq_task_insert_into_thread(struct cmdq_task *task)
-{
- struct device *dev = task->cmdq->mbox.dev;
- struct cmdq_thread *thread = task->thread;
- struct cmdq_task *prev_task = list_last_entry(
- >task_busy_list, typeof(*task), list_entry);
- u64 *prev_task_base = prev_task->pkt->va_base;
-
- /* let previous task jump to this task */
- dma_sync_single_for_cpu(dev, prev_task->pa_base,
- prev_task->pkt->cmd_buf_size, DMA_TO_DEVICE);
- prev_task_base[CMDQ_NUM_CMD(prev_task->pkt) - 1] =
- (u64)CMDQ_JUMP_BY_PA << 32 | task->pa_base;
- dma_sync_single_for_device(dev, prev_task->pa_base,
- prev_task->pkt->cmd_buf_size, DMA_TO_DEVICE);
-
- cmdq_thread_invalidate_fetched_data(thread);
-}
-
-static bool cmdq_command_is_wfe(u64 cmd)
-{
- u64 wfe_option = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
- u64 wfe_op = (u64)(CMDQ_CODE_WFE << CMDQ_OP_CODE_SHIFT) << 32;
- u64 wfe_mask = (u64)CMDQ_OP_CODE_MASK << 32 | 0x;
-
- return ((cmd & wfe_mask) == (wfe_op | wfe_option));
-}
-
-/* we assume tasks in the same display GCE thread are waiting the same event.
*/
-static void cmdq_task_remove_wfe(struct cmdq_task *task)
-{
- struct device *dev = task->cmdq->mbox.dev;
- u64 *base = task->pkt->va_base;
- int i;
-
- dma_sync_single_for_cpu(dev, task->pa_base, task->pkt->cmd_buf_size,
- DMA_TO_DEVICE);
- for (i = 0; i < CMDQ_NUM_CMD(task->pkt); i++)
- if (cmdq_command_is_wfe(base[i]))
- base[i] = (u64)CMDQ_JUMP_BY_OFFSET << 32 |
- CMDQ_JUMP_PASS;
- dma_sync_single_for_device(dev, task->pa_base, task->pkt->cmd_buf_size,
- DMA_TO_DEVICE);
-}
-
static bool cmdq_thread_is_in_wfe(struct cmdq_thread *thread)
{
return readl(thread->base + CMDQ_THR_WAIT_TOKEN) & CMDQ_THR_IS_WAITING;
}
-static void cmdq_thread_wait_end(struct cmdq_thread *thread,
-unsigned long end_pa)
-{
- struct device *dev = thread->chan->mbox->dev;
- unsigned long curr_pa;
-
- if (readl_poll_timeout_atomic(thread->base + CMDQ_THR_CURR_ADDR,
- curr_pa, curr_pa == end_pa, 1, 20))
- dev_err(dev, "GCE thread cannot run to end.\n");
-}
-
-static void cmdq_task_exec_done(struct cmdq_task *task, enum cmdq_cb_status
sta)
-{
- struct cmdq_task_cb *cb = >pkt->async_cb;
- struct cmdq_cb_data data;
-
- WARN_ON(cb->cb == (cmdq_async_flush_cb)NULL);
- data.sta = sta;
- data.data = cb->data;
- cb->cb(data);
-
- list_del(>list_entry);
-}
-
-static void cmdq_task_handle_error(struct cmdq_task *task)
-{
- struct cmdq_thread *thread = task->thread;
- struct cmdq_task
[PATCH 1/3] mailbox: Add ability for clients to abort data in channel
This patch supplies a new framework API, mbox_abort_channel(), and
a new controller interface, abort_data().
For some client's application, it need to clean up the data in channel
but keep the channel so it could send data to channel later.
Signed-off-by: CK Hu
---
drivers/mailbox/mailbox.c | 23 +++
include/linux/mailbox_client.h | 1 +
include/linux/mailbox_controller.h | 4
3 files changed, 28 insertions(+)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index c6a7d4582dc6..281647162c76 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -428,6 +428,29 @@ struct mbox_chan *mbox_request_channel_byname(struct
mbox_client *cl,
}
EXPORT_SYMBOL_GPL(mbox_request_channel_byname);
+/**
+ * mbox_abort_channel - The client abort all data in a mailbox
+ * channel by this call.
+ * @chan: The mailbox channel to be aborted.
+ */
+void mbox_abort_channel(struct mbox_chan *chan)
+{
+ unsigned long flags;
+
+ if (!chan || !chan->cl)
+ return;
+
+ if (chan->mbox->ops->abort_data)
+ chan->mbox->ops->abort_data(chan);
+
+ /* The queued TX requests are simply aborted, no callbacks are made */
+ spin_lock_irqsave(>lock, flags);
+ chan->cl = NULL;
+ chan->active_req = NULL;
+ spin_unlock_irqrestore(>lock, flags);
+}
+EXPORT_SYMBOL_GPL(mbox_abort_channel);
+
/**
* mbox_free_channel - The client relinquishes control of a mailbox
* channel by this call.
diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
index faa7da3c9c8b..209d1d458029 100644
--- a/include/linux/mailbox_client.h
+++ b/include/linux/mailbox_client.h
@@ -47,6 +47,7 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg);
int mbox_flush(struct mbox_chan *chan, unsigned long timeout);
void mbox_client_txdone(struct mbox_chan *chan, int r); /* atomic */
bool mbox_client_peek_data(struct mbox_chan *chan); /* atomic */
+void mbox_abort_channel(struct mbox_chan *chan); /* may sleep */
void mbox_free_channel(struct mbox_chan *chan); /* may sleep */
#endif /* __MAILBOX_CLIENT_H */
diff --git a/include/linux/mailbox_controller.h
b/include/linux/mailbox_controller.h
index 4994a438444c..518aa4ca2fe4 100644
--- a/include/linux/mailbox_controller.h
+++ b/include/linux/mailbox_controller.h
@@ -27,6 +27,9 @@ struct mbox_chan;
* @flush: Called when a client requests transmissions to be blocking but
* the context doesn't allow sleeping. Typically the controller
* will implement a busy loop waiting for the data to flush out.
+ * @abort_data:Called when a client relinquishes control of a chan.
+ * This call may block too. The controller may do stuff
+ * that need to sleep.
* @startup: Called when a client requests the chan. The controller
* could ask clients for additional parameters of communication
* to be provided via client's chan_data. This call may
@@ -50,6 +53,7 @@ struct mbox_chan;
struct mbox_chan_ops {
int (*send_data)(struct mbox_chan *chan, void *data);
int (*flush)(struct mbox_chan *chan, unsigned long timeout);
+ void (*abort_data)(struct mbox_chan *chan);
int (*startup)(struct mbox_chan *chan);
void (*shutdown)(struct mbox_chan *chan);
bool (*last_tx_done)(struct mbox_chan *chan);
--
2.18.1
[PATCH v2 1/2] gpio: sprd: Fix the incorrect data register
From: Neo Hou
Since differnt type EICs have its own data register to read, thus fix the
incorrect data register.
Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
Cc:
Signed-off-by: Neo Hou
Signed-off-by: Baolin Wang
---
Changes from v1:
- Add fix tag and CC stable.
---
drivers/gpio/gpio-eic-sprd.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-eic-sprd.c b/drivers/gpio/gpio-eic-sprd.c
index e0d6a0a..257df59 100644
--- a/drivers/gpio/gpio-eic-sprd.c
+++ b/drivers/gpio/gpio-eic-sprd.c
@@ -180,7 +180,18 @@ static void sprd_eic_free(struct gpio_chip *chip, unsigned
int offset)
static int sprd_eic_get(struct gpio_chip *chip, unsigned int offset)
{
- return sprd_eic_read(chip, offset, SPRD_EIC_DBNC_DATA);
+ struct sprd_eic *sprd_eic = gpiochip_get_data(chip);
+
+ switch (sprd_eic->type) {
+ case SPRD_EIC_DEBOUNCE:
+ return sprd_eic_read(chip, offset, SPRD_EIC_DBNC_DATA);
+ case SPRD_EIC_ASYNC:
+ return sprd_eic_read(chip, offset, SPRD_EIC_ASYNC_DATA);
+ case SPRD_EIC_SYNC:
+ return sprd_eic_read(chip, offset, SPRD_EIC_SYNC_DATA);
+ default:
+ return -ENOTSUPP;
+ }
}
static int sprd_eic_direction_input(struct gpio_chip *chip, unsigned int
offset)
--
1.7.9.5
[PATCH v2 2/2] gpio: sprd: Fix incorrect irq type setting for the async EIC
From: Neo Hou
When setting async EIC as IRQ_TYPE_EDGE_BOTH type, we missed to set the
SPRD_EIC_ASYNC_INTMODE register to 0, which means detecting edge signals.
Thus this patch fixes the issue.
Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
Cc:
Signed-off-by: Neo Hou
Signed-off-by: Baolin Wang
---
Changes from v1:
- Add fix tag and CC stable.
---
drivers/gpio/gpio-eic-sprd.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-eic-sprd.c b/drivers/gpio/gpio-eic-sprd.c
index 257df59..e41223c 100644
--- a/drivers/gpio/gpio-eic-sprd.c
+++ b/drivers/gpio/gpio-eic-sprd.c
@@ -379,6 +379,7 @@ static int sprd_eic_irq_set_type(struct irq_data *data,
unsigned int flow_type)
irq_set_handler_locked(data, handle_edge_irq);
break;
case IRQ_TYPE_EDGE_BOTH:
+ sprd_eic_update(chip, offset, SPRD_EIC_ASYNC_INTMODE,
0);
sprd_eic_update(chip, offset, SPRD_EIC_ASYNC_INTBOTH,
1);
irq_set_handler_locked(data, handle_edge_irq);
break;
--
1.7.9.5
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Wed, Jan 16, 2019 at 12:42 PM Josh Snyder wrote: > > For Netflix, losing accurate information from the mincore syscall would > lengthen database cluster maintenance operations from days to months. We > rely on cross-process mincore to migrate the contents of a page cache from > machine to machine, and across reboots. Ok, this is the kind of feedback we need, and means I guess we can't just use the mapping existence for mincore. The two other ways that we considered were: (a) owner of the file gets to know cache information for that file. (b) having the fd opened *writably* gets you cache residency information. Sadly, taking a look at happycache, you open the file read-only, so (b) doesn't work. Judging just from the source code, I can't tell how the user ownership works. Any input on that? And if you're not the owner of the file, do you have another suggestion for that "Yes, I have the right to see what's in-core for this file". Because the problem is literally that if it's some random read-only system file, the kernel shouldn't leak access patterns to it.. Linus
Re: [PATCH v5 4/6] usb: gadget: add mechanism to specify an explicit status stage
On Mon, Jan 14, 2019 at 10:24:44AM -0500, Alan Stern wrote: > On Mon, 14 Jan 2019, Paul Elder wrote: > > > > > > Can you check your uvc > > > > > changes using dummy_hcd with the patch below? > > > > > > > > I'm not sure what to make of the test results. I get the same results > > > > with or without the patch. Which I guess makes sense... in dummy_queue, > > > > this is getting hit when the uvc function driver tries to complete the > > > > delayed status: > > > > > > > > req = usb_request_to_dummy_request(_req); > > > > if (!_req || !list_empty(>queue) || !_req->complete) > > > > return -EINVAL; > > > > > > > > So the delayed/explicit status stage is never completed, afaict. > > > > > > I presume you are hitting the !list_empty(>queue) test, yes? The > > > other two tests are trivial. > > > > Yes, that is what's happening. > > > > > Triggering the !list_empty() test means the request has already been > > > submitted and not yet completed. This probably indicates there is a > > > bug in the uvc function driver code. > > > > The uvc function driver works with musb, though :/ > > > > I compared the sequence of calls to the uvc setup, completion handler, > > and status stage sending, and for some reason dummy_hcd, after an OUT > > setup-completion-status sequence, calls a completion-status-completion > > sequence, and then goes on the the next request. musb simply goes on to > > the next request after the setup-completion-status sequence. > > I don't quite understand. There's a control-OUT transfer, the setup, > data, and status transactions all complete normally, and then what > happens? What do you mean by "a completion-status-completion > sequence"? A more detailed description would help. > I meant the functions (procedures) in the function driver, so the setup handler (uvc_function_setup), the completion handler (uvc_function_ep0_complete), and the status sender (uvc_send_response), although the last one actually sends the data stage for control IN. So after the status is sent on the uvc gadget driver's end, its completion handler is called again without the setup handler being called beforehand and I cant figure out why. > > I commented out the paranoia block in dummy_timer, and dummy_hcd still > > does the extra completion, but it doesn't error out anymore. I doubt > > that's the/a solution though, especially since I get: > > > > [ 22.616577] uvcvideo: Failed to query (129) UVC probe control : -75 > > (exp. 26). > > [ 22.624481] uvcvideo: Failed to initialize the device (-5). > > > > Not sure if that's a result of dummy_hcd not supporting isochronous > > transfers or not. > > > > I'm not sure where to continue investigating :/ > > Perhaps removing the "#if 0" protecting the dev_dbg line in > dummy_queue() would provide some helpful output. It did, but didn't get me much farther :/ > Another thing to check would be if the "implement an emulated > single-request FIFO" in dummy_queue() is causing trouble. There's no > harm in replacing the long "if" condition with "if (0)". That didn't change anything. Although I did notice that the dummy_queue that calls the completion handler without the preceeding setup handler says that it's in the status stage (ep->status_stage == 1). Thanks, Paul
Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
On 1/15/19 2:57 AM, Benjamin Tissoires wrote: On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov wrote: On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote: On 1/11/19 7:40 PM, Dmitry Torokhov wrote: Hi Kim, Hi Dmitry, On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote: This patch is the result of seeing this message: psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-in...@vger.kernel.org. If I set psmouse.synaptics_intertouch=1, or add the PNP ID to smbus_pnp_ids, the touchpad continues to work, and the above message goes away, but we now get: psmouse serio1: synaptics: Trying to set up SMBus access psmouse serio1: synaptics: SMbus companion is not ready yet With this patch applied, i.e., the PNP IDs are added to the forcepad array, the touchpad continues to work and all of the above messages disappear. Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have physical button underneath it)? As far as I know there were only couple of HP laptops with forcepads and when switching to RMI mode forcepads need F21 handler that we do not currently have in the kernel. I see, no, I'm not sure, but assuming you're right, the IDs should be added to the smbus array instead, after fixing the SMbus "companion not ready" problem? Pointers for that and the below interrupts when touchpad idle after resume, welcome. Also, the link to get the RMI4 spec in Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt is broken. Any pointers for that also appreciated. OK, sorting it all out some more: - because we do not have support for F21 necessary for forcepads adding APIC ID to forcepad list actuallty disables SMbus companion mode, that is why you no longer see "companion not ready" messages vs. setting psmouse.synaptics_intertouch=1 module parameter. Yep - this does not really matter as your touchpad ends up being driven by i2c-hid and hid-multitouch drivers, and that is how we wait it to work, as we do not want to deviate from behavior on Windows since OEM tested it (the device and firmware) in tha configuration. Yep too. The I2C-hid touchpads from Synaptics do not have the SMBus wired at all, so we can't enable SMBus for them. Also, the fact that the device gets loaded over i2c-hid means that we can't know that it is the case from the psmouse/synaptics point of view. Sigh, OK, I wasn't registering the word "not" when reading "If i2c-hid and hid-rmi are not used" too quickly. - we need to figure out issue with interrupts on resume, maybe Benjamin have seen it? First time I see it. I just tried on a XPS 9360 and kernel v4.18 (fedora) and nothing was a problem. I then tried on a XPS 9575 with v4.19, and here, the wacom I2C node is also keeping firing the interrupts, but not the touchpad. However, here, the interrupts are not stopping when I touch the touchscreen or if I approach a pen. Kim, rmmod-ing i2c-hid and modprobing back it with the parameter debug=1 doesn't show any events processed when the interrupts are firing. Do you see the same? After rmmodding i2c_hid, the WCOM488F and SYNA2393 entries in /proc/interrupts somewhat expectedly disappear, however, the modprobe (with or without debug=1) fails to bring them back, with these messages left in dmesg: [ 3882.073222] calling i2c_hid_driver_init+0x0/0x1000 [i2c_hid] @ 3082 [ 3882.180938] i2c_hid i2c-WCOM488F:00: HID over i2c has not been provided an Int IRQ [ 3882.181060] i2c_hid: probe of i2c-WCOM488F:00 failed with error -22 [ 3882.181065] probe of i2c-WCOM488F:00 returned 0 after 496 usecs [ 3882.289196] i2c_hid i2c-SYNA2393:00: HID over i2c has not been provided an Int IRQ [ 3882.289318] i2c_hid: probe of i2c-SYNA2393:00 failed with error -22 [ 3882.289321] probe of i2c-SYNA2393:00 returned 0 after 508 usecs [ 3882.289418] initcall i2c_hid_driver_init+0x0/0x1000 [i2c_hid] returned 0 after 29 usecs In order to work around that problem, I set h2c_hid.debug=1 in the boot command line, and after a resume, dmesg contains these messages, relevant to i2c_hid: [ 267.235673] i2c_hid i2c-WCOM488F:00: calling i2c_hid_resume+0x0/0x140 [i2c_hid] @ 3078, parent: i2c-9 [ 267.235676] input input16: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0 [ 267.235681] input input16: input_dev_resume+0x0/0x50 returned 0 after 0 usecs [ 267.235682] i2c_hid i2c-WCOM488F:00: i2c_hid_set_power [ 267.235687] input input17: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0 [ 267.235689] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 00 08 [ 267.235693] input input17: input_dev_resume+0x0/0x50 returned 0 after 0 usecs [ 267.235698] idma64 idma64.1: calling platform_pm_resume+0x0/0x50 @ 3060, parent: :00:15.1 [ 267.235701] idma64 idma64.1: platform_pm_resume+0x0/0x50 returned 0
Re: [PATCH v12 01/16] tracing: Use str_has_prefix() in synth_event_create()
On Tue, 2019-01-15 at 16:05 -0600, Tom Zanussi wrote:
> Since we now have a str_has_prefix() that returns the length, we can
> use that instead of explicitly calculating it.
[]
> diff --git a/kernel/trace/trace_events_hist.c
> b/kernel/trace/trace_events_hist.c
[]
> @@ -1200,8 +1200,7 @@ static int synth_event_create(int argc, const char
> **argv)
>
> /* This interface accepts group name prefix */
> if (strchr(name, '/')) {
> - len = sizeof(SYNTH_SYSTEM "/") - 1;
> - if (strncmp(name, SYNTH_SYSTEM "/", len))
> + if ((len = str_has_prefix(name, SYNTH_SYSTEM "/")) == 0)
Since this is a single test, and not multiple if/else if
blocks, I believe this would read better on two lines
len = str_has_prefix(name, SYNTH_SYSTEM "/");
if (len == 0)
> return -EINVAL;
> name += len;
> }
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Wed, Jan 16, 2019 at 11:45 AM Dave Chinner wrote: > > I'm assuming that you can invalidate the page cache reliably by a > means that does not repeated require probing to detect invalidation > has occurred. I've mentioned one method in this discussion > already... Yes. And it was made clear to you that it was a bug in xfs dio and what the right thing to do was. And you ignored that, and claimed it was a feature. Why do you then bother arguing this thing? We absolutely agree that xfs has an information leak. If you don't care, just _say_ so. Don't try to argue against other people who are trying to fix things. We can easily just say "ok, xfs people don't care", and ignore the xfs invalidation issue. That's fine. But don't try to make it a big deal for other filesystems that _don't_ have the bug. I even pointed out how ext4 does the page cache flushing correcrly. You pooh-poohed it. You can't have it both ways. Either you care or you don't. If you don't care (and so far everything you said seems to imply you don't), then why are you even discussing this? Just admit you don't care, and we're done. Linus
Re: [PATCH v3 2/3] drivers: platform: goldfish: goldfish_address_space: add a driver
> > Do you have a pointer to the QEMU commit that matches up with the device > > that this driver is supposed to be supporting? > > The device code is here: > > https://android.googlesource.com/platform/external/qemu/+/emu-master-dev/hw/pci/goldfish_address_space.c Hi Greg, do you need anything else to review my patch? > why the existing memory driver does not work well enough for you I tried to find the existing driver to share memory between QEMU and a linux guest but could not find one.
Re: [PATCH v4] staging: Mediatek: Use individual config flags in Makefile
Hi George,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[cannot apply to v5.0-rc2 next-20190115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/George-Hilliard/staging-Mediatek-Use-individual-config-flags-in-Makefile/20190116-084915
config: x86_64-randconfig-e0-201902 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-14) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from drivers/staging/mt7621-mmc/dbg.c:51:
drivers/staging/mt7621-mmc/mt6575_sd.h: In function 'sdr_set_bits':
drivers/staging/mt7621-mmc/mt6575_sd.h:459:12: error: implicit declaration
of function 'readl'; did you mean 'd_real'?
[-Werror=implicit-function-declaration]
u32 val = readl(reg);
^
d_real
>> drivers/staging/mt7621-mmc/mt6575_sd.h:462:2: error: implicit declaration of
>> function 'writel'; did you mean 'wrmsrl'?
>> [-Werror=implicit-function-declaration]
writel(val, reg);
^~
wrmsrl
cc1: some warnings being treated as errors
vim +462 drivers/staging/mt7621-mmc/mt6575_sd.h
8b634a9c John Crispin 2018-03-15 456
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 457 static inline void
sdr_set_bits(void __iomem *reg, u32 bs)
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 458 {
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 @459 u32 val = readl(reg);
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 460
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 461 val |= bs;
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 @462 writel(val, reg);
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 463 }
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 464
:: The code at line 462 was first introduced by commit
:: 0b78f05d510b01e353481f5bccb63661d2cb5c32 staging: mt7621-mmc: Correct
datatypes for io and sanitize io access
:: TO: Christian Lütke-Stetzkamp
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC] perf tools: Filter out hidden symbols from labels
Hi, On Tue, Jan 15, 2019 at 01:35:40PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Jan 15, 2019 at 04:13:16PM +, Nick Clifton escreveu: > > Hi Jiri, > > > > > When perf is built with annobin plugin (RHEL8 build) extra symbols > > > are added to its binary: > > > > A bit of background for those wondering why annobin is creating > > these symbols: Annobin is a plugin for gcc that records data > > about how object file were built. It is specifically designed > > to be able to cope with files that are built using multiple > > different sets of optimization options. (Eg because of #pragma > > directives or function specific optimization attributes). It > > generates notes to cover each compiled region of code, and it > > needs the symbols in order to be able to determine exactly which > > areas in a linked binary were compiled with which options. > > Humm, it would be nice for perf annotate to show those options when one > navigates the annotation, something like press some hotkey and see the > optimization flags used. Is there any library that gets those > annotations and put them in some linked list that we could use in > tools/perf/? If it's just an ELF note, we could parse it directly. https://developers.redhat.com/blog/2018/02/20/annobin-storing-information-binaries/ Thanks, Namhyung
Re: [PATCH 0/3] doc: networking: integrate scaling document into doc tree
From: Otto Sabart Date: Wed, 9 Jan 2019 20:57:01 +0100 > These patches integrate scaling document into documentation tree. > > There are no semantic changes. Jon, I assume this is another series you will take in. Again, I expect no major conflicts with the networking tree.
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On Tue, Jan 15, 2019 at 09:23:12PM -0500, Jerome Glisse wrote:
> On Tue, Jan 15, 2019 at 06:01:09PM -0800, Dan Williams wrote:
> > On Tue, Jan 15, 2019 at 5:56 PM Jerome Glisse wrote:
> > > On Tue, Jan 15, 2019 at 04:44:41PM -0800, John Hubbard wrote:
> > [..]
> > > To make it clear.
> > >
> > > Lock code:
> > > GUP()
> > > ...
> > > lock_page(page);
> > > if (PageWriteback(page)) {
> > > unlock_page(page);
> > > wait_stable_page(page);
> > > goto retry;
> > > }
> > > atomic_add(page->refcount, PAGE_PIN_BIAS);
> > > unlock_page(page);
> > >
> > > test_set_page_writeback()
> > > bool pinned = false;
> > > ...
> > > pinned = page_is_pin(page); // could be after TestSetPageWriteback
> > > TestSetPageWriteback(page);
> > > ...
> > > return pinned;
> > >
> > > Memory barrier:
> > > GUP()
> > > ...
> > > atomic_add(page->refcount, PAGE_PIN_BIAS);
> > > smp_mb();
> > > if (PageWriteback(page)) {
> > > atomic_add(page->refcount, -PAGE_PIN_BIAS);
> > > wait_stable_page(page);
> > > goto retry;
> > > }
> > >
> > > test_set_page_writeback()
> > > bool pinned = false;
> > > ...
> > > TestSetPageWriteback(page);
> > > smp_wmb();
> > > pinned = page_is_pin(page);
> > > ...
> > > return pinned;
> > >
> > >
> > > One is not more complex than the other. One can contend, the other
> > > will _never_ contend.
> >
> > The complexity is in the validation of lockless algorithms. It's
> > easier to reason about locks than barriers for the long term
> > maintainability of this code. I'm with Jan and John on wanting to
> > explore lock_page() before a barrier-based scheme.
>
> How is the above hard to validate ?
Well, if you think it's so easy, then please write the test cases so
we can add them to fstests and make sure that we don't break it in
future.
If you can't write filesystem test cases that exercise these race
conditions reliably, then the answer to your question is "it is
extremely hard to validate" and the correct thing to do is to start
with the simple lock_page() based algorithm.
Premature optimisation in code this complex is something we really,
really need to avoid.
-Dave.
--
Dave Chinner
da...@fromorbit.com
Re: [PATCH] usb: dwc3: gadget: Fail request submission if it was already queued
Hi,
On 1/11/2019 2:51 PM, Felipe Balbi wrote:
> Hi,
>
> Manu Gautam writes:
>>> Manu Gautam writes:
If a function driver tries to re-submit an already queued request,
it can results in corruption of pending/started request lists.
Catch such conditions and fail the request submission to DCD.
Signed-off-by: Manu Gautam
---
drivers/usb/dwc3/gadget.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 679c12e14522..51716c6b286a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1290,6 +1290,12 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep
*dep, struct dwc3_request *req)
>request, req->dep->name))
return -EINVAL;
+ if (req->request.status == -EINPROGRESS) {
>>> this test is really not enough. What if gadget driver set status to
>>> EINPROGRESS before submission? A better check would involve making sure
>>> req isn't part of dep->pending_list or dep->started_list or
>>> dep->cancelled_list. It's clear that this won't work very well as the
>>> amount of requests grow.
>> Thanks for quick review.
>> 'request.status' check can be replaced:
>> +if (!list_empty(>list) {
>>
>> And replace list_del with list_del_init from dwc3_gadget_giveback()
> I would rather avoid this. We could start tracking our own internal
> dwc3_request status. Something along the lines of:
Thanks for this quick patch.
[snip]
>
> With this, we can remove some of the other request flags, such as "started".
>
>>> Anyway, which gadget driver did this? Why is it only affecting dwc3?
>> Function driver is not in upstream (f_mtp.c).
> So this could happen with any UDC, right? Why is f_mtp.c queueing the
> same request twice?
Looks like chipidea UDC already has such a check.
It is not yet clear that why f_mtp queued same request twice.
However, having a safeguard check in UDC should be helpful.
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
RE: [PATCH] USB: Fix configuration selection issues introduced in v4.20.0
Hi Yakimov,
As per UAC3 configuration, the first configuration will always be
backward-compatible.
So, there cannot be any UAC3-compatible device which has first configuration as
UAC3.
And secondly, the commit ff2a8c532c14 does not break the pre-existing logic.
I also thought so much about moving the code above Ethernet check while
preparing ff2a8c532c14.
But, then, it doesn't break the existing logic and so decided against moving it.
Thanks,
Saranya
> -Original Message-
> From: Nikolay Yakimov [mailto:r...@livid.pp.ru]
> Sent: Tuesday, January 15, 2019 9:44 PM
> To: Greg Kroah-Hartman
> Cc: Nikolay Yakimov ; Gopal, Saranya
> ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] USB: Fix configuration selection issues introduced in v4.20.0
>
> Commit f13912d3f014a introduced changes to the usb_choose_configuration
> function
> to better support USB Audio UAC3-compatible devices. However, there are a
> few
> problems with this patch. First of all, it adds new "if" clauses in the middle
> of an existing "if"/"else if" tree, which obviously breaks pre-existing logic.
> Secondly, since it continues iterating over configurations in one of the
> branches,
> other code in the loop can choose an unintended configuration. Finally,
> if an audio device's first configuration is UAC3-compatible, and there
> are multiple UAC3 configurations, the second one would be chosen, due to
> the first configuration never being checked for UAC3-compatibility.
>
> Commit ff2a8c532c14 tries to fix the second issue, but it goes about it in a
> somewhat unnecessarily convoluted way, in my opinion, and does nothing
> to fix the first or the last one.
>
> This patch tries to rectify problems described by essentially rewriting
> code introduced in f13912d3f014a. Notice the code was moved to *before*
> the "if"/"else if" tree.
>
> Signed-off-by: Nikolay Yakimov
> ---
> drivers/usb/core/generic.c | 44 ++
> 1 file changed, 25 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/usb/core/generic.c b/drivers/usb/core/generic.c
> index f713cecc1f41..1ac9c1e5f773 100644
> --- a/drivers/usb/core/generic.c
> +++ b/drivers/usb/core/generic.c
> @@ -118,6 +118,31 @@ int usb_choose_configuration(struct usb_device
> *udev)
> continue;
> }
>
> + /*
> + * Select first configuration as default for audio so that
> + * devices that don't comply with UAC3 protocol are supported.
> + * But, still iterate through other configurations and
> + * select UAC3 compliant config if present.
> + */
> + if (desc && is_audio(desc)) {
> + /* Always prefer the first found UAC3 config */
> + if (is_uac3_config(desc)) {
> + best = c;
> + break;
> + }
> +
> + /* If there is no UAC3 config, prefer the first config
> */
> + else if (i == 0)
> + best = c;
> +
> + /* Unconditional continue, because the rest of the code
> + * in the loop is irrelevant for audio devices, and
> + * because it can reassign best, which for audio devices
> + * we don't want.
> + */
> + continue;
> + }
> +
> /* When the first config's first interface is one of Microsoft's
>* pet nonstandard Ethernet-over-USB protocols, ignore it
> unless
>* this kernel has enabled the necessary host side driver.
> @@ -132,25 +157,6 @@ int usb_choose_configuration(struct usb_device
> *udev)
> #endif
> }
>
> - /*
> - * Select first configuration as default for audio so that
> - * devices that don't comply with UAC3 protocol are supported.
> - * But, still iterate through other configurations and
> - * select UAC3 compliant config if present.
> - */
> - if (i == 0 && num_configs > 1 && desc && is_audio(desc)) {
> - best = c;
> - continue;
> - }
> -
> - if (i > 0 && desc && is_audio(desc)) {
> - if (is_uac3_config(desc)) {
> - best = c;
> - break;
> - }
> - continue;
> - }
> -
> /* From the remaining configs, choose the first one whose
>* first interface is for a non-vendor-specific class.
>* Reason: Linux is more likely to have a class driver
> --
> 2.20.1
[PATCH] iommu/amd: Fix IOMMU page flush when detach all devices from a domain
From: Suravee Suthikulpanit
When a VM is terminated, the VFIO driver detaches all pass-through
devices from VFIO domain by clearing domain id and page table root
pointer from each device table entry (DTE), and then invalidates
the DTE. Then, the VFIO driver unmap pages and invalidate IOMMU pages.
Currently, the IOMMU driver keeps track of which IOMMU and how many
devices are attached to the domain. When invalidate IOMMU pages,
the driver checks if the IOMMU is still attached to the domain before
issuing the invalidate page command.
However, since VFIO has already detached all devices from the domain,
the subsequent INVALIDATE_IOMMU_PAGES commands are being skipped as
there is no IOMMU attached to the domain. This results in data
corruption and could cause the PCI device to end up in indeterministic
state.
Fix this by always issuing the IOMMU pages invalidate command when
device count is zero, which is the case when detaching all the devices
from the domain.
Cc: Boris Ostrovsky
Signed-off-by: Brijesh Singh
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd_iommu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 525659b88ade..ab31ba75da1b 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1248,7 +1248,13 @@ static void __domain_flush_pages(struct
protection_domain *domain,
build_inv_iommu_pages(, address, size, domain->id, pde);
for (i = 0; i < amd_iommu_get_num_iommus(); ++i) {
- if (!domain->dev_iommu[i])
+ /*
+* The dev_cnt is zero when all devices are detached
+* from the domain. This is the case when VFIO detaches
+* all devices from the group before flushing IOMMU pages.
+* So, always issue the flush command.
+*/
+ if (domain->dev_cnt && !domain->dev_iommu[i])
continue;
/*
--
2.17.1
[PATCH] iommu/amd: Mark translation invalid during device detach
From: Suravee Suthikulpanit
When a device switches domain, IOMMU driver detach device from the old
domain, and attach device to the new domain. During this period
the host table root pointer is not set, which means DMA translation
should be marked as invalid (clear TV bit).
So, clear the TV bit when detach the device. The TV bit will be set
again when attaching device to the new domain.
Cc: Boris Ostrovsky
Signed-off-by: Brijesh Singh
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 87ba23a75b38..525659b88ade 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1956,7 +1956,7 @@ static void set_dte_entry(u16 devid, struct
protection_domain *domain,
static void clear_dte_entry(u16 devid)
{
/* remove entry from the device table seen by the hardware */
- amd_iommu_dev_table[devid].data[0] = DTE_FLAG_V | DTE_FLAG_TV;
+ amd_iommu_dev_table[devid].data[0] = DTE_FLAG_V;
amd_iommu_dev_table[devid].data[1] &= DTE_FLAG_MASK;
amd_iommu_apply_erratum_63(devid);
--
2.17.1
Re: [PATCH v2 2/3] dt-bindings: arm: fsl: Add devicetree binding for Oxalis
On Tue, Jan 15, 2019 at 8:21 PM Shawn Guo wrote: > > On Mon, Jan 14, 2019 at 12:02:47PM -0600, Rob Herring wrote: > > On Mon, Jan 14, 2019 at 4:21 AM Manivannan Sadhasivam > > wrote: > > > > > > Add devicetree binding for Oxalis board in JSON format. While adding > > > that, let's fix the description for LS1012A also. > > > > > > Signed-off-by: Manivannan Sadhasivam > > > --- > > > Documentation/devicetree/bindings/arm/fsl.yaml | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml > > > b/Documentation/devicetree/bindings/arm/fsl.yaml > > > index d34fe0749199..0f30142fe316 100644 > > > --- a/Documentation/devicetree/bindings/arm/fsl.yaml > > > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml > > > @@ -173,12 +173,13 @@ properties: > > >- fsl,vf610 > > >- fsl,vf610m4 > > > > > > - - description: LS1021A based Boards > > > + - description: LS1012A based Boards > > > > Well, yes that was wrong... > > > > > items: > > >- enum: > > >- fsl,ls1012a-rdb > > >- fsl,ls1012a-frdm > > >- fsl,ls1012a-qds > > > + - ebs-systart,oxalis > > > > Sort alphabetically. > > > > >- const: fsl,ls1021a > > > > And this is wrong too. > > > > I you just change it, then we will be missing an entry for LS1021A. > > What's the status of that SoC because there is no board dts file? We > > should not have .dtsi files in the kernel which don't get built. > > Hmm, I do not see any LS1021A SoC .dtsi in the tree. I suspect it's > just a typo of LS1012A. > > @Leo, do we have a LS1021A SoC? arch/arm/boot/dts/ls1021a.dtsi Rob
Re: [RFC v2 1/6] dt-bindings: Add a binding for Mediatek SCP
On Wed, Jan 16, 2019 at 4:34 AM Rob Herring wrote: > > On Tue, Jan 08, 2019 at 01:26:01PM +0800, Pi-Hsun Shih wrote: > > From: Erin Lo > > > > Add a DT binding documentation of SCP for the > > MT8183 SoC from Mediatek. > > > > Signed-off-by: Erin Lo > > --- > > Changes from v1: > > - no change > > No answer to my question on v1? > Sorry I missed the last mail. Yes there would be additional optional properties. For the current patch series, the "cros-ec-rpmsg" entry would not be listed in the device tree, but there would be a "mediatek,mt8183-rpmsg" under this node. Would update this in v3. > > --- > > .../devicetree/bindings/remoteproc/mtk,scp.txt | 10 ++ > > 1 file changed, 10 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt > > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt > > new file mode 100644 > > index 00..b07e5c4ca9af1d > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt > > @@ -0,0 +1,10 @@ > > +Mediatek SCP Bindings > > + > > + > > +This binding provides support for ARM Cortex M4 Co-processor found on some > > +Mediatek SoCs. > > + > > +Required properties: > > +- compatible Should be "mediatek,mt8183-scp" > > +- clocks Clock for co-processor (See: > > ../clock/clock-bindings.txt) > > + > > -- > > 2.20.1.97.g81188d93c3-goog > >
RE: [PATCHv4 1/4] dt-bindings: add DT binding for the layerscape PCIe controller with EP mode
-Original Message- From: Rob Herring Sent: 2019年1月11日 22:31 To: Xiaowei Bao Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo Li ; kis...@ti.com; lorenzo.pieral...@arm.com; a...@arndb.de; gre...@linuxfoundation.org; M.h. Lian ; Mingkai Hu ; Roy Zang ; kstew...@linuxfoundation.org; cyrille.pitc...@free-electrons.com; pombreda...@nexb.com; shawn@rock-chips.com; niklas.cas...@axis.com; linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; Xiaowei Bao Subject: Re: [PATCHv4 1/4] dt-bindings: add DT binding for the layerscape PCIe controller with EP mode On Tue, 8 Jan 2019 11:09:19 +0800, Xiaowei Bao wrote: > Add the documentation for the Device Tree binding for the layerscape > PCIe controller with EP mode. > > Signed-off-by: Xiaowei Bao > --- > v2: > - Add the SoC specific compatibles. > v3: > - modify the commit message. > v4: > - no change. > > .../devicetree/bindings/pci/layerscape-pci.txt |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed. [Xiaowei Bao] Hi Rob, thanks a lot for your comments, if the patches have new update, I will add the Acked-by/Reviewed-by, thanks.
Re: [RFC PATCH 0/4] watchdog: hpwdt: Fix NMI-related behaviour when CONFIG_HPWDT_NMI_DECODING is enabled
On Mon, Jan 14, 2019 at 07:36:13AM +0500, Ivan Mironov wrote: > Hi, > > I found out that hpwdt alters NMI behaviour unexpectedly if compiled > with enabled CONFIG_HPWDT_NMI_DECODING: > > * System starts to panic on any NMI with misleading message. hpwdt doesn't start to panic on any NMI. It starts to panic on: 1) NMI_SERR associated with NMI 2) NMI_IO_CHECK associated with IO errors 3) NMI_UNKNOWN NMI unclaimed by all local handlers. On Gen10 going forward we plan to restrict to just iLO generated NMIs. There is a long history on hp/hpe proliant systems where hpwdt was handler of general IO errors (at least ones that would cause NMI to be generated) and we chose to panic in these situation as the errors were generally quite serious. Yes, this has caused some problems in the past as Linux has overloaded NMI and some subsystems didn't claim the NMIs that they generated (think profiling.) But, I haven't seen these types of problems for several years now. The more modern platforms have more robust error handling built into them and to linux so going forward we'll restrict hpwdt to a more traditional WDT role. But we're retaining the more conservative approach for legacy platforms. How would you suggest that the message be enhanced? > * Watchdog provided by hpwdt is not working after such panic. > > Here are the patches that should fix this. > > This is an RFC patch series because I am not sure that patches are > correct. Questions: > > * Are "mynmi" flags always set on all supported iLO versions when iLO >is the source of NMI? Unfortunately no. hpwdt is a dual purpose driver. It handles the iLO watchdog timer and the "Generate NMI to System" button. These are closely related hardware wise. However, some platforms generate NMI for "Generate NMI to System" button but aren't signaled via iLO registers. These will show up as NMI_UNKNOWN, hence while hpwdt still claims these. There are also some systems that do not set the nmistat bits correctly. So as to not break legacy platforms, the use the nmistat bits for control will be for Gen10 going forward. > * Is it safe to reset "mynmi" flags to zero if code decides to not panic? The reading of the registers is itself destructive (sets to zero) but the real issue is that some proliant systems lack the ability to acknowledge the NMI so only one can ever be received. So returning is not advisable as no further NMI will be generated via this path. A reset through firmware is required to restore the feature. > > Ivan Mironov (4): > watchdog: hpwdt: Don't disable watchdog on NMI > watchdog: hpwdt: Don't panic on foreign NMI > watchdog: hpwdt: Add more information into message > watchdog: hpwdt: Make panic behaviour configurable > > drivers/watchdog/hpwdt.c | 45 ++-- > 1 file changed, 25 insertions(+), 20 deletions(-) > > -- > 2.20.1 -- - Jerry Hoemann Software Engineer Hewlett Packard Enterprise -
Re: [PATCH v2] plugin python: Adjust the handling after PyRun_String() failed
On Thu, 27 Apr 2017 11:55:58 +0900 Taeung Song wrote: > Even though PyRun_String() failed, > just 0 will be returned but we need to return -1 > that means error status, so fix it. Ug, I just noticed this patch floating in the flood of my INBOX. I just applied it, and will be pushing it out soon. Thanks, and I'm really sorry for not seeing it. -- Steve > > Signed-off-by: Taeung Song > --- > plugin_python.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/plugin_python.c b/plugin_python.c > index 2997679..c283ed7 100644 > --- a/plugin_python.c > +++ b/plugin_python.c > @@ -55,7 +55,7 @@ static int load_plugin(struct pevent *pevent, const char > *path, > > free(load); > > - return 0; > + return res ? 0 : -1; > } > > int PEVENT_PLUGIN_LOADER(struct pevent *pevent)
Re: [RFC PATCH 4/4] watchdog: hpwdt: Make panic behaviour configurable
On Mon, Jan 14, 2019 at 07:36:17AM +0500, Ivan Mironov wrote:
> This adds an option to not panic on NMI even if it was caused by iLO.
>
> Signed-off-by: Ivan Mironov
> ---
> drivers/watchdog/hpwdt.c | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
> index 95d002b5b120..b12858491189 100644
> --- a/drivers/watchdog/hpwdt.c
> +++ b/drivers/watchdog/hpwdt.c
> @@ -37,6 +37,10 @@ static unsigned int soft_margin = DEFAULT_MARGIN; /* in
> seconds */
> static bool nowayout = WATCHDOG_NOWAYOUT;
> static bool pretimeout = IS_ENABLED(CONFIG_HPWDT_NMI_DECODING);
>
> +#ifdef CONFIG_HPWDT_NMI_DECODING
> +static bool panic_on_nmi = true;
> +#endif /* CONFIG_HPWDT_NMI_DECODING */
> +
> static void __iomem *pci_mem_addr; /* the PCI-memory address */
> static unsigned long __iomem *hpwdt_nmistat;
> static unsigned long __iomem *hpwdt_timer_reg;
> @@ -146,7 +150,10 @@ static int hpwdt_set_pretimeout(struct watchdog_device
> *wdd, unsigned int req)
>
> static int hpwdt_my_nmi(void)
> {
> - return ioread8(hpwdt_nmistat) & 0x6;
> + int nmistat = ioread8(hpwdt_nmistat);
> +
> + iowrite8(nmistat & ~0x6, hpwdt_nmistat);
> + return nmistat & 0x6;
This is a read only register.
> }
>
> /*
> @@ -168,7 +175,10 @@ static int hpwdt_pretimeout(unsigned int ulReason,
> struct pt_regs *regs)
>"4. iLO Event Log\n",
>mynmi, ulReason, smp_processor_id());
>
> - nmi_panic(regs, "hpwdt: NMI: Not continuing");
> + if (panic_on_nmi)
> + nmi_panic(regs, "hpwdt: NMI: Not continuing");
> +
> + pr_emerg("Dazed and confused, but trying to continue\n");
>
The watchdog core provides a way to enable/disable the NMI pretimeout
dynamically
via ioctl. The pretimeout NMI can also be disabled via module parameter to
hpwdt.
This adds complexity without really adding functionality.
BTW, don't reuse error messages. Makes it difficult to tell where the error
originated from.
> return NMI_HANDLED;
> }
> @@ -376,6 +386,9 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped
> once started (default="
> #ifdef CONFIG_HPWDT_NMI_DECODING
> module_param(pretimeout, bool, 0);
> MODULE_PARM_DESC(pretimeout, "Watchdog pretimeout enabled");
> -#endif
> +
> +module_param(panic_on_nmi, bool, 0);
> +MODULE_PARM_DESC(panic_on_nmi, "Cause panic on NMI induced by iLO
> (default=1)");
> +#endif /* CONFIG_HPWDT_NMI_DECODING */
>
> module_pci_driver(hpwdt_driver);
> --
> 2.20.1
--
-
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-
Re: [PATCH] arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region
OK, thanks. But seems this mail be ignored, do i need re-sent the patch?
On 2018/12/26 21:49, Ard Biesheuvel wrote:
> On Tue, 25 Dec 2018 at 03:30, Yueyi Li wrote:
>> Hi Ard,
>>
>>
>> On 2018/12/24 17:45, Ard Biesheuvel wrote:
>>> Does the following change fix your issue as well?
>>>
>>> index 9b432d9fcada..9dcf0ff75a11 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -447,7 +447,7 @@ void __init arm64_memblock_init(void)
>>>* memory spans, randomize the linear region as well.
>>>*/
>>> if (memstart_offset_seed > 0 && range >=
>>> ARM64_MEMSTART_ALIGN) {
>>> - range = range / ARM64_MEMSTART_ALIGN + 1;
>>> + range /= ARM64_MEMSTART_ALIGN;
>>> memstart_addr -= ARM64_MEMSTART_ALIGN *
>>>((range * memstart_offset_seed)
>>> >> 16);
>>> }
>> Yes, it can fix this also. I just think modify the first *range*
>> calculation would be easier to grasp, what do you think?
>>
> I don't think there is a difference, to be honest, but I will leave it
> up to the maintainers to decide which approach they prefer.
Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
On 01/16/19 at 12:10am, Borislav Petkov wrote:
> On Tue, Jan 15, 2019 at 05:58:34PM +0800, Kairui Song wrote:
> > When efi=noruntime or efi=oldmap is used, EFI services won't be available
> > in the second kernel, therefore the second kernel will not be able to get
> > the ACPI RSDP address from firmware by calling EFI services and won't
> > boot. Previously we are expecting the user to set the acpi_rsdp=
> > on kernel command line for second kernel as there was no way to pass RSDP
> > address to second kernel.
> >
> > After commit e6e094e053af ('x86/acpi, x86/boot: Take RSDP address from
> > boot params if available'), now it's possible to set an acpi_rsdp_addr
> > parameter in the boot_params passed to second kernel, this commit make
> > use of it, detect and set the RSDP address when it's required for second
> > kernel to boot.
> >
> > Tested with an EFI enabled KVM VM with efi=noruntime.
> >
> > Suggested-by: Dave Young
> > Signed-off-by: Kairui Song
> > ---
> > arch/x86/kernel/kexec-bzimage64.c | 21 +
> > drivers/acpi/acpica/tbxfroot.c| 3 +--
> > include/acpi/acpixf.h | 2 +-
> > 3 files changed, 23 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/kexec-bzimage64.c
> > b/arch/x86/kernel/kexec-bzimage64.c
> > index 53917a3ebf94..0a90dcbd041f 100644
> > --- a/arch/x86/kernel/kexec-bzimage64.c
> > +++ b/arch/x86/kernel/kexec-bzimage64.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -255,8 +256,28 @@ setup_boot_parameters(struct kimage *image, struct
> > boot_params *params,
> > /* Setup EFI state */
> > setup_efi_state(params, params_load_addr, efi_map_offset, efi_map_sz,
> > efi_setup_data_offset);
> > +
> > +#ifdef CONFIG_ACPI
> > + /* Setup ACPI RSDP pointer in case EFI is not available in second
> > kernel */
> > + if (!acpi_disabled && (!efi_enabled(EFI_RUNTIME_SERVICES) ||
> > efi_enabled(EFI_OLD_MEMMAP))) {
> > + /* Copied from acpi_os_get_root_pointer accordingly */
> > + params->acpi_rsdp_addr = boot_params.acpi_rsdp_addr;
> > + if (!params->acpi_rsdp_addr) {
> > + if (efi_enabled(EFI_CONFIG_TABLES)) {
> > + if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> > + params->acpi_rsdp_addr = efi.acpi20;
> > + else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> > + params->acpi_rsdp_addr = efi.acpi;
> > + } else if
> > (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
> > + acpi_find_root_pointer(>acpi_rsdp_addr);
> > + }
> > + }
> > + if (!params->acpi_rsdp_addr)
> > + pr_warn("RSDP is not available for second kernel\n");
> > + }
> > #endif
>
> Amazing the amount of ACPI RDSP parsing and fiddling patches flying
> around these days...
>
> In any case, this needs to be synchronized with:
>
> https://lkml.kernel.org/r/20190107032243.25324-1-fanc.f...@cn.fujitsu.com
>
> and checked whether the above can be used instead of sprinkling of ACPI
> parsing code left and right.
Both Baoquan and Chao are cced for comments.
The above KASLR patches seems some early code to parsing acpi, but I think in
this
patch just call acpi function to get the root pointer no need to add the
duplicate logic of if/else/else if.
Kairui, do you have any reason for the checking? Is there some simple
acpi function to just return the root pointer?
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
Thanks
Dave
