Re: [RFCv2 00/48] perf tools: Add threads to record command
Hi, On 23.09.2018 22:30, Jiri Olsa wrote: > On Fri, Sep 21, 2018 at 09:13:08AM +0300, Alexey Budankov wrote: > > SNIP > >> Events: >> cpu/period=P,event=0x3c/Duk;CPU_CLK_UNHALTED.THREAD >> cpu/period=P,umask=0x3/Duk;CPU_CLK_UNHALTED.REF_TSC >> cpu/period=P,event=0xc0/Duk;INST_RETIRED.ANY >> cpu/period=0xaae61,event=0xc2,umask=0x10/uk;UOPS_RETIRED.ALL >> cpu/period=0x11171,event=0xc2,umask=0x20/uk;UOPS_RETIRED.SCALAR_SIMD >> cpu/period=0x11171,event=0xc2,umask=0x40/uk;UOPS_RETIRED.PACKED_SIMD >> >> = >> >> Command: >> /usr/bin/time /tmp/vtune_amplifier_2019.574715/bin64/perf.thr record >> --threads=T \ >> -a -N -B -T -R --call-graph dwarf,1024 --user-regs=ip,bp,sp \ >> -e cpu/period=P,event=0x3c/Duk,\ >>cpu/period=P,umask=0x3/Duk,\ >>cpu/period=P,event=0xc0/Duk,\ >>cpu/period=0x30d40,event=0xc2,umask=0x10/uk,\ >>cpu/period=0x4e20,event=0xc2,umask=0x20/uk,\ >>cpu/period=0x4e20,event=0xc2,umask=0x40/uk \ >> --clockid=monotonic_raw -- ./matrix.(icc|gcc) > > hum, so I guess the results suck because of the -a option, > getting extra samples for all the perf record threads > > could you try without the -a? you monitor only user events, > so you're interested only in ./matrix.* samples, right? Ok, trying without -a, in per-process mode. VTune collects as user as kernel mode samples, using /uk modifiers set. The set can be extended to collect in VM host and guests as well. Thanks, Alexey > > thanks, > jirka >
Re: [PATCH] Driver core: add bus_find_device_by_fwnode
On Mon, Sep 24, 2018 at 12:06:13PM +0530, Silesh C V wrote: > Hello Greg, > On Mon, Sep 24, 2018 at 10:48 AM Greg Kroah-Hartman > wrote: > > > > On Mon, Sep 24, 2018 at 10:05:55AM +0530, Silesh C V wrote: > > > Some drivers need to find the device on a bus having a specific firmware > > > node. Currently, such drivers have their own implementations to do this. > > > Provide a helper similar to bus_find_device_by_name so that each driver > > > does not have to reinvent this. > > > > Is there a second patch that uses this function? We don't add api calls > > that are not used. > > OK. If I change, say, of_find_i2c_device_by_node, > of_find_i2c_adapter_by_node, of_phy_find_device and > of_find_spi_device_by_node to use this API, will that be good enough? > If that is OK, I will send this as a series in v2. I have no idea. Why would you want to create a new api call with no users? Let's see the patch series before being able to properly judge it... thanks, greg k-h
Re: [PATCH v3 2/2] remoteproc: qcom: Introduce Non-PAS ADSP PIL driver
On 9/24/2018 12:19 PM, Rohit Kumar wrote: Thanks Sibi for reviewing. On 9/22/2018 1:11 AM, Sibi Sankar wrote: Hi Rohit, On 2018-09-03 17:22, Rohit kumar wrote: This adds Non PAS ADSP PIL driver for Qualcomm Technologies Inc SoCs. Added initial support for SDM845 with ADSP bootup and shutdown operation handled from Application Processor SubSystem(APSS). Signed-off-by: Rohit kumar --- ... Also I see the following warns on stopping the adsp remoteproc, couldn't root cause it though: It should be issue in Q6 drivers. I will check and update q6 drivers. Thanks for reporting. Checked this warning. This is a core driver issue fixed with https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/base/core.c?h=next-20180924&id=2ec16150179888b81717d1d3ce84e634f4736af2 device_del+0x84/0x29c platform_device_del+0x2c/0x88 platform_device_unregister+0x1c/0x30 of_platform_device_destroy+0x98/0xa8 device_for_each_child+0x54/0xa4 of_platform_depopulate+0x38/0x54 q6asm_remove+0x1c/0x2c apr_device_remove+0x38/0x70 device_release_driver_internal+0x124/0x1c8 device_release_driver+0x24/0x30 bus_remove_device+0xcc/0xe4 device_del+0x1f8/0x29c device_unregister+0x1c/0x30 apr_remove_device+0x1c/0x2c device_for_each_child+0x54/0xa4 apr_remove+0x28/0x34 rpmsg_dev_remove+0x48/0x70 device_release_driver_internal+0x124/0x1c8 device_release_driver+0x24/0x30 bus_remove_device+0xcc/0xe4 device_del+0x1f8/0x29c device_unregister+0x1c/0x30 qcom_glink_remove_device+0x1c/0x2c device_for_each_child+0x54/0xa4 qcom_glink_native_remove+0x54/0x15c qcom_glink_smem_unregister+0x1c/0x30 glink_subdev_stop+0x1c/0x2c [qcom_common] rproc_stop+0x40/0xc0 rproc_shutdown+0x6c/0xc0 rproc_del+0x28/0xa0 adsp_remove+0x20/0x5c [qcom_adsp_pil] platform_drv_remove+0x28/0x50 device_release_driver_internal+0x124/0x1c8 driver_detach+0x44/0x80 bus_remove_driver+0x78/0x9c driver_unregister+0x34/0x54 platform_driver_unregister+0x1c/0x28 cleanup_module+0x14/0x6bc [qcom_adsp_pil] SyS_delete_module+0x1c4/0x214 Thanks, Rohit Thanks
Re: [GIT PULL] UBIFS fixes for 4.19-rc4
I fredags, den 21 september 2018, 15:53:42 CEST skrev Greg KH: > On Fri, Sep 21, 2018 at 11:33:15AM +0200, Richard Weinberger wrote: >> Greg, >> >> The following changes since commit ae596de1a0c8c2c924dc99d23c026259372ab234: >> >> Compiler Attributes: naked can be shared (2018-09-20 15:23:58 +0200) > > Wow, bold move, new patches with less than 24 hours in your tree. That > means linux-next didn't see them :( > >> are available in the Git repository at: >> >> git://git.infradead.org/linux-ubifs.git tags/upstream-4.19-rc4 > > Now pulled, but really, don't you think that they should at least go > through 0-day first? Maybe no one runs ubifs on mainline kernels... FWIW, we do... Cheers, Peter
Re: [GIT PULL] UBIFS fixes for 4.19-rc4
On Mon, Sep 24, 2018 at 09:11:55AM +0200, Peter Rosin wrote: > I fredags, den 21 september 2018, 15:53:42 CEST skrev Greg KH: > > On Fri, Sep 21, 2018 at 11:33:15AM +0200, Richard Weinberger wrote: > >> Greg, > >> > >> The following changes since commit > >> ae596de1a0c8c2c924dc99d23c026259372ab234: > >> > >> Compiler Attributes: naked can be shared (2018-09-20 15:23:58 +0200) > > > > Wow, bold move, new patches with less than 24 hours in your tree. That > > means linux-next didn't see them :( > > > >> are available in the Git repository at: > >> > >> git://git.infradead.org/linux-ubifs.git tags/upstream-4.19-rc4 > > > > Now pulled, but really, don't you think that they should at least go > > through 0-day first? Maybe no one runs ubifs on mainline kernels... > > FWIW, we do... That's good to know. I was just trying to say that patches asked to be pulled in, less than 24 hours from when they were added to the developer's tree, is usually a little "suspect" as they normally have not had the chance to go through our "CI" systems. That's all, I wasn't trying to disparage the UBIFS codebase at all :) thanks, greg k-h
Re: [PATCH V4 00/27] C-SKY(csky) Linux Kernel Port
Hi Arnd,
On Fri, Sep 21, 2018 at 7:19 AM Arnd Bergmann wrote:
> On Thu, Sep 20, 2018 at 10:52 AM Palmer Dabbelt wrote:
> > On Fri, 14 Sep 2018 07:37:20 PDT (-0700), ren_...@c-sky.com wrote:
> > > On Wed, Sep 12, 2018 at 04:30:36PM +0200, Arnd Bergmann wrote:
> > >> On Wed, Sep 12, 2018 at 3:25 PM Guo Ren wrote:
> My plan was to get that all into 4.20, and then have a conversation about the
> actual syscall table changes in 4.21. If we need it for both csky and rv32,
> we might just change the generic syscall table that way in 4.21 without
> changing all the other ones along with them. I don't want to drag things out
> over too many merge windows though, and my plan was to do all architectures
> together to simplify the version checks in the libc code to only have to check
> for a single version.
What happens with the version checks if it is backported to stable?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] clocksource/drivers: Unify the names to timer-* format
On Mon, Sep 24, 2018 at 08:31:26AM +0200, Daniel Lezcano wrote: > On 24/09/2018 08:28, Uwe Kleine-König wrote: > > On Mon, Sep 24, 2018 at 06:15:17AM +0200, Daniel Lezcano wrote: > >> In order to make some housekeeping in the directory, this patch renames > >> drivers to the timer-* format in order to unify their names. > >> > >> There is no functional changes. > >> > >> Signed-off-by: Daniel Lezcano > >> --- > >> MAINTAINERS | 10 +- > >> drivers/clocksource/Makefile | 26 +- > >> drivers/clocksource/cadence_ttc_timer.c | 543 > >> -- > >> drivers/clocksource/fsl_ftm_timer.c | 376 - > >> drivers/clocksource/owl-timer.c | 173 -- > >> drivers/clocksource/qcom-timer.c | 258 -- > >> drivers/clocksource/time-armada-370-xp.c | 416 --- > >> drivers/clocksource/time-efm32.c | 287 > >> drivers/clocksource/time-lpc32xx.c| 314 - > >> drivers/clocksource/time-orion.c | 192 --- > >> drivers/clocksource/time-pistachio.c | 218 > >> drivers/clocksource/timer-armada-370-xp.c | 416 +++ > >> drivers/clocksource/timer-cadence-ttc.c | 543 > >> ++ > >> drivers/clocksource/timer-efm32.c | 287 > >> drivers/clocksource/timer-fsl-ftm.c | 376 + > >> drivers/clocksource/timer-lpc32xx.c | 314 + > >> drivers/clocksource/timer-orion.c | 192 +++ > >> drivers/clocksource/timer-owl.c | 173 ++ > >> drivers/clocksource/timer-pistachio.c | 218 > >> drivers/clocksource/timer-qcom.c | 258 ++ > >> drivers/clocksource/timer-versatile.c | 44 +++ > >> drivers/clocksource/timer-vf-pit.c| 204 +++ > >> drivers/clocksource/timer-vt8500.c| 168 + > >> drivers/clocksource/timer-zevio.c | 218 > >> drivers/clocksource/versatile.c | 44 --- > >> drivers/clocksource/vf_pit_timer.c| 204 --- > >> drivers/clocksource/vt8500_timer.c| 168 - > >> drivers/clocksource/zevio-timer.c | 218 > >> 28 files changed, 3429 insertions(+), 3429 deletions(-) > > > > Wow, with git format-patch -M this should look much smaller and so > > easier to review. > > Yes, I forgot the option :/ I think you want: git config diff.renames true or a newer git (>= 2.9, which enabled that by default). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH] gpio: mockup: use device properties instead of platform_data
niedz., 23 wrz 2018 o 13:17 Bartosz Golaszewski napisał(a):
>
> Some users want to introduce device tree support to the mockup driver.
> Let's make it easier by switching to using generic device properties.
> The driver stays compatible with previous use cases and after this
> conversion there'll be no need to change the way probing of mockup
> GPIO chips works.
>
> Tested with libgpiod test suite.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/gpio/gpio-mockup.c | 82 --
> 1 file changed, 51 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
> index d66b7a768ecd..4e66bd83b76c 100644
> --- a/drivers/gpio/gpio-mockup.c
> +++ b/drivers/gpio/gpio-mockup.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include "gpiolib.h"
>
> @@ -28,6 +29,8 @@
> * of GPIO lines.
> */
> #define GPIO_MOCKUP_MAX_RANGES (GPIO_MOCKUP_MAX_GC * 2)
> +/* Maximum of three properties + the sentinel. */
> +#define GPIO_MOCKUP_MAX_PROP 4
>
> #define gpio_mockup_err(...) pr_err(GPIO_MOCKUP_NAME ": " __VA_ARGS__)
>
> @@ -59,13 +62,6 @@ struct gpio_mockup_dbgfs_private {
> int offset;
> };
>
> -struct gpio_mockup_platform_data {
> - int base;
> - int ngpio;
> - int index;
> - bool named_lines;
> -};
> -
> static int gpio_mockup_ranges[GPIO_MOCKUP_MAX_RANGES];
> static int gpio_mockup_num_ranges;
> module_param_array(gpio_mockup_ranges, int, &gpio_mockup_num_ranges, 0400);
> @@ -255,26 +251,37 @@ static int gpio_mockup_name_lines(struct device *dev,
>
> static int gpio_mockup_probe(struct platform_device *pdev)
> {
> - struct gpio_mockup_platform_data *pdata;
> struct gpio_mockup_chip *chip;
> struct gpio_chip *gc;
> - int rv, base, ngpio;
> struct device *dev;
> - char *name;
> + const char *name;
> + int rv, base;
> + u16 ngpio;
>
> dev = &pdev->dev;
> - pdata = dev_get_platdata(dev);
> - base = pdata->base;
> - ngpio = pdata->ngpio;
> +
> + rv = device_property_read_u32(dev, "gpio-base", &base);
> + if (rv && rv == -ENOENT)
Linus, I just noticed that we either need to drop the check for
-ENOENT or add an else that returns on any other error. I'll need to
send a v2 but I'll let you first tell me if you like the general idea.
Bart
> + base = -1;
> +
> + rv = device_property_read_u16(dev, "nr-gpios", &ngpio);
> + if (rv)
> + return rv;
> +
> + rv = device_property_read_string(dev, "chip-name", &name);
> + if (rv)
> + name = NULL;
>
> chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
> if (!chip)
> return -ENOMEM;
>
> - name = devm_kasprintf(dev, GFP_KERNEL, "%s-%c",
> - pdev->name, pdata->index);
> - if (!name)
> - return -ENOMEM;
> + if (!name) {
> + name = devm_kasprintf(dev, GFP_KERNEL,
> + "%s-%c", pdev->name, pdev->id + 'A');
> + if (!name)
> + return -ENOMEM;
> + }
>
> gc = &chip->gc;
> gc->base = base;
> @@ -295,7 +302,7 @@ static int gpio_mockup_probe(struct platform_device *pdev)
> if (!chip->lines)
> return -ENOMEM;
>
> - if (pdata->named_lines) {
> + if (device_property_read_bool(dev, "named-gpio-lines")) {
> rv = gpio_mockup_name_lines(dev, chip);
> if (rv)
> return rv;
> @@ -339,9 +346,11 @@ static void gpio_mockup_unregister_pdevs(void)
>
> static int __init gpio_mockup_init(void)
> {
> - int i, num_chips, err = 0, index = 'A';
> - struct gpio_mockup_platform_data pdata;
> + struct property_entry properties[GPIO_MOCKUP_MAX_PROP];
> + int i, prop, num_chips, err = 0, base;
> + struct platform_device_info pdevinfo;
> struct platform_device *pdev;
> + u16 ngpio;
>
> if ((gpio_mockup_num_ranges < 2) ||
> (gpio_mockup_num_ranges % 2) ||
> @@ -371,17 +380,28 @@ static int __init gpio_mockup_init(void)
> }
>
> for (i = 0; i < num_chips; i++) {
> - pdata.index = index++;
> - pdata.base = gpio_mockup_range_base(i);
> - pdata.ngpio = pdata.base < 0
> - ? gpio_mockup_range_ngpio(i)
> - : gpio_mockup_range_ngpio(i) - pdata.base;
> - pdata.named_lines = gpio_mockup_named_lines;
> -
> - pdev = platform_device_register_resndata(NULL,
> -GPIO_MOCKUP_NAME,
> -i, NULL, 0, &pdata,
> -sizeof(pdata));
> + memset(properties, 0, sizeof(
Re: [RFC/PATCH 2/5] device property: introduce notion of subnodes for legacy boards
On Fri, Sep 21, 2018 at 04:33:36PM -0700, Dmitry Torokhov wrote:
> On Thu, Sep 20, 2018 at 01:16:48PM +0300, Heikki Krogerus wrote:
> > On Wed, Sep 19, 2018 at 10:13:26AM -0700, Dmitry Torokhov wrote:
> > > > > diff --git a/drivers/base/pset_property.c
> > > > > b/drivers/base/pset_property.c
> > > > > index 08ecc13080ae..63f2377aefe8 100644
> > > > > --- a/drivers/base/pset_property.c
> > > > > +++ b/drivers/base/pset_property.c
> > > > > @@ -18,6 +18,11 @@ struct property_set {
> > > > > struct device *dev;
> > > > > struct fwnode_handle fwnode;
> > > > > const struct property_entry *properties;
> > > > > +
> > > > > + struct property_set *parent;
> > > > > + /* Entry in parent->children list */
> > > > > + struct list_head child_node;
> > > > > + struct list_head children;
> > > >
> > > > Add
> > > >
> > > > const char *name;
> > > >
> > > > and you can implement also pset_get_named_child_node().
> > >
> > > Or
> > > char name[];
> > >
> > > to avoid separate allocation.
> >
> > Let's not do that, especially if you are planning on exporting this
> > structure.
>
> Can you please elaborate why? Not using pointer saves us 4/8 bytes +
> however much memory we need for bookkeeping for the extra chunk. Given
> that majority of pset nodes are unnamed this seems wasteful.
>
> > If the name is coming from .rodata, there is no need to
> > allocate anything for the name. Check kstrdup_const().
>
> The data is most likely coming as __initconst so we do need to copy it.
OK, I did not consider that. Yes, it makes sense to always copy.
Thanks,
--
heikki
Re: [RESEND PATCH v3 2/2] serial: uartps: Change uart ID port allocation
Hi Michal,
On Thu, Sep 20, 2018 at 1:42 PM Michal Simek wrote:
> For IPs which have alias algorightm all the time using that alias and
> minor number. It means serial20 alias ends up as ttyPS20.
>
> If alias is not setup for probed IP instance the first unused position is
> used but that needs to be checked if it is really empty because another
> instance doesn't need to be probed at that time. of_alias_get_alias_list()
> fills alias bitmap which exactly shows which ID is free.
> If alias pointing to different not compatible IP, it is free to use.
>
> cdns_get_id() call is placed below structure allocation to simplify
> error path.
>
> Signed-off-by: Michal Simek
JFTR, for sh-sci, I used a different approach, as all ports in the static DTB
can have an alias (if aliases are needed at all), and only DT overlays cannot
have them. Cfr. commit 7678f4c20fa7670f ("serial: sh-sci: Add support for
dynamic instances").
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] usb: typec: tcpm: Fix APDO PPS order checking to be based on voltage
On Fri, Sep 21, 2018 at 04:04:11PM +0100, Adam Thomson wrote:
> Current code mistakenly checks against max current to determine
> order but this should be max voltage. This commit fixes the issue
> so order is correctly determined, thus avoiding failure based on
> a higher voltage PPS APDO having a lower maximum current output,
> which is actually valid.
>
> Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS")
> Cc:
> Signed-off-by: Adam Thomson
Reviewed-by: Heikki Krogerus
> ---
> Code based on usb-testing branch (ae8a2ca8a2215c7e31e6d874f7303801bb15fbb)
>
> drivers/usb/typec/tcpm/tcpm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 4f1f421..c11b3be 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -1430,8 +1430,8 @@ static enum pdo_err tcpm_caps_err(struct tcpm_port
> *port, const u32 *pdo,
> if (pdo_apdo_type(pdo[i]) != APDO_TYPE_PPS)
> break;
>
> - if (pdo_pps_apdo_max_current(pdo[i]) <
> - pdo_pps_apdo_max_current(pdo[i - 1]))
> + if (pdo_pps_apdo_max_voltage(pdo[i]) <
> + pdo_pps_apdo_max_voltage(pdo[i - 1]))
> return PDO_ERR_PPS_APDO_NOT_SORTED;
> else if (pdo_pps_apdo_min_voltage(pdo[i]) ==
> pdo_pps_apdo_min_voltage(pdo[i - 1])
> &&
> --
> 1.9.1
Thanks,
--
heikki
Re: [RFT] arm64: ARM: dts: exynos: Remove double SD card detect pin inversion on TM2
Hi Krzysztof, On 2018-09-21 20:30, Krzysztof Kozlowski wrote: > The SDHCI standard, MMC host controller bindings and MMC core defines > card detect pin as active low. Therefore there is no point to invert it > twice. > > Signed-off-by: Krzysztof Kozlowski Works fine on TM2 and TM2e. However I'm not sure if it makes sense to refer to the SDHCI standard, as Exynos5433 has only DWMMC host controllers. Tested-by: Marek Szyprowski > --- > arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi > b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi > index a1e3194b7483..86d8ddc3288a 100644 > --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi > +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi > @@ -939,8 +939,7 @@ > status = "okay"; > cap-sd-highspeed; > disable-wp; > - cd-gpios = <&gpa2 4 GPIO_ACTIVE_HIGH>; > - cd-inverted; > + cd-gpios = <&gpa2 4 GPIO_ACTIVE_LOW>; > card-detect-delay = <200>; > samsung,dw-mshc-ciu-div = <3>; > samsung,dw-mshc-sdr-timing = <0 4>; Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [RESEND PATCH v3 1/2] of: base: Introduce of_alias_get_alias_list() to check alias IDs
Hi Michal,
On Thu, Sep 20, 2018 at 1:42 PM Michal Simek wrote:
> The function travels the lookup table to record alias ids for the given
> device match structures and alias stem.
> This function will be used by serial drivers to check if requested alias
> is allocated or free to use.
>
> Signed-off-by: Michal Simek
> Reviewed-by: Rob Herring
I know this has already been applied, it just drew my attention.
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -16,6 +16,7 @@
>
> #define pr_fmt(fmt)"OF: " fmt
>
> +#include
> #include
> #include
> #include
> @@ -1943,6 +1944,57 @@ int of_alias_get_id(struct device_node *np, const char
> *stem)
> EXPORT_SYMBOL_GPL(of_alias_get_id);
>
> /**
> + * of_alias_get_alias_list - Get alias list for the given device driver
> + * @matches: Array of OF device match structures to search in
> + * @stem: Alias stem of the given device_node
> + * @bitmap:Bitmap field pointer
> + * @nbits: Maximum number of alias ID which can be recorded it bitmap
IDs
> + *
> + * The function travels the lookup table to record alias ids for the given
> + * device match structures and alias stem.
> + *
> + * Return: 0 or -ENOSYS when !CONFIG_OF
> + */
> +int of_alias_get_alias_list(const struct of_device_id *matches,
> +const char *stem, unsigned long *bitmap,
> +unsigned int nbits)
> +{
> + struct alias_prop *app;
> +
> + /* Zero bitmap field to make sure that all the time it is clean */
> + bitmap_zero(bitmap, nbits);
> +
> + mutex_lock(&of_mutex);
> + pr_debug("%s: Looking for stem: %s\n", __func__, stem);
> + list_for_each_entry(app, &aliases_lookup, link) {
> + pr_debug("%s: stem: %s, id: %d\n",
> +__func__, app->stem, app->id);
> +
> + if (strcmp(app->stem, stem) != 0) {
> + pr_debug("%s: stem comparison doesn't passed %s\n",
didn't pass?
> +__func__, app->stem);
> + continue;
> + }
> +
> + if (app->id >= nbits) {
> + pr_debug("%s: ID %d greater then bitmap field %d\n",
than
%u for unsigned int
> + __func__, app->id, nbits);
> + continue;
Shouldn't this return an error, if of_match_node() below would have matched?
> + }
> +
> + if (of_match_node(matches, app->np)) {
> + pr_debug("%s: Allocated ID %d\n", __func__, app->id);
> + set_bit(app->id, bitmap);
> + }
> + /* Alias exist but it not compatible with matches */
exists but is npt
> + }
> + mutex_unlock(&of_mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_alias_get_alias_list);
> +
> +/**
> * of_alias_get_highest_id - Get highest alias id for the given stem
> * @stem: Alias stem to be examined
> *
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] kernel/kcov: Replace vm_insert_page with vmf_insert_page
On Sat, Sep 22, 2018 at 7:52 PM Matthew Wilcox wrote:
>
> On Fri, Sep 21, 2018 at 12:42:54AM +0530, Souptick Joarder wrote:
> > for (off = 0; off < size; off += PAGE_SIZE) {
> > page = vmalloc_to_page(kcov->area + off);
> > - if (vm_insert_page(vma, vma->vm_start + off, page))
> > - WARN_ONCE(1, "vm_insert_page() failed");
> > + if (vmf_insert_page(vma, vma->vm_start + off, page)
> > + != VM_FAULT_NOPAGE)
> > + WARN_ONCE(1, "vmf_insert_page() failed");
> > }
>
> I think this is the wrong approach (as well as being buggy).
>
> We should have a vmalloc_insert_range() _or something similar_ that
> replaces this entire loop. That makes each _user_ simpler. What you're
> trying to do right now makes each user more complex, and that's the
> wrong approach.
There are two different opinions here.
Andrey mentioned, to use vmf_insert_page() in fault handlers context and
not to remove vm_insert_page in his review comments.
And your opinion is to have vmalloc_insert_range() _or something similar_
that will replace whole loop. with this vm_insert_page will be removed.
Which one is better to go with ??
Re: [PATCH v2 3/5] m68k: Added system call table generation support
Hi Geert,
On Mon, 24 Sep 2018 at 12:33, Geert Uytterhoeven wrote:
>
> Hi Firoz,
>
> On Thu, Sep 20, 2018 at 5:07 PM Firoz Khan wrote:
> > The system call tables are in different format in all
> > architecture and it will be difficult to manually add or
> > modify the system calls in the respective files. To make
> > it easy by keeping a script and which'll generate the
> > header file and syscall table file so this change will
> > unify them across all architectures.
> >
> > The system call table generation script is added in
> > syscalls directory which contain the script to generate
> > both uapi header file system call table generation file
> > and syscall.tbl file which'll be the input for the scripts.
> >
> > syscall.tbl contains the list of available system calls
> > along with system call number and corresponding entry point.
> > Add a new system call in this architecture will be possible
> > by adding new entry in the syscall.tbl file.
> >
> > Adding a new table entry consisting of:
> > - System call number.
> > - ABI.
> > - System call name.
> > - Entry point name.
> >
> > syscallhdr.sh and syscalltbl.sh will generate uapi header-
> > unistd.h and syscall_table.h files respectively. File
> > syscall_table.h is included by syscall_table.S - the real
> > system call table. Both .sh files will parse the content
> > syscall.tbl to generate the header and table files.
> >
> > ARM, s390 and x86 architecuture does have the similar support.
> > I leverage their implementation to come up with a generic
> > solution. And this is the ground work for y2038 issue. We need
> > to change two dozons of system call implementation and this
> > work will reduce the effort by simply modify two dozon entries
> > in syscall.tbl.
> >
> > Signed-off-by: Firoz Khan
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/arch/m68k/kernel/syscalls/syscall.tbl
> > @@ -0,0 +1,369 @@
> > +#
> > +# Linux system call numbers and entry vectors
> > +#
> > +# The format is:
> > +#
> > +#
> > +# The abi is always common for this file.
> > +#
> > +0 common restart_syscall sys_restart_syscall
>
> Why the indentation by an "odd" number of spaces, instead of TABs?
I'll check and fix ASAP. Hopefully I can post a clean (almost) patch series
within couple of days!
- Firoz
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
[PATCH v2 2/2] iio: adc: at91: fix wrong channel number in triggered buffer mode
When channels are registered, the hardware channel number is not the
actual iio channel number.
This is because the driver is probed with a certain number of accessible
channels. Some pins are routed and some not, depending on the description of
the board in the DT.
Because of that, channels 0,1,2,3 can correspond to hardware channels
2,3,4,5 for example.
In the buffered triggered case, we need to do the translation accordingly.
Fixed the channel number to stop reading the wrong channel.
Fixes 0e589d5fb "ARM: AT91: IIO: Add AT91 ADC driver."
Cc: Maxime Ripard
Signed-off-by: Eugen Hristev
---
Changes in v2:
- Added 'const' spec to the declaration to avoid build warning
drivers/iio/adc/at91_adc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index e3be88e..75d2f73 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -248,12 +248,14 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void
*p)
struct iio_poll_func *pf = p;
struct iio_dev *idev = pf->indio_dev;
struct at91_adc_state *st = iio_priv(idev);
+ struct iio_chan_spec const *chan;
int i, j = 0;
for (i = 0; i < idev->masklength; i++) {
if (!test_bit(i, idev->active_scan_mask))
continue;
- st->buffer[j] = at91_adc_readl(st, AT91_ADC_CHAN(st, i));
+ chan = idev->channels + i;
+ st->buffer[j] = at91_adc_readl(st, AT91_ADC_CHAN(st,
chan->channel));
j++;
}
--
2.7.4
[PATCH v2 1/2] iio: adc: at91: fix acking DRDY irq on simple conversions
When doing simple conversions, the driver did not acknowledge the DRDY irq.
If this irq status is not acked, it will be left pending, and as soon as a
trigger is enabled, the irq handler will be called, it doesn't know why
this status has occurred because no channel is pending, and then it will go
int a irq loop and board will hang.
To avoid this situation, read the LCDR after a raw conversion is done.
Fixes 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
Cc: Maxime Ripard
Signed-off-by: Eugen Hristev
---
Hello Jonathan,
I moved this LCDR read/acknowledge into the IRQ handler after the conversion
value is being read.
Sorry about the noise to stable@vger, removed from message.
Thanks,
Eugen
drivers/iio/adc/at91_adc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 44b5168..e3be88e 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -279,6 +279,8 @@ static void handle_adc_eoc_trigger(int irq, struct iio_dev
*idev)
iio_trigger_poll(idev->trig);
} else {
st->last_value = at91_adc_readl(st, AT91_ADC_CHAN(st,
st->chnb));
+ /* Needed to ACK the DRDY interruption */
+ at91_adc_readl(st, AT91_ADC_LCDR);
st->done = true;
wake_up_interruptible(&st->wq_data_avail);
}
--
2.7.4
Re: [PATCH] memory_hotplug: Free pages as higher order
On 2018-09-21 21:12, Dan Williams wrote:
On Fri, Sep 21, 2018 at 2:40 AM Arun KS wrote:
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%.
Modify external providers of online callback to align with
the change.
Signed-off-by: Arun KS
---
Changes since RFC:
- Rebase.
- As suggested by Michal Hocko remove pages_per_block.
- Modifed external providers of online_page_callback.
RFC:
https://lore.kernel.org/patchwork/patch/984754/
---
drivers/hv/hv_balloon.c| 6 +++--
drivers/xen/balloon.c | 18 +++---
include/linux/memory_hotplug.h | 2 +-
mm/memory_hotplug.c| 55
+-
4 files changed, 63 insertions(+), 18 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b1b7880..c5bc0b5 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -771,7 +771,7 @@ static void hv_mem_hot_add(unsigned long start,
unsigned long size,
}
}
-static void hv_online_page(struct page *pg)
+static int hv_online_page(struct page *pg, unsigned int order)
{
struct hv_hotadd_state *has;
unsigned long flags;
@@ -783,10 +783,12 @@ static void hv_online_page(struct page *pg)
if ((pfn < has->start_pfn) || (pfn >= has->end_pfn))
continue;
- hv_page_online_one(has, pg);
+ hv_bring_pgs_online(has, pfn, (1UL << order));
break;
}
spin_unlock_irqrestore(&dm_device.ha_lock, flags);
+
+ return 0;
}
static int pfn_covered(unsigned long start_pfn, unsigned long
pfn_cnt)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index e12bb25..010cf4d 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -390,8 +390,8 @@ static enum bp_state
reserve_additional_memory(void)
/*
* add_memory_resource() will call online_pages() which in its
turn
-* will call xen_online_page() callback causing deadlock if we
don't
-* release balloon_mutex here. Unlocking here is safe because
the
+* will call xen_bring_pgs_online() callback causing deadlock
if we
+* don't release balloon_mutex here. Unlocking here is safe
because the
* callers drop the mutex before trying again.
*/
mutex_unlock(&balloon_mutex);
@@ -422,6 +422,18 @@ static void xen_online_page(struct page *page)
mutex_unlock(&balloon_mutex);
}
+static int xen_bring_pgs_online(struct page *pg, unsigned int order)
+{
+ unsigned long i, size = (1 << order);
+ unsigned long start_pfn = page_to_pfn(pg);
+
+ pr_debug("Online %lu pages starting at pfn 0x%lx\n", size,
start_pfn);
+ for (i = 0; i < size; i++)
+ xen_online_page(pfn_to_page(start_pfn + i));
+
+ return 0;
+}
+
static int xen_memory_notifier(struct notifier_block *nb, unsigned
long val, void *v)
{
if (val == MEM_ONLINE)
@@ -744,7 +756,7 @@ static int __init balloon_init(void)
balloon_stats.max_retry_count = RETRY_UNLIMITED;
#ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
- set_online_page_callback(&xen_online_page);
+ set_online_page_callback(&xen_bring_pgs_online);
register_memory_notifier(&xen_memory_nb);
register_sysctl_table(xen_root);
diff --git a/include/linux/memory_hotplug.h
b/include/linux/memory_hotplug.h
index 34a2822..7b04c1d 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -87,7 +87,7 @@ extern int test_pages_in_a_zone(unsigned long
start_pfn, unsigned long end_pfn,
unsigned long *valid_start, unsigned long *valid_end);
extern void __offline_isolated_pages(unsigned long, unsigned long);
-typedef void (*online_page_callback_t)(struct page *page);
+typedef int (*online_page_callback_t)(struct page *page, unsigned int
order);
extern int set_online_page_callback(online_page_callback_t callback);
extern int restore_online_page_callback(online_page_callback_t
callback);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 38d94b7..24c2b8e 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -47,7 +47,7 @@
* and restore_online_page_callback() for generic callback restore.
*/
-static void generic_online_page(struct page *page);
+static int generic_online_page(struct page *page, unsigned int
order);
static online_page_callback_t online_page_callback =
generic_online_page;
static DEFINE_MUTEX(online_page_callback_lock);
@@ -655,26 +655,57 @@ void __online_page_free(struct page *page)
}
EXPORT_SYMBOL_GPL(__online_page_free);
-static void generic_online_page(struct page *page)
+static int generic_online_page(struct page *page, unsigned int order)
{
- __online_page_set_limits(page);
- _
Re: [PATCH] framewarn: expand KASAN_EXTRA exception to KASAN
On Sat, Sep 22, 2018 at 4:56 PM, Arnd Bergmann wrote: > On Fri, Sep 21, 2018 at 2:45 AM Dmitry Vyukov wrote: >> >> On Fri, Sep 21, 2018 at 11:25 AM, Andrey Ryabinin >> wrote: >> > On 09/21/2018 04:50 AM, Andy Lutomirski wrote: >> >> This patch seems reasonable, but you emailed the wrong people :) >> >> >> >> On Thu, Sep 20, 2018 at 5:15 PM Jason A. Donenfeld >> >> wrote: >> >>> >> >>> It turns out that KASAN in general will bloat stack frames in unexpected >> >>> ways, not just KASAN_EXTRA. So, this patch trivially changes that >> >>> default to be associated with KASAN instead of KASAN_EXTRA. >> >>> >> > >> > KASAN_EXTRA bloats stack more than just KASAN, that's why the limit is >> > higher than just for KASAN. >> > If want more details, tead the changelog from commit >> > e7c52b84fb18f08ce49b6067ae6285aca79084a8 >> > >> > If anything causes "stack frame > 2048" warning for KASAN we should at >> > least try to fix it, >> > I mean reduce stack usage. >> >> >> +Nick who is also hitting these warnings on clang/arm64 build. As far >> as I understand the situation there is much worse. >> >> I would be good to understand/fix the worst offenders. But the stack >> size increase with KASAN is a real, inherent thing. So if we live very >> close the edge, we can get people using different compilers and/or >> versions of compilers constantly breaking each other. And clang hits >> this warnings in lots of places today just because the current code >> was tailored to gcc over long period, i.e. allowing more locals where >> gcc happened to handle that better and having fewer locals where gcc >> happened to handle it worse. But for another compiler all these >> assumptions are significantly perturbed. >> >> Nick, do you know what frame size limit eliminates the bulk of >> warnings on clang? Is 3072 a reasonable limit allowing to fix the >> remaining outliners? > > I do not consider 3072 a reasonable limit at all. For gcc, we managed to fix > or > work around all the bugs that caused excessive stack usage. In almost all > cases there was something seriously wrong with code generation. I added > the KASAN_EXTRA option for the one thing that added an inherent significant > overhead to the stack usage. > > llvm apparently has a similar bug to what we fixed in gcc. I created a > reduced test case for one of the file at: > https://bugs.llvm.org/show_bug.cgi?id=38809 > > Unfortunately, nobody has commented on that so far, but in the > meantime I think the best workaround would be to disable asan-stack > entirely when building with clang, and moving it to KASAN_EXTRA > there, like we did with the scope check on gcc. Good point. I CCed more people on https://bugs.llvm.org/show_bug.cgi?id=38809
Re: [PATCH] clk: tegra: Fix an infinite loop when clock rate is zero
On Fri, Sep 21, 2018 at 06:00:37PM -0400, ryang wrote: > Calling clk_set_rate or clk_round_rate will lock up the kernel when the > rate is zero. This avoids the infinite loop and uses a slightly more > optimized p divider calculation. > Acked-By: Peter De Schrijver At some point we should also limit pdiv to its maximum possible value, but that's not so obvious as we need to take into account PLLs where pdiv is non-linear. Peter. > Signed-off-by: ryang > --- > drivers/clk/tegra/clk-pll.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c > index 830d1c87fa7c..17a058c3bbc1 100644 > --- a/drivers/clk/tegra/clk-pll.c > +++ b/drivers/clk/tegra/clk-pll.c > @@ -582,9 +582,8 @@ static int _calc_rate(struct clk_hw *hw, struct > tegra_clk_pll_freq_table *cfg, > } > > /* Raise VCO to guarantee 0.5% accuracy */ > - for (cfg->output_rate = rate; cfg->output_rate < 200 * cfreq; > - cfg->output_rate <<= 1) > - p_div++; > + p_div = rate ? fls((200 * cfreq) / rate) : 0; > + cfg->output_rate = rate << p_div; > > cfg->m = parent_rate / cfreq; > cfg->n = cfg->output_rate / cfreq; > -- > 2.17.1 >
Re: [PATCH RESEND 0/6] arm64: add support for generic cpu vulnerabilities
On Mon, Sep 17, 2018 at 02:35:08PM +0100, Will Deacon wrote: > On Wed, Sep 05, 2018 at 11:25:33AM +0200, Mian Yousaf Kaukab wrote: > > On Mon, Aug 27, 2018 at 04:33:04PM +0200, Mian Yousaf Kaukab wrote: > > > GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a > > > system is affected by vulnerabilities like meltdown and other variants > > > of spectre. This small series adds support for it in arm64. > > > > Marc, Will, Can you please review this series? > > Sorry it took so long to get to this, it's just consistently failed to > get to the top of my review queue. I had a quick look just now and there > are a few things to address before we can take the series. Thank you for the review. I will get back to you after fixing the comments as soon as possible. > > Cheers, > > Will Thanks, Yousaf
Re: [PATCH] clk: tegra: Return the exact clock rate from clk_round_rate
On Fri, Sep 21, 2018 at 06:01:49PM -0400, ryang wrote:
> The current behavior is that clk_round_rate would return the same clock
> rate passed to it for valid PLL configurations. This change will return
> the exact rate the PLL will provide in accordance with clk API.
>
> Signed-off-by: ryang
> ---
> drivers/clk/tegra/clk-pll.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
> index 17a058c3bbc1..36014a6ec42e 100644
> --- a/drivers/clk/tegra/clk-pll.c
> +++ b/drivers/clk/tegra/clk-pll.c
> @@ -595,7 +595,12 @@ static int _calc_rate(struct clk_hw *hw, struct
> tegra_clk_pll_freq_table *cfg,
> return -EINVAL;
> }
>
> - cfg->output_rate >>= p_div;
> + if (cfg->m == 0) {
> + cfg->output_rate = 0;
I think a WARN_ON() is appropriate here. the input divider should never be 0.
Peter.
> + } else {
> + cfg->output_rate = cfg->n * DIV_ROUND_UP(parent_rate, cfg->m);
> + cfg->output_rate >>= p_div;
> + }
>
> if (pll->params->pdiv_tohw) {
> ret = _p_div_to_hw(hw, 1 << p_div);
> --
> 2.17.1
>
Re: [PATCH] printk: inject caller information into the body of message
On 2018/09/19 20:02, Tetsuo Handa wrote: > On 2018/09/14 21:22, Sergey Senozhatsky wrote: >> The "SMP-safe" comment becomes a bit tricky when pr_line is used with a >> static buffer. Either we need to require synchronization - umm... and >> document it - or to provide some means of synchronization in pr_line(). >> Let's think what pr_line API should do about it. >> >> Any thoughts? >> > > I'm inclined to propose a simple one shown below, similar to just having > several "struct cont" for concurrent printk() users. > What Linus has commented is that implicit context is bad, and below one > uses explicit context. > After almost all users are converted to use below one, we might be able > to get rid of KERN_CONT support. The reason of using statically preallocated global buffers is that I think that it is inconvenient for KERN_CONT users to calculate necessary bytes only for avoiding message truncation. The pr_line might be passed to deep into the callchain and adjusting buffer size whenever the content's possible max length changes is as much painful as changing printk() to accept only one "const char *" argument. Even if we guarantee that any context can allocate buffer from kernel stack, we cannot guarantee that many concurrent printk() won't trigger lockup. Thus, I think that trying to allocate from finite static buffers with a fallback to unbuffered printk() upon failure is sufficient. By the way, kbuild test robot told me that I forgot to drop asmlinkage keyword. include/linux/printk.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/printk.h b/include/linux/printk.h index 889491b..3347442 100644 --- a/include/linux/printk.h +++ b/include/linux/printk.h @@ -178,7 +178,7 @@ asmlinkage __printf(1, 2) __cold void flush_printk_buffer(struct printk_buffer *ptr); __printf(2, 3) int buffered_printk(struct printk_buffer *ptr, const char *fmt, ...); -asmlinkage __printf(2, 0) +__printf(2, 0) int buffered_vprintk(struct printk_buffer *ptr, const char *fmt, va_list args); void put_printk_buffer(struct printk_buffer *ptr);
Re: [PATCH 1/2] gpiolib: Fix missing updates of bitmap index
On Mon, Sep 24, 2018 at 1:52 AM Janusz Krzysztofik wrote:
> In new code introduced by commit b17566a6b08b ("gpiolib: Implement fast
> processing path in get/set array"), bitmap index is not updated with
> next found zero bit position as it should while skipping over pins
> already processed via fast bitmap path, possibly resulting in an
> infinite loop. Fix it.
>
> Signed-off-by: Janusz Krzysztofik
Patch applied!
Thanks for working on getting this into shape!
Yours,
Linus Walleij
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: > > On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: > > > > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > > > On 20 September 2018 at 14:31, Florian Fainelli > > > wrote: > > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > > >>> On 20 September 2018 at 13:55, Florian Fainelli > > >>> wrote: > > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > > > On 19 September 2018 at 07:31, Jim Quinlan > > > wrote: > > >> The Broadcom STB PCIe host controller is intimately related to the > > >> memory subsystem. This close relationship adds complexity to how cpu > > >> system memory is mapped to PCIe memory. Ideally, this mapping is an > > >> identity mapping, or an identity mapping off by a constant. Not so > > >> in > > >> this case. > > >> > > >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB > > >> of system memory. Here is how the PCIe controller maps the > > >> system memory to PCIe memory: > > >> > > >> memc0-a@[03fff] <=> pci@[03fff] > > >> memc0-b@[1...13fff] <=> pci@[ 40007fff] > > >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > > >> memc1-b@[3...33fff] <=> pci@[ c000] > > >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] > > >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] > > >> > > > > > > So is describing this as > > > > > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > > > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > > > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > > > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > > > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > > > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > > > > > not working for you? I haven't tried this myself, but since DT permits > > > describing the inbound mappings this way, we should fix the code if it > > > doesn't work at the moment. > > > > You mean encoding the memory controller index in the first cell? If > > that > > works, that's indeed a much cleaner solution, though is it standard > > compliant in any form? > > >>> > > >>> No those are just memory addresses (although I may have screwed up the > > >>> order). From Documentation/devicetree/booting-without-of.txt: > > >>> > > >>> """ > > >>> Optional property: > > >>> - dma-ranges: encoded as arbitrary number of > > >>> triplets of > > >>> (child-bus-address, parent-bus-address, length). Each triplet > > >>> specified > > >>> describes a contiguous DMA address range. > > >>> """ > > >>> > > >> > > >> Then I am confused by your comment, that's what this patch does, it adds > > >> support for reading "dma-ranges" from Device Tree and setting up inbound > > >> windows using that. The only caveat is that because the PCIe root > > >> complex has some ties with the memory bus architecture it is connected > > >> to (SCB in our case) there is still a requirement to know the > > >> translation between a given physical address and its backing memory > > >> controller/aperture. > > >> > > > > > > Ah ok, apologies for the noise then. > > > > > > I was hoping that having working support for dma-ranges would remove > > > the need for the special phys<->dma conversion routines. > > > > What you describe definitively works with platform devices, but I am not > > sure this is working for PCIe devices, although, conceptually it should, > > yes. > Sorry for my delay in responding. One problem is that > of_dma_configure() only looks at the first dma-range given and then > converts it to dev->dma_pfn_offset which is respected by the DMA API. > However, we often have multiple dma-ranges, not just one. This is the > big issue. > Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? In any case, the description of dma-ranges should be in sync with the way Linux interprets it, so this is either a documentation bug or a DMA layer bug. > There is another issue with of_dma_configure() being invoked by the EP > driver on "bridge->parent->of_node", which is our RC device, > Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of > our RC's device node and this misses the dma-ranges property which is > contained within the RC. I think I could workaround this but there is > no getting around the first problem. > IIUC dma-ranges should be added to the parent bus of a device, which I guess is slightly ambiguous for a root complex that incorporates a host bridge.
[PATCH RT] tty: serial: pl011: fix warning about uninitialized variable
Silence the following gcc warning:
drivers/tty/serial/amba-pl011.c: In function ‘pl011_console_write’:
./include/linux/spinlock.h:260:3: warning: ‘flags’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
_raw_spin_unlock_irqrestore(lock, flags); \
^~~
drivers/tty/serial/amba-pl011.c:2214:16: note: ‘flags’ was declared here
unsigned long flags;
^
The code is correct. Thus, initializing flags to zero doesn't change the
behavior and resolves the warning.
Signed-off-by: Kurt Kanzenbach
---
drivers/tty/serial/amba-pl011.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 484861278e9c..a658214486e7 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2211,7 +2211,7 @@ pl011_console_write(struct console *co, const char *s,
unsigned int count)
{
struct uart_amba_port *uap = amba_ports[co->index];
unsigned int old_cr = 0, new_cr;
- unsigned long flags;
+ unsigned long flags = 0;
int locked = 1;
clk_enable(uap->clk);
--
2.11.0
Re: [PATCH] ARM: dts: Add support for Liebherr's BK4 device (vf610 based)
Hi Fabio,
Thanks for your review.
> On Fri, Sep 21, 2018 at 12:27 PM, Lukasz Majewski
> wrote:
> > This commit adds DTS support for BK4 device from Liebherr. It
> > uses vf610 SoC from NXP.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/vf610-bk4.dts | 504
> > 2 files changed, 505
> > insertions(+) create mode 100644 arch/arm/boot/dts/vf610-bk4.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index b5bd3de87c33..e6f159895fa9 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -577,6 +577,7 @@ dtb-$(CONFIG_SOC_LS1021A) += \
> > ls1021a-twr.dtb
> > dtb-$(CONFIG_SOC_VF610) += \
> > vf500-colibri-eval-v3.dtb \
> > + vf610-bk4.dtb \
> > vf610-colibri-eval-v3.dtb \
> > vf610m4-colibri.dtb \
> > vf610-cosmic.dtb \
> > diff --git a/arch/arm/boot/dts/vf610-bk4.dts
> > b/arch/arm/boot/dts/vf610-bk4.dts new file mode 100644
> > index ..4ad7e739a0ad
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vf610-bk4.dts
> > @@ -0,0 +1,504 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2018
> > + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> > + */
> > +
> > +/dts-v1/;
> > +#include "vf610.dtsi"
> > +
> > +/ {
> > + model = "Liebherr BK4 controller";
> > + compatible = "lwn,bk4", "fsl,vf610";
> > +
> > + chosen {
> > + bootargs = "console=ttyLP1,115200";
>
> You could pass stdout-path instead.
Ok.
>
> > + };
> > +
> > + memory@8000 {
> > + reg = <0x8000 0x800>;
> > + };
> > +
> > + audio_ext: mclk_osc {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <24576000>;
> > + };
>
> This seems to be unused.
The audio_ext label is used (referenced) in the "clks".
>
> > +
> > + enet_ext: eth_osc {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <5000>;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpio_leds>;
> > +
> > + /* LED D5 */
> > + led0: heartbeat {
> > + label = "heartbeat";
> > + gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> > + default-state = "on";
> > + linux,default-trigger = "heartbeat";
> > + };
> > + };
> > +
> > + regulators {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + reg_3p3v: regulator@0 {
>
> Please move all regulators outside of the simple-bus container and use
> this naming convention:
>
> reg_3p3v: regulator-3p3v {
Ok.
>
> > +&dspi3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_dspi3>;
> > + bus-num = <3>;
> > + status = "okay";
> > +
> > + spidev3@0 {
> > + compatible = "fsl,vf610-dspi";
> > + spi-max-frequency = <3000>;
> > + reg = <0>;
> > + fsl,spi-slave-mode;
>
> Such property does not exist.
It has been added in the other patch sent to ML:
https://lkml.org/lkml/2018/9/18/792
But till now no comments/reply.
>
> I also thought that spidev nodes in dt were not recommended.
This is a bit "unusual" on BK4, as the spidev driver is the only "user"
of the SPI subsystem on this board. In other words - the /dev/spidevX.Y
provided by spidev is solely used for communication.
Hence, I would prefer to make it explicit in the DTS.
>
> > +&iomuxc {
>
> Like Stefan mentioned it is common practice on imx dts files to place
> the iomuxc node as the last one.
Ok.
>
>
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_bk4_common>;
>
> This seems to be not called from any driver.
Yes. This is "base" setup for the board. Those configured pins are
thereafter used by several user space programs.
>
> We usually use a hog group for such purpose.
I wanted to name it explicit that we do use it for this controller.
However, no problem to rename it to hog.
>
> > +
> > + pinctrl_bk4_common: commongrp {
> > + fsl,pins = <
> > + /* One_Wire_PSU_EN */
> > + VF610_PAD_PTC29__GPIO_102
> > 0x1183
> > + /* SPI */
> > + VF610_PAD_PTB26__GPIO_96
> > 0x1183
> > + VF610_PAD_PTE14__GPIO_119
> > 0x1183
> > + VF610_PAD_PTE4__GPIO_109
> > 0x1181
> > + /* Feedback_Lines */
> > + VF610_PAD
Re: [PATCH v10 25/26] KVM: s390: CPU model support for AP virtualization
On 22/09/2018 01:31, Tony Krowiak wrote:
> On 09/12/2018 03:43 PM, Tony Krowiak wrote:
>> From: Tony Krowiak
>>
>> Introduces a new CPU model feature and two CPU model
>> facilities to support AP virtualization for KVM guests.
>>
>> CPU model feature:
>>
>> The KVM_S390_VM_CPU_FEAT_AP feature indicates that
>> AP instructions are available on the guest. This
>> feature will be enabled by the kernel only if the AP
>> instructions are installed on the linux host. This feature
>> must be specifically turned on for the KVM guest from
>> userspace to use the VFIO AP device driver for guest
>> access to AP devices.
>>
>> CPU model facilities:
>>
>> 1. AP Query Configuration Information (QCI) facility is installed.
>>
>> This is indicated by setting facilities bit 12 for
>> the guest. The kernel will not enable this facility
>> for the guest if it is not set on the host.
>>
>> If this facility is not set for the KVM guest, then only
>> APQNs with an APQI less than 16 will be used by a Linux
>> guest regardless of the matrix configuration for the virtual
>> machine. This is a limitation of the Linux AP bus.
>>
>> 2. AP Facilities Test facility (APFT) is installed.
>>
>> This is indicated by setting facilities bit 15 for
>> the guest. The kernel will not enable this facility for
>> the guest if it is not set on the host.
>>
>> If this facility is not set for the KVM guest, then no
>> AP devices will be available to the guest regardless of
>> the guest's matrix configuration for the virtual
>> machine. This is a limitation of the Linux AP bus.
>>
>> Signed-off-by: Tony Krowiak
>> Reviewed-by: Christian Borntraeger
>> Reviewed-by: Halil Pasic
>> Reviewed-by: David Hildenbrand
>> Tested-by: Michael Mueller
>> Tested-by: Farhan Ali
>> Signed-off-by: Christian Borntraeger
>> ---
>> arch/s390/kvm/kvm-s390.c |5 +
>> arch/s390/tools/gen_facilities.c |2 ++
>> 2 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index 286c2e0..f0b8e2a 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -371,6 +371,11 @@ static void kvm_s390_cpu_feat_init(void)
>>
>> if (MACHINE_HAS_ESOP)
>> allow_cpu_feat(KVM_S390_VM_CPU_FEAT_ESOP);
>> +
>> +/* Check if AP instructions installed on host */
>> +if (ap_instructions_available())
>> +allow_cpu_feat(KVM_S390_VM_CPU_FEAT_AP);
>> +
>> /*
>> * We need SIE support, ESOP (PROT_READ protection for gmap_shadow),
>> * 64bit SCAO (SCA passthrough) and IDTE (for gmap_shadow unshadowing).
>> diff --git a/arch/s390/tools/gen_facilities.c
>> b/arch/s390/tools/gen_facilities.c
>> index 0c85aed..fd788e0 100644
>> --- a/arch/s390/tools/gen_facilities.c
>> +++ b/arch/s390/tools/gen_facilities.c
>> @@ -106,6 +106,8 @@ struct facility_def {
>>
>> .name = "FACILITIES_KVM_CPUMODEL",
>> .bits = (int[]){
>> +12, /* AP Query Configuration Information */
>> +15, /* AP Facilities Test */
>> 156, /* etoken facility */
>> -1 /* END */
>> }
>>
>
> The fixup! patch below modifies this patch (25/26) to illustrate how
> David's recommendation will be implemented for v11 of the series. It
> is one of three fixup! patches (the other two are in responses to
> 03/26 and 11/26) included to generate discussion in v10 rather than
> waiting until v11 for comments.
>
> ---8<---
>
> From: Tony Krowiak
> Date: Thu, 20 Sep 2018 13:28:07 -0400
> Subject: [FIXUP v10] fixup!: KVM: s390: CPU model support for AP
> virtualization
>
> ---
> arch/s390/kvm/kvm-s390.c |4
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index a3a7cd9..ff38251 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -372,10 +372,6 @@ static void kvm_s390_cpu_feat_init(void)
> if (MACHINE_HAS_ESOP)
> allow_cpu_feat(KVM_S390_VM_CPU_FEAT_ESOP);
>
> - /* Check if AP instructions installed on host */
> - if (ap_instructions_available())
> - allow_cpu_feat(KVM_S390_VM_CPU_FEAT_AP);
> -
> /*
>* We need SIE support, ESOP (PROT_READ protection for gmap_shadow),
>* 64bit SCAO (SCA passthrough) and IDTE (for gmap_shadow unshadowing).
>
Yes, looks sane.
--
Thanks,
David / dhildenb
Re: [PATCH] tools: Remove conflicting BITS_PER_LONG define
Hello Arnaldo,
Em Wed, Sep 12, 2018 at 07:02:32PM +0200, Alexander Sverdlin escreveu:
> CC .../tools/objtool/builtin-check.o
> ...
> In file included from
> .../tools/arch/x86/include/uapi/asm/bitsperlong.h:11:0,
> from .../tools/include/asm-generic/bitops/__ffs.h:6,
> from .../tools/include/asm-generic/bitops.h:16,
> from .../tools/include/linux/bitops.h:35,
> from .../tools/include/linux/hashtable.h:13,
> from elf.h:24,
> from check.h:22,
> from builtin-check.c:30:
> .../tools/include/asm-generic/bitsperlong.h:8:0: error: "BITS_PER_LONG"
> redefined [-Werror]
> #define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
[...]
finally I more or less know what happens here. In the actual Linux we have two
files defining the
same define:
>> # 1 ".../tools/include/linux/bitops.h" 1
#ifndef BITS_PER_LONG
# define BITS_PER_LONG __WORDSIZE
#endif
>> # 6 ".../tools/include/asm-generic/bitsperlong.h" 2
#ifdef __SIZEOF_LONG__
#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
#else
#define BITS_PER_LONG __WORDSIZE
#endif
So the two defines only work together if bitsperlong.h is included first.
In objtool both files are included and for most people bitsperlong.h is indeed
included first.
> I'll try and get one for building a x86_64 tools/perf,
> tools/lib/{api,bpf,traceevent} to see if I manage to reproduce the
> problem you're reporting.
One way to reproduce the reverted include order is to take a HOST compiler
built against old Linux headers, namely 2.6.30 and older.
This is because of the changes in asm/types.h.
It would be possible to put a guard into bitsperlong.h (#ifndef BITS_PER_LONG),
but it just doesn't look correct to me that we have two files defining the same
thing once quite simple, in the second case even more tricky.
--
Best regards,
Alexander Sverdlin.
Re: [PATCH v10 03/26] KVM: s390: refactor crypto initialization
On 22/09/2018 01:18, Tony Krowiak wrote:
> On 09/12/2018 03:42 PM, Tony Krowiak wrote:
>> From: Tony Krowiak
>>
>> This patch refactors the code that initializes and sets up the
>> crypto configuration for a guest. The following changes are
>> implemented via this patch:
>>
>> 1. Prior to the introduction of AP device virtualization, it
>> was not necessary to provide guest access to the CRYCB
>> unless the MSA extension 3 (MSAX3) facility was installed
>> on the host system. With the introduction of AP device
>> virtualization, the CRYCB must be made accessible to the
>> guest if the AP instructions are installed on the host
>> and are to be provided to the guest.
>>
>> 2. Introduces a flag indicating AP instructions executed on
>> the guest shall be interpreted by the firmware. It is
>> initialized to indicate AP instructions are to be
>> to be interpreted and is used to set the SIE bit for
>> each vcpu during vcpu setup.
>>
>> Signed-off-by: Tony Krowiak
>> Reviewed-by: Halil Pasic
>> Acked-by: Christian Borntraeger
>> Acked-by: Janosch Frank
>> Tested-by: Michael Mueller
>> Tested-by: Farhan Ali
>> Signed-off-by: Christian Borntraeger
>> ---
>> arch/s390/include/asm/kvm_host.h |2 +
>> arch/s390/include/uapi/asm/kvm.h |1 +
>> arch/s390/kvm/kvm-s390.c | 71
>> ++
>> 3 files changed, 37 insertions(+), 37 deletions(-)
>>
>
> (...)
>
>> diff --git a/arch/s390/include/uapi/asm/kvm.h
>> b/arch/s390/include/uapi/asm/kvm.h
>> index 9a50f02..8c23afc 100644
>> --- a/arch/s390/include/uapi/asm/kvm.h
>> +++ b/arch/s390/include/uapi/asm/kvm.h
>> @@ -130,6 +130,7 @@ struct kvm_s390_vm_cpu_machine {
>> #define KVM_S390_VM_CPU_FEAT_PFMFI 11
>> #define KVM_S390_VM_CPU_FEAT_SIGPIF12
>> #define KVM_S390_VM_CPU_FEAT_KSS 13
>> +#define KVM_S390_VM_CPU_FEAT_AP 14
>> struct kvm_s390_vm_cpu_feat {
>> __u64 feat[16];
>> };
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index 876fbb2..d717041 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -40,6 +40,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include "kvm-s390.h"
>> #include "gaccess.h"
>>
>
> (...)
>
>> @@ -2586,17 +2575,25 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
>>
>> static void kvm_s390_vcpu_crypto_setup(struct kvm_vcpu *vcpu)
>> {
>> -if (!test_kvm_facility(vcpu->kvm, 76))
>> +/*
>> + * If neither the AP instructions nor the MSAX3 facility are configured
>> + * for the guest, there is nothing to set up.
>> + */
>> +if (!test_kvm_cpu_feat(vcpu->kvm, KVM_S390_VM_CPU_FEAT_AP) &&
>> +!test_kvm_facility(vcpu->kvm, 76))
>> return;
>>
>> +vcpu->arch.sie_block->crycbd = vcpu->kvm->arch.crypto.crycbd;
>> vcpu->arch.sie_block->ecb3 &= ~(ECB3_AES | ECB3_DEA);
>>
>> +if (test_kvm_cpu_feat(vcpu->kvm, KVM_S390_VM_CPU_FEAT_AP))
>> +vcpu->arch.sie_block->eca |= ECA_APIE;
>> +
>> +/* Set up protected key support */
>> if (vcpu->kvm->arch.crypto.aes_kw)
>> vcpu->arch.sie_block->ecb3 |= ECB3_AES;
>> if (vcpu->kvm->arch.crypto.dea_kw)
>> vcpu->arch.sie_block->ecb3 |= ECB3_DEA;
>> -
>> -vcpu->arch.sie_block->crycbd = vcpu->kvm->arch.crypto.crycbd;
>> }
>>
>> void kvm_s390_vcpu_unsetup_cmma(struct kvm_vcpu *vcpu)
>>
>
> The fixup! patch below modifies this patch (03/26) to illustrate how
>
> David's recommendation will be implemented for v11 of the series. It
>
> is one of three fixup! patches (the other two are in responses to
> 11/26
> and 25/26) included to generate discussion in v10 rather than
>
> waiting until v11 for comments.
>
> ---8<---
>
> From: Tony Krowiak
> Date: Thu, 20 Sep 2018 12:26:08 -0400
> Subject: [FIXUP v10] fixup!: KVM: s390: refactor crypto initialization
>
> ---
> arch/s390/include/asm/kvm_host.h |1 +
> arch/s390/include/uapi/asm/kvm.h |1 -
> arch/s390/kvm/kvm-s390.c |9 -
> 3 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/arch/s390/include/asm/kvm_host.h
> b/arch/s390/include/asm/kvm_host.h
> index 423cce7..79fa0a3 100644
> --- a/arch/s390/include/asm/kvm_host.h
> +++ b/arch/s390/include/asm/kvm_host.h
> @@ -718,6 +718,7 @@ struct kvm_s390_crypto {
> __u32 crycbd;
> __u8 aes_kw;
> __u8 dea_kw;
> + __u8 apie;
> };
>
> #define APCB0_MASK_SIZE 1
> diff --git a/arch/s390/include/uapi/asm/kvm.h
> b/arch/s390/include/uapi/asm/kvm.h
> index 8c23afc..9a50f02 100644
> --- a/arch/s390/include/uapi/asm/kvm.h
> +++ b/arch/s390/include/uapi/asm/kvm.h
> @@ -130,7 +130,6 @@ struct kvm_s390_vm_cpu_machine {
> #define KVM_S390_VM_CPU_FEAT_PFMFI 11
> #define KVM_S390_VM_CPU_FEAT_SIGPIF 12
> #define KVM_S390_VM_CPU_FEAT_KSS13
> -#define KVM_
Re: [RESEND PATCH v3 2/2] PCI: meson: add the Amlogic Meson PCIe controller driver
Hi Hanjie, On 21/09/2018 07:03, Hanjie Lin wrote: > From: Yue Wang > > The Amlogic Meson PCIe host controller is based on the Synopsys DesignWare > PCI core. This patch adds the driver support for Meson PCIe controller. > > Signed-off-by: Yue Wang > Signed-off-by: Hanjie Lin > --- > drivers/pci/controller/dwc/Kconfig | 12 + > drivers/pci/controller/dwc/Makefile| 1 + > drivers/pci/controller/dwc/pci-meson.c | 617 > + > 3 files changed, 630 insertions(+) > create mode 100644 drivers/pci/controller/dwc/pci-meson.c > > diff --git a/drivers/pci/controller/dwc/Kconfig > b/drivers/pci/controller/dwc/Kconfig > index 91b0194..6cb36f6 100644 > --- a/drivers/pci/controller/dwc/Kconfig > +++ b/drivers/pci/controller/dwc/Kconfig > @@ -193,4 +193,16 @@ config PCIE_HISI_STB > help >Say Y here if you want PCIe controller support on HiSilicon STB > SoCs > > +config PCI_MESON > + bool "MESON PCIe controller" > + depends on PCI > + depends on PCI_MSI_IRQ_DOMAIN I would suggest to compress the previous 2 line into in just one, like: depends on PCI && PCI_MSI_IRQ_DOMAIN Regards, Gustavo > + select PCIEPORTBUS > + select PCIE_DW_HOST > + help > + Say Y here if you want to enable PCI controller support on Amlogic > + SoCs. The PCI controller on Amlogic is based on DesignWare hardware > + and therefore the driver re-uses the DesignWare core functions to > + implement the driver. > + > endmenu > diff --git a/drivers/pci/controller/dwc/Makefile > b/drivers/pci/controller/dwc/Makefile > index 5d2ce72..cf676bd 100644 > --- a/drivers/pci/controller/dwc/Makefile > +++ b/drivers/pci/controller/dwc/Makefile > @@ -14,6 +14,7 @@ obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o > obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o > obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o > obj-$(CONFIG_PCIE_HISI_STB) += pcie-histb.o > +obj-$(CONFIG_PCI_MESON) += pci-meson.o > > # The following drivers are for devices that use the generic ACPI > # pci_root.c driver but don't support standard ECAM config access. > diff --git a/drivers/pci/controller/dwc/pci-meson.c > b/drivers/pci/controller/dwc/pci-meson.c > new file mode 100644 > index 000..9c92a89 > --- /dev/null > +++ b/drivers/pci/controller/dwc/pci-meson.c > @@ -0,0 +1,617 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * PCIe host controller driver for Amlogic MESON SoCs > + * > + * Copyright (c) 2018 Amlogic, inc. > + * Author: Yue Wang > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "pcie-designware.h" > + > +#define to_meson_pcie(x) dev_get_drvdata((x)->dev) > + > +/* External local bus interface registers */ > +#define PLR_OFFSET 0x700 > +#define PCIE_PORT_LINK_CTRL_OFF (PLR_OFFSET + 0x10) > +#define FAST_LINK_MODE BIT(7) > +#define LINK_CAPABLE_MASKGENMASK(21, 16) > +#define LINK_CAPABLE_X1 BIT(16) > + > +#define PCIE_GEN2_CTRL_OFF (PLR_OFFSET + 0x10c) > +#define NUM_OF_LANES_MASKGENMASK(12, 8) > +#define NUM_OF_LANES_X1 BIT(8) > +#define DIRECT_SPEED_CHANGE BIT(17) > + > +#define TYPE1_HDR_OFFSET 0x0 > +#define PCIE_STATUS_COMMAND (TYPE1_HDR_OFFSET + 0x04) > +#define PCI_IO_ENBIT(0) > +#define PCI_MEM_SPACE_EN BIT(1) > +#define PCI_BUS_MASTER_ENBIT(2) > + > +#define PCIE_BASE_ADDR0 (TYPE1_HDR_OFFSET + 0x10) > +#define PCIE_BASE_ADDR1 (TYPE1_HDR_OFFSET + 0x14) > + > +#define PCIE_CAP_OFFSET 0x70 > +#define PCIE_DEV_CTRL_DEV_STUS (PCIE_CAP_OFFSET + 0x08) > +#define PCIE_CAP_MAX_PAYLOAD_MASKGENMASK(7, 5) > +#define PCIE_CAP_MAX_PAYLOAD_SIZE(x) ((x) << 5) > +#define PCIE_CAP_MAX_READ_REQ_MASK GENMASK(14, 12) > +#define PCIE_CAP_MAX_READ_REQ_SIZE(x)((x) << 12) > + > +#define PCI_CLASS_REVISION_MASK GENMASK(7, 0) > + > +/* PCIe specific config registers */ > +#define PCIE_CFG00x0 > +#define APP_LTSSM_ENABLE BIT(7) > + > +#define PCIE_CFG_STATUS120x30 > +#define IS_SMLH_LINK_UP(x) ((x) & (1 << 6)) > +#define IS_RDLH_LINK_UP(x) ((x) & (1 << 16)) > +#define IS_LTSSM_UP(x) x) >> 10) & 0x1f) == 0x11) > + > +#define PCIE_CFG_STATUS170x44 > +#define PM_CURRENT_STATE(x) (((x) >> 7) & 0x1) > + > +#define WAIT_LINKUP_TIMEOUT 2000 > +#define PORT_CLK_RATE1UL > +#define MAX_PAYLOAD_SIZE 256 > +#define MAX_READ_REQ_SIZE256 > +#define MESON_PCIE_PHY_POWERUP 0x1c > +#define PCIE_RESET_DELAY 500 > +#define PCIE_SHARED_RESET1 > +#define PCIE_NORMAL_RESET0 > + > +
Re: [PATCH v10 11/26] s390: vfio-ap: implement mediated device open callback
> /**
> - * Verify that the AP instructions are available on the guest. This is
> indicated
> - * via the KVM_S390_VM_CPU_FEAT_AP CPU model feature.
> + * Verify that the AP instructions are being interpreted by firmware
> for the
> + * guest. This is indicated by the kvm->arch.crypto.apie flag.
>*/
> static int kvm_ap_validate_crypto_setup(struct kvm *kvm)
> {
> - if (test_bit_inv(KVM_S390_VM_CPU_FEAT_AP, kvm->arch.cpu_feat))
> + if (kvm->arch.crypto.apie)
> return 0;
I wonder if this check makes sense, because apie can be toggled during
runtime. I guess it would be sufficient to check if the ap control block
is available and apie is supported by the HW.
--
Thanks,
David / dhildenb
RE: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller
Hi Boris & Miquel, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Saturday, September 22, 2018 1:43 PM > To: Miquel Raynal > Cc: Naga Sureshkumar Relli ; rich...@nod.at; > dw...@infradead.org; > computersforpe...@gmail.com; marek.va...@gmail.com; kyungmin.p...@samsung.com; > abs...@codeaurora.org; peterpand...@micron.com; frieder.schre...@exceet.de; > linux- > m...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek > ; > nagasureshkumarre...@gmail.com > Subject: Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for > Arasan NAND > Flash Controller > > On Sat, 22 Sep 2018 09:53:40 +0200 > Miquel Raynal wrote: > > > Hi Naga, > > > > Naga Sureshkumar Relli wrote on Tue, 11 Sep 2018 > > 05:23:09 +: > > > > > Hi Boris, > > > > > > > -Original Message- > > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > > > Sent: Monday, August 20, 2018 10:10 PM > > > > To: Naga Sureshkumar Relli > > > > Cc: miquel.ray...@bootlin.com; rich...@nod.at; > > > > dw...@infradead.org; computersforpe...@gmail.com; > > > > marek.va...@gmail.com; kyungmin.p...@samsung.com; > > > > abs...@codeaurora.org; peterpand...@micron.com; > > > > frieder.schre...@exceet.de; linux- m...@lists.infradead.org; > > > > linux-kernel@vger.kernel.org; Michal Simek ; > > > > nagasureshkumarre...@gmail.com > > > > Subject: Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add > > > > support for Arasan NAND Flash Controller > > > > > > > > Hi Naga, > > > > > > > > On Fri, 17 Aug 2018 18:49:24 +0530 Naga Sureshkumar Relli > > > > wrote: > > > > > > > > > > > > I haven't finished reviewing the driver but there are still a > > > > bunch of things that look strange, for instance, your > > > > ->read/write_page() implementation looks suspicious. Let's discuss that > > > > before you send a > new version. > > Sorry, I've been too busy to finish my review :-/. Please submit the new > version as Miquel > suggested. Ok, I will do. Thanks, Naga Sureshkumar Relli > > > > Could you please review the remaining stuff? > > > I have the changes ready with me which will address all your comments > > > given to this series. > > > > > > Thanks, > > > Naga Sureshkumar Relli > > > > Please submit the new version that is ready, the rest of the review > > will come. > > > > > > Thanks, > > Miquèl
Re: [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection
On Sat, 22 Sep 2018, Thomas Gleixner wrote: > Lunch and coffee indeed made brain work better. The simple solution was way > too obvious. Ah, cool, I like it a lot. Do you want me to fold this into v7, or are you on it already? Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH V4 00/27] C-SKY(csky) Linux Kernel Port
On Mon, Sep 24, 2018 at 9:21 AM Geert Uytterhoeven wrote: > > Hi Arnd, > > On Fri, Sep 21, 2018 at 7:19 AM Arnd Bergmann wrote: > > On Thu, Sep 20, 2018 at 10:52 AM Palmer Dabbelt wrote: > > > On Fri, 14 Sep 2018 07:37:20 PDT (-0700), ren_...@c-sky.com wrote: > > > > On Wed, Sep 12, 2018 at 04:30:36PM +0200, Arnd Bergmann wrote: > > > >> On Wed, Sep 12, 2018 at 3:25 PM Guo Ren wrote: > > My plan was to get that all into 4.20, and then have a conversation about > > the > > actual syscall table changes in 4.21. If we need it for both csky and rv32, > > we might just change the generic syscall table that way in 4.21 without > > changing all the other ones along with them. I don't want to drag things out > > over too many merge windows though, and my plan was to do all architectures > > together to simplify the version checks in the libc code to only have to > > check > > for a single version. > > What happens with the version checks if it is backported to stable? They end up as dead code. The way these version checks are done in glibc, we always try the new interface first before falling back to the old version, but don't check the kernel version at runtime. The compile-time check optimizes out the fallback if glibc is built for a recent-enough minimum kernel version that is guaranteed to have the new version. Arnd
Re: [PATCH 00/15] tools/lib/traceevent: Namespace updates to make traceevent into a library
On Sun, 23 Sep 2018 20:56:26 +0200 Jiri Olsa wrote: > > Steven, > is there still something left to rename, or we can start moving it into > public rpm? > We're testing it as a external library, and we did find something. Did you get this patch? https://lore.kernel.org/lkml/20180921152037.1e23c...@gandalf.local.home We're testing it against powertop and mceutils, when we get it working well with them, then I think it's time to start going ahead and making it into an rpm. Thanks Jiri! -- Steve
RE: [PATCH 1/4] soc/fsl/qbman: Check if CPU is offline when initializing portals
> -Original Message-
> From: Li Yang [mailto:leoyang...@nxp.com]
> Sent: Saturday, September 22, 2018 1:15 AM
> To: Madalin-cristian Bucur
> Subject: Re: [PATCH 1/4] soc/fsl/qbman: Check if CPU is offline when
> initializing portals
>
> On Thu, Sep 20, 2018 at 10:09 AM Madalin Bucur
> wrote:
> >
> > From: Roy Pledge
> >
> > If the affine portal for a specific CPU is offline at boot time
> > affine its interrupt to CPU 0. If the CPU is later brought online
> > the hotplug handler will correctly adjust the affinity.
>
> Although this does provide better compatibility with cpu hotplug, we
> still have a problem. You are assuming the CPU0 is always online
> which is not the case for arm64. How about not setting the affinity
> and let the system decide if the dedicated CPU is offline?
I can change the hardcoding of CPU 0 with raw_smp_processor_id().
While we're at it, I'd move the introduced code into a helper function
to avoid duplication:
static inline void dpaa_set_portal_irq_affinity(struct device* dev,
int cpu, int
irq)
> >
> > Signed-off-by: Roy Pledge
> > Signed-off-by: Madalin Bucur
> > ---
> > drivers/soc/fsl/qbman/bman.c | 17 +
> > drivers/soc/fsl/qbman/qman.c | 18 +-
> > 2 files changed, 26 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
> > index f9485cedc648..2e6e682bf16b 100644
> > --- a/drivers/soc/fsl/qbman/bman.c
> > +++ b/drivers/soc/fsl/qbman/bman.c
> > @@ -562,10 +562,19 @@ static int bman_create_portal(struct bman_portal
> *portal,
> > dev_err(c->dev, "request_irq() failed\n");
> > goto fail_irq;
> > }
> > - if (c->cpu != -1 && irq_can_set_affinity(c->irq) &&
> > - irq_set_affinity(c->irq, cpumask_of(c->cpu))) {
> > - dev_err(c->dev, "irq_set_affinity() failed\n");
> > - goto fail_affinity;
> > + if (cpu_online(c->cpu) && c->cpu != -1 &&
> > + irq_can_set_affinity(c->irq)) {
> > + if (irq_set_affinity(c->irq, cpumask_of(c->cpu))) {
> > + dev_err(c->dev, "irq_set_affinity() failed
> %d\n",
> > + c->cpu);
> > + goto fail_affinity;
> > + }
> > + } else {
> > + /* CPU is offline, direct IRQ to CPU 0 */
> > + if (irq_set_affinity(c->irq, cpumask_of(0))) {
> > + dev_err(c->dev, "irq_set_affinity() cpu 0
> failed\n");
> > + goto fail_affinity;
> > + }
> > }
> >
> > /* Need RCR to be empty before continuing */
> > diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
> > index ecb22749df0b..7dbcb475a59c 100644
> > --- a/drivers/soc/fsl/qbman/qman.c
> > +++ b/drivers/soc/fsl/qbman/qman.c
> > @@ -935,7 +935,6 @@ static inline int qm_mc_result_timeout(struct
> qm_portal *portal,
> > break;
> > udelay(1);
> > } while (--timeout);
> > -
> > return timeout;
> > }
> >
> > @@ -1210,10 +1209,19 @@ static int qman_create_portal(struct qman_portal
> *portal,
> > dev_err(c->dev, "request_irq() failed\n");
> > goto fail_irq;
> > }
> > - if (c->cpu != -1 && irq_can_set_affinity(c->irq) &&
> > - irq_set_affinity(c->irq, cpumask_of(c->cpu))) {
> > - dev_err(c->dev, "irq_set_affinity() failed\n");
> > - goto fail_affinity;
> > + if (cpu_online(c->cpu) && c->cpu != -1 &&
> > + irq_can_set_affinity(c->irq)) {
> > + if (irq_set_affinity(c->irq, cpumask_of(c->cpu))) {
> > + dev_err(c->dev, "irq_set_affinity() failed
> %d\n",
> > + c->cpu);
> > + goto fail_affinity;
> > + }
> > + } else {
> > + /* CPU is offline, direct IRQ to CPU 0 */
> > + if (irq_set_affinity(c->irq, cpumask_of(0))) {
> > + dev_err(c->dev, "irq_set_affinity() cpu 0
> failed\n");
> > + goto fail_affinity;
> > + }
> > }
> >
> > /* Need EQCR to be empty before continuing */
> > --
> > 2.1.0
> >
[PATCH] mmc: core: Allow building PWRSEQ_SD8787 with LIBERTAS_SDIO
The sd8686 "libertas" SDIO adapter's power is controlled with WLAN_RST and WLAN_PD pins -- pretty much the same way as sd8787. Allow building the power sequencing driver along with the libertas Wi-Fi driver. Signed-off-by: Lubomir Rintel --- drivers/mmc/core/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig index 42e89060cd41..2f38a7ad07e0 100644 --- a/drivers/mmc/core/Kconfig +++ b/drivers/mmc/core/Kconfig @@ -14,7 +14,7 @@ config PWRSEQ_EMMC config PWRSEQ_SD8787 tristate "HW reset support for SD8787 BT + Wifi module" - depends on OF && (MWIFIEX || BT_MRVL_SDIO) + depends on OF && (MWIFIEX || BT_MRVL_SDIO || LIBERTAS_SDIO) help This selects hardware reset support for the SD8787 BT + Wifi module. By default this option is set to n. -- 2.19.0
[PATCH 1/2] arm64: dts: marvell: armada-cp110: change the PPv2 IRQ names
This patch changes the PPv2 IRQ names in the CP110 device tree to match a corresponding change in the Marvell PPv2 driver. The reason this was updated is the IRQ where names after Tx/Rx interrupts, but this is not true and can be configured. A following patch will add more of them and the names wouldn't make sense. Signed-off-by: Antoine Tenart --- arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm64/boot/dts/marvell/armada-cp110.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110.dtsi index 840c8454d03e..6a13690cf1e4 100644 --- a/arch/arm64/boot/dts/marvell/armada-cp110.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-cp110.dtsi @@ -53,8 +53,8 @@ , , ; - interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2", - "tx-cpu3", "rx-shared", "link"; + interrupt-names = "hif0", "hif1", "hif2", + "hif3", "hif4", "link"; port-id = <0>; gop-port-id = <0>; status = "disabled"; @@ -67,8 +67,8 @@ , , ; - interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2", - "tx-cpu3", "rx-shared", "link"; + interrupt-names = "hif0", "hif1", "hif2", + "hif3", "hif4", "link"; port-id = <1>; gop-port-id = <2>; status = "disabled"; @@ -81,8 +81,8 @@ , , ; - interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2", - "tx-cpu3", "rx-shared", "link"; + interrupt-names = "hif0", "hif1", "hif2", + "hif3", "hif4", "link"; port-id = <2>; gop-port-id = <3>; status = "disabled"; -- 2.17.1
[PATCH 2/2] arm64: dts: marvell: armada-cp110: describe more PPv2 interrupts
This patch describes 3 additional interrupts per PPv2 port. Those interrupts will be used later in future versions of the Marvell PPv2 driver, and now the device tree description matches the hardware capabilities. Signed-off-by: Antoine Tenart --- arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 21 --- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/marvell/armada-cp110.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110.dtsi index 6a13690cf1e4..26d6e602d1ec 100644 --- a/arch/arm64/boot/dts/marvell/armada-cp110.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-cp110.dtsi @@ -52,9 +52,14 @@ , , , + , + , + , + , ; interrupt-names = "hif0", "hif1", "hif2", - "hif3", "hif4", "link"; + "hif3", "hif4", "hif5", "hif6", "hif7", + "hif8", "link"; port-id = <0>; gop-port-id = <0>; status = "disabled"; @@ -66,9 +71,14 @@ , , , + , + , + , + , ; interrupt-names = "hif0", "hif1", "hif2", - "hif3", "hif4", "link"; + "hif3", "hif4", "hif5", "hif6", "hif7", + "hif8", "link"; port-id = <1>; gop-port-id = <2>; status = "disabled"; @@ -80,9 +90,14 @@ , , , + , + , + , + , ; interrupt-names = "hif0", "hif1", "hif2", - "hif3", "hif4", "link"; + "hif3", "hif4", "hif5", "hif6", "hif7", + "hif8", "link"; port-id = <2>; gop-port-id = <3>; status = "disabled"; -- 2.17.1
[REVIEW][PATCH 00/15] signal/arm64: siginfo cleanups
This is the continuation of my work to sort out signaling of exceptions with siginfo. The old signal sending functions by taking a siginfo argument resulted in their callers having to deal with the fiddly nature of siginfo directly. In small numbers of callers this is not a problem but in the number of callers in the kernel this resulted in cases where fields were not initialized or improperly initialized before being passed to userspace. To avoid having to worry about those issues I have added new signal sending functions that each deal wit a different siginfo case. When using these functions there is no room for the fiddly nature of siginfo to cause mistakes. This is my set of changes to update arm64 to use those functions. Along with some refactoring so those functions can be cleanly used. Folks please review and double check me. I think I have kept these changes simple and obviously correct but I am human and mess up sometimes. After these patches have had a chance to be reviewed I plan to merge them by my siginfo tree. If you would rather take them in the arm64 tree let me know. All of the prerequisites should have been merged through Linus's tree several releases ago. Eric W. Biederman (15): signal/arm64: Push siginfo generation into arm64_notify_die signal/arm64: Remove unneeded tsk parameter from arm64_force_sig_info signal/arm64: Factor out arm64_show_signal from arm64_force_sig_info signal/arm64: Factor set_thread_esr out of __do_user_fault signal/arm64: Consolidate the two hwpoison cases in do_page_fault signal/arm64: For clarity separate the 3 signal sending cases in do_page_fault signal/arm64: Expand __do_user_fault and remove it signal/arm64: Only perform one esr_to_fault_info call in do_page_fault signal/arm64: Only call set_thread_esr once in do_page_fault signal/arm64: Add and use arm64_force_sig_fault where appropriate signal/arm64: Add and use arm64_force_sig_mceerr as appropriate signal/arm64: Remove arm64_force_sig_info signal/arm64: In ptrace_hbptriggered name the signal description string signal/arm64: Add and use arm64_force_sig_ptrace_errno_trap signal/arm64: Use send_sig_fault where appropriate arch/arm64/include/asm/system_misc.h | 3 +- arch/arm64/include/asm/traps.h | 5 +- arch/arm64/kernel/debug-monitors.c | 11 ++--- arch/arm64/kernel/fpsimd.c | 10 ++-- arch/arm64/kernel/ptrace.c | 16 +++--- arch/arm64/kernel/sys_compat.c | 13 ++--- arch/arm64/kernel/traps.c| 67 - arch/arm64/mm/fault.c| 94 +--- 8 files changed, 90 insertions(+), 129 deletions(-)
[REVIEW][PATCH 04/15] signal/arm64: Factor set_thread_esr out of __do_user_fault
This pepares for sending signals with something other than
arm64_force_sig_info.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/mm/fault.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index f42aff0e90ad..654a861c4bd0 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -297,9 +297,9 @@ static void __do_kernel_fault(unsigned long addr, unsigned
int esr,
die_kernel_fault(msg, addr, esr, regs);
}
-static void __do_user_fault(struct siginfo *info, unsigned int esr)
+static void set_thread_esr(unsigned long address, unsigned int esr)
{
- current->thread.fault_address = (unsigned long)info->si_addr;
+ current->thread.fault_address = address;
/*
* If the faulting address is in the kernel, we must sanitize the ESR.
@@ -352,6 +352,11 @@ static void __do_user_fault(struct siginfo *info, unsigned
int esr)
}
current->thread.fault_code = esr;
+}
+
+static void __do_user_fault(struct siginfo *info, unsigned int esr)
+{
+ set_thread_esr((unsigned long)info->si_addr, esr);
arm64_force_sig_info(info, esr_to_fault_info(esr)->name);
}
--
2.17.1
[REVIEW][PATCH 03/15] signal/arm64: Factor out arm64_show_signal from arm64_force_sig_info
Filling in siginfo is error prone and so it is wise to use more
specialized helpers to do that work. Factor out the arm specific
unhandled signal reporting from the work of delivering a signal so
the code can be modified to use functions that take the information
to fill out siginfo as parameters.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/kernel/traps.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 24035d124608..daee8c2ca561 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -224,24 +224,19 @@ void die(const char *str, struct pt_regs *regs, int err)
do_exit(SIGSEGV);
}
-static bool show_unhandled_signals_ratelimited(void)
+static void arm64_show_signal(int signo, const char *str)
{
static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
DEFAULT_RATELIMIT_BURST);
- return show_unhandled_signals && __ratelimit(&rs);
-}
-
-void arm64_force_sig_info(struct siginfo *info, const char *str)
-{
struct task_struct *tsk = current;
unsigned int esr = tsk->thread.fault_code;
struct pt_regs *regs = task_pt_regs(tsk);
- if (!unhandled_signal(tsk, info->si_signo))
- goto send_sig;
-
- if (!show_unhandled_signals_ratelimited())
- goto send_sig;
+ /* Leave if the signal won't be shown */
+ if (!show_unhandled_signals ||
+ !unhandled_signal(tsk, signo) ||
+ !__ratelimit(&rs))
+ return;
pr_info("%s[%d]: unhandled exception: ", tsk->comm, task_pid_nr(tsk));
if (esr)
@@ -251,9 +246,12 @@ void arm64_force_sig_info(struct siginfo *info, const char
*str)
print_vma_addr(KERN_CONT " in ", regs->pc);
pr_cont("\n");
__show_regs(regs);
+}
-send_sig:
- force_sig_info(info->si_signo, info, tsk);
+void arm64_force_sig_info(struct siginfo *info, const char *str)
+{
+ arm64_show_signal(info->si_signo, str);
+ force_sig_info(info->si_signo, info, current);
}
void arm64_notify_die(const char *str, struct pt_regs *regs,
--
2.17.1
[REVIEW][PATCH 01/15] signal/arm64: Push siginfo generation into arm64_notify_die
Instead of generating a struct siginfo before calling arm64_notify_die
pass the signal number, tne sicode and the fault address into
arm64_notify_die and have it call force_sig_fault instead of
force_sig_info to let the generic code generate the struct siginfo.
This keeps code passing just the needed information into
siginfo generating code, making it easier to see what
is happening and harder to get wrong. Further by letting
the generic code handle the generation of struct siginfo
it reduces the number of sites generating struct siginfo
making it possible to review them and verify that all
of the fiddly details for a structure passed to userspace
are handled properly.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/include/asm/system_misc.h | 3 +-
arch/arm64/kernel/sys_compat.c | 13 -
arch/arm64/kernel/traps.c| 24
arch/arm64/mm/fault.c| 41 +++-
4 files changed, 30 insertions(+), 51 deletions(-)
diff --git a/arch/arm64/include/asm/system_misc.h
b/arch/arm64/include/asm/system_misc.h
index 28893a0b141d..0e2a0ecaf484 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -33,7 +33,8 @@ void die(const char *msg, struct pt_regs *regs, int err);
struct siginfo;
void arm64_notify_die(const char *str, struct pt_regs *regs,
- struct siginfo *info, int err);
+ int signo, int sicode, void __user *addr,
+ int err);
void hook_debug_fault_code(int nr, int (*fn)(unsigned long, unsigned int,
struct pt_regs *),
diff --git a/arch/arm64/kernel/sys_compat.c b/arch/arm64/kernel/sys_compat.c
index a6109825eeb9..32653d156747 100644
--- a/arch/arm64/kernel/sys_compat.c
+++ b/arch/arm64/kernel/sys_compat.c
@@ -68,8 +68,8 @@ do_compat_cache_op(unsigned long start, unsigned long end,
int flags)
*/
long compat_arm_syscall(struct pt_regs *regs)
{
- siginfo_t info;
unsigned int no = regs->regs[7];
+ void __user *addr;
switch (no) {
/*
@@ -112,13 +112,10 @@ long compat_arm_syscall(struct pt_regs *regs)
break;
}
- clear_siginfo(&info);
- info.si_signo = SIGILL;
- info.si_errno = 0;
- info.si_code = ILL_ILLTRP;
- info.si_addr = (void __user *)instruction_pointer(regs) -
-(compat_thumb_mode(regs) ? 2 : 4);
+ addr = (void __user *)instruction_pointer(regs) -
+ (compat_thumb_mode(regs) ? 2 : 4);
- arm64_notify_die("Oops - bad compat syscall(2)", regs, &info, no);
+ arm64_notify_die("Oops - bad compat syscall(2)", regs,
+SIGILL, ILL_ILLTRP, addr, no);
return 0;
}
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 039e9ff379cc..459eb6fb7158 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -257,13 +257,23 @@ void arm64_force_sig_info(struct siginfo *info, const
char *str,
}
void arm64_notify_die(const char *str, struct pt_regs *regs,
- struct siginfo *info, int err)
+ int signo, int sicode, void __user *addr,
+ int err)
{
if (user_mode(regs)) {
+ struct siginfo info;
+
WARN_ON(regs != current_pt_regs());
current->thread.fault_address = 0;
current->thread.fault_code = err;
- arm64_force_sig_info(info, str, current);
+
+ clear_siginfo(&info);
+ info.si_signo = signo;
+ info.si_errno = 0;
+ info.si_code = sicode;
+ info.si_addr = addr;
+
+ arm64_force_sig_info(&info, str, current);
} else {
die(str, regs, err);
}
@@ -348,12 +358,9 @@ static int call_undef_hook(struct pt_regs *regs)
void force_signal_inject(int signal, int code, unsigned long address)
{
- siginfo_t info;
const char *desc;
struct pt_regs *regs = current_pt_regs();
- clear_siginfo(&info);
-
switch (signal) {
case SIGILL:
desc = "undefined instruction";
@@ -372,12 +379,7 @@ void force_signal_inject(int signal, int code, unsigned
long address)
signal = SIGKILL;
}
- info.si_signo = signal;
- info.si_errno = 0;
- info.si_code = code;
- info.si_addr = (void __user *)address;
-
- arm64_notify_die(desc, regs, &info, 0);
+ arm64_notify_die(desc, regs, signal, code, (void __user *)address, 0);
}
/*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 50b30ff30de4..86fe70d8722f 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -625,8 +625,8 @@ static int do_bad(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
static int do_sea(unsigned long addr, unsigned int esr, struct pt_
[REVIEW][PATCH 02/15] signal/arm64: Remove unneeded tsk parameter from arm64_force_sig_info
Every caller passes in current for tsk so there is no need to pass
tsk. Instead make tsk a local variable initialized to current.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/include/asm/traps.h | 3 +--
arch/arm64/kernel/debug-monitors.c | 2 +-
arch/arm64/kernel/ptrace.c | 2 +-
arch/arm64/kernel/traps.c | 8
arch/arm64/mm/fault.c | 2 +-
5 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
index c320f3bf6c57..cd3a2ca9c179 100644
--- a/arch/arm64/include/asm/traps.h
+++ b/arch/arm64/include/asm/traps.h
@@ -37,8 +37,7 @@ void register_undef_hook(struct undef_hook *hook);
void unregister_undef_hook(struct undef_hook *hook);
void force_signal_inject(int signal, int code, unsigned long address);
void arm64_notify_segfault(unsigned long addr);
-void arm64_force_sig_info(struct siginfo *info, const char *str,
- struct task_struct *tsk);
+void arm64_force_sig_info(struct siginfo *info, const char *str);
/*
* Move regs->pc to next instruction and do necessary setup before it
diff --git a/arch/arm64/kernel/debug-monitors.c
b/arch/arm64/kernel/debug-monitors.c
index 06ca574495af..e0d9502be5bf 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -224,7 +224,7 @@ static void send_user_sigtrap(int si_code)
if (interrupts_enabled(regs))
local_irq_enable();
- arm64_force_sig_info(&info, "User debug trap", current);
+ arm64_force_sig_info(&info, "User debug trap");
}
static int single_step_handler(unsigned long addr, unsigned int esr,
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 6219486fa25f..20b68cb31ecb 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -211,7 +211,7 @@ static void ptrace_hbptriggered(struct perf_event *bp,
force_sig_ptrace_errno_trap(si_errno, (void __user
*)bkpt->trigger);
}
#endif
- arm64_force_sig_info(&info, "Hardware breakpoint trap (ptrace)",
current);
+ arm64_force_sig_info(&info, "Hardware breakpoint trap (ptrace)");
}
/*
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 459eb6fb7158..24035d124608 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -231,9 +231,9 @@ static bool show_unhandled_signals_ratelimited(void)
return show_unhandled_signals && __ratelimit(&rs);
}
-void arm64_force_sig_info(struct siginfo *info, const char *str,
- struct task_struct *tsk)
+void arm64_force_sig_info(struct siginfo *info, const char *str)
{
+ struct task_struct *tsk = current;
unsigned int esr = tsk->thread.fault_code;
struct pt_regs *regs = task_pt_regs(tsk);
@@ -273,7 +273,7 @@ void arm64_notify_die(const char *str, struct pt_regs *regs,
info.si_code = sicode;
info.si_addr = addr;
- arm64_force_sig_info(&info, str, current);
+ arm64_force_sig_info(&info, str);
} else {
die(str, regs, err);
}
@@ -630,7 +630,7 @@ asmlinkage void bad_el0_sync(struct pt_regs *regs, int
reason, unsigned int esr)
current->thread.fault_address = 0;
current->thread.fault_code = esr;
- arm64_force_sig_info(&info, "Bad EL0 synchronous exception", current);
+ arm64_force_sig_info(&info, "Bad EL0 synchronous exception");
}
#ifdef CONFIG_VMAP_STACK
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 86fe70d8722f..f42aff0e90ad 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -352,7 +352,7 @@ static void __do_user_fault(struct siginfo *info, unsigned
int esr)
}
current->thread.fault_code = esr;
- arm64_force_sig_info(info, esr_to_fault_info(esr)->name, current);
+ arm64_force_sig_info(info, esr_to_fault_info(esr)->name);
}
static void do_bad_area(unsigned long addr, unsigned int esr, struct pt_regs
*regs)
--
2.17.1
[REVIEW][PATCH 05/15] signal/arm64: Consolidate the two hwpoison cases in do_page_fault
These two cases are practically the same and use siginfo differently
from the other signals sent from do_page_fault. So consolidate them
to make future changes easier.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/mm/fault.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 654a861c4bd0..0ddc8c6ba53b 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -577,16 +577,16 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
*/
si.si_signo = SIGBUS;
si.si_code = BUS_ADRERR;
- } else if (fault & VM_FAULT_HWPOISON_LARGE) {
- unsigned int hindex = VM_FAULT_GET_HINDEX(fault);
+ } else if (fault & (VM_FAULT_HWPOISON_LARGE | VM_FAULT_HWPOISON)) {
+ unsigned int lsb;
+
+ lsb = PAGE_SHIFT;
+ if (fault & VM_FAULT_HWPOISON_LARGE)
+ lsb = hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
si.si_signo = SIGBUS;
si.si_code = BUS_MCEERR_AR;
- si.si_addr_lsb = hstate_index_to_shift(hindex);
- } else if (fault & VM_FAULT_HWPOISON) {
- si.si_signo = SIGBUS;
- si.si_code = BUS_MCEERR_AR;
- si.si_addr_lsb = PAGE_SHIFT;
+ si.si_addr_lsb = lsb;
} else {
/*
* Something tried to access memory that isn't in our memory
--
2.17.1
[PATCH net-next 2/2] net: mvpp2: use round-robin scheduling for TX queues on the same CPU
This commit allows each TXQ to be picked in a round-robin fashion by
the PPv2 transmit scheduling mechanism. This is opposed to the default
behaviour that prioritizes the highest numbered queues.
Suggested-by: Yan Markman
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 1 +
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index f5dceef60b0e..176c6b56fdcc 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -331,6 +331,7 @@
#define MVPP2_TXP_SCHED_ENQ_MASK 0xff
#define MVPP2_TXP_SCHED_DISQ_OFFSET8
#define MVPP2_TXP_SCHED_CMD_1_REG 0x8010
+#define MVPP2_TXP_SCHED_FIXED_PRIO_REG 0x8014
#define MVPP2_TXP_SCHED_PERIOD_REG 0x8018
#define MVPP2_TXP_SCHED_MTU_REG0x801c
#define MVPP2_TXP_MTU_MAX 0x7
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index bdacb9577216..c2ed71788e4f 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1448,6 +1448,9 @@ static void mvpp2_defaults_set(struct mvpp2_port *port)
tx_port_num);
mvpp2_write(port->priv, MVPP2_TXP_SCHED_CMD_1_REG, 0);
+ /* Set TXQ scheduling to Round-Robin */
+ mvpp2_write(port->priv, MVPP2_TXP_SCHED_FIXED_PRIO_REG, 0);
+
/* Close bandwidth for all queues */
for (queue = 0; queue < MVPP2_MAX_TXQ; queue++) {
ptxq = mvpp2_txq_phys(port->id, queue);
--
2.11.0
[REVIEW][PATCH 06/15] signal/arm64: For clarity separate the 3 signal sending cases in do_page_fault
It gets easy to confuse what is going on when some code is shared and some not
so stop sharing the trivial bits of signal generation to make future updates
easier to understand.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/mm/fault.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 0ddc8c6ba53b..14d6ff895139 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -567,16 +567,16 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
return 0;
}
- clear_siginfo(&si);
- si.si_addr = (void __user *)addr;
-
if (fault & VM_FAULT_SIGBUS) {
/*
* We had some memory, but were unable to successfully fix up
* this page fault.
*/
+ clear_siginfo(&si);
si.si_signo = SIGBUS;
si.si_code = BUS_ADRERR;
+ si.si_addr = (void __user *)addr;
+ __do_user_fault(&si, esr);
} else if (fault & (VM_FAULT_HWPOISON_LARGE | VM_FAULT_HWPOISON)) {
unsigned int lsb;
@@ -584,20 +584,25 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
if (fault & VM_FAULT_HWPOISON_LARGE)
lsb = hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
+ clear_siginfo(&si);
si.si_signo = SIGBUS;
si.si_code = BUS_MCEERR_AR;
+ si.si_addr = (void __user *)addr;
si.si_addr_lsb = lsb;
+ __do_user_fault(&si, esr);
} else {
/*
* Something tried to access memory that isn't in our memory
* map.
*/
+ clear_siginfo(&si);
si.si_signo = SIGSEGV;
si.si_code = fault == VM_FAULT_BADACCESS ?
SEGV_ACCERR : SEGV_MAPERR;
+ si.si_addr = (void __user *)addr;
+ __do_user_fault(&si, esr);
}
- __do_user_fault(&si, esr);
return 0;
no_context:
--
2.17.1
[REVIEW][PATCH 10/15] signal/arm64: Add and use arm64_force_sig_fault where appropriate
Wrap force_sig_fault with a helper that calls arm64_show_signal
and call arm64_force_sig_fault where appropraite.
Signed-off-by: Eric W. Biederman
---
arch/arm64/include/asm/traps.h | 1 +
arch/arm64/kernel/debug-monitors.c | 11 +++
arch/arm64/kernel/ptrace.c | 11 +++
arch/arm64/kernel/traps.c | 27 ++-
arch/arm64/mm/fault.c | 26 --
5 files changed, 25 insertions(+), 51 deletions(-)
diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
index cd3a2ca9c179..08e99901edbc 100644
--- a/arch/arm64/include/asm/traps.h
+++ b/arch/arm64/include/asm/traps.h
@@ -37,6 +37,7 @@ void register_undef_hook(struct undef_hook *hook);
void unregister_undef_hook(struct undef_hook *hook);
void force_signal_inject(int signal, int code, unsigned long address);
void arm64_notify_segfault(unsigned long addr);
+void arm64_force_sig_fault(int signo, int code, void __user *addr, const char
*str);
void arm64_force_sig_info(struct siginfo *info, const char *str);
/*
diff --git a/arch/arm64/kernel/debug-monitors.c
b/arch/arm64/kernel/debug-monitors.c
index e0d9502be5bf..d7bb6aefae0a 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -210,13 +210,6 @@ NOKPROBE_SYMBOL(call_step_hook);
static void send_user_sigtrap(int si_code)
{
struct pt_regs *regs = current_pt_regs();
- siginfo_t info;
-
- clear_siginfo(&info);
- info.si_signo = SIGTRAP;
- info.si_errno = 0;
- info.si_code= si_code;
- info.si_addr= (void __user *)instruction_pointer(regs);
if (WARN_ON(!user_mode(regs)))
return;
@@ -224,7 +217,9 @@ static void send_user_sigtrap(int si_code)
if (interrupts_enabled(regs))
local_irq_enable();
- arm64_force_sig_info(&info, "User debug trap");
+ arm64_force_sig_fault(SIGTRAP, si_code,
+(void __user *)instruction_pointer(regs),
+"User debug trap");
}
static int single_step_handler(unsigned long addr, unsigned int esr,
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 20b68cb31ecb..7ab75e78aa08 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -182,13 +182,6 @@ static void ptrace_hbptriggered(struct perf_event *bp,
struct pt_regs *regs)
{
struct arch_hw_breakpoint *bkpt = counter_arch_bp(bp);
- siginfo_t info;
-
- clear_siginfo(&info);
- info.si_signo = SIGTRAP;
- info.si_errno = 0;
- info.si_code= TRAP_HWBKPT;
- info.si_addr= (void __user *)(bkpt->trigger);
#ifdef CONFIG_COMPAT
if (is_compat_task()) {
@@ -211,7 +204,9 @@ static void ptrace_hbptriggered(struct perf_event *bp,
force_sig_ptrace_errno_trap(si_errno, (void __user
*)bkpt->trigger);
}
#endif
- arm64_force_sig_info(&info, "Hardware breakpoint trap (ptrace)");
+ arm64_force_sig_fault(SIGTRAP, TRAP_HWBKPT,
+ (void __user *)(bkpt->trigger),
+ "Hardware breakpoint trap (ptrace)");
}
/*
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index daee8c2ca561..37a3309863e0 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -248,6 +248,13 @@ static void arm64_show_signal(int signo, const char *str)
__show_regs(regs);
}
+void arm64_force_sig_fault(int signo, int code, void __user *addr,
+ const char *str)
+{
+ arm64_show_signal(signo, str);
+ force_sig_fault(signo, code, addr, current);
+}
+
void arm64_force_sig_info(struct siginfo *info, const char *str)
{
arm64_show_signal(info->si_signo, str);
@@ -259,19 +266,11 @@ void arm64_notify_die(const char *str, struct pt_regs
*regs,
int err)
{
if (user_mode(regs)) {
- struct siginfo info;
-
WARN_ON(regs != current_pt_regs());
current->thread.fault_address = 0;
current->thread.fault_code = err;
- clear_siginfo(&info);
- info.si_signo = signo;
- info.si_errno = 0;
- info.si_code = sicode;
- info.si_addr = addr;
-
- arm64_force_sig_info(&info, str);
+ arm64_force_sig_fault(signo, sicode, addr, str);
} else {
die(str, regs, err);
}
@@ -616,19 +615,13 @@ asmlinkage void bad_mode(struct pt_regs *regs, int
reason, unsigned int esr)
*/
asmlinkage void bad_el0_sync(struct pt_regs *regs, int reason, unsigned int
esr)
{
- siginfo_t info;
void __user *pc = (void __user *)instruction_pointer(regs);
- clear_siginfo(&info);
- info.si_signo = SIGILL;
- info.si_errno = 0;
- info.si_code = ILL_ILLOPC;
-
[REVIEW][PATCH 09/15] signal/arm64: Only call set_thread_esr once in do_page_fault
This code is truly common between the signal sending cases so share it.
Signed-off-by: Eric W. Biederman
---
arch/arm64/mm/fault.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index ab85533e2255..959c4a565c8e 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -564,6 +564,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
}
inf = esr_to_fault_info(esr);
+ set_thread_esr(addr, esr);
if (fault & VM_FAULT_SIGBUS) {
/*
* We had some memory, but were unable to successfully fix up
@@ -573,7 +574,6 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
si.si_signo = SIGBUS;
si.si_code = BUS_ADRERR;
si.si_addr = (void __user *)addr;
- set_thread_esr(addr, esr);
arm64_force_sig_info(&si, inf->name);
} else if (fault & (VM_FAULT_HWPOISON_LARGE | VM_FAULT_HWPOISON)) {
unsigned int lsb;
@@ -587,7 +587,6 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
si.si_code = BUS_MCEERR_AR;
si.si_addr = (void __user *)addr;
si.si_addr_lsb = lsb;
- set_thread_esr(addr, esr);
arm64_force_sig_info(&si, inf->name);
} else {
/*
@@ -599,7 +598,6 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
si.si_code = fault == VM_FAULT_BADACCESS ?
SEGV_ACCERR : SEGV_MAPERR;
si.si_addr = (void __user *)addr;
- set_thread_esr(addr, esr);
arm64_force_sig_info(&si, inf->name);
}
--
2.17.1
[REVIEW][PATCH 08/15] signal/arm64: Only perform one esr_to_fault_info call in do_page_fault
As this work is truly common between all of the signal sending cases
there is no need to repeat it between the different cases.
Signed-off-by: Eric W. Biederman
---
arch/arm64/mm/fault.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 7df3d8b561c2..ab85533e2255 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -424,6 +424,7 @@ static bool is_el0_instruction_abort(unsigned int esr)
static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
+ const struct fault_info *inf;
struct task_struct *tsk;
struct mm_struct *mm;
struct siginfo si;
@@ -562,6 +563,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
return 0;
}
+ inf = esr_to_fault_info(esr);
if (fault & VM_FAULT_SIGBUS) {
/*
* We had some memory, but were unable to successfully fix up
@@ -572,7 +574,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
si.si_code = BUS_ADRERR;
si.si_addr = (void __user *)addr;
set_thread_esr(addr, esr);
- arm64_force_sig_info(&si, esr_to_fault_info(esr)->name);
+ arm64_force_sig_info(&si, inf->name);
} else if (fault & (VM_FAULT_HWPOISON_LARGE | VM_FAULT_HWPOISON)) {
unsigned int lsb;
@@ -586,7 +588,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
si.si_addr = (void __user *)addr;
si.si_addr_lsb = lsb;
set_thread_esr(addr, esr);
- arm64_force_sig_info(&si, esr_to_fault_info(esr)->name);
+ arm64_force_sig_info(&si, inf->name);
} else {
/*
* Something tried to access memory that isn't in our memory
@@ -598,7 +600,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
SEGV_ACCERR : SEGV_MAPERR;
si.si_addr = (void __user *)addr;
set_thread_esr(addr, esr);
- arm64_force_sig_info(&si, esr_to_fault_info(esr)->name);
+ arm64_force_sig_info(&si, inf->name);
}
return 0;
--
2.17.1
[REVIEW][PATCH 07/15] signal/arm64: Expand __do_user_fault and remove it
Not all of the signals passed to __do_user_fault can be handled
the same way so expand the now tiny __do_user_fault in it's callers
and remove it.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/mm/fault.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 14d6ff895139..7df3d8b561c2 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -354,12 +354,6 @@ static void set_thread_esr(unsigned long address, unsigned
int esr)
current->thread.fault_code = esr;
}
-static void __do_user_fault(struct siginfo *info, unsigned int esr)
-{
- set_thread_esr((unsigned long)info->si_addr, esr);
- arm64_force_sig_info(info, esr_to_fault_info(esr)->name);
-}
-
static void do_bad_area(unsigned long addr, unsigned int esr, struct pt_regs
*regs)
{
/*
@@ -375,7 +369,8 @@ static void do_bad_area(unsigned long addr, unsigned int
esr, struct pt_regs *re
si.si_code = inf->code;
si.si_addr = (void __user *)addr;
- __do_user_fault(&si, esr);
+ set_thread_esr(addr, esr);
+ arm64_force_sig_info(&si, inf->name);
} else {
__do_kernel_fault(addr, esr, regs);
}
@@ -576,7 +571,8 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
si.si_signo = SIGBUS;
si.si_code = BUS_ADRERR;
si.si_addr = (void __user *)addr;
- __do_user_fault(&si, esr);
+ set_thread_esr(addr, esr);
+ arm64_force_sig_info(&si, esr_to_fault_info(esr)->name);
} else if (fault & (VM_FAULT_HWPOISON_LARGE | VM_FAULT_HWPOISON)) {
unsigned int lsb;
@@ -589,7 +585,8 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
si.si_code = BUS_MCEERR_AR;
si.si_addr = (void __user *)addr;
si.si_addr_lsb = lsb;
- __do_user_fault(&si, esr);
+ set_thread_esr(addr, esr);
+ arm64_force_sig_info(&si, esr_to_fault_info(esr)->name);
} else {
/*
* Something tried to access memory that isn't in our memory
@@ -600,7 +597,8 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
si.si_code = fault == VM_FAULT_BADACCESS ?
SEGV_ACCERR : SEGV_MAPERR;
si.si_addr = (void __user *)addr;
- __do_user_fault(&si, esr);
+ set_thread_esr(addr, esr);
+ arm64_force_sig_info(&si, esr_to_fault_info(esr)->name);
}
return 0;
--
2.17.1
Re: [PATCH] staging: greybus: control.c: fixed some coding style issues
On Thu, Sep 20, 2018 at 10:38:28PM +1000, Aaron Williams wrote: > fixed some "Alignment should match open parenthesis" checks. Note that this is not something that is mandated by the kernel coding style, but rather a preference of the authors of checkpatch (and the check is only enabled when the --strict option is given or when checkpatch is run on net and staging code). As the author and maintainer of this particular code, I do not think this patch should be applied, but Greg may have a different opinion on this as the overall staging maintainer. > Signing up for the kernel clean up crew while I learn C I would strongly suggest learning C *before* moving on to do kernel work. Thanks, Johan
[REVIEW][PATCH 14/15] signal/arm64: Add and use arm64_force_sig_ptrace_errno_trap
Add arm64_force_sig_ptrace_errno_trap for consistency with
arm64_force_sig_fault and use it where appropriate.
This adds the show_signal logic to the force_sig_errno_trap case,
where it was apparently overlooked earlier.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/include/asm/traps.h | 1 +
arch/arm64/kernel/ptrace.c | 4 +++-
arch/arm64/kernel/traps.c | 7 +++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
index d32b8bd440af..f9c1aa6167d2 100644
--- a/arch/arm64/include/asm/traps.h
+++ b/arch/arm64/include/asm/traps.h
@@ -39,6 +39,7 @@ void force_signal_inject(int signal, int code, unsigned long
address);
void arm64_notify_segfault(unsigned long addr);
void arm64_force_sig_fault(int signo, int code, void __user *addr, const char
*str);
void arm64_force_sig_mceerr(int code, void __user *addr, short lsb, const char
*str);
+void arm64_force_sig_ptrace_errno_trap(int errno, void __user *addr, const
char *str);
/*
* Move regs->pc to next instruction and do necessary setup before it
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 921267f59d0d..1710a2d01669 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -202,7 +202,9 @@ static void ptrace_hbptriggered(struct perf_event *bp,
break;
}
}
- force_sig_ptrace_errno_trap(si_errno, (void __user
*)bkpt->trigger);
+ arm64_force_sig_ptrace_errno_trap(si_errno,
+ (void __user *)bkpt->trigger,
+ desc);
}
#endif
arm64_force_sig_fault(SIGTRAP, TRAP_HWBKPT,
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index de67818258cd..856b32aa03d8 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -262,6 +262,13 @@ void arm64_force_sig_mceerr(int code, void __user *addr,
short lsb,
force_sig_mceerr(code, addr, lsb, current);
}
+void arm64_force_sig_ptrace_errno_trap(int errno, void __user *addr,
+ const char *str)
+{
+ arm64_show_signal(SIGTRAP, str);
+ force_sig_ptrace_errno_trap(errno, addr);
+}
+
void arm64_notify_die(const char *str, struct pt_regs *regs,
int signo, int sicode, void __user *addr,
int err)
--
2.17.1
[REVIEW][PATCH 13/15] signal/arm64: In ptrace_hbptriggered name the signal description string
This will let the description be reused shortly.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/kernel/ptrace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 7ab75e78aa08..921267f59d0d 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -182,6 +182,7 @@ static void ptrace_hbptriggered(struct perf_event *bp,
struct pt_regs *regs)
{
struct arch_hw_breakpoint *bkpt = counter_arch_bp(bp);
+ const char *desc = "Hardware breakpoint trap (ptrace)";
#ifdef CONFIG_COMPAT
if (is_compat_task()) {
@@ -206,7 +207,7 @@ static void ptrace_hbptriggered(struct perf_event *bp,
#endif
arm64_force_sig_fault(SIGTRAP, TRAP_HWBKPT,
(void __user *)(bkpt->trigger),
- "Hardware breakpoint trap (ptrace)");
+ desc);
}
/*
--
2.17.1
[REVIEW][PATCH 11/15] signal/arm64: Add and use arm64_force_sig_mceerr as appropriate
Add arm64_force_sig_mceerr for consistency with arm64_force_sig_fault,
and use it in the one location that can take advantage of it.
This removes the fiddly filling out of siginfo before sending a signal
reporting an memory error to userspace.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/include/asm/traps.h | 1 +
arch/arm64/kernel/traps.c | 7 +++
arch/arm64/mm/fault.c | 9 ++---
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
index 08e99901edbc..193f0b0e8ee3 100644
--- a/arch/arm64/include/asm/traps.h
+++ b/arch/arm64/include/asm/traps.h
@@ -38,6 +38,7 @@ void unregister_undef_hook(struct undef_hook *hook);
void force_signal_inject(int signal, int code, unsigned long address);
void arm64_notify_segfault(unsigned long addr);
void arm64_force_sig_fault(int signo, int code, void __user *addr, const char
*str);
+void arm64_force_sig_mceerr(int code, void __user *addr, short lsb, const char
*str);
void arm64_force_sig_info(struct siginfo *info, const char *str);
/*
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 37a3309863e0..baa96dfffeec 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -255,6 +255,13 @@ void arm64_force_sig_fault(int signo, int code, void
__user *addr,
force_sig_fault(signo, code, addr, current);
}
+void arm64_force_sig_mceerr(int code, void __user *addr, short lsb,
+ const char *str)
+{
+ arm64_show_signal(SIGBUS, str);
+ force_sig_mceerr(code, addr, lsb, current);
+}
+
void arm64_force_sig_info(struct siginfo *info, const char *str)
{
arm64_show_signal(info->si_signo, str);
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 66c295019a9a..f0ccb209d181 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -422,7 +422,6 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
const struct fault_info *inf;
struct task_struct *tsk;
struct mm_struct *mm;
- struct siginfo si;
vm_fault_t fault, major = 0;
unsigned long vm_flags = VM_READ | VM_WRITE;
unsigned int mm_flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
@@ -574,12 +573,8 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
if (fault & VM_FAULT_HWPOISON_LARGE)
lsb = hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
- clear_siginfo(&si);
- si.si_signo = SIGBUS;
- si.si_code = BUS_MCEERR_AR;
- si.si_addr = (void __user *)addr;
- si.si_addr_lsb = lsb;
- arm64_force_sig_info(&si, inf->name);
+ arm64_force_sig_mceerr(BUS_MCEERR_AR, (void __user *)addr, lsb,
+ inf->name);
} else {
/*
* Something tried to access memory that isn't in our memory
--
2.17.1
[REVIEW][PATCH 12/15] signal/arm64: Remove arm64_force_sig_info
The function has no more callers so remove it.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/include/asm/traps.h | 1 -
arch/arm64/kernel/traps.c | 6 --
2 files changed, 7 deletions(-)
diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
index 193f0b0e8ee3..d32b8bd440af 100644
--- a/arch/arm64/include/asm/traps.h
+++ b/arch/arm64/include/asm/traps.h
@@ -39,7 +39,6 @@ void force_signal_inject(int signal, int code, unsigned long
address);
void arm64_notify_segfault(unsigned long addr);
void arm64_force_sig_fault(int signo, int code, void __user *addr, const char
*str);
void arm64_force_sig_mceerr(int code, void __user *addr, short lsb, const char
*str);
-void arm64_force_sig_info(struct siginfo *info, const char *str);
/*
* Move regs->pc to next instruction and do necessary setup before it
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index baa96dfffeec..de67818258cd 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -262,12 +262,6 @@ void arm64_force_sig_mceerr(int code, void __user *addr,
short lsb,
force_sig_mceerr(code, addr, lsb, current);
}
-void arm64_force_sig_info(struct siginfo *info, const char *str)
-{
- arm64_show_signal(info->si_signo, str);
- force_sig_info(info->si_signo, info, current);
-}
-
void arm64_notify_die(const char *str, struct pt_regs *regs,
int signo, int sicode, void __user *addr,
int err)
--
2.17.1
[REVIEW][PATCH 15/15] signal/arm64: Use send_sig_fault where appropriate
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/kernel/fpsimd.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 58c53bc96928..5ebe73b69961 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -842,7 +842,6 @@ asmlinkage void do_fpsimd_acc(unsigned int esr, struct
pt_regs *regs)
*/
asmlinkage void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
{
- siginfo_t info;
unsigned int si_code = FPE_FLTUNK;
if (esr & ESR_ELx_FP_EXC_TFV) {
@@ -858,12 +857,9 @@ asmlinkage void do_fpsimd_exc(unsigned int esr, struct
pt_regs *regs)
si_code = FPE_FLTRES;
}
- clear_siginfo(&info);
- info.si_signo = SIGFPE;
- info.si_code = si_code;
- info.si_addr = (void __user *)instruction_pointer(regs);
-
- send_sig_info(SIGFPE, &info, current);
+ send_sig_fault(SIGFPE, si_code,
+ (void __user *)instruction_pointer(regs),
+ current);
}
void fpsimd_thread_switch(struct task_struct *next)
--
2.17.1
[PATCH] objtool: Link with -lz
This should fix the following when statically linking host tools: gcc .../tools/objtool/objtool-in.o -lelf .../tools/objtool/libsubcmd.a -static -o .../tools/objtool/objtool .../bin/ld: .../sys-root/lib/libelf.a(elf_compress.o): in function `__libelf_compress': .../libelf/elf_compress.c:113: undefined reference to `deflateInit_' Signed-off-by: Alexander Sverdlin --- tools/objtool/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile index c9d038f..d1847e3 100644 --- a/tools/objtool/Makefile +++ b/tools/objtool/Makefile @@ -32,7 +32,7 @@ INCLUDES := -I$(srctree)/tools/include \ -I$(srctree)/tools/objtool/arch/$(ARCH)/include WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed CFLAGS += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) -LDFLAGS += -lelf $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS) +LDFLAGS += -lelf -lz $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS) # Allow old libelf to be used: elfshdr := $(shell echo '$(pound)include ' | $(CC) $(CFLAGS) -x c -E - | grep elf_getshdr) -- 2.4.6
Re: [PATCH 0/9] HID: intel ISH: Cleanup patches
On Tue, 11 Sep 2018, Srinivas Pandruvada wrote: > This series is a cleanup series only and help to abstract client API. > > There are no functional changes. > > Even Xu (6): > hid: intel-ish-hid: ishtp: add helper function for driver data get/set > hid: intel-ish-hid: use helper function for private driver data > set/get > hid: intel-ish-hid: ishtp: add helper functions for client buffer > operation > hid: intel-ish-hid: use helper function to access client buffer > hid: intel-ish-hid: ishtp: add helper function for client search > hid: intel-ish-hid: use helper function to search client id > > Hong Liu (2): > HID: intel-ish-hid: use resource-managed api > HID: intel-ish-hid: using list_head for ipc write queue > > Srinivas Pandruvada (1): > HID: intel_ish-hid: Enhance API to get ring buffer sizes Applied to for-4.20/ish. -- Jiri Kosina SUSE Labs
Re: [PATCH v7 4/7] edac: synopsys: Add macro defines for ZynqMP DDRC
On Mon, Sep 17, 2018 at 07:55:02PM +0530, Manish Narani wrote: > Add macro defines for ZynqMP DDR controller. These macros will be used > for ZyqnMP ECC operations. > > Signed-off-by: Manish Narani > --- > drivers/edac/synopsys_edac.c | 168 > +++ > 1 file changed, 168 insertions(+) > > diff --git a/drivers/edac/synopsys_edac.c b/drivers/edac/synopsys_edac.c > index eb458e5..6bf7959 100644 > --- a/drivers/edac/synopsys_edac.c > +++ b/drivers/edac/synopsys_edac.c > @@ -97,6 +97,174 @@ > #define SCRUB_MODE_MASK 0x7 > #define SCRUB_MODE_SECDED0x4 > > +/* DDR ECC Quirks */ > +#define DDR_ECC_INTR_SUPPORT BIT(0) > +#define DDR_ECC_DATA_POISON_SUPPORT BIT(1) All those new additions are one column further to the left than the old ones. Why? Is there some significance here or can they all be vertically aligned? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] hyper-v: Fix wakeup from suspend-to-idle
On Wed, 12 Sep 2018, Vitaly Kuznetsov wrote:
> It makes little sense but still possible to put Hyper-V guests into
> suspend-to-idle state. To wake them up two wakeup sources were registered
> in the past: hyperv-keyboard and hid-hyperv. However, since
> commit eed4d47efe95 ("ACPI / sleep: Ignore spurious SCI wakeups from
> suspend-to-idle") pm_wakeup_event() from these devices is ignored. Switch
> to pm_wakeup_hard_event() API as these devices are actually the only
> possible way to wakeup Hyper-V guests.
>
> Fixes: eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from
> suspend-to-idle)
> Signed-off-by: Vitaly Kuznetsov
> ---
> drivers/hid/hid-hyperv.c | 2 +-
Acked-by: Jiri Kosina
for the above. I guess this'd better go through ACPI tree?
Thanks,
--
Jiri Kosina
SUSE Labs
Re: [PATCH V2] hid: hid-core: Fix a sleep-in-atomic-context bug in __hid_request()
On Thu, 13 Sep 2018, Jia-Ju Bai wrote: > hid_alloc_report_buf() has to be called with GFP_ATOMIC in > __hid_request(), because there are the following callchains > leading to __hid_request() being an atomic context: > > picolcd_send_and_wait (acquire a spinlock) > hid_hw_request > __hid_request > hid_alloc_report_buf(GFP_KERNEL) > > picolcd_reset (acquire a spinlock) > hid_hw_request > __hid_request > hid_alloc_report_buf(GFP_KERNEL) > > lg4ff_play (acquire a spinlock) > hid_hw_request > __hid_request > hid_alloc_report_buf(GFP_KERNEL) > > lg4ff_set_autocenter_ffex (acquire a spinlock) > hid_hw_request > __hid_request > hid_alloc_report_buf(GFP_KERNEL) Hm, so it's always drivers calling out into core in atomic context. So either we take this, and put our bets on being able to allocate the buffer without sleeping, or actually fix the few drivers (it's just lg4ff and picolcd at the end of the day) not to do that, and explicitly anotate __hid_request() with might_sleep(). Hmm? Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] staging: rtl8188eu, rtl8723bs: fix spelling mistake "evet" -> "event"
It's better to just delete these. regards, dan carpenter
Re: [PATCH 04/13] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB mode
On Thu, 2018-09-20 at 18:31 +0100, Robin Murphy wrote:
> On 03/09/18 07:01, Yong Wu wrote:
> > MediaTek extend the arm v7s descriptor to support the dram over 4GB.
> >
> > In the mt2712 and mt8173, it's called "4GB mode", the physical address
> > is from 0x4000_ to 0x1_3fff_, but from EMI point of view, it
> > is remapped to high address from 0x1__ to 0x1__, the
> > bit32 is always enabled. thus, in the M4U, we always enable the bit9
> > for all PTEs which means to enable bit32 of physical address.
> >
> > but in mt8183, M4U support the dram from 0x4000_ to 0x3__
> > which isn't remaped. We extend the PTEs: the bit9 represent bit32 of
> > PA and the bit4 represent bit33 of PA. Meanwhile the iova still is
> > 32bits.
> >
> > In order to unify code, in the "4GB mode", we add the bit32 for the
> > physical address manually in our driver.
> >
> > Correspondingly, Adding bit32 and bit33 for the PA in the iova_to_phys
> > has to been moved into v7s.
> >
> > Signed-off-by: Yong Wu
> > ---
> > In mt8183, the PA is from 0x4000_ to 0x3__ while the iova
> > still is 32bits. Acturally, our HW extend the v7s pgtable. currently
> > the lvl1 pgtable is 16KB, our HW double it. but 32bit iova is enough
> > for us currently, thus we don't change it.
> > ---
> > drivers/iommu/io-pgtable-arm-v7s.c | 38
> > ++
> > drivers/iommu/io-pgtable.h | 8
> > drivers/iommu/mtk_iommu.c | 15 +--
> > drivers/iommu/mtk_iommu.h | 1 +
> > 4 files changed, 44 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
> > b/drivers/iommu/io-pgtable-arm-v7s.c
> > index b5948ba..47538dd 100644
> > --- a/drivers/iommu/io-pgtable-arm-v7s.c
> > +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> > @@ -124,7 +124,9 @@
> > #define ARM_V7S_TEX_MASK 0x7
> > #define ARM_V7S_ATTR_TEX(val) (((val) & ARM_V7S_TEX_MASK) <<
> > ARM_V7S_TEX_SHIFT)
> >
> > -#define ARM_V7S_ATTR_MTK_4GB BIT(9) /* MTK extend it for 4GB
> > mode */
> > +/* MTK extend the two bits below for over 4GB mode */
> > +#define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
> > +#define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
> >
> > /* *well, except for TEX on level 2 large pages, of course :( */
> > #define ARM_V7S_CONT_PAGE_TEX_SHIFT 6
> > @@ -268,7 +270,8 @@ static void __arm_v7s_set_pte(arm_v7s_iopte *ptep,
> > arm_v7s_iopte pte,
> > }
> >
> > static arm_v7s_iopte arm_v7s_prot_to_pte(int prot, int lvl,
> > -struct io_pgtable_cfg *cfg)
> > +struct io_pgtable_cfg *cfg,
> > +phys_addr_t paddr) /* Only for MTK */
>
> I'd rather keep this function dedicated to just generating the
> permissions and attributes. If necessary I'm quite happy to add
> additional helpers for getting/setting the address, much like LPAE now
> has for handling 52-bit IOVAs.
Adding the two additional helpers looks need touch many lines. thus, I
use a new patch for it.
Thanks very much for your review.
>
> > {
> > bool ap = !(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS);
> > arm_v7s_iopte pte = ARM_V7S_ATTR_NG | ARM_V7S_ATTR_S;
> > @@ -295,8 +298,12 @@ static arm_v7s_iopte arm_v7s_prot_to_pte(int prot, int
> > lvl,
> > if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
> > pte |= ARM_V7S_ATTR_NS_SECTION;
> >
> > - if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB)
> > - pte |= ARM_V7S_ATTR_MTK_4GB;
> > + if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
> > + if (paddr & BIT_ULL(32))
> > + pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
> > + if (paddr & BIT_ULL(33))
> > + pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
> > + }
> >
> > return pte;
> > }
> > @@ -392,7 +399,7 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable
> > *data,
> > return -EEXIST;
> > }
> >
> > - pte = arm_v7s_prot_to_pte(prot, lvl, cfg);
> > + pte = arm_v7s_prot_to_pte(prot, lvl, cfg, paddr);
> > if (num_entries > 1)
> > pte = arm_v7s_pte_to_cont(pte, lvl);
> >
> > @@ -484,7 +491,11 @@ static int arm_v7s_map(struct io_pgtable_ops *ops,
> > unsigned long iova,
> > if (!(prot & (IOMMU_READ | IOMMU_WRITE)))
> > return 0;
> >
> > - if (WARN_ON(upper_32_bits(iova) || upper_32_bits(paddr)))
> > + if (WARN_ON(upper_32_bits(iova)))
> > + return -ERANGE;
> > +
> > + if (WARN_ON(upper_32_bits(paddr) &&
> > + !(iop->cfg.quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB)))
>
> TBH I'd just cram the quirk check into the right-hand-side of the ||
> rather than introduce a separate if() - there's already too many
> parentheses to read the whole thing easily ;)
Fix it in v2.
Also, the comments below are fixed.
Thanks.
>
> > return -ER
Re: [PATCH v2] HID: logitech: fix a used uninitialized GCC warning
On Thu, 13 Sep 2018, zhong jiang wrote: > Fix the following compile warning: > > drivers/hid/hid-logitech-hidpp.c: In function 'hi_res_scroll_enable': > drivers/hid/hid-logitech-hidpp.c:2714:54: warning: 'multiplier' may be used > uninitialized in this function [-Wmaybe-uninitialized] > hidpp->vertical_wheel_counter.resolution_multiplier = multiplier; > > Signed-off-by: zhong jiang > --- > v1->v2: > According to Benjamin's suggestion, To initialize the value > and remove the duplicated assignement. Applied to for-4.20/logitech-highres. Thanks, -- Jiri Kosina SUSE Labs
Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
Hi Stephen, On Mon, Sep 24, 2018 at 02:38:53PM +1000, Stephen Rothwell wrote: > diff --cc arch/arm64/Kconfig > index da5e6f085561,f8a618a292f4.. > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@@ -785,7 -786,8 +785,8 @@@ config ARCH_FLATMEM_ENABL > def_bool !NUMA > > config HAVE_ARCH_PFN_VALID > -def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM > +def_bool y > + select HAVE_MEMBLOCK_PFN_VALID It looks fine. Thanks. -- Catalin
Re: [PATCH] HID: intel-ish-hid: Enable Ice Lake mobile
On Tue, 11 Sep 2018, Srinivas Pandruvada wrote:
> Added PCI ID for Ice Lake mobile platform.
>
> Signed-off-by: Srinivas Pandruvada
> ---
> drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
> drivers/hid/intel-ish-hid/ipc/pci-ish.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> index 97869b7410eb..1b4e93e19e6b 100644
> --- a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> +++ b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> @@ -29,6 +29,7 @@
> #define CNL_Ax_DEVICE_ID 0x9DFC
> #define GLK_Ax_DEVICE_ID 0x31A2
> #define CNL_H_DEVICE_ID 0xA37C
> +#define ICL_MOBILE_DEVICE_ID 0x34FC
>
> #define REVISION_ID_CHT_A0 0x6
> #define REVISION_ID_CHT_Ax_SI 0x0
> diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> index 09d085946db3..4d78f85021a5 100644
> --- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> +++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> @@ -38,6 +38,7 @@ static const struct pci_device_id ish_pci_tbl[] = {
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, CNL_Ax_DEVICE_ID)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, GLK_Ax_DEVICE_ID)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, CNL_H_DEVICE_ID)},
> + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, ICL_MOBILE_DEVICE_ID)},
> {0, }
Applied to for-4.19/fixes.
--
Jiri Kosina
SUSE Labs
[PATCH] Revert "uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name"
This changes UAPI, breaking iwd and libell:
ell/key.c: In function 'kernel_dh_compute':
ell/key.c:205:38: error: 'struct keyctl_dh_params' has no member named
'private'; did you mean 'dh_private'?
struct keyctl_dh_params params = { .private = private,
^~~
dh_private
This reverts commit 8a2336e549d385bb0b46880435b411df8d8200e8.
Cc: David Howells
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: Mat Martineau
Cc: Andrew Morton
Cc: Linus Torvalds
Cc:
---
include/uapi/linux/keyctl.h | 2 +-
security/keys/dh.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
index 910cc4334b21..7b8c9e19bad1 100644
--- a/include/uapi/linux/keyctl.h
+++ b/include/uapi/linux/keyctl.h
@@ -65,7 +65,7 @@
/* keyctl structures */
struct keyctl_dh_params {
- __s32 dh_private;
+ __s32 private;
__s32 prime;
__s32 base;
};
diff --git a/security/keys/dh.c b/security/keys/dh.c
index 3b602a1e27fa..711e89d8c415 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -300,7 +300,7 @@ long __keyctl_dh_compute(struct keyctl_dh_params __user
*params,
}
dh_inputs.g_size = dlen;
- dlen = dh_data_from_key(pcopy.dh_private, &dh_inputs.key);
+ dlen = dh_data_from_key(pcopy.private, &dh_inputs.key);
if (dlen < 0) {
ret = dlen;
goto out2;
--
2.19.0
Re: [PATCH 5/6] fsmount: do not use legacy MS_ flags
On Mon, Sep 24, 2018 at 07:50:38AM +0100, David Howells wrote:
> Christian Brauner wrote:
>
> > Ok, understood. What about passing the different attrs as a struct?
> >
> > struct mount_attr {
> > unsigned int attr_cmd,
> > unsigned int attr_values,
> > unsigned int attr_mask,
> >
> > };
> >
> > mount_setattr(int dfd, const char *path, unsigned int atflags,
> > struct mount_attr *attr);
> >
> > I find that to be a little cleaner in all honesty.
> > One could also add a version argument similar to what we currently do
> > for vfs fcaps so that kernel and userspace can easily navigate
> > compabitility when a new member gets added or removed in later releases.
>
> Yeah, we could do that - it's not like I expect mount_setattr() to have to be
> particularly performant in the user interface. I would put the attr_cmd in
> the argument list, probably, so that you can use that to vary the struct in
> future (say we run out of attribute bits).
Yes, that makes sense and mimicks standard ioctl() behavior. So
struct mount_attr {
unsigned int attr_values,
unsigned int attr_mask,
}
mount_setattr(int dfd, const char *path, unsigned int atflags,
unsigned int attr_cmd, struct mount_attr *attr);
I have thought a little more about splitting up the mount flags into
sensible sets. I think the following four sets make sense:
enum {
MOUNT_ATTR_PROPAGATION = 1,
MOUNT_ATTR_SECURITY,
MOUNT_ATTR_SYNC,
MOUNT_ATTR_TIME,
};
MOUNT_ATTR_PROPAGATION:
#define MOUNT_ATTR_PRIVATE(1<<0)
#define MOUNT_ATTR_SHARED (1<<1)
#define MOUNT_ATTR_SLAVE (1<<2)
#define MOUNT_ATTR_UNBINDABLE (1<<3)
MOUNT_ATTR_SECURITY:
#define MOUNT_ATTR_MANDLOCK (1<<0)
#define MOUNT_ATTR_NODEV(1<<1)
#define MOUNT_ATTR_NOEXEC (1<<2)
#define MOUNT_ATTR_NOSUID (1<<3)
#define MOUNT_ATTR_NOREMOTELOCK (1<<4)
#define MOUNT_ATTR_RDONLY (1<<5)
#define MOUNT_ATTR_POSIXACL (1<<6)
#define MOUNT_ATTR_SILENT (1<<7)
MOUNT_ATTR_SYNC
#define MOUNT_ATTR_DIRSYNC (1<<0)
#define MOUNT_ATTR_SYNCHRONOUS (1<<1)
MOUNT_ATTR_TIME:
#define MOUNT_ATTR_LAZYTIME(1<<0)
#define MOUNT_ATTR_NOATIME (1<<1)
#define MOUNT_ATTR_NODIRATIME (1<<2)
#define MOUNT_ATTR_RELATIME(1<<3)
#define MOUNT_ATTR_STRICTATIME (1<<4)
If we ever run out of flags in a specific set I suggest to introduce a
new enum member of the same name with a version number appended and an
alias with a (obvs lower) version number for the old set. A concrete
example would be:
enum {
MOUNT_ATTR_PROPAGATION = 1,
MOUNT_ATTR_SECURITY,
MOUNT_ATTR_SECURITY_1 = MOUNT_ATTR_SECURITY,
MOUNT_ATTR_SYNC,
MOUNT_ATTR_TIME,
MOUNT_ATTR_SECURITY_2,
};
These flags will likely become AT_* flags or be tied to a syscall
afaict.
#define MS_REMOUNT 32
#define MS_BIND 4096
#define MS_MOVE 8192
#define MS_REC 16384
Internal sb flags will not be part of the new mount attr sets. (They
should - imho - not be exposed to userspace at all.):
#define MS_KERNMOUNT(1<<22)
#define MS_SUBMOUNT (1<<26)
#define MS_NOREMOTELOCK (1<<27)
#define MS_NOSEC(1<<28)
#define MS_BORN (1<<29)
#define MS_ACTIVE (1<<30)
#define MS_NOUSER (1<<31)
What remains is an odd duck that probably could be thrown into security
but also *shrug*
#define MS_I_VERSION(1<<23)
Christian
signature.asc
Description: PGP signature
Re: [PATCH v7 7/7] edac: synopsys: Add Error Injection support for ZynqMP DDRC
On Mon, Sep 17, 2018 at 07:55:05PM +0530, Manish Narani wrote:
> Add support for Error Injection for ZynqMP DDRC IP. For injecting
> errors, the Row, Column, Bank, Bank Group and Rank bits positions are
> determined via Address Map registers of Synopsys DDRC.
>
> Signed-off-by: Manish Narani
> ---
> drivers/edac/synopsys_edac.c | 423
> ++-
> 1 file changed, 417 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/edac/synopsys_edac.c b/drivers/edac/synopsys_edac.c
> index 7ab5b9a..177b5c3 100644
> --- a/drivers/edac/synopsys_edac.c
> +++ b/drivers/edac/synopsys_edac.c
> @@ -302,12 +302,18 @@ struct synps_ecc_status {
>
> /**
> * struct synps_edac_priv - DDR memory controller private instance data.
> - * @baseaddr:Base address of the DDR controller.
> - * @message: Buffer for framing the event specific info.
> - * @stat:ECC status information.
> - * @p_data: Platform data
> - * @ce_cnt: Correctable Error count.
> - * @ue_cnt: Uncorrectable Error count.
> + * @baseaddr:Base address of the DDR controller.
> + * @message: Buffer for framing the event specific info.
> + * @stat:ECC status information.
> + * @p_data: Platform data
> + * @ce_cnt: Correctable Error count.
> + * @ue_cnt: Uncorrectable Error count.
> + * @poison_addr: Data poison address.
> + * @row_shift: Bit shifts for row bit.
> + * @col_shift: Bit shifts for column bit.
> + * @bank_shift: Bit shifts for bank bit.
> + * @bankgrp_shift: Bit shifts for bank group bit.
> + * @rank_shift: Bit shifts for rank bit.
> */
> struct synps_edac_priv {
> void __iomem *baseaddr;
> @@ -316,6 +322,14 @@ struct synps_edac_priv {
> const struct synps_platform_data *p_data;
> u32 ce_cnt;
> u32 ue_cnt;
> +#ifdef CONFIG_EDAC_DEBUG
> + ulong poison_addr;
> + u32 row_shift[18];
> + u32 col_shift[14];
> + u32 bank_shift[3];
> + u32 bankgrp_shift[2];
> + u32 rank_shift[1];
> +#endif
> };
>
> /**
> @@ -842,7 +856,12 @@ static const struct synps_platform_data zynqmp_edac_def
> = {
> .get_mtype = zynqmp_get_mtype,
> .get_dtype = zynqmp_get_dtype,
> .get_eccstate = zynqmp_get_eccstate,
> +#ifdef CONFIG_EDAC_DEBUG
> + .quirks = (DDR_ECC_INTR_SUPPORT |
> +DDR_ECC_DATA_POISON_SUPPORT),
> +#else
> .quirks = DDR_ECC_INTR_SUPPORT,
> +#endif
> };
Simplify that:
.quirks = (DDR_ECC_INTR_SUPPORT
#ifdef CONFIG_EDAC_DEBUG
| DDR_ECC_DATA_POISON_SUPPORT
#endif
),
> +/**
> + * setup_address_map - Set Address Map by querying ADDRMAP registers.
> + * @priv:DDR memory controller private instance data.
> + *
> + * Set Address Map by querying ADDRMAP registers.
> + *
> + * Return: none.
> + */
> +static void setup_address_map(struct synps_edac_priv *priv)
> +{
> + u32 addrmap[12];
> + int index;
> +
> + for (index = 0; index < 12; index++) {
> + u32 addrmap_offset;
> +
> + addrmap_offset = ECC_ADDRMAP0_OFFSET + (index * 4);
> + addrmap[index] = readl(priv->baseaddr + addrmap_offset);
> + }
> +
> + /* Set Row Address Map */
> + setup_row_address_map(priv, addrmap);
> +
> + /* Set Column Address Map */
> + setup_column_address_map(priv, addrmap);
> +
> + /* Set Bank Address Map */
> + setup_bank_address_map(priv, addrmap);
> +
> + /* Set Bank Group Address Map */
> + setup_bg_address_map(priv, addrmap);
> +
> + /* Set Rank Address Map */
> + setup_rank_address_map(priv, addrmap);
All those comments which basically repeat the function name look useless
to me.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v5] ARM: mvebu: use dt_fixup to provide fallback for enable-method
On Fri, Sep 21, 2018 at 12:05:48PM +0200, Gregory CLEMENT wrote:
> Hi Chris,
>
> On jeu., juil. 26 2018, Chris Packham
> wrote:
>
> > We need to maintain backwards compatibility with device trees that don't
> > define an enable method. At the same time we want the device tree to be
> > able to specify an enable-method and have it stick.
> >
> > Previously by having smp assigned in the DT_MACHINE definition this
> > would be picked up by setup_arch() and override whatever
> > arm_dt_init_cpu_maps() had configured. Now we move the initial
> > assignment of default smp_ops to a dt_fixup and let
> > arm_dt_init_cpu_maps() override that if the device tree defines an
> > enable-method.
> >
> > Signed-off-by: Chris Packham
>
> I made several tests on an Armada XP based board: OpenBlock AX3: I
> modify the enable-method in the decvice tree, and I confirm that without
> your patch it is not taken into account whereas with this patch the
> enable-method is applied form the device tree. I also didn't see any
> regression with the original dtb.
>
> So I added my:
> Tested-by: Gregory CLEMENT
>
> and applied on mvebu/soc
Hi,
Looks like this broke non-SMP. Not a huge deal, but please apply this as
closely as possible on top of the previous patch (or squash it in).
- 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< -
>From 3190d9502607995c7aecce79beec36714574d494 Mon Sep 17 00:00:00 2001
From: Olof Johansson
Date: Mon, 24 Sep 2018 02:37:31 -0700
Subject: [PATCH] ARM: mvebu: fix !SMP build
Wrap set_smp_ops() in CONFIG_SMP.
Fixes: d6ec59de9a0a8 ("ARM: mvebu: use dt_fixup to provide fallback for
enable-method")
Cc: Chris Packham
Signed-off-by: Olof Johansson
---
arch/arm/mach-mvebu/board-v7.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index 5bbde5e..0b10acd 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -147,7 +147,9 @@ static void __init mvebu_dt_init(void)
static void __init armada_370_xp_dt_fixup(void)
{
+#ifdef CONFIG_SMP
smp_set_ops(smp_ops(armada_xp_smp_ops));
+#endif
}
static const char * const armada_370_xp_dt_compat[] __initconst = {
--
2.8.6
Re: [PATCH 1/3] x86: baytrail/cherrytrail: Rework and move P-Unit PMIC bus semaphore code
On Sun, Sep 23, 2018 at 04:45:08PM +0200, Hans de Goede wrote:
> On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the
> kernel. The P-Unit has a semaphore for the PMIC bus which we can take to
> block it from accessing the shared bus while the kernel wants to access it.
>
> Currently we have the I2C-controller driver acquiring and releasing the
> semaphore around each I2C transfer. There are 2 problems with this:
>
> 1) PMIC accesses often come in the form of a read-modify-write on one of
> the PMIC registers, we currently release the P-Unit's PMIC bus semaphore
> between the read and the write. If the P-Unit modifies the register during
> this window?, then we end up overwriting the P-Unit's changes.
> I believe that this is mostly an academic problem, but I'm not sure.
>
> 2) To safely access the shared I2C bus, we need to do 3 things:
> a) Notify the GPU driver that we are starting a window in which it may not
> access the P-Unit, since the P-Unit seems to ignore the semaphore for
> explicit power-level requests made by the GPU driver
> b) Make a pm_qos request to force all CPU cores out of C6/C7 since entering
> C6/C7 while we hold the semaphore hangs the SoC
> c) Finally take the P-Unit's PMIC bus semaphore
> All 3 these steps together are somewhat expensive, so ideally if we have
> a bunch of i2c transfers grouped together we only do this once for the
> entire group.
>
> Taking the read-modify-write on a PMIC register as example then ideally we
> would only do all 3 steps once at the beginning and undo all 3 steps once
> at the end.
>
> For this we need to be able to take the semaphore from within e.g. the PMIC
> opregion driver, yet we do not want to remove the taking of the semaphore
> from the I2C-controller driver, as that is still necessary to protect many
> other code-paths leading to accessing the shared I2C bus.
>
> This means that we first have the PMIC driver acquire the semaphore and
> then have the I2C controller driver trying to acquire it again.
>
> To make this possible this commit does the following:
>
> 1) Move the semaphore code from being private to the I2C controller driver
> into the generic iosf_mbi code, which already has other code to deal with
> the shared bus so that it can be accessed outside of the I2C bus driver.
>
> 2) Rework the code so that it can be called multiple times nested, while
> still blocking I2C accesses while e.g. the GPU driver has indicated the
> P-Unit needs the bus through a iosf_mbi_punit_acquire() call.
>
> Signed-off-by: Hans de Goede
> ---
> Note this commit deliberately limits the i2c-designware changes to
> only touch i2c-designware-baytrail.c, deliberately not doing some cleanups
> which become possible after removing the semaphore code from the
> i2c-designmware code. This is done so that this commit can be merged
> through the x86 tree without causing conflicts in the i2c tree.
>
> The cleanups to the i2c-designware tree will be done in a follow up
> patch which can be merged once this commit is in place.
> +static void iosf_mbi_reset_semaphore(void)
> +{
> + if (iosf_mbi_modify(BT_MBI_UNIT_PMC, MBI_REG_READ,
> + iosf_mbi_sem_address, 0, PUNIT_SEMAPHORE_BIT))
> + dev_err(&mbi_pdev->dev, "Error punit semaphore reset failed\n");
> +
> + pm_qos_update_request(&iosf_mbi_pm_qos, PM_QOS_DEFAULT_VALUE);
> +
> + blocking_notifier_call_chain(&iosf_mbi_pmic_bus_access_notifier,
> + MBI_PMIC_BUS_ACCESS_END, NULL);
> + mutex_unlock(&iosf_mbi_punit_mutex);
Can we actually move this to the callers?
To me sounds slightly more logical to see lock in *block*() call and unlock in
*unblock*() respectively.
> +}
> +int iosf_mbi_block_punit_i2c_access(void)
> +{
> + unsigned long start, end;
> + int ret = 0;
> + u32 sem;
> +
> + if (WARN_ON(!mbi_pdev || !iosf_mbi_sem_address))
> + return -ENXIO;
> +
> + mutex_lock(&iosf_mbi_block_punit_i2c_access_count_mutex);
> +
> + if (iosf_mbi_block_punit_i2c_access_count > 0)
> + goto out;
> +
> + mutex_lock(&iosf_mbi_punit_mutex);
> + blocking_notifier_call_chain(&iosf_mbi_pmic_bus_access_notifier,
> + MBI_PMIC_BUS_ACCESS_BEGIN, NULL);
> +
> + /*
> + * Disallow the CPU to enter C6 or C7 state, entering these states
> + * requires the punit to talk to the pmic and if this happens while
> + * we're holding the semaphore, the SoC hangs.
> + */
> + pm_qos_update_request(&iosf_mbi_pm_qos, 0);
> +
> + /* host driver writes to side band semaphore register */
> + ret = iosf_mbi_write(BT_MBI_UNIT_PMC, MBI_REG_WRITE,
> + iosf_mbi_sem_address, PUNIT_SEMAPHORE_ACQUIRE);
> + if (ret) {
> + dev_err(&mbi_pdev->dev, "Error punit semaphore request
> failed\n");
> + goto out;
> + }
> +
> + /* host driver waits for bit 0 to be set in semaphore r
Re: [PATCH v2 4/5] staging: vc04_services: Surround complex macros
On Sun, Sep 23, 2018 at 03:06:19PM +0100, Aymen Qader wrote:
> This patch fixes the checkpatch.pl error:
>
> ERROR: Macros with complex values should be enclosed in parentheses
>
> in the interface/vchi directory
>
> Signed-off-by: Aymen Qader
> ---
> drivers/staging/vc04_services/interface/vchi/vchi.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h
> b/drivers/staging/vc04_services/interface/vchi/vchi.h
> index d8e660240a44..f818cf2e27e1 100644
> --- a/drivers/staging/vc04_services/interface/vchi/vchi.h
> +++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
> @@ -92,14 +92,14 @@ typedef struct vchi_msg_vector_ex {
> } VCHI_MSG_VECTOR_EX_T;
>
> // Construct an entry in a msg vector for a pointer (p) of length (l)
> -#define VCHI_VEC_POINTER(p, l) VCHI_VEC_POINTER, { {
> (VCHI_MEM_HANDLE_T)(p), (l) } }
> +#define VCHI_VEC_POINTER(p, l) (VCHI_VEC_POINTER, { {
> (VCHI_MEM_HANDLE_T)(p), (l) } })
>
> // Construct an entry in a msg vector for a message handle (h), starting at
> offset (o) of length (l)
> -#define VCHI_VEC_HANDLE(h, o, l) VCHI_VEC_HANDLE, { { (h), (o), (l) } }
> +#define VCHI_VEC_HANDLE(h, o, l) (VCHI_VEC_HANDLE, { { (h), (o), (l) } })
>
> // Macros to manipulate 'FOURCC' values
> #define MAKE_FOURCC(x) ((int32_t)((x[0] << 24) | (x[1] << 16) | (x[2] << 8)
> | x[3]))
> -#define FOURCC_TO_CHAR(x) (x >> 24) & 0xFF, (x >> 16) & 0xFF, (x >> 8) &
> 0xFF, x & 0xFF
> +#define FOURCC_TO_CHAR(x) ((x >> 24) & 0xFF, (x >> 16) & 0xFF, (x >> 8) &
> 0xFF, x & 0xFF)
>
These are never used so far as I can see, but if they were, then this
would probably break the code. Go through the git log and find out how
they used to work and if they can be removed.
regards,
dan carpenter
Re: [PATCH v2 5/5] staging: vc04_services: Remove spaces after '*'
On Sun, Sep 23, 2018 at 03:06:20PM +0100, Aymen Qader wrote:
> This patch fixes the checkpatch.pl error:
>
> ERROR: "foo * bar" should be "foo* bar"
It should be "foo *bar".
>
> in the interface/vchi directory
>
> Signed-off-by: Aymen Qader
> ---
> drivers/staging/vc04_services/interface/vchi/vchi.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h
> b/drivers/staging/vc04_services/interface/vchi/vchi.h
> index f818cf2e27e1..77bf92018165 100644
> --- a/drivers/staging/vc04_services/interface/vchi/vchi.h
> +++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
> @@ -154,7 +154,7 @@ typedef struct service_info_tag {
> extern "C" {
> #endif
>
> -extern /*@observer@*/ VCHI_CONNECTION_T * vchi_create_connection(const
> VCHI_CONNECTION_API_T * function_table,
^
> +extern /*@observer@*/ VCHI_CONNECTION_T *vchi_create_connection(const
> VCHI_CONNECTION_API_T * function_table,
>const
> VCHI_MESSAGE_DRIVER_T * low_level);
^^^
Change these as well.
regards,
dan carpenter
Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
What about something like the below. I tested it, including the error
case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled
after pci_unmap_iospace(). Actually, I would prefer to use
pci_remap_iospace() and pci_unmap_iospace() but for now this API
doesn't allow overloading the memory type used for the mapping.
Thanks for providing this fix so quickly, Thomas. I can confirm that this
patch -- tested on top of
54eda9df17f3215b9ed16629ee71ea07413efdaf ("Merge
tag 'pci-v4.19-fixes-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci").
Disclaimer: I
have zero familiarity with Linux' PCI code.
Tested-by: Jan Kundrát
Thanks for the testing. I'll wait for Russell to say if he is happy
(or not) with the addition of pci_unmap_io() in the ARM code, if that's
the case, I'll send a proper patch to fix the issue.
Hi Thomas, Russell,
is there a proper patch for this? I've just verified that 4.19-rc5 won't
boot for me either. Thomas' quick patch applies and makes the problem go
away.
With kind regards,
Jan
Re: [PATCH] ARM: dts: exynos: Add CD and WP pins to Odroid XU SD card
Hi Krzysztof,
On 2018-09-21 23:03, Krzysztof Kozlowski wrote:
> Defining card-detect and write-protect GPIO pins in Odroid XU SD Card
> does not change anything from functional point of view - dw-mmc driver
> was reading the state from registers. Adding cd-gpios and wp-gpios
> properties changes only internal driver behavior to access the pins
> directly.
>
> Add them to DTS only to comprehensively describe the hardware. Minor
> benefit is that write-protect pin configuration makes sure that it will
> be properly pulled up to indicate write access.
>
> This also removes debug messages:
> dwmmc_exynos 1222.mmc: No GPIO consumer cd found
> dwmmc_exynos 1222.mmc: No GPIO consumer wp found
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> arch/arm/boot/dts/exynos5410-odroidxu.dts | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts
> b/arch/arm/boot/dts/exynos5410-odroidxu.dts
> index a2046f5f998c..dae360f29a47 100644
> --- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
> +++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
> @@ -525,12 +525,14 @@
>
> &mmc_2 {
> status = "okay";
> + wp-gpios = <&gpm5 0 GPIO_ACTIVE_LOW>;
> + cd-gpios = <&gpc2 2 GPIO_ACTIVE_LOW>;
> card-detect-delay = <200>;
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
> + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4 &sd2_wp>;
IMHO there is no point adding cd-gpios property if CD line is already
assigned to this device via respective pin ctrl entry (as special function).
Handling of WP line is even more controversial imho. Ideally the drivers
or mmc core should check somehow if WP line is available or not and act
respectively. WP line is not available on uSD card connector so there is
no point describing it.
> bus-width = <4>;
> cap-sd-highspeed;
> vmmc-supply = <&ldo21_reg>;
> @@ -573,6 +575,14 @@
> samsung,pin-pud = ;
> samsung,pin-drv = ;
> };
> +
> + sd2_wp: sd2-wp {
> + samsung,pins = "gpm5-0";
> + samsung,pin-function = ;
> + /* Pin is floating so pull it up to disable write-protect */
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
> + };
> };
>
> &pwm {
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v5] ARM: mvebu: use dt_fixup to provide fallback for enable-method
On 24/09/18 21:54, Olof Johansson wrote:
> On Fri, Sep 21, 2018 at 12:05:48PM +0200, Gregory CLEMENT wrote:
>> Hi Chris,
>>
>> On jeu., juil. 26 2018, Chris Packham
>> wrote:
>>
>>> We need to maintain backwards compatibility with device trees that don't
>>> define an enable method. At the same time we want the device tree to be
>>> able to specify an enable-method and have it stick.
>>>
>>> Previously by having smp assigned in the DT_MACHINE definition this
>>> would be picked up by setup_arch() and override whatever
>>> arm_dt_init_cpu_maps() had configured. Now we move the initial
>>> assignment of default smp_ops to a dt_fixup and let
>>> arm_dt_init_cpu_maps() override that if the device tree defines an
>>> enable-method.
>>>
>>> Signed-off-by: Chris Packham
>>
>> I made several tests on an Armada XP based board: OpenBlock AX3: I
>> modify the enable-method in the decvice tree, and I confirm that without
>> your patch it is not taken into account whereas with this patch the
>> enable-method is applied form the device tree. I also didn't see any
>> regression with the original dtb.
>>
>> So I added my:
>> Tested-by: Gregory CLEMENT
>>
>> and applied on mvebu/soc
>
> Hi,
>
> Looks like this broke non-SMP. Not a huge deal, but please apply this as
> closely as possible on top of the previous patch (or squash it in).
>
>
> - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< - 8< -
>
>
>
> From 3190d9502607995c7aecce79beec36714574d494 Mon Sep 17 00:00:00 2001
> From: Olof Johansson
> Date: Mon, 24 Sep 2018 02:37:31 -0700
> Subject: [PATCH] ARM: mvebu: fix !SMP build
>
> Wrap set_smp_ops() in CONFIG_SMP.
>
> Fixes: d6ec59de9a0a8 ("ARM: mvebu: use dt_fixup to provide fallback for
> enable-method")
> Cc: Chris Packham
> Signed-off-by: Olof Johansson
> ---
> arch/arm/mach-mvebu/board-v7.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
> index 5bbde5e..0b10acd 100644
> --- a/arch/arm/mach-mvebu/board-v7.c
> +++ b/arch/arm/mach-mvebu/board-v7.c
> @@ -147,7 +147,9 @@ static void __init mvebu_dt_init(void)
>
> static void __init armada_370_xp_dt_fixup(void)
> {
> +#ifdef CONFIG_SMP
> smp_set_ops(smp_ops(armada_xp_smp_ops));
> +#endif
> }
>
> static const char * const armada_370_xp_dt_compat[] __initconst = {
>
Makes sense to me.
Gregory, do you want me to send a v6 or are you able to squash this in?
RE: [PATCH v7 2/7] edac: synps: Add platform specific structures for ddrc controller
Hi Boris, Thanks for the review. > -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Friday, September 21, 2018 2:37 PM > To: Manish Narani > Cc: robh...@kernel.org; mark.rutl...@arm.com; mche...@kernel.org; > Michal Simek ; leoyang...@nxp.com; > sudeep.ho...@arm.com; amit.kuche...@linaro.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > e...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v7 2/7] edac: synps: Add platform specific structures for > ddrc controller > > On Wed, Sep 19, 2018 at 01:33:58PM +, Manish Narani wrote: > > Apart from this one, I have covered all the comments from the previous > review. > > Are you sure? > > Let's see. I said: > > | Kill all that "function pointer" fluff. Here's how I've changed it: > | > | /** > | * struct synps_platform_data - synps platform data structure > | * @edac_geterror_info: edac error info > | * @edac_get_mtype: get mtype > | * @edac_get_dtype: get dtype > | * @edac_get_eccstate: get ECC state > ^ > > This is supposed to denote that this function returns whether ECC checking is > enabled on the controller or not. > > Your patch has: > > + * struct synps_platform_data - synps platform data structure. > + * @geterror_info: Get error info. > + * @get_mtype: Get mtype. > + * @get_dtype: Get dtype. > + * @get_eccstate: Get eccstate. > > So what is "eccstate"? Is it a struct or a variable or ...? > > Do you see my point? > > I know, it is a small thing but documenting our code properly is something > which people would be thanking us for. Even you will be thanking yourself when > you look at this months from now after having forgotten it all. > > Please check the rest of your additions for similar discrepancies. Okay sure. Will be rectified in v8. Thanks, Manish
Re: [PATCH v2 0/5] staging: vc04_services: Fix checkpatch.pl errors
On Sun, Sep 23, 2018 at 03:06:15PM +0100, Aymen Qader wrote: > v2: Added cover letter correctly > We weren't super stressed that the cover letter threading was wrong. We're not ogres. Anyway, just fixup the last two and resend a v3. regards, dan carpenter
Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
Hello, On Mon, 24 Sep 2018 12:02:33 +0200, Jan Kundrát wrote: > is there a proper patch for this? I've just verified that 4.19-rc5 won't > boot for me either. Thomas' quick patch applies and makes the problem go > away. I was waiting for a quick review from Russell on my proposal, but since it didn't happen so far, I will send a proper patch series, hopefully today. Thanks for your reminder! Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v10 00/26] guest dedicated crypto adapters
FWIW, assuming that review comments for v10 will be addresses in v11, I plan to add the upcoming v11 to a topic branch and will merge that after 2 or 3 days after v11 in kvms390/next. In the future the vfio-ap driver will likely be handled by Martins s390 tree, so I guess it makes sense for him to merge the upcoming topic branch as well. I will coordinate with Martin. Christian On 09/12/2018 09:42 PM, Tony Krowiak wrote: > From: Tony Krowiak > > Notes: > = > > Patches 1-2 (by David) are posted with this series because they are not > currently available in our master branch, upon which this series is based, > and because this series is dependent upon them. > > This patch series works with the v8 QEMU patches. > > Abstract: > > > On s390, we have cryptographic coprocessor cards, which are modeled on > Linux as devices on the AP bus. Each card can be partitioned into domains > which can be thought of as a set of hardware registers for processing > crypto commands. Crypto commands are sent to a specific domain within a > card is via a queue which is identified as a (card,domain) tuple. We model > this something like the following (assuming we have access to cards 3 and > 4 and domains 1 and 2): > > AP -> card3 -> queue (3,1) > -> queue (3,2) >-> card4 -> queue (4,1) > -> queue (4,2) > > If we want to virtualize this, we can use a feature provided by the > hardware. We basically attach a satellite control block to our main > hardware virtualization control block and the hardware takes care of > most of the rest. > > For this control block, we don't specify explicit tuples, but a list of > cards and a list of domains. The guest will get access to the cross > product. > > Because of this, we need to take care that the lists provided to > different guests don't overlap; i.e., we need to enforce sane > configurations. Otherwise, one guest may get access to things like > secret keys for another guest. > > The idea of this patch set is to introduce a new device, the matrix > device. This matrix device hangs off a different root and acts as the > parent node for mdev devices. > > If you now want to give the tuples (4,1) and (4,2), you need to do the > following: > > - Make sure the queues (4,1) and (4,2) belong to vfio_ap (see patches > #5 and #6) > - Create the mediated device. > - Assign card 4 and domains 1 and 2 to the mediated device > - Optionally activate the mediated device. > > QEMU will now simply consume the mediated device and things should work. > > For a complete description of the architecture and concepts underlying > the design, see the Documentation/s390/vfio-ap.txt file included with this > patch set. > > v9 => v10 Change log: > === > * Replaced statically allocated with dynamically allocated matrix device > * Made changes to drivers/iommu/Kconfig and arch/s390/Kconfig to fix the > dependency chain so that make menuconfig can be used to configure VFIO_AP > * Added KVM device attributes to enable/disable hw interpretation of AP > instructions from userspace. > * Return more meaningful error values from mediated matrix device > assignment sysfs interfaces > * No longer enforcing convention that the ADM is a superset of the AQM at > for guest level 2 > * Broke 2 vSIE patches into several to make it easier to review them > * Reworked vSIE patches to handle various CRYCB formats > v8 => v9 Change log: > === > * Removed /sys/devices/virtual/misc/vfio_ap device and restored > /sys/devices/vfio_ap/matrix device as parent of mediated matrix devices > * Return boolean from ap_configuration_available() in ap.h instead of 0 or > an error. > * Miscellaneous changes due to review comments > > v7 => v8 Change log: > === > * Removed the AP bus gained the ability to designate queues as 'used by > host' or as 'used by alternate driver(s)'. > * Removed 'activate' attribute from mediated device. > * Do consistency checking during device assignment: > 1. Verify that APQNs assigned to the mediated device are bound to the > VFIO AP device driver > 2. Verify that no APQN assigned to the mediated matrix device is assigned > to any other mediated matrix device. > * The attributes of a mediated matrix device that is in use by a guest can > not be changed - i.e., no device assignment/unassignment allowed > * A mediated matrix device that is in use by a guest can not be removed. > * Removed all printk logging from VFIO AP driver; allowing return codes > from interfaces to describe the error. > * Reworked the handling of the CRYCB in vSIE based upon patches introduced > by David in the mainline. > > v6 => v7 Change log: > === > * The AP bus gained the ability to designate queues as 'used by host' > or as 'used by alternate driver(s)'. This allows us to authorise access > (via the CRYCB) to queues that are not currently bound to the vfio_ap > driver. If
[PATCH v3 0/4] devres: provide and use devm_kstrdup_const()
This series implements devm_kstrdup_const() together with some prerequisite changes and uses it in pmc-atom driver. v1 -> v2: - fixed the changelog in the patch implementing devm_kstrdup_const() - fixed the kernel doc - moved is_kernel_rodata() to asm-generic/sections.h - fixed constness v2 -> v3: - rebased on top of 4.19-rc5 as there were some conflicts in the pmc-atom driver - collected Reviewed-by tags Bartosz Golaszewski (4): devres: constify p in devm_kfree() mm: move is_kernel_rodata() to asm-generic/sections.h devres: provide devm_kstrdup_const() clk: pmc-atom: use devm_kstrdup_const() drivers/base/devres.c | 43 -- drivers/clk/x86/clk-pmc-atom.c | 19 --- include/asm-generic/sections.h | 14 +++ include/linux/device.h | 5 +++- mm/util.c | 7 -- 5 files changed, 63 insertions(+), 25 deletions(-) -- 2.18.0
[PATCH v3 1/4] devres: constify p in devm_kfree()
Make devm_kfree() signature uniform with that of kfree(). To avoid
compiler warnings: cast p to (void *) when calling devres_destroy().
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Bjorn Andersson
---
drivers/base/devres.c | 5 +++--
include/linux/device.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index f98a097e73f2..438c91a43508 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -885,11 +885,12 @@ EXPORT_SYMBOL_GPL(devm_kasprintf);
*
* Free memory allocated with devm_kmalloc().
*/
-void devm_kfree(struct device *dev, void *p)
+void devm_kfree(struct device *dev, const void *p)
{
int rc;
- rc = devres_destroy(dev, devm_kmalloc_release, devm_kmalloc_match, p);
+ rc = devres_destroy(dev, devm_kmalloc_release,
+ devm_kmalloc_match, (void *)p);
WARN_ON(rc);
}
EXPORT_SYMBOL_GPL(devm_kfree);
diff --git a/include/linux/device.h b/include/linux/device.h
index 8f882549edee..33f7cb271fbb 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -692,7 +692,7 @@ static inline void *devm_kcalloc(struct device *dev,
{
return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
}
-extern void devm_kfree(struct device *dev, void *p);
+extern void devm_kfree(struct device *dev, const void *p);
extern char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp)
__malloc;
extern void *devm_kmemdup(struct device *dev, const void *src, size_t len,
gfp_t gfp);
--
2.18.0
[PATCH v3 2/4] mm: move is_kernel_rodata() to asm-generic/sections.h
Export this routine so that we can use it later in devm_kstrdup_const()
and devm_kfree_const().
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Bjorn Andersson
---
include/asm-generic/sections.h | 14 ++
mm/util.c | 7 ---
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 849cd8eb5ca0..d79abca81a52 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -141,4 +141,18 @@ static inline bool init_section_intersects(void *virt,
size_t size)
return memory_intersects(__init_begin, __init_end, virt, size);
}
+/**
+ * is_kernel_rodata - checks if the pointer address is located in the
+ *.rodata section
+ *
+ * @addr: address to check
+ *
+ * Returns: true if the address is located in .rodata, false otherwise.
+ */
+static inline bool is_kernel_rodata(unsigned long addr)
+{
+ return addr >= (unsigned long)__start_rodata &&
+ addr < (unsigned long)__end_rodata;
+}
+
#endif /* _ASM_GENERIC_SECTIONS_H_ */
diff --git a/mm/util.c b/mm/util.c
index 9e3ebd2ef65f..470f5cd80b64 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -15,17 +15,10 @@
#include
#include
-#include
#include
#include "internal.h"
-static inline int is_kernel_rodata(unsigned long addr)
-{
- return addr >= (unsigned long)__start_rodata &&
- addr < (unsigned long)__end_rodata;
-}
-
/**
* kfree_const - conditionally free memory
* @x: pointer to the memory
--
2.18.0
[PATCH v3 3/4] devres: provide devm_kstrdup_const()
Provide a resource managed version of kstrdup_const(). This variant
internally calls devm_kstrdup() on pointers that are outside of
.rodata section and returns the string as is otherwise.
Also provide a corresponding version of devm_kfree().
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Bjorn Andersson
---
drivers/base/devres.c | 38 ++
include/linux/device.h | 3 +++
2 files changed, 41 insertions(+)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 438c91a43508..48185d57bc5b 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -11,6 +11,8 @@
#include
#include
+#include
+
#include "base.h"
struct devres_node {
@@ -822,6 +824,28 @@ char *devm_kstrdup(struct device *dev, const char *s,
gfp_t gfp)
}
EXPORT_SYMBOL_GPL(devm_kstrdup);
+/**
+ * devm_kstrdup_const - resource managed conditional string duplication
+ * @dev: device for which to duplicate the string
+ * @s: the string to duplicate
+ * @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ *
+ * Strings allocated by devm_kstrdup_const will be automatically freed when
+ * the associated device is detached.
+ *
+ * RETURNS:
+ * Source string if it is in .rodata section otherwise it falls back to
+ * devm_kstrdup.
+ */
+const char *devm_kstrdup_const(struct device *dev, const char *s, gfp_t gfp)
+{
+ if (is_kernel_rodata((unsigned long)s))
+ return s;
+
+ return devm_kstrdup(dev, s, gfp);
+}
+EXPORT_SYMBOL(devm_kstrdup_const);
+
/**
* devm_kvasprintf - Allocate resource managed space and format a string
* into that.
@@ -895,6 +919,20 @@ void devm_kfree(struct device *dev, const void *p)
}
EXPORT_SYMBOL_GPL(devm_kfree);
+/**
+ * devm_kfree_const - Resource managed conditional kfree
+ * @dev: device this memory belongs to
+ * @p: memory to free
+ *
+ * Function calls devm_kfree only if @p is not in .rodata section.
+ */
+void devm_kfree_const(struct device *dev, const void *p)
+{
+ if (!is_kernel_rodata((unsigned long)p))
+ devm_kfree(dev, p);
+}
+EXPORT_SYMBOL(devm_kfree_const);
+
/**
* devm_kmemdup - Resource-managed kmemdup
* @dev: Device this memory belongs to
diff --git a/include/linux/device.h b/include/linux/device.h
index 33f7cb271fbb..79ccc6eb0975 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -693,7 +693,10 @@ static inline void *devm_kcalloc(struct device *dev,
return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
}
extern void devm_kfree(struct device *dev, const void *p);
+extern void devm_kfree_const(struct device *dev, const void *p);
extern char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp)
__malloc;
+extern const char *devm_kstrdup_const(struct device *dev,
+ const char *s, gfp_t gfp);
extern void *devm_kmemdup(struct device *dev, const void *src, size_t len,
gfp_t gfp);
--
2.18.0
[PATCH v3 4/4] clk: pmc-atom: use devm_kstrdup_const()
Use devm_kstrdup_const() in the pmc-atom driver. This mostly serves as
an example of how to use this new routine to shrink driver code.
While we're at it: replace a call to kcalloc() with devm_kcalloc().
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Stephen Boyd
Reviewed-by: Bjorn Andersson
---
drivers/clk/x86/clk-pmc-atom.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/x86/clk-pmc-atom.c b/drivers/clk/x86/clk-pmc-atom.c
index d977193842df..239197799ea3 100644
--- a/drivers/clk/x86/clk-pmc-atom.c
+++ b/drivers/clk/x86/clk-pmc-atom.c
@@ -247,14 +247,6 @@ static void plt_clk_unregister_fixed_rate_loop(struct
clk_plt_data *data,
plt_clk_unregister_fixed_rate(data->parents[i]);
}
-static void plt_clk_free_parent_names_loop(const char **parent_names,
- unsigned int i)
-{
- while (i--)
- kfree_const(parent_names[i]);
- kfree(parent_names);
-}
-
static void plt_clk_unregister_loop(struct clk_plt_data *data,
unsigned int i)
{
@@ -280,8 +272,8 @@ static const char **plt_clk_register_parents(struct
platform_device *pdev,
if (!data->parents)
return ERR_PTR(-ENOMEM);
- parent_names = kcalloc(nparents, sizeof(*parent_names),
- GFP_KERNEL);
+ parent_names = devm_kcalloc(&pdev->dev, nparents,
+ sizeof(*parent_names), GFP_KERNEL);
if (!parent_names)
return ERR_PTR(-ENOMEM);
@@ -294,7 +286,8 @@ static const char **plt_clk_register_parents(struct
platform_device *pdev,
err = PTR_ERR(data->parents[i]);
goto err_unreg;
}
- parent_names[i] = kstrdup_const(clks[i].name, GFP_KERNEL);
+ parent_names[i] = devm_kstrdup_const(&pdev->dev,
+clks[i].name, GFP_KERNEL);
}
data->nparents = nparents;
@@ -302,7 +295,6 @@ static const char **plt_clk_register_parents(struct
platform_device *pdev,
err_unreg:
plt_clk_unregister_fixed_rate_loop(data, i);
- plt_clk_free_parent_names_loop(parent_names, i);
return ERR_PTR(err);
}
@@ -352,8 +344,6 @@ static int plt_clk_probe(struct platform_device *pdev)
goto err_drop_mclk;
}
- plt_clk_free_parent_names_loop(parent_names, data->nparents);
-
platform_set_drvdata(pdev, data);
return 0;
@@ -362,7 +352,6 @@ static int plt_clk_probe(struct platform_device *pdev)
err_unreg_clk_plt:
plt_clk_unregister_loop(data, i);
plt_clk_unregister_parents(data);
- plt_clk_free_parent_names_loop(parent_names, data->nparents);
return err;
}
--
2.18.0
Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
On Thu, Sep 13, 2018 at 10:42:41AM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote:
> > On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
> > > What about something like the below. I tested it, including the error
> > > case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled
> > > after pci_unmap_iospace(). Actually, I would prefer to use
> > > pci_remap_iospace() and pci_unmap_iospace() but for now this API
> > > doesn't allow overloading the memory type used for the mapping.
> >
> > Thanks for providing this fix so quickly, Thomas. I can confirm that this
> > patch -- tested on top of 54eda9df17f3215b9ed16629ee71ea07413efdaf ("Merge
> > tag 'pci-v4.19-fixes-1' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci"). Disclaimer: I
> > have zero familiarity with Linux' PCI code.
> >
> > Tested-by: Jan Kundrát
>
> Thanks for the testing. I'll wait for Russell to say if he is happy
> (or not) with the addition of pci_unmap_io() in the ARM code, if that's
> the case, I'll send a proper patch to fix the issue.
I'd prefer not to provide an unmapping API, because it gives the
impression that it's okay to unmap the IO space mapping, and we'll
end up with drivers that decide to call it in their cleanup path.
IO space isn't expected to ever go away - eg, on a PC, it's always
present.
I've been toying with the idea of making pci_map_io() ignore
subsequent attempts to overwrite the mapping with an identical
mapping, and WARN() if there is an attempt to overwrite an existing
mapping with other physical address, but I'm not entirely happy
with that either (which is why I haven't responded sooner.)
At the moment, I don't have a way forward that I'm happy with for
this.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
RE: [RFC PATCH v2 2/2] phy: cadence: Add driver for Sierra PHY
Hi, On 20 September 2018 11:10, Kishon Vijay Abraham I wrote: > Hi, > > On Thursday 06 September 2018 08:12 PM, Alan Douglas wrote: > > Add a Sierra PHY driver with PCIe and USB support. > > > > The PHY has multiple lanes, which can be configured into > > groups, and a generic PHY device is created for each group. > > > > There are two resets controlling the overall PHY block, one > > to enable the APB interface for programming registers, and > > another to enable the PHY itself. Additionally there are > > resets for each PHY lane. > > > > The PHY can be configured in hardware to read register > > settings from ROM, or they can be written by the driver. > > > > The sequence of operation on startup is to enable the APB > > bus, write the PHY registers (if required) for each lane > > group, and then enable the PHY. Each group of lanes > > can then be individually controlled using the power_on()/ > > power_off() function for that generic PHY > > > > Signed-off-by: Alan Douglas > > --- > > drivers/phy/Kconfig | 1 + > > drivers/phy/Makefile | 1 + > > drivers/phy/cadence/Kconfig | 9 + > > drivers/phy/cadence/Makefile | 2 + > > drivers/phy/cadence/cdns-sierra.c | 385 > > ++ > > 5 files changed, 398 insertions(+) > > create mode 100644 drivers/phy/cadence/Kconfig > > create mode 100644 drivers/phy/cadence/Makefile > > create mode 100644 drivers/phy/cadence/cdns-sierra.c > > > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > > index 5c8d452..cc47f85 100644 > > --- a/drivers/phy/Kconfig > > +++ b/drivers/phy/Kconfig > > @@ -43,6 +43,7 @@ config PHY_XGENE > > source "drivers/phy/allwinner/Kconfig" > > source "drivers/phy/amlogic/Kconfig" > > source "drivers/phy/broadcom/Kconfig" > > +source "drivers/phy/cadence/Kconfig" > > source "drivers/phy/hisilicon/Kconfig" > > source "drivers/phy/lantiq/Kconfig" > > source "drivers/phy/marvell/Kconfig" > > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile > > index 84e3bd9..ba48acd 100644 > > --- a/drivers/phy/Makefile > > +++ b/drivers/phy/Makefile > > @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_RENESAS)+= renesas/ > > obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/ > > obj-$(CONFIG_ARCH_TEGRA) += tegra/ > > obj-y += broadcom/\ > > + cadence/ \ > >hisilicon/ \ > >marvell/ \ > >motorola/\ > > diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig > > new file mode 100644 > > index 000..098df0f > > --- /dev/null > > +++ b/drivers/phy/cadence/Kconfig > > @@ -0,0 +1,9 @@ > > +# > > +# Phy drivers for Cadence PHYs > > +# > > +config CDNS_SIERRA_PHY > > + tristate "Cadence Sierra PHY Driver" > > + depends on OF && HAS_IOMEM && RESET_CONTROLLER > > + select GENERIC_PHY > > + help > > + Enable this to support the Cadence Sierra PHY driver > > diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile > > new file mode 100644 > > index 000..c396c69 > > --- /dev/null > > +++ b/drivers/phy/cadence/Makefile > > @@ -0,0 +1,2 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +obj-$(CONFIG_CDNS_SIERRA_PHY) += cdns-sierra.o > > diff --git a/drivers/phy/cadence/cdns-sierra.c > > b/drivers/phy/cadence/cdns-sierra.c > > new file mode 100644 > > index 000..83568b4 > > --- /dev/null > > +++ b/drivers/phy/cadence/cdns-sierra.c > > @@ -0,0 +1,385 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Cadence Sierra PHY Driver > > + * > > + * Copyright (c) 2018 Cadence Design Systems > > + * Author: Alan Douglas > > + * > > + */ > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +/* PHY register offsets */ > > +#define SIERRA_PHY_PLL_CFG (0xc00e << 2) > > +#define SIERRA_DET_STANDEC_A (0x4000 << 2) > > +#define SIERRA_DET_STANDEC_B (0x4001 << 2) > > +#define SIERRA_DET_STANDEC_C (0x4002 << 2) > > +#define SIERRA_DET_STANDEC_D (0x4003 << 2) > > +#define SIERRA_DET_STANDEC_E (0x4004 << 2) > > +#define SIERRA_PSM_LANECAL (0x4008 << 2) > > +#define SIERRA_PSM_DIAG(0x4015 << 2) > > +#define SIERRA_PSC_TX_A0 (0x4028 << 2) > > +#define SIERRA_PSC_TX_A1 (0x4029 << 2) > > +#define SIERRA_PSC_TX_A2 (0x402A << 2) > > +#define SIERRA_PSC_TX_A3 (0x402B << 2) > > +#define SIERRA_PSC_RX_A0 (0x4030 << 2) > > +#define SIERRA_PSC_RX_A1 (0x4031 << 2) > > +#define SIERRA_PSC_RX_A2 (0x4032 << 2) > > +#define SIERRA_PSC_RX_A3 (0x4033 << 2) > > +#def
RE: [PATCH v7 2/7] edac: synps: Add platform specific structures for ddrc controller
Hi Boris, Thanks for the review. > -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Friday, September 21, 2018 2:46 PM > To: Manish Narani > Cc: robh...@kernel.org; mark.rutl...@arm.com; mche...@kernel.org; > Michal Simek ; leoyang...@nxp.com; > sudeep.ho...@arm.com; amit.kuche...@linaro.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > e...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v7 2/7] edac: synps: Add platform specific structures for > ddrc controller > > There's more: > > I said: > > > > @@ -370,12 +398,12 @@ static int synps_edac_init_csrows(struct > > > mem_ctl_info *mci) > > > That function returns 0 unconditionally. Make it a void in a prepatch. > > But you've lumped this change together with a bunch more. Maybe my request > wasn't clear so let me rephrase it: > > That function returns 0 unconditionally. Make it a void in a *separate* > prepatch. > > Ok? Yes, okay. 😊 I will keep it in a separate prepatch in v8. Thanks, Manish
RE: [PATCH v7 5/7] edac: synopsys: Add EDAC ECC support for ZynqMP DDRC
Hi Boris,
Thanks for the review.
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Friday, September 21, 2018 6:26 PM
> On Mon, Sep 17, 2018 at 07:55:03PM +0530, Manish Narani wrote:
> > Add EDAC ECC support for ZynqMP DDRC IP. The IP supports interrupts
> > for corrected and uncorrected errors. Add interrupt handlers for the same.
> >
> > Signed-off-by: Manish Narani
> > ---
> > drivers/edac/Kconfig | 2 +-
> > drivers/edac/synopsys_edac.c | 304
> > ---
> > 2 files changed, 287 insertions(+), 19 deletions(-)
>
> ...
> > + if (priv->p_data->quirks & DDR_ECC_INTR_SUPPORT) {
>
> This whole chunk together with the if, looks like it could be a separate
> function
> called maybe request_irq() or so.
May be I can keep it like edac_setup_irq() ?
>
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0) {
> > + edac_printk(KERN_ERR, EDAC_MC,
> > + "No irq %d in DT\n", irq);
>
> Align arguments on opening brace.
Okay
>
> Then, here it is "irq"...
>
> > + rc = irq;
> > + goto free_edac_mc;
> > + }
> > +
> > + rc = devm_request_irq(&pdev->dev, irq,
> > + synps_edac_intr_handler,
> > + 0, dev_name(&pdev->dev), mci);
>
> Also align on opening brace.
>
> > + if (rc < 0) {
> > + edac_printk(KERN_ERR, EDAC_MC, "Failed to request
> Irq\n");
>
> ... here it is "Irq".
>
> I'd say it should be "IRQ" everywhere.
Okay
>
> > + goto free_edac_mc;
> > + }
> > +
> > + /* Enable UE/CE Interrupts */
> > + writel((DDR_QOSUE_MASK | DDR_QOSCE_MASK),
> > + priv->baseaddr + DDR_QOS_IRQ_EN_OFST);
> > + }
> > +
> > rc = edac_mc_add_mc(mci);
> > if (rc) {
> > edac_printk(KERN_ERR, EDAC_MC,
> > @@ -684,7 +945,8 @@ static int synps_edac_mc_probe(struct
> platform_device *pdev)
> > * Start capturing the correctable and uncorrectable errors. A write of
> > * 0 starts the counters.
> > */
> > - writel(0x0, baseaddr + ECC_CTRL_OFST);
> > + if (!(priv->p_data->quirks & DDR_ECC_INTR_SUPPORT))
> > + writel(0x0, baseaddr + ECC_CTRL_OFST);
> > return rc;
> >
> > free_edac_mc:
> > @@ -702,7 +964,13 @@ static int synps_edac_mc_probe(struct
> > platform_device *pdev) static int synps_edac_mc_remove(struct
> > platform_device *pdev) {
> > struct mem_ctl_info *mci = platform_get_drvdata(pdev);
> > + struct synps_edac_priv *priv;
> >
> > + priv = mci->pvt_info;
> > + if (priv->p_data->quirks & DDR_ECC_INTR_SUPPORT)
> > + /* Disable UE/CE Interrupts */
> > + writel((DDR_QOSUE_MASK | DDR_QOSCE_MASK),
> > + priv->baseaddr + DDR_QOS_IRQ_DB_OFST);
>
> This could be a disable_irq() function. Makes the code easier to follow.
Okay. Will update this in v8.
Thanks,
Manish
[PATCH 0/2] thunderbolt: Fixes for v4.19-rc6
Hi Greg, This includes two fixes: - Stop handling ICM events when the domain is already removed upon module removal. - If the module is built into the kernel image, initialize after IOMMUs to keep the driver working when IOMMUs are enabled. I've included both patches as well in case prefer to apply them directely instead of pulling the signed tag. Thanks! The following changes since commit 11da3a7f84f19c26da6f86af878298694ede0804: Linux 4.19-rc3 (2018-09-09 17:26:43 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git tags/thunderbolt-fixes-for-v4.19-rc6 for you to fetch changes up to b3cea5ec12adc0fe0c0d264e56aa97ab617a51d6: thunderbolt: Initialize after IOMMUs (2018-09-14 10:45:22 +0300) thunderbolt: Fixes for v4.19-rc6 Mika Westerberg (2): thunderbolt: Do not handle ICM events after domain is stopped thunderbolt: Initialize after IOMMUs drivers/thunderbolt/icm.c | 49 --- drivers/thunderbolt/nhi.c | 2 +- 2 files changed, 21 insertions(+), 30 deletions(-) -- 2.18.0
[PATCH 2/2] thunderbolt: Initialize after IOMMUs
If IOMMU is enabled and Thunderbolt driver is built into the kernel image, it will be probed before IOMMUs are attached to the PCI bus. Because of this DMA mappings the driver does will not go through IOMMU and start failing right after IOMMUs are enabled. For this reason move the Thunderbolt driver initialization happen at rootfs level. Signed-off-by: Mika Westerberg --- drivers/thunderbolt/nhi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c index 88cff05a1808..5cd6bdfa068f 100644 --- a/drivers/thunderbolt/nhi.c +++ b/drivers/thunderbolt/nhi.c @@ -1191,5 +1191,5 @@ static void __exit nhi_unload(void) tb_domain_exit(); } -fs_initcall(nhi_init); +rootfs_initcall(nhi_init); module_exit(nhi_unload); -- 2.18.0
[PATCH 1/2] thunderbolt: Do not handle ICM events after domain is stopped
If there is a long chain of devices connected when the driver is loaded
ICM sends device connected event for each and those are put to tb->wq
for later processing. Now if the driver gets unloaded in the middle, so
that the work queue is not yet empty it gets flushed by tb_domain_stop().
However, by that time the root switch is already removed so the driver
crashes when it tries to dereference it in ICM event handling callbacks.
Fix this by checking whether the root switch is already removed. If it
is we know that the domain is stopped and we should merely skip handling
the event.
Signed-off-by: Mika Westerberg
---
drivers/thunderbolt/icm.c | 49 ---
1 file changed, 20 insertions(+), 29 deletions(-)
diff --git a/drivers/thunderbolt/icm.c b/drivers/thunderbolt/icm.c
index e1e264a9a4c7..28fc4ce75edb 100644
--- a/drivers/thunderbolt/icm.c
+++ b/drivers/thunderbolt/icm.c
@@ -738,14 +738,6 @@ icm_fr_xdomain_connected(struct tb *tb, const struct
icm_pkg_header *hdr)
u8 link, depth;
u64 route;
- /*
-* After NVM upgrade adding root switch device fails because we
-* initiated reset. During that time ICM might still send
-* XDomain connected message which we ignore here.
-*/
- if (!tb->root_switch)
- return;
-
link = pkg->link_info & ICM_LINK_INFO_LINK_MASK;
depth = (pkg->link_info & ICM_LINK_INFO_DEPTH_MASK) >>
ICM_LINK_INFO_DEPTH_SHIFT;
@@ -1037,14 +1029,6 @@ icm_tr_device_connected(struct tb *tb, const struct
icm_pkg_header *hdr)
if (pkg->hdr.packet_id)
return;
- /*
-* After NVM upgrade adding root switch device fails because we
-* initiated reset. During that time ICM might still send device
-* connected message which we ignore here.
-*/
- if (!tb->root_switch)
- return;
-
route = get_route(pkg->route_hi, pkg->route_lo);
authorized = pkg->link_info & ICM_LINK_INFO_APPROVED;
security_level = (pkg->hdr.flags & ICM_FLAGS_SLEVEL_MASK) >>
@@ -1408,19 +1392,26 @@ static void icm_handle_notification(struct work_struct
*work)
mutex_lock(&tb->lock);
- switch (n->pkg->code) {
- case ICM_EVENT_DEVICE_CONNECTED:
- icm->device_connected(tb, n->pkg);
- break;
- case ICM_EVENT_DEVICE_DISCONNECTED:
- icm->device_disconnected(tb, n->pkg);
- break;
- case ICM_EVENT_XDOMAIN_CONNECTED:
- icm->xdomain_connected(tb, n->pkg);
- break;
- case ICM_EVENT_XDOMAIN_DISCONNECTED:
- icm->xdomain_disconnected(tb, n->pkg);
- break;
+ /*
+* When the domain is stopped we flush its workqueue but before
+* that the root switch is removed. In that case we should treat
+* the queued events as being canceled.
+*/
+ if (tb->root_switch) {
+ switch (n->pkg->code) {
+ case ICM_EVENT_DEVICE_CONNECTED:
+ icm->device_connected(tb, n->pkg);
+ break;
+ case ICM_EVENT_DEVICE_DISCONNECTED:
+ icm->device_disconnected(tb, n->pkg);
+ break;
+ case ICM_EVENT_XDOMAIN_CONNECTED:
+ icm->xdomain_connected(tb, n->pkg);
+ break;
+ case ICM_EVENT_XDOMAIN_DISCONNECTED:
+ icm->xdomain_disconnected(tb, n->pkg);
+ break;
+ }
}
mutex_unlock(&tb->lock);
--
2.18.0
Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
Hello,
On Mon, 24 Sep 2018 11:12:13 +0100, Russell King - ARM Linux wrote:
> > Thanks for the testing. I'll wait for Russell to say if he is happy
> > (or not) with the addition of pci_unmap_io() in the ARM code, if that's
> > the case, I'll send a proper patch to fix the issue.
>
> I'd prefer not to provide an unmapping API, because it gives the
> impression that it's okay to unmap the IO space mapping, and we'll
> end up with drivers that decide to call it in their cleanup path.
> IO space isn't expected to ever go away - eg, on a PC, it's always
> present.
But being able to unmap it would also be needed to be able to remove
PCI host controller drivers, and therefore compile them as module, and
make them more like any other drivers.
I'm not sure why we need to guarantee that the I/O space is always
mapped:
- It isn't mapped before the PCI controller driver does the mapping.
- There is no reason for it to be accessed when the PCI controller
driver is not initialized: PCI devices can only be probed and
initialized when the PCI controller driver is probed/initialized.
Also, in general, pci_ioremap_io() is ARM specific, and is now only
used by very few drivers:
- Dove (Marvell platform)
- IOP13xx
- MV78xx0 (Marvell platform, should be moved to use pci-mvebu)
- Orion5x (Marvell platform, should be moved to use pci-mvebu)
- pci-mvebu
- at91_cf
All other drivers, including on ARM, use pci_remap_iospace(), which
does provide the pci_unmap_iospace() counter part.
The only reason I have not changed pci-mvebu to use
pci_{remap,unmap}_iospace() is because it doesn't allow to change the
memory attributes.
But to me, the general direction is that the ARM-specific
pci_remap_io() API is fading away, and its replacement already provides
an unmapping capability. So why not add the same unmapping capability
to pci_remap_io() ?
> I've been toying with the idea of making pci_map_io() ignore
> subsequent attempts to overwrite the mapping with an identical
> mapping, and WARN() if there is an attempt to overwrite an existing
> mapping with other physical address, but I'm not entirely happy
> with that either (which is why I haven't responded sooner.)
>
> At the moment, I don't have a way forward that I'm happy with for
> this.
But we have a regression and we need to fix it. Do you suggest to not
use the new pci_host_probe() API ?
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[PATCH 02/14] MIPS: dts: Add aliases node for lantiq danube serial
Previous implementation uses a hard-coded register value to check
if the current serial entity is the console entity.
Now the lantiq serial driver uses the aliases for the index of the
serial port.
The lantiq danube serial dts are updated with aliases to support this.
Signed-off-by: Songjun Wu
---
arch/mips/boot/dts/lantiq/danube.dtsi | 2 +-
arch/mips/boot/dts/lantiq/easy50712.dts | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/mips/boot/dts/lantiq/danube.dtsi
b/arch/mips/boot/dts/lantiq/danube.dtsi
index 510be63c8bdf..73746d7577d7 100644
--- a/arch/mips/boot/dts/lantiq/danube.dtsi
+++ b/arch/mips/boot/dts/lantiq/danube.dtsi
@@ -74,7 +74,7 @@
reg = <0xe100a00 0x100>;
};
- serial@e100c00 {
+ asc1: serial@e100c00 {
compatible = "lantiq,asc";
reg = <0xe100c00 0x400>;
interrupt-parent = <&icu0>;
diff --git a/arch/mips/boot/dts/lantiq/easy50712.dts
b/arch/mips/boot/dts/lantiq/easy50712.dts
index 1ce20b7d05cb..452860ca1868 100644
--- a/arch/mips/boot/dts/lantiq/easy50712.dts
+++ b/arch/mips/boot/dts/lantiq/easy50712.dts
@@ -4,6 +4,10 @@
/include/ "danube.dtsi"
/ {
+ aliases {
+ serial0 = &asc1;
+ };
+
chosen {
bootargs = "console=ttyLTQ0,115200 init=/etc/preinit";
};
--
2.11.0
[PATCH 07/14] serial: lantiq: Rename fpiclk to freqclk
fpiclk is platform specific, freqclk is more generic.
Signed-off-by: Songjun Wu
---
drivers/tty/serial/lantiq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index e351f80996d3..4acdbdf8fe7a 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -105,7 +105,7 @@ static DEFINE_SPINLOCK(ltq_asc_lock);
struct ltq_uart_port {
struct uart_portport;
/* clock used to derive divider */
- struct clk *fpiclk;
+ struct clk *freqclk;
/* clock gating of the ASC core */
struct clk *clk;
unsigned inttx_irq;
@@ -309,7 +309,7 @@ lqasc_startup(struct uart_port *port)
if (!IS_ERR(ltq_port->clk))
clk_enable(ltq_port->clk);
- port->uartclk = clk_get_rate(ltq_port->fpiclk);
+ port->uartclk = clk_get_rate(ltq_port->freqclk);
asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
@@ -632,7 +632,7 @@ lqasc_console_setup(struct console *co, char *options)
if (!IS_ERR(ltq_port->clk))
clk_enable(ltq_port->clk);
- port->uartclk = clk_get_rate(ltq_port->fpiclk);
+ port->uartclk = clk_get_rate(ltq_port->freqclk);
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
@@ -744,8 +744,8 @@ lqasc_probe(struct platform_device *pdev)
port->irq = irqres[0].start;
port->mapbase = mmres->start;
- ltq_port->fpiclk = clk_get_fpi();
- if (IS_ERR(ltq_port->fpiclk)) {
+ ltq_port->freqclk = clk_get_fpi();
+ if (IS_ERR(ltq_port->freqclk)) {
pr_err("failed to get fpi clk\n");
return -ENOENT;
}
--
2.11.0
[PATCH 04/14] serial: lantiq: Change ltq_w32_mask to asc_update_bits
ltq prefix is platform specific function, asc prefix
is more generic.
Signed-off-by: Songjun Wu
---
drivers/tty/serial/lantiq.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 66c671677761..4c14608b8ef8 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -113,6 +113,13 @@ struct ltq_uart_port {
unsigned interr_irq;
};
+static inline void asc_update_bits(u32 clear, u32 set, void __iomem *reg)
+{
+ u32 tmp = readl(reg);
+
+ writel((tmp & ~clear) | set, reg);
+}
+
static inline struct
ltq_uart_port *to_ltq_uart_port(struct uart_port *port)
{
@@ -163,16 +170,16 @@ lqasc_rx_chars(struct uart_port *port)
if (rsr & ASCSTATE_ANY) {
if (rsr & ASCSTATE_PE) {
port->icount.parity++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRPE,
+ asc_update_bits(0, ASCWHBSTATE_CLRPE,
port->membase + LTQ_ASC_WHBSTATE);
} else if (rsr & ASCSTATE_FE) {
port->icount.frame++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRFE,
+ asc_update_bits(0, ASCWHBSTATE_CLRFE,
port->membase + LTQ_ASC_WHBSTATE);
}
if (rsr & ASCSTATE_ROE) {
port->icount.overrun++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRROE,
+ asc_update_bits(0, ASCWHBSTATE_CLRROE,
port->membase + LTQ_ASC_WHBSTATE);
}
@@ -252,7 +259,7 @@ lqasc_err_int(int irq, void *_port)
struct uart_port *port = (struct uart_port *)_port;
spin_lock_irqsave(membase + LTQ_ASC_WHBSTATE);
spin_unlock_irqrestore(clk);
port->uartclk = clk_get_rate(ltq_port->fpiclk);
- ltq_w32_mask(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
+ asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
ltq_w32(0, port->membase + LTQ_ASC_PISEL);
@@ -320,7 +327,7 @@ lqasc_startup(struct uart_port *port)
* setting enable bits
*/
wmb();
- ltq_w32_mask(0, ASCCON_M_8ASYNC | ASCCON_FEN | ASCCON_TOEN |
+ asc_update_bits(0, ASCCON_M_8ASYNC | ASCCON_FEN | ASCCON_TOEN |
ASCCON_ROEN, port->membase + LTQ_ASC_CON);
retval = request_irq(ltq_port->tx_irq, lqasc_tx_int,
@@ -364,9 +371,9 @@ lqasc_shutdown(struct uart_port *port)
free_irq(ltq_port->err_irq, port);
ltq_w32(0, port->membase + LTQ_ASC_CON);
- ltq_w32_mask(ASCRXFCON_RXFEN, ASCRXFCON_RXFFLU,
+ asc_update_bits(ASCRXFCON_RXFEN, ASCRXFCON_RXFFLU,
port->membase + LTQ_ASC_RXFCON);
- ltq_w32_mask(ASCTXFCON_TXFEN, ASCTXFCON_TXFFLU,
+ asc_update_bits(ASCTXFCON_TXFEN, ASCTXFCON_TXFFLU,
port->membase + LTQ_ASC_TXFCON);
if (!IS_ERR(ltq_port->clk))
clk_disable(ltq_port->clk);
@@ -438,7 +445,7 @@ lqasc_set_termios(struct uart_port *port,
spin_lock_irqsave(membase + LTQ_ASC_CON);
+ asc_update_bits(0, con, port->membase + LTQ_ASC_CON);
/* Set baud rate - take a divider of 2 into account */
baud = uart_get_baud_rate(port, new, old, 0, port->uartclk / 16);
@@ -446,19 +453,19 @@ lqasc_set_termios(struct uart_port *port,
divisor = divisor / 2 - 1;
/* disable the baudrate generator */
- ltq_w32_mask(ASCCON_R, 0, port->membase + LTQ_ASC_CON);
+ asc_update_bits(ASCCON_R, 0, port->membase + LTQ_ASC_CON);
/* make sure the fractional divider is off */
- ltq_w32_mask(ASCCON_FDE, 0, port->membase + LTQ_ASC_CON);
+ asc_update_bits(ASCCON_FDE, 0, port->membase + LTQ_ASC_CON);
/* set up to use divisor of 2 */
- ltq_w32_mask(ASCCON_BRS, 0, port->membase + LTQ_ASC_CON);
+ asc_update_bits(ASCCON_BRS, 0, port->membase + LTQ_ASC_CON);
/* now we can write the new baudrate into the register */
ltq_w32(divisor, port->membase + LTQ_ASC_BG);
/* turn the baudrate generator back on */
- ltq_w32_mask(0, ASCCON_R, port->membase + LTQ_ASC_CON);
+ asc_update_bits(0, ASC
[PATCH 09/14] serial: lantiq: Add CCF support
Previous implementation uses platform-dependent API to get the clock.
Those functions are not available for other SoC which uses the same IP.
The CCF (Common Clock Framework) have an abstraction based APIs for
clock. In future, the platform specific code will be removed when the
legacy soc use CCF as well.
Change to use CCF APIs to get clock and rate. So that different SoCs
can use the same driver.
Signed-off-by: Songjun Wu
---
drivers/tty/serial/lantiq.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 34b1ef3c12ce..88210de00f35 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -744,14 +744,22 @@ lqasc_probe(struct platform_device *pdev)
port->irq = irqres[0].start;
port->mapbase = mmres->start;
- ltq_port->freqclk = clk_get_fpi();
+ if (IS_ENABLED(CONFIG_LANTIQ) && !IS_ENABLED(CONFIG_COMMON_CLK))
+ ltq_port->freqclk = clk_get_fpi();
+ else
+ ltq_port->freqclk = devm_clk_get(&pdev->dev, "freq");
+
+
if (IS_ERR(ltq_port->freqclk)) {
pr_err("failed to get fpi clk\n");
return -ENOENT;
}
/* not all asc ports have clock gates, lets ignore the return code */
- ltq_port->clk = clk_get(&pdev->dev, NULL);
+ if (IS_ENABLED(CONFIG_LANTIQ) && !IS_ENABLED(CONFIG_COMMON_CLK))
+ ltq_port->clk = clk_get(&pdev->dev, NULL);
+ else
+ ltq_port->clk = devm_clk_get(&pdev->dev, "asc");
ltq_port->tx_irq = irqres[0].start;
ltq_port->rx_irq = irqres[1].start;
--
2.11.0
[PATCH 10/14] serial: lantiq: Reorder the head files
Reorder the head files according to the coding style. Signed-off-by: Songjun Wu --- drivers/tty/serial/lantiq.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c index 88210de00f35..c983694ba24d 100644 --- a/drivers/tty/serial/lantiq.c +++ b/drivers/tty/serial/lantiq.c @@ -8,22 +8,22 @@ * Copyright (C) 2010 Thomas Langer, */ -#include -#include -#include +#include #include -#include #include -#include -#include -#include -#include -#include +#include +#include +#include +#include #include #include -#include -#include -#include +#include +#include +#include +#include +#include +#include +#include #include -- 2.11.0
