RE: [PATCH RFC V2 1/3] Input: goodix - add dt axis swapping and axis inversion support
> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Karsten Merker
> Sent: 09 October, 2015 20:56
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin;
> linux-in...@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Chen-Yu Tsai;
> Karsten Merker
> Subject: [PATCH RFC V2 1/3] Input: goodix - add dt axis swapping and axis
> inversion support
>
> Implement support for the following device-tree properties
> in the goodix touchscreen driver:
>
> - touchscreen-inverted-x: X axis is inverted (boolean)
> - touchscreen-inverted-y: Y axis is inverted (boolean)
> - touchscreen-swapped-x-y: X and Y axis are swapped (boolean)
>
> These are necessary on tablets which have a display in portrait
> format while the touchscreen is in landscape format, such as e.g.
> the MSI Primo 81.
>
> Signed-off-by: Karsten Merker
> ---
> drivers/input/touchscreen/goodix.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/input/touchscreen/goodix.c
> b/drivers/input/touchscreen/goodix.c
> index 22bfc4b..a05bdad 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -2,6 +2,7 @@
> * Driver for Goodix Touchscreens
> *
> * Copyright (c) 2014 Red Hat Inc.
> + * Copyright (c) 2015 K. Merker
> *
> * This code is based on gt9xx.c authored by and...@goodix.com:
> *
> @@ -53,6 +54,9 @@ struct goodix_ts_data {
> atomic_t open_count;
> /* Protects power management calls and access to suspended flag */
> struct mutex mutex;
> + bool swapped_x_y;
> + bool inverted_x;
> + bool inverted_y;
> };
>
> #define GOODIX_GPIO_INT_NAME "irq"
> @@ -271,6 +275,14 @@ static void goodix_ts_report_touch(struct goodix_ts_data
> *ts, u8 *coor_data)
> input_y = ts->abs_y_max - input_y;
> }
>
> + /* Inversions have to happen before axis swapping */
> + if (ts->inverted_x)
> + input_x = ts->abs_x_max - input_x;
> + if (ts->inverted_y)
> + input_y = ts->abs_y_max - input_y;
> + if (ts->swapped_x_y)
> + swap(input_x, input_y);
> +
> input_mt_slot(ts->input_dev, id);
> input_mt_report_slot_state(ts->input_dev, MT_TOOL_FINGER, true);
> input_report_abs(ts->input_dev, ABS_MT_POSITION_X, input_x);
> @@ -666,6 +678,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
>error);
> ts->abs_x_max = GOODIX_MAX_WIDTH;
> ts->abs_y_max = GOODIX_MAX_HEIGHT;
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
> ts->int_trigger_type = GOODIX_INT_TRIGGER;
> ts->max_touch_num = GOODIX_MAX_CONTACTS;
> return;
> @@ -673,6 +687,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
>
> ts->abs_x_max = get_unaligned_le16(&config[RESOLUTION_LOC]);
> ts->abs_y_max = get_unaligned_le16(&config[RESOLUTION_LOC + 2]);
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
> ts->int_trigger_type = config[TRIGGER_LOC] & 0x03;
> ts->max_touch_num = config[MAX_CONTACTS_LOC] & 0x0f;
> if (!ts->abs_x_max || !ts->abs_y_max || !ts->max_touch_num) {
> @@ -680,6 +696,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
> "Invalid config, using defaults\n");
> ts->abs_x_max = GOODIX_MAX_WIDTH;
> ts->abs_y_max = GOODIX_MAX_HEIGHT;
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
> ts->max_touch_num = GOODIX_MAX_CONTACTS;
> }
>
> @@ -950,6 +968,15 @@ static int goodix_ts_probe(struct i2c_client *client,
> return 0;
> }
>
> +#ifdef CONFIG_OF
> + ts->swapped_x_y = of_property_read_bool(client->dev.of_node,
> + "touchscreen-swapped-x-y");
> + ts->inverted_x = of_property_read_bool(client->dev.of_node,
> +"touchscreen-inverted-x");
> + ts->inverted_y = of_property_read_bool(client->dev.of_node,
> +"touchscreen-inverted-y");
> +#endif
> +
If interrupt and reset gpio pins are declared in the DT configuration, this
code will not
be executed. To make the properties available for all configurations
(with/without
gpio pins declared), you should read the properties inside
goodix_configure_dev().
You could also use device_property_read_bool() instead, so that these
properties can
be used with ACPI 5.1. as well.
Thanks,
Irina
> return goodix_configure_dev(ts);
>
> err_free_cfg_name:
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel
Re: [PATCH v5 1/3] initialize each mbigen device node as a interrupt controller.
Majun,
On Tue, 13 Oct 2015, majun (F) wrote:
> 在 2015/10/12 0:45, Thomas Gleixner 写道:
> > So now in the mbigen case this looks like this:
> >
> > [MSI-BUS] - [MBIGEN]<---[Device interrupt]
> >
> > Again, you have a 'wire' from the device to the MSI unit (MBIGEN) and
> > we do not care about that 'wire' either. What we care about is how we
> > find the MSI (mbigen) configuration registers for a particular
> > device. So we need a DT/ACPI entry which describes those configuration
> > registers and whatever supplementary information is required. That
> > will make the mbigen driver extremly simple.
> >
>
> According to your suggestions, I tried to make the hardware structure likes
> below:
>
> device(8250 uart) -> mbigne -> ITS-pMSI --> ITS --> GIC
I'm not sure whether mbigen should be connected to ITS-pMSI (I assume
you mean ITS-PCI-MSI).
mbigen is a seperate MSI domain, so it should connect to ITS, but I
leave that to Marc.
> And 8250 uart dts node is:
>
> 8250_uart {
> compatible = "xxx";
> msi-parent = < &mbigen>;
> config_addr = ; /* configuration register */
> interrupts = ;
> interrupt-parent = ?
> }
>
> My question is what's the interrupt-parent should be?
There is no interrupt parent for 8250_uart. Why would you want that?
I'm really not a DT expert, but I think you want something like this:
8250_uart {
compatible = "xxx";
msi-parent = < &mbigen_node5>;
interrupt-map = <&mbigen5 0>;
};
and then have
mbigen_node5 {
...
reg = <>;
};
So the other devices which are connected to mbigen_node5 have the same
msi-parent. But then again, please discuss that with Marc and the DT
wizards.
Thanks,
tglx
Re: [PATCH] UBIFS: Fix possible memory leak in ubifs_readdir()
> On 12.10.2015, at 23:35, Richard Weinberger wrote:
>
> If ubifs_tnc_next_ent() returns something else than -ENOENT
> we leak file->private_data.
>
> Signed-off-by: Richard Weinberger
> ---
> fs/ubifs/dir.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
> index 5c27c66..cb88ea3 100644
> --- a/fs/ubifs/dir.c
> +++ b/fs/ubifs/dir.c
> @@ -449,13 +449,14 @@ static int ubifs_readdir(struct file *file, struct
> dir_context *ctx)
> }
>
> out:
> + kfree(file->private_data);
> + file->private_data = NULL;
> +
> if (err != -ENOENT) {
> ubifs_err(c, "cannot find next direntry, error %d", err);
> return err;
> }
>
> - kfree(file->private_data);
> - file->private_data = NULL;
> /* 2 is a special value indicating that there are no more direntries */
> ctx->pos = 2;
> return 0;
> --
> 2.5.0
Looks good to me.
Reviewed-by: David Gstir
Thanks,
David--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices
+Nishanth,
On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
> On embedded devices, often there is a combination of
> removable mmc devices (e.g. MMC/SD cards) and hard
> wired ones (e.g. eMMC). Depending on the hardware
> configuration, the 'mmcblkN' node might change if
> the removable device is available or not at boot time.
>
> E.g. if the removable device is attached at boot time,
> it might become mmxblk0. And the hard wired one mmcblk1.
> But if the removable device isn't there at boot time,
> the hard wired one will become mmcblk0. This makes it
> somehow difficult to hard code the root device to the
> non-removable device and boot fast.
Why not use "root=PARTUUID=${uuid}" option instead of relying on mmcblk no?
U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
does this in u-boot.
[1]
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=437bc42e7ff930dc4d4bd47199d2e823cf84bf4c;hp=85d17be374678ec37fd1e55db994a942e400dc80
Thanks and regards,
Lokesh
>
> Signed-off-by: Heiko Schocher
> ---
> Dirk Behme tried to bring this in, last mail I found:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
> where Dirk worked in Arnds suggestion to use the
> "/aliases" device node"
>
> I adapt this to the omap_hsmmc driver.
>
> Is there another solution for this problem?
> Or why was this patch not accepted to mainline?
>
> drivers/mmc/card/block.c | 6 --
> drivers/mmc/host/omap_hsmmc.c | 6 ++
> include/linux/mmc/host.h | 3 +++
> 3 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index c742cfd..62250d8 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -2106,7 +2106,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
> mmc_card *card,
> struct mmc_blk_data *md;
> int devidx, ret;
>
> - devidx = find_first_zero_bit(dev_use, max_devices);
> + devidx = find_next_zero_bit(dev_use, max_devices,
> + card->host->devidx);
> if (devidx >= max_devices)
> return ERR_PTR(-ENOSPC);
> __set_bit(devidx, dev_use);
> @@ -2124,7 +2125,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
> mmc_card *card,
>* index anymore so we keep track of a name index.
>*/
> if (!subname) {
> - md->name_idx = find_first_zero_bit(name_use, max_devices);
> + md->name_idx = find_next_zero_bit(name_use, max_devices,
> + card->host->devidx);
> __set_bit(md->name_idx, name_use);
> } else
> md->name_idx = ((struct mmc_blk_data *)
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 7fb0753..0b45b48 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2059,6 +2059,12 @@ static int omap_hsmmc_probe(struct platform_device
> *pdev)
> host->pbias_enabled = 0;
> host->vqmmc_enabled = 0;
>
> + if (pdev->dev.of_node) {
> + ret = of_alias_get_id(pdev->dev.of_node, "mmcblk");
> + if (ret >= 0)
> + host->mmc->devidx = ret;
> + }
> +
> ret = omap_hsmmc_gpio_init(mmc, host, pdata);
> if (ret)
> goto err_gpio;
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 83b81fd..4f071681 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -382,6 +382,9 @@ struct mmc_host {
> int dsr_req;/* DSR value is valid */
> u32 dsr;/* optional driver stage (DSR) value */
>
> + /* preferred mmc block device index (mmcblkX) */
> + unsigned intdevidx;
> +
> unsigned long private[0] cacheline_aligned;
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: dts: twl4030: Add iio properties for bci subnode
Hi,
On Tue, Oct 13, 2015 at 1:53 AM, Sebastian Reichel wrote:
> Hi,
>
> On Mon, Oct 12, 2015 at 03:20:10PM -0700, Tony Lindgren wrote:
>> * Tony Lindgren [151012 14:43]:
>> > * Belisko Marek [150926 13:02]:
>> > > Tony sorry I forgot to add you to the recipients for this patchset.
>> > > Can you please queue this patch. Many thanks.
>> >
>> > OK applying into omap-for-v4.4/dt thanks.
>>
>> Actually dropping this one, it makes build fail as we don't
>> have twl4030_madc yet.
>>
>> Maybe please send a separate set of dts patches for me.
>
> mh that's strange, twl4030-madc is there since a long time. But
> checking the patch, it seems Marek got the phandle wrong:
OK, thanks for letting me know. I'll send update soon. Thanks.
>
> $ grep -B1 "ti,twl4030-madc" arch/arm/boot/dts/twl4030.dtsi
> twl_madc: madc {
> compatible = "ti,twl4030-madc";
>
> Once that is fixed, the patch should have no dependencies.
>
> -- Sebastian
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v9 9/9] Input: goodix - sort includes using inverse Xmas tree order
> -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: 12 October, 2015 19:31 > To: Bastien Nocera > Cc: Mark Rutland; Tirdea, Irina; Aleksei Mamlin; Karsten Merker; > linux-in...@vger.kernel.org; Purdila, Octavian; lkml; > devicet...@vger.kernel.org > Subject: Re: [PATCH v9 9/9] Input: goodix - sort includes using inverse Xmas > tree order > > On Mon, Oct 12, 2015 at 8:53 AM, Bastien Nocera wrote: > > On Mon, 2015-10-12 at 16:51 +0100, Mark Rutland wrote: > >> On Mon, Oct 12, 2015 at 05:40:37PM +0200, Bastien Nocera wrote: > >> > On Mon, 2015-10-12 at 16:39 +0100, Mark Rutland wrote: > >> > > Why? > >> > > >> > It was already discussed in the thread for a previous version, > >> > please > >> > refer to that. > >> > >> Fine, but surely that should be in the commit message, to prevent > >> others > >> like myself repeatedly asking the same question? > > > > Fair point. Irina? > > No, let's just leave poor includes alone. > OK, will drop this :) Thanks, Irina > -- > Dmitry
RE: [PATCH v9 2/9] Input: goodix - reset device at init
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 12 October, 2015 19:48
> To: Tirdea, Irina
> Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker;
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
>
> On Mon, Oct 12, 2015 at 06:24:30PM +0300, Irina Tirdea wrote:
> > After power on, it is recommended that the driver resets the device.
> > The reset procedure timing is described in the datasheet and is used
> > at device init (before writing device configuration) and
> > for power management. It is a sequence of setting the interrupt
> > and reset pins high/low at specific timing intervals. This procedure
> > also includes setting the slave address to the one specified in the
> > ACPI/device tree.
> >
> > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices).
> >
> > For reset the driver needs to control the interrupt and
> > reset gpio pins (configured through ACPI/device tree). For devices
> > that do not have the gpio pins properly declared, the functionality
> > depending on these pins will not be available, but the device can still
> > be used with basic functionality.
> >
> > For both device tree and ACPI, the interrupt gpio pin configuration is
> > read from the "irq-gpio" property and the reset pin configuration is
> > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > can be specified using the _DSD section. This functionality will not be
> > available for devices that use indexed gpio pins declared in the _CRS
> > section (we need to provide backward compatibility with devices
> > that do not support using the interrupt gpio pin as output).
> >
> > For ACPI, the pins can be specified using ACPI 5.1:
> > Device (STAC)
> > {
> > Name (_HID, "GDIX1001")
> > ...
> >
> > Method (_CRS, 0, Serialized)
> > {
> > Name (RBUF, ResourceTemplate ()
> > {
> > I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
> > AddressingMode7Bit, "\\I2C0",
> > 0x00, ResourceConsumer, ,
> > )
> >
> > GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
> > "\\I2C0", 0x00, ResourceConsumer, ,
> > )
> > { // Pin list
> > 0
> > }
> >
> > GpioIo (Exclusive, PullDown, 0x, 0x,
> > IoRestrictionOutputOnly, "\\I2C0", 0x00,
> > ResourceConsumer, ,
> > )
> > {
> > 1
> > }
> > })
> > Return (RBUF)
> > }
> >
> > Name (_DSD, Package ()
> > {
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > Package ()
> > {
> > Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
> > Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
> > ...
> > }
> > }
> >
> > Signed-off-by: Octavian Purdila
> > Signed-off-by: Irina Tirdea
> > Acked-by: Bastien Nocera
> > Tested-by: Bastien Nocera
> > Tested-by: Aleksei Mamlin
> > ---
> > .../bindings/input/touchscreen/goodix.txt | 5 +
> > drivers/input/touchscreen/Kconfig | 1 +
> > drivers/input/touchscreen/goodix.c | 101
> > +
> > 3 files changed, 107 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > index 8ba98ee..7137881 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > @@ -12,6 +12,8 @@ Required properties:
> > - reg : I2C address of the chip. Should be 0x5d or
> > 0x14
> > - interrupt-parent: Interrupt controller to which the chip is
> > connected
> > - interrupts : Interrupt to which the chip is connected
> > + - irq-gpio: GPIO pin used for IRQ
> > + - reset-gpio : GPIO pin used for reset
> >
> > Example:
> >
> > @@ -23,6 +25,9 @@ Example:
> > reg = <0x5d>;
> > interrupt-parent = <&gpio>;
> > interrupts = <0 0>;
> > +
> > + irq-gpio = <&gpio1 0 0>;
> > + reset-gpio = <&gpio1 1 0>;
> > };
> >
> > /* ... */
> > diff --git a/drivers/input/touchscreen/Kconfig
> > b/drivers/input/touchscreen/Kconfig
> > index 771d95c..76f5a9d 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -324,6 +324,7 @@ config TOUCHSCREEN_FUJITSU
> > con
Re: [PATCH v5 1/3] initialize each mbigen device node as a interrupt controller.
Hi Thomas:
在 2015/10/12 0:45, Thomas Gleixner 写道:
> On Sun, 11 Oct 2015, Marc Zyngier wrote:
>> On Sun, 11 Oct 2015 11:54:49 +0200
>> Thomas Gleixner wrote:
>>
>>> On Sat, 10 Oct 2015, Marc Zyngier wrote:
On Sat, 10 Oct 2015 17:01:32 +0800
"majun (F)" wrote:
> But there is a problem If i make the structure like you said.
>
> For example, my hardware structure likes below:
>
> uart --> mbigen --> ITS-pMSI --> ITS --> GIC
> virq1
>
> virq1 means the virq number allocted by irq_of_parse_and_map() function
> when system parse the uart dts node in initializing stage.
>
> To create a ITS device, I need to call msi_domain_alloc_irqs() function
> in my mbigen alloc function.
>
> In this function, a new virq number(named as virq2 ) which different from
> virq1 is allocated.
> So, this is a big problem.
I think I see what your problem is:
- The wired interrupt (uart -> mbigen) is allocated through DT (and
must be available early, because of of_platform_populate),
- The MSI (mgigen -> ITS) is dynamic (and allocated much later,
because the device model kicks in after irqchip init, and we cannot
allocate MSIs without a device).
>>>
>>> Why do we need that wired interrupt at all?
>>>
>>> We can make mbigen the 'msi-parent' of the device and let the
>>> msi_domain_ops::msi_prepare() callback figure out the actual wiring
>>> through device->fwnode.
>>
>> That's because the device behind the mbigen can't do any MSI at all.
>> Think of a 8250 uart, for example.
>>
>> If we make the mbigen the msi-parent of the uart, then we need to teach
>> the 8250 driver to request MSIs.
>
> I really do not understand why of_platform_populate cares about
> interrupt allocations. That's outright stupid. We should care about
> that at device probe time, i.e. at the point where the driver is
> registered and probed if there is matching platform data. If we do it
> in of_platform_populate then we allocate interrupts even for devices
> which do not have a driver, i.e. we just waste memory.
>
> So we better teach a couple of drivers to handle that instead of
> inventing horrible workarounds.
>
>> It also means that the DT doesn't represent the HW anymore (this
>> wired interrupt actually exists).
>
> I think the abstraction here is wrong. If it would be correct, then
> PCI-MSI would be wrong. The MSI part of PCI is a MSI producer, mbigen
> is as well. Technically MSI is not integral part of the PCI device, it
> just happens to have it's configuration registers in the PCI
> configuration space of the device:
>
> [PCI-BUS]--[Interrupt mode selector]
> ||
> ||
> --[Legacy irq gate]<-
> || |
> || |---[Device interrupt]
> || |
> --[MSI unit]<
>
> So you have a 'wire' from the device to the MSI unit, but we do not
> care about that 'wire'. All we care about are the MSI configuration
> registers. We find them via the PCI device which gives us the address
> of the PCI configuration space.
>
> So now in the mbigen case this looks like this:
>
> [MSI-BUS] - [MBIGEN]<---[Device interrupt]
>
> Again, you have a 'wire' from the device to the MSI unit (MBIGEN) and
> we do not care about that 'wire' either. What we care about is how we
> find the MSI (mbigen) configuration registers for a particular
> device. So we need a DT/ACPI entry which describes those configuration
> registers and whatever supplementary information is required. That
> will make the mbigen driver extremly simple.
>
According to your suggestions, I tried to make the hardware structure likes
below:
device(8250 uart) -> mbigne -> ITS-pMSI --> ITS --> GIC
And 8250 uart dts node is:
8250_uart {
compatible = "xxx";
msi-parent = < &mbigen>;
config_addr = ; /* configuration register */
interrupts = ;
interrupt-parent = ?
}
My question is what's the interrupt-parent should be?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
On 2015/10/13 5:35, Bjorn Helgaas wrote:
> [+cc Arnd, Rob]
>
> Hi Zhou,
>
> I have a few minor comments and two questions: one about the fact
> all the config accesses are 32 bits, and another about the use of the
> "msi-parent" node.
>
> On Sat, Oct 10, 2015 at 10:59:15AM +0800, Zhou Wang wrote:
>> This patch adds PCIe host support for HiSilicon SoC Hip05.
>>
>> Signed-off-by: Zhou Wang
>> Signed-off-by: Gabriele Paoloni
>> Signed-off-by: liudongdong
>> Signed-off-by: Kefeng Wang
>> Signed-off-by: qiuzhenfa
>
> This is a pretty long Signed-off-by chain. If each of these people
> created part of this patch, that's fine. I'm just checking whether
> that's the case, or whether some of these should be Reviewed-by,
> Suggested-by, etc., per Documentation/SubmittingPatches.
>
Hi Bjorn,
Thanks for reminding this. I had merged patches from those colleagues,
so just add Signed-off-by from them.
>> ---
>> drivers/pci/host/Kconfig | 8 ++
>> drivers/pci/host/Makefile| 1 +
>> drivers/pci/host/pcie-hisi.c | 320
>> +++
>> 3 files changed, 329 insertions(+)
>> create mode 100644 drivers/pci/host/pcie-hisi.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index d5e58ba..ae873be 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -145,4 +145,12 @@ config PCIE_IPROC_BCMA
>>Say Y here if you want to use the Broadcom iProc PCIe controller
>>through the BCMA bus interface
>>
>> +config PCI_HISI
>> +depends on OF && ARM64
>> +bool "HiSilicon SoC HIP05 PCIe controller"
>> +select PCIEPORTBUS
>> +select PCIE_DW
>> +help
>> + Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC
>> +
>> endmenu
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index 140d66f..ea1dbf2 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>> obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>> obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
>> obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
>> +obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
>> diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
>> new file mode 100644
>> index 000..26aa0d9
>> --- /dev/null
>> +++ b/drivers/pci/host/pcie-hisi.c
>> @@ -0,0 +1,320 @@
>> +/*
>> + * PCIe host controller driver for HiSilicon Hip05 SoC
>> + *
>> + * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
>> + *
>> + * Author: Zhou Wang
>> + * Dacai Zhu
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "pcie-designware.h"
>> +
>> +#define PCIE_SUBCTRL_MODE_REG 0x2800
>> +#define PCIE_SUBCTRL_SYS_STATE4_REG 0x6818
>> +#define PCIE_SLV_DBI_MODE 0x0
>> +#define PCIE_SLV_SYSCTRL_MODE 0x1
>> +#define PCIE_SLV_CONTENT_MODE 0x2
>> +#define PCIE_SLV_MSI_ASID 0x10
>> +#define PCIE_LTSSM_LINKUP_STATE 0x11
>> +#define PCIE_LTSSM_STATE_MASK 0x3F
>> +#define PCIE_MSI_ASID_ENABLE(0x1 << 12)
>> +#define PCIE_MSI_ASID_VALUE (0x1 << 16)
>> +#define PCIE_MSI_TRANS_ENABLE (0x1 << 12)
>> +#define PCIE_MSI_TRANS_REG 0x1c8
>> +#define PCIE_MSI_LOW_ADDRESS0x1b4
>> +#define PCIE_MSI_HIGH_ADDRESS 0x1c4
>> +#define PCIE_GITS_TRANSLATER0x10040
>
> "TRANSLATOR" is the more common spelling. But if you're matching
> hardware documentation, you should follow that.
>
This is a copy from linux/include/linux/irqchip/arm-gic-v3.h:
#define GITS_TRANSLATER 0X10040
It indicates the offset of ITS's GITS_TRANSLATER register.
>> +#define PCIE_SYS_CTRL20_REG 0x20
>> +#define PCIE_RD_TAB_SEL BIT(31)
>> +#define PCIE_RD_TAB_EN BIT(30)
>> +
>> +#define to_hisi_pcie(x) container_of(x, struct hisi_pcie, pp)
>> +
>> +struct hisi_pcie {
>> +struct regmap *subctrl;
>> +void __iomem *reg_base;
>> +u32 port_id;
>> +struct pcie_port pp;
>> +};
>> +
>> +static inline void hisi_pcie_apb_writel(struct hisi_pcie *pcie,
>> +u32 val, u32 reg)
>> +{
>> +writel(val, pcie->reg_base + reg);
>> +}
>> +
>> +static inline u32 hisi_pcie_apb_readl(struct hisi_pcie *pcie, u32 reg)
>> +{
>>
[PATCH] NFC: nfcwilink: Drop a useless static qualifier
There is no need to have the 'struct nfcwilink *drv' variable static in the
probe function.
It only wastes a few bytes of memory.
Signed-off-by: Christophe JAILLET
---
drivers/nfc/nfcwilink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/nfcwilink.c b/drivers/nfc/nfcwilink.c
index ce2e2cf..f81e500 100644
--- a/drivers/nfc/nfcwilink.c
+++ b/drivers/nfc/nfcwilink.c
@@ -497,7 +497,7 @@ static struct nci_ops nfcwilink_ops = {
static int nfcwilink_probe(struct platform_device *pdev)
{
- static struct nfcwilink *drv;
+ struct nfcwilink *drv;
int rc;
__u32 protocols;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] zsmalloc: remove unless line in obj_free
Signed-off-by: Hui Zhu --- mm/zsmalloc.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index f135b1b..c7338f0 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1428,8 +1428,6 @@ static void obj_free(struct zs_pool *pool, struct size_class *class, struct page *first_page, *f_page; unsigned long f_objidx, f_offset; void *vaddr; - int class_idx; - enum fullness_group fullness; BUG_ON(!obj); @@ -1437,7 +1435,6 @@ static void obj_free(struct zs_pool *pool, struct size_class *class, obj_to_location(obj, &f_page, &f_objidx); first_page = get_first_page(f_page); - get_zspage_mapping(first_page, &class_idx, &fullness); f_offset = obj_idx_to_offset(f_page, f_objidx, class->size); vaddr = kmap_atomic(f_page); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes
On 13/10/15 03:43, Tony Lindgren wrote:
> * Roger Quadros [150918 08:00]:
>> Add compatible id, GPMC register resource and interrupt
>> resource to NAND controller nodes.
>>
>> The GPMC driver now implements gpiochip and irqchip so
>> enable gpio-controller and interrupt-controller properties.
>>
>> With this the interrupt parent of NAND node changes so fix it
>> accordingly.
> ...
>> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
>> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
>> @@ -35,11 +35,14 @@
>> };
>>
>> &gpmc {
>> -ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
>> +ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
>>
>> nand@0,0 {
>> -linux,mtd-name = "micron,mt29f4g16abbda3w";
>> +compatible = "ti,omap2-nand";
>> reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
>> +interrupt-parent = <&intc>;
>> +interrupts = <20>;
>> +linux,mtd-name = "micron,mt29f4g16abbda3w";
>> nand-bus-width = <16>;
>> ti,nand-ecc-opt = "bch8";
>> gpmc,sync-clk-ps = <0>;
>
> At least torpedo breaks for NFSroot as NAND now overlaps with
> Ethernet.. What's the policy you have for moving the addresses
> around?
For OMAP3 I intended to use 0x3000 for NAND but incorrectly
used 0x0800 for the torpedo.
Does setting it to 0x3000 work? If not what is the original
NAND address for this board?
>
> There may be other similar cases to check too.
Just checked that all other OMAP3 boards I've set to 0x3000
if they were 0x0.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ext4: use private version of page_zero_new_buffers() for data=journal mode
On Fri, 9 Oct 2015 00:01:09 -0400
Theodore Ts'o wrote:
> If there is a error while copying data from userspace into the page
> cache during a write(2) system call, in data=journal mode, in
> ext4_journalled_write_end() were using page_zero_new_buffers() from
> fs/buffer.c. Unfortunately, this sets the buffer dirty flag, which is
> no good if journalling is enabled. This is a long-standing bug that
> goes back for years and years in ext3, but a combination of (a)
> data=journal not being very common, (b) in many case it only results
> in a warning message. and (c) only very rarely causes the kernel hang,
> means that we only really noticed this as a problem when commit
> 998ef75ddb caused this failure to happen frequently enough to cause
> generic/208 to fail when run in data=journal mode.
>
> The fix is to have our own version of this function that doesn't call
> mark_dirty_buffer(), since we will end up calling
> ext4_handle_dirty_metadata() on the buffer head(s) in questions very
> shortly afterwards in ext4_journalled_write_end().
>
> Thanks to Dave Hansen and Linus Torvalds for helping to identify the
> root cause of the problem.
>
> Signed-off-by: Theodore Ts'o
> ---
> fs/ext4/inode.c | 34 +-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index ae52e32..0a589bb 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -1181,6 +1181,38 @@ errout:
> return ret ? ret : copied;
> }
>
> +/*
> + * This is a private version of page_zero_new_buffers() which doesn't
> + * set the buffer to be dirty, since in data=journalled mode we need
> + * to call ext4_handle_dirty_metadata() instad.
Small typo: s/instad/instead/
> + */
> +static void zero_new_buffers(struct page *page, unsigned from, unsigned to)
> +{
> + unsigned int block_start = 0, block_end;
> + struct buffer_head *head, *bh;
> +
> + bh = head = page_buffers(page);
> + do {
> + block_end = block_start + bh->b_size;
> + if (buffer_new(bh)) {
> + if (block_end > from && block_start < to) {
> + if (!PageUptodate(page)) {
> + unsigned start, size;
> +
> + start = max(from, block_start);
> + size = min(to, block_end) - start;
> +
> + zero_user(page, start, size);
> + set_buffer_uptodate(bh);
> + }
> + clear_buffer_new(bh);
> + }
> + }
> + block_start = block_end;
> + bh = bh->b_this_page;
> + } while (bh != head);
> +}
> +
> static int ext4_journalled_write_end(struct file *file,
>struct address_space *mapping,
>loff_t pos, unsigned len, unsigned copied,
> @@ -1207,7 +1239,7 @@ static int ext4_journalled_write_end(struct file *file,
> if (copied < len) {
> if (!PageUptodate(page))
> copied = 0;
> - page_zero_new_buffers(page, from+copied, to);
> + zero_new_buffers(page, from+copied, to);
> }
>
> ret = ext4_walk_page_buffers(handle, page_buffers(page), from,
--
Best regards,
Leonid Fedorenchik
Software Engineer
Paragon Software Group
Skype: leonid.fedorenchik
http://www.paragon-software.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated scalable urandom patchkit
> We're really getting into low-level implementations here, and I think > it's best to worry about these sorts of things when we have a patch to > review. > it's probably safer to simply not exit it. > I'm personally more inclined to keep it with the task struct, so that > different threads will use different crypto contexts, just from > simplicity point of view since we won't need to worry about locking. > Once we code it up we can see how many bytes this takes, we can have > this discussion. I'm fine with all of these; thank you. > This is one of the reasons why I looked at, and then discarded, to use > x86 accelerated AES as the basis for a CRNG. Setting up AES so that > it can be used easily with or without hardware acceleration looks very > complicated to do in a cross-architectural way, and I haven't looked as deeply, but it didn't look too hard. Is it possible to briefly explain the problem? I assumed you'd have an arch-specific capabilities probe function that would set up an operations structure. That would provide the various buffer sizes required, and setup (kernel_fpu_begin() and key scheduling) CPRNG core, and teardown (kernel_fpu_end()) functions. It there some huge gotcha I'm overlooking? > I don't want to drag in all of the crypto layer for /dev/random. Oh, gods, no; the crypto layer drives me nuts. Truthfully, the main hair of the crypto layer is all the modular cipher modes on top of block ciphers, and the scatterlist stuff to handle arbitrarily fragmented input and output buffers for the benefit of the network layer, but the code is horrible reading. Every time I look, I find something I want to fix (the CTS mode implementation uses 6 blocks worth of stack buffer; I have a patch to reduce that to 3) but then I get lost is the morass of structures and wrappers trying to make the code fit in with the rest. There's a struct crypto_tfm, crypto_alg, crypto_instance, cipher_desc, crypto_type, crypto_template, crypto_spawn... I've been trying to read it and I still have no idea what half of them are for. And I *still* haven't figured out how to get the self-test code to tell me that test X was performed and passed. I ended up writing my own test, which seems wrong. > ... and I've thought about this as being the first step towards > potentially replacing SHA1 with something ChaCha20 based, in light of > the SHAppening attack. Unfortunately, BLAKE2s is similar to ChaCha > only from design perspective, not an implementation perspective. > Still, I suspect the just looking at the crypto primitives, even if we > need to include two independent copies of the ChaCha20 core crypto and > the Blake2s core crypto, it still should be about half the size of the > SHA-1 crypto primitive. Well, the SHAppening doesn't really change much except a slight schedule tweak, but yeah, it's one of those things that would be nice to get around to. I'm not sure what you expect to do with ChaCha, though; it's really an expansion function, not compression, and not easily adapted to be one. BLAKE2 is a bit ugly. I'm generally not liking MD5/SHA-like designs that dribble the message and some round constants in; I'm much preferring the large-state "add a bunch of input all at once" designs like Keccak, SipHash and DJB's SHA-3 entry, CubeHash. Have you seen it? It's quite similar to Keccak, just using a 32x32 = 1024 bit state rather than Keccak's 25*64=1600. The reason it got dumped is because, like Keccak, to get n bits of preimage resistance, it requires 2n bits of "capacity" bits unused each round. When you ask for 512 bits of preimage resistance, you can only import a few bits of message each block. Keccak has the same problem, but it has a big enough block that it can handle it. In Dan's submission, you'll see his usual "this is a stupid request which I'm only paying lip service to", and his "SHA-3-512-formal" proposal was dog-slow. To quote: The "SHA-3-512-formal" proposal is aimed at users who are (1) concerned with attacks using 2^384 operations, (2) unconcerned with quantum attacks that cost far less, and (3) unaware that attackers able to carry out 2^256 operations would wreak havoc on the entire SHA-3 landscape, forcing SHA-3 to be replaced no matter which function is selected as SHA-3. The "SHA-3-512-normal" proposal is aimed at sensible users. For all real-world cryptographic applications, the "formal" versions here can be ignored, and the tweak amounts to a proposal of CubeHash16/32 as SHA-3." If NIST had proposed changing the preimage resistance rules *before* the final decision, things would have gone a lot differently. > And from the non-plumbing side of things, Andi's patchset increases > the size of /dev/random by a bit over 6%, or 974 bytes from a starting > base of 15719 bytes. It ought to be possible to implement a ChaCha20 > based CRNG (ignoring the crypto primitives) in less t
Re: [PATCH] drivers :staging: android: make alignment match open parenthesis
On Tue, Oct 13, 2015 at 11:40:00AM +0800, Greg KH wrote:
- ashmem_area_cachep = kmem_cache_create("ashmem_area_cache",
- sizeof(struct ashmem_area),
- 0, 0, NULL);
+ ashmem_area_cachep =
+ kmem_cache_create("ashmem_area_cache",
+ sizeof(struct ashmem_area),
+ 0, 0, NULL);
is this really more readable?
You are right. The four-line version looks stupid. Just ignore
these changes.
Thanks for your patience,
liao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] thp: use is_zero_pfn only after pte_present check
On Mon, Oct 12, 2015 at 10:41:24PM -0700, Greg Kroah-Hartman wrote: > On Tue, Oct 13, 2015 at 11:38:38AM +0900, Minchan Kim wrote: > > Use is_zero_pfn on pteval only after pte_present check on pteval > > (It might be better idea to introduce is_zero_pte where checks > > pte_present first). Otherwise, it could work with swap or > > migration entry and if pte_pfn's result is equal to zero_pfn > > by chance, we lose user's data in __collapse_huge_page_copy. > > So if you're luck, the application is segfaulted and finally you > > could see below message when the application is exit. > > > > BUG: Bad rss-counter state mm:88007f099300 idx:2 val:3 > > > > Cc: > > Acked-by: Kirill A. Shutemov > > Reviewed-by: Andrea Arcangeli > > Signed-off-by: Minchan Kim > > --- > > Hello Greg, > > > > This patch should go to -stable but when you will apply it > > after merging of linus tree, it will be surely conflicted due > > to userfaultfd part. > > > > I want to know how to handle it. > > You will get an automated email saying it didn't apply and then you > provide a backported version. Or you send a properly backported version > to sta...@vger.kernel.org before then, with the git commit id of the > patch in Linus's tree. Okay, I will send a right version when I received automatd email. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3-rc3 BAR allocation problems on multiple machines
On Mon, Oct 12, 2015 at 10:43 PM, Yinghai Lu wrote:
> On Mon, Oct 12, 2015 at 10:06 PM, Meelis Roos wrote:
>>> >> > sparc64 machines:
>>
>> Updated on V210 - the others were more recent. Now I get more BAR
>> warning there too:
>>
>> http://kodu.ut.ee/~mroos/dm/dm.v210+patches
>>
>
> interesting, mem and mem64 is overlapping.
>
> [ 38.824625] /pci@1f,70: TOMATILLO PCI Bus Module ver[4:0]
> [ 38.824654] /pci@1f,70: PCI IO [io
> 0x7f60100-0x7f601ff] offset 7f60100
> [ 38.824680] /pci@1f,70: PCI MEM [mem
> 0x7f7-0x7f7] offset 7f7
> [ 38.824704] /pci@1f,70: PCI MEM64 [mem
> 0x7f7-0x7f7] offset 7f7
> [ 38.826310] PCI: Scanning PBM /pci@1f,70
> [ 38.826479] schizo f0069c00: PCI host bridge to bus :00
> [ 38.826506] pci_bus :00: root bus resource [io
> 0x7f60100-0x7f601ff] (bus address [0x-0xff])
> [ 38.826536] pci_bus :00: root bus resource [mem
> 0x7f7-0x7f7] (bus address [0x-0x])
> [ 38.826565] pci_bus :00: root bus resource [mem
> 0x7f7-0x7f7] (bus address [0x-0x])
>
For overlapping, please check attached patch that should fix the problem.
Thanks
Yinghai
Subject: [PATCH] sparc/PCI: check overlapping mmio64 with mmio for root bus
Found one system have overlapping between mmio64 and mmio:
/pci@1d,70: TOMATILLO PCI Bus Module ver[4:0]
/pci@1d,70: PCI IO [io 0x7c60100-0x7c601ff] offset 7c60100
/pci@1d,70: PCI MEM [mem 0x7c7-0x7c7] offset 7c7
/pci@1d,70: PCI MEM64 [mem 0x7c7-0x7c7] offset 7c7
PCI: Scanning PBM /pci@1d,70
schizo f00859d4: PCI host bridge to bus 0003:00
pci_bus 0003:00: root bus resource [io 0x7c60100-0x7c601ff] (bus address [0x-0xff])
pci_bus 0003:00: root bus resource [mem 0x7c7-0x7c7] (bus address [0x-0x])
pci_bus 0003:00: root bus resource [mem 0x7c7-0x7c7] (bus address [0x-0x])
so add checking for overlapping, and skip that mem64.
Signed-off-by: Yinghai Lu
---
arch/sparc/kernel/pci_common.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/sparc/kernel/pci_common.c
===
--- linux-2.6.orig/arch/sparc/kernel/pci_common.c
+++ linux-2.6/arch/sparc/kernel/pci_common.c
@@ -483,12 +483,17 @@ void pci_determine_mem_io_space(struct p
if (mem64_offset != pbm->mem_offset)
panic("mem offset %llx != mem64 offset %llx\n",
pbm->mem_offset, mem64_offset);
+ if (pbm->mem64_space.start <= pbm->mem_space.end)
+pbm->mem64_space.start = pbm->mem_space.end + 1;
+ if (pbm->mem64_space.start > pbm->mem64_space.end)
+pbm->mem64_space.flags = 0;
} else
pbm->mem_offset = mem64_offset;
+ }
+ if (pbm->mem64_space.flags)
printk("%s: PCI MEM64 %pR offset %llx\n",
pbm->name, &pbm->mem64_space, pbm->mem_offset);
- }
pbm->io_space.name = pbm->mem_space.name = pbm->name;
pbm->mem64_space.name = pbm->name;
Re: 4.3-rc3 BAR allocation problems on multiple machines
On Mon, Oct 12, 2015 at 10:06 PM, Meelis Roos wrote: >> >> > sparc64 machines: > > Updated on V210 - the others were more recent. Now I get more BAR > warning there too: > > http://kodu.ut.ee/~mroos/dm/dm.v210+patches other warning: [ 38.829890] pci 0001:00:07.0: can't claim BAR 2 [mem 0x7ff-0x7ff000f]: address conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f] [ 38.829924] pci 0001:00:06.0: can't claim BAR 0 [io 0x7fe0100-0x7fe010f]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100] [ 38.829957] pci 0001:00:0d.0: can't claim BAR 0 [io 0x7fe01000900-0x7fe01000907]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100] [ 38.829988] pci 0001:00:0d.0: can't claim BAR 1 [io 0x7fe01000918-0x7fe0100091f]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100] [ 38.830019] pci 0001:00:0d.0: can't claim BAR 2 [io 0x7fe01000910-0x7fe01000917]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100] [ 38.830050] pci 0001:00:0d.0: can't claim BAR 3 [io 0x7fe01000908-0x7fe0100090f]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100] [ 38.830081] pci 0001:00:0d.0: can't claim BAR 4 [io 0x7fe01000920-0x7fe0100092f]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100] are real overlapping 1. between BAR1 and BAR2 for 0001:00:07.0. 2. between BAR from 0001:00:07.0 and 0001:00:06.0 io. I would suspect 1:00:07.0 is not assigned by firmware. [ 38.830112] PCI: /pci@1e,60 can't claim Video RAM area [mem 0x7ff000a-0x7ff000b]: address conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f] [ 38.830150] PCI: /pci@1e,60 can't claim System ROM [mem 0x7ff000f-0x7ff000f]: address conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f] [ 38.830187] PCI: /pci@1e,60 can't claim Video ROM [mem 0x7ff000c-0x7ff000c7fff]: address conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f] those are intended. Anyway OBP does not assign resource to 1:00:07.0 ? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity
On Tue, Oct 13, 2015 at 12:12:29AM +0300, Laurent Pinchart wrote: > Hello, > > While working on regulators, GPIOs and DT I noticed that many of our DT source > files incorrectly describe fixed regulators. The common error patterns are > > - Usage of the undefined (and never parsed) enable-active-low property > - Usage of the enable-active-high property without specifying an enable GPIO > - Typos in the enabl GPIO property name (gpios instead of gpio) > - Mismatch between the enable-active-high property (or the lack thereof) and > the enable GPIO flags > > This patch series fixes those issues in all the DT sources after locating the > errors using the following script. Nice. For the i.MX boards: Reviewed-by: Sascha Hauer Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] scsi: report 'INQUIRY result too short' once per host
On 10/12/2015 05:16 PM, Vitaly Kuznetsov wrote:
> Hannes Reinecke writes:
>
>> On 10/08/2015 06:54 PM, Vitaly Kuznetsov wrote:
>>> Some host adapters (e.g. Hyper-V storvsc) are known for not respecting the
>>> SPC-2/3/4 requirement for 'INQUIRY data (see table ...) shall contain at
>>> least 36 bytes'. As a result we get tons on 'scsi 0:7:1:1: scsi scan:
>>> INQUIRY result too short (5), using 36' messages on console. This can be
>>> problematic for slow consoles. Introduce short_inquiry flag in struct
>>> Scsi_Host to print the message once per host.
>>>
>>> Signed-off-by: Vitaly Kuznetsov
>>> ---
>>> Changes since v2:
>>> - This is a successor of previously sent (and still not merged) "scsi:
>>> introduce short_inquiry flag for broken host adapters" patch. I'm not
>>> particularly sure which solution is better but I'm leaning towards this
>>> one as it doesn't require changes to adapter drivers.
>>> ---
>>> drivers/scsi/scsi_scan.c | 9 ++---
>>> include/scsi/scsi_host.h | 3 +++
>>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
>>> index f9f3f82..cd347e4 100644
>>> --- a/drivers/scsi/scsi_scan.c
>>> +++ b/drivers/scsi/scsi_scan.c
>>> @@ -701,9 +701,12 @@ static int scsi_probe_lun(struct scsi_device *sdev,
>>> unsigned char *inq_result,
>>> * strings.
>>> */
>>> if (sdev->inquiry_len < 36) {
>>> - sdev_printk(KERN_INFO, sdev,
>>> - "scsi scan: INQUIRY result too short (%d),"
>>> - " using 36\n", sdev->inquiry_len);
>>> + if (!sdev->host->short_inquiry) {
>>> + shost_printk(KERN_INFO, sdev->host,
>>> + "scsi scan: INQUIRY result too short (%d),"
>>> + " using 36\n", sdev->inquiry_len);
>>> + sdev->host->short_inquiry = 1;
>>> + }
>>> sdev->inquiry_len = 36;
>>> }
>>>
>> At least you need to check if you've received any valid data here;
>> 'INQUIRY result too short' is also a common error if the interrupt
>> is hosed when trying to access the device.
>> So please check for 'inquiry_len > 4' before setting 'short_inquiry'.
>
> Currently we proceed even with a shorter reply... Should we abort the
> scan (and return -EOI?) in case we got inquiry_len <= 4?
>
Yes please. We need to ensure that we actually received some data,
and not running into an error scenario here.
So we need to read at least five bytes of data, as byte 4 carries
the response length. If we read less than that we have no way of
figuring out if the response data is even remotely sane.
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] cpufreq: create cpu/cpufreq/policyX directories
On 12-10-15, 12:31, Saravana Kannan wrote: > Can we use the first CPU in the related CPUs mask? Instead of the > first CPU that the policy got created on? The policyX numbering > would be a bit more consistent that way. Okay, checked this again. The problem is that ->init() isn't called yet and we are very early in the initialization sequence. So, we can't really know related_cpus yet. So I will keep it unchanged for now. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] igb: improve handling of disconnected adapters
On Wed, 2015-10-07 at 09:21 -0400, Jarod Wilson wrote: > Some pci changes upcoming in 4.3 seem to cause additional > disconnects, > which can happen at unfortuitous times for igb, leading to issues > such as > this: > > [ 414.440115] igb :15:00.0: enabling device ( -> 0002) > [ 414.474934] pps pps0: new PPS source ptp1 > [ 414.474937] igb :15:00.0: added PHC on eth0 > [ 414.474938] igb :15:00.0: Intel(R) Gigabit Ethernet Network > Connection > [ 414.474940] igb :15:00.0: eth0: (PCIe:2.5Gb/s:Width x1) > e8:ea:6a:00:1b:2a > [ 414.475072] igb :15:00.0: eth0: PBA No: 000200-000 > [ 414.475073] igb :15:00.0: Using MSI-X interrupts. 4 rx > queue(s), 4 tx queue(s) > [ 414.478453] igb :15:00.0 enp21s0: renamed from eth0 > [ 414.497747] IPv6: ADDRCONF(NETDEV_UP): enp21s0: link is not ready > [ 414.536745] igb :15:00.0 enp21s0: PCIe link lost, device now > detached > [ 414.854808] BUG: unable to handle kernel paging request at > 3818 > [ 414.854827] IP: [] > igb_configure_tx_ring+0x14c/0x250 [igb] > [ 414.854846] PGD 0 > [ 414.854849] Oops: 0002 [#1] SMP > [ 414.854856] Modules linked in: firewire_ohci firewire_core > crc_itu_t igb dca ctr ccm arc4 iwlmvm mac80211 fuse xt_CHECKSUM > ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT > nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat > ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat > nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle > ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat > nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack > iptable_mangle iptable_security iptable_raw iptable_filter bnep > dm_mirror dm_region_hash dm_log dm_mod snd_hda_codec_hdmi coretemp > x86_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt ppdev kvm > iTCO_vendor_support hp_wmi sparse_keymap crct10dif_pclmul > crc32_pclmul ghash_clmulni_intel > [ 414.855073] drbg ansi_cprng snd_hda_codec_realtek > snd_hda_codec_generic aesni_intel aes_x86_64 lrw gf128mul glue_helper > ablk_helper cryptd snd_hda_intel snd_hda_codec microcode snd_hda_core > snd_hwdep snd_seq snd_seq_device snd_pcm iwlwifi uvcvideo btusb > cfg80211 videobuf2_vmalloc videobuf2_memops btrtl btbcm > videobuf2_core btintel bluetooth v4l2_common snd_timer videodev snd > parport_pc rtsx_pci_ms joydev pcspkr input_leds i2c_i801 media sg > memstick rfkill soundcore lpc_ich 8250_fintek parport mei_me hp_accel > ie31200_edac shpchp lis3lv02d mei edac_core input_polldev hp_wireless > tpm_infineon sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc > ip_tables xfs libcrc32c sr_mod sd_mod cdrom rtsx_pci_sdmmc mmc_core > crc32c_intel serio_raw rtsx_pci nouveau mxm_wmi ahci hwmon libahci > e1000e drm_kms_helper > [ 414.855309] ptp xhci_pci pps_core ttm xhci_hcd wmi video ipv6 > autofs4 > [ 414.855331] CPU: 2 PID: 875 Comm: NetworkManager Not tainted 4.2.0 > -5.el7_UNSUPPORTED.x86_64 #1 > [ 414.855348] Hardware name: Hewlett-Packard HP ZBook 15 G2/2253, > BIOS M70 Ver. 01.07 02/26/2015 > [ 414.855365] task: 880484698c00 ti: 88005859c000 task.ti: > 88005859c000 > [ 414.855380] RIP: 0010:[] [] > igb_configure_tx_ring+0x14c/0x250 [igb] > [ 414.855401] RSP: 0018:88005859f608 EFLAGS: 00010246 > [ 414.855410] RAX: 3818 RBX: RCX: > 3818 > [ 414.855424] RDX: RSI: 0008 RDI: > 002a9fe6 > [ 414.855437] RBP: 88005859f638 R08: 03030300 R09: > ffe7 > [ 414.855451] R10: 81fa91b4 R11: 07e3 R12: > > [ 414.855464] R13: 880471c98840 R14: 8804670a1180 R15: > 000483cce000 > [ 414.855478] FS: 7f389c6fb8c0() GS:88049dc8() > knlGS: > [ 414.855493] CS: 0010 DS: ES: CR0: 80050033 > [ 414.855504] CR2: 3818 CR3: 0004875da000 CR4: > 001406e0 > [ 414.855518] Stack: > [ 414.855520] 88005859f638 880471c98840 880471c98df8 > 0001 > [ 414.855538] 880471c98848 0001 88005859f698 > a0b99cb0 > [ 414.85] 88005859f678 59ab02179a7fe4d0 f3ce6b27ad46225f > f5454218094e72d1 > [ 414.855572] Call Trace: > [ 414.855577] [] igb_configure+0x240/0x400 [igb] > [ 414.855590] [] __igb_open+0xc2/0x560 [igb] > [ 414.855602] [] ? notifier_call_chain+0x4d/0x80 > [ 414.855614] [] igb_open+0x10/0x20 [igb] > [ 414.855625] [] __dev_open+0xb1/0x130 > [ 414.855636] [] __dev_change_flags+0xa1/0x160 > [ 414.855647] [] dev_change_flags+0x29/0x60 > [ 414.855658] [] do_setlink+0x5d3/0xaa0 > [ 414.855679] [] ? nla_parse+0xa3/0x100 > [ 414.855689] [] rtnl_newlink+0x4f0/0x880 > [ 414.855700] [] ? rtnl_newlink+0xf3/0x880 > [ 414.855721] [] ? netlink_unicast+0x1ae/0x220 > [ 414.855734] [] ? security_capable+0x48/0x60 > [ 414.855746] [] ? ns_capable+0x2d/0x60 > [ 414.855756] [] rtnetl
Re: [PATCH 5/5] cpufreq: Drop redundant check for inactive policies
On 12-10-15, 12:35, Saravana Kannan wrote: > Doesn't really seem related to the sysfs reorg/clean up. Should it > be a separate patch outside of this series? Sent it separately now .. > Acked-by: Saravana Kannan A reviewed-by would have been more appropriate here though. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] f2fs crypto: fix racing of accessing encrypted page among different competitors
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, October 13, 2015 5:00 AM
> To: Chao Yu
> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] f2fs crypto: fix racing of accessing encrypted page
> among different
> competitors
>
> On Thu, Oct 08, 2015 at 08:50:39PM +0800, Chao Yu wrote:
> > >From 0211c6ed82440891b3369851d079f6c69b432b6c Mon Sep 17 00:00:00 2001
> > From: Chao Yu
> > Date: Thu, 8 Oct 2015 13:27:34 +0800
> > Subject: [PATCH] f2fs crypto: fix racing of accessing encrypted page among
> > different competitors
> >
> > Since we use different page cache (normally inode's page cache for R/W
> > and meta inode's page cache for GC) to cache the same physical block
> > which is belong to an encrypted inode. Writeback of these two page
> > cache should be exclusive, but now we didn't handle writeback state
> > well, so there may be potential racing problem:
> >
> > a)
> > kworker:f2fs_gc:
> > - f2fs_write_data_pages
> > - f2fs_write_data_page
> >- do_write_data_page
> > - write_data_page
> > - f2fs_submit_page_mbio
> > (page#1 in inode's page cache was queued
> > in f2fs bio cache, and be ready to write
> > to new blkaddr)
> > - gc_data_segment
> > - move_encrypted_block
> >- pagecache_get_page
> > (page#2 in meta inode's page cache
> > was cached with the invalid datas
> > of physical block located in new
> > blkaddr)
> >- f2fs_submit_page_mbio
> > (page#1 was submitted, later, page#2
> > with invalid data will be submitted)
> >
> > b)
> > f2fs_gc:
> > - gc_data_segment
> > - move_encrypted_block
> >- f2fs_submit_page_mbio
> > (page#1 in meta inode's page cache was
> > queued in f2fs bio cache, and be ready
> > to write to new blkaddr)
> > user thread:
> > - f2fs_write_begin
> > - f2fs_submit_page_bio
> > (we submit the request to block layer
> > to update page#2 in inode's page cache
> > with physical block located in new
> > blkaddr, so here we may read gabbage
> > data from new blkaddr since GC hasn't
> > writebacked the page#1 yet)
> >
> > This patch fixes above potential racing problem for encrypted inode.
> >
> > Signed-off-by: Chao Yu
> > ---
> > fs/f2fs/data.c| 20 +++-
> > fs/f2fs/f2fs.h| 1 +
> > fs/f2fs/file.c| 5 +
> > fs/f2fs/gc.c | 13 ++---
> > fs/f2fs/segment.c | 17 +
> > 5 files changed, 44 insertions(+), 12 deletions(-)
> >
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 40a0102..d791bd3 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -954,21 +954,14 @@ submit_and_realloc:
> >
> > if (f2fs_encrypted_inode(inode) &&
> > S_ISREG(inode->i_mode)) {
> > - struct page *cpage;
> >
> > ctx = f2fs_get_crypto_ctx(inode);
> > if (IS_ERR(ctx))
> > goto set_error_page;
> >
> > /* wait the page to be moved by cleaning */
> > - cpage = find_lock_page(
> > - META_MAPPING(F2FS_I_SB(inode)),
> > - block_nr);
> > - if (cpage) {
> > - f2fs_wait_on_page_writeback(cpage,
> > - DATA);
> > - f2fs_put_page(cpage, 1);
> > - }
> > + f2fs_wait_on_encrypted_page_writeback(
> > + F2FS_I_SB(inode), block_nr);
> > }
> >
> > bio = bio_alloc(GFP_KERNEL,
> > @@ -1059,6 +1052,11 @@ int do_write_data_page(struct f2fs_io_info *fio)
> > }
> >
> > if (f2fs_encrypted_inode(inode) && S_ISREG(inode->i_mode)) {
> > +
> > + /* wait for GCed encrypted page writeback */
> > + f2fs_wait_on_encrypted_page_writeback(F2FS_I_SB(inode),
> > + fio->blk_addr);
> > +
> > fio->encrypted_page = f2fs_encrypt(inode, fio->page);
> >
Re: [PATCH] drivers :staging: android: make alignment match open parenthesis
On Tue, Oct 13, 2015 at 11:32:31AM +0800, Liao Tonglang wrote:
> Cleanup for checkpatch.pl warn below:
> CHECK: Alignment should match open parenthesis
> #836: FILE: drivers/staging/android/ashmem.c:836:
> by split three lines to four.
>
> Signed-off-by: Liao Tonglang
> ---
> drivers/staging/android/ashmem.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/android/ashmem.c
> b/drivers/staging/android/ashmem.c
> index 60200a3..99fc7dc 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -832,9 +832,10 @@ static int __init ashmem_init(void)
> {
> int ret;
>
> - ashmem_area_cachep = kmem_cache_create("ashmem_area_cache",
> - sizeof(struct ashmem_area),
> - 0, 0, NULL);
> + ashmem_area_cachep =
> + kmem_cache_create("ashmem_area_cache",
> + sizeof(struct ashmem_area),
> + 0, 0, NULL);
Now you are just getting very picky for checkpatch issues, is this
really more readable?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000
On 12-10-15 14:38, Michal Simek wrote:
Hi Mike,
On 10/12/2015 02:22 PM, Mike Looijmans wrote:
On 12-10-15 13:16, Michal Simek wrote:
+static int zynq_fpga_ops_write(struct fpga_manager *mgr,
+const char *buf, size_t count)
+{
+ struct zynq_fpga_priv *priv;
+ int err;
+ char *kbuf;
+ size_t i, in_count;
+ dma_addr_t dma_addr;
+ u32 transfer_length = 0;
+ bool endian_swap = false;
+
+ in_count = count;
+ priv = mgr->priv;
+
+ kbuf = dma_alloc_coherent(priv->dev, count, &dma_addr,
GFP_KERNEL);
+ if (!kbuf)
+ return -ENOMEM;
+
+ memcpy(kbuf, buf, count);
+
+ /* look for the sync word */
+ for (i = 0; i < count - 4; i++) {
+ if (memcmp(kbuf + i, "\x66\x55\x99\xAA", 4) == 0) {
+ dev_dbg(priv->dev, "Found normal sync word\n");
+ endian_swap = false;
+ break;
+ }
This is bin format
+ if (memcmp(kbuf + i, "\xAA\x99\x55\x66", 4) == 0) {
+ dev_dbg(priv->dev, "Found swapped sync word\n");
+ endian_swap = true;
+ break;
+ }
This is bit format from header
+ }
How much control do we have over mandating the format of firmware at
this point? It'd be swell if we could just mandate a specific
endianness, and leave this munging to usermode.
That's a good question. Personally I do only care about one of both,
but that's just because I get to decide for my targets...
Opinions from the Xilinx guys?
Don't know full history about this but in past bitstream in BIT format
was used. Which is header (partially decoding in u-boot for example)
with data.
On zynq native format is BIN which is format without header and data is
swapped.
This code just detects which format is used. If BIT, header is skipped
and data is swapped to BIN format.
Back to origin question if this is something what can be handled from
user space. And answer is - yes it can be handled there.
But based on my experience it is very useful to be able to handle BIT
because it is built by tools by default.
Also with BIN format you are loosing record what this data bitstream
targets. Header in BIT gives you at least some ideas.
People should stop using "cat" to program the FPGA and use a userspace
tool instead. I've already released such tools under GPL, so anyone can
pick up on it and extend it as required.
Link?
https://github.com/topic-embedded-products/dyplo-utils/blob/master/dyploprogrammer.cpp
https://github.com/topic-embedded-products/libdyplo/blob/master/hardware.cpp#L261
Will need some work to combine into a single tool though.
This is fpga manager based driver where "cat" won't be used.
Haven't looked into it yet, but I guess at some point one will have to stream
some data from userspace into the device, right?
The header for the "bit" format is completely ignored (you can't even
use it to determine if the bitstream is compatible with the current
device) so there's no point in carrying it around.
up2you what you want to do with it. If you work with different boards
with different FPGAs it is at least helpful to know if X.bit target this
or that board. Unfortunately I am not aware about any public document
which describe what there is written.
On the zynq, doing
the "swap" in userspace was measurably faster than having the driver
handle it, and that was even without using NEON instructions for byte
swapping.
I admit that being able to do "cat static.bit > /dev/xdevcfg" has had
its uses. But it's not something that belongs in mainline Linux.
It is about comfort but I have really not a problem that driver will
handle just BIN format.
Probably one of the key reasons that the "bit" format is still popular
is that getting the Vivado tools to create a proper "bin" that will
actually work on the Zynq is about as easy as nailing jelly to a tree.
We've been using a simple Python script to do the bit->bin conversion
for that reason.
In vivado it is one tcl cmd. But truth is that I don't really get why
BIN is not generated by default.
If I recall correctly, Vivado strips the "bit" header but doesn't swap the
bytes, so the resulting bin file won't work.
Using the "bin" format in the driver keeps it simple and singular.
Userspace tools can add whatever wrappers and headers they feel
appropriate to it, these checks don't belong in the driver since they
will be application specific. For example, some users would want to
verify that a partial bitstream actually matches the static part that's
currently in the FPGA.
agree.
Thanks,
Michal
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this
[PATCH] arm, omap2, sram: On HS/EMU devices, only 64K internal SRAM is available.
Of this, secure content (including PPA) uses initial
portion of the SRAM. This chunk is not (and shouldn't
be) accessible from the public code.
The minimum size of this chunk (0x350) is used in this
patch. Available size is rounded off to 63K.
Both values would require a change if size of secure
content grows beyond 0x350.
Signed-off-by: Heiko Schocher
Signed-off-by: Ayoub Zaki
---
arch/arm/mach-omap2/sram.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index cd488b8..2e7c00f 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -47,6 +47,28 @@
#define GP_DEVICE 0x300
+/**
+ * Size of chunk used by secure content in the HS/EMU devices.
+ *
+ * This size is not fixed. It depends upon the implementation of PPA.
+ * May need to be modified if the size grows.
+ */
+#define AM33XX_HS_HEADER_SIZE 0x0350
+
+/**
+ * Start of public SRAM on HS/EMU devices.
+ */
+#define AM33XX_SRAM_PA 0x4030
+#define AM33XX_SRAM_PUB_PA (AM33XX_SRAM_PA + AM33XX_HS_HEADER_SIZE)
+
+/**
+ * Size of public SRAM available on HS/EMU devices.
+ *
+ * This size also depends upon AM33XX_HS_HEADER_SIZE.
+ * Current value is derived from nearest round-off.
+ */
+#define AM33XX_SRAM_PUB_SIZE 0xfc00 /* 63K */
+
#define ROUND_DOWN(value,boundary) ((value) & (~((boundary)-1)))
static unsigned long omap_sram_start;
@@ -99,6 +121,9 @@ static void __init omap_detect_sram(void)
} else {
omap_sram_size = 0x8000; /* 32K */
}
+ } else if (soc_is_am33xx()) {
+ omap_sram_start = AM33XX_SRAM_PUB_PA;
+ omap_sram_size = AM33XX_SRAM_PUB_SIZE;
} else {
omap_sram_start = OMAP2_SRAM_PUB_PA;
omap_sram_size = 0x800; /* 2K */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] thp: use is_zero_pfn only after pte_present check
On Tue, Oct 13, 2015 at 11:38:38AM +0900, Minchan Kim wrote: > Use is_zero_pfn on pteval only after pte_present check on pteval > (It might be better idea to introduce is_zero_pte where checks > pte_present first). Otherwise, it could work with swap or > migration entry and if pte_pfn's result is equal to zero_pfn > by chance, we lose user's data in __collapse_huge_page_copy. > So if you're luck, the application is segfaulted and finally you > could see below message when the application is exit. > > BUG: Bad rss-counter state mm:88007f099300 idx:2 val:3 > > Cc: > Acked-by: Kirill A. Shutemov > Reviewed-by: Andrea Arcangeli > Signed-off-by: Minchan Kim > --- > Hello Greg, > > This patch should go to -stable but when you will apply it > after merging of linus tree, it will be surely conflicted due > to userfaultfd part. > > I want to know how to handle it. You will get an automated email saying it didn't apply and then you provide a backported version. Or you send a properly backported version to sta...@vger.kernel.org before then, with the git commit id of the patch in Linus's tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: wilc1000: remove WILC1000_DYNAMICALLY_ALLOCATE_MEMROY
On Sat, Oct 10, 2015 at 03:41:54PM +0300, Stanislav Kholmanskikh wrote: > The config option in the subject may be removed, because, > indeed, it only serves as the 'n' value for > CONFIG_WILC1000_PREALLOCATE_AT_LOADING_DRIVER > > Signed-off-by: Stanislav Kholmanskikh > --- > drivers/staging/wilc1000/Kconfig | 15 ++- > drivers/staging/wilc1000/Makefile | 3 --- > 2 files changed, 2 insertions(+), 16 deletions(-) > > diff --git a/drivers/staging/wilc1000/Kconfig > b/drivers/staging/wilc1000/Kconfig > index 59ccecc..2701a01 100644 > --- a/drivers/staging/wilc1000/Kconfig > +++ b/drivers/staging/wilc1000/Kconfig > @@ -6,27 +6,16 @@ config WILC1000 > ---help--- > This module only support IEEE 802.11n WiFi. > > -choice > -prompt "Memory Allocation" > -depends on WILC1000 > -default WILC1000_PREALLOCATE_AT_LOADING_DRIVER > - > config WILC1000_PREALLOCATE_AT_LOADING_DRIVER > bool "Preallocate memory at loading driver" > + depends on WILC1000 > + default y Hm, why have this now? Both of these options should go away, please work on fixing up the code to not need them and then delete the options, right now you are just deleting config options which doesn't seem wise. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi: advansys needs ISA dma api for ISA support
On 10/12/2015 05:10 PM, Arnd Bergmann wrote:
> The advansys drvier uses the request_dma function that is used on ISA
> machines for the internal DMA controller, which causes build errors
> on platforms that have ISA slots but do not provide the ISA DMA API:
>
> drivers/scsi/advansys.c: In function 'advansys_board_found':
> drivers/scsi/advansys.c:11300:10: error: implicit declaration of function
> 'request_dma' [-Werror=implicit-function-declaration]
>
> The problem now showed up in ARM randconfig builds after commit
> 6571fb3f8b7f ("advansys: Update to version 3.5 and remove compilation
> warning") made it possible to build on platforms that have neither
> VIRT_TO_BUS nor ISA_DMA_API but that do have ISA.
>
> This adds the missing dependency.
>
> Signed-off-by: Arnd Bergmann
>
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index d2f480b04a52..d4aa6a1a806c 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -499,6 +499,7 @@ config SCSI_ADVANSYS
> tristate "AdvanSys SCSI support"
> depends on SCSI
> depends on ISA || EISA || PCI
> + depends on ISA_DMA_API || !ISA
> help
> This is a driver for all SCSI host adapters manufactured by
> AdvanSys. It is documented in the kernel source in
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: Move IIO Dummy Driver out of staging
On 12 October 2015 18:59:57 BST, Daniel Baluta wrote: > > >>> +static unsigned instances = 1; >>> +module_param(instances, uint, 0); > >One concern about this. We will still create a default number of >'instances' >when using configuration via configfs? > >I'm not sure we can remove this parameter once the module is moved >out of staging, since we break the ABI (?) I'm not that bothered about ABI breakage on this one. Not going to break anything real after all! > >The rest looks good to me. I'm pretty sure that moving this out of >staging >will make the module more visible and people will jump with >enhancements. > > >thanks, >Daniel >-- >To unsubscribe from this list: send the line "unsubscribe linux-iio" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3-rc3 BAR allocation problems on multiple machines
On Mon, Oct 12, 2015 at 10:06 PM, Meelis Roos wrote: >> >> > sparc64 machines: >> >> >> >> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git >> >> for-pci-v4.4-next >> >> >> >> It should fix some "no compatible bridge window" >> > >> > Blade 100: still has 2 address conflicts: >> > http://kodu.ut.ee/~mroos/dm/dm.sb100+patch >> > >> > V240: still has a lot of address conflicts: >> > http://kodu.ut.ee/~mroos/dm/dm.v240+patch >> > >> > V210: fixes the line >> > pci 0001:00:07.0: can't claim BAR 0 [io 0x7fe0100-0x7fe0100]: >> > address conflict with 0001:00:06.0 [io 0x7fe01000600-0x7fe0100061f] >> > >> > These lines are still present: >> > >> > pci 0001:00:07.0: can't claim BAR 1 [mem 0x7ff-0x7ff000f]: >> > address conflict with Video RAM area [??? 0x7ff000a-0x7ff000b >> > flags 0x8000] >> > pci 0001:00:07.0: can't claim BAR 2 [mem 0x7ff-0x7ff000f]: >> > address conflict with Video RAM area [??? 0x7ff000a-0x7ff000b >> > flags 0x8000] >> > >> you should not have those. >> >> Looks like you are using old branch before 2015-10-05. >> >> If you use the git directly, please update the branch to local again. > > Updated on V210 - the others were more recent. Now I get more BAR > warning there too: > > http://kodu.ut.ee/~mroos/dm/dm.v210+patches > interesting, mem and mem64 is overlapping. [ 38.824625] /pci@1f,70: TOMATILLO PCI Bus Module ver[4:0] [ 38.824654] /pci@1f,70: PCI IO [io 0x7f60100-0x7f601ff] offset 7f60100 [ 38.824680] /pci@1f,70: PCI MEM [mem 0x7f7-0x7f7] offset 7f7 [ 38.824704] /pci@1f,70: PCI MEM64 [mem 0x7f7-0x7f7] offset 7f7 [ 38.826310] PCI: Scanning PBM /pci@1f,70 [ 38.826479] schizo f0069c00: PCI host bridge to bus :00 [ 38.826506] pci_bus :00: root bus resource [io 0x7f60100-0x7f601ff] (bus address [0x-0xff]) [ 38.826536] pci_bus :00: root bus resource [mem 0x7f7-0x7f7] (bus address [0x-0x]) [ 38.826565] pci_bus :00: root bus resource [mem 0x7f7-0x7f7] (bus address [0x-0x]) We need to add more sanitary checking. Can you send boot log after booting with "debug ignore_loglevel ofpci_debug=1" ? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] staging: rtl8188eu: bugfix: correct channels range is set in Hal_ReadTxPowerInfo88E
On Sat, Oct 10, 2015 at 01:27:00PM +0700, Ivan Safonov wrote: > Correct channels range is 1..14 (numbering from 1) but not 0..13. Why? Have you tested this? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 1/2] staging: rtl8192u: r8192U_core: add temporary variables to keep lines under 80 characters
On Sun, Oct 04, 2015 at 06:55:57PM -0400, Raphaël Beamonte wrote:
> Add some temporary variables to reduce line length under the maximum
> of 80 characters, as per the kernel code style.
>
> Signed-off-by: Raphaël Beamonte
> ---
> drivers/staging/rtl8192u/r8192U_core.c | 130
> ++---
> 1 file changed, 88 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 28b54ba..e67be02 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -171,6 +171,7 @@ static void rtl819x_set_channel_map(u8 channel_plan,
> struct r8192_priv *priv)
> {
> int i, max_chan = -1, min_chan = -1;
> struct ieee80211_device *ieee = priv->ieee80211;
> + struct CHANNEL_LIST *cl;
>
> switch (channel_plan) {
> case COUNTRY_CODE_FCC:
> @@ -194,15 +195,18 @@ static void rtl819x_set_channel_map(u8 channel_plan,
> struct r8192_priv *priv)
>"unknown rf chip, can't set channel map in
> function:%s()\n",
>__func__);
> }
> - if (ChannelPlan[channel_plan].Len != 0) {
> + cl = &ChannelPlan[channel_plan];
> + if (cl->Len != 0) {
> /* Clear old channel map */
> memset(GET_DOT11D_INFO(ieee)->channel_map, 0,
> sizeof(GET_DOT11D_INFO(ieee)->channel_map));
> /* Set new channel map */
> - for (i = 0; i < ChannelPlan[channel_plan].Len; i++) {
> - if (ChannelPlan[channel_plan].Channel[i] <
> min_chan || ChannelPlan[channel_plan].Channel[i] > max_chan)
> + for (i = 0; i < cl->Len; i++) {
> + u8 chan = cl->Channel[i];
> +
> + if (chan < min_chan || chan > max_chan)
> break;
> -
> GET_DOT11D_INFO(ieee)->channel_map[ChannelPlan[channel_plan].Channel[i]] = 1;
> + GET_DOT11D_INFO(ieee)->channel_map[chan] = 1;
> }
> }
> break;
> @@ -1649,9 +1653,11 @@ short rtl8192_tx(struct net_device *dev, struct
> sk_buff *skb)
> &zero, 0, tx_zero_isr, dev);
> status = usb_submit_urb(tx_urb_zero, GFP_ATOMIC);
> if (status) {
> + int idx = tcb_desc->queue_index;
> +
> RT_TRACE(COMP_ERR,
>"Error TX URB for zero byte %d, error
> %d",
> -
> atomic_read(&priv->tx_pending[tcb_desc->queue_index]),
> + atomic_read(&priv->tx_pending[idx]),
No need to create a whole new variable when you only use it once.
>status);
> return -1;
> }
> @@ -1863,7 +1869,9 @@ static void rtl8192_qos_activate(struct work_struct
> *work)
>*/
> for (i = 0; i < QOS_QUEUE_NUM; i++) {
> /* Mode G/A: slotTimeTimer = 9; Mode B: 20 */
> - u1bAIFS = qos_parameters->aifs[i] * ((mode & (IEEE_G |
> IEEE_N_24G)) ? 9 : 20) + aSifsTime;
> + int slotTimeTimer = ((mode & (IEEE_G | IEEE_N_24G)) ? 9 : 20);
> +
> + u1bAIFS = qos_parameters->aifs[i] * slotTimeTimer + aSifsTime;
Same here, you only used this once, if you just don't like the
formatting, change that, but don't create a variable that is only used
once please.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] staging: rtl8188eu: 5 GHz channel groups removed from /hal/rtl8188e_hal_init.c
On Sat, Oct 10, 2015 at 01:23:13PM +0700, Ivan Safonov wrote: > Unnecessary channel groups for 5 GHz removed from Hal_GetChnlGroup88E > and it transformed to pretty get_channel_group(const u8 channel). > > Also removed code for 5 GHz frequency in Hal_ReadPowerValueFromPROM_8188E. Why did you do two different things in this patch? Have you tested this? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] staging: rtl8188eu: BITn macro replaced by BIT(n) in hal/rtl8188e_hal_init.c
On Sat, Oct 10, 2015 at 01:28:34PM +0700, Ivan Safonov wrote: > This patch replace BITn macro to BIT(n). Why? Have you deleted the BITn macros? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] Staging: rtl8712: Use ether_addr_equal() over memcmp()
On Tue, Oct 13, 2015 at 12:19:12AM +0530, punit vara wrote:
> On Tue, Oct 13, 2015 at 12:16 AM, Punit Vara wrote:
> > This patch is to the rtl871x_ioctl_linux.c file that fixes up following
> > warning reported by checkpatch.pl :
> >
> > -Prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp()
> >
> > bssid and pnetwork->network.MacAddress both are 6 byte
> > array which aligned with u16
> >
> > Signed-off-by: Punit Vara
> > ---
> > drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > index 143be0f..b19556a 100644
> > --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > @@ -2008,7 +2008,7 @@ static int r871x_get_ap_info(struct net_device *dev,
> > return -EINVAL;
> > }
> > netdev_info(dev, "r8712u: BSSID:%pM\n", bssid);
> > - if (!memcmp(bssid, pnetwork->network.MacAddress, ETH_ALEN))
> > {
> > + if (ether_addr_equal(bssid, pnetwork->network.MacAddress)) {
> > /* BSSID match, then check if supporting wpa/wpa2 */
> > pbuf = r8712_get_wpa_ie(&pnetwork->network.IEs[12],
> >&wpa_ielen, pnetwork->network.IELength-12);
> > --
> > 2.5.3
> >
>
> I have updated the patch as per feedback from various developers. As I
> am sending second time subject should be patch v2 right ?
Please resend the whole series please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/2] arm64: kvm: allows kvm cpu hotplug
On 10/12/2015 10:28 PM, James Morse wrote:
On 29/05/15 06:38, AKASHI Takahiro wrote:
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents, especially, kexec from rebooting the system on a boot
core in EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need arm64-specific cpu hotplug hook any more.
I think we do... on platforms where cpuidle uses psci to temporarily turn
off cores that aren't in use, we lose the el2 state. This hotplug hook
restores the state, even if there a no vms running.
If I understand you correctly, with or without my patch, kvm doesn't work
under cpuidle anyway. Right?
If so, saving/restoring cpu states (or at least, kicking cpu hotplug hooks)
is cpuidle driver's responsibility, isn't it?
-Takahiro AKASHI
This patch prevents me from running vms on such a platform, qemu gives:
kvm [1500]: Unsupported exception type: 6264688KVM internal error.
Suberror: 0
kvmtool goes with a more dramatic:
KVM exit reason: 17 ("KVM_EXIT_INTERNAL_ERROR")
Disabling CONFIG_ARM_CPUIDLE solves this problem.
(Sorry to revive an old thread - I've been using v4 of this patch for the
hibernate/suspend-to-disk series).
Since this patch modifies common part of code between arm and arm64, one
stub definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compiling errors.
Signed-off-by: AKASHI Takahiro
diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index fd085ec..afe6263 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -1136,6 +1136,11 @@ ENTRY(kvm_call_hyp)
ret
ENDPROC(kvm_call_hyp)
+ENTRY(kvm_call_reset)
+ hvc #HVC_RESET
+ ret
+ENDPROC(kvm_call_reset)
+
.macro invalid_vector label, target
.align 2
\label:
@@ -1179,10 +1184,27 @@ el1_sync: //
Guest trapped into EL2
cmp x18, #HVC_GET_VECTORS
b.ne1f
mrs x0, vbar_el2
- b 2f
-
-1: /* Default to HVC_CALL_HYP. */
+ b do_eret
+ /* jump into trampoline code */
+1: cmp x18, #HVC_RESET
+ b.ne2f
+ /*
+* Entry point is:
+* TRAMPOLINE_VA
+* + (__kvm_hyp_reset - (__hyp_idmap_text_start & PAGE_MASK))
+*/
+ adrpx2, __kvm_hyp_reset
+ add x2, x2, #:lo12:__kvm_hyp_reset
+ adrpx3, __hyp_idmap_text_start
+ add x3, x3, #:lo12:__hyp_idmap_text_start
+ and x3, x3, PAGE_MASK
+ sub x2, x2, x3
+ ldr x3, =TRAMPOLINE_VA
+ add x2, x2, x3
+ br x2 // no return
+
+2: /* Default to HVC_CALL_HYP. */
What was the reason not to use kvm_call_hyp(__kvm_hyp_reset, ...)?
(You mentioned you wanted to at [0] - I can't find the details in the archive)
Thanks,
James
[0] http://lists.infradead.org/pipermail/kexec/2015-April/335533.html
pushlr, xzr
/*
@@ -1196,7 +1218,9 @@ el1_sync: // Guest
trapped into EL2
blr lr
pop lr, xzr
-2: eret
+
+do_eret:
+ eret
el1_trap:
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices
On embedded devices, often there is a combination of
removable mmc devices (e.g. MMC/SD cards) and hard
wired ones (e.g. eMMC). Depending on the hardware
configuration, the 'mmcblkN' node might change if
the removable device is available or not at boot time.
E.g. if the removable device is attached at boot time,
it might become mmxblk0. And the hard wired one mmcblk1.
But if the removable device isn't there at boot time,
the hard wired one will become mmcblk0. This makes it
somehow difficult to hard code the root device to the
non-removable device and boot fast.
Signed-off-by: Heiko Schocher
---
Dirk Behme tried to bring this in, last mail I found:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
where Dirk worked in Arnds suggestion to use the
"/aliases" device node"
I adapt this to the omap_hsmmc driver.
Is there another solution for this problem?
Or why was this patch not accepted to mainline?
drivers/mmc/card/block.c | 6 --
drivers/mmc/host/omap_hsmmc.c | 6 ++
include/linux/mmc/host.h | 3 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c742cfd..62250d8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2106,7 +2106,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
struct mmc_blk_data *md;
int devidx, ret;
- devidx = find_first_zero_bit(dev_use, max_devices);
+ devidx = find_next_zero_bit(dev_use, max_devices,
+ card->host->devidx);
if (devidx >= max_devices)
return ERR_PTR(-ENOSPC);
__set_bit(devidx, dev_use);
@@ -2124,7 +2125,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
* index anymore so we keep track of a name index.
*/
if (!subname) {
- md->name_idx = find_first_zero_bit(name_use, max_devices);
+ md->name_idx = find_next_zero_bit(name_use, max_devices,
+ card->host->devidx);
__set_bit(md->name_idx, name_use);
} else
md->name_idx = ((struct mmc_blk_data *)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7fb0753..0b45b48 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2059,6 +2059,12 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->pbias_enabled = 0;
host->vqmmc_enabled = 0;
+ if (pdev->dev.of_node) {
+ ret = of_alias_get_id(pdev->dev.of_node, "mmcblk");
+ if (ret >= 0)
+ host->mmc->devidx = ret;
+ }
+
ret = omap_hsmmc_gpio_init(mmc, host, pdata);
if (ret)
goto err_gpio;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 83b81fd..4f071681 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -382,6 +382,9 @@ struct mmc_host {
int dsr_req;/* DSR value is valid */
u32 dsr;/* optional driver stage (DSR) value */
+ /* preferred mmc block device index (mmcblkX) */
+ unsigned intdevidx;
+
unsigned long private[0] cacheline_aligned;
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH Resend] cpufreq: Drop redundant check for inactive policies
We just made sure policy->cpu is online and this check will always fail
as the policy is active. Drop it.
Signed-off-by: Viresh Kumar
Acked-by: Saravana Kannan
---
Resending as a separate patch.
drivers/cpufreq/cpufreq.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 58aabe0f2d2c..4fa2215cc6ec 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -843,18 +843,11 @@ static ssize_t store(struct kobject *kobj, struct
attribute *attr,
down_write(&policy->rwsem);
- /* Updating inactive policies is invalid, so avoid doing that. */
- if (unlikely(policy_is_inactive(policy))) {
- ret = -EBUSY;
- goto unlock_policy_rwsem;
- }
-
if (fattr->store)
ret = fattr->store(policy, buf, count);
else
ret = -EIO;
-unlock_policy_rwsem:
up_write(&policy->rwsem);
unlock:
put_online_cpus();
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block-mq:Fix the null memory access while setting tags cpumask
In nr_hw_queues >1 cases when certain number of cpus are onlined/or
offlined, that results change in request_queue map in block-mq layer,
we see the kernel dumping like:
BUG: unable to handle kernel NULL pointer dereference at 0080
IP: [] cpumask_set_cpu+0x6/0xd
PGD 6d957067 PUD 7604c067 PMD 0
Oops: 0002 [#1] SMP
Modules linked in: null_blk
CPU: 2 PID: 1926 Comm: bash Not tainted 4.3.0-rc2+ #24
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: 8800724cd1c0 ti: 880070a2c000 task.ti: 880070a2c000
RIP: 0010:[] [] cpumask_set_cpu+0x6/0xd
RSP: 0018:880070a2fbc8 EFLAGS: 00010203
RAX: 880073eedc00 RBX: 88006cc88000 RCX: 88006c06b000
RDX: 0007 RSI: 0080 RDI: 0008
RBP: 880070a2fbc8 R08: 88006c06ac00 R09: 88006c06ad48
R10: 88004ea8 R11: 88006c069650 R12: 88007378fe28
R13: 0008 R14: e8500200 R15: 81d2a630
FS: 7fa34803b700() GS:88007cc4() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0080 CR3: 761d2000 CR4: 06e0
Stack:
880070a2fc18 8128edec 880073eedc00
0039 88006cc88000 0007 ffe3
81cef2c0 880070a2fc38 8129049a
Call Trace:
[] blk_mq_map_swqueue+0x9d/0x206
[] blk_mq_queue_reinit_notify+0xe3/0x144
[] notifier_call_chain+0x37/0x63
[] __raw_notifier_call_chain+0xe/0x10
[] __cpu_notify+0x20/0x32
[] cpu_notify_nofail+0x13/0x1b
[] _cpu_down+0x18a/0x264
[] ? path_put+0x1f/0x23
[] cpu_down+0x2d/0x3a
[] cpu_subsys_offline+0x14/0x16
[] device_offline+0x65/0x94
[] online_store+0x48/0x68
[] ? kernfs_fop_write+0x6f/0x143
[] dev_attr_store+0x20/0x22
[] sysfs_kf_write+0x3c/0x3e
[] kernfs_fop_write+0xed/0x143
[] __vfs_write+0x28/0xa6
[] ? security_file_permission+0x3c/0x44
[] ? percpu_down_read+0x21/0x42
[] ? __sb_start_write+0x24/0x41
[] vfs_write+0x8d/0xd1
[] SyS_write+0x59/0x83
[] entry_SYSCALL_64_fastpath+0x12/0x71
Code: 03 75 06 65 48 ff 0a eb 1a f0 48 83 af 68 07 00 00 01 74 02 eb 0d 48 8d
bf 68 07 00 00 ff 90 78 07 00 00 5d c3 55 89 ff 48 89 e5 48 0f ab 3e 5d c3
0f 1f 44 00 00 55 8b 4e 44 31 d2 8b b7 94
RIP [] cpumask_set_cpu+0x6/0xd
RSP
CR2: 0080
How to reproduce:
1. create 80 vcpu guest with 10 core 8 threads
2. modprobe null_blk submit_queues=64
3. for i in 72 73 74 75 76 77 78 79 ; do
echo 0 > /sys/devices/system/cpu/cpu$i/online;
done
Reason:
We try to set freed hwctx->tag->cpumask in blk_mq_map_swqueue().
Introduced during commit f26cdc8536ad ("blk-mq: Shared tag enhancements").
What is happening:
When certain number of cpus are onlined/offlined, that results in
blk_mq_update_queue_map, we could potentially end up in new mapping to
hwctx.
Subsequent blk_mq_map_swqueue of request_queue, tries to set the
hwctx->tags->cpumask which is already freed by blk_mq_free_rq_map in
earlier itearation when it was not mapped.
Fix:
Set the hwctx->tags->cpumask only after blk_mq_init_rq_map() is done
hwctx->tags->cpumask does not follow the hwctx->cpumask after new
mapping even in the cases where new mapping does not cause problem.
That is also fixed with this change.
This problem is originally found in powervm which had 160 cpus (SMT8),
128 nr_hw_queues. The dump was easily reproduced with offlining last core
and it has been a blocker issue because cpu hotplug is a common case for
DLPAR.
Signed-off-by: Raghavendra K T
---
block/blk-mq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index f2d67b4..39a7834 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1811,7 +1811,6 @@ static void blk_mq_map_swqueue(struct request_queue *q)
hctx = q->mq_ops->map_queue(q, i);
cpumask_set_cpu(i, hctx->cpumask);
- cpumask_set_cpu(i, hctx->tags->cpumask);
ctx->index_hw = hctx->nr_ctx;
hctx->ctxs[hctx->nr_ctx++] = ctx;
}
@@ -1836,6 +1835,7 @@ static void blk_mq_map_swqueue(struct request_queue *q)
if (!set->tags[i])
set->tags[i] = blk_mq_init_rq_map(set, i);
hctx->tags = set->tags[i];
+ cpumask_copy(hctx->tags->cpumask, hctx->cpumask);
WARN_ON(!hctx->tags);
/*
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] Produce system time from correlated clocksource
On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote:
> +int get_correlated_timestamp(struct correlated_ts *crt,
> + struct correlated_cs *crs)
> +{
> + struct timekeeper *tk = &tk_core.timekeeper;
> + unsigned long seq;
> + cycles_t cycles, cycles_now, cycles_last;
> + ktime_t base;
> + s64 nsecs;
> + int ret;
> +
> + do {
> + seq = read_seqcount_begin(&tk_core.seq);
> + /*
> + * Verify that the correlated clocksoure is related to
> + * the currently installed timekeeper clocksoure
> + */
> + if (tk->tkr_mono.clock != crs->related_cs)
> + return -ENODEV;
> +
> + /*
> + * Get a timestamp from the device if get_ts is non-NULL
> + */
> + if( crt->get_ts ) {
CodingStyle.
> + ret = crt->get_ts(crt);
> + if (ret)
> + return ret;
> + }
> +
> + /*
> + * Convert the timestamp to timekeeper clock cycles
> + */
> + cycles = crs->convert(crs, crt->system_ts);
> +
> + /*
> + * If we have get_ts is valid, we know the cycles value
> + * value is up to date and we can just do the conversion
> + */
> + if( crt->get_ts )
Ditto.
> + goto do_convert;
> +
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Foundation Technical Advisory Board Elections and Nomination process
On Tue, Oct 6, 2015 at 3:06 AM, Grant Likely wrote: > [Resending because I messed up the first one] > > The elections for five of the ten members of the Linux Foundation > Technical Advisory Board (TAB) are held every year[1]. This year the > election will be at the 2015 Kernel Summit in Seoul, South Korea > (probably on the Monday, 26 October) and will be open to all attendees > of both Kernel Summit and Korea Linux Forum. > > Anyone is eligible to stand for election, simply send your nomination to: > > tech-board-disc...@lists.linux-foundation.org > > We currently have 3 nominees for five places: > Thomas Gleixner > Greg Kroah-Hartman > Stephen Hemminger I'd like to nominate myself to stand for a place on the TAB. I'll be physically at Kernel Summit. Thanks! -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/vmwgfx: switch from ioremap_cache to memremap
Hi!
On 10/13/2015 12:35 AM, Dan Williams wrote:
> Per commit 2e586a7e017a "drm/vmwgfx: Map the fifo as cached" the driver
> expects the fifo registers to be cacheable. In preparation for
> deprecating ioremap_cache() convert its usage in vmwgfx to memremap().
>
> Cc: David Airlie
> Cc: Thomas Hellstrom
> Cc: Sinclair Yeh
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Dan Williams
While I have nothing against the conversion, what's stopping the
compiler from reordering writes on a generic architecture and caching
and reordering reads on x86 in particular? At the very least it looks to
me like the memory accesses of the memremap'd memory needs to be
encapsulated within READ_ONCE and WRITE_ONCE.
How is this handled in the other conversions?
Thanks,
Thomas
> ---
>
> This is part of the tree-wide conversion of ioremap_cache() to
> memremap() targeted for v4.4 [1]
>
> As noted in that cover letter feel free to apply or ack. These
> individual conversions can go in independently given the base memremap()
> implementation is already upstream in v4.3-rc1.
>
> This passes a clean run of sparse, but I have not tried to run the
> result.
>
> [1]:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2015_10_9_699&d=BQICaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=XuVtQ3_28jin5hdK6wBcLigEiRc-1TuelYa3zm94m44&s=kN3-2XStWWU0f20wNGpmQiwZTTiBBzwD4LShvfokwkQ&e=
>
>
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |8 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 -
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 23 ---
> drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 102
> -
> drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |9 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_irq.c |8 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 24
> 7 files changed, 84 insertions(+), 92 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 2c7a25c71af2..d6152cd7c634 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -752,8 +752,8 @@ static int vmw_driver_load(struct drm_device *dev,
> unsigned long chipset)
> ttm_lock_set_kill(&dev_priv->fbdev_master.lock, false, SIGTERM);
> dev_priv->active_master = &dev_priv->fbdev_master;
>
> - dev_priv->mmio_virt = ioremap_cache(dev_priv->mmio_start,
> - dev_priv->mmio_size);
> + dev_priv->mmio_virt = memremap(dev_priv->mmio_start,
> +dev_priv->mmio_size, MEMREMAP_WB);
>
> if (unlikely(dev_priv->mmio_virt == NULL)) {
> ret = -ENOMEM;
> @@ -907,7 +907,7 @@ out_no_irq:
> out_no_device:
> ttm_object_device_release(&dev_priv->tdev);
> out_err4:
> - iounmap(dev_priv->mmio_virt);
> + memunmap(dev_priv->mmio_virt);
> out_err3:
> vmw_ttm_global_release(dev_priv);
> out_err0:
> @@ -958,7 +958,7 @@ static int vmw_driver_unload(struct drm_device *dev)
> pci_release_regions(dev->pdev);
>
> ttm_object_device_release(&dev_priv->tdev);
> - iounmap(dev_priv->mmio_virt);
> + memunmap(dev_priv->mmio_virt);
> if (dev_priv->ctx.staged_bindings)
> vmw_binding_state_free(dev_priv->ctx.staged_bindings);
> vmw_ttm_global_release(dev_priv);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index f19fd39b43e1..7ff1db23de80 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -375,7 +375,7 @@ struct vmw_private {
> uint32_t stdu_max_height;
> uint32_t initial_width;
> uint32_t initial_height;
> - u32 __iomem *mmio_virt;
> + u32 *mmio_virt;
> uint32_t capabilities;
> uint32_t max_gmr_ids;
> uint32_t max_gmr_pages;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> index 567ddede51d1..97f75adc080d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> @@ -141,9 +141,9 @@ static bool vmw_fence_enable_signaling(struct fence *f)
>
> struct vmw_fence_manager *fman = fman_from_fence(fence);
> struct vmw_private *dev_priv = fman->dev_priv;
> + u32 *fifo_mem = dev_priv->mmio_virt;
> + u32 seqno = *(fifo_mem + SVGA_FIFO_FENCE);
>
> - u32 __iomem *fifo_mem = dev_priv->mmio_virt;
> - u32 seqno = ioread32(fifo_mem + SVGA_FIFO_FENCE);
> if (seqno - fence->base.seqno < VMW_FENCE_WRAP)
> return false;
>
>
Here, for example.
/Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] leds: leds-gpio: add shutdown function
add a shutdown function for setting the gpio-leds
into off state when shuting down.
Signed-off-by: Heiko Schocher
---
drivers/leds/leds-gpio.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index af1876a..5db4515 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -291,9 +291,22 @@ static int gpio_led_remove(struct platform_device *pdev)
return 0;
}
+static void gpio_led_shutdown(struct platform_device *pdev)
+{
+ struct gpio_leds_priv *priv = platform_get_drvdata(pdev);
+ int i;
+
+ for (i = 0; i < priv->num_leds; i++) {
+ struct gpio_led_data *led = &priv->leds[i];
+
+ gpio_led_set(&led->cdev, LED_OFF);
+ }
+}
+
static struct platform_driver gpio_led_driver = {
.probe = gpio_led_probe,
.remove = gpio_led_remove,
+ .shutdown = gpio_led_shutdown,
.driver = {
.name = "leds-gpio",
.of_match_table = of_gpio_leds_match,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers
On 10/12/15 9:34 PM, Wangnan (F) wrote:
On 2015/10/13 12:16, Alexei Starovoitov wrote:
On 10/12/15 8:51 PM, Wangnan (F) wrote:
why 'set disable' is needed ?
the example given in cover letter shows the use case where you want
to receive samples only within sys_write() syscall.
The example makes sense, but sys_write() is running on this cpu, so
just
disabling it on the current one is enough.
Our real use case is control of the system-wide sampling. For example,
we need sampling all CPUs when smartphone start refershing its display.
We need all CPUs because in Android system there are plenty of threads
get involed into this behavior. We can't achieve this by controling
sampling on only one CPU. This is the reason we need 'set enable'
and 'set disable'.
ok, but that use case may have different enable/disable pattern.
In sys_write example ultra-fast enable/disable is must have, since
the whole syscall is fast and overhead should be minimal.
but for display refresh? we're talking milliseconds, no?
Can you just ioctl() it from user space?
If cost of enable/disable is high or the time range between toggling is
long, then doing it from the bpf program doesn't make sense. Instead
the program can do bpf_perf_event_output() to send a notification to
user space that condition is met and the user space can ioctl() events.
OK. I think I understand your design principle that, everything inside BPF
should be as fast as possible.
Make userspace control events using ioctl make things harder. You know that
'perf record' itself doesn't care too much about events it reveived. It
only
copies data to perf.data, but what we want is to use perf record simply
like
this:
# perf record -e evt=cycles -e control.o/pmu=evt/ -a sleep 100
And in control.o we create uprobe point to mark the start and finish of
a frame:
SEC("target=/a/b/c.o\nstartFrame=0x123456")
int startFrame(void *) {
bpf_pmu_enable(pmu);
return 1;
}
SEC("target=/a/b/c.o\nfinishFrame=0x234568")
int finishFrame(void *) {
bpf_pmu_disable(pmu);
return 1;
}
I think it is make sence also.
yes. that looks quite useful,
but did you consider re-entrant startFrame() ?
start << here sampling starts
start
finish << here all samples disabled?!
finish
and startFrame()/finishFrame() running on all cpus of that user app ?
One cpu entering into startFrame() while another cpu doing finishFrame
what behavior should be? sampling is still enabled on all cpus? or off?
Either case doesn't seem to work with simple enable/disable.
Few emails in this thread back, I mentioned inc/dec of a flag
to solve that.
What about using similar
implementation
like PERF_EVENT_IOC_SET_OUTPUT, creating a new ioctl like
PERF_EVENT_IOC_SET_ENABLER,
then let perf to select an event as 'enabler', then BPF can still
control one atomic
variable to enable/disable a set of events.
you lost me on that last sentence. How this 'enabler' will work?
Also I'm still missing what's wrong with perf doing ioctl() on
events on all cpus manually when bpf program tells it to do so.
Is it speed you concerned about or extra work in perf ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: phy: smsc: disable energy detect mode
On some boards the energy enable detect mode leads in
trouble with some switches, so make the enabling of
this mode configurable through DT.
Signed-off-by: Heiko Schocher
---
.../devicetree/bindings/net/smsc-lan87xx.txt | 19 +
drivers/net/phy/smsc.c | 24 +-
2 files changed, 38 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/smsc-lan87xx.txt
diff --git a/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
new file mode 100644
index 000..39aa1dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
@@ -0,0 +1,19 @@
+SMSC LAN87xx Ethernet PHY
+
+Some boards require special tuning values. Configure them
+through an Ethernet OF device node.
+
+Optional properties:
+
+- disable-energy-detect:
+ If set, do not enable energy detect mode for the SMSC phy.
+ default: enable energy detect mode
+
+Examples:
+
+ /* Attach to an Ethernet device with autodetected PHY */
+ &cpsw_emac0 {
+ phy_id = <&davinci_mdio>, <0>;
+ phy-mode = "mii";
+ disable-energy-detect;
+ };
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index 70b0895..f90fbf3 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -43,16 +43,30 @@ static int smsc_phy_ack_interrupt(struct phy_device *phydev)
static int smsc_phy_config_init(struct phy_device *phydev)
{
+#ifdef CONFIG_OF
+ int len;
+ struct device *dev = &phydev->dev;
+ struct device_node *of_node = dev->of_node;
+#endif
int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+ int enable_energy = 1;
if (rc < 0)
return rc;
- /* Enable energy detect mode for this SMSC Transceivers */
- rc = phy_write(phydev, MII_LAN83C185_CTRL_STATUS,
- rc | MII_LAN83C185_EDPWRDOWN);
- if (rc < 0)
- return rc;
+#ifdef CONFIG_OF
+ if (!of_node && dev->parent->of_node)
+ of_node = dev->parent->of_node;
+ if (of_find_property(of_node, "disable-energy-detect", &len))
+ enable_energy = 0;
+#endif
+ if (enable_energy) {
+ /* Enable energy detect mode for this SMSC Transceivers */
+ rc = phy_write(phydev, MII_LAN83C185_CTRL_STATUS,
+ rc | MII_LAN83C185_EDPWRDOWN);
+ if (rc < 0)
+ return rc;
+ }
return smsc_phy_ack_interrupt(phydev);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
videobuf2-core.c:undefined reference to `__tracepoint_vb2_buf_queue'
Hi Philipp, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 25cb62b76430a91cc6195f902e61c2cb84ade622 commit: 2091f5181c66b3617a977e79843aba10e087be6c [media] videobuf2: add trace events date: 3 months ago config: i386-randconfig-x0-10131131 (attached as .config) reproduce: git checkout 2091f5181c66b3617a977e79843aba10e087be6c # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/built-in.o: In function `sur40_vidioc_querycap': sur40.c:(.text+0x1ba910): undefined reference to `video_devdata' drivers/built-in.o: In function `sur40_poll': sur40.c:(.text+0x1bb0b2): undefined reference to `v4l2_get_timestamp' drivers/built-in.o: In function `sur40_probe': sur40.c:(.text+0x1bb67b): undefined reference to `v4l2_device_register' sur40.c:(.text+0x1bb69b): undefined reference to `v4l2_device_unregister' sur40.c:(.text+0x1bb86e): undefined reference to `video_device_release_empty' sur40.c:(.text+0x1bb896): undefined reference to `__video_register_device' sur40.c:(.text+0x1bb920): undefined reference to `video_unregister_device' drivers/built-in.o: In function `sur40_disconnect': sur40.c:(.text+0x1bb949): undefined reference to `video_unregister_device' sur40.c:(.text+0x1bb951): undefined reference to `v4l2_device_unregister' drivers/built-in.o: In function `__enqueue_in_driver': >> videobuf2-core.c:(.text+0x1be4d0): undefined reference to >> `__tracepoint_vb2_buf_queue' drivers/built-in.o: In function `vb2_buffer_done': >> (.text+0x1bef80): undefined reference to `__tracepoint_vb2_buf_done' drivers/built-in.o: In function `vb2_fop_mmap': (.text+0x1bf2cf): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_internal_dqbuf': >> videobuf2-core.c:(.text+0x1bff38): undefined reference to >> `__tracepoint_vb2_dqbuf' drivers/built-in.o: In function `vb2_ioctl_querybuf': (.text+0x1c053c): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_create_bufs': (.text+0x1c15f9): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_reqbufs': (.text+0x1c23c9): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_streamoff': (.text+0x1c25b9): undefined reference to `video_devdata' drivers/built-in.o: In function `_vb2_fop_release': (.text+0x1c26d9): undefined reference to `video_devdata' drivers/built-in.o: In function `_vb2_fop_release': (.text+0x1c2702): undefined reference to `v4l2_fh_release' drivers/built-in.o: In function `vb2_fop_release': (.text+0x1c275c): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_streamon': (.text+0x1c29d9): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_prepare_buf': (.text+0x1c2b39): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_internal_qbuf': >> videobuf2-core.c:(.text+0x1c2cf8): undefined reference to >> `__tracepoint_vb2_qbuf' drivers/built-in.o: In function `vb2_poll': (.text+0x1c32b8): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_poll': (.text+0x1c3449): undefined reference to `v4l2_event_pending' drivers/built-in.o: In function `vb2_fop_poll': (.text+0x1c362b): undefined reference to `video_devdata' drivers/built-in.o: In function `__vb2_perform_fileio': videobuf2-core.c:(.text+0x1c3e07): undefined reference to `v4l2_get_timestamp' drivers/built-in.o: In function `vb2_fop_write': (.text+0x1c412d): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_fop_read': (.text+0x1c425d): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_thread': videobuf2-core.c:(.text+0x1c45e7): undefined reference to `v4l2_get_timestamp' drivers/built-in.o: In function `vb2_ioctl_qbuf': (.text+0x1c4709): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_dqbuf': (.text+0x1c48af): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_expbuf': (.text+0x1c4bc9): undefined reference to `video_devdata' drivers/built-in.o:(.rodata+0x2a7b0): undefined reference to `video_ioctl2' drivers/built-in.o:(.rodata+0x2a7bc): undefined reference to `v4l2_fh_open' drivers/built-in.o:(__jump_table+0x4dc): undefined reference to `__tracepoint_vb2_buf_queue' drivers/built-in.o:(__jump_table+0x4e8): undefined reference to `__tracepoint_vb2_buf_done' drivers/built-in.o:(__jump_table+0x4f4): undefined reference to `__tracepoint_vb2_dqbuf' drivers/built-in.o:(__jump_table+0x500): undefined reference to `__tracepoint_vb2_qbuf' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbui
[PATCH] rtc: pcf8563: disable CLKOUT
Disable the CLKOUT of the RTC after power-up.
After power-up/reset of the RTC, CLKOUT is enabled by default,
with CLKOUT enabled the RTC chip has 2-3 times higher power
consumption. If you do not need CLKOUT, you can disable the
CLKOUT with setting "disable-clkout" property.
Signed-off-by: Heiko Schocher
---
Documentation/devicetree/bindings/rtc/pcf8563.txt | 22 ++
drivers/rtc/rtc-pcf8563.c | 37 +++
2 files changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/pcf8563.txt
diff --git a/Documentation/devicetree/bindings/rtc/pcf8563.txt
b/Documentation/devicetree/bindings/rtc/pcf8563.txt
new file mode 100644
index 000..36f49e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/pcf8563.txt
@@ -0,0 +1,22 @@
+* Philips PCF8563/Epson RTC8564 Real Time Clock
+
+Philips PCF8563/Epson RTC8564 Real Time Clock
+
+Required properties:
+see: Documentation/devicetree/bindings/i2c/trivial-devices.txt
+
+Optional property:
+- disable-clkout:
+ disable the CLKOUT of the RTC after power-up.
+ After power-up/reset of the RTC, CLKOUT is enabled by default,
+ with CLKOUT enabled the RTC chip has 2-3 times higher power
+ consumption. If you not need CLKOUT, you can disable the CLKOUT
+ with setting this property.
+
+Example:
+
+pcf8563@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ disable-clkout;
+};
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index e569243..fa9a412 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -53,6 +53,7 @@
#define PCF8563_SC_LV 0x80 /* low voltage */
#define PCF8563_MO_C 0x80 /* century */
+#define PCF8563_CLKOUT 0x80 /* CLKOUT */
static struct i2c_driver pcf8563_driver;
@@ -74,6 +75,7 @@ struct pcf8563 {
*/
int c_polarity; /* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */
int voltage_low; /* incicates if a low_voltage was detected */
+ int disable_clkout;
struct i2c_client *client;
};
@@ -186,6 +188,33 @@ static irqreturn_t pcf8563_irq(int irq, void *dev_id)
return IRQ_NONE;
}
+static int pcf8563_disable_clkout(struct i2c_client *client)
+{
+ struct pcf8563 *pcf8563 = i2c_get_clientdata(client);
+ unsigned char buf;
+ int err;
+
+ if (!pcf8563->disable_clkout)
+ return 0;
+
+ err = pcf8563_read_block_data(client, PCF8563_REG_CLKO, 1, &buf);
+ if (err)
+ return err;
+
+ if (buf & PCF8563_CLKOUT) {
+ buf = 0x00;
+ dev_warn(&client->dev, "CLKOUT enabled! Disabling it...\n");
+ err = pcf8563_write_block_data(client, PCF8563_REG_CLKO, 1,
+ &buf);
+ if (err < 0)
+ dev_err(&client->dev, "could not disable clock\n");
+ } else {
+ dev_info(&client->dev, "CLKOUT disabled.\n");
+ }
+
+ return 0;
+}
+
/*
* In the routines that deal directly with the pcf8563 hardware, we use
* rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
@@ -235,6 +264,7 @@ static int pcf8563_get_datetime(struct i2c_client *client,
struct rtc_time *tm)
tm->tm_sec, tm->tm_min, tm->tm_hour,
tm->tm_mday, tm->tm_mon, tm->tm_year, tm->tm_wday);
+ pcf8563_disable_clkout(client);
return 0;
}
@@ -406,6 +436,9 @@ static int pcf8563_probe(struct i2c_client *client,
int err;
unsigned char buf;
unsigned char alm_pending;
+#ifdef CONFIG_OF
+ int len;
+#endif
dev_dbg(&client->dev, "%s\n", __func__);
@@ -419,6 +452,10 @@ static int pcf8563_probe(struct i2c_client *client,
dev_info(&client->dev, "chip found, driver version " DRV_VERSION "\n");
+#ifdef CONFIG_OF
+ if (of_find_property(client->dev.of_node, "disable-clkout", &len))
+ pcf8563->disable_clkout = 1;
+#endif
i2c_set_clientdata(client, pcf8563);
pcf8563->client = client;
device_set_wakeup_capable(&client->dev, 1);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3-rc3 BAR allocation problems on multiple machines
> >> > sparc64 machines: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > >> for-pci-v4.4-next > >> > >> It should fix some "no compatible bridge window" > > > > Blade 100: still has 2 address conflicts: > > http://kodu.ut.ee/~mroos/dm/dm.sb100+patch > > > > V240: still has a lot of address conflicts: > > http://kodu.ut.ee/~mroos/dm/dm.v240+patch > > > > V210: fixes the line > > pci 0001:00:07.0: can't claim BAR 0 [io 0x7fe0100-0x7fe0100]: > > address conflict with 0001:00:06.0 [io 0x7fe01000600-0x7fe0100061f] > > > > These lines are still present: > > > > pci 0001:00:07.0: can't claim BAR 1 [mem 0x7ff-0x7ff000f]: > > address conflict with Video RAM area [??? 0x7ff000a-0x7ff000b flags > > 0x8000] > > pci 0001:00:07.0: can't claim BAR 2 [mem 0x7ff-0x7ff000f]: > > address conflict with Video RAM area [??? 0x7ff000a-0x7ff000b flags > > 0x8000] > > > you should not have those. > > Looks like you are using old branch before 2015-10-05. > > If you use the git directly, please update the branch to local again. Updated on V210 - the others were more recent. Now I get more BAR warning there too: http://kodu.ut.ee/~mroos/dm/dm.v210+patches -- Meelis Roos (mr...@linux.ee) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] Produce system time from correlated clocksource
On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > Another representative use case of time sync and the correlated > clocksource (in addition to PTP noted above) is PTP synchronized > audio. The added explanations of the audio use case do help. However, you did not address my point in the last series in any way. > In a streaming application, as an example, samples will be sent > and/or received by multiple devices with a presentation time that is > in terms of the PTP master clock. Synchronizing the audio output on > these devices requires correlating the audio clock with the PTP > master clock. The more precise this correlation is, the better the > audio quality (i.e. out of sync audio sounds bad). This is mega important. You want to convert PTP time into audio clock time. There is no need for the system time at all. > From an application standpoint, to correlate the PTP master clock > with the audio device clock, the system clock is used as a > intermediate timebase. But why involve the system time base? > The transforms such an application would > perform are: > > System Clock <-> Audio clock > System Clock <-> Network Device Clock [<-> PTP Master Clock] This is extra work with no benefit. In fact, this hurts you because of the need to take avoid update_wall_time AND because of the NTP frequency adjustments. Cascaded servos are prone to gain peaking, and this can easily avoided in this case. > Modern Intel platforms can perform a more accurate cross- > timestamp in hardware (ART,audio device clock). The audio driver > requires ART->system time transforms -- the same as required for > the network driver. No, it doesn't need the system time. It only needs the PTP time. > The modification to the original patch accomodates these > slow devices by adding the option of providing an ART value outside > of the retry loop and adding a history which can consulted in the > case of an out of date counter value. The history is kept by > making the shadow_timekeeper an array. Each write to the > timekeeper rotates through the array, preserving a > history of updates. This is all wrong. All you need to provide the DSP with (ART, PTP) pairs. This can be done in a multiple of the DSP period, like every 1, 10, or 100 milliseconds. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'
On Mon, Oct 05, 2015 at 06:03:35PM -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> Which is the most common default found in other similar tools.
I think it's more useful to change the default only when --children is
used. And there's a related issue too - please see below link:
https://lkml.org/lkml/2014/8/14/49
Thanks,
Namhyung
>
> Requested-by: Ingo Molnar
> Cc: Adrian Hunter
> Cc: Borislav Petkov
> Cc: Chandler Carruth
> Cc: David Ahern
> Cc: Frederic Weisbecker
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Cc: Stephane Eranian
> Cc: Wang Nan
> Link: https://www.youtube.com/watch?v=nXaxk27zwlk
> Link: http://lkml.kernel.org/n/tip-v8lq36aispvdwgxdmt9p9...@git.kernel.org
> Signed-off-by: Arnaldo Carvalho de Melo
> ---
> tools/perf/Documentation/perf-report.txt | 2 +-
> tools/perf/builtin-report.c | 4 ++--
> tools/perf/util/util.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf-report.txt
> b/tools/perf/Documentation/perf-report.txt
> index ce499035e6d8..e4fdeeb51123 100644
> --- a/tools/perf/Documentation/perf-report.txt
> +++ b/tools/perf/Documentation/perf-report.txt
> @@ -192,7 +192,7 @@ OPTIONS
> when available. Usually more convenient to use --branch-history
> for this.
>
> - Default: fractal,0.5,callee,function.
> + Default: graph,0.5,caller
>
> --children::
> Accumulate callchain of children to parent entry so that then can
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index b5623639f67d..3b23b25d1589 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -633,7 +633,7 @@ int cmd_report(int argc, const char **argv, const char
> *prefix __maybe_unused)
> bool has_br_stack = false;
> int branch_mode = -1;
> bool branch_call_mode = false;
> - char callchain_default_opt[] = "fractal,0.5,callee";
> + char callchain_default_opt[] = "graph,0.5,caller";
> const char * const report_usage[] = {
> "perf report []",
> NULL
> @@ -701,7 +701,7 @@ int cmd_report(int argc, const char **argv, const char
> *prefix __maybe_unused)
> "Only display entries with parent-match"),
> OPT_CALLBACK_DEFAULT('g', "call-graph", &report,
> "output_type,min_percent[,print_limit],call_order[,branch]",
>"Display callchains using output_type (graph, flat,
> fractal, or none) , min percent threshold, optional print limit, callchain
> order, key (function or address), add branches. "
> - "Default: fractal,0.5,callee,function",
> &report_parse_callchain_opt, callchain_default_opt),
> + "Default: graph,0.5,caller", &report_parse_callchain_opt,
> callchain_default_opt),
> OPT_BOOLEAN(0, "children", &symbol_conf.cumulate_callchain,
> "Accumulate callchains of children and show total overhead
> as well"),
> OPT_INTEGER(0, "max-stack", &report.max_stack,
> diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
> index ce465b259e52..c1bf9ff210b0 100644
> --- a/tools/perf/util/util.c
> +++ b/tools/perf/util/util.c
> @@ -17,9 +17,9 @@
> #include "callchain.h"
>
> struct callchain_param callchain_param = {
> - .mode = CHAIN_GRAPH_REL,
> + .mode = CHAIN_GRAPH_ABS,
> .min_percent = 0.5,
> - .order = ORDER_CALLEE,
> + .order = ORDER_CALLER,
> .key= CCKEY_FUNCTION
> };
>
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers
On 2015/10/13 12:16, Alexei Starovoitov wrote:
On 10/12/15 8:51 PM, Wangnan (F) wrote:
why 'set disable' is needed ?
the example given in cover letter shows the use case where you want
to receive samples only within sys_write() syscall.
The example makes sense, but sys_write() is running on this cpu, so
just
disabling it on the current one is enough.
Our real use case is control of the system-wide sampling. For example,
we need sampling all CPUs when smartphone start refershing its display.
We need all CPUs because in Android system there are plenty of threads
get involed into this behavior. We can't achieve this by controling
sampling on only one CPU. This is the reason we need 'set enable'
and 'set disable'.
ok, but that use case may have different enable/disable pattern.
In sys_write example ultra-fast enable/disable is must have, since
the whole syscall is fast and overhead should be minimal.
but for display refresh? we're talking milliseconds, no?
Can you just ioctl() it from user space?
If cost of enable/disable is high or the time range between toggling is
long, then doing it from the bpf program doesn't make sense. Instead
the program can do bpf_perf_event_output() to send a notification to
user space that condition is met and the user space can ioctl() events.
OK. I think I understand your design principle that, everything inside BPF
should be as fast as possible.
Make userspace control events using ioctl make things harder. You know that
'perf record' itself doesn't care too much about events it reveived. It only
copies data to perf.data, but what we want is to use perf record simply like
this:
# perf record -e evt=cycles -e control.o/pmu=evt/ -a sleep 100
And in control.o we create uprobe point to mark the start and finish of
a frame:
SEC("target=/a/b/c.o\nstartFrame=0x123456")
int startFrame(void *) {
bpf_pmu_enable(pmu);
return 1;
}
SEC("target=/a/b/c.o\nfinishFrame=0x234568")
int finishFrame(void *) {
bpf_pmu_disable(pmu);
return 1;
}
I think it is make sence also.
I still think perf is not necessary be independent each other. You know
we have
PERF_EVENT_IOC_SET_OUTPUT which can set multiple events output through one
ringbuffer. This way perf events are connected.
I think the 'set disable/enable' design in this patchset satisify the
design goal
that in BPF program we only do simple and fast things. The only
inconvience is
we add something into map, which is ugly. What about using similar
implementation
like PERF_EVENT_IOC_SET_OUTPUT, creating a new ioctl like
PERF_EVENT_IOC_SET_ENABLER,
then let perf to select an event as 'enabler', then BPF can still
control one atomic
variable to enable/disable a set of events.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3 group scheduling regression
On Tue, Oct 13, 2015 at 06:08:34AM +0200, Mike Galbraith wrote:
> It sounded like you wanted me to run the below alone. If so, it's a nogo.
Yes, thanks.
Then it is the sad fact that after migrate and removed_load_avg is added
in migrate_task_rq_fair(), we don't get a chance to update the tg so fast
that at the destination the mplayer is weighted to the group's share.
>
> -
> Task | Runtime ms | Switches | Average delay ms |
> Maximum delay ms | Maximum delay at |
>
> -
> oink:(8) | 787001.236 ms |21641 | avg:0.377 ms | max:
> 21.991 ms | max at: 51.504005 s
> mplayer:(25) | 4256.224 ms | 7264 | avg: 19.698 ms | max:
> 2087.489 ms | max at:115.294922 s
> Xorg:1011 | 1507.958 ms | 4081 | avg:8.349 ms | max:
> 1652.200 ms | max at:126.908021 s
> konsole:1752 |697.806 ms | 1186 | avg:5.749 ms | max:
> 160.189 ms | max at: 53.037952 s
> testo:(9) |438.164 ms | 2551 | avg:6.616 ms | max:
> 215.527 ms | max at:117.302455 s
> plasma-desktop:1716 |280.418 ms | 1624 | avg:3.701 ms | max:
> 574.806 ms | max at: 53.582261 s
> kwin:1708 |144.986 ms | 2422 | avg:3.301 ms | max:
> 315.707 ms | max at:116.555721 s
>
> > --
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 4df37a4..3dba883 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -2686,12 +2686,13 @@ static inline u64 cfs_rq_clock_task(struct cfs_rq
> > *cfs_rq);
> > static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
> > {
> > struct sched_avg *sa = &cfs_rq->avg;
> > - int decayed;
> > + int decayed, updated = 0;
> >
> > if (atomic_long_read(&cfs_rq->removed_load_avg)) {
> > long r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
> > sa->load_avg = max_t(long, sa->load_avg - r, 0);
> > sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
> > + updated = 1;
> > }
> >
> > if (atomic_long_read(&cfs_rq->removed_util_avg)) {
> > @@ -2708,7 +2709,7 @@ static inline int update_cfs_rq_load_avg(u64 now,
> > struct cfs_rq *cfs_rq)
> > cfs_rq->load_last_update_time_copy = sa->last_update_time;
> > #endif
> >
> > - return decayed;
> > + return decayed | updated;
A typo: decayed || updated, but shouldn't make any difference.
> > }
> >
> > /* Update task and its cfs_rq load average */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated scalable urandom patchkit
On Mon, Oct 12, 2015 at 7:46 PM, Theodore Ts'o wrote: On Mon, Oct 12, 2015 at 04:30:59PM -0400, George Spelvin wrote: > Segregating abusers solves both problems. If we do this then we don't > need to drop the locks from the nonblocking pool, which solves the > security problem. Er, sort of. I still think my points were valid, but they're about a particular optimization suggestion you had. By avoiding the need for the optimization, the entire issue is mooted. Sure, I'm not in love with anyone's particular optimization, whether it's mine, yours, or Andi's. I'm just trying to solve the scalability problem while also trying to keep the code maintainable and easy to understand (and over the years we've actually made things worse, to the extent that having a single mixing for the input and output pools is starting to be more of problem than a feature, since we're coding in a bunch of exceptions when it's the output pool, etc.). So if we can solve a problem by routing around it, that's fine in my book. You have to copy the state *anyway* because you don't want it overwritten by the ChaCha output, so there's really no point storing the constants. (Also, ChaCha has a simpler input block structure than Salsa20; the constants are all adjacent.) We're really getting into low-level implementations here, and I think it's best to worry about these sorts of things when we have a patch to review. (Note: one problem with ChaCha specifically is that is needs 16x32 bits of registers, and Arm32 doesn't quite have enough. We may want to provide an arch CPRNG hook so people can plug in other algorithms with good platform support, like x86 AES instructions.) So while a ChaCha20-based CRNG should be faster than a SHA-1 based CRNG, and I consider this a good thing, for me speed is **not** more important than keeping the underlying code maintainable and simple. This is one of the reasons why I looked at, and then discarded, to use x86 accelerated AES as the basis for a CRNG. Setting up AES so that it can be used easily with or without hardware acceleration looks very complicated to do in a cross-architectural way, and I don't want to drag in all of the crypto layer for /dev/random. The same variables can be used (with different parameters) to decide if we want to get out of mitigation mode. The one thing to watch out for is that "cat /dev/sdX" may have some huge pauses once the buffer cache fills. We don't want to forgive after too small a fixed interval. At least initially, once we go into mitigation mode for a particular process, it's probably safer to simply not exit it. Finally, we have the issue of where to attach this rate-limiting structure and crypto context. My idea was to use the struct file. But now that we have getrandom(2), it's harder. mm, task_struct, signal_struct, what? I'm personally more inclined to keep it with the task struct, so that different threads will use different crypto contexts, just from simplicity point of view since we won't need to worry about locking. Since many processes don't use /dev/urandom or getrandom(2) at all, the first time they do, we'd allocate a structure and hang it off the task_struct. When the process exits, we would explicitly memzero it and then release the memory. (Post-finally, do we want this feature to be configurable under CONFIG_EMBEDDED? I know keeping the /dev/random code size small is a speficic design goal, and abuse mitigation is optional.) Once we code it up we can see how many bytes this takes, we can have this discussion. I'll note that ChaCha20 is much more compact than SHA1: textdata bss dec hex filename 4230 0 042301086 /build/ext4-64/lib/sha1.o 1152 304 0 1456 5b0 /build/ext4-64/crypto/chacha20_generic.o ... and I've thought about this as being the first step towards potentially replacing SHA1 with something ChaCha20 based, in light of the SHAppening attack. Unfortunately, BLAKE2s is similar to ChaCha only from design perspective, not an implementation perspective. Still, I suspect the just looking at the crypto primitives, even if we need to include two independent copies of the ChaCha20 core crypto and the Blake2s core crypto, it still should be about half the size of the SHA-1 crypto primitive. And from the non-plumbing side of things, Andi's patchset increases the size of /dev/random by a bit over 6%, or 974 bytes from a starting base of 15719 bytes. It ought to be possible to implement a ChaCha20 based CRNG (ignoring the crypto primitives) in less than 974 bytes of x86_64 assembly. :-) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ This might be stupid,
Re: [PATCH] regulator: qcom-smd: Correct set_load() unit
On Mon, Oct 12, 2015 at 05:49:52PM -0700, Bjorn Andersson wrote: > The set_load() op deals with uA while the SMD packets used mA, so > convert as we're building the packet. > > Signed-off-by: Bjorn Andersson > --- Looks fine to me. Thanks for the fix. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*
On Monday 12 October 2015 10:59 PM, Tony Lindgren wrote: * Tony Lindgren [151012 10:17]: * Keerthy [150901 17:24]: On Tuesday 01 September 2015 11:33 PM, Tony Lindgren wrote: * Keerthy [150901 10:22]: On Wednesday 26 August 2015 09:29 AM, Keerthy wrote: Currently apart from dra7, omap5 and amx3 all the other SoCs are identified using cpu_is_* functions which is not right since they are all SoCs(System on Chips). Hence changing the SoC identification code to use soc_is instead of cpu_is and keeping defines for cpu_is where needed. This allows us to replace the rest of cpu_is usage along with other fixes as needed. Tony, A Gentle ping on this. Looks good to me for v4.4. I'll apply it after some testing after -rc1. Thanks Tony. Now with the fixes finally out of the way, applying into omap-for-v4.4/cleanup. Uhh actually not applying. This breaks builds quite a bit depending on the .config options chosen: arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function ‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration] arch/arm/mach-omap2/control.c:257:15: error: implicit declaration of function ‘cpu_is_omap243x’ [-Werror=implicit-function-declaration] arch/arm/mach-omap2/control.c:259:8: error: implicit declaration of function ‘cpu_is_omap44xx’ [-Werror=implicit-function-declaration] ... arch/arm/mach-omap2/io.c:389:7: error: implicit declaration of function ‘cpu_is_omap34xx’ [-Werror=implicit-function-declaration] arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function ‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration] ... arch/arm/mach-omap2/io.c:389:7: error: implicit declaration of function ‘cpu_is_omap34xx’ [-Werror=implicit-function-declaration] arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function ‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration] ... arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function ‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration] arch/arm/mach-omap2/control.c:257:15: error: implicit declaration of function ‘cpu_is_omap243x’ [-Werror=implicit-function-declaration] arch/arm/mach-omap2/control.c:259:8: error: implicit declaration of function ‘cpu_is_omap44xx’ [-Werror=implicit-function-declaration] ... arch/arm/mach-omap2/io.c:767:6: error: implicit declaration of function ‘cpu_is_omap24xx’ [-Werror=implicit-function-declaration] Keerthy, can you please test this with just single SoC configurations and run randconfig builds on this overnight. I will do that Tony. I tested omap2plus_defconfig and boot tested on multiple platforms. And then we obviously need to test to make sure that this does not break booting on various platforms for multi SoC and single SoC configurations. Okay. And then you can repost, please include what all was tested. Sure. Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] fsl-ifc: add missing include on ARM64
Dear Arnd,
I would like to have your feedback on this patch.
If it is good now, can you accept it?
Lijun
On 10/1/15, 4:14 PM, "Lijun Pan" wrote:
>Need to include sched.h to fix the following compilation error
>if FSL_IFC is enabled on ARM64 machine.
>
>In file included from include/linux/mmzone.h:9:0,
> from include/linux/gfp.h:5,
> from include/linux/kmod.h:22,
> from include/linux/module.h:13,
> from drivers/memory/fsl_ifc.c:22:
>drivers/memory/fsl_ifc.c: In function ‘check_nand_stat’:
>include/linux/wait.h:165:35: error: ‘TASK_NORMAL’ undeclared (first use in
>this function)
> #define wake_up(x) __wake_up(x, TASK_NORMAL, 1, NULL)
> ^
>drivers/memory/fsl_ifc.c:136:3: note: in expansion of macro ‘wake_up’
> wake_up(&ctrl->nand_wait);
> ^
>include/linux/wait.h:165:35: note: each undeclared identifier is reported only
>once for each function it appears in
> #define wake_up(x) __wake_up(x, TASK_NORMAL, 1, NULL)
> ^
>drivers/memory/fsl_ifc.c:136:3: note: in expansion of macro ‘wake_up’
> wake_up(&ctrl->nand_wait);
> ^
>
>Analysis is as follows:
>I put some instrumental code and get the
>following .h files inclusion sequence:
>
>In file included from ./arch/arm64/include/asm/compat.h:25:0,
> from ./arch/arm64/include/asm/stat.h:23,
> from include/linux/stat.h:5,
> from include/linux/module.h:10,
> from drivers/memory/fsl_ifc.c:23:
>include/linux/sched.h:113:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>‘__attribute__’ before ‘struct’
> struct sched_attr {
> ^
>
>CONFIG_COMPAT=y is enabled while 39 and 48 bit VA is selected.
>When 42 bit VA is selected, it does not enable CONFIG_COMPAT=y
>
>In ./arch/arm64/include/asm/stat.h:23, it has
>"#ifdef CONFIG_COMPAT"
>"#include "
>"..."
>"#endif"
>
>Since ./arch/arm64/include/asm/stat.h does not
>include ./arch/arm64/include/asm/compat.h,
>then it will not include include/linux/sched.h
>Hence we have to manually add "#include "
>in drivers/memory/fsl_ifc.c
>
>Signed-off-by: Lijun Pan
>---
>v3: change the subject title to better reflect the commit message
>insert linux/sched.h in more appropriate place among all .h files
>articulate CONFIG_COMPAT=y is set in 39/48 bit VA
>v2: reordering the include .h files according to Arnd's suggestion
>detailing why linux/sched.h is needed.
>
> drivers/memory/fsl_ifc.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
>index e87459f..acd1460 100644
>--- a/drivers/memory/fsl_ifc.c
>+++ b/drivers/memory/fsl_ifc.c
>@@ -22,6 +22,7 @@
> #include
> #include
> #include
>+#include
> #include
> #include
> #include
>--
>2.3.3
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers
On 10/12/15 8:51 PM, Wangnan (F) wrote: why 'set disable' is needed ? the example given in cover letter shows the use case where you want to receive samples only within sys_write() syscall. The example makes sense, but sys_write() is running on this cpu, so just disabling it on the current one is enough. Our real use case is control of the system-wide sampling. For example, we need sampling all CPUs when smartphone start refershing its display. We need all CPUs because in Android system there are plenty of threads get involed into this behavior. We can't achieve this by controling sampling on only one CPU. This is the reason we need 'set enable' and 'set disable'. ok, but that use case may have different enable/disable pattern. In sys_write example ultra-fast enable/disable is must have, since the whole syscall is fast and overhead should be minimal. but for display refresh? we're talking milliseconds, no? Can you just ioctl() it from user space? If cost of enable/disable is high or the time range between toggling is long, then doing it from the bpf program doesn't make sense. Instead the program can do bpf_perf_event_output() to send a notification to user space that condition is met and the user space can ioctl() events. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3 group scheduling regression
On Tue, 2015-10-13 at 03:55 +0800, Yuyang Du wrote:
> On Mon, Oct 12, 2015 at 12:23:31PM +0200, Mike Galbraith wrote:
> > On Mon, 2015-10-12 at 10:12 +0800, Yuyang Du wrote:
> >
> > > I am guessing it is in calc_tg_weight(), and naughty boys do make them
> > > more
> > > favored, what a reality...
> > >
> > > Mike, beg you test the following?
> >
> > Wow, that was quick. Dinky patch made it all better.
> >
> >
> > -
> > Task | Runtime ms | Switches | Average delay ms |
> > Maximum delay ms | Maximum delay at |
> >
> > -
> > oink:(8) | 739056.970 ms |27270 | avg:2.043 ms |
> > max: 29.105 ms | max at:339.988310 s
> > mplayer:(25) | 36448.997 ms |44670 | avg:1.886 ms |
> > max: 72.808 ms | max at:302.153121 s
> > Xorg:988 | 13334.908 ms |22210 | avg:0.081 ms |
> > max: 25.005 ms | max at:269.068666 s
> > testo:(9) | 2558.540 ms |13703 | avg:0.124 ms |
> > max:6.412 ms | max at:279.235272 s
> > konsole:1781 | 1084.316 ms | 1457 | avg:0.006 ms |
> > max:1.039 ms | max at:268.863379 s
> > kwin:1734 |879.645 ms |17855 | avg:0.458 ms |
> > max: 15.788 ms | max at:268.854992 s
> > pulseaudio:1808 |356.334 ms |15023 | avg:0.028 ms |
> > max:6.134 ms | max at:324.479766 s
> > threaded-ml:3483 |292.782 ms |25769 | avg:0.364 ms |
> > max: 40.387 ms | max at:294.550515 s
> > plasma-desktop:1745 |265.055 ms | 1470 | avg:0.102 ms |
> > max: 21.886 ms | max at:267.724902 s
> > perf:3439 | 61.677 ms |2 | avg:0.117 ms |
> > max:0.232 ms | max at:367.043889 s
>
> Phew...
>
> I think maybe the real disease is the tg->load_avg is not updated in time.
> I.e., it is after migrate, the source cfs_rq does not decrease its
> contribution
> to the parent's tg->load_avg fast enough.
It sounded like you wanted me to run the below alone. If so, it's a nogo.
-
Task | Runtime ms | Switches | Average delay ms | Maximum
delay ms | Maximum delay at |
-
oink:(8) | 787001.236 ms |21641 | avg:0.377 ms | max:
21.991 ms | max at: 51.504005 s
mplayer:(25) | 4256.224 ms | 7264 | avg: 19.698 ms | max:
2087.489 ms | max at:115.294922 s
Xorg:1011 | 1507.958 ms | 4081 | avg:8.349 ms | max:
1652.200 ms | max at:126.908021 s
konsole:1752 |697.806 ms | 1186 | avg:5.749 ms | max:
160.189 ms | max at: 53.037952 s
testo:(9) |438.164 ms | 2551 | avg:6.616 ms | max:
215.527 ms | max at:117.302455 s
plasma-desktop:1716 |280.418 ms | 1624 | avg:3.701 ms | max:
574.806 ms | max at: 53.582261 s
kwin:1708 |144.986 ms | 2422 | avg:3.301 ms | max:
315.707 ms | max at:116.555721 s
> --
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 4df37a4..3dba883 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2686,12 +2686,13 @@ static inline u64 cfs_rq_clock_task(struct cfs_rq
> *cfs_rq);
> static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
> {
> struct sched_avg *sa = &cfs_rq->avg;
> - int decayed;
> + int decayed, updated = 0;
>
> if (atomic_long_read(&cfs_rq->removed_load_avg)) {
> long r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
> sa->load_avg = max_t(long, sa->load_avg - r, 0);
> sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
> + updated = 1;
> }
>
> if (atomic_long_read(&cfs_rq->removed_util_avg)) {
> @@ -2708,7 +2709,7 @@ static inline int update_cfs_rq_load_avg(u64 now,
> struct cfs_rq *cfs_rq)
> cfs_rq->load_last_update_time_copy = sa->last_update_time;
> #endif
>
> - return decayed;
> + return decayed | updated;
> }
>
> /* Update task and its cfs_rq load average */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Jaehoon,
On 13 October 2015 at 07:36, Jaehoon Chung wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
Anand,
You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
pad correctly for Exynos5420 boards"). Why? There is no explanation in
the commit message about this.
>>>
>>> I don't remember to send the patch relevant to this. Hmm...
>>> Well, Is this patch really signed-off by me?
>>>
>>> Best Regards,
>>>
>>> Jaehoon Chung
Best regards,
Krzysztof
>>>
>>>
>>>
>>> Some how I don't receive these mail on my email id.
>>>
>>> I have picked up these changes from tizen repository for OdroidXU3.
>>> I have tested with this changes to detect UHS-I micro cd cards.
>>> That's the reason for this email.
>
> It seems to make manually, right?
> I have checked the tizen repository.
>
> The below is
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -335,7 +335,9 @@
> 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>;
> + cd-gpios = <&gpc2 2 0>;
> + cd-inverted;
> + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus1 &sd2_bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> };
>
>
>
> Yours
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = <&gpc2 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
> + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>
> Did you know what differ? :)
>
> Best Regards,
> Jaehoon Chung
>
>>
>> ... and you applied it blindly without looking at actual existing
>> contents and at previous commits.
>>
>> That is not how patches from different repositories should be cherry picked.
>>
>> Best regards,
>> Krzysztof
>>
>>
>
Looks like my changes have introduce another bug so please ignore this changes.
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks
On 10/12/2015 01:52 PM, Al Stone wrote: On 10/11/2015 09:58 PM, Pat Erley wrote: On 10/11/2015 08:49 PM, Hanjun Guo wrote: On 10/12/2015 11:08 AM, Pat Erley wrote: On 10/05/2015 10:12 AM, Al Stone wrote: On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote: On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote: On 09/30/2015 03:00 AM, Hanjun Guo wrote: On 2015/9/30 7:45, Al Stone wrote: NB: this patch set is for use against the linux-pm bleeding edge branch. [snip...] For this patch set, Reviewed-by: Hanjun Guo Thanks Hanjun Thanks, Hanjun! Series applied, thanks! Rafael Thanks, Rafael! Just decided to test out linux-next (to see the new nouveau cleanups). This change set prevents my Lenovo W510 from booting properly. Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to eventually replace the macro" Gets the system booting again. I'm attaching my dmesg from the failed boot, who wants the acpidump? [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1 [0.00] ACPI: Error parsing LAPIC address override entry [0.00] ACPI: Invalid BIOS MADT, disabling ACPI Seems the MADT revision is not right, could you dump the ACPI MADT (APIC) table and send it out? I will take a look :) Thanks Hanjun Here ya go, enjoy. Feel free to CC me on any patches that might fix it. Pat, Would you mind sending a copy of the FADT, also, please? The first of the ACPI messages is a check of version correspondence between the FADT and MADT, while the second message is from looking at just an MADT subtable. Thanks for sending the MADT out -- that helps me quite a lot in thinking this through. BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a look at these, also: [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623) [0.00] ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704) Not inherently dangerous, but definitely sloppy and mind-numbingly easy to avoid, IIRC. Here ya go. /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20150717-64 * Copyright (c) 2000 - 2015 Intel Corporation * * Disassembly of facp.dat, Mon Oct 12 21:06:03 2015 * * ACPI Data Table [FACP] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 4]Signature : "FACP"[Fixed ACPI Description Table (FADT)] [004h 0004 4] Table Length : 00F4 [008h 0008 1] Revision : 04 [009h 0009 1] Checksum : 59 [00Ah 0010 6] Oem ID : "LENOVO" [010h 0016 8] Oem Table ID : "TP-6N " [018h 0024 4] Oem Revision : 1450 [01Ch 0028 4] Asl Compiler ID : "LNVO" [020h 0032 4]Asl Compiler Revision : 0001 [024h 0036 4] FACS Address : BBEE7000 [028h 0040 4] DSDT Address : BBFF1C9B [02Ch 0044 1]Model : 00 [02Dh 0045 1] PM Profile : 02 [Mobile] [02Eh 0046 2]SCI Interrupt : 0009 [030h 0048 4] SMI Command Port : 00B2 [034h 0052 1]ACPI Enable Value : F0 [035h 0053 1] ACPI Disable Value : F1 [036h 0054 1] S4BIOS Command : 00 [037h 0055 1] P-State Control : 80 [038h 0056 4] PM1A Event Block Address : 1000 [03Ch 0060 4] PM1B Event Block Address : [040h 0064 4] PM1A Control Block Address : 1004 [044h 0068 4] PM1B Control Block Address : [048h 0072 4]PM2 Control Block Address : 1050 [04Ch 0076 4] PM Timer Block Address : 1008 [050h 0080 4] GPE0 Block Address : 1020 [054h 0084 4] GPE1 Block Address : [058h 0088 1] PM1 Event Block Length : 04 [059h 0089 1] PM1 Control Block Length : 02 [05Ah 0090 1] PM2 Control Block Length : 01 [05Bh 0091 1]PM Timer Block Length : 04 [05Ch 0092 1]GPE0 Block Length : 10 [05Dh 0093 1]GPE1 Block Length : 00 [05Eh 0094 1] GPE1 Base Offset : 00 [05Fh 0095 1] _CST Support : 85 [060h 0096 2] C2 Latency : 0001 [062h 0098 2] C3 Latency : 0039 [064h 0100 2] CPU Cache Size : [066h 0102 2] Cache Flush Stride : [068h 0104 1]Duty Cycle Offset : 01 [069h 0105 1] Duty Cycle Width : 03 [06Ah 0106 1] RTC Day Alarm Index : 0D [06Bh 0107 1]RTC Month Alarm Index : 00 [06Ch 0108 1]RTC Century Index : 32 [06Dh 0109 2] Boot Flags (decoded below) : 0012 Legacy Devices Supported (V2) : 0 8042 Present on ports 60/64 (V2) : 1 VGA Not Present (V4) : 0
Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers
On 2015/10/13 11:39, Alexei Starovoitov wrote: On 10/12/15 8:27 PM, Wangnan (F) wrote: Then how to avoid racing? For example, when one core disabling all events in a map, another core is enabling all of them. This racing may causes sereval perf events in a map dump samples while other events not. To avoid such racing I think some locking must be introduced, then cost is even higher. The reason why we introduce an atomic pointer is because each operation should controls a set of events, not one event, due to the per-cpu manner of perf events. why 'set disable' is needed ? the example given in cover letter shows the use case where you want to receive samples only within sys_write() syscall. The example makes sense, but sys_write() is running on this cpu, so just disabling it on the current one is enough. Our real use case is control of the system-wide sampling. For example, we need sampling all CPUs when smartphone start refershing its display. We need all CPUs because in Android system there are plenty of threads get involed into this behavior. We can't achieve this by controling sampling on only one CPU. This is the reason we need 'set enable' and 'set disable'. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 09:13, Krzysztof Kozlowski wrote: > On 13.10.2015 12:08, Anand Moon wrote: >> Hi Krzysztof, >> >> On 13 October 2015 at 05:44, Krzysztof Kozlowski >> wrote: >>> On 13.10.2015 00:32, Anand Moon wrote: Hi Krzysztof, On 12 October 2015 at 11:14, Krzysztof Kozlowski wrote: > On 12.10.2015 00:46, Anand Moon wrote: >> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) > > This description is not entirely correct. The MMC driver already > supports these UHS speeds (you did not any code) so you rather enabled > it (description of bindings says "is supported"). > > You mentioned DDR50 but I don't see respective property below. > > How do you know that these modes are really supported? I don't know. Can > you convince me? Setting this DDR50 capability give me this error. That's the reason to drop this capability. >>> >>> But you mentioned it in commit message! "Added support for UHS-I ... >>> (DDR50)" >>> >>> In the same time dropping DDR50 is not an sufficient proof that "SDR50 >>> and SDR104 are really supported". >>> >> >> These changes are related to the microSD card capabilities. >> So SDR50 have better frequency over DDR50. On the same Sandisk card. >> >> When the card select the capability for DDR50 >> --- >> [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address >> [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB >> [4.009179] mmcblk0: error -110 sending status command, retrying >> [4.009271] mmcblk0: error -115 sending stop command, original cmd >> response 0x900, card status 0x900 >> [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, >> cmd response 0x900, card status 0x0 >> [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 40Hz, actual 396825HZ div = 63) >> [4.067770] Console: switching to colour frame buffer device 274x77 >> [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [4.099692] mmc1: tried to reset card >> [4.101332] mmcblk0: p1 p2 >> >> >> When the card select the capability for SDR50 >> - >> [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req >> 1Hz, actual 1HZ div = 0) >> [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address >> [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB >> [ 2.461743] mmcblk0: p1 p2 >> >> Which will relate to better read/write speed. > > Which is not an answer to my question. To none of my previous questions. OK, you are correct.Just ignore these changes. -Anand Moon > > Best regards, > Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] debugfs: Add read-only/write-only bool file ops
On 12-10-15, 18:09, Stephen Boyd wrote: > There aren't any read-only or write-only bool file ops, but there > is a caller of debugfs_create_bool() that calls it with mode > equal to 0400. This leads to the possibility of userspace > modifying the file, so let's use the newly created > debugfs_create_mode() helper here to fix this. > > Signed-off-by: Stephen Boyd > --- > fs/debugfs/file.c | 15 ++- > 1 file changed, 14 insertions(+), 1 deletion(-) Reviewed-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] debugfs: Add read-only/write-only size_t file ops
On 12-10-15, 18:09, Stephen Boyd wrote: > There aren't any read-only or write-only size_t file ops, but there > is a caller of debugfs_create_size_t() that calls it with mode > equal to 0400. This leads to the possibility of userspace > modifying the file, so let's use the newly created > debugfs_create_mode() helper here to fix this. > > Signed-off-by: Stephen Boyd > --- > fs/debugfs/file.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On 13.10.2015 12:08, Anand Moon wrote: > Hi Krzysztof, > > On 13 October 2015 at 05:44, Krzysztof Kozlowski > wrote: >> On 13.10.2015 00:32, Anand Moon wrote: >>> Hi Krzysztof, >>> >>> On 12 October 2015 at 11:14, Krzysztof Kozlowski >>> wrote: On 12.10.2015 00:46, Anand Moon wrote: > Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) This description is not entirely correct. The MMC driver already supports these UHS speeds (you did not any code) so you rather enabled it (description of bindings says "is supported"). You mentioned DDR50 but I don't see respective property below. How do you know that these modes are really supported? I don't know. Can you convince me? >>> >>> Setting this DDR50 capability give me this error. That's the reason to >>> drop this capability. >> >> But you mentioned it in commit message! "Added support for UHS-I ... >> (DDR50)" >> >> In the same time dropping DDR50 is not an sufficient proof that "SDR50 >> and SDR104 are really supported". >> > > These changes are related to the microSD card capabilities. > So SDR50 have better frequency over DDR50. On the same Sandisk card. > > When the card select the capability for DDR50 > --- > [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > req 5000Hz, actual 5000HZ div = 0) > [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address > [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB > [4.009179] mmcblk0: error -110 sending status command, retrying > [4.009271] mmcblk0: error -115 sending stop command, original cmd > response 0x900, card status 0x900 > [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, > cmd response 0x900, card status 0x0 > [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > req 40Hz, actual 396825HZ div = 63) > [4.067770] Console: switching to colour frame buffer device 274x77 > [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > req 5000Hz, actual 5000HZ div = 0) > [4.099692] mmc1: tried to reset card > [4.101332] mmcblk0: p1 p2 > > > When the card select the capability for SDR50 > - > [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req > 1Hz, actual 1HZ div = 0) > [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address > [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB > [ 2.461743] mmcblk0: p1 p2 > > Which will relate to better read/write speed. Which is not an answer to my question. To none of my previous questions. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] debugfs: Add read-only/write-only x64 file ops
On 12-10-15, 18:09, Stephen Boyd wrote: > There aren't any read-only or write-only x64 file ops, but there > is a caller of debugfs_create_x64() that calls it with mode equal > to S_IRUGO. This leads to the possibility of userspace modifying > the file, so let's use the newly created debugfs_create_mode() > helper here to fix this. > > Signed-off-by: Stephen Boyd > --- > fs/debugfs/file.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] debugfs: Consolidate file mode checks in debugfs_create_*()
On 12-10-15, 18:09, Stephen Boyd wrote: > The code that creates debugfs file with different file ops based > on the file mode is duplicated in each debugfs_create_*() API. > Consolidate that code into debugfs_create_mode(), that takes > three file ops structures so that we don't have to keep > copy/pasting that logic. > > Signed-off-by: Stephen Boyd > --- > fs/debugfs/file.c | 98 > ++- > 1 file changed, 32 insertions(+), 66 deletions(-) Reviewed-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3 group scheduling regression
On Mon, Oct 12, 2015 at 12:23:31PM +0200, Mike Galbraith wrote:
> On Mon, 2015-10-12 at 10:12 +0800, Yuyang Du wrote:
>
> > I am guessing it is in calc_tg_weight(), and naughty boys do make them more
> > favored, what a reality...
> >
> > Mike, beg you test the following?
>
> Wow, that was quick. Dinky patch made it all better.
>
>
> -
> Task | Runtime ms | Switches | Average delay ms |
> Maximum delay ms | Maximum delay at |
>
> -
> oink:(8) | 739056.970 ms |27270 | avg:2.043 ms | max:
> 29.105 ms | max at:339.988310 s
> mplayer:(25) | 36448.997 ms |44670 | avg:1.886 ms | max:
> 72.808 ms | max at:302.153121 s
> Xorg:988 | 13334.908 ms |22210 | avg:0.081 ms | max:
> 25.005 ms | max at:269.068666 s
> testo:(9) | 2558.540 ms |13703 | avg:0.124 ms | max:
> 6.412 ms | max at:279.235272 s
> konsole:1781 | 1084.316 ms | 1457 | avg:0.006 ms | max:
> 1.039 ms | max at:268.863379 s
> kwin:1734 |879.645 ms |17855 | avg:0.458 ms | max:
> 15.788 ms | max at:268.854992 s
> pulseaudio:1808 |356.334 ms |15023 | avg:0.028 ms | max:
> 6.134 ms | max at:324.479766 s
> threaded-ml:3483 |292.782 ms |25769 | avg:0.364 ms | max:
> 40.387 ms | max at:294.550515 s
> plasma-desktop:1745 |265.055 ms | 1470 | avg:0.102 ms | max:
> 21.886 ms | max at:267.724902 s
> perf:3439 | 61.677 ms |2 | avg:0.117 ms | max:
> 0.232 ms | max at:367.043889 s
Phew...
I think maybe the real disease is the tg->load_avg is not updated in time.
I.e., it is after migrate, the source cfs_rq does not decrease its contribution
to the parent's tg->load_avg fast enough.
--
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4df37a4..3dba883 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2686,12 +2686,13 @@ static inline u64 cfs_rq_clock_task(struct cfs_rq
*cfs_rq);
static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
{
struct sched_avg *sa = &cfs_rq->avg;
- int decayed;
+ int decayed, updated = 0;
if (atomic_long_read(&cfs_rq->removed_load_avg)) {
long r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
sa->load_avg = max_t(long, sa->load_avg - r, 0);
sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
+ updated = 1;
}
if (atomic_long_read(&cfs_rq->removed_util_avg)) {
@@ -2708,7 +2709,7 @@ static inline int update_cfs_rq_load_avg(u64 now, struct
cfs_rq *cfs_rq)
cfs_rq->load_last_update_time_copy = sa->last_update_time;
#endif
- return decayed;
+ return decayed | updated;
}
/* Update task and its cfs_rq load average */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] qlcnic: constify qlcnic_mbx_ops structure
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Julia Lawall
> Sent: Sunday, October 11, 2015 4:48 AM
> To: Dept-GE Linux NIC Dev
> Cc: kernel-janit...@vger.kernel.org; netdev ; linux-
> kernel
> Subject: [PATCH] qlcnic: constify qlcnic_mbx_ops structure
>
> The only instance of a qlcnic_mbx_ops structure is never modified. Thus the
> declaration of the structure and all references to the structure type can be
> made
> const.
>
> In the definition of the qlcnic_mailbox structure, the ops field is no longer
> lined
> up with the other fields. This was left as is, to avoid a lot of trivial
> changes on
> the other lines.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/net/ethernet/qlogic/qlcnic/qlcnic.h |2 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c |4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
> index 9f0bdd9..37a731b 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
> @@ -4048,7 +4048,7 @@ static void qlcnic_83xx_mailbox_worker(struct
> work_struct *work)
> struct qlcnic_mailbox *mbx = container_of(work, struct qlcnic_mailbox,
> work);
> struct qlcnic_adapter *adapter = mbx->adapter;
> - struct qlcnic_mbx_ops *mbx_ops = mbx->ops;
> + const struct qlcnic_mbx_ops *mbx_ops = mbx->ops;
> struct device *dev = &adapter->pdev->dev;
> atomic_t *rsp_status = &mbx->rsp_status;
> struct list_head *head = &mbx->cmd_q;
> @@ -4098,7 +4098,7 @@ static void qlcnic_83xx_mailbox_worker(struct
> work_struct *work)
> }
> }
>
> -static struct qlcnic_mbx_ops qlcnic_83xx_mbx_ops = {
> +static const struct qlcnic_mbx_ops qlcnic_83xx_mbx_ops = {
> .enqueue_cmd= qlcnic_83xx_enqueue_mbx_cmd,
> .dequeue_cmd= qlcnic_83xx_dequeue_mbx_cmd,
> .decode_resp= qlcnic_83xx_decode_mbx_rsp,
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
> index d6696cf..46bbea8 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
> @@ -1092,7 +1092,7 @@ struct qlcnic_filter_hash { struct qlcnic_mailbox {
> struct workqueue_struct *work_q;
> struct qlcnic_adapter *adapter;
> - struct qlcnic_mbx_ops *ops;
> + const struct qlcnic_mbx_ops *ops;
> struct work_struct work;
> struct completion completion;
> struct list_headcmd_q;
>
Acked-by: Sony Chacko
Thanks,
Sony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] cpufreq: create cpu/cpufreq/policyX directories
On 12-10-15, 12:31, Saravana Kannan wrote: > Can we use the first CPU in the related CPUs mask? Instead of the > first CPU that the policy got created on? The policyX numbering > would be a bit more consistent that way. Okay.. > Suggested-by: ? Will add. Though me/Rafael thought about it long back, but then dropped the idea :) > Didn't notice when this got added. Do we really need this anymore if > we don't care about moving the directory and creating symlinks? I > don't think we need it anymore. And if we really need to know > related - offline, we can use for_each_cpu_and(related, > online/present mask) Its about tracking present-cpus, for which the link is present. So, it is still required. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers
On 10/12/15 8:27 PM, Wangnan (F) wrote: Then how to avoid racing? For example, when one core disabling all events in a map, another core is enabling all of them. This racing may causes sereval perf events in a map dump samples while other events not. To avoid such racing I think some locking must be introduced, then cost is even higher. The reason why we introduce an atomic pointer is because each operation should controls a set of events, not one event, due to the per-cpu manner of perf events. why 'set disable' is needed ? the example given in cover letter shows the use case where you want to receive samples only within sys_write() syscall. The example makes sense, but sys_write() is running on this cpu, so just disabling it on the current one is enough. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vf610_adc: Fix internal temperature calculation
Hi Stefan,
Sorry! for the delay.
On 10/08/2015 11:46 AM, Stefan Agner wrote:
Hi Bhuvan,
On 2015-09-23 06:43, Bhuvanchandra DV wrote:
There is an observed temperature difference of ~20°C with the
internal temperature reading and the temperature measured on
SoC package. Existing calculations consider the typical values
provided in datasheet. Those typical values are valid for
VREFH_ADC at 3.0V. Voltage at 25°C is different for different
VREFH_ADC voltages. With VREFH_ADC at 3.3V, voltage at 25°C is
0.699V. Hence update the VTEMP25 to 0.699V which gives ADCR@Temp25
as 867 and the final temperature readings differs with ~5°C from
the external readings.
I am not entirely happy with the message. The proposed changes seem not
to alter the offset which would explain a ~20°C difference... Where do
this 20°C come from?
The ~20°C difference is observed at higher temperatures when VTEMP25
at VREDH_ADC of 3V0 is considered. Will update the comment according
to the updated VTEMP25 constant instead of the 20°C difference which
is confusing wrt the changes done here.
Best regards,
Bhuvan
--
Stefan
Formula for finding ADCR@Temp25:
ADCR@Temp25 = (ADCR@Vdd * V@TEMP25 * 10) / VDDconv
ADCR@Vdd for 12-Bit ADC = 4095
VDDconv = VREFH_ADC * 10
VREFH_ADC@3.3V
ADCR@Temp25 = (4095 * .699 * 10) / 33
ADCR@Temp25 ~= 867
| VREFH_ADC | V@TEMP25 | VDDconv | ADCR@Temp25 |
| 3.0V| 0.696mV |30 | 950 |
| 3.3V| 0.699mV |33 | 867 |
Signed-off-by: Bhuvanchandra DV
---
drivers/iio/adc/vf610_adc.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
index f4df2a7..e7abc13 100644
--- a/drivers/iio/adc/vf610_adc.c
+++ b/drivers/iio/adc/vf610_adc.c
@@ -103,6 +103,13 @@
#define DEFAULT_SAMPLE_TIME 1000
+/* V at 25°C of 696 mV */
+#define VF610_VTEMP25_3V0 950
+/* V at 25°C of 699 mV */
+#define VF610_VTEMP25_3V3 867
+/* Typical sensor slope coefficient at all temperatures */
+#define VF610_TEMP_SLOPE_COEFF 1840
+
enum clk_sel {
VF610_ADCIOC_BUSCLK_SET,
VF610_ADCIOC_ALTCLK_SET,
@@ -636,11 +643,13 @@ static int vf610_read_raw(struct iio_dev *indio_dev,
break;
case IIO_TEMP:
/*
- * Calculate in degree Celsius times 1000
- * Using sensor slope of 1.84 mV/°C and
- * V at 25°C of 696 mV
- */
- *val = 25000 - ((int)info->value - 864) * 100 /
1840;
+* Calculate in degree Celsius times 1000
+* Using the typical sensor slope of 1.84 mV/°C
+* and VREFH_ADC at 3.3V, V at 25°C of 699 mV
+*/
+ *val = 25000 - ((int)info->value - VF610_VTEMP25_3V3) *
+ 100 / VF610_TEMP_SLOPE_COEFF;
+
break;
default:
mutex_unlock(&indio_dev->mlock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers :staging: android: make alignment match open parenthesis
Cleanup for checkpatch.pl warn below:
CHECK: Alignment should match open parenthesis
#836: FILE: drivers/staging/android/ashmem.c:836:
by split three lines to four.
Signed-off-by: Liao Tonglang
---
drivers/staging/android/ashmem.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 60200a3..99fc7dc 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -832,9 +832,10 @@ static int __init ashmem_init(void)
{
int ret;
- ashmem_area_cachep = kmem_cache_create("ashmem_area_cache",
- sizeof(struct ashmem_area),
- 0, 0, NULL);
+ ashmem_area_cachep =
+ kmem_cache_create("ashmem_area_cache",
+ sizeof(struct ashmem_area),
+ 0, 0, NULL);
if (unlikely(!ashmem_area_cachep)) {
pr_err("failed to create slab cache\n");
return -ENOMEM;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev] [PATCH 1/2] f2fs: add F2FS_GOING_DOWN_METAFLUSH to test power-failure
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, October 13, 2015 4:37 AM
> To: Chao Yu
> Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 1/2] f2fs: add F2FS_GOING_DOWN_METAFLUSH to
> test power-failure
>
> On Mon, Oct 12, 2015 at 05:01:29PM +0800, Chao Yu wrote:
> > > -Original Message-
> > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > > Sent: Friday, October 09, 2015 8:29 AM
> > > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > > linux-f2fs-de...@lists.sourceforge.net
> > > Cc: Jaegeuk Kim
> > > Subject: [f2fs-dev] [PATCH 1/2] f2fs: add F2FS_GOING_DOWN_METAFLUSH to
> > > test power-failure
> > >
> > > This patch introduces F2FS_GOING_DOWN_METAFLUSH which flushes meta pages
> > > like
> > > SSA blocks and then blocks all the writes.
> > > This can be used by power-failure tests.
> > >
> > > Signed-off-by: Jaegeuk Kim
> >
> > Good idea! I test power-failure case by changing src/godown to use new
> > macro, until now, I didn't catch any consistent problem. :)
> >
> > Reviewed-by: Chao Yu
>
> Yeah, I could reproduce the original issue with xfstests like below too.
> (Added "-n" to issue METAFLUSH in godown.)
Ah, looks good! Thanks for sharing me this test. :)
Thanks,
>
> ---
> tests/f2fs/002 | 85
> ++
> tests/f2fs/002.out | 5
> tests/f2fs/group | 1 +
> 3 files changed, 91 insertions(+)
> create mode 100755 tests/f2fs/002
> create mode 100644 tests/f2fs/002.out
>
> diff --git a/tests/f2fs/002 b/tests/f2fs/002
> new file mode 100755
> index 000..f3decbd
> --- /dev/null
> +++ b/tests/f2fs/002
> @@ -0,0 +1,85 @@
> +#! /bin/bash
> +# FS QA Test No. f2fs/002
> +#
> +# This test detects a f2fs-specific issue which is resolved by:
> +#f2fs: fix SSA updates resulting in corruption
> +# The purpose is to check whether filesystem metadata becomes inconsistent
> +# after fcollapse was called.
> +#
> +#---
> +# Copyright (c) 2015 Jaegeuk Kim. All Rights Reserved.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation.
> +#
> +# This program is distributed in the hope that it would be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write the Free Software Foundation,
> +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> +#
> +#---
> +#
> +
> +seq=`basename $0`
> +seqres=$RESULT_DIR/$seq
> +echo "QA output created by $seq"
> +
> +here=`pwd`
> +tmp=/tmp/$$
> +status=1 # failure is the default!
> +trap "rm -f $tmp.*; exit \$status" 0 1 2 3 15
> +
> +# get standard environment, filters and checks
> +. ./common/rc
> +. ./common/filter
> +. ./common/log
> +. ./common/punch
> +
> +# real QA test starts here
> +_supported_fs f2fs
> +_supported_os Linux
> +
> +rm -f $seqres.full
> +rm -f $tmp.log
> +
> +_require_scratch
> +_require_scratch_shutdown
> +_require_xfs_io_command "fcollapse"
> +
> +_scratch_mkfs > /dev/null 2>&1
> +
> +# collapse without sync
> +_run_test()
> +{
> + testfile=$SCRATCH_MNT/$1.$seq.$$
> +
> + _scratch_mount
> +
> + $XFS_IO_PROG -f -c "pwrite 0 5m" -c fsync $testfile > /dev/null
> + [ $1 -eq 1 ] && sync
> + $XFS_IO_PROG -c "fcollapse 64k 2m" $testfile > /dev/null
> +
> + echo "godown"
> + src/godown -v -n $SCRATCH_MNT >> $seqres.full
> +
> + echo "unmount"
> + umount $SCRATCH_MNT
> +
> + # curious if FS consistent at start
> + _check_scratch_fs $SCRATCH_DEV
> + [ $? -ne 0 ] && _fatal "fsck failed"
> +}
> +
> +# run without sync
> +_run_test 0
> +
> +# run with sync
> +_run_test 1
> +
> +status=0
> +exit
> diff --git a/tests/f2fs/002.out b/tests/f2fs/002.out
> new file mode 100644
> index 000..bbbf710
> --- /dev/null
> +++ b/tests/f2fs/002.out
> @@ -0,0 +1,5 @@
> +QA output created by 002
> +godown
> +unmount
> +godown
> +unmount
> diff --git a/tests/f2fs/group b/tests/f2fs/group
> index daba9a3..ff2305b 100644
> --- a/tests/f2fs/group
> +++ b/tests/f2fs/group
> @@ -4,3 +4,4 @@
> # - comment line before each group is "new" description
> #
> 001 auto quick rw
> +002 auto quick rw
> --
> 2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers
On 2015/10/13 3:29, Alexei Starovoitov wrote: On 10/12/15 2:02 AM, Kaixu Xia wrote: +extern const struct bpf_func_proto bpf_perf_event_sample_enable_proto; +extern const struct bpf_func_proto bpf_perf_event_sample_disable_proto; externs are unnecessary. Just make them static. Also I prefer single helper that takes a flag, so we can extend it instead of adding func_id for every little operation. To avoid conflicts if you touch kernel/bpf/* or bpf.h please always base your patches of net-next. > +atomic_set(&map->perf_sample_disable, 0); global flag per map is no go. events are independent and should be treated as such. Then how to avoid racing? For example, when one core disabling all events in a map, another core is enabling all of them. This racing may causes sereval perf events in a map dump samples while other events not. To avoid such racing I think some locking must be introduced, then cost is even higher. The reason why we introduce an atomic pointer is because each operation should controls a set of events, not one event, due to the per-cpu manner of perf events. Thank you. Please squash these two patches, since they're part of one logical feature. Splitting them like this only makes review harder. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] cpufreq: Use cpumask_copy instead of cpumask_or to copy a mask
On 12-10-15, 12:12, Saravana Kannan wrote:
> > if (new_policy) {
> > /* related_cpus should at least include policy->cpus. */
> >-cpumask_or(policy->related_cpus, policy->related_cpus,
> >policy->cpus);
> >+cpumask_copy(policy->related_cpus, policy->cpus);
>
> Again, why? It actually seems wrong. A 4 core cluster could come up
> with just 2 cores when the policy is added. But the related CPUs
> would be 4 CPUs.
Firstly, the patch hasn't changed anything at all. related_cpus was
empty until this point, and orring or setting it with ->cpus will
result in the same output.
Secondly, this is what we always wanted. related_cpus should contain
the mask of all possible CPUs for that cluster.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Jaehoon Chung,
On 13 October 2015 at 07:36, Jaehoon Chung wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
Anand,
You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
pad correctly for Exynos5420 boards"). Why? There is no explanation in
the commit message about this.
>>>
>>> I don't remember to send the patch relevant to this. Hmm...
>>> Well, Is this patch really signed-off by me?
>>>
>>> Best Regards,
>>>
>>> Jaehoon Chung
Best regards,
Krzysztof
>>>
>>>
>>>
>>> Some how I don't receive these mail on my email id.
>>>
>>> I have picked up these changes from tizen repository for OdroidXU3.
>>> I have tested with this changes to detect UHS-I micro cd cards.
>>> That's the reason for this email.
>
> It seems to make manually, right?
> I have checked the tizen repository.
>
> The below is
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -335,7 +335,9 @@
> 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>;
> + cd-gpios = <&gpc2 2 0>;
> + cd-inverted;
> + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus1 &sd2_bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> };
>
>
>
> Yours
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = <&gpc2 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
> + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>
> Did you know what differ? :)
>
My mistake, I will drop the changes. Sorry for the whole mess.
-Anand Moon
> Best Regards,
> Jaehoon Chung
>
>>
>> ... and you applied it blindly without looking at actual existing
>> contents and at previous commits.
>>
>> That is not how patches from different repositories should be cherry picked.
>>
>> Best regards,
>> Krzysztof
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3 group scheduling regression
On Mon, Oct 12, 2015 at 01:47:23PM +0200, Peter Zijlstra wrote:
>
> Also, should we do the below? At this point se->on_rq is still 0 so
> reweight_entity() will not update (dequeue/enqueue) the accounting, but
> we'll have just accounted the 'old' load.weight.
>
> Doing it this way around we'll first update the weight and then account
> it, which seems more accurate.
I think the original looks ok.
The account_entity_enqueue() adds child entity's load.weight to parent's load:
update_load_add(&cfs_rq->load, se->load.weight)
Then recalculate the shares.
Then reweight_entity() resets the parent entity's load.weight.
> ---
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 700eb548315f..d2efef565aed 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3009,8 +3009,8 @@ enqueue_entity(struct cfs_rq *cfs_rq, struct
> sched_entity *se, int flags)
>*/
> update_curr(cfs_rq);
> enqueue_entity_load_avg(cfs_rq, se);
> - account_entity_enqueue(cfs_rq, se);
> update_cfs_shares(cfs_rq);
> + account_entity_enqueue(cfs_rq, se);
>
> if (flags & ENQUEUE_WAKEUP) {
> place_entity(cfs_rq, se, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPF in shm_lock ipc
On Mon, 12 Oct 2015, Bueso wrote:
On Mon, 12 Oct 2015, Kirill A. Shutemov wrote:
On Mon, Oct 12, 2015 at 10:49:45AM -0700, Davidlohr Bueso wrote:
diff --git a/ipc/shm.c b/ipc/shm.c
index 4178727..9615f19 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -385,9 +385,25 @@ static struct mempolicy *shm_get_policy(struct
vm_area_struct *vma,
static int shm_mmap(struct file *file, struct vm_area_struct *vma)
{
- struct shm_file_data *sfd = shm_file_data(file);
+ struct file *vma_file = vma->vm_file;
+ struct shm_file_data *sfd = shm_file_data(vma_file);
+ struct ipc_ids *ids = &shm_ids(sfd->ns);
+ struct kern_ipc_perm *shp;
int ret;
+ rcu_read_lock();
+ shp = ipc_obtain_object_check(ids, sfd->id);
+ if (IS_ERR(shp)) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (!ipc_valid_object(shp)) {
+ ret = -EIDRM;
+ goto err;
+ }
+ rcu_read_unlock();
+
Hm. Isn't it racy? What prevents IPC_RMID from happening after this point?
Nothing, but that is later caught by shm_open() doing similar checks. We
basically end up doing a check between ->mmap() calls, which is fair imho.
Note that this can occur anywhere in ipc as IPC_RMID is a user request/cmd,
and we try to respect it -- thus you can argue this race anywhere, which is
why we have EIDRM/EINVL. Ultimately the user should not be doing such hacks
_anyway_. So I'm not really concerned about it.
Another similar alternative would be perhaps to make shm_lock() return an
error, and thus propagate that error to mmap return. That way we would have
a silent way out of the warning scenario (afterward we cannot race as we
hold the ipc object lock). However, the users would now have to take this
into account...
[validity check lockless]
->mmap()
[validity check lock]
Something like this, maybe. Although I could easily be missing things...
I've tested it enough to see Dimitry's testcase handled ok, and put it
through ltp. Also adding Manfred to the Cc, who always catches my idiotic
mistakes.
8<-
From: Davidlohr Bueso
Date: Mon, 12 Oct 2015 19:38:34 -0700
Subject: [PATCH] ipc/shm: fix handling of (re)attaching to a deleted segment
There are currently two issues when dealing with segments that are
marked for deletion:
(i) With d0edd8528362 (ipc: convert invalid scenarios to use WARN_ON)
we relaxed the system-wide impact of using a deleted segment. However,
we can now perfectly well trigger the warning and then deference a nil
pointer -- where shp does not exist.
(ii) As of a399b29dfbaa (ipc,shm: fix shm_file deletion races) we
forbid attaching/mapping a previously deleted segment; a feature once
unique to Linux, but removed[1] as a side effect of lockless ipc object
lookups and security checks. Similarly, Dmitry Vyukov reported[2] a
simple test case that creates a new vma for a previously deleted
segment, triggering the WARN_ON mentioned in (i).
This patch tries to address (i) by moving the shp error check out
of shm_lock() and handled by the caller instead. The benefit of this
is that it allows better handling out of situations where we end up
returning ERMID or EINVAL. Specifically, there are three callers
of shm_lock which we must look into:
- open/close -- which we ensure to never do any operations on
the pairs, thus becoming no-ops if found a prev
IPC_RMID.
- loosing the reference of nattch upon shmat(2) -- not feasible.
In addition, the common WARN_ON call is technically removed, but
we add a new one for the bogus shmat(2) case, which is definitely
unacceptable to race with RMID if nattch is bumped up.
To address (ii), a new shm_check_vma_validity() helper is added
(for lack of a better name), which attempts to detect early on
any races with RMID, before doing the full ->mmap. There is still
a window between the callback and the shm_open call where we can
race with IPC_RMID. If this is the case, it is handled by the next
shm_lock().
shm_mmap:
[shm validity checks lockless]
->mmap()
[shm validity checks lock] <-- at this point there after there
is no race as we hold the ipc
object lock.
[1] https://lkml.org/lkml/2015/10/12/483
[2] https://lkml.org/lkml/2015/10/12/284
Signed-off-by: Davidlohr Bueso
---
ipc/shm.c | 78 +++
1 file changed, 73 insertions(+), 5 deletions(-)
diff --git a/ipc/shm.c b/ipc/shm.c
index 4178727..47a7a67 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -156,11 +156,10 @@ static inline struct shmid_kernel *shm_lock(struct
ipc_namespace *ns, int id)
struct kern_ipc_perm *ipcp = ipc_lock(&shm_ids(ns), id);
/*
-* We raced in the idr lookup or with shm_destroy(). Either way, the
-* ID is busted.
+* Callers of shm_lock() must vali
Re: [RFC PATCH 1/2] perf: Add the flag sample_disable not to output data on samples
On 10/12/15 7:30 PM, xiakaixu wrote:
The proper perf_event_enable/disable are so heavy that another
>mechanism needed? cpu_function_call is probably too much to do
>from bpf program, but that can be simplified?
>Based on the use case from cover letter, sounds like you want
>something like soft_disable?
>Then extending event->state would make the most sense.
>Also consider the case of re-entrant event enable/disable.
>So inc/dec of a flag may be needed?
Thanks for your comments!
I've tried perf_event_enable/disable, but there is a warning caused
by cpu_function_call. The main reason as follows,
int smp_call_function_single(...)
{
...
WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
&& !oops_in_progress);
of course, that's what I meant by 'cpu_function_call is too much
to do from bpf program'. In this case it's running out of kprobe
with disabled irq, so you hit the warning, but even if it was regular
tracepoint, doing ipi from bpf is too much. All bpf helpers must be
deterministic without such side effects.
So I added the extra atomic flag filed in order to avoid this problem.
that's a hammer approach. There are other ways to do it, like:
- extend event->state with this soft_disable-like functionality
(Also consider the case of re-entrant event enable/disable.
inc/dec may be needed)
- or tap into event->attr.sample_period
may be it can be temporarily set to zero to indicate soft_disabled.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 05:44, Krzysztof Kozlowski wrote: > On 13.10.2015 00:32, Anand Moon wrote: >> Hi Krzysztof, >> >> On 12 October 2015 at 11:14, Krzysztof Kozlowski >> wrote: >>> On 12.10.2015 00:46, Anand Moon wrote: Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) >>> >>> This description is not entirely correct. The MMC driver already >>> supports these UHS speeds (you did not any code) so you rather enabled >>> it (description of bindings says "is supported"). >>> >>> You mentioned DDR50 but I don't see respective property below. >>> >>> How do you know that these modes are really supported? I don't know. Can >>> you convince me? >> >> Setting this DDR50 capability give me this error. That's the reason to >> drop this capability. > > But you mentioned it in commit message! "Added support for UHS-I ... > (DDR50)" > > In the same time dropping DDR50 is not an sufficient proof that "SDR50 > and SDR104 are really supported". > These changes are related to the microSD card capabilities. So SDR50 have better frequency over DDR50. On the same Sandisk card. When the card select the capability for DDR50 --- [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB [4.009179] mmcblk0: error -110 sending status command, retrying [4.009271] mmcblk0: error -115 sending stop command, original cmd response 0x900, card status 0x900 [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0 [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 40Hz, actual 396825HZ div = 63) [4.067770] Console: switching to colour frame buffer device 274x77 [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.099692] mmc1: tried to reset card [4.101332] mmcblk0: p1 p2 When the card select the capability for SDR50 - [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req 1Hz, actual 1HZ div = 0) [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB [ 2.461743] mmcblk0: p1 p2 Which will relate to better read/write speed. -Anand Moon > Best regards, > Krzysztof > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] extcon: gpio: Add the support for Device tree bindings
Hi Mark,
On 2015년 10월 05일 20:13, Mark Rutland wrote:
> On Mon, Oct 05, 2015 at 03:58:19PM +0900, Chanwoo Choi wrote:
>> This patch adds the support for Device tree bindings of extcon-gpio driver.
>> The extcon-gpio device tree node must include the both 'extcon-id' and
>> 'extcon-gpio' property.
>>
>> For exmaple:
>> usb_cable: extcon-gpio-0 {
>> compatible = "extcon-gpio";
>> extcon-id = ;
>> extcon-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
>> }
>>
>> ta_cable: extcon-gpio-1 {
>> compatible = "extcon-gpio";
>> extcon-id = ;
>> extcon-gpio = <&gpio3 2 GPIO_ACTIVE_LOW>;
>> debounce-ms = <50>; /* 50 millisecond */
>> wakeup-source;
>> }
>>
>> &dwc3_usb {
>> extcon = <&usb_cable>;
>> };
>>
>> &charger {
>> extcon = <&ta_cable>;
>> };
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> Changes from v1:
>> - Create the include/dt-bindings/extcon/extcon.h including the identification
>> of external connector. These definitions are used in dts file.
>> - Fix error if CONFIG_OF is disabled.
>>
>> .../devicetree/bindings/extcon/extcon-gpio.txt | 38 +++
>> drivers/extcon/extcon-gpio.c | 110
>> -
>> include/dt-bindings/extcon/extcon.h| 44 +
>> include/linux/extcon/extcon-gpio.h | 6 +-
>> 4 files changed, 173 insertions(+), 25 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
>> create mode 100644 include/dt-bindings/extcon/extcon.h
>>
>> diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
>> b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
>> new file mode 100644
>> index ..70c36f729963
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
>> @@ -0,0 +1,38 @@
>> +GPIO Extcon device
>> +
>> +This is a virtual device used to generate specific external connector
>> +from the GPIO pin connected to a GPIO pin.
>> +
>> +Required properties:
>> +- compatible: Must be "extcon-gpio".
>> +- extcon-id: unique id for specific external connector.
>> + See include/dt-bindings/extcon/extcon.h.
>
> This property is either misnamed and badly described, or it is
> pointless (the node is sufficient to form a unique ID which can be
> referenced by phandle).
>
> What is this used for exactly?
OK, I'll modify the description of 'extcon-id' property as following:
- extcon-id: The extcon support the various type of external connector to check
whether connector is attached or detached. The each external connector has
the unique number to identify it. So this property includes the unique number
which indicates the specific external connector. When external connector is
attached or detached, GPIO pin detect the changed state. See include/
dt-bindings/extcon/extcon.h which defines the unique number for supported
external connector from extcon framework.
>
>> +- extcon-gpio: GPIO pin to detect the external connector. See gpio binding.
>> +
>> +Optional properties:
>> +- debounce-ms: the debounce dealy for GPIO pin in millisecond.
>> +- wakeup-source: Boolean, extcon can wake-up the system.
>> +
>> +Example: Examples of extcon-gpio node as listed below:
>> +
>> +usb_cable: extcon-gpio-0 {
>> +compatible = "extcon-gpio";
>> +extcon-id = ;
>> +extcon-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
>> +}
>> +
>> +ta_cable: extcon-gpio-1 {
>> +compatible = "extcon-gpio";
>> +extcon-id = ;
>> +extcon-gpio = <&gpio3 2 GPIO_ACTIVE_LOW>;
>> +debounce-ms = <50>; /* 50 millisecond */
>> +wakeup-source;
>> +}
>> +
>> +&dwc3_usb {
>> +extcon = <&usb_cable>;
>> +};
>> +
>> +&charger {
>> +extcon = <&ta_cable>;
>> +};
>> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
>> index 279ff8f6637d..7f3e24aae0c4 100644
>> --- a/drivers/extcon/extcon-gpio.c
>> +++ b/drivers/extcon/extcon-gpio.c
>> @@ -1,8 +1,8 @@
>> /*
>> * extcon_gpio.c - Single-state GPIO extcon driver based on extcon class
>> *
>> - * Copyright (C) 2008 Google, Inc.
>> - * Author: Mike Lockwood
>> + * Copyright (C) 2015 Chanwoo Choi , Samsung
>> Electronics
>> + * Copyright (C) 2008 Mike Lockwood , Google, Inc.
>> *
>> * Modified by MyungJoo Ham to support extcon
>> * (originally switch class is supported)
>> @@ -26,12 +26,14 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> struct gpio_extcon_data {
>> struct extcon_dev *edev;
>> int irq;
>> +bool irq_wakeup;
>> struct delayed_work work;
>> unsigned long debounce_jiffies;
>>
>> @@ -61,19 +63,50 @@ static irqreturn_t gpio_irq_handler(int irq, void
>> *dev_id)
>> return IRQ_HANDLED;
>> }
>>
>> -s
Re: [PATCH v2 3/3] leds: rt5033: Add RT5033 Flash led device driver
Hi Jacek,
Thanks for your kind comments
I also append reply below
On 2015년 10월 13일 00:10, Jacek Anaszewski wrote:
> Hi Ingi,
>
> Thanks for the update. Few comments below.
>
> On 10/12/2015 03:12 PM, Ingi Kim wrote:
>> This patch adds device driver of Richtek RT5033 PMIC.
>> The driver supports a current regulated output to drive
>> white LEDs for camera flash.
>>
>> Signed-off-by: Ingi Kim
>> ---
>> drivers/leds/Kconfig | 8 ++
>> drivers/leds/Makefile | 1 +
>> drivers/leds/leds-rt5033.c | 223
>> +
>> include/linux/mfd/rt5033-private.h | 49
>> include/linux/mfd/rt5033.h | 22 +++-
>> 5 files changed, 301 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/leds/leds-rt5033.c
>>
>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>> index 42990f2..29613e3 100644
>> --- a/drivers/leds/Kconfig
>> +++ b/drivers/leds/Kconfig
>> @@ -345,6 +345,14 @@ config LEDS_PCA963X
>> LED driver chip accessed via the I2C bus. Supported
>> devices include PCA9633 and PCA9634
>>
>> +config LEDS_RT5033
>> +tristate "LED support for RT5033 PMIC"
>> +depends on LEDS_CLASS_FLASH && OF
>> +depends on MFD_RT5033
>> +help
>> + This option enables support for on-chip LED driver on
>> + RT5033 PMIC.
>> +
>> config LEDS_WM831X_STATUS
>> tristate "LED support for status LEDs on WM831x PMICs"
>> depends on LEDS_CLASS
>> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
>> index b503f92..bcc4d93 100644
>> --- a/drivers/leds/Makefile
>> +++ b/drivers/leds/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+= leds-cobalt-qube.o
>> obj-$(CONFIG_LEDS_COBALT_RAQ)+= leds-cobalt-raq.o
>> obj-$(CONFIG_LEDS_SUNFIRE)+= leds-sunfire.o
>> obj-$(CONFIG_LEDS_PCA9532)+= leds-pca9532.o
>> +obj-$(CONFIG_LEDS_RT5033)+= leds-rt5033.o
>> obj-$(CONFIG_LEDS_GPIO_REGISTER)+= leds-gpio-register.o
>> obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
>> obj-$(CONFIG_LEDS_LP3944)+= leds-lp3944.o
>> diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.c
>> new file mode 100644
>> index 000..b470c94
>> --- /dev/null
>> +++ b/drivers/leds/leds-rt5033.c
>> @@ -0,0 +1,223 @@
>> +/*
>> + * led driver for RT5033
>> + *
>> + * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
>> + * Ingi Kim
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define RT5033_LED_FLASH_TIMEOUT_MIN64000
>> +#define RT5033_LED_FLASH_TIMEOUT_STEPS32000
>> +#define RT5033_LED_TORCH_CURRENT_LEVEL_MAX16
>> +
>> +/* Macro for getting offset of flash timeout */
>> +#define GET_TIMEOUT_OFFSET(tm, step)((tm) / (step) - 2)
>> +
>> +static struct rt5033_led *flcdev_to_led(
>> +struct led_classdev_flash *fled_cdev)
>> +{
>> +return container_of(fled_cdev, struct rt5033_led, fled_cdev);
>> +}
>> +
>> +static int rt5033_led_brightness_set(struct led_classdev *led_cdev,
>> + enum led_brightness brightness)
>> +{
>> +struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
>> +struct rt5033_led *led = flcdev_to_led(fled_cdev);
>
> I assume that you don't use mutex here deliberately?
>
Actually I'm not sure why flash driver uses mutex.
In consideration of blocking competition, however, I'd be better to use it
>> +if (!brightness) {
>> +regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2,
>> + RT5033_FLED_CTRL2_MASK, 0x0);
>> +} else {
>> +regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION1,
>> + RT5033_FLED_FUNC1_MASK, RT5033_FLED_PINCTRL);
>> +regmap_update_bits(led->regmap,RT5033_REG_FLED_CTRL1,
>> + RT5033_FLED_CTRL1_MASK,
>> + (brightness - 1) << 4);
>> +regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2,
>> + RT5033_FLED_CTRL2_MASK, RT5033_FLED_ENFLED);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static void rt5033_init_flash_timeout(struct rt5033_led *led)
>> +{
>> +struct led_flash_setting *setting;
>> +
>> +setting = &led->fled_cdev.timeout;
>> +setting->min = RT5033_LED_FLASH_TIMEOUT_MIN;
>> +setting->max = led->data->flash_max_timeout;
>> +setting->step = RT5033_LED_FLASH_TIMEOUT_STEPS;
>> +setting->val = led->data->flash_max_timeout;
>> +}
>> +
>> +static int rt5033_led_parse_dt(struct rt5033_led *led, struct device *dev)
>> +{
>> +struct device_node *np = dev->of_node;
>> +struct device_node *child_node;
>> +struct rt5033_led_config_data *data;
>> +int ret = 0;
>> +
>> +if (!np)
>> +return -ENXIO
[PATCH v2] thp: use is_zero_pfn only after pte_present check
Use is_zero_pfn on pteval only after pte_present check on pteval
(It might be better idea to introduce is_zero_pte where checks
pte_present first). Otherwise, it could work with swap or
migration entry and if pte_pfn's result is equal to zero_pfn
by chance, we lose user's data in __collapse_huge_page_copy.
So if you're luck, the application is segfaulted and finally you
could see below message when the application is exit.
BUG: Bad rss-counter state mm:88007f099300 idx:2 val:3
Cc:
Acked-by: Kirill A. Shutemov
Reviewed-by: Andrea Arcangeli
Signed-off-by: Minchan Kim
---
Hello Greg,
This patch should go to -stable but when you will apply it
after merging of linus tree, it will be surely conflicted due
to userfaultfd part.
I want to know how to handle it.
Thanks.
mm/huge_memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 4b06b8db9df2..bbac913f96bc 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2206,7 +2206,8 @@ static int __collapse_huge_page_isolate(struct
vm_area_struct *vma,
for (_pte = pte; _pte < pte+HPAGE_PMD_NR;
_pte++, address += PAGE_SIZE) {
pte_t pteval = *_pte;
- if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) {
+ if (pte_none(pteval) || (pte_present(pteval) &&
+ is_zero_pfn(pte_pfn(pteval {
if (!userfaultfd_armed(vma) &&
++none_or_zero <= khugepaged_max_ptes_none)
continue;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated scalable urandom patchkit
On Mon, Oct 12, 2015 at 04:30:59PM -0400, George Spelvin wrote: > > Segregating abusers solves both problems. If we do this then we don't > > need to drop the locks from the nonblocking pool, which solves the > > security problem. > > Er, sort of. I still think my points were valid, but they're > about a particular optimization suggestion you had. By avoiding > the need for the optimization, the entire issue is mooted. Sure, I'm not in love with anyone's particular optimization, whether it's mine, yours, or Andi's. I'm just trying to solve the scalability problem while also trying to keep the code maintainable and easy to understand (and over the years we've actually made things worse, to the extent that having a single mixing for the input and output pools is starting to be more of problem than a feature, since we're coding in a bunch of exceptions when it's the output pool, etc.). So if we can solve a problem by routing around it, that's fine in my book. > You have to copy the state *anyway* because you don't want it overwritten > by the ChaCha output, so there's really no point storing the constants. > (Also, ChaCha has a simpler input block structure than Salsa20; the > constants are all adjacent.) We're really getting into low-level implementations here, and I think it's best to worry about these sorts of things when we have a patch to review. > (Note: one problem with ChaCha specifically is that is needs 16x32 bits > of registers, and Arm32 doesn't quite have enough. We may want to provide > an arch CPRNG hook so people can plug in other algorithms with good > platform support, like x86 AES instructions.) So while a ChaCha20-based CRNG should be faster than a SHA-1 based CRNG, and I consider this a good thing, for me speed is **not** more important than keeping the underlying code maintainable and simple. This is one of the reasons why I looked at, and then discarded, to use x86 accelerated AES as the basis for a CRNG. Setting up AES so that it can be used easily with or without hardware acceleration looks very complicated to do in a cross-architectural way, and I don't want to drag in all of the crypto layer for /dev/random. > The same variables can be used (with different parameters) to decide if > we want to get out of mitigation mode. The one thing to watch out for > is that "cat /dev/sdX" may have some huge pauses once > the buffer cache fills. We don't want to forgive after too small a > fixed interval. At least initially, once we go into mitigation mode for a particular process, it's probably safer to simply not exit it. > Finally, we have the issue of where to attach this rate-limiting structure > and crypto context. My idea was to use the struct file. But now that > we have getrandom(2), it's harder. mm, task_struct, signal_struct, what? I'm personally more inclined to keep it with the task struct, so that different threads will use different crypto contexts, just from simplicity point of view since we won't need to worry about locking. Since many processes don't use /dev/urandom or getrandom(2) at all, the first time they do, we'd allocate a structure and hang it off the task_struct. When the process exits, we would explicitly memzero it and then release the memory. > (Post-finally, do we want this feature to be configurable under > CONFIG_EMBEDDED? I know keeping the /dev/random code size small is > a speficic design goal, and abuse mitigation is optional.) Once we code it up we can see how many bytes this takes, we can have this discussion. I'll note that ChaCha20 is much more compact than SHA1: textdata bss dec hex filename 4230 0 042301086 /build/ext4-64/lib/sha1.o 1152 304 01456 5b0 /build/ext4-64/crypto/chacha20_generic.o ... and I've thought about this as being the first step towards potentially replacing SHA1 with something ChaCha20 based, in light of the SHAppening attack. Unfortunately, BLAKE2s is similar to ChaCha only from design perspective, not an implementation perspective. Still, I suspect the just looking at the crypto primitives, even if we need to include two independent copies of the ChaCha20 core crypto and the Blake2s core crypto, it still should be about half the size of the SHA-1 crypto primitive. And from the non-plumbing side of things, Andi's patchset increases the size of /dev/random by a bit over 6%, or 974 bytes from a starting base of 15719 bytes. It ought to be possible to implement a ChaCha20 based CRNG (ignoring the crypto primitives) in less than 974 bytes of x86_64 assembly. :-) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Jaehoon Chung,
On 13 October 2015 at 08:09, Jaehoon Chung wrote:
> On 10/13/2015 11:29 AM, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 13 October 2015 at 05:40, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 23:33, Anand Moon wrote:
Hi Krzysztof,
On 12 October 2015 at 17:43, Krzysztof Kozlowski
wrote:
> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
On 12.10.2015 00:46, Anand Moon wrote:
> Added support for vmmc/vqmmc-supply for emmc/sd cards.
> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
I can't see the description of a problem which is fixed. If you fix
something, then please describe what is wrong.
> Added ramp-delay for LDO9(VDD33_USB3_0).
> Added ramp-delay for LDO13(VDDQ_MMC2).
> Added ramp-delay for LDO15(ETH_P3V3).
>
> Signed-off-by: Anand Moon
>
> ---
> Changes based on
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v4.4-next/dt-samsung branch
>
> Note:
> Changes need for support of UHS-I highspeed cards.
> changes for vqmmc-supply for emmc is not supported.
>
> [1.831136] vdd_ldo9: ramp_delay not set
> [1.843049] vdd_ldo13: ramp_delay not set
> [1.850975] vdd_ldo15: ramp_delay not set
> [1.862816] vdd_sd: ramp_delay not set
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 26decbd..58c06d3 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -157,6 +157,7 @@
> regulator-min-microvolt = <300>;
> regulator-max-microvolt = <300>;
> regulator-always-on;
> +regulator-ramp-delay = <12000>;
> };
>
> ldo10_reg: LDO10 {
> @@ -182,9 +183,10 @@
>
> ldo13_reg: LDO13 {
> regulator-name = "vdd_ldo13";
> -regulator-min-microvolt = <280>;
> +regulator-min-microvolt = <180>;
> regulator-max-microvolt = <280>;
> regulator-always-on;
> +regulator-ramp-delay = <12000>;
> };
>
> ldo15_reg: LDO15 {
> @@ -213,6 +215,7 @@
> regulator-min-microvolt = <280>;
> regulator-max-microvolt = <280>;
> regulator-always-on;
> +regulator-ramp-delay = <12000>;
Where did you get this value from? It looks wrong... My datasheet does
not have 12000 uV/uS.
>>>
>>
>>> Anand,
>>>
>>> We have actually been here:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>>>
>>> That time you used 8000. I asked the same question - how did you figure
>>> out the exact value.
>>>
>>> Now we have the same question - why 12000?
>>>
>>> It is completely fine to make a mistake (I do a lot of them) but please
>>> try not to make the same mistake again.
>>>
>>> BR,
>>> Krzysztof
>>
>> I will focus more in the future to clamp down my mistakes to minimal.
>>
>>>
> };
>
> ldo24_reg: LDO24 {
> @@ -338,6 +341,7 @@
> samsung,dw-mshc-ddr-timing = <0 2>;
> samsung,dw-mshc-hs400-timing = <0 2>;
> samsung,read-strobe-delay = <90>;
> +vmmc-supply = <&ldo3_reg>;
> pinctrl-names = "default";
> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
> &sd0_cd &sd0_rclk>;
> bus-width = <8>;
> @@ -352,6 +356,8 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> +vmmc-supply = <&ldo19_reg>;
> +vqmmc-supply = <&ldo13_reg>;
It looks wrong. LDO13 is used in one place as VQMMC and in other as
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Krzysztof,
On 13 October 2015 at 05:42, Krzysztof Kozlowski
wrote:
> On 12.10.2015 23:47, Anand Moon wrote:
>>>
>>> Anand,
>>>
>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>> the commit message about this.
>>
>> I don't remember to send the patch relevant to this. Hmm...
>> Well, Is this patch really signed-off by me?
>>
>> Best Regards,
>>
>> Jaehoon Chung
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>>>
>>
>>
>> Some how I don't receive these mail on my email id.
>>
>> I have picked up these changes from tizen repository for OdroidXU3.
>> I have tested with this changes to detect UHS-I micro cd cards.
>> That's the reason for this email.
>
> ... and you applied it blindly without looking at actual existing
> contents and at previous commits.
>
> That is not how patches from different repositories should be cherry picked.
Sorry But I did not change it right way. By looking at the diff.
If the changes are wrong I will drop that changes.
I have to dig in my logs to find out why I have changes this setting.
Here is the log below, I will check If I am able to reproduce this bug
in the current kernel.
Sorry for the mess I have created.
---
Oct 6 08:23:21 odroidxu4 kernel: [6.559940]
==
Oct 6 08:23:21 odroidxu4 kernel: [6.559943] [ INFO: possible
circular locking dependency detected ]
Oct 6 08:23:21 odroidxu4 kernel: [6.559947] 4.2.0-xu4hkdn #7 Not tainted
Oct 6 08:23:21 odroidxu4 kernel: [6.559950]
---
Oct 6 08:23:21 odroidxu4 kernel: [6.559954] swapper/0/1 is trying
to acquire lock:
Oct 6 08:23:21 odroidxu4 kernel: [6.559972]
(&map->mutex){+.+...}, at: [] regmap_lock_mutex+0x1c/0x20
Oct 6 08:23:21 odroidxu4 kernel: [6.559975]
Oct 6 08:23:21 odroidxu4 kernel: [6.559975] but task is already
holding lock:
Oct 6 08:23:21 odroidxu4 kernel: [6.559987]
(prepare_lock){+.+.+.}, at: [] clk_prepare_lock+0x20/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.559990]
Oct 6 08:23:21 odroidxu4 kernel: [6.559990] which lock already
depends on the new lock.
Oct 6 08:23:21 odroidxu4 kernel: [6.559990]
Oct 6 08:23:21 odroidxu4 kernel: [6.559993]
Oct 6 08:23:21 odroidxu4 kernel: [6.559993] the existing
dependency chain (in reverse order) is:
Oct 6 08:23:21 odroidxu4 kernel: [6.560004]
Oct 6 08:23:21 odroidxu4 kernel: [6.560004] -> #1 (prepare_lock){+.+.+.}:
Oct 6 08:23:21 odroidxu4 kernel: [6.560019][]
mutex_lock_nested+0x84/0x4e4
Oct 6 08:23:21 odroidxu4 kernel: [6.560026][]
clk_prepare_lock+0x60/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.560033][]
clk_unprepare+0x28/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560044][]
exynos5_i2c_xfer+0x2dc/0x3a4
Oct 6 08:23:21 odroidxu4 kernel: [6.560051][]
__i2c_transfer+0x160/0xc60
Oct 6 08:23:21 odroidxu4 kernel: [6.560057][]
i2c_transfer+0x74/0xa0
Oct 6 08:23:21 odroidxu4 kernel: [6.560065][]
regmap_i2c_read+0x58/0x74
Oct 6 08:23:21 odroidxu4 kernel: [6.560072][]
_regmap_raw_read+0x130/0x654
Oct 6 08:23:21 odroidxu4 kernel: [6.560078][]
_regmap_bus_read+0x34/0x6c
Oct 6 08:23:21 odroidxu4 kernel: [6.560083][]
_regmap_read+0x7c/0x350
Oct 6 08:23:21 odroidxu4 kernel: [6.560090][]
regmap_read+0x50/0x70
Oct 6 08:23:21 odroidxu4 kernel: [6.560100][]
regulator_is_enabled_regmap+0x30/0xa4
Oct 6 08:23:21 odroidxu4 kernel: [6.560107][]
_regulator_is_enabled.part.10+0x2c/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560113][]
_regulator_do_set_voltage+0x720/0x9d0
Oct 6 08:23:21 odroidxu4 kernel: [6.560119][]
regulator_set_voltage+0xc4/0x150
Oct 6 08:23:21 odroidxu4 kernel: [6.560129][]
dw_mci_switch_voltage+0x98/0xbc
Oct 6 08:23:21 odroidxu4 kernel: [6.560136][]
mmc_power_up.part.16+0x6c/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.560143][]
mmc_start_host+0x54/0x78
Oct 6 08:23:21 odroidxu4 kernel: [6.560149][]
mmc_add_host+0x6c/0x90
Oct 6 08:23:21 odroidxu4 kernel: [6.560156][]
dw_mci_probe+0x660/0xc98
Oct 6 08:23:21 odroidxu4 kernel: [6.560162][]
dw_mci_pltfm_register+0x9c/0xa8
Oct 6 08:23:21 odroidxu4 kernel: [6.560168][]
dw_mci_exynos_probe+0x30/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560176][]
platform_drv_probe+0x54/0xb4
Oct 6 08:23:21 odroidxu4 kernel: [6.560183][]
driver_probe_device+0x184/0x2c0
Oct 6 08:23:21 odroidxu4 kernel: [6.560189][]
__driver_attach+0xa4/0xa8
Oct 6 08:23:21 odroidxu4 kernel: [6.560195][]
bus_for_each_dev+0x78/0xac
Oct 6 08:23:21 odroidxu4 kernel: [6.560202][]
driver_
Re: [PATCH 1/2] atm: iphase: return -ENOMEM instead of -1 in case of failed kmalloc()
From: Tillmann Heidsieck Date: Sat, 10 Oct 2015 21:47:18 +0200 > Smatch complains about returning hard coded error codes, silence this > warning. > > drivers/atm/iphase.c:115 ia_enque_rtn_q() warn: returning -1 instead of > -ENOMEM is sloppy > > Signed-off-by: Tillmann Heidsieck Applied to net-next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] atm: iphase: fix misleading indention
From: Tillmann Heidsieck Date: Sat, 10 Oct 2015 21:47:19 +0200 > Fix a smatch warning: > drivers/atm/iphase.c:1178 rx_pkt() warn: curly braces intended? > > The code is correct, the indention is misleading. In case the allocation > of skb fails, we want to skip to the end. > > Signed-off-by: Tillmann Heidsieck Applied to net-next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
On 10/13/2015 11:29 AM, Anand Moon wrote:
> Hi Krzysztof,
>
> On 13 October 2015 at 05:40, Krzysztof Kozlowski
> wrote:
>> On 12.10.2015 23:33, Anand Moon wrote:
>>> Hi Krzysztof,
>>>
>>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>>> wrote:
W dniu 12.10.2015 o 20:08, Anand Moon pisze:
> Hi Krzysztof,
>
> On 12 October 2015 at 11:19, Krzysztof Kozlowski
> wrote:
>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
Added support for vmmc/vqmmc-supply for emmc/sd cards.
Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>>
>>> I can't see the description of a problem which is fixed. If you fix
>>> something, then please describe what is wrong.
>>>
Added ramp-delay for LDO9(VDD33_USB3_0).
Added ramp-delay for LDO13(VDDQ_MMC2).
Added ramp-delay for LDO15(ETH_P3V3).
Signed-off-by: Anand Moon
---
Changes based on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v4.4-next/dt-samsung branch
Note:
Changes need for support of UHS-I highspeed cards.
changes for vqmmc-supply for emmc is not supported.
[1.831136] vdd_ldo9: ramp_delay not set
[1.843049] vdd_ldo13: ramp_delay not set
[1.850975] vdd_ldo15: ramp_delay not set
[1.862816] vdd_sd: ramp_delay not set
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 26decbd..58c06d3 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -157,6 +157,7 @@
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-always-on;
+regulator-ramp-delay = <12000>;
};
ldo10_reg: LDO10 {
@@ -182,9 +183,10 @@
ldo13_reg: LDO13 {
regulator-name = "vdd_ldo13";
-regulator-min-microvolt = <280>;
+regulator-min-microvolt = <180>;
regulator-max-microvolt = <280>;
regulator-always-on;
+regulator-ramp-delay = <12000>;
};
ldo15_reg: LDO15 {
@@ -213,6 +215,7 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
+regulator-ramp-delay = <12000>;
>>>
>>> Where did you get this value from? It looks wrong... My datasheet does
>>> not have 12000 uV/uS.
>>
>
>> Anand,
>>
>> We have actually been here:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>>
>> That time you used 8000. I asked the same question - how did you figure
>> out the exact value.
>>
>> Now we have the same question - why 12000?
>>
>> It is completely fine to make a mistake (I do a lot of them) but please
>> try not to make the same mistake again.
>>
>> BR,
>> Krzysztof
>
> I will focus more in the future to clamp down my mistakes to minimal.
>
>>
>>>
};
ldo24_reg: LDO24 {
@@ -338,6 +341,7 @@
samsung,dw-mshc-ddr-timing = <0 2>;
samsung,dw-mshc-hs400-timing = <0 2>;
samsung,read-strobe-delay = <90>;
+vmmc-supply = <&ldo3_reg>;
pinctrl-names = "default";
pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
&sd0_cd &sd0_rclk>;
bus-width = <8>;
@@ -352,6 +356,8 @@
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
samsung,dw-mshc-ddr-timing = <0 2>;
+vmmc-supply = <&ldo19_reg>;
+vqmmc-supply = <&ldo13_reg>;
>>>
>>> It looks wrong. LDO13 is used in one place as VQMMC and in other as
>>> VMMC. How did you figure out which regulator supplies which power
>>> domain?
>>>
>
> I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
>
> From the PWR_PMCI_
Re: [PATCH net-next] net: hns: fix the unknown phy_nterface_t type error
From: huangdaode Date: Sat, 10 Oct 2015 17:20:38 +0800 > This patch fix the building error reported by Jiri Pirko > > drivers/net/ethernet/hisilicon/hns/hnae.h:465:2: error: unknown type > name 'phy_interface_t' > phy_interface_t phy_if; > ^ > the full build log is on https://lists.01.org/pipermail/kbuild-all. > > Signed-off-by: huangdaode > Signed-off-by: yankejian Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf hists browser: Add 'm' key for context menu display
Em Tue, Oct 13, 2015 at 09:02:01AM +0900, Namhyung Kim escreveu: > With horizontal scrolling, the left/right arrow keys are used to > scroll columns and ENTER/ESC keys are used to enter/exit menu. > However if callchain is recorded, the ENTER key is used to toggle > callchain expansion so there's no way to display menu. Use 'm' key to > display the menu for this case. Thanks, applied. - Arnaldo > Signed-off-by: Namhyung Kim > --- > tools/perf/ui/browsers/hists.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c > index 9b7346a881cf..c8ec9bdb9c04 100644 > --- a/tools/perf/ui/browsers/hists.c > +++ b/tools/perf/ui/browsers/hists.c > @@ -1769,6 +1769,7 @@ static int perf_evsel__hists_browse(struct perf_evsel > *evsel, int nr_events, > "E Expand all callchains\n" \ > "F Toggle percentage of filtered entries\n" \ > "H Display column headers\n"\ > + "m Display context menu\n" \ > "S Zoom into current Processor Socket\n"\ > > /* help messages are sorted by lexical order of the hotkey */ > @@ -1934,6 +1935,7 @@ static int perf_evsel__hists_browse(struct perf_evsel > *evsel, int nr_events, > continue; > case K_ENTER: > case K_RIGHT: > + case 'm': > /* menu */ > break; > case K_ESC: > -- > 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] perf: Add the flag sample_disable not to output data on samples
于 2015/10/13 3:20, Alexei Starovoitov 写道:
> On 10/12/15 2:02 AM, Kaixu Xia wrote:
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index f57d7fe..25e073d 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -39,6 +39,7 @@ struct bpf_map {
>> u32 max_entries;
>> const struct bpf_map_ops *ops;
>> struct work_struct work;
>> +atomic_t perf_sample_disable;
>> };
>>
>> struct bpf_map_type_list {
>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>> index 092a0e8..0606d1d 100644
>> --- a/include/linux/perf_event.h
>> +++ b/include/linux/perf_event.h
>> @@ -483,6 +483,8 @@ struct perf_event {
>> perf_overflow_handler_toverflow_handler;
>> void*overflow_handler_context;
>>
>> +atomic_t*sample_disable;
>
> this looks fragile and unnecessary.
> Why add such field to generic bpf_map and carry its pointer into perf_event?
> Single extra field in perf_event would have been enough.
> Even better is to avoid adding any fields.
> There is already event->state why not to use that?
> The proper perf_event_enable/disable are so heavy that another
> mechanism needed? cpu_function_call is probably too much to do
> from bpf program, but that can be simplified?
> Based on the use case from cover letter, sounds like you want
> something like soft_disable?
> Then extending event->state would make the most sense.
> Also consider the case of re-entrant event enable/disable.
> So inc/dec of a flag may be needed?
Thanks for your comments!
I've tried perf_event_enable/disable, but there is a warning caused
by cpu_function_call. The main reason as follows,
int smp_call_function_single(...)
{
...
WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
&& !oops_in_progress);
...
}
So I added the extra atomic flag filed in order to avoid this problem.
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 13 October 2015 at 05:40, Krzysztof Kozlowski
wrote:
> On 12.10.2015 23:33, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>> wrote:
>>> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
Hi Krzysztof,
On 12 October 2015 at 11:19, Krzysztof Kozlowski
wrote:
> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>> On 12.10.2015 00:46, Anand Moon wrote:
>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>
>> I can't see the description of a problem which is fixed. If you fix
>> something, then please describe what is wrong.
>>
>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>
>>> Signed-off-by: Anand Moon
>>>
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Note:
>>> Changes need for support of UHS-I highspeed cards.
>>> changes for vqmmc-supply for emmc is not supported.
>>>
>>> [1.831136] vdd_ldo9: ramp_delay not set
>>> [1.843049] vdd_ldo13: ramp_delay not set
>>> [1.850975] vdd_ldo15: ramp_delay not set
>>> [1.862816] vdd_sd: ramp_delay not set
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 26decbd..58c06d3 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -157,6 +157,7 @@
>>> regulator-min-microvolt = <300>;
>>> regulator-max-microvolt = <300>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo10_reg: LDO10 {
>>> @@ -182,9 +183,10 @@
>>>
>>> ldo13_reg: LDO13 {
>>> regulator-name = "vdd_ldo13";
>>> -regulator-min-microvolt = <280>;
>>> +regulator-min-microvolt = <180>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo15_reg: LDO15 {
>>> @@ -213,6 +215,7 @@
>>> regulator-min-microvolt = <280>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>
>> Where did you get this value from? It looks wrong... My datasheet does
>> not have 12000 uV/uS.
>
> Anand,
>
> We have actually been here:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>
> That time you used 8000. I asked the same question - how did you figure
> out the exact value.
>
> Now we have the same question - why 12000?
>
> It is completely fine to make a mistake (I do a lot of them) but please
> try not to make the same mistake again.
>
> BR,
> Krzysztof
I will focus more in the future to clamp down my mistakes to minimal.
>
>>
>>> };
>>>
>>> ldo24_reg: LDO24 {
>>> @@ -338,6 +341,7 @@
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> samsung,dw-mshc-hs400-timing = <0 2>;
>>> samsung,read-strobe-delay = <90>;
>>> +vmmc-supply = <&ldo3_reg>;
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
>>> &sd0_cd &sd0_rclk>;
>>> bus-width = <8>;
>>> @@ -352,6 +356,8 @@
>>> samsung,dw-mshc-ciu-div = <3>;
>>> samsung,dw-mshc-sdr-timing = <0 4>;
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> +vmmc-supply = <&ldo19_reg>;
>>> +vqmmc-supply = <&ldo13_reg>;
>>
>> It looks wrong. LDO13 is used in one place as VQMMC and in other as
>> VMMC. How did you figure out which regulator supplies which power domain?
>>
I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
From the PWR_PMCI_S2MPS11_LDO_CTRL document it LDO13 point to VDDQ_MMC2.
>>>
>>> Aaa right, by mistake I thought that you put LDO13 here and in the node
>>> before, but there is LDO3, not 13. Yo
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On 10/12/2015 10:16 PM, Krzysztof Kozlowski wrote:
> W dniu 12.10.2015 o 22:04, Jaehoon Chung pisze:
>> On 10/12/2015 09:42 PM, Krzysztof Kozlowski wrote:
>>> W dniu 12.10.2015 o 19:46, Anand Moon pisze:
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>
> This description is not entirely correct. The MMC driver already
> supports these UHS speeds (you did not any code) so you rather enabled
> it (description of bindings says "is supported").
>
> You mentioned DDR50 but I don't see respective property below.
Looks like I missed it, I will add this in the next patch,
>
> How do you know that these modes are really supported? I don't know. Can
> you convince me?
>>>
>>> That part was not answered...
>>
>> In my experiment, it needs two requirements.
>> One is that Host controller supported UHS-I mode or others, other is SD-card.
>> In Anand's commit message, there is no information for this.
>>
>> And 50MB/s or 104MB/s is not real performance. (Just theoretical values)
>> It seems that can get those performances.
>
> Right. But do you know if the host actually supports these?
Actually, it needs to check the User Manual for SoC.
If i can't check the User manual, i can't also know whether it supports or not.
Especially, there is no register that can be known which SD specification
version at dw-mmc controller.
Well, if i miss something, let me know. I will also check more.
Best Regards,
Jaehoon Chung
>
>>
>>>
>
>>
>> Signed-off-by: Anand Moon
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>
> I don't get what is exactly fixed here. What was the error? What is the
> outcome of this fix? The log below is before or after?
>
> Best regards,
> Krzysztof
>
>>
>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>> 1Hz, actual 1HZ div = 0)
>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>> [2.461743] mmcblk0: p1 p2
>
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 58c06d3..ba4a87b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -364,6 +364,10 @@
>> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>> bus-width = <4>;
>> cap-sd-highspeed;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> };
>>
>> &pinctrl_0 {
>>
>
Changes were made to support Sandisk Ultra UHS-I class 10 card support.
OdroidXU3/XU4 board would not boot up using this card.
Depending on the capability of the UHS-I card, the speed of the card
is selected.
I have just added the enhance capability feature to support them.
>>>
>>> So without these capabilities mentioned microSD card cannot be used? So
>>> I have a UHS-I card, that one exactly:
>>> http://www.samsung.com/us/support/owners/product/MB-MP32D/APC
>>>
>>> It works:
>>> [2.628365] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req
>>> 5000Hz, actual 5000HZ div = 0)
>>> [2.693296] mmc1: new high speed SDHC card at address 0001
>>> [2.703867] mmcblk0: mmc1:0001 0 29.8 GiB
>>> [2.708406] mmcblk0: p1 p2
>>>
>>> This is just HS mode.
>>>
>>> In the same time isn't UHS-I backward compatible? Your report seems
>>> surprising.
>>
>> Right. it's not issue. just working as lower mode than its capability.
>
> Anand's report mentions "board would not boot up" which seems quite
> drastic. :)
>
> Thanks Jaehoon for help in reviewing this patch.
>
>
> Dear Anand,
>
> Could you describe in more details observable issues, what is fixed or
> what feature is added?
>
> Best regards,
> Krzysztof
>
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> Best regards,
>>> Krzysztof
>>>
On warm boot: i.e reboot of the board.
[4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
req 5000Hz, actual 5000HZ div = 0)
[4.657555] mmc1: new high speed SDHC card at address
[4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
[4.669206] mmcblk0: p1 p2
On cold boot:: ie: power on the board.
[4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
req
Re: 4.3 group scheduling regression
On Mon, 2015-10-12 at 13:47 +0200, Peter Zijlstra wrote: > Also, should we do the below? Ew. Box said "Either you quilt pop/burn, or I boot windows." ;-) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of regulator supply properties
On Tue, Oct 13, 2015 at 1:10 AM, Mark Rutland wrote:
> On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:
>> The physical display tied to the framebuffer may have regulators
>> providing power to it, such as power for LCDs or interface conversion
>> chips.
>>
>> The number of regulators in use may vary, but the regulator supply
>> binding can not be a list. Work around this by adding a "num-supplies"
>> property to communicate the number of supplies, and a list of 0 ~ N
>> "vinN-supply" properties for the actual regulator supply.
>
> This is getting more complicated by the minute...
Yeah...
I considered "backlight" and "panel" properties, but that seems to need
more effort to parse. Regulators seemed easier.
>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> .../devicetree/bindings/video/simple-framebuffer.txt | 14
>> ++
>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> index 4474ef6e0b95..0cc43e1be8b5 100644
>> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> @@ -47,10 +47,14 @@ Required properties:
>>- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>>
>> Optional properties:
>> -- clocks : List of clocks used by the framebuffer. Clocks listed here
>> - are expected to already be configured correctly. The OS must
>> - ensure these clocks are not modified or disabled while the
>> - simple framebuffer remains active.
>> +- clocks : List of clocks used by the framebuffer.
>> +- num-supplies : The number of regulators used by the framebuffer.
>> +- vinN-supply : The N-th (from 0) regulator used by the framebuffer.
>
> I don't see why you need num-supplies. Why not just try probing
> vin${N}-supply until such a property isn't present in the DT?
That's doable. Though I'd add a hard limit on it. Does 16 seem reasonable?
Thanks
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] Fix random hang up issue while kernel init
Hi Matthias, On Mon, 2015-10-12 at 18:32 +0200, Matthias Brugger wrote: > > On 07/10/15 11:14, James Liao wrote: > > This patch is based on v4.3-rc4, to fix system hanging up issue > > while disabling unused clocks. > > > > There is nothing different in mtk-scpsys.c and mt8173.dtsi from v1 [1]. > > > > Changes since v1: > > - Rebase to v4.3-rc4. > > - Add a patch to change the corresponding binding document. > > - Add a separated patch to change the dtsi. > > > > [1] https://patchwork.kernel.org/patch/7262411/ > > > > James Liao (3): > >dt-bindings: soc: Add clocks for Mediatek SCPSYS unit > >soc: mediatek: Fix random hang up issue while kernel init > >arm64: dts: mt8173: Add clocks for SCPSYS unit > > > > .../devicetree/bindings/soc/mediatek/scpsys.txt| 10 ++-- > > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 +- > > drivers/soc/mediatek/mtk-scpsys.c | 67 > > ++ > > 3 files changed, 54 insertions(+), 29 deletions(-) > > > > -- > > 1.9.1 > > > > > > Applied. Does this fix also needs to be applied to earlier kernel versions? No need, because venc and venc_lt clocks are not controlled by CCF before v4.2. Best regards, James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
