* RE: [PATCH v5 3/3] clocksource: Add clockevent support to NPS400 driver
From: Noam Camus @ 2016-11-14 16:45 UTC (permalink / raw)
To: Daniel Lezcano
Cc: robh+dt@kernel.org, mark.rutland@arm.com, tglx@linutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161114154154.GF2016@mai>
> From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
> Sent: Monday, November 14, 2016 5:42 PM
>> When you are saying "we have a framework" do you mean to some generic
>> framework in the kernel?
> Yes, IIRC it is regmap but I'm not sure.
Indeed regmap is a generic framework and it primarily meant for registers which can be mapped to our virtual/logical address space which is not the case here. For our auxiliary registers access we use dedicated instructions (lr/sr) and not LOAD/STORE like GCC produce.
It is possible to use such regmap but this driver will be filled with all regmap handling just to hide couple of lines. This will not serve this driver readability well.
>I think there is something I am missing with this HW scheduling thing. Why are these hw_schd_save/hw_schd_restore functions needed to be called from the timer driver ? Regarding the explanation, the HW scheduling can happen everywhere at any time, not only in the timer code but this one is the only one which need the hw_schd_save/hw_schd_restore calls, why ?
I use them not just here they are also serve to protect our L1 cache and TLB which are also shared within same core. You can't see this yet since patch are not still push to arch/arc tree.
>Why,
>spin_lock(&lock);
>write_aux_reg(...)
>spin_unlock(&lock);
>can't work ?
Because I can't use spinlock in interrupt context (I call to nps_clkevent_rm_thread() in irq_handler).
>IIUC, there can be more than 16 cpus/threads, so calling hw_schd_save / hw_schd_restore will disable the HW scheduling for the entire system while one cpu is processing something with these couple of registers, no ?
NO, HW scheduling will be disabled only for this specific core, all other cores will not be affected since they got their own private registers.
...
>> >And tick_resume. Perhaps, that is the reason why NO_HZ hangs.
>> What NO_HZ hang are you referring to in this case? How calling
>> nps_clkevent_rm_thread() explain such hang? Anyway I agree, and will
>> add
>> nps_clkevent_rm_thread() to tick_resume.
>Actually I meant NOHZ_FULL.
Still got no clue what hang we are talking about here!
Note:
I looked at arch/tile timer driver again and noticed that I can work without periodic mode. This is exactly what I need here (pure oneshot mode).
With this fact I can define
Static void nps_clkevent_rm_thread(void)
Static void nps_clkevent_add_thread(void)
Also HW scheduling save/restore is only used in *rm_thread/*add_thread since I can now remove nps_clkevent_set_periodic() and nps_clkevent_timer_event_setup().
This way clockevent driver seem much simpler and it is clearer to understanding.
I hope that this approach of not having periodic mode is acceptable.
-Noam
^ permalink raw reply
* Re: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
From: Ville Syrjälä @ 2016-11-14 16:45 UTC (permalink / raw)
To: Sharma, Shashank
Cc: Jose Abreu, Jia, Lin A, Akashdeep Sharma, Emil Velikov, dri-devel,
Daniel Vetter, Jim Bride
In-Reply-To: <f0636aa1-2134-1ab8-40f5-a21730d3c493@intel.com>
On Mon, Nov 14, 2016 at 10:12:04PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 11/14/2016 9:50 PM, Ville Syrjälä wrote:
> > On Mon, Nov 14, 2016 at 09:37:18PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
> >>> On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
> >>>> Regards
> >>>> Shashank
> >>>>> the revert:
> >>>>>
> >>>>> HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 700mm x 390mm
> >>>>> - 1920x1080 60.00*+
> >>>>> - 1920x1080i 60.00 50.00
> >>>>> + 1920x1080 60.00*+ 50.00 59.94 30.00 25.00 24.00 29.97 23.98
> >>>>> + 1920x1080i 60.00 50.00 59.94
> >>>>> 1600x1200 60.00
> >>>>> 1680x1050 59.88
> >>>>> 1280x1024 75.02 60.02
> >>>>> @@ -13,30 +13,29 @@
> >>>>> 1360x768 60.02
> >>>>> 1280x800 59.91
> >>>>> 1152x864 75.00
> >>>>> - 1280x720 60.00 50.00
> >>>>> + 1280x720 60.00 50.00 59.94
> >>>>> 1024x768 75.03 70.07 60.00
> >>>>> 832x624 74.55
> >>>>> 800x600 72.19 75.00 60.32
> >>>>> - 640x480 75.00 72.81 66.67 59.94
> >>>>> + 720x576 50.00
> >>>>> + 720x480 60.00 59.94
> >>>>> + 640x480 75.00 72.81 66.67 60.00 59.94
> >>>>> 720x400 70.08
> >>>> None of these aspect ratios are new modes / new aspect ratios from HDMI
> >>>> 2.0/CEA-861-F
> >>>> These are the existing modes, and should be independent of reverted
> >>>> patches.
> >>> They're affected because your patches changed them by adding the aspect
> >>> ratio flags to them.
> >> Yes, But they are independent of reverted patch, which adds aspect ratio
> >> for HDMI 2.0 ratios (64:27 and 256:135)
> > The second patch had to be reverted so that the first patch would revert
> > cleanly.
> >
> >>>>> This was with sna, which does this:
> >>>>> #define KNOWN_MODE_FLAGS ((1<<14)-1)
> >>>>> if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
> >>>>> mode->status = MODE_BAD; /* unknown flags => unhandled */
> >>>>> so all the modes with an aspect ratio just vanished.
> >>>>>
> >>>>> -modesetting and -ati on the other hand just copy over the unknown
> >>>>> bits into the xrandr mode structure, which sounds dubious at best:
> >>>>> mode->Flags = kmode->flags; //& FLAG_BITS;
> >>>>> I've not checked what damage it can actually cause.
> >>>>>
> >>>>>
> >>>>> It looks like a few modes disappeared from the kernel's mode list
> >>>>> as well, presumably because some cea modes in the list originated from
> >>>>> DTDs and whanot so they don't have an aspect ratio and that causes
> >>>>> add_alternate_cea_modes() to ignore them. So not populating an aspect
> >>>>> ratio for cea modes originating from a source other than
> >>>>> edid_cea_modes[] looks like another bug to me as well.
> >>>> I am writing a patch series to cap the aspect ratio implementation under
> >>>> a drm_cap_hdmi2_aspect_ratios
> >>>> This is how its going to work (inspired from the 2D/stereo series from
> >>>> damien L)
> >>>>
> >>>> - Add a new capability hdmi2_ar
> >>> It should be just a generic "expose aspect ratio flags to userspace?"
> >> Makes sense, in this way we can even revert the aspect_ratio property
> >> for HDMI connector, as discussed during
> >> the code review sessions of this patch series. In this way, when kernel
> >> will expose the aspect ratios, it will either
> >> do the aspect ratios as per EDID, or wont.
> >>>> - by default parsing the new hdmi 2.0 aspect ratio will be disabled
> >>>> under check of this cap
> >>>> - during bootup time, while initializing the display, a userspace can
> >>>> get_cap on the hdmi2_aspect_ratio
> >>>> - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
> >>>> kernel will expose these aspect ratios
> >>>>> Another bug I think might be the ordering of the modes with aspect ratio
> >>>>> specified. IIRC the spec says that the preferred aspect ratio should be
> >>>>> listed first in the EDID, but I don't think we preserve that ordering
> >>>>> in the final mode list. I guess we could fix that by somehow noting
> >>>>> which aspect ratio is preferred and sort based on that, or we try to
> >>>>> preserve the order from the EDID until we're ready to sort, and then do
> >>>>> the sorting with a stable algorithm.
> >>>> AFAIK The mode order and priority is decided and arranged in userspace,
> >>>> based on various factors like
> >>>> - preferred mode.
> >>>> - previously applied mode in previous sessions (like for android tvs)
> >>>> - Bigger h/w vs better refresh rate ?
> >>>> - Xserver applies its own algorithms to decide which mode should be
> >>>> shown first.
> >>> Xorg does sort on its own. But since it doesn't know anything about
> >>> aspect ratios and whatnot I wouldn't rely on that for anything. I
> >>> also wouldn't expect eg. wayland compositors to do their own sorting.
> >>> And yeah, looks like weston at least doesn't do any sorting whatsoever.
> >>>
> >>>> I dont think kernel needs to bother about it.
> >>> So I'm going to say that we in fact do need to bother.
> >>>
> >> IMHO, making policies for UI is not a part of kernel design, a UI
> >> manager (Hardware composed, X or Wayland) should take care of it, as
> >> they have access to much information (Like previously applied mode, user
> >> preference etc). When it comes to sorting of modes, the only general rule
> >> across drivers like FB, V4L2, I have seen is the first mode in the list
> >> should be preferred mode, which we are still keeping. And after that our
> >> probed_modes were
> >> anyways not sorted now, so it doesn't matter further.
> > Having userspace be responsible for sorting the aspect ratios would
> > perhaps require that userspace parses the EDID, which is pretty crazy.
> Why ?
> userspace has to just set cap for aspect ratio, and kernel can read
> EDID, parse the CEA block, populate the aspect ratios flags
> and add the modes (Just what this patch was doing, except the cap part)
> Once userspace has the getResources/getConnector call filled, it can
> access all the modes (with and without aspect) and do the sorting
> in any way it wants.
> > I guess it could try to deduce something from the physical aspect ratio
> > of the display, but I'm not sure that's quite what we want either.
> >
> > Also we already sort the modes in the kernel anyway, so it's not like
> > we'd be doing something new by also considering the aspect ratios.
> > I would at the very least want to avoid a totally random order between
> > modes that differ only by the aspect ratio.
> Path: get_connector -> probe_single_connector_mode -> drm_add_edid_modes
> Again, IMHO, we don't sort the modes in kernel, we populate modes in a
> particular order, which is:
> (From drm_edid.c::drm_add_edid_modes)
> ##############################################################
> /*
> * EDID spec says modes should be preferred in this order:
> * - preferred detailed mode
> * - other detailed modes from base block
> * - detailed modes from extension blocks
> * - CVT 3-byte code modes
> * - standard timing codes
> * - established timing codes
> * - modes inferred from GTF or CVT range information
> *
> * We get this pretty much right.
> *
> * XXX order for additional mode types in extension blocks?
> */
> num_modes += add_detailed_modes(connector, edid, quirks);
> num_modes += add_cvt_modes(connector, edid);
> num_modes += add_standard_modes(connector, edid);
> num_modes += add_established_modes(connector, edid);
> num_modes += add_cea_modes(connector, edid);
> num_modes += add_alternate_cea_modes(connector, edid);
> num_modes += add_displayid_detailed_modes(connector, edid);
> ###############################################################
>
> Here the modes are added in the connector, in the same order they are
> arranged into their respective blocks in EDID.
> But the order to read the block is a preferred order (no sorting).
>
> Now, in this patch series, we are adding aspect ratio information in
> edid_cea_modes db, which is going to affect only
> add_cea/alternate_cea_modes() call, and the modes accordingly.
> Please let me know if I misunderstood something here.
We explicitly sort the modes after this.
>
> Regards
> Shashank
> >> If X server doesn't know what to do with aspect ratio flags, it can
> >> chose not to set the cap, and if HWC knows, it can chose to set. This is
> >> the same situation as 2D stereo modes
> >> which are existing already.
> >>
> >> Regards
> >> Shashank
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Hannes Frederic Sowa @ 2016-11-14 16:44 UTC (permalink / raw)
To: Jason A. Donenfeld, David Ahern, Netdev, WireGuard mailing list,
LKML, YOSHIFUJI Hideaki
In-Reply-To: <20161113232813.28926-1-Jason@zx2c4.com>
On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
> This puts the IPv6 routing functions in parity with the IPv4 routing
> functions. Namely, we now check in v6 that if a flowi6 requests an
> saddr, the returned dst actually corresponds to a net device that has
> that saddr. This mirrors the v4 logic with __ip_dev_find in
> __ip_route_output_key_hash. In the event that the returned dst is not
> for a dst with a dev that has the saddr, we return -EINVAL, just like
> v4; this makes it easy to use the same error handlers for both cases.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: David Ahern <dsa@cumulusnetworks.com>
> ---
> Changes from v2:
> It turns out ipv6_chk_addr already has the device enumeration
> logic that we need by simply passing NULL.
>
> net/ipv6/ip6_output.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 6001e78..b3b5cb6 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
> const struct sock *sk,
> int err;
> int flags = 0;
>
> + if (!ipv6_addr_any(&fl6->saddr) &&
> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
> + return -EINVAL;
Hmm, this check is too permissive, no?
E.g. what happens if you move a link local address from one interface to
another? In this case this code would still allow the saddr to be used.
I just also quickly read up on the history (sorry was travelling last
week) and wonder if you ever saw a user space facing bug or if this is
basically some difference you saw while writing out of tree code?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH 0/2] Salvator-X: Add GPIO keys support
From: Laurent Pinchart @ 2016-11-14 16:44 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Laurent Pinchart, Linux-Renesas, Kieran Bingham
In-Reply-To: <CAMuHMdVs7BSYOiPHvSnmP4+OGZVyGL6K+X3i9DT4VBfqBRxtzw@mail.gmail.com>
Hi Geert,
On Monday 14 Nov 2016 14:47:00 Geert Uytterhoeven wrote:
> On Mon, Nov 14, 2016 at 2:41 PM, Laurent Pinchart wrote:
> > On Monday 14 Nov 2016 14:35:26 Geert Uytterhoeven wrote:
> >> The main reason I haven't sent out a similar series yet is because the
> >> GPIOs used for the 3 push buttons are shared with the 3 user LEDs. For
> >> each of them, you have to choose at DT time if you want to use them as
> >> buttons or as LEDs.
> >>
> >> On ULCB, the same issue is present. For those, we settled on 1 key and 2
> >> LEDs...
> >>
> >> Looking forward to more comments...
> >
> > In theory the GPIOs could be shared by the gpio-keys and LED drivers in
> > open- drain mode. I'm not sure the GPIO subsystem supports that though.
>
> Been there, done that, cfr. "[RFD] Sharing GPIOs for input (buttons) and
> output (LEDs)". The result wasn't pretty...
Wasn't it ? Linus basically told you to use open-drain GPIOs and fix the GPIO
driver in case it can't read the value of GPIOs configured as output in open-
drain mode. If didn't shoot the idea down.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] mm/pkeys: generate pkey system call code only if ARCH_HAS_PKEYS is selected
From: Dave Hansen @ 2016-11-14 16:44 UTC (permalink / raw)
To: Heiko Carstens, Andrew Morton
Cc: linux-arch, linux-kernel, linux-mm, Mark Rutland
In-Reply-To: <20161114111251.70084-1-heiko.carstens@de.ibm.com>
On 11/14/2016 03:12 AM, Heiko Carstens wrote:
> Having code for the pkey_mprotect, pkey_alloc and pkey_free system
> calls makes only sense if ARCH_HAS_PKEYS is selected. If not selected
> these system calls will always return -ENOSPC or -EINVAL.
>
> To simplify things and have less code generate the pkey system call
> code only if ARCH_HAS_PKEYS is selected.
>
> For architectures which have already wired up the system calls, but do
> not select ARCH_HAS_PKEYS this will result in less generated code and
> a different return code: the three system calls will now always return
> -ENOSYS, using the cond_syscall mechanism.
>
> For architectures which have not wired up the system calls less
> unreachable code will be generated.
>
> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
This is fine with me. FWIW:
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
^ permalink raw reply
* Re: [PATCH] mm/pkeys: generate pkey system call code only if ARCH_HAS_PKEYS is selected
From: Dave Hansen @ 2016-11-14 16:44 UTC (permalink / raw)
To: Heiko Carstens, Andrew Morton
Cc: linux-arch, linux-kernel, linux-mm, Mark Rutland
In-Reply-To: <20161114111251.70084-1-heiko.carstens@de.ibm.com>
On 11/14/2016 03:12 AM, Heiko Carstens wrote:
> Having code for the pkey_mprotect, pkey_alloc and pkey_free system
> calls makes only sense if ARCH_HAS_PKEYS is selected. If not selected
> these system calls will always return -ENOSPC or -EINVAL.
>
> To simplify things and have less code generate the pkey system call
> code only if ARCH_HAS_PKEYS is selected.
>
> For architectures which have already wired up the system calls, but do
> not select ARCH_HAS_PKEYS this will result in less generated code and
> a different return code: the three system calls will now always return
> -ENOSYS, using the cond_syscall mechanism.
>
> For architectures which have not wired up the system calls less
> unreachable code will be generated.
>
> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
This is fine with me. FWIW:
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] IB/mlx4: Rework special QP creation error path
From: Bart Van Assche @ 2016-11-14 16:44 UTC (permalink / raw)
To: Doug Ledford
Cc: Yishai Hadas, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
The special QP creation error path relies on offset_of(struct mlx4_ib_sqp,
qp) == 0. Remove this assumption because that makes the QP creation
code easier to understand.
Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
Cc: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/infiniband/hw/mlx4/qp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index 570bc86..b63d6be 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -644,7 +644,7 @@ static int create_qp_common(struct mlx4_ib_dev *dev, struct ib_pd *pd,
int qpn;
int err;
struct ib_qp_cap backup_cap;
- struct mlx4_ib_sqp *sqp;
+ struct mlx4_ib_sqp *sqp = NULL;
struct mlx4_ib_qp *qp;
enum mlx4_ib_qp_type qp_type = (enum mlx4_ib_qp_type) init_attr->qp_type;
struct mlx4_ib_cq *mcq;
@@ -933,7 +933,9 @@ static int create_qp_common(struct mlx4_ib_dev *dev, struct ib_pd *pd,
mlx4_db_free(dev->dev, &qp->db);
err:
- if (!*caller_qp)
+ if (sqp)
+ kfree(sqp);
+ else if (!*caller_qp)
kfree(qp);
return err;
}
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 2/6] mfd: stm32-adc: Add support for stm32 ADC
From: Lee Jones @ 2016-11-14 16:47 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Fabrice Gasnier, linux-iio, linux-arm-kernel, devicetree,
linux-kernel, linux, robh+dt, mark.rutland, mcoquelin.stm32,
alexandre.torgue, lars, knaack.h, pmeerw
In-Reply-To: <9ba617f4-fd3d-2b48-2607-9eec3cc4253a@kernel.org>
On Sat, 12 Nov 2016, Jonathan Cameron wrote:
> On 10/11/16 16:18, Fabrice Gasnier wrote:
> > Add core driver for STMicroelectronics STM32 ADC (Analog to Digital
> > Converter). STM32 ADC can be composed of up to 3 ADCs with shared
> > resources like clock prescaler, common interrupt line and analog
> > reference voltage.
> > This core driver basically manages shared resources.
> >
> > Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> Looks good to me (other than the build issue obviously ;)
>
> The fun bit will be trying to keep the whole thing this clean as you
> add the more 'interesting' functionality. *fingers crossed*
>
> Acked-by: Jonathan Cameron <jic23@kernel.org>
There isn't anything MFD about this driver.
Please move it into IIO.
> > ---
> > drivers/mfd/Kconfig | 14 ++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/stm32-adc-core.c | 301 +++++++++++++++++++++++++++++++++++++
> > include/linux/mfd/stm32-adc-core.h | 52 +++++++
> > 4 files changed, 368 insertions(+)
> > create mode 100644 drivers/mfd/stm32-adc-core.c
> > create mode 100644 include/linux/mfd/stm32-adc-core.h
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index c6df644..2580cee 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -1152,6 +1152,20 @@ config MFD_PALMAS
> > If you say yes here you get support for the Palmas
> > series of PMIC chips from Texas Instruments.
> >
> > +config MFD_STM32_ADC
> > + tristate "STMicroelectronics STM32 adc"
> > + depends on ARCH_STM32 || COMPILE_TEST
> > + depends on OF
> > + select MFD_CORE
> > + select REGULATOR
> > + select REGULATOR_FIXED_VOLTAGE
> > + help
> > + Select this option to enable the core driver for STMicroelectronics
> > + STM32 analog-to-digital converter (ADC).
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called stm32-adc-core.
> > +
> > config TPS6105X
> > tristate "TI TPS61050/61052 Boost Converters"
> > depends on I2C
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 9834e66..4571506 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -185,6 +185,7 @@ obj-$(CONFIG_MFD_INTEL_LPSS_PCI) += intel-lpss-pci.o
> > obj-$(CONFIG_MFD_INTEL_LPSS_ACPI) += intel-lpss-acpi.o
> > obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
> > obj-$(CONFIG_MFD_PALMAS) += palmas.o
> > +obj-$(CONFIG_MFD_STM32_ADC) += stm32-adc-core.o
> > obj-$(CONFIG_MFD_VIPERBOARD) += viperboard.o
> > obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
> > obj-$(CONFIG_MFD_RK808) += rk808.o
> > diff --git a/drivers/mfd/stm32-adc-core.c b/drivers/mfd/stm32-adc-core.c
> > new file mode 100644
> > index 0000000..bcf52fb
> > --- /dev/null
> > +++ b/drivers/mfd/stm32-adc-core.c
> > @@ -0,0 +1,301 @@
> > +/*
> > + * This file is part of STM32 ADC driver
> > + *
> > + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
> > + * Author: Fabrice Gasnier <fabrice.gasnier@st.com>.
> > + *
> > + * Inspired from: fsl-imx25-tsadc
> > + *
> > + * License type: GPLv2
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License version 2 as published by
> > + * the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> > + * or FITNESS FOR A PARTICULAR PURPOSE.
> > + * See the GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License along with
> > + * this program. If not, see <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irqchip/chained_irq.h>
> > +#include <linux/irqdesc.h>
> > +#include <linux/irqdomain.h>
> > +#include <linux/mfd/stm32-adc-core.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/slab.h>
> > +
> > +/* STM32F4 - common registers for all ADC instances: 1, 2 & 3 */
> > +#define STM32F4_ADC_CSR (STM32_ADCX_COMN_OFFSET + 0x00)
> > +#define STM32F4_ADC_CCR (STM32_ADCX_COMN_OFFSET + 0x04)
> > +
> > +/* STM32F4_ADC_CSR - bit fields */
> > +#define STM32F4_EOC3 BIT(17)
> > +#define STM32F4_EOC2 BIT(9)
> > +#define STM32F4_EOC1 BIT(1)
> > +
> > +/* STM32F4_ADC_CCR - bit fields */
> > +#define STM32F4_ADC_ADCPRE_SHIFT 16
> > +#define STM32F4_ADC_ADCPRE_MASK GENMASK(17, 16)
> > +
> > +/* STM32 F4 maximum analog clock rate (from datasheet) */
> > +#define STM32F4_ADC_MAX_CLK_RATE 36000000
> > +
> > +/**
> > + * struct stm32_adc_priv - stm32 ADC core private data
> > + * @irq: irq for ADC block
> > + * @domain: irq domain reference
> > + * @aclk: clock reference for the analog circuitry
> > + * @vref: regulator reference
> > + * @common: common data for all ADC instances
> > + */
> > +struct stm32_adc_priv {
> > + int irq;
> > + struct irq_domain *domain;
> > + struct clk *aclk;
> > + struct regulator *vref;
> > + struct stm32_adc_common common;
> > +};
> > +
> > +static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
> > +{
> > + return container_of(com, struct stm32_adc_priv, common);
> > +}
> > +
> > +/* STM32F4 ADC internal common clock prescaler division ratios */
> > +static int stm32f4_pclk_div[] = {2, 4, 6, 8};
> > +
> > +/**
> > + * stm32f4_adc_clk_sel() - Select stm32f4 ADC common clock prescaler
> > + * @priv: stm32 ADC core private data
> > + * Select clock prescaler used for analog conversions, before using ADC.
> > + */
> > +static int stm32f4_adc_clk_sel(struct platform_device *pdev,
> > + struct stm32_adc_priv *priv)
> > +{
> > + unsigned long rate;
> > + u32 val;
> > + int i;
> > +
> > + rate = clk_get_rate(priv->aclk);
> > + for (i = 0; i < ARRAY_SIZE(stm32f4_pclk_div); i++) {
> > + if ((rate / stm32f4_pclk_div[i]) <= STM32F4_ADC_MAX_CLK_RATE)
> > + break;
> > + }
> > + if (i >= ARRAY_SIZE(stm32f4_pclk_div))
> > + return -EINVAL;
> > +
> > + val = readl_relaxed(priv->common.base + STM32F4_ADC_CCR);
> > + val &= ~STM32F4_ADC_ADCPRE_MASK;
> > + val |= i << STM32F4_ADC_ADCPRE_SHIFT;
> > + writel_relaxed(val, priv->common.base + STM32F4_ADC_CCR);
> > +
> > + dev_dbg(&pdev->dev, "Using analog clock source at %ld kHz\n",
> > + rate / (stm32f4_pclk_div[i] * 1000));
> > +
> > + return 0;
> > +}
> > +
> > +/* ADC common interrupt for all instances */
> > +static void stm32_adc_irq_handler(struct irq_desc *desc)
> > +{
> > + struct stm32_adc_priv *priv = irq_desc_get_handler_data(desc);
> > + struct irq_chip *chip = irq_desc_get_chip(desc);
> > + u32 status;
> > +
> > + chained_irq_enter(chip, desc);
> > + status = readl_relaxed(priv->common.base + STM32F4_ADC_CSR);
> > +
> > + if (status & STM32F4_EOC1)
> > + generic_handle_irq(irq_find_mapping(priv->domain, 0));
> > +
> > + if (status & STM32F4_EOC2)
> > + generic_handle_irq(irq_find_mapping(priv->domain, 1));
> > +
> > + if (status & STM32F4_EOC3)
> > + generic_handle_irq(irq_find_mapping(priv->domain, 2));
> > +
> > + chained_irq_exit(chip, desc);
> > +};
> > +
> > +static int stm32_adc_domain_map(struct irq_domain *d, unsigned int irq,
> > + irq_hw_number_t hwirq)
> > +{
> > + irq_set_chip_data(irq, d->host_data);
> > + irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_level_irq);
> > +
> > + return 0;
> > +}
> > +
> > +static void stm32_adc_domain_unmap(struct irq_domain *d, unsigned int irq)
> > +{
> > + irq_set_chip_and_handler(irq, NULL, NULL);
> > + irq_set_chip_data(irq, NULL);
> > +}
> > +
> > +static const struct irq_domain_ops stm32_adc_domain_ops = {
> > + .map = stm32_adc_domain_map,
> > + .unmap = stm32_adc_domain_unmap,
> > + .xlate = irq_domain_xlate_onecell,
> > +};
> > +
> > +static int stm32_adc_irq_probe(struct platform_device *pdev,
> > + struct stm32_adc_priv *priv)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > +
> > + priv->irq = platform_get_irq(pdev, 0);
> > + if (priv->irq < 0) {
> > + dev_err(&pdev->dev, "failed to get irq\n");
> > + return priv->irq;
> > + }
> > +
> > + priv->domain = irq_domain_add_simple(np, STM32_ADC_MAX_ADCS, 0,
> > + &stm32_adc_domain_ops,
> > + priv);
> > + if (!priv->domain) {
> > + dev_err(&pdev->dev, "Failed to add irq domain\n");
> > + return -ENOMEM;
> > + }
> > +
> > + irq_set_chained_handler(priv->irq, stm32_adc_irq_handler);
> > + irq_set_handler_data(priv->irq, priv);
> > +
> > + return 0;
> > +}
> > +
> > +static void stm32_adc_irq_remove(struct platform_device *pdev,
> > + struct stm32_adc_priv *priv)
> > +{
> > + int hwirq;
> > +
> > + for (hwirq = 0; hwirq < STM32_ADC_MAX_ADCS; hwirq++)
> > + irq_dispose_mapping(irq_find_mapping(priv->domain, hwirq));
> > + irq_domain_remove(priv->domain);
> > + irq_set_chained_handler(priv->irq, NULL);
> > +}
> > +
> > +static int stm32_adc_probe(struct platform_device *pdev)
> > +{
> > + struct stm32_adc_priv *priv;
> > + struct device_node *np = pdev->dev.of_node;
> > + struct resource *res;
> > + int ret;
> > +
> > + if (!pdev->dev.of_node)
> > + return -ENODEV;
> > +
> > + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + priv->common.base = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(priv->common.base))
> > + return PTR_ERR(priv->common.base);
> > +
> > + priv->vref = devm_regulator_get(&pdev->dev, "vref");
> > + if (IS_ERR(priv->vref)) {
> > + ret = PTR_ERR(priv->vref);
> > + dev_err(&pdev->dev, "vref get failed, %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = regulator_enable(priv->vref);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "vref enable failed\n");
> > + return ret;
> > + }
> > +
> > + ret = regulator_get_voltage(priv->vref);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "vref get voltage failed, %d\n", ret);
> > + goto err_regulator_disable;
> > + }
> > + priv->common.vref_mv = ret / 1000;
> > + dev_dbg(&pdev->dev, "vref+=%dmV\n", priv->common.vref_mv);
> > +
> > + priv->aclk = devm_clk_get(&pdev->dev, "adc");
> > + if (IS_ERR(priv->aclk)) {
> > + ret = PTR_ERR(priv->aclk);
> > + dev_err(&pdev->dev, "Can't get 'adc' clock\n");
> > + goto err_regulator_disable;
> > + }
> > +
> > + ret = clk_prepare_enable(priv->aclk);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "adc clk enable failed\n");
> > + goto err_regulator_disable;
> > + }
> > +
> > + ret = stm32f4_adc_clk_sel(pdev, priv);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "adc clk selection failed\n");
> > + goto err_clk_disable;
> > + }
> > +
> > + ret = stm32_adc_irq_probe(pdev, priv);
> > + if (ret < 0)
> > + goto err_clk_disable;
> > +
> > + platform_set_drvdata(pdev, &priv->common);
> > +
> > + ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "failed to populate DT children\n");
> > + goto err_irq_remove;
> > + }
> > +
> > + return 0;
> > +
> > +err_irq_remove:
> > + stm32_adc_irq_remove(pdev, priv);
> > +
> > +err_clk_disable:
> > + clk_disable_unprepare(priv->aclk);
> > +
> > +err_regulator_disable:
> > + regulator_disable(priv->vref);
> > +
> > + return ret;
> > +}
> > +
> > +static int stm32_adc_remove(struct platform_device *pdev)
> > +{
> > + struct stm32_adc_common *common = platform_get_drvdata(pdev);
> > + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
> > +
> > + of_platform_depopulate(&pdev->dev);
> > + stm32_adc_irq_remove(pdev, priv);
> > + clk_disable_unprepare(priv->aclk);
> > + regulator_disable(priv->vref);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id stm32_adc_of_match[] = {
> > + { .compatible = "st,stm32f4-adc-core" },
> > +};
> > +MODULE_DEVICE_TABLE(of, stm32_adc_of_match);
> > +
> > +static struct platform_driver stm32_adc_driver = {
> > + .probe = stm32_adc_probe,
> > + .remove = stm32_adc_remove,
> > + .driver = {
> > + .name = "stm32-adc-core",
> > + .of_match_table = stm32_adc_of_match,
> > + },
> > +};
> > +module_platform_driver(stm32_adc_driver);
> > +
> > +MODULE_AUTHOR("Fabrice Gasnier <fabrice.gasnier@st.com>");
> > +MODULE_DESCRIPTION("STMicroelectronics STM32 ADC MFD driver");
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_ALIAS("platform:stm32-adc-core");
> > diff --git a/include/linux/mfd/stm32-adc-core.h b/include/linux/mfd/stm32-adc-core.h
> > new file mode 100644
> > index 0000000..081fa5f
> > --- /dev/null
> > +++ b/include/linux/mfd/stm32-adc-core.h
> > @@ -0,0 +1,52 @@
> > +/*
> > + * This file is part of STM32 ADC driver
> > + *
> > + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
> > + * Author: Fabrice Gasnier <fabrice.gasnier@st.com>.
> > + *
> > + * License type: GPLv2
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License version 2 as published by
> > + * the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> > + * or FITNESS FOR A PARTICULAR PURPOSE.
> > + * See the GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License along with
> > + * this program. If not, see <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#ifndef __STM32_ADC_H
> > +#define __STM32_ADC_H
> > +
> > +/*
> > + * STM32 - ADC global register map
> > + * ________________________________________________________
> > + * | Offset | Register |
> > + * --------------------------------------------------------
> > + * | 0x000 | Master ADC1 |
> > + * --------------------------------------------------------
> > + * | 0x100 | Slave ADC2 |
> > + * --------------------------------------------------------
> > + * | 0x200 | Slave ADC3 |
> > + * --------------------------------------------------------
> > + * | 0x300 | Master & Slave common regs |
> > + * --------------------------------------------------------
> > + */
> > +#define STM32_ADC_MAX_ADCS 3
> > +#define STM32_ADCX_COMN_OFFSET 0x300
> > +
> > +/**
> > + * struct stm32_adc_common - stm32 ADC driver common data (for all instances)
> > + * @base: control registers base cpu addr
> > + * @vref_mv: vref voltage (mv)
> > + */
> > +struct stm32_adc_common {
> > + void __iomem *base;
> > + int vref_mv;
> > +};
> > +
> > +#endif
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Paolo Bonzini @ 2016-11-14 16:43 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <20161114154015.GA30048@amt.cnet>
On 14/11/2016 16:40, Marcelo Tosatti wrote:
> static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> {
> KVMClockState *s = opaque;
>
> /*
> * On machine types that support reliable KVM_GET_CLOCK,
> * if host kernel does provide reliable KVM_GET_CLOCK,
> * set src_use_reliable_get_clock=true so that destination
> * avoids reading kvmclock from memory.
> */
> if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable())
> {
> s->src_use_reliable_get_clock = true;
> }
>
> return s->mach_use_reliable_get_clock;
> }
>
>
> Ah, OK, done.
s->src_use_reliable_get_clock should not be set with
KVM_CHECK_EXTENSION, but rather from the flags returned by KVM_GET_CLOCK.
> So s->src_use_reliable_get_clock is only used to indicate
> to the destination that: "you can use KVM_GET_CLOCK value,
> its safe".
Yes, we agree. I was listing all the points, not just those where we
disagree. Actually I'm not sure where we disagree, except on using
flags from KVM_CHECK_EXTENSION vs. flags from KVM_GET_CLOCK...
Paolo
^ permalink raw reply
* Re: [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Paolo Bonzini @ 2016-11-14 16:43 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <20161114154015.GA30048@amt.cnet>
On 14/11/2016 16:40, Marcelo Tosatti wrote:
> static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> {
> KVMClockState *s = opaque;
>
> /*
> * On machine types that support reliable KVM_GET_CLOCK,
> * if host kernel does provide reliable KVM_GET_CLOCK,
> * set src_use_reliable_get_clock=true so that destination
> * avoids reading kvmclock from memory.
> */
> if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable())
> {
> s->src_use_reliable_get_clock = true;
> }
>
> return s->mach_use_reliable_get_clock;
> }
>
>
> Ah, OK, done.
s->src_use_reliable_get_clock should not be set with
KVM_CHECK_EXTENSION, but rather from the flags returned by KVM_GET_CLOCK.
> So s->src_use_reliable_get_clock is only used to indicate
> to the destination that: "you can use KVM_GET_CLOCK value,
> its safe".
Yes, we agree. I was listing all the points, not just those where we
disagree. Actually I'm not sure where we disagree, except on using
flags from KVM_CHECK_EXTENSION vs. flags from KVM_GET_CLOCK...
Paolo
^ permalink raw reply
* Re: Creating 'wic' image
From: Maciej Borzęcki @ 2016-11-14 16:42 UTC (permalink / raw)
To: Mike Looijmans; +Cc: OE-core
In-Reply-To: <95b4383a-727c-a022-9a9a-5398c7dabf36@topic.nl>
On Mon, Nov 14, 2016 at 4:23 PM, Mike Looijmans <mike.looijmans@topic.nl> wrote:
> In order to make life easier for people, I was looking into creating images
> with the "wic" tool.
>
> There's just one big piece of documentation lacking: What's the format it
> wants my rootfs and boot files?
> http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html
I agree that wic is not exactly user-friendly, even after going through
the documentation.
There is no 'special 'format for rootfs or boot files. All that wic does
is assemble a disk image with partitions specified in kickstart file.
Partitions are created by source plugins (scripts/lib/wic/plugins/source
in poky tree).
Currently, you'll find the following files there (I'll comment on the
ones I use[d]):
- bootimg-efi.py
- bootimg-partition.py
Creates a partition of given --fstype and populates it with files
listed in IMAGE_BOOT_FILES. The files must exist in DEPLOY_DIR_IMAGE.
For instance, you can use this plugin to prepare a boot partition for
BeagleBone Black, copying over MLO and u-boot.img. Alternatively you
could also prepare a boot partition for Raspberry Pi, copying over
Broadcom files and kernel image. See
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-IMAGE_BOOT_FILES
https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/conf/machine/include/rpi-base.inc#n55
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf/machine/beaglebone.conf#n42
- bootimg-pcbios.py
- fsimage.py
This one can be used if you happen to have a filesystem image ready.
We actually use it in Mender because currently, wic lacks the ability
to specify a fixed size of a partition (a patch series adding that was
posted).
The way it works, you are assumed to have a file system image ready
upfront and then just specify it like this in kickstart:
part / --source fsimage --sourceparams=file=<path> --ondisk
mmcblk0 --label primary
- isoimage-isohybrid.py
For all I know, this one requires syslinux.
- rawcopy.py
rawcopy puts a verbatim copy of a file inside the disk image,
basically covers a use case when, for instance, you need to place a
bootloader at a specific offset. Minor quirks:
- you are not able to explicitly specify offset, hence commonly used
with --align,
- it's usually undesirable to have a partition table entry for this
partition, hence often used with --no-table
- rootfs_pcbios_ext.py
- rootfs.py
Creates a partition image with contents of rootfs of a particular
image (if -e was used) or some directory (not necessarily the actualy
rootfs). The file system to use is determined by --fstype.
>
> Basically I want an SD card with a FAT boot partition and an ext4 rootfs,
> and "sdimage-bootpart" is pretty close to that.
The 'sdimage-bootpart' image is actually used by beaglebone (as defined
in meta-yocto-bsp). Machine config sets this:
WKS_FILE = "sdimage-bootpart.wks"
See
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf/machine/beaglebone.conf#n21
for reference
>
> Without "wic", I build a tar of the rootfs and copy the boot files using a
> bit of shell scripting.
>
> Adding "wic" to IMAGE_FSTYPES just results in an error that I should set
> WKS_FILE but I have no clue as to what file that should point to.
>
> Running wic manually just results in more missing variables that I can't
> find what to specify in them...
Another thing that is not obvious is that wic will not cause bitbake to
build native tools that may be required when building in image. The user
is expected to figure out by themselves.
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf/machine/beaglebone.conf#n23
Hope that helps.
Cheers,
--
Maciej Borzecki
RnDity
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Lorenzo Pieralisi @ 2016-11-14 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114155222.GZ2078@8bytes.org>
On Mon, Nov 14, 2016 at 04:52:23PM +0100, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
> > If we've already made the decision to move away from bus ops, I don't
> > see that it makes sense to deliberately introduce new dependencies on
> > them. Besides, as it stands, this patch literally implements "tell the
> > iommu-core which hardware-iommus exist in the system and a seperate
> > iommu_ops ptr for each of them" straight off.
>
> Not sure which code you are looking at, but as I see it we have only
> per-device iommu-ops now (with this patch). That is different from
> having core-visible hardware-iommu instances where devices could link
> to.
This patch enables the IOMMU-OF-node<->device look-up on non-OF (ie
ACPI) systems by "converting" the of_node to a generic fwnode_handle,
that's all it does (and move the related look-up code from
drivers/iommu/of_iommu.c to drivers/iommu/iommu.c so that it does
not depend on OF_IOMMU any longer).
> Also the rest of iommu-core code still makes use of the per-bus ops. The
> per-device ops are only used for the of_xlate fn-ptr.
I can put this patch on the backburner and retrieve the iommu_ops
through the dev->bus path in the IORT xlate function (iort_iommu_xlate()
introduced in the last patch), the change is trivial and should work
just fine but it deserves a v8 to give everyone a chance to test it.
We would end-up handling the device->iommu_ops look-up differently in DT
and ACPI for streamid translations though, I am not sure I see a reason
why.
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Lorenzo Pieralisi @ 2016-11-14 16:42 UTC (permalink / raw)
To: Joerg Roedel
Cc: Robin Murphy, iommu, Will Deacon, Hanjun Guo, Marc Zyngier,
Rafael J. Wysocki, Tomasz Nowicki, Jon Masters, Eric Auger,
Sinan Kaya, Nate Watterson, Prem Mallappa, Dennis Chen,
linux-acpi, linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20161114155222.GZ2078@8bytes.org>
On Mon, Nov 14, 2016 at 04:52:23PM +0100, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
> > If we've already made the decision to move away from bus ops, I don't
> > see that it makes sense to deliberately introduce new dependencies on
> > them. Besides, as it stands, this patch literally implements "tell the
> > iommu-core which hardware-iommus exist in the system and a seperate
> > iommu_ops ptr for each of them" straight off.
>
> Not sure which code you are looking at, but as I see it we have only
> per-device iommu-ops now (with this patch). That is different from
> having core-visible hardware-iommu instances where devices could link
> to.
This patch enables the IOMMU-OF-node<->device look-up on non-OF (ie
ACPI) systems by "converting" the of_node to a generic fwnode_handle,
that's all it does (and move the related look-up code from
drivers/iommu/of_iommu.c to drivers/iommu/iommu.c so that it does
not depend on OF_IOMMU any longer).
> Also the rest of iommu-core code still makes use of the per-bus ops. The
> per-device ops are only used for the of_xlate fn-ptr.
I can put this patch on the backburner and retrieve the iommu_ops
through the dev->bus path in the IORT xlate function (iort_iommu_xlate()
introduced in the last patch), the change is trivial and should work
just fine but it deserves a v8 to give everyone a chance to test it.
We would end-up handling the device->iommu_ops look-up differently in DT
and ACPI for streamid translations though, I am not sure I see a reason
why.
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
From: Sharma, Shashank @ 2016-11-14 16:42 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Jose Abreu, Jia, Lin A, Akashdeep Sharma, Emil Velikov, dri-devel,
Daniel Vetter, Jim Bride
In-Reply-To: <20161114162041.GZ31595@intel.com>
Regards
Shashank
On 11/14/2016 9:50 PM, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 09:37:18PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
>>> On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
>>>> Regards
>>>> Shashank
>>>>> the revert:
>>>>>
>>>>> HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 700mm x 390mm
>>>>> - 1920x1080 60.00*+
>>>>> - 1920x1080i 60.00 50.00
>>>>> + 1920x1080 60.00*+ 50.00 59.94 30.00 25.00 24.00 29.97 23.98
>>>>> + 1920x1080i 60.00 50.00 59.94
>>>>> 1600x1200 60.00
>>>>> 1680x1050 59.88
>>>>> 1280x1024 75.02 60.02
>>>>> @@ -13,30 +13,29 @@
>>>>> 1360x768 60.02
>>>>> 1280x800 59.91
>>>>> 1152x864 75.00
>>>>> - 1280x720 60.00 50.00
>>>>> + 1280x720 60.00 50.00 59.94
>>>>> 1024x768 75.03 70.07 60.00
>>>>> 832x624 74.55
>>>>> 800x600 72.19 75.00 60.32
>>>>> - 640x480 75.00 72.81 66.67 59.94
>>>>> + 720x576 50.00
>>>>> + 720x480 60.00 59.94
>>>>> + 640x480 75.00 72.81 66.67 60.00 59.94
>>>>> 720x400 70.08
>>>> None of these aspect ratios are new modes / new aspect ratios from HDMI
>>>> 2.0/CEA-861-F
>>>> These are the existing modes, and should be independent of reverted
>>>> patches.
>>> They're affected because your patches changed them by adding the aspect
>>> ratio flags to them.
>> Yes, But they are independent of reverted patch, which adds aspect ratio
>> for HDMI 2.0 ratios (64:27 and 256:135)
> The second patch had to be reverted so that the first patch would revert
> cleanly.
>
>>>>> This was with sna, which does this:
>>>>> #define KNOWN_MODE_FLAGS ((1<<14)-1)
>>>>> if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
>>>>> mode->status = MODE_BAD; /* unknown flags => unhandled */
>>>>> so all the modes with an aspect ratio just vanished.
>>>>>
>>>>> -modesetting and -ati on the other hand just copy over the unknown
>>>>> bits into the xrandr mode structure, which sounds dubious at best:
>>>>> mode->Flags = kmode->flags; //& FLAG_BITS;
>>>>> I've not checked what damage it can actually cause.
>>>>>
>>>>>
>>>>> It looks like a few modes disappeared from the kernel's mode list
>>>>> as well, presumably because some cea modes in the list originated from
>>>>> DTDs and whanot so they don't have an aspect ratio and that causes
>>>>> add_alternate_cea_modes() to ignore them. So not populating an aspect
>>>>> ratio for cea modes originating from a source other than
>>>>> edid_cea_modes[] looks like another bug to me as well.
>>>> I am writing a patch series to cap the aspect ratio implementation under
>>>> a drm_cap_hdmi2_aspect_ratios
>>>> This is how its going to work (inspired from the 2D/stereo series from
>>>> damien L)
>>>>
>>>> - Add a new capability hdmi2_ar
>>> It should be just a generic "expose aspect ratio flags to userspace?"
>> Makes sense, in this way we can even revert the aspect_ratio property
>> for HDMI connector, as discussed during
>> the code review sessions of this patch series. In this way, when kernel
>> will expose the aspect ratios, it will either
>> do the aspect ratios as per EDID, or wont.
>>>> - by default parsing the new hdmi 2.0 aspect ratio will be disabled
>>>> under check of this cap
>>>> - during bootup time, while initializing the display, a userspace can
>>>> get_cap on the hdmi2_aspect_ratio
>>>> - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
>>>> kernel will expose these aspect ratios
>>>>> Another bug I think might be the ordering of the modes with aspect ratio
>>>>> specified. IIRC the spec says that the preferred aspect ratio should be
>>>>> listed first in the EDID, but I don't think we preserve that ordering
>>>>> in the final mode list. I guess we could fix that by somehow noting
>>>>> which aspect ratio is preferred and sort based on that, or we try to
>>>>> preserve the order from the EDID until we're ready to sort, and then do
>>>>> the sorting with a stable algorithm.
>>>> AFAIK The mode order and priority is decided and arranged in userspace,
>>>> based on various factors like
>>>> - preferred mode.
>>>> - previously applied mode in previous sessions (like for android tvs)
>>>> - Bigger h/w vs better refresh rate ?
>>>> - Xserver applies its own algorithms to decide which mode should be
>>>> shown first.
>>> Xorg does sort on its own. But since it doesn't know anything about
>>> aspect ratios and whatnot I wouldn't rely on that for anything. I
>>> also wouldn't expect eg. wayland compositors to do their own sorting.
>>> And yeah, looks like weston at least doesn't do any sorting whatsoever.
>>>
>>>> I dont think kernel needs to bother about it.
>>> So I'm going to say that we in fact do need to bother.
>>>
>> IMHO, making policies for UI is not a part of kernel design, a UI
>> manager (Hardware composed, X or Wayland) should take care of it, as
>> they have access to much information (Like previously applied mode, user
>> preference etc). When it comes to sorting of modes, the only general rule
>> across drivers like FB, V4L2, I have seen is the first mode in the list
>> should be preferred mode, which we are still keeping. And after that our
>> probed_modes were
>> anyways not sorted now, so it doesn't matter further.
> Having userspace be responsible for sorting the aspect ratios would
> perhaps require that userspace parses the EDID, which is pretty crazy.
Why ?
userspace has to just set cap for aspect ratio, and kernel can read
EDID, parse the CEA block, populate the aspect ratios flags
and add the modes (Just what this patch was doing, except the cap part)
Once userspace has the getResources/getConnector call filled, it can
access all the modes (with and without aspect) and do the sorting
in any way it wants.
> I guess it could try to deduce something from the physical aspect ratio
> of the display, but I'm not sure that's quite what we want either.
>
> Also we already sort the modes in the kernel anyway, so it's not like
> we'd be doing something new by also considering the aspect ratios.
> I would at the very least want to avoid a totally random order between
> modes that differ only by the aspect ratio.
Path: get_connector -> probe_single_connector_mode -> drm_add_edid_modes
Again, IMHO, we don't sort the modes in kernel, we populate modes in a
particular order, which is:
(From drm_edid.c::drm_add_edid_modes)
##############################################################
/*
* EDID spec says modes should be preferred in this order:
* - preferred detailed mode
* - other detailed modes from base block
* - detailed modes from extension blocks
* - CVT 3-byte code modes
* - standard timing codes
* - established timing codes
* - modes inferred from GTF or CVT range information
*
* We get this pretty much right.
*
* XXX order for additional mode types in extension blocks?
*/
num_modes += add_detailed_modes(connector, edid, quirks);
num_modes += add_cvt_modes(connector, edid);
num_modes += add_standard_modes(connector, edid);
num_modes += add_established_modes(connector, edid);
num_modes += add_cea_modes(connector, edid);
num_modes += add_alternate_cea_modes(connector, edid);
num_modes += add_displayid_detailed_modes(connector, edid);
###############################################################
Here the modes are added in the connector, in the same order they are
arranged into their respective blocks in EDID.
But the order to read the block is a preferred order (no sorting).
Now, in this patch series, we are adding aspect ratio information in
edid_cea_modes db, which is going to affect only
add_cea/alternate_cea_modes() call, and the modes accordingly.
Please let me know if I misunderstood something here.
Regards
Shashank
>> If X server doesn't know what to do with aspect ratio flags, it can
>> chose not to set the cap, and if HWC knows, it can chose to set. This is
>> the same situation as 2D stereo modes
>> which are existing already.
>>
>> Regards
>> Shashank
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Hannes Frederic Sowa @ 2016-11-14 16:44 UTC (permalink / raw)
To: Jason A. Donenfeld, David Ahern, Netdev, WireGuard mailing list,
LKML, YOSHIFUJI Hideaki
In-Reply-To: <20161113232813.28926-1-Jason@zx2c4.com>
On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
> This puts the IPv6 routing functions in parity with the IPv4 routing
> functions. Namely, we now check in v6 that if a flowi6 requests an
> saddr, the returned dst actually corresponds to a net device that has
> that saddr. This mirrors the v4 logic with __ip_dev_find in
> __ip_route_output_key_hash. In the event that the returned dst is not
> for a dst with a dev that has the saddr, we return -EINVAL, just like
> v4; this makes it easy to use the same error handlers for both cases.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: David Ahern <dsa@cumulusnetworks.com>
> ---
> Changes from v2:
> It turns out ipv6_chk_addr already has the device enumeration
> logic that we need by simply passing NULL.
>
> net/ipv6/ip6_output.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 6001e78..b3b5cb6 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
> const struct sock *sk,
> int err;
> int flags = 0;
>
> + if (!ipv6_addr_any(&fl6->saddr) &&
> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
> + return -EINVAL;
Hmm, this check is too permissive, no?
E.g. what happens if you move a link local address from one interface to
another? In this case this code would still allow the saddr to be used.
I just also quickly read up on the history (sorry was travelling last
week) and wonder if you ever saw a user space facing bug or if this is
basically some difference you saw while writing out of tree code?
Thanks,
Hannes
^ permalink raw reply
* [PATCH] cpufreq: intel_pstate: fix intel_pstate_use_acpi_profile helper
From: Arnd Bergmann @ 2016-11-14 16:41 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, Srinivas Pandruvada, Len Brown, Viresh Kumar,
Philippe Longepe, Stephane Gasparini, linux-pm, linux-kernel
The newly added function uses two different prototypes depending
on configuration, and one of them does not match the caller:
drivers/cpufreq/intel_pstate.c: In function ‘copy_cpu_funcs’:
drivers/cpufreq/intel_pstate.c:1798:2: error: too few arguments to function ‘intel_pstate_use_acpi_profile’
This changes it to look like the other one.
Fixes: 3bea6a285476 ("cpufreq: intel_pstate: Use cpu load based algorithm for mobile class devices")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/cpufreq/intel_pstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 65832f8eacdc..7153cf2d8e11 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1779,7 +1779,7 @@ static void intel_pstate_use_acpi_profile(void)
get_target_pstate_use_cpu_load;
}
#else
-static inline void intel_pstate_use_acpi_profile(struct pstate_funcs *funcs)
+static inline void intel_pstate_use_acpi_profile(void)
{
}
#endif
--
2.9.0
^ permalink raw reply related
* Re: [PATCH] clk: rockchip: validity should be checked prior to clock rate change
From: Heiko Stuebner @ 2016-11-14 16:41 UTC (permalink / raw)
To: Elaine Zhang
Cc: mturquette, sboyd, xf, rocky.hao, huangtao, xxx, jay.xu,
linux-clk, linux-rockchip, linux-kernel
In-Reply-To: <1478596214-761-1-git-send-email-zhangqing@rock-chips.com>
Am Dienstag, 8. November 2016, 17:10:14 CET schrieb Elaine Zhang:
> If validity is not checked prior to clock rate change, clk_set_rate(
> cpu_clk, unsupported_rate) will return success, but the real clock rate
> change operation is prohibited in post clock change event. Alough post
> clock change event will report error due to unsupported clock rate is
> set, but this error message is ignored by clock framework.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>
after Elaine clarified that the line mentioning Rocky was actually a tested-by,
applied to my clock branch
Thanks
Heiko
^ permalink raw reply
* Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)
From: Johannes Schindelin @ 2016-11-14 16:40 UTC (permalink / raw)
To: Michael J Gruber
Cc: Jacob Keller, Junio C Hamano, Dennis Kaarsemaker,
Git mailing list
In-Reply-To: <0c39be16-76f8-0800-41a2-b7b1dccdd652@drmicha.warpmail.net>
Hi Michael,
On Mon, 14 Nov 2016, Michael J Gruber wrote:
> why should a *file* argument (which is not a pathspec in --no-index
> mode) not be treated in the same way in which every other command treats
> a file argument?
We are talking about `<(command)` here, which is most distinctly not a
file argument at all.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH] filemap: add comment for confusing logic in page_cache_tree_insert()
From: Johannes Weiner @ 2016-11-14 16:39 UTC (permalink / raw)
To: Kirill A. Shutemov; +Cc: Andrew Morton, linux-mm, Jan Kara
In-Reply-To: <20161110163640.126124-1-kirill.shutemov@linux.intel.com>
On Thu, Nov 10, 2016 at 07:36:40PM +0300, Kirill A. Shutemov wrote:
> Unlike THP, hugetlb pages represented by one entry on radix-tree.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Cc: Jan Kara <jack@suse.cz>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/2] NFSv4: Fix CLOSE races with OPEN
From: Jeff Layton @ 2016-11-14 16:40 UTC (permalink / raw)
To: Trond Myklebust, linux-nfs; +Cc: Benjamin Coddington
In-Reply-To: <1479140396-17779-2-git-send-email-trond.myklebust@primarydata.com>
On Mon, 2016-11-14 at 11:19 -0500, Trond Myklebust wrote:
> If the reply to a successful CLOSE call races with an OPEN to the same
> file, we can end up scribbling over the stateid that represents the
> new open state.
> The race looks like:
>
> Client Server
> ====== ======
>
> CLOSE stateid A on file "foo"
> CLOSE stateid A, return stateid C
> OPEN file "foo"
> OPEN "foo", return stateid B
> Receive reply to OPEN
> Reset open state for "foo"
> Associate stateid B to "foo"
>
> Receive CLOSE for A
> Reset open state for "foo"
> Replace stateid B with C
>
> The fix is to examine the argument of the CLOSE, and check for a match
> with the current stateid "other" field. If the two do not match, then
> the above race occurred, and we should just ignore the CLOSE.
>
> Reported-by: Benjamin Coddington <bcodding@redhat.com>
> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
> ---
> fs/nfs/nfs4_fs.h | 7 +++++++
> fs/nfs/nfs4proc.c | 12 ++++++------
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
> index 9b3a82abab07..1452177c822d 100644
> --- a/fs/nfs/nfs4_fs.h
> +++ b/fs/nfs/nfs4_fs.h
> @@ -542,6 +542,13 @@ static inline bool nfs4_valid_open_stateid(const struct nfs4_state *state)
> return test_bit(NFS_STATE_RECOVERY_FAILED, &state->flags) == 0;
> }
>
> +static inline bool nfs4_state_match_open_stateid_other(const struct nfs4_state *state,
> + const nfs4_stateid *stateid)
> +{
> + return test_bit(NFS_OPEN_STATE, &state->flags) &&
> + nfs4_stateid_match_other(&state->open_stateid, stateid);
> +}
> +
> #else
>
> #define nfs4_close_state(a, b) do { } while (0)
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index f550ac69ffa0..b7b0080977c0 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -1458,7 +1458,6 @@ static void nfs_resync_open_stateid_locked(struct nfs4_state *state)
> }
>
> static void nfs_clear_open_stateid_locked(struct nfs4_state *state,
> - nfs4_stateid *arg_stateid,
> nfs4_stateid *stateid, fmode_t fmode)
> {
> clear_bit(NFS_O_RDWR_STATE, &state->flags);
> @@ -1476,10 +1475,9 @@ static void nfs_clear_open_stateid_locked(struct nfs4_state *state,
> }
> if (stateid == NULL)
> return;
> - /* Handle races with OPEN */
> - if (!nfs4_stateid_match_other(arg_stateid, &state->open_stateid) ||
> - (nfs4_stateid_match_other(stateid, &state->open_stateid) &&
> - !nfs4_stateid_is_newer(stateid, &state->open_stateid))) {
> + /* Handle OPEN+OPEN_DOWNGRADE races */
> + if (nfs4_stateid_match_other(stateid, &state->open_stateid) &&
> + !nfs4_stateid_is_newer(stateid, &state->open_stateid)) {
> nfs_resync_open_stateid_locked(state);
> return;
> }
> @@ -1493,7 +1491,9 @@ static void nfs_clear_open_stateid(struct nfs4_state *state,
> nfs4_stateid *stateid, fmode_t fmode)
> {
> write_seqlock(&state->seqlock);
> - nfs_clear_open_stateid_locked(state, arg_stateid, stateid, fmode);
> + /* Ignore, if the CLOSE argment doesn't match the current stateid */
> + if (nfs4_state_match_open_stateid_other(state, arg_stateid))
> + nfs_clear_open_stateid_locked(state, stateid, fmode);
> write_sequnlock(&state->seqlock);
> if (test_bit(NFS_STATE_RECLAIM_NOGRACE, &state->flags))
> nfs4_schedule_state_manager(state->owner->so_server->nfs_client);
I still don't quite get it. What's the point of paying any attention at
all to the stateid returned by the server in a CLOSE response? It's
either:
a) completely bogus, if the server is following the SHOULD in RFC5661,
section 18.2.4
...or...
b) refers to a now-defunct stateid -- probably a later version of the
one sent in the request, but the spec doesn't really spell that out,
AFAICT.
In either case, I don't think it ought to be trusted. Why not just use
the arg_stateid universally here?
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply
* Re: [Qemu-devel] [PULL V2 0/3] Net patches
From: Stefan Hajnoczi @ 2016-11-14 16:40 UTC (permalink / raw)
To: Jason Wang; +Cc: peter.maydell, qemu-devel
In-Reply-To: <1479092066-20810-1-git-send-email-jasowang@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
On Mon, Nov 14, 2016 at 10:54:23AM +0800, Jason Wang wrote:
> Pavel Dovgalyuk (1):
> record/replay: add network support
QEMU is in soft freeze. The policy has changed this release and only
bug fixes are being accepted during soft freeze. Please don't include
new features.
http://qemu-project.org/Planning/SoftFeatureFreeze
Please submit a new version without this patch or explain why it is a
necessary bug fix for -rc0.
Thanks,
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] btrfs-progs: add OPEN_CTREE_INVALIDATE_FST flag
From: David Sterba @ 2016-11-14 16:40 UTC (permalink / raw)
To: Omar Sandoval; +Cc: Qu Wenruo, linux-btrfs, kernel-team
In-Reply-To: <20161114162256.GA22223@vader>
On Mon, Nov 14, 2016 at 08:22:56AM -0800, Omar Sandoval wrote:
> > > --- a/disk-io.c
> > > +++ b/disk-io.c
> > > @@ -904,7 +904,7 @@ free_all:
> > > return NULL;
> > > }
> > >
> > > -int btrfs_check_fs_compatibility(struct btrfs_super_block *sb, int writable)
> > > +int btrfs_check_fs_compatibility(struct btrfs_super_block *sb, unsigned flags)
> >
> > IIRC kernel checkpatch will warn on single "unsigned", as it's recommended
> > to use "unsigned int".
>
> I was going for consistency with the rest of disk-io.c, but I can fix
> it.
Not needed IMHO, we don't use unsinged int/unsigned consistently.
^ permalink raw reply
* Re: [PATCH 4/6] btrfs-progs: add btrfs_clear_free_space_tree() from the kernel
From: Omar Sandoval @ 2016-11-14 16:33 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs, kernel-team
In-Reply-To: <33ac5417-0e5d-af0d-6b8e-c6603795d429@cn.fujitsu.com>
On Mon, Nov 14, 2016 at 09:38:19AM +0800, Qu Wenruo wrote:
>
>
> At 11/14/2016 03:35 AM, Omar Sandoval wrote:
> > From: Omar Sandoval <osandov@fb.com>
> >
> > Signed-off-by: Omar Sandoval <osandov@fb.com>
>
> Only small nits about the BUG_ON() and return value.
> Despite that, feel free to add my reviewed-by:
>
> Reviewed-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
> > ---
> > ctree.h | 6 ++++
> > extent-tree.c | 10 +++++++
> > free-space-tree.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > free-space-tree.h | 1 +
> > root-tree.c | 22 ++++++++++++++
> > 5 files changed, 126 insertions(+)
> >
> > diff --git a/ctree.h b/ctree.h
> > index d67b852..90193ad 100644
> > --- a/ctree.h
> > +++ b/ctree.h
> > @@ -2504,6 +2504,10 @@ int btrfs_inc_ref(struct btrfs_trans_handle *trans, struct btrfs_root *root,
> > struct extent_buffer *buf, int record_parent);
> > int btrfs_dec_ref(struct btrfs_trans_handle *trans, struct btrfs_root *root,
> > struct extent_buffer *buf, int record_parent);
> > +void btrfs_free_tree_block(struct btrfs_trans_handle *trans,
> > + struct btrfs_root *root,
> > + struct extent_buffer *buf,
> > + u64 parent, int last_ref);
> > int btrfs_free_extent(struct btrfs_trans_handle *trans,
> > struct btrfs_root *root,
> > u64 bytenr, u64 num_bytes, u64 parent,
> > @@ -2664,6 +2668,8 @@ int btrfs_add_root_ref(struct btrfs_trans_handle *trans,
> > int btrfs_insert_root(struct btrfs_trans_handle *trans, struct btrfs_root
> > *root, struct btrfs_key *key, struct btrfs_root_item
> > *item);
> > +int btrfs_del_root(struct btrfs_trans_handle *trans, struct btrfs_root *root,
> > + struct btrfs_key *key);
> > int btrfs_update_root(struct btrfs_trans_handle *trans, struct btrfs_root
> > *root, struct btrfs_key *key, struct btrfs_root_item
> > *item);
> > diff --git a/extent-tree.c b/extent-tree.c
> > index 3b1577e..d445723 100644
> > --- a/extent-tree.c
> > +++ b/extent-tree.c
> > @@ -2467,6 +2467,16 @@ static int del_pending_extents(struct btrfs_trans_handle *trans, struct
> > return err;
> > }
> >
> > +
> > +void btrfs_free_tree_block(struct btrfs_trans_handle *trans,
> > + struct btrfs_root *root,
> > + struct extent_buffer *buf,
> > + u64 parent, int last_ref)
> > +{
> > + btrfs_free_extent(trans, root, buf->start, buf->len, parent,
> > + root->root_key.objectid, btrfs_header_level(buf), 0);
> > +}
>
> btrfs_free_extent() will return int.
>
> Better return it.
Will fix.
> > +
> > /*
> > * remove an extent from the root, returns 0 on success
> > */
> > diff --git a/free-space-tree.c b/free-space-tree.c
> > index 3c7a246..d972f26 100644
> > --- a/free-space-tree.c
> > +++ b/free-space-tree.c
> > @@ -20,6 +20,7 @@
> > #include "disk-io.h"
> > #include "free-space-cache.h"
> > #include "free-space-tree.h"
> > +#include "transaction.h"
> >
> > static struct btrfs_free_space_info *
> > search_free_space_info(struct btrfs_trans_handle *trans,
> > @@ -67,6 +68,92 @@ static int free_space_test_bit(struct btrfs_block_group_cache *block_group,
> > return !!extent_buffer_test_bit(leaf, ptr, i);
> > }
> >
> > +static int clear_free_space_tree(struct btrfs_trans_handle *trans,
> > + struct btrfs_root *root)
> > +{
> > + struct btrfs_path *path;
> > + struct btrfs_key key;
> > + int nr;
> > + int ret;
> > +
> > + path = btrfs_alloc_path();
> > + if (!path)
> > + return -ENOMEM;
> > +
> > + key.objectid = 0;
> > + key.type = 0;
> > + key.offset = 0;
> > +
> > + while (1) {
> > + ret = btrfs_search_slot(trans, root, &key, path, -1, 1);
> > + if (ret < 0)
> > + goto out;
> > +
> > + nr = btrfs_header_nritems(path->nodes[0]);
> > + if (!nr)
> > + break;
> > +
> > + path->slots[0] = 0;
> > + ret = btrfs_del_items(trans, root, path, 0, nr);
> > + if (ret)
> > + goto out;
> > +
> > + btrfs_release_path(path);
> > + }
> > +
> > + ret = 0;
> > +out:
> > + btrfs_free_path(path);
> > + return ret;
> > +}
> > +
> > +int btrfs_clear_free_space_tree(struct btrfs_fs_info *fs_info)
> > +{
> > + struct btrfs_trans_handle *trans;
> > + struct btrfs_root *tree_root = fs_info->tree_root;
> > + struct btrfs_root *free_space_root = fs_info->free_space_root;
> > + int ret;
> > + u64 features;
> > +
> > + trans = btrfs_start_transaction(tree_root, 0);
> > + if (IS_ERR(trans))
> > + return PTR_ERR(trans);
> > +
> > +
> > + features = btrfs_super_compat_ro_flags(fs_info->super_copy);
> > + features &= ~(BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE_VALID |
> > + BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE);
> > + btrfs_set_super_compat_ro_flags(fs_info->super_copy, features);
> > + fs_info->free_space_root = NULL;
> > +
> > + ret = clear_free_space_tree(trans, free_space_root);
> > + if (ret)
> > + goto abort;
> > +
> > + ret = btrfs_del_root(trans, tree_root, &free_space_root->root_key);
> > + if (ret)
> > + goto abort;
> > +
> > + list_del(&free_space_root->dirty_list);
> > +
> > + clean_tree_block(trans, tree_root, free_space_root->node);
>
> Better catch the return value.
>
> > + btrfs_free_tree_block(trans, free_space_root, free_space_root->node,
> > + 0, 1);
>
> Here too.
Oh yeah these two return void in the kernel, but I'll fix it here.
> > +
> > + free_extent_buffer(free_space_root->node);
> > + free_extent_buffer(free_space_root->commit_root);
> > + kfree(free_space_root);
> > +
> > + ret = btrfs_commit_transaction(trans, tree_root);
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +
> > +abort:
>
> This reminds me again that we really need a btrfs_abort_transaction() in
> btrfs-progs.
> (And I always forget to implement it)
>
> > + return ret;
> > +}
> > +
> > static int load_free_space_bitmaps(struct btrfs_fs_info *fs_info,
> > struct btrfs_block_group_cache *block_group,
> > struct btrfs_path *path,
> > diff --git a/free-space-tree.h b/free-space-tree.h
> > index 7529a46..4845f13 100644
> > --- a/free-space-tree.h
> > +++ b/free-space-tree.h
> > @@ -19,6 +19,7 @@
> > #ifndef __BTRFS_FREE_SPACE_TREE_H__
> > #define __BTRFS_FREE_SPACE_TREE_H__
> >
> > +int btrfs_clear_free_space_tree(struct btrfs_fs_info *fs_info);
> > int load_free_space_tree(struct btrfs_fs_info *fs_info,
> > struct btrfs_block_group_cache *block_group);
> >
> > diff --git a/root-tree.c b/root-tree.c
> > index cca424e..c660447 100644
> > --- a/root-tree.c
> > +++ b/root-tree.c
> > @@ -143,6 +143,28 @@ int btrfs_insert_root(struct btrfs_trans_handle *trans, struct btrfs_root
> > return ret;
> > }
> >
> > +/* drop the root item for 'key' from 'root' */
> > +int btrfs_del_root(struct btrfs_trans_handle *trans, struct btrfs_root *root,
> > + struct btrfs_key *key)
> > +{
> > + struct btrfs_path *path;
> > + int ret;
> > +
> > + path = btrfs_alloc_path();
> > + if (!path)
> > + return -ENOMEM;
> > + ret = btrfs_search_slot(trans, root, key, path, -1, 1);
> > + if (ret < 0)
> > + goto out;
> > +
> > + BUG_ON(ret != 0);
>
> Better to avoid BUG_ON().
>
> Return -ENOENT seems good enough.
Copied this straight from the kernel, but you're right, no reason to
crash progs.
Thanks for the review!
> Thanks,
> Qu
>
> > +
> > + ret = btrfs_del_item(trans, root, path);
> > +out:
> > + btrfs_free_path(path);
> > + return ret;
> > +}
> > +
> > /*
> > * add a btrfs_root_ref item. type is either BTRFS_ROOT_REF_KEY
> > * or BTRFS_ROOT_BACKREF_KEY.
> >
>
>
--
Omar
^ permalink raw reply
* Re: [RFC PATCH v3 10/20] Add support to access boot related data in the clear
From: Tom Lendacky @ 2016-11-14 16:24 UTC (permalink / raw)
To: Kani, Toshimitsu, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kasan-dev@googlegroups.com, x86@kernel.org,
iommu@lists.linux-foundation.org, linux-efi@vger.kernel.org,
linux-arch@vger.kernel.org, linux-doc@vger.kernel.org
Cc: matt@codeblueprint.co.uk, corbet@lwn.net, tglx@linutronix.de,
konrad.wilk@oracle.com, joro@8bytes.org, dvyukov@google.com,
aryabinin@virtuozzo.com, riel@redhat.com, lwoodman@redhat.com,
mingo@redhat.com, hpa@zytor.com, luto@kernel.org,
pbonzini@redhat.com, bp@alien8.de, glider@google.com,
rkrcmar@redhat.com, arnd@arndb.de
In-Reply-To: <1478880929.20881.148.camel@hpe.com>
On 11/11/2016 10:17 AM, Kani, Toshimitsu wrote:
> On Wed, 2016-11-09 at 18:36 -0600, Tom Lendacky wrote:
>> Boot data (such as EFI related data) is not encrypted when the system
>> is booted and needs to be accessed unencrypted. Add support to apply
>> the proper attributes to the EFI page tables and to the
>> early_memremap and memremap APIs to identify the type of data being
>> accessed so that the proper encryption attribute can be applied.
> :
>> +static bool memremap_apply_encryption(resource_size_t phys_addr,
>> + unsigned long size)
>> +{
>> + /* SME is not active, just return true */
>> + if (!sme_me_mask)
>> + return true;
>> +
>> + /* Check if the address is part of the setup data */
>> + if (memremap_setup_data(phys_addr, size))
>> + return false;
>> +
>> + /* Check if the address is part of EFI boot/runtime data */
>> + switch (efi_mem_type(phys_addr)) {
>> + case EFI_BOOT_SERVICES_DATA:
>> + case EFI_RUNTIME_SERVICES_DATA:
>> + return false;
>> + }
>> +
>> + /* Check if the address is outside kernel usable area */
>> + switch (e820_get_entry_type(phys_addr, phys_addr + size -
>> 1)) {
>> + case E820_RESERVED:
>> + case E820_ACPI:
>> + case E820_NVS:
>> + case E820_UNUSABLE:
>> + return false;
>> + }
>> +
>> + return true;
>> +}
>
> Are you supporting encryption for E820_PMEM ranges? If so, this
> encryption will persist across a reboot and does not need to be
> encrypted again, right? Also, how do you keep a same key across a
> reboot?
The key will change across a reboot... so I need to look into this
more for memory that isn't used as traditional system ram.
Thanks,
Tom
>
> Thanks,
> -Toshi
>
^ permalink raw reply
* [PATCH 4/4] drm: rcar-du: Fix LVDS start sequence on Gen3
From: Laurent Pinchart @ 2016-11-14 16:39 UTC (permalink / raw)
To: dri-devel; +Cc: linux-renesas-soc, Koji Matsuoka
In-Reply-To: <1479141552-8509-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
From: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
According to the latest revision of the datasheet, the LVDS I/O pins
must be enabled before starting the PLL. Fix it.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index b74105a80a6e..e3a4985f6f3f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -104,7 +104,14 @@ static void rcar_du_lvdsenc_start_gen3(struct rcar_du_lvdsenc *lvds,
rcar_lvds_write(lvds, LVDPLLCR, pllcr);
- /* Turn the PLL on, set it to LVDS normal mode, wait for the startup
+ /* Turn all the channels on. */
+ rcar_lvds_write(lvds, LVDCR1,
+ LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
+ LVDCR1_CHSTBY_GEN3(1) | LVDCR1_CHSTBY_GEN3(0) |
+ LVDCR1_CLKSTBY_GEN3);
+
+ /*
+ * Turn the PLL on, set it to LVDS normal mode, wait for the startup
* delay and turn the output on.
*/
lvdcr0 = LVDCR0_PLLON;
@@ -117,12 +124,6 @@ static void rcar_du_lvdsenc_start_gen3(struct rcar_du_lvdsenc *lvds,
lvdcr0 |= LVDCR0_LVRES;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
- /* Turn all the channels on. */
- rcar_lvds_write(lvds, LVDCR1,
- LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
- LVDCR1_CHSTBY_GEN3(1) | LVDCR1_CHSTBY_GEN3(0) |
- LVDCR1_CLKSTBY_GEN3);
}
static int rcar_du_lvdsenc_start(struct rcar_du_lvdsenc *lvds,
--
Regards,
Laurent Pinchart
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.