Re: [PATCH v4 1/4] PCI: Export symbols of PCI functions

[Ray Jui]

Hi Alex,

On 3/9/2015 6:00 PM, Alex Williamson wrote:
> On Mon, 2015-03-09 at 17:21 -0700, Ray Jui wrote:
>> Export symbols of the following PCI functions so they can be referenced
>> by a PCI driver compiled as a kernel loadable module:
>>
>> pci_common_swizzle
>> pci_create_root_bus
>> pci_stop_root_bus
>> pci_remove_root_bus
>> pci_assign_unassigned_bus_resources
>> pci_fixup_irqs
>>
>> Signed-off-by: Ray Jui 
>> ---
>>  drivers/pci/pci.c   |1 +
>>  drivers/pci/probe.c |1 +
>>  drivers/pci/remove.c|2 ++
>>  drivers/pci/setup-bus.c |1 +
>>  drivers/pci/setup-irq.c |1 +
>>  5 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 81f06e8..fb4a3da 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -2492,6 +2492,7 @@ u8 pci_common_swizzle(struct pci_dev *dev, u8 *pinp)
>>  *pinp = pin;
>>  return PCI_SLOT(dev->devfn);
>>  }
>> +EXPORT_SYMBOL(pci_common_swizzle);
>>  
>>  /**
>>   *  pci_release_region - Release a PCI bar
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 8d2f400..eb24ef9 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1993,6 +1993,7 @@ err_out:
>>  kfree(b);
>>  return NULL;
>>  }
>> +EXPORT_SYMBOL(pci_create_root_bus);
>>  
>>  int pci_bus_insert_busn_res(struct pci_bus *b, int bus, int bus_max)
>>  {
>> diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
>> index 8bd76c9..c523159 100644
>> --- a/drivers/pci/remove.c
>> +++ b/drivers/pci/remove.c
>> @@ -139,6 +139,7 @@ void pci_stop_root_bus(struct pci_bus *bus)
>>  /* stop the host bridge */
>>  device_release_driver(_bridge->dev);
>>  }
>> +EXPORT_SYMBOL(pci_stop_root_bus);
>>  
>>  void pci_remove_root_bus(struct pci_bus *bus)
>>  {
>> @@ -158,3 +159,4 @@ void pci_remove_root_bus(struct pci_bus *bus)
>>  /* remove the host bridge */
>>  device_unregister(_bridge->dev);
>>  }
>> +EXPORT_SYMBOL(pci_remove_root_bus);
>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>> index e3e17f3..932c9e5 100644
>> --- a/drivers/pci/setup-bus.c
>> +++ b/drivers/pci/setup-bus.c
>> @@ -1750,3 +1750,4 @@ void pci_assign_unassigned_bus_resources(struct 
>> pci_bus *bus)
>>  __pci_bus_assign_resources(bus, _list, NULL);
>>  BUG_ON(!list_empty(_list));
>>  }
>> +EXPORT_SYMBOL(pci_assign_unassigned_bus_resources);
>> diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
>> index 4e2d595..9d2bbb6 100644
>> --- a/drivers/pci/setup-irq.c
>> +++ b/drivers/pci/setup-irq.c
>> @@ -65,3 +65,4 @@ void pci_fixup_irqs(u8 (*swizzle)(struct pci_dev *, u8 *),
>>  for_each_pci_dev(dev)
>>  pdev_fixup_irq(dev, swizzle, map_irq);
>>  }
>> +EXPORT_SYMBOL(pci_fixup_irqs);
> 
> 
> Why not EXPORT_SYMBOL_GPL for all of these?  Some of these seem fairly
> close to PCI core functionality for arbitrarily licensed modules.
> 

I have no issue with that. I know there have been a lot of debates on
EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL use. If EXPORT_SYMBOL_GPL is
preferred on these PCI functions here, I'll make the change.


I'm still waiting for comments from Bjorn on the Broadcom iProc PCI
driver itself. This change will go with other changes in the iProc PCI
driver.

Thanks,

Ray
--
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] firmware_class: Add firmware filename overrides

[Charles Mooney]

Okay, thanks for the reviews.  My hope was to avoid having to add that
feature into each driver, but that's okay.
-Charlie

On Fri, Mar 6, 2015 at 3:33 PM, Marcel Holtmann  wrote:
> Hi Charles,
>
 Specifically this was motivated by a situation where we have one
 device with a dual-sourced touchscreen. Both use the same driver 
 but
 have different hardware & fw. Our FW updating software therefore,
 needs to be able to update with the correct FW and detect all this 
 at
 runtime due to a read-only partition (so moving the firmware 
 binaries
 around isn't really an option)
 Here the device has only one touchscreen at a time, but it isn't 
 known
 until run-time which will be present.

 So in this case the driver is serving the same function in each
 situation (running a touchscreen) but may be working with different
 hardware.

 Another situation where I've personally wanted this functionality 
 is
 on a device that uses the same touch driver for both a touchscreen 
 and
 a touchpad on the same device. If the driver only grabs a copy of 
 FW
 from, say, /lib/firmware/touch_fw.bin then you either need to move 
 the
 firmware binaries around on disk to update either device, or have a
 change like this that allows you to override which filename it 
 loads.
 The moving option is not viable if you're using a RO filesystem.
>>>
>>> what is the actual problem here? We have drivers that load multiple 
>>> firmware files and we have drivers that pick a different firmware 
>>> depending on some parameters it reads from the device.
>>>
>>> Seems this is all possible already at the moment with the existing 
>>> framework. You just need to update the drivers to operate properly.
>>>
>>
>> I totally agree, this functionality is not novel.  We could have 
>> added
>> this feature into the specific driver in question, but then we will
>> have to do the same thing on all the other drivers we might want to 
>> do
>> this on.  I guess the real problem that this solves is by adding the
>> change here, it allows you to override firmware names for *any* 
>> driver
>> without having to duplicate the functionality in each one as they 
>> come
>> up.
>>
>> For a specific instance, here at ChromiumOS we have devices that use
>> Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that
>> all can encounter this issue.  The Atmel driver has a similar version
>> of this feature baked into it but the others don't.  We could add a
>> fw_filename attribute to each of these drivers, but then it would 
>> have
>> to be maintained across (at least) four drivers.
>
> what I am hearing here is that you can not query the hardware and 
> figure out which manufacturer it is and with that don't know which 
> firmware you need.

 Right, the drivers in question (bunch of input drivers such as
 elan_ts, atmel_mxt_ts, etc) might not be able to determine the
 "proper" configuration to load. Factories quite often swap
 pin-compatible parts and want to use the same image. Also the parts
 can be swapped out during RMA while keeping the same image. Userspace
 is able to query magnitude of sources and make an informed decision
 that it then communicates to the kernel.

> However if that is the case, then this seems to be something that 
> should be solved with device tree.

 Why are we making device tree a hard dependency here?
>>>
>>> device tree is suppose to describe the hardware in your devices. If you 
>>> can not determinate your hardware by enumeration or other means, then 
>>> it should be done via device tree. Seems the perfect fit here.
>>
>> And if I do not have device tree?
>
> so if you do not have an enumeration method for your hardware, then I 
> assume you most likely have device tree in one form or another.
>
> And even if you really don't, nothing is stopping you from adding device 
> tree.

 We have ACPI (for example) and no, it is not 5.0.
>>>
>>> It depends if the driver can determinate what the device is from
>>> ACPI. If yes, you can just load the corresponding fw image
>>> for the current device. Otherwise the ACPI can't help your problem.
>>
>> We run into the situation where to very similar devices (all the same
>> HW models) need to ship with the same OS image.  One 

[PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

[Doug Anderson]

The dw_mmc driver enables HLE errors as part of DW_MCI_ERROR_FLAGS but
nothing in the interrupt handler actually handles them and ACKs them.
That means that if we ever get an HLE error we'll just keep getting
interrupts and we'll wedge things.

We really don't expect HLE errors but if we ever get them we shouldn't
silently ignore them.

Note that I have seen HLE errors while constantly ejecting and
inserting cards (ejecting while inserting, etc).

Signed-off-by: Doug Anderson 
---
Note that this works together with the patch I sent up yesterday (the
CMD 11 timer).  I would have sent the two together except that I had
local printouts (and ACKing of HLE) and didn't realize that this was
also required for a full solution.

 drivers/mmc/host/dw_mmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 47dfd0e..294edc9c 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -44,11 +44,11 @@
 /* Common flag combinations */
 #define DW_MCI_DATA_ERROR_FLAGS(SDMMC_INT_DRTO | SDMMC_INT_DCRC | \
 SDMMC_INT_HTO | SDMMC_INT_SBE  | \
-SDMMC_INT_EBE)
+SDMMC_INT_EBE | SDMMC_INT_HLE)
 #define DW_MCI_CMD_ERROR_FLAGS (SDMMC_INT_RTO | SDMMC_INT_RCRC | \
-SDMMC_INT_RESP_ERR)
+SDMMC_INT_RESP_ERR | SDMMC_INT_HLE)
 #define DW_MCI_ERROR_FLAGS (DW_MCI_DATA_ERROR_FLAGS | \
-DW_MCI_CMD_ERROR_FLAGS  | SDMMC_INT_HLE)
+DW_MCI_CMD_ERROR_FLAGS)
 #define DW_MCI_SEND_STATUS 1
 #define DW_MCI_RECV_STATUS 2
 #define DW_MCI_DMA_THRESHOLD   16
-- 
2.2.0.rc0.207.ga3a616c

--
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] soc: mediatek: Add PMIC wrapper for MT8135 and MT8173 SoCs

[Russell King - ARM Linux]

On Tue, Mar 10, 2015 at 04:22:34PM +0100, Sascha Hauer wrote:
> + for (i = 0; i < 4; i++) {
> + pwrap_writel(wrp, i, PWRAP_SIDLY);
> + pwrap_read(wrp, PWRAP_DEW_READ_TEST, );
> + printk("%s: 0x%04x\n", __func__, rdata);

Is this really ready for submission, or is this just a hidden oversight?

What I tend to do with such debugging is _not_ to indent it at all, which
means when the file is reviewed before sending it out (or indeed, when
diffing it to review the updates before committing those changes or an
amendment to the previous commit) that it sticks out like a sore thumb.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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 3/7] x86, boot: Don't overlap VO with ZO data

[Borislav Petkov]

On Tue, Mar 10, 2015 at 08:42:40AM -0700, Yinghai Lu wrote:
> In arch/x86/boot/header.S, we already use VO and ZO.
> So please keep on using them, and don't introduce "kernel proper" etc.

So you're suggesting commit messages should use variable names and
prefixes from the code instead of being human-readable?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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 12/18] dt-bindings: Document the STM32 USART bindings

[Maxime Coquelin]

2015-03-10 16:08 GMT+01:00 Arnd Bergmann :
> On Friday 20 February 2015 19:01:11 Maxime Coquelin wrote:
>> +
>> +Example:
>> +usart1: usart@40011000 {
>> +   compatible = "st,stm32-usart";
>>
>
> Please use generic node names everywhere. The standard name for a serial
> port is "serial".

I already had the remark, and it is already fixed in the next version.

Thanks,
Maxime

>
> Arnd
--
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] capabilities: Ambient capability set V2

[Christoph Lameter]

On Mon, 9 Mar 2015, Andrew G. Morgan wrote:

> If this is new info, perhaps you might reconsider the rationale for your
> patch? I suspect you are focused on addressing a problem that you felt was
> unaddressed before, but given how much appears to have been unclear to you
> about the current implementation it might be worth a pause for thought.

The problems with unclear documentation and a weird counterintuitive
implementation that lots of people have trouble to use do not impact the
approach as far as I can tell. The discovery about how to set inheritable
bits does not help with the use cases here.

Even with this patch there is still the need to write a wrapper to get
the functionality that one would expect to just be possible by setting
inheritable bits on a file. The necessity to set the bits via prctl
in the wrapper complicates matters further and makes it even more
difficult than we thought before to make use of this feature.

> http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf

Well maybe one should make sure that this info is properly comunicated
in the man pages and related documentation? This seems to be a big decade
old desaster. I need a Ph.D. in capabilities in order to attempt to use
them (but then oww no they still are not able to handle my use cases).

We get security through obscurity and also have then the inabilty to make
effective use of capabilities? Security measures need to follow
basic conventions, be obvious and easily understandable as well as well
documented. There is a huge risk of a sysadmin misconfiguring one of the
multiple measures that one needs to go through in order to gain some
sort of inheritance of capabilities and thereby adding more functionality
than necessary just in order to get it to work.

The best measure would be to make the inheritance bits work as one
would naturally expect. They just allow full inheritance of the caps.
No wrappers needed and its easily understood what it does.


--
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/pmu: Reject groups spanning multiple hardware PMUs

[Peter Zijlstra]

On Tue, Mar 10, 2015 at 03:36:08PM +, Mark Rutland wrote:
> On the assumption that the patch is otherwise OK, how about the commit
> message below?

Yeah, that'll do fine. 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 v3 3/7] x86, boot: Don't overlap VO with ZO data

[Yinghai Lu]

On Tue, Mar 10, 2015 at 8:21 AM, Borislav Petkov  wrote:
> On Tue, Mar 10, 2015 at 08:17:01AM -0700, Yinghai Lu wrote:
>> Make it not confusing.
>>
>> ZO: arch/x86/boot/compressed/vmlinux
>> VO: vmlinux
>>
>> setup + ZO ==> bzImage.
>>
>> compressed kernel is just compressed VO.
>
> So the two end up being the "compressed kernel" and "kernel proper".
>
> And then the subject turns into
>
> "Don't overlap kernel proper's brk with the compressed kernel's data section"
>
> Does that still confuse you?

In arch/x86/boot/header.S, we already use VO and ZO.
So please keep on using them, and don't introduce "kernel proper" etc.

Thanks

Yinghai Lu
--
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 v1] Mediatek SCPSYS power domain support

[Sascha Hauer]

This series adds support for the MediaTek SCPSYS unit.

The SCPSYS unit handles several power management related tasks such
as thermal measurement, DVFS, interrupt filter and low level sleep
control.

The initial support only contains the generic power domain handling.
This is needed to turn on power to the different power domains.

The driver is quite straight forward now. Due to the lack of a better
place I have put it to drivers/soc/mediatek. As the SCPSYS unit has
several other tasks that also do not fit into some specific subsystem
this probably is a good place for this driver.

Please review, any input welcome.

Sascha

changes since RFC:

- add a commit log to driver patch
- drop manipulating infracfg registers for now, can be added (properly)
  later
- Add warning messages when errors occur
- add NULL pointer check for kmalloc
- Enable all power domains when PM is disabled to allow consumers to work

--
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 07/18] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-03-10 16:02 GMT+01:00 Arnd Bergmann :
> On Friday 20 February 2015 19:01:06 Maxime Coquelin wrote:
>> +/* AHB1 */
>> +#define GPIOA_RESET0
>> +#define GPIOB_RESET1
>> +#define GPIOC_RESET2
>> +#define GPIOD_RESET3
>> +#define GPIOE_RESET4
>> +#define GPIOF_RESET5
>> +#define GPIOG_RESET6
>> +#define GPIOH_RESET7
>> +#define GPIOI_RESET8
>> +#define GPIOJ_RESET9
>> +#define GPIOK_RESET10
>>
>
> As these are just the hardware numbers, it's better to not make them
> part of the binding at all. Instead, just document in the binding that
> one is supposed to pass the hardware number as the argument.

The reset controller is part of the RCC (Reset & Clock Controller) IP.
In this version, I only provided the reset registers to the reset
controller driver, but as per Andreas Färber remark, I should avec a
single DT node for both the resets and clocks.

In the next version I am preparing, the defines doesn't look as
trivial as in this version, GPIOA_RESET being 128 for instance.

Is it fine for you if I keep the defines part of the binding?

Br,
Maxime
>
> Arnd
--
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 07/18] drivers: reset: Add STM32 reset driver

[Maxime Coquelin]

2015-03-10 16:02 GMT+01:00 Arnd Bergmann :
> On Friday 20 February 2015 19:01:06 Maxime Coquelin wrote:
>> +/* AHB1 */
>> +#define GPIOA_RESET0
>> +#define GPIOB_RESET1
>> +#define GPIOC_RESET2
>> +#define GPIOD_RESET3
>> +#define GPIOE_RESET4
>> +#define GPIOF_RESET5
>> +#define GPIOG_RESET6
>> +#define GPIOH_RESET7
>> +#define GPIOI_RESET8
>> +#define GPIOJ_RESET9
>> +#define GPIOK_RESET10
>>
>
> As these are just the hardware numbers, it's better to not make them
> part of the binding at all. Instead, just document in the binding that
> one is supposed to pass the hardware number as the argument.

The reset controller is part of the RCC (Reset & Clock Controller) IP.
In this version, I only provided the reset registers to the reset
controller driver, but as per Andrea

>
> Arnd
--
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 3/4] ARM64: MediaTek: Add generic pm domain support

[Sascha Hauer]

Enable support for generic power domains in the config.

Signed-off-by: Sascha Hauer 
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b8e973..aef77d2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -174,6 +174,7 @@ config ARCH_FSL_LS2085A
 config ARCH_MEDIATEK
bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
select ARM_GIC
+   select PM_GENERIC_DOMAINS if PM
help
  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
 
-- 
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/

Re: [GIT PULL v2] of: Add of-graph helpers to loop over endpoints and find ports by id

[Russell King - ARM Linux]

On Tue, Mar 10, 2015 at 04:24:47PM +0100, Philipp Zabel wrote:
> Hi Grant, Rob,
> 
> Am Dienstag, den 03.03.2015, 08:59 +0100 schrieb Philipp Zabel:
> > Hi Grant, Rob,
> > 
> > this series has been around for quite some time now, basically unchanged
> > except for adding fixes for new users of the API that keep appearing
> > over time in different subsystems.
> > 
> > It would be really helpful to get this merged for v4.0. Could you still
> > make this happen?
> >
> > Alternatively, could I please get your ack to allow this tag to be
> > merged into the other subsystem trees for v4.1 so that patches that
> > depend on it don't have to wait for yet another merge window?
> 
> The question still stands. It would be great to hear from you and maybe
> get this change in at least in time for v4.1.

Let's look at the history.

10-03-2015: This reminder
03-03-2015: Pull request (ignored from what can be seen)
01-03-2015: Request from Laurent about what's happening
27-02-2015: Reminder
23-02-2015: Re-base (and version 8) due to conflicts
11-02-2015: Reminder
22-01-2015: Pull request
23-12-2014: Version 7

During that time, there's not been one peep from Rob or Grant on this.
At what point has there been enough pestering that it's sufficient to
bypass an apparently uninterested maintainer, who can't be bothered to
say yes or no to a set of patches?

For such a key subsystem in the kernel, this is bad.  If Grant isn't
interested in performing a maintainer role, I'd be willing to pick up
that function (which'll be ironic, because that's the kind of thing
that Linaro's been doing to me over the last few years... picking
stuff off my plate without any discussion or agreement with me first,
leaving me with almost nothing to do.  No, I'm not pissed at that...
not much.)

I guess if you were to submit patches to Andrew, Andrew may take them
in this circumstance and eventually send them on to Linus.  Andrew?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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 4/4] ARM64: MediaTek MT8173: Add SCPSYS device node

[Sascha Hauer]

This adds the SCPSYS device node to the MT8173 dtsi file.

Signed-off-by: Sascha Hauer 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 8554ec3..9fa64ac 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -105,6 +105,12 @@
compatible = "simple-bus";
ranges;
 
+   scpsys: scpsys@10006000 {
+   compatible = "mediatek,mt8173-scpsys";
+   #power-domain-cells = <1>;
+   reg = <0 0x10006000 0 0x1000>;
+   };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt8173-sysirq",
"mediatek,mt6577-sysirq";
-- 
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 2/4] soc: Mediatek: Add SCPSYS power domain driver

[Sascha Hauer]

This adds a power domain driver for the Mediatek SCPSYS unit.

The System Control Processor System (SCPSYS) has several power
management related tasks in the system. The tasks include thermal
measurement, dynamic voltage frequency scaling (DVFS), interrupt
filter and lowlevel sleep control. The System Power Manager (SPM)
inside the SCPSYS is for the MTCMOS power domain control.

For now this driver only adds power domain support, the more
advanced features are not yet supported. The driver implements
the generic PM domain device tree bindings, the first user will
most likely be the Mediatek AFE audio driver.

Signed-off-by: Sascha Hauer 
---
 drivers/soc/mediatek/Kconfig |   6 +
 drivers/soc/mediatek/Makefile|   1 +
 drivers/soc/mediatek/mtk-scpsys.c| 345 +++
 include/dt-bindings/power/mt8173-power.h |  15 ++
 4 files changed, 367 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-scpsys.c
 create mode 100644 include/dt-bindings/power/mt8173-power.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index bcdb22d..1d34819 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -9,3 +9,9 @@ config MTK_PMIC_WRAP
  Say yes here to add support for MediaTek PMIC Wrapper found
  on different MediaTek SoCs. The PMIC wrapper is a proprietary
  hardware to connect the PMIC.
+
+config MTK_SCPSYS
+   tristate "MediaTek SCPSYS Support"
+   help
+ Say yes here to add support for the MediaTek SCPSYS power domain
+ driver.
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index ecaf4de..ce88693 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
+obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
new file mode 100644
index 000..a72ac51
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -0,0 +1,345 @@
+/*
+ * Copyright (c) 2015 Pengutronix, Sascha Hauer 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SPM_VDE_PWR_CON0x0210
+#define SPM_MFG_PWR_CON0x0214
+#define SPM_VEN_PWR_CON0x0230
+#define SPM_ISP_PWR_CON0x0238
+#define SPM_DIS_PWR_CON0x023c
+#define SPM_VEN2_PWR_CON   0x0298
+#define SPM_AUDIO_PWR_CON  0x029c
+#define SPM_MFG_2D_PWR_CON 0x02c0
+#define SPM_MFG_ASYNC_PWR_CON  0x02c4
+#define SPM_USB_PWR_CON0x02cc
+#define SPM_PWR_STATUS 0x060c
+#define SPM_PWR_STATUS_2ND 0x0610
+
+#define PWR_RST_B_BIT  BIT(0)
+#define PWR_ISO_BITBIT(1)
+#define PWR_ON_BIT BIT(2)
+#define PWR_ON_2ND_BIT BIT(3)
+#define PWR_CLK_DIS_BITBIT(4)
+
+#define DIS_PWR_STA_MASK   BIT(3)
+#define MFG_PWR_STA_MASK   BIT(4)
+#define ISP_PWR_STA_MASK   BIT(5)
+#define VDE_PWR_STA_MASK   BIT(7)
+#define VEN2_PWR_STA_MASK  BIT(20)
+#define VEN_PWR_STA_MASK   BIT(21)
+#define MFG_2D_PWR_STA_MASKBIT(22)
+#define MFG_ASYNC_PWR_STA_MASK BIT(23)
+#define AUDIO_PWR_STA_MASK BIT(24)
+#define USB_PWR_STA_MASK   BIT(25)
+
+struct scp_domain_data {
+   const char *name;
+   u32 sta_mask;
+   int ctl_offs;
+   u32 sram_pdn_bits;
+   u32 sram_pdn_ack_bits;
+   int id;
+};
+
+static struct scp_domain_data scp_domain_data[] = {
+   {
+   .id = MT8173_POWER_DOMAIN_VDE,
+   .name = "vde",
+   .sta_mask = VDE_PWR_STA_MASK,
+   .ctl_offs = SPM_VDE_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   }, {
+   .id = MT8173_POWER_DOMAIN_MFG,
+   .name = "mfg",
+   .sta_mask = MFG_PWR_STA_MASK,
+   .ctl_offs = SPM_MFG_PWR_CON,
+   .sram_pdn_bits = GENMASK(13, 8),
+   .sram_pdn_ack_bits = GENMASK(21, 16),
+   }, {
+   .id = MT8173_POWER_DOMAIN_VEN,
+   .name = "ven",
+   .sta_mask = VEN_PWR_STA_MASK,
+   

[PATCH 1/4] dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit

[Sascha Hauer]

This adds documentation for the MediaTek SCPSYS unit found in MT8173 SoCs.

Signed-off-by: Sascha Hauer 
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt| 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/scpsys.txt

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
new file mode 100644
index 000..4764a03
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -0,0 +1,32 @@
+MediaTek SCPSYS
+===
+
+The System Control Processor System (SCPSYS) has several power management
+related tasks in the system. The tasks include thermal measurement, dynamic
+voltage frequency scaling (DVFS), interrupt filter and lowlevel sleep control.
+The System Power Manager (SPM) inside the SCPSYS is for the MTCMOS power
+domain control.
+
+The driver implements the Generic PM domain bindings described in
+power/power_domain.txt. It provides the power domains defined in
+include/dt-bindings/power/mt8173-power.h.
+
+Required properties:
+- compatible: Must be "mediatek,mt8173-scpsys"
+- #power-domain-cells: Must be 1
+- reg: Address range of the SCPSYS unit
+
+Example:
+
+   scpsys: scpsys@10006000 {
+   #power-domain-cells = <1>;
+   compatible = "mediatek,mt8173-scpsys";
+   reg = <0 0x10006000 0 0x1000>;
+   };
+
+Example consumer:
+
+   afe: mt8173-afe-pcm@1122 {
+   compatible = "mediatek,mt8173-afe-pcm";
+   power-domains = < MT8173_POWER_DOMAIN_AUDIO>;
+   };
-- 
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/

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Peter Jones]

> >> So, for the sysfs interface, let's not allow loading from /lib. Let's
> >> not require a userland tool. Let's just do,
> >>
> >>   # echo /path/to/my/awesome/capsule.bin > /sys/../capsule
> >
> >>
> >> and be done with it.
> >>
> >> Hmmm?
> >
> > I assume you're implying a) the capsule header with the guid is embedded
> > in the .bin there already, and b) one contiguous write(2) with error
> > reporting coming through something like vars.c's efi_status_to_err()?
> >
> > If so, yes, I prefer this API.
> >
> 
> Is using a char device really so bad?  I have a "simple_char" that
> makes this really easy that's pending review.

As long as there's straightforward propagation of the EFI_STATUS return
from UpdateCapsule() back, sysfs file vs char device makes very little
difference to me.  Either way it's open(), write(), close().  Using the
runtime firmware upload interface designed for wifi and scsi devices is
the part I don't really like.

-- 
Peter
--
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/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration

[Tony Lindgren]

* Linus Walleij  [150310 03:39]:
> On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon  wrote:
> 
> > +Configuration definition follows similar model as the pinctrl-single:
> > +The groups of pin configuration are defined under "pinctrl-single,pins"
> > +
> > +_iodelay_core {
> > +   mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
> > +   pinctrl-single,pins = <
> > +   0x18c (A_DELAY(0) | G_DELAY(120))   /* 
> > CFG_GPMC_A19_IN */
> > +   0x1a4 (A_DELAY(265) | G_DELAY(360)) /* 
> > CFG_GPMC_A20_IN */
> > +   0x1b0 (A_DELAY(0) | G_DELAY(120))   /* 
> > CFG_GPMC_A21_IN */
> > +   0x1bc (A_DELAY(0) | G_DELAY(120))   /* 
> > CFG_GPMC_A22_IN */
> > +   0x1c8 (A_DELAY(287) | G_DELAY(420)) /* 
> > CFG_GPMC_A23_IN */
> > +   0x1d4 (A_DELAY(144) | G_DELAY(240)) /* 
> > CFG_GPMC_A24_IN */
> > +   0x1e0 (A_DELAY(0) | G_DELAY(0)) /* 
> > CFG_GPMC_A25_IN */
> > +   0x1ec (A_DELAY(120) | G_DELAY(0))   /* 
> > CFG_GPMC_A26_IN */
> > +   0x1f8 (A_DELAY(120) | G_DELAY(180)) /* 
> > CFG_GPMC_A27_IN */
> > +   0x360 (A_DELAY(0) | G_DELAY(0)) /* 
> > CFG_GPMC_CS1_IN */
> > +   >;
> > +   };
> > +};
> 
> But wait.
> 
> The promise when we merged pinctrl-single was that this driver was to be used
> when the system had a one-register-per-pin layout and it was easy to do device
> trees based on that.
> 
> We were very reluctant to accept that even though we didn't even have the
> generic pin control bindings in place, the argument being that the driver
> should know the detailed register layout, it should not be described in the
> device tree. We eventually caved in and accepted it as an exception.

Hey let's get few things straight here. There's nothing stopping the
driver from knowing a detailed register layout with the pinctrl-single
binding. This can be very easily done based on the compatible flag and
match data as needed and check the values provided.

And let's also recap the reasons for the pinctrl-single binding. The
the main reason for the pinctrl-single binding is to avoid mapping
individual register bits to device tree compatible string properties.

Imagine doing that for hundreds of similar registers. Believe me, I tried
using device tree properties initially and it just sucked big time. For
larger amounts of dts data, it's best to stick to numeric values and
phandles in the device tree data and rely on the preprocessor for
getting the values right.

Finally, we don't want to build databases into the kernel drivers for
every SoC. We certainly have plenty fo those already.
 
> Since this pin controller is not using pinctrl-single it does not enjoy that
> privilege and you need to explain why this pin controller cannot use the
> generic bindings like so many other pin controllers have since started
> to do. ("It is in the same SoC" is not an acceptable argument.)
>
> What is wrong with this:
> Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

Nishanth, care to explain your reasons for using pinctrl-single binding
here vs the generic binding? Is the amount of string parsing with the
data an issue here?
 
> We can add generic delay bindings to the list, it even seems like
> a good idea to do so, as it is likely something that will come up in
> other hardware and will be needed for ACPI etc going forward.

We certainly need to make setting delays (with values) generic, no
doubt about that.

If the large amount of data is not an issue here, we could maybe set
each iodelay register as a separate device? Then the binding could
be just along the interrupts-extended type binding:

foo = < 0x18c A_DELAY(0) G_DELAY(120)>;

Where the 0x18c is the instance offset of the register within the
ti,dra7-iodelay compatible controller.

Regards,

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 1/4] perf, tools: Output running time and run/enabled ratio in CSV mode

[Andi Kleen]

> Why not handle both cases here?
> 
> static void print_running(u64 run, u64 ena)
> {
>   if (csv_output)
>   fprintf(output, ...);
>   else if (run != ena)
>   fprintf(output, ...);
> }

print_running has 6 callers. run != ena is only needed
for two of them. So I don't think it makes sense to do.

-Andi
--
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/pmu: Reject groups spanning multiple hardware PMUs

[Mark Rutland]

On Tue, Mar 10, 2015 at 12:53:51PM +, Peter Zijlstra wrote:
> On Tue, Mar 10, 2015 at 12:05:21PM +, Mark Rutland wrote:
> > On Tue, Mar 10, 2015 at 11:27:23AM +, Peter Zijlstra wrote:
> > > On Mon, Mar 09, 2015 at 12:46:30PM +, Suzuki K. Poulose wrote:
> > > > From: "Suzuki K. Poulose" 
> > > > 
> > > > Don't allow grouping hardware events from different PMUs
> > > >  (eg. CCI + CPU).
> > > 
> > > Uhm, how does this work? If we have multiple hardware PMUs we'll stop
> > > scheduling events after the first failed event schedule. This can leave
> > > one of the PMUs severely under utilized.
> > 
> > The problem is here group validation at pmu::event_init() time, not
> > scheduling.
> 
> Maybe make that a little more explicit.

On the assumption that the patch is otherwise OK, how about the commit
message below?

>8
arm/pmu: Reject groups spanning multiple hardware PMUs

The perf core implicitly rejects events spanning multiple HW PMUs, as in
these cases the event->ctx will differ. However this validation is
performed after pmu::event_init() is called in perf_init_event(), and
thus pmu::event_init() may be called with a group leader from a
different HW PMU.

The ARM PMU driver does not take this fact into account, and when
validating groups assumes that it can call to_arm_pmu(event->pmu) for
any HW event. When the event in question is from another HW PMU this is
wrong, and results in dereferencing garbage.

This patch updates the ARM PMU driver to first test for and reject
events from other PMUs, moving the to_arm_pmu and related logic after
this test. Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2, with
a CCI PMU present:

CPU: 0 PID: 1527 Comm: perf_fuzzer Not tainted 4.0.0-rc2 #57
Hardware name: ARM-Versatile Express
task: bd8484c0 ti: be676000 task.ti: be676000
PC is at 0xbf1bbc90
LR is at validate_event+0x34/0x5c
pc : []lr : [<80016060>]psr: 0013
...
[<80016060>] (validate_event) from [<80016198>] (validate_group+0x28/0x90)
[<80016198>] (validate_group) from [<80016398>] (armpmu_event_init+0x150/0x218)
[<80016398>] (armpmu_event_init) from [<800882e4>] 
(perf_try_init_event+0x30/0x48)
[<800882e4>] (perf_try_init_event) from [<8008f544>] (perf_init_event+0x5c/0xf4)
[<8008f544>] (perf_init_event) from [<8008f8a8>] (perf_event_alloc+0x2cc/0x35c)
[<8008f8a8>] (perf_event_alloc) from [<8009015c>] 
(SyS_perf_event_open+0x498/0xa70)
[<8009015c>] (SyS_perf_event_open) from [<8000e420>] (ret_fast_syscall+0x0/0x34)
Code: bf1be000 bf1bb380 802a2664  (0002)
---[ end trace 01aff0ff00926a0a ]---
>8

Mark.
--
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: [V4.0.0-rc3] Xhci Regression: ERROR Transfer event TRB DMA ptr not part of current TD

[Jörg Otte]

2015-03-10 15:03 GMT+01:00 Jörg Otte :
> 2015-03-10 14:06 GMT+01:00 Mathias Nyman :
>> On 10.03.2015 11:40, Jörg Otte wrote:
>>> If I plug in my USB DVB-T stick I get the following in dmesg:
>>>
>>> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm 
>>> state.
>>> dvb-usb: will pass the complete MPEG2 transport stream to the software 
>>> demuxer.
>>> DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver)
>>> usb 1-1: DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0
>>> Highspeed DVB-T Receiver)...
>>> input: IR-receiver inside an USB DVB receiver as
>>> /devices/pci:00/:00:14.0/usb1/1-1/input/input17
>>> dvb-usb: schedule remote query interval to 50 msecs.
>>> xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part of
>>> current TD ep_index 1 comp_code 1
>>> xhci_hcd :00:14.0: Looking for event-dma 000207540400
>>> trb-start 000207540420 trb-end 000207540420 seg-start
>>> 0002075404
>>> xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part of
>>> current TD ep_index 1 comp_code 1
>>> xhci_hcd :00:14.0: Looking for event-dma 000207540410
>>> trb-start 000207540420 trb-end 000207540420 seg-start
>>> 0002075404
>>> dvb-usb: bulk message failed: -110 (2/0)
>>>
>>> and DVB-T is not functional. The problem came in with:
>>>
>>> 1163d50 Merge tag 'usb-4.0-rc3' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
>>>
>>> I never had this xhci_hcd error before so this is a regression.
>>>
>>>
>>> Thanks, Jörg
>>
>> Oh, thanks.
>>
>> Looks like we get an event for a TRB we just moved past.
>>
>> Any chance you could take a log with xhci debugging enabled before attaching 
>> the DVB-T
>> stick?
>>
>> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
>>
>>
>
> here it comes attached.
>
>
>> I'd suspect one of these two patches:
>>
>> commit 45ba2154d12fc43b70312198ec47085f10be801a
>> xhci: fix reporting of 0-sized URBs in control endpoint
>>
>> commit 27082e2654dc148078b0abdfc3c8e5ccbde0ebfa
>> xhci: Clear the host side toggle manually when endpoint is 'soft reset'
>>

Revert the commits.
The second one  "xhci: Clear the host side..."  is it !

Thanks, Jörg
--
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 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

[Jani Nikula]

On Tue, 10 Mar 2015, Archit Taneja  wrote:
> On 03/10/2015 03:35 PM, Daniel Vetter wrote:
>> On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
>>>
>>>
>>> On 03/10/2015 03:17 PM, Daniel Vetter wrote:
 On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
>>> DRM_KMS_FB_HELPER selects that for us, right?
>>
>> Hm right I've missed that. Reminds me that you need one more patch at the
>> end to remove all the various select DRM_KMS_FB_HELPER from all drm
>> drivers. Otherwise this knob here won't work by default if you e.g. select
>> radeon. In general we can't mix explicit options with menu entries with a
>> select.
>
> I was trying that out. Removing DRM_KMS_FB_HELPER and having 
> DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff 
> internally in their respective xyz_fbdev.c files.
>
> Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers 
> and replace them with 'select DRM_FBDEV_EMULATION'?

Slightly tangential: As a rule of thumb, you should not "select"
anything that is visible in menuconfig or has dependencies [1]. This
will break the build eventually, and attempts to fix it are troublesome
[2].

BR,
Jani.

[1] Documentation/kbuild/kconfig-language.txt
[2] http://mid.gmane.org/1413580403-16225-1-git-send-email-jani.nik...@intel.com


-- 
Jani Nikula, Intel Open Source Technology Center
--
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] staging: sm750fb: Fix sparse warning

[Lorenzo Stoakes]

On 10 March 2015 at 15:06, Greg KH  wrote:
> This doesn't apply anymore due to other patches I just took, so can you
> rebase this patch on my latest staging-testing branch of staging.git?

Fixed in v3 of staging: sm750fb: Cleanup the type of mmio75.

> Also, how about someone fixing the real compiler warnings this driver is
> spitting out first, before we worry about sparse warnings?  That's much
> more relevant here as it's keeping the driver from being built in
> linux-next at the moment.
>
> thanks,
>
> greg k-h

I am more than happy to take a look at this later today when I have
the opportunity to do so :)

-- 
Lorenzo Stoakes
https:/ljs.io
--
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/

ARCH_EXYNOS5433 missing in Kconfig

[Valentin Rothberg]

Hi Chanwoo,

your commit 96bd6224f07b ("clk: samsung: exynos5433: Add clocks using
common clock framework") is included in today's linux-next tree (i.e.,
next-20150310).

This patch conditionally compiles clk-exynos5433.c depending on the
Kconfig option ARCH_EXYNOS5433.  However, this option is not defined
in Kconfig, so that the driver cannot be compiled at the current
state:

+obj-$(CONFIG_ARCH_EXYNOS5433)  += clk-exynos5433.o

Is there a patch queued somewhere that adds this Kconfig symbol?  I
detected the issue by running undertaker-checkpatch from the
Undertaker tool suite (undertaker.cs.fau.de).  There is also a tool in
the git tree that can detect such issues (i.e.,
scripts/checkkconfigsymbols.py).

Kind regards,
 Valentin
--
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 tip/core/rcu 04/20] metag: Use common outgoing-CPU-notification code

[James Hogan]

Hi Paul,

On 03/03/15 17:42, Paul E. McKenney wrote:
> From: "Paul E. McKenney" 
> 
> This commit removes the open-coded CPU-offline notification with new
> common code.  This change avoids calling scheduler code using RCU from
> an offline CPU that RCU is ignoring.  This commit is compatible with
> the existing code in not checking for timeout during a prior offline
> for a given CPU.
> 
> Signed-off-by: Paul E. McKenney 
> Cc: James Hogan 
> Cc: 

I gave this a try via linux-next, but unfortunately it causes the
following warning every time a CPU goes down:
META213-Thread0 DSP [LogF] CPU1: unable to kill

If I add printks, I see that the state on entry to both cpu_wait_death
and cpu_report_death is already CPU_POST_DEAD, suggesting that it hasn't
changed from its initial value.

Should arches other than x86 now be calling cpu_set_state_online()? The
patchlet below seems to resolve it for Meta (not sure if that is the
best place in the startup sequence to do it, perhaps it doesn't matter).

diff --git a/arch/metag/kernel/smp.c b/arch/metag/kernel/smp.c
index ac3a199e33e7..430e379ec71f 100644
--- a/arch/metag/kernel/smp.c
+++ b/arch/metag/kernel/smp.c
@@ -383,6 +383,7 @@ asmlinkage void secondary_start_kernel(void)
 * OK, now it's safe to let the boot CPU continue
 */
set_cpu_online(cpu, true);
+   cpu_set_state_online(cpu);
complete(_running);
 
/*

Looking at the comment before cpu_set_state_online:
> /*
>  * Mark the specified CPU online.
>  *
>  * Note that it is permissible to omit this call entirely, as is
>  * done in architectures that do no CPU-hotplug error checking.
>  */

Which suggests it wasn't wrong to omit it before your patches came
along.

Cheers
James


> ---
>  arch/metag/kernel/smp.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/metag/kernel/smp.c b/arch/metag/kernel/smp.c
> index f006d2276f40..ac3a199e33e7 100644
> --- a/arch/metag/kernel/smp.c
> +++ b/arch/metag/kernel/smp.c
> @@ -261,7 +261,6 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>  }
>  
>  #ifdef CONFIG_HOTPLUG_CPU
> -static DECLARE_COMPLETION(cpu_killed);
>  
>  /*
>   * __cpu_disable runs on the processor to be shutdown.
> @@ -299,7 +298,7 @@ int __cpu_disable(void)
>   */
>  void __cpu_die(unsigned int cpu)
>  {
> - if (!wait_for_completion_timeout(_killed, msecs_to_jiffies(1)))
> + if (!cpu_wait_death(cpu, 1))
>   pr_err("CPU%u: unable to kill\n", cpu);
>  }
>  
> @@ -314,7 +313,7 @@ void cpu_die(void)
>   local_irq_disable();
>   idle_task_exit();
>  
> - complete(_killed);
> + (void)cpu_report_death();
>  
>   asm ("XOR   TXENABLE, D0Re0,D0Re0\n");
>  }
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock

[Peter Zijlstra]

On Tue, Mar 10, 2015 at 03:10:46PM +0100, Maarten Lankhorst wrote:
> Op 10-03-15 om 13:37 schreef Peter Zijlstra:

> > So IIRC this is the function that checks who gets wounded (and gets to
> > do the whole retry thing), right?
> >
> > So for the RT case, I think we should extend it to not (primarily) be a
> > FIFO thing, but also consider the priority of the tasks involved.
> >
> > Maybe a little something like:
> >
> > if (hold_ctx->task->prio < ctx->task->prio)
> > return -EDEADLOCK;
> >
> > before the timestamp check; although I suppose we should also add a
> > deadline test in case both prios are -1.

> I think that's useful but if you implement -EDEADLK based on thread
> priority, any boosted thread should receive -EDEADLK when it tries to
> acquire a new lock in the same context, to force it to back off..

But _only_ if the boost comes from inside the ww_ctx, right?

Yeah, implementing that might be tricky, maybe we can keep it as a note
for now ;)
--
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 05/18] reset: Add reset_controller_of_init() function

[Maxime Coquelin]

2015-03-10 16:00 GMT+01:00 Arnd Bergmann :
> On Friday 20 February 2015 19:01:04 Maxime Coquelin wrote:
>> Some platforms need to initialize the reset controller before the timers.
>>
>> This patch introduces a reset_controller_of_init() function that can be
>> called before the timers intialization.
>>
>> Signed-off-by: Maxime Coquelin 
>>
>
> Not sure about this. It seems like the cleanest approach if we get
> a lot of these, but then again it is probably very rare, and I'd
> like to avoid adding such infrastructure if it's just for one
> SoC. Could we add a hack in the machine initialization instead?

Sun6i also need to initialize the reset controller early. Today, they
hack the machine initialization.
With two SoCs having the same need, what should we do?

That said, I'm fine with either way. If reset_controller_of_init gets
accepted, I will send the patch for sun6i.

>
> I think ideally this would be done in the boot loader before we
> even start Linux, but I don't know if that's possible for you.

>From what I understand, the only constraint is to perform it after the
clock is enabled.
So this should be possible to do it in the bootloader, but it means
also adding timers clocks ungating in the bootloader.

Br,
Maxime

>
> Arnd
--
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: [PCI] BUG: unable to handle kernel

[Murali Karicheri]

On 03/09/2015 02:12 PM, Guenter Roeck wrote:

On 03/09/2015 11:09 AM, Murali Karicheri wrote:

On 03/09/2015 01:34 PM, Guenter Roeck wrote:

On 03/09/2015 10:03 AM, Murali Karicheri wrote:

On 03/09/2015 12:07 PM, Guenter Roeck wrote:

On 03/09/2015 08:53 AM, Murali Karicheri wrote:

On 03/09/2015 10:44 AM, Bjorn Helgaas wrote:

On Mon, Mar 9, 2015 at 9:17 AM, Murali
Karicheri
wrote:

On 03/06/2015 12:58 PM, Murali Karicheri wrote:


On 03/06/2015 11:55 AM, Guenter Roeck wrote:


On Fri, Mar 06, 2015 at 10:48:59AM -0500, Murali Karicheri wrote:
[ ... ]


From 098b4f5e4ab9407fbdbfcca3a91785c17e25cf03 Mon Sep 17
00:00:00 2001

From: Murali Karicheri
Date: Fri, 6 Mar 2015 10:23:08 -0500
Subject: [PATCH] pci: of : fix kernel crash

This is a debug patch to root cause the kernel crash

commit 0b2af171520e5d5e7d5b5f479b90a6a5014d9df6

PCI: Update DMA configuration from DT

Signed-off-by: Murali Karicheri
---
drivers/of/of_pci.c | 8 
drivers/pci/host-bridge.c | 5 +
2 files changed, 13 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 86d3c38..5a59fb8 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -129,6 +129,14 @@ void of_pci_dma_configure(struct pci_dev
*pci_dev)
struct device *dev =_dev->dev;
struct device *bridge = pci_get_host_bridge_device(pci_dev);

+ if (!bridge || !bridge->parent) {
+ if (!bridge)
+ pr_err("PCI bridge not found\n");
+ if (!bridge->parent)
+ pr_err("PCI bridge parent not found\n");



You'll see a crash here if bridge is NULL. Maybe add an else
before
the second
if statement ? Also, dev_err might be a bit more useful and
would be
available.


Fixed and attached.

Murali


Thanks,
Guenter


+ return;
+ }
+
of_dma_configure(dev, bridge->parent->of_node);
pci_put_host_bridge_device(bridge);
}
diff --git a/drivers/pci/host-bridge.c
b/drivers/pci/host-bridge.c
index 3e5bbf9..ef2ab51 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -28,6 +28,11 @@ struct device
*pci_get_host_bridge_device(struct
pci_dev *dev)
struct pci_bus *root_bus = find_pci_root_bus(dev->bus);
struct device *bridge = root_bus->bridge;

+ if (!bridge) {
+ pr_err("PCI: bridge not found\n");
+ return NULL;
+ }
+
kobject_get(>kobj);
return bridge;
}
--
1.7.9.5






BJorn,

Any chance of applying the attached debug patch to see if this
fixes
and
provide some additional information on this BUG? Not sure who will
pick this
one and apply.


The change that caused the oops (0b2af171520e ("PCI: Update DMA
configuration from DT")) only exists on my pci/iommu branch, so I'm
the one to apply it.

It's much easier for me to deal with plain text patches (not
attachments).

I'm hesitating because I don't want to encourage use of the 0-day
testing robot as a tool at which we can just throw debug patches.
The
robot is a service that costs somebody real money, and I want to
be a
good neighbor when using it.


Thanks for the clarification as I don't have much information on the
testing robot. At the same time the question is how similar incidence
in the past have been handled. I am a newbie w.r.t to this. This is
first time I have introduced a patch that impacts multiple
arch/machines.



Was the information in the robot's report enough to reproduce the
oops? If not, is there additional information we could add to the
report that would enable you to reproduce it? Even if we can't
reproduce the oops, the report seems detailed enough that we
should be
able to deduce the problem and produce a fix in which we have high
confidence.


The BUG report essentially indicates the crash happened in
of_pci_dma_configure(). The machine specific log make sense to a
person familiar with this arch and I am not familiar with the
same. So
anyone can help narrow down the root cause of this?

Looking at the code, there are two ptr variables that are accessed
without checking for NULL as initial thinking was that these can
never
be NULL. So the debug patch is just adding addition check before
accessing the ptr. I can send this patch without debug prints if that
make sense. I was thinking to get confirmation that this is indeed
the
case before adding the check. What do you think the right approach
here? Send a patch for this to the ML for adding the check as a
potential fix? Or someone can help me investigate the crash dump and
root cause it? or if we can use test robot to confirm this, I can
re-send the patch ASIS to the list. Please clarify.


If the assumption is that the pointers can never be NULL,
wouldn't it be important to see a call trace and to find out
if the NULL pointers can actually be seen by design,
or if there is some other bug ?


Call trace shows

[ 0.57] [<7976c1ac>] pci_device_add+0xbc/0x820
[ 0.57] [<7976c1ac>] pci_device_add+0xbc/0x820


And BUG seems to be in of_pci_dma_configure() as shown in the BUG
report.

of_pci_dma_configure() calls newly added API call to
pci_get_host_bridge_device(). Seems like this has succeeded which
means bridge is non NULL IMO. 

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Andy Lutomirski]

On Tue, Mar 10, 2015 at 8:21 AM, Peter Jones  wrote:
> On Tue, Mar 10, 2015 at 12:26:52PM +, Matt Fleming wrote:
>> On Fri, 06 Mar, at 04:39:12PM, Peter Jones wrote:
>> >
>> > So again: do we really need or want to do this?
>>
>> One thing that we totally lose the ability to do is use the capsule
>> interface for things *other* than firmware updates, e.g.
>>
>>  https://lkml.org/lkml/2013/10/16/327
>>
>> Also, requiring embedded or custom OS to include fwupdate into their
>> existing boot solutions is a bit heavy handed when literally all they
>> want to do is cat a binary blob to a sysfs file.
>>
>> I don't see why we can't have both solutions.
>
> Yeah - we clearly need a kernel interface for some embedded devices, and
> it'd be better for every vendor to not implement it themselves.
>
>> Another thing is that ESRT isn't going to be supported by every
>> platform.
>
> Yeah - though I think you're *mostly* talking about the same platforms
> as above.
>
>> So, for the sysfs interface, let's not allow loading from /lib. Let's
>> not require a userland tool. Let's just do,
>>
>>   # echo /path/to/my/awesome/capsule.bin > /sys/../capsule
>
>>
>> and be done with it.
>>
>> Hmmm?
>
> I assume you're implying a) the capsule header with the guid is embedded
> in the .bin there already, and b) one contiguous write(2) with error
> reporting coming through something like vars.c's efi_status_to_err()?
>
> If so, yes, I prefer this API.
>

Is using a char device really so bad?  I have a "simple_char" that
makes this really easy that's pending review.

--Andy

> --
> Peter



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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 v3] staging: sm750fb: Cleanup the type of mmio750

[Lorenzo Stoakes]

This patch assigns the more appropriate void* type to the mmio750 variable
eliminating an unnecessary volatile qualifier in the process. Additionally it
updates parameter types as necessary where those parameters interact with
mmio750, removes unnecessary casts and updates the type of the
lynx_share->pvReg field which is passed to the ddk750_set_mmio method.

As a consequence, this patch fixes the following sparse warning:-

drivers/staging/sm750fb/ddk750_help.c:12:17: warning: incorrect type in 
assignment (different address spaces)

Signed-off-by: Lorenzo Stoakes 
---
 drivers/staging/sm750fb/ddk750_chip.h |  4 +++-
 drivers/staging/sm750fb/ddk750_help.c |  4 ++--
 drivers/staging/sm750fb/ddk750_help.h | 10 +-
 drivers/staging/sm750fb/sm750.h   |  2 +-
 4 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.h 
b/drivers/staging/sm750fb/ddk750_chip.h
index d761b72..04cb0d5 100644
--- a/drivers/staging/sm750fb/ddk750_chip.h
+++ b/drivers/staging/sm750fb/ddk750_chip.h
@@ -5,6 +5,8 @@
 #define SM750LE_REVISION_ID ((unsigned char)0xfe)
 #endif
 
+#include 
+
 /* This is all the chips recognized by this library */
 typedef enum _logical_chip_type_t
 {
@@ -72,7 +74,7 @@ logical_chip_type_t getChipType(void);
 unsigned int calcPllValue(unsigned int request,pll_value_t *pll);
 unsigned int calcPllValue2(unsigned int,pll_value_t *);
 unsigned int formatPllReg(pll_value_t *pPLL);
-void ddk750_set_mmio(volatile unsigned char *,unsigned short,char);
+void ddk750_set_mmio(void __iomem *,unsigned short,char);
 unsigned int ddk750_getVMSize(void);
 int ddk750_initHw(initchip_param_t *);
 unsigned int getPllValue(clock_type_t clockType, pll_value_t *pPLL);
diff --git a/drivers/staging/sm750fb/ddk750_help.c 
b/drivers/staging/sm750fb/ddk750_help.c
index cc00d2b..c68ff3b 100644
--- a/drivers/staging/sm750fb/ddk750_help.c
+++ b/drivers/staging/sm750fb/ddk750_help.c
@@ -2,12 +2,12 @@
 //#include "ddk750_chip.h"
 #include "ddk750_help.h"
 
-volatile unsigned char __iomem * mmio750 = NULL;
+void __iomem * mmio750 = NULL;
 char revId750 = 0;
 unsigned short devId750 = 0;
 
 /* after driver mapped io registers, use this function first */
-void ddk750_set_mmio(volatile unsigned char * addr,unsigned short devId,char 
revId)
+void ddk750_set_mmio(void __iomem * addr,unsigned short devId,char revId)
 {
mmio750 = addr;
devId750 = devId;
diff --git a/drivers/staging/sm750fb/ddk750_help.h 
b/drivers/staging/sm750fb/ddk750_help.h
index 4fc93b5..07c8264 100644
--- a/drivers/staging/sm750fb/ddk750_help.h
+++ b/drivers/staging/sm750fb/ddk750_help.h
@@ -12,14 +12,14 @@
 #if 0
 /* if 718 big endian turned on,be aware that don't use this driver for general 
use,only for ppc big-endian */
 #warning "big endian on target cpu and enable nature big endian support of 718 
capability !"
-#define PEEK32(addr)   __raw_readl((void __iomem 
*)(mmio750)+(addr))
-#define POKE32(addr,data)  __raw_writel((data),(void 
__iomem*)(mmio750)+(addr))
+#define PEEK32(addr)   __raw_readl(mmio750 + addr)
+#define POKE32(addr,data)  __raw_writel(data, mmio750 + addr)
 #else /* software control endianess */
-#define PEEK32(addr) readl((addr)+mmio750)
-#define POKE32(addr,data) writel((data),(addr)+mmio750)
+#define PEEK32(addr) readl(addr + mmio750)
+#define POKE32(addr,data) writel(data, addr + mmio750)
 #endif
 
-extern volatile unsigned  char __iomem * mmio750;
+extern void __iomem * mmio750;
 extern char revId750;
 extern unsigned short devId750;
 #else
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index d39968c..5361116 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -63,7 +63,7 @@ struct lynx_share{
unsigned long vidreg_start;
__u32 vidmem_size;
__u32 vidreg_size;
-   volatile unsigned char __iomem * pvReg;
+   void __iomem * pvReg;
unsigned char __iomem * pvMem;
/* locks*/
spinlock_t slock;
-- 
2.3.2

--
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: fwupdate

[Peter Jones]

On Tue, Mar 10, 2015 at 10:56:32AM -0400, Peter Jones wrote:
> That said, I haven't sent my patch to add the capsule headers to gnu-efi
> yet, so you won't get very far - I'll make sure and send those this
> week, hopefully today.

Slight correction, I did actually do that - it's in the current upstream
repo.

-- 
Peter
--
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] storvsc: use KBUILD_MODNAME to fill .proc_name

[Olaf Hering]

Since the previous patch ead3700d893654d440edcb66fb3767a0c0db54cf ("storvsc:
use cmd_size to allocate per-command data") fills .proc_name now anyway give it
a usable content for v4.0. Old mkinitrd in SLES makes use of this variable to
find the required storage driver.

Signed-off-by: Olaf Hering 
---

This should go into v4.0 because ead3700d893654d440edcb66fb3767a0c0db54cf is in 
v4.0-rc1.


 drivers/scsi/storvsc_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index efc6e44..458e3d4 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1642,7 +1642,7 @@ static struct scsi_host_template scsi_driver = {
.bios_param =   storvsc_get_chs,
.queuecommand = storvsc_queuecommand,
.eh_host_reset_handler =storvsc_host_reset_handler,
-   .proc_name ="storvsc_host",
+   .proc_name =KBUILD_MODNAME,
.eh_timed_out = storvsc_eh_timed_out,
.slave_configure =  storvsc_device_configure,
.cmd_per_lun =  255,
--
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 2/2] soc: mediatek: Add PMIC wrapper for MT8135 and MT8173 SoCs

[Sascha Hauer]

From: Flora Fu 

This adds support for the PMIC wrapper found on MediaTek MT8135 and
MT8173 SoCs. The PMIC wrapper is found on MT6xxx SoCs aswell but these
are currently not supported.

On MediaTek MT8135, MT8173 and other SoCs the PMIC is connected via
SPI. The SPI master interface is not directly visible to the CPU, but
only through the PMIC wrapper inside the SoC. The communication between
the SoC and the PMIC can optionally be encrypted. Also a non standard
Dual IO SPI mode can be used to increase speed. The MT8135 also supports
a special feature named "IP Pairing". With IP Pairing the pins of some
SoC internal peripherals can be on the PMIC. The signals of these pins
are routed over the SPI bus using the pwrap bridge. Because of these
optional non SPI conform features the PMIC driver is not implemented as
a SPI bus master driver.

Signed-off-by: Flora Fu, MediaTek
Signed-off-by: Sascha Hauer 
---
 drivers/soc/Kconfig  |   1 +
 drivers/soc/Makefile |   1 +
 drivers/soc/mediatek/Kconfig |  11 +
 drivers/soc/mediatek/Makefile|   1 +
 drivers/soc/mediatek/mtk-pmic-wrap.c | 978 +++
 5 files changed, 992 insertions(+)
 create mode 100644 drivers/soc/mediatek/Kconfig
 create mode 100644 drivers/soc/mediatek/Makefile
 create mode 100644 drivers/soc/mediatek/mtk-pmic-wrap.c

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 76d6bd4..d8bde82f0 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
 menu "SOC (System On Chip) specific Drivers"
 
+source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/ti/Kconfig"
 source "drivers/soc/versatile/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 063113d..70042b2 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -2,6 +2,7 @@
 # Makefile for the Linux Kernel SOC specific device drivers.
 #
 
+obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
 obj-$(CONFIG_ARCH_QCOM)+= qcom/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
 obj-$(CONFIG_SOC_TI)   += ti/
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
new file mode 100644
index 000..bcdb22d
--- /dev/null
+++ b/drivers/soc/mediatek/Kconfig
@@ -0,0 +1,11 @@
+#
+# MediaTek SoC drivers
+#
+config MTK_PMIC_WRAP
+   tristate "MediaTek PMIC Wrapper Support"
+   depends on ARCH_MEDIATEK
+   select REGMAP
+   help
+ Say yes here to add support for MediaTek PMIC Wrapper found
+ on different MediaTek SoCs. The PMIC wrapper is a proprietary
+ hardware to connect the PMIC.
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
new file mode 100644
index 000..ecaf4de
--- /dev/null
+++ b/drivers/soc/mediatek/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
new file mode 100644
index 000..0cd8fc10
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -0,0 +1,978 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Flora Fu, MediaTek
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PWRAP_MT8135_BRIDGE_IORD_ARB_EN0x4
+#define PWRAP_MT8135_BRIDGE_WACS3_EN   0x10
+#define PWRAP_MT8135_BRIDGE_INIT_DONE3 0x14
+#define PWRAP_MT8135_BRIDGE_WACS4_EN   0x24
+#define PWRAP_MT8135_BRIDGE_INIT_DONE4 0x28
+#define PWRAP_MT8135_BRIDGE_INT_EN 0x38
+#define PWRAP_MT8135_BRIDGE_TIMER_EN   0x48
+#define PWRAP_MT8135_BRIDGE_WDT_UNIT   0x50
+#define PWRAP_MT8135_BRIDGE_WDT_SRC_EN 0x54
+
+/* macro for wrapper status */
+#define PWRAP_GET_WACS_RDATA(x)(((x) >> 0) & 0x)
+#define PWRAP_GET_WACS_FSM(x)  (((x) >> 16) & 0x0007)
+#define PWRAP_GET_WACS_REQ(x)  (((x) >> 19) & 0x0001)
+#define PWRAP_STATE_SYNC_IDLE0 (1 << 20)
+#define PWRAP_STATE_INIT_DONE0 (1 << 21)
+
+/* macro for WACS FSM */
+#define PWRAP_WACS_FSM_IDLE0x00
+#define PWRAP_WACS_FSM_REQ 0x02
+#define PWRAP_WACS_FSM_WFDLE   0x04
+#define PWRAP_WACS_FSM_WFVLDCLR0x06
+#define PWRAP_WACS_INIT_DONE   0x01
+#define PWRAP_WACS_WACS_SYNC_IDLE  0x01
+#define PWRAP_WACS_SYNC_BUSY   0x00
+
+/* macro for device wrapper default value */
+#define PWRAP_DEW_READ_TEST_VAL

[PATCH] pci: of : fix BUG: unable to handle kernel

[Murali Karicheri]

On some platforms such as that based on x86, ia64 etc, root bus is
created with parent node passed in as NULL to pci_create_root_bus().
On these platforms, the patch series "PCI: get DMA configuration from
parent device" when applied causes kernel crash. So add a check for this
in of_pci_dma_configure()

Signed-off-by: Murali Karicheri 
---
 drivers/of/of_pci.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 86d3c38..a8e485c 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -129,6 +129,10 @@ void of_pci_dma_configure(struct pci_dev *pci_dev)
struct device *dev = _dev->dev;
struct device *bridge = pci_get_host_bridge_device(pci_dev);
 
+   /* Some platforms can have bridge->parent set to NULL */
+   if (!bridge->parent)
+   return;
+
of_dma_configure(dev, bridge->parent->of_node);
pci_put_host_bridge_device(bridge);
 }
-- 
1.7.9.5

--
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 v2] Mediatek PMIC wrapper support

[Sascha Hauer]

[Note: This is v2 of this series which contains the PMIC wrapper patches only,
the patches themselves have been posted as part of other series already]

This series adds support for the PMIC wrapper found on MT8135 and
MT8173 SoCs. No further compile time dependencies.

Changes since last version:

- Remove #define DEBUG
- Remove PMIC specific register writes
- Mention other SoCs which contain a PMIC wrapper aswell

--
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 3/7] x86, boot: Don't overlap VO with ZO data

[Borislav Petkov]

On Tue, Mar 10, 2015 at 08:17:01AM -0700, Yinghai Lu wrote:
> Make it not confusing.
> 
> ZO: arch/x86/boot/compressed/vmlinux
> VO: vmlinux
> 
> setup + ZO ==> bzImage.
> 
> compressed kernel is just compressed VO.

So the two end up being the "compressed kernel" and "kernel proper".

And then the subject turns into

"Don't overlap kernel proper's brk with the compressed kernel's data section"

Does that still confuse you?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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 1/2] dt-bindings: ARM: Mediatek: document binding for the PMIC wrapper

[Sascha Hauer]

This adds documentation for the PMIC wrapper unit found on Mediatek
SoCs. Currently support are the MT8135 and MT8173 SoCs, but the PMIC
wrapper can also be found on MT6xxx and possibly other SoCs.

Signed-off-by: Sascha Hauer 
---
 .../devicetree/bindings/soc/mediatek/pwrap.txt | 58 ++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/pwrap.txt

diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt 
b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
new file mode 100644
index 000..ddeb5b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
@@ -0,0 +1,58 @@
+MediaTek PMIC Wrapper Driver
+
+This document describes the binding for the MediaTek PMIC wrapper.
+
+On MediaTek SoCs the PMIC is connected via SPI. The SPI master interface
+is not directly visible to the CPU, but only through the PMIC wrapper
+inside the SoC. The communication between the SoC and the PMIC can
+optionally be encrypted. Also a non standard Dual IO SPI mode can be
+used to increase speed.
+
+IP Pairing
+
+on MT8135 the pins of some SoC internal peripherals can be on the PMIC.
+The signals of these pins are routed over the SPI bus using the pwrap
+bridge. In the binding description below the properties needed for bridging
+are marked with "IP Pairing". These are optional on SoCs which do not support
+IP Pairing
+
+Required properties in pwrap device node.
+- compatible:
+   "mediatek,mt8135-pwrap" for MT8135 SoCs
+   "mediatek,mt8173-pwrap" for MT8173 SoCs
+- interrupts: IRQ for pwrap in SOC
+- reg-names: Must include the following entries:
+  "pwrap": Main registers base
+  "pwrap-bridge": bridge base (IP Pairing)
+- reg: Must contain an entry for each entry in reg-names.
+- reset-names: Must include the following entries:
+  "pwrap"
+  "pwrap-bridge" (IP Pairing)
+- resets: Must contain an entry for each entry in reset-names.
+- clock-names: Must include the following entries:
+  "spi": SPI bus clock
+  "wrap": Main module clock
+- clocks: Must contain an entry for each entry in clock-names.
+
+Optional properities:
+- pmic: Mediatek PMIC MFD is the child device of pwrap
+  See the following for child node definitions:
+  Documentation/devicetree/bindings/mfd/mt6397.txt
+
+Example:
+   pwrap: pwrap@1000f000 {
+   compatible = "mediatek,mt8135-pwrap";
+   reg = <0 0x1000f000 0 0x1000>,
+   <0 0x11017000 0 0x1000>;
+   reg-names = "pwrap", "pwrap-bridge";
+   interrupts = ;
+   resets = < MT8135_INFRA_PMIC_WRAP_RST>,
+   < MT8135_PERI_PWRAP_BRIDGE_SW_RST>;
+   reset-names = "pwrap", "pwrap-bridge";
+   clocks = <>, <>;
+   clock-names = "spi", "wrap";
+
+   pmic {
+   compatible = "mediatek,mt6397";
+   };
+   };
-- 
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/

Re: [RFC] shmem: Add eventfd notification on utlilization level

[Beata Michalska]

On 03/10/2015 03:22 PM, Jan Kara wrote:
> On Tue 10-03-15 06:03:23, Christoph Hellwig wrote:
>> On Tue, Mar 10, 2015 at 10:51:41AM +0900, Kyungmin Park wrote:
>>> Any updates?
>> Please just add disk quota support to tmpfs so thast the standard quota
>> netlink notifications can be used.
>   If I understand the problem at hand, they are really interested in
> notification when running out of free space. Using quota for that doesn't
> seem ideal since that tracks used space per user, not free space on fs as a
> whole.
>
> But if I remember right there were discussions about ENOSPC notification
> from filesystem for thin provisioning usecases. It would be good to make
> this consistent with those but I'm not sure if it went anywhere.
>
>   Honza

The ideal case here, would be to get the notification, despite the type
of the actual filesystem, whenever the amount of free space drops below
a certain level. Quota doesn't seem to be the right approach here.

BR
Beata Michalska

--
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: [GIT PULL v2] of: Add of-graph helpers to loop over endpoints and find ports by id

[Philipp Zabel]

Hi Grant, Rob,

Am Dienstag, den 03.03.2015, 08:59 +0100 schrieb Philipp Zabel:
> Hi Grant, Rob,
> 
> this series has been around for quite some time now, basically unchanged
> except for adding fixes for new users of the API that keep appearing
> over time in different subsystems.
> 
> It would be really helpful to get this merged for v4.0. Could you still
> make this happen?
>
> Alternatively, could I please get your ack to allow this tag to be
> merged into the other subsystem trees for v4.1 so that patches that
> depend on it don't have to wait for yet another merge window?

The question still stands. It would be great to hear from you and maybe
get this change in at least in time for v4.1.

best regards
Philipp

--
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] ceph: match wait_for_completion_timeout return type

[Nicholas Mc Guire]

return type of wait_for_completion_timeout is unsigned long not int. An
appropriately named unsigned long is added and the assignment fixed up.

Signed-off-by: Nicholas Mc Guire 
---

This was only compile tested for x86_64_defconfig + CONFIG_CEPH_FS=m

Patch is against 4.0-rc2 linux-next (localversion-next is -next-20150306)

 fs/ceph/dir.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
index 83e9976..4bee6b7 100644
--- a/fs/ceph/dir.c
+++ b/fs/ceph/dir.c
@@ -1218,6 +1218,7 @@ static int ceph_dir_fsync(struct file *file, loff_t 
start, loff_t end,
struct ceph_mds_request *req;
u64 last_tid;
int ret = 0;
+   unsigned long time_left;
 
dout("dir_fsync %p\n", inode);
ret = filemap_write_and_wait_range(inode->i_mapping, start, end);
@@ -1240,11 +1241,11 @@ static int ceph_dir_fsync(struct file *file, loff_t 
start, loff_t end,
dout("dir_fsync %p wait on tid %llu (until %llu)\n",
 inode, req->r_tid, last_tid);
if (req->r_timeout) {
-   ret = wait_for_completion_timeout(
+   time_left = wait_for_completion_timeout(
>r_safe_completion, req->r_timeout);
-   if (ret > 0)
+   if (time_left > 0)
ret = 0;
-   else if (ret == 0)
+   else if (!time_left)
ret = -EIO;  /* timed out */
} else {
wait_for_completion(>r_safe_completion);
-- 
1.7.10.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/

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Peter Jones]

On Tue, Mar 10, 2015 at 12:26:52PM +, Matt Fleming wrote:
> On Fri, 06 Mar, at 04:39:12PM, Peter Jones wrote:
> > 
> > So again: do we really need or want to do this?
> 
> One thing that we totally lose the ability to do is use the capsule
> interface for things *other* than firmware updates, e.g.
> 
>  https://lkml.org/lkml/2013/10/16/327 
> 
> Also, requiring embedded or custom OS to include fwupdate into their
> existing boot solutions is a bit heavy handed when literally all they
> want to do is cat a binary blob to a sysfs file.
> 
> I don't see why we can't have both solutions.

Yeah - we clearly need a kernel interface for some embedded devices, and
it'd be better for every vendor to not implement it themselves.

> Another thing is that ESRT isn't going to be supported by every
> platform.

Yeah - though I think you're *mostly* talking about the same platforms
as above.

> So, for the sysfs interface, let's not allow loading from /lib. Let's
> not require a userland tool. Let's just do,
> 
>   # echo /path/to/my/awesome/capsule.bin > /sys/../capsule

> 
> and be done with it.
> 
> Hmmm?

I assume you're implying a) the capsule header with the guid is embedded
in the .bin there already, and b) one contiguous write(2) with error
reporting coming through something like vars.c's efi_status_to_err()?

If so, yes, I prefer this API.

-- 
Peter
--
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 5/5] arm-cci: Fix CCI PMU event validation

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

We mask the event with the CCI_PMU_EVENT_MASK, before passing
the config to pmu_validate_hw_event(), which causes extra bits
to be ignored and qualifies an invalid event code as valid.

e.g,
 $ perf stat -a -C 0 -e CCI_400/config=0x1ff,name=cycles/ sleep 1
   Performance counter stats for 'system wide':

 506951142  cycles

   1.013879626 seconds time elapsed

where, cycles has an event coding of 0xff. This patch also removes
the unnecessary 'event' mask in pmu_write_register, since the config_base
is set by the pmu code after the event is validated.

Changes since V2:
 - Switch to input unsigned long for pmu_validate_hw_event()

Signed-off-by: Suzuki K. Poulose 
---
 drivers/bus/arm-cci.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 581190d..89c86e9 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -179,12 +179,15 @@ enum cci400_perf_events {
 #define CCI_REV_R1_MASTER_PORT_MIN_EV  0x00
 #define CCI_REV_R1_MASTER_PORT_MAX_EV  0x11
 
-static int pmu_validate_hw_event(u8 hw_event)
+static int pmu_validate_hw_event(unsigned long hw_event)
 {
u8 ev_source = CCI_PMU_EVENT_SOURCE(hw_event);
u8 ev_code = CCI_PMU_EVENT_CODE(hw_event);
int if_type;
 
+   if (hw_event & ~CCI_PMU_EVENT_MASK)
+   return -ENOENT;
+
switch (ev_source) {
case CCI_PORT_S0:
case CCI_PORT_S1:
@@ -258,7 +261,6 @@ static void pmu_enable_counter(int idx)
 
 static void pmu_set_event(int idx, unsigned long event)
 {
-   event &= CCI_PMU_EVENT_MASK;
pmu_write_register(event, idx, CCI_PMU_EVT_SEL);
 }
 
@@ -275,7 +277,7 @@ static int pmu_get_event_idx(struct cci_pmu_hw_events *hw, 
struct perf_event *ev
 {
struct cci_pmu *cci_pmu = to_cci_pmu(event->pmu);
struct hw_perf_event *hw_event = >hw;
-   unsigned long cci_event = hw_event->config_base & CCI_PMU_EVENT_MASK;
+   unsigned long cci_event = hw_event->config_base;
int idx;
 
if (cci_event == CCI_PMU_CYCLES) {
@@ -296,7 +298,7 @@ static int pmu_get_event_idx(struct cci_pmu_hw_events *hw, 
struct perf_event *ev
 static int pmu_map_event(struct perf_event *event)
 {
int mapping;
-   u8 config = event->attr.config & CCI_PMU_EVENT_MASK;
+   unsigned long config = event->attr.config;
 
if (event->attr.type < PERF_TYPE_MAX)
return -ENOENT;
-- 
1.7.9.5


--
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 4/5] arm-cci: Split the code for PMU vs driver support

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

This patch separates the PMU driver code from the low level
CCI driver code and enables the PMU driver for ARM64.

Introduces config options for both.

 ARM_CCI400_PORT_CTRL   - controls the low level driver code for
  CCI400 ports.
 ARM_CCI400_PMU - controls the PMU driver code
 ARM_CCI400_COMMON  - Common defintions for CCI400

This patch also changes:
 ARM_CCI - common code for probing the CCI devices. This can be
   used for adding support for newer CCI versions(e.g, CCI-500).

Changes since V2:
  - Make ARM_CCI400_PMU default y (Suggested-by: Sudeep Holla)
Changes since V1 (Suggestions-by: Nicolas Pitre):
  - Renames
CONFIG_ARM_CCI400_MCPM => CONFIG_ARM_CCI400_PORT_CTRL
CCI400_MCPM_PORTS_DATA => CCI400_PORTS_DATA
  - Select ARM_CCI400_COMMON for ARM_CCI400_PORT_CTRL
  - Better documentation in the git commit log about the ARM_CCI config.

Cc: Bartlomiej Zolnierkiewicz 
Cc: Kukjin Kim 
Cc: Abhilash Kesavan 
Cc: Liviu Dudau 
Cc: Lorenzo Pieralisi 
Cc: Sudeep Holla 
Cc: Nicolas Pitre 
Cc: Punit Agrawal 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm/mach-exynos/Kconfig   |2 +-
 arch/arm/mach-vexpress/Kconfig |4 ++--
 drivers/bus/Kconfig|   28 
 drivers/bus/arm-cci.c  |   24 
 include/linux/arm-cci.h|7 ++-
 5 files changed, 53 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 603820e..81064cd 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -123,7 +123,7 @@ config SOC_EXYNOS5800
 config EXYNOS5420_MCPM
bool "Exynos5420 Multi-Cluster PM support"
depends on MCPM && SOC_EXYNOS5420
-   select ARM_CCI
+   select ARM_CCI400_PORT_CTRL
select ARM_CPU_SUSPEND
help
  This is needed to provide CPU and cluster power management
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 3c2509b..daa7ab6 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -53,7 +53,7 @@ config ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA
 config ARCH_VEXPRESS_DCSCB
bool "Dual Cluster System Control Block (DCSCB) support"
depends on MCPM
-   select ARM_CCI
+   select ARM_CCI400_PORT_CTRL
help
  Support for the Dual Cluster System Configuration Block (DCSCB).
  This is needed to provide CPU and cluster power management
@@ -71,7 +71,7 @@ config ARCH_VEXPRESS_SPC
 config ARCH_VEXPRESS_TC2_PM
bool "Versatile Express TC2 power management"
depends on MCPM
-   select ARM_CCI
+   select ARM_CCI400_PORT_CTRL
select ARCH_VEXPRESS_SPC
select ARM_CPU_SUSPEND
help
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index b99729e..79e297b 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -43,12 +43,32 @@ config OMAP_INTERCONNECT
help
  Driver to enable OMAP interconnect error handling driver.
 
-config ARM_CCI
-   bool "ARM CCI driver support"
+config ARM_CCI400_PORT_CTRL
+   bool
depends on ARM && OF && CPU_V7
+   select ARM_CCI400_COMMON
+   help
+ Low level power management driver for CCI400 cache coherent
+ interconnect for ARM platforms.
+
+config ARM_CCI400_PMU
+   bool "ARM CCI400 PMU support"
+   default y
+   depends on ARM || ARM64
+   depends on HW_PERF_EVENTS
+   select ARM_CCI400_COMMON
help
- Driver supporting the CCI cache coherent interconnect for ARM
- platforms.
+ Support for PMU events monitoring on the ARM CCI cache coherent
+ interconnect.
+
+ If unsure, say Y
+
+config ARM_CCI400_COMMON
+   bool
+   select ARM_CCI
+
+config ARM_CCI
+   bool
 
 config ARM_CCN
bool "ARM CCN driver support"
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 70dff09..581190d 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -32,6 +32,7 @@
 static void __iomem *cci_ctrl_base;
 static unsigned long cci_ctrl_phys;
 
+#ifdef CONFIG_ARM_CCI400_PORT_CTRL
 struct cci_nb_ports {
unsigned int nb_ace;
unsigned int nb_ace_lite;
@@ -42,12 +43,19 @@ static const struct cci_nb_ports cci400_ports = {
.nb_ace_lite = 3
 };
 
+#define CCI400_PORTS_DATA  (_ports)
+#else
+#define CCI400_PORTS_DATA  (NULL)
+#endif
+
 static const struct of_device_id arm_cci_matches[] = {
-   {.compatible = "arm,cci-400", .data = _ports },
+#ifdef CONFIG_ARM_CCI400_COMMON
+   {.compatible = "arm,cci-400", .data = CCI400_PORTS_DATA },
+#endif
{},
 };
 
-#ifdef CONFIG_HW_PERF_EVENTS
+#ifdef CONFIG_ARM_CCI400_PMU
 
 #define DRIVER_NAME"CCI-400"
 #define DRIVER_NAME_PMUDRIVER_NAME " PMU"
@@ -1013,14 +1021,16 @@ static int __init cci_platform_init(void)
return 

[PATCH 3/5] arm-cci: Get rid of secure transactions for PMU driver

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

Avoid secure transactions while probing the CCI PMU. The
existing code makes use of the Peripheral ID2 (PID2) register
to determine the revision of the CCI400, which requires a
secure transaction. This puts a limitation on the usage of the
driver on systems running non-secure Linux(e.g, ARM64).

Updated the device-tree binding for cci pmu node to add the explicit
revision number for the compatible field.

The supported strings are :
arm,cci-400-pmu,r0
arm,cci-400-pmu,r1
arm,cci-400-pmu - DEPRECATED. See NOTE below

NOTE: If the revision is not mentioned, we need to probe the cci revision,
which could be fatal on a platform running non-secure. We need a reliable way
to know if we can poke the CCI registers at runtime on ARM32. We depend on
'mcpm_is_available()' when it is available. mcpm_is_available() returns true
only when there is a registered driver for mcpm. Otherwise, we assume that we
don't have secure access, and skips probing the revision number(ARM64 case).

The MCPM should figure out if it is safe to access the CCI. Unfortunately
there isn't a reliable way to indicate the same via dtb. This patch doesn't
address/change the current situation. It only deals with the CCI-PMU, leaving
the assumptions about the secure access as it has been, prior to this patch.

Changes since V2:
 - Use 'bool' instead of 'int' for platform_has_secure_cci_access().
   (Suggested-by: Sudeep Holla)

Cc: devicet...@vger.kernel.org
Cc: Punit Agrawal 
Signed-off-by: Suzuki K. Poulose 
---
 Documentation/devicetree/bindings/arm/cci.txt |7 +++--
 arch/arm/include/asm/arm-cci.h|   42 +
 arch/arm64/include/asm/arm-cci.h  |   27 
 drivers/bus/arm-cci.c |   17 +-
 include/linux/arm-cci.h   |2 ++
 5 files changed, 92 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/arm-cci.h
 create mode 100644 arch/arm64/include/asm/arm-cci.h

diff --git a/Documentation/devicetree/bindings/arm/cci.txt 
b/Documentation/devicetree/bindings/arm/cci.txt
index f28d82b..0e4b6a7 100644
--- a/Documentation/devicetree/bindings/arm/cci.txt
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -94,8 +94,11 @@ specific to ARM.
- compatible
Usage: required
Value type: 
-   Definition: must be "arm,cci-400-pmu"
-
+   Definition: Supported strings are :
+"arm,cci-400-pmu,r0"
+"arm,cci-400-pmu,r1"
+"arm,cci-400-pmu"  - DEPRECATED, permitted 
only where OS has
+ secure acces to CCI 
registers
- reg:
Usage: required
Value type: Integer cells. A register entry, expressed
diff --git a/arch/arm/include/asm/arm-cci.h b/arch/arm/include/asm/arm-cci.h
new file mode 100644
index 000..fe77f7a
--- /dev/null
+++ b/arch/arm/include/asm/arm-cci.h
@@ -0,0 +1,42 @@
+/*
+ * arch/arm/include/asm/arm-cci.h
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#ifndef __ASM_ARM_CCI_H
+#define __ASM_ARM_CCI_H
+
+#ifdef CONFIG_MCPM
+#include 
+
+/*
+ * We don't have a reliable way of detecting whether,
+ * if we have access to secure-only registers, unless
+ * mcpm is registered.
+ */
+static inline bool platform_has_secure_cci_access(void)
+{
+   return mcpm_is_available();
+}
+
+#else
+static inline bool platform_has_secure_cci_access(void)
+{
+   return false;
+}
+#endif
+
+#endif
diff --git a/arch/arm64/include/asm/arm-cci.h b/arch/arm64/include/asm/arm-cci.h
new file mode 100644
index 000..f0b6371
--- /dev/null
+++ b/arch/arm64/include/asm/arm-cci.h
@@ -0,0 +1,27 @@
+/*
+ * arch/arm64/include/asm/arm-cci.h
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more 

[PATCHv3 0/5] arm-cci400: PMU monitoring support on ARM64

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

This series enables the PMU monitoring support for CCI400 on ARM64.
The existing CCI400 driver code is a mix of PMU driver and the MCPM
driver code. The MCPM driver is only used on ARM(32) and contains
arm32 assembly and hence can't be built on ARM64. This patch splits
the code to

 - ARM_CCI400_PORT_CTRL driver - depends on ARM && V7
 - ARM_CCI400_PMU driver

Accessing the Peripheral ID2 register(PID2) on CCI-400, to detect
the revision of the chipset, is a secure operation. Hence, it prevents
us from running this on non-secure platforms. The issue is overcome by
explicitly mentioning the revision number of the CCI PMU in the device tree
binding. The device-tree binding has been updated with the new bindings.

i.e,arm-cci-400-pmu,r0 => revision 0
arm-cci-400-pmu,r1 => revision 1
arm-cci-400-pmu => (old) DEPRECATED

The old binding has been DEPRECATED and must be used only on ARM32
system with secure access. We don't have a reliable dynamic way to detect
if the system is running secure. This series tries to use the best safe
method by relying on the availability of MCPM(as it was prior to the series).
It is upto the MCPM platform driver to decide, if the system is secure before
it goes ahead and registers its drivers and pokes the CCI. This series doesn't
address/solve the problem of MCPM. I will be happy to use a better approach,
if there is any.

Tested on (non-secure)TC2 and A53x2.

Changes sinve V2

 - Include suggestions from Sudeep Holla.
 - Cleanup event validation checks.

Changes since V1 (Suggestions from Nicolas Pitre):

 - Split Patch 2 to separate the 'PMU' abstraction(now Patch 2/5)
   from the introduction of a new device-tree binding(now Patch 3/5)
 - Rename
ARM_CCI400_MCPM => ARM_CCI400_PORT_CTRL
CCI400_MCPM_PORTS_DATA => CCI400_PORTS_DATA
 - Select ARM_CCI400_COMMON for ARM_CCI400_PORT_CTRL
 - Better documentation in the git commit log about the ARM_CCI config.
 - Move the 'pr_info' to its apporpriate patch.


Suzuki K. Poulose (5):
  arm-cci: Rearrange code for splitting PMU vs driver code
  arm-cci: Abstract the CCI400 PMU speicific definitions
  arm-cci: Get rid of secure transactions for PMU driver
  arm-cci: Split the code for PMU vs driver support
  arm-cci: Fix CCI PMU event validation

 Documentation/devicetree/bindings/arm/cci.txt |7 +-
 arch/arm/include/asm/arm-cci.h|   42 +++
 arch/arm/mach-exynos/Kconfig  |2 +-
 arch/arm/mach-vexpress/Kconfig|4 +-
 arch/arm64/include/asm/arm-cci.h  |   27 ++
 drivers/bus/Kconfig   |   28 +-
 drivers/bus/arm-cci.c |  496 ++---
 include/linux/arm-cci.h   |9 +-
 8 files changed, 384 insertions(+), 231 deletions(-)
 create mode 100644 arch/arm/include/asm/arm-cci.h
 create mode 100644 arch/arm64/include/asm/arm-cci.h

-- 
1.7.9.5


--
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 2/5] arm-cci: Abstract the CCI400 PMU speicific definitions

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

CCI400 has different event specifications for PMU, for revsion
0 and revision 1. As of now, we check the revision every single
time before using the parameters for the PMU. This patch abstracts
the details of the pmu models in a struct (cci_pmu_model) and
stores the information in cci_pmu at initialisation time, avoiding
multiple probe operations.

Changes since V2:
 - Cleanup event validation(pmu_validate_hw_event). Get rid of
   helper functions:
pmu_is_valid_slave_event
pmu_is_valid_master_event

Signed-off-by: Suzuki K. Poulose 
---
 drivers/bus/arm-cci.c |  141 -
 1 file changed, 81 insertions(+), 60 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index ea39fc2..f88383e 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -79,19 +79,38 @@ static const struct of_device_id arm_cci_matches[] = {
 
 #define CCI_PMU_MAX_HW_EVENTS 5   /* CCI PMU has 4 counters + 1 cycle counter 
*/
 
+/* Types of interfaces that can generate events */
+enum {
+   CCI_IF_SLAVE,
+   CCI_IF_MASTER,
+   CCI_IF_MAX,
+};
+
+struct event_range {
+   u32 min;
+   u32 max;
+};
+
 struct cci_pmu_hw_events {
struct perf_event *events[CCI_PMU_MAX_HW_EVENTS];
unsigned long used_mask[BITS_TO_LONGS(CCI_PMU_MAX_HW_EVENTS)];
raw_spinlock_t pmu_lock;
 };
 
+struct cci_pmu_model {
+   char *name;
+   struct event_range event_ranges[CCI_IF_MAX];
+};
+
+static struct cci_pmu_model cci_pmu_models[];
+
 struct cci_pmu {
void __iomem *base;
struct pmu pmu;
int nr_irqs;
int irqs[CCI_PMU_MAX_HW_EVENTS];
unsigned long active_irqs;
-   struct pmu_port_event_ranges *port_ranges;
+   const struct cci_pmu_model *model;
struct cci_pmu_hw_events hw_events;
struct platform_device *plat_device;
int num_events;
@@ -152,53 +171,11 @@ enum cci400_perf_events {
 #define CCI_REV_R1_MASTER_PORT_MIN_EV  0x00
 #define CCI_REV_R1_MASTER_PORT_MAX_EV  0x11
 
-struct pmu_port_event_ranges {
-   u8 slave_min;
-   u8 slave_max;
-   u8 master_min;
-   u8 master_max;
-};
-
-static struct pmu_port_event_ranges port_event_range[] = {
-   [CCI_REV_R0] = {
-   .slave_min = CCI_REV_R0_SLAVE_PORT_MIN_EV,
-   .slave_max = CCI_REV_R0_SLAVE_PORT_MAX_EV,
-   .master_min = CCI_REV_R0_MASTER_PORT_MIN_EV,
-   .master_max = CCI_REV_R0_MASTER_PORT_MAX_EV,
-   },
-   [CCI_REV_R1] = {
-   .slave_min = CCI_REV_R1_SLAVE_PORT_MIN_EV,
-   .slave_max = CCI_REV_R1_SLAVE_PORT_MAX_EV,
-   .master_min = CCI_REV_R1_MASTER_PORT_MIN_EV,
-   .master_max = CCI_REV_R1_MASTER_PORT_MAX_EV,
-   },
-};
-
-/*
- * Export different PMU names for the different revisions so userspace knows
- * because the event ids are different
- */
-static char *const pmu_names[] = {
-   [CCI_REV_R0] = "CCI_400",
-   [CCI_REV_R1] = "CCI_400_r1",
-};
-
-static int pmu_is_valid_slave_event(u8 ev_code)
-{
-   return pmu->port_ranges->slave_min <= ev_code &&
-   ev_code <= pmu->port_ranges->slave_max;
-}
-
-static int pmu_is_valid_master_event(u8 ev_code)
-{
-   return pmu->port_ranges->master_min <= ev_code &&
-   ev_code <= pmu->port_ranges->master_max;
-}
-
 static int pmu_validate_hw_event(u8 hw_event)
 {
u8 ev_source = CCI_PMU_EVENT_SOURCE(hw_event);
u8 ev_code = CCI_PMU_EVENT_CODE(hw_event);
+   int if_type;
 
switch (ev_source) {
case CCI_PORT_S0:
@@ -207,18 +184,22 @@ static int pmu_validate_hw_event(u8 hw_event)
case CCI_PORT_S3:
case CCI_PORT_S4:
/* Slave Interface */
-   if (pmu_is_valid_slave_event(ev_code))
-   return hw_event;
+   if_type = CCI_IF_SLAVE;
break;
case CCI_PORT_M0:
case CCI_PORT_M1:
case CCI_PORT_M2:
/* Master Interface */
-   if (pmu_is_valid_master_event(ev_code))
-   return hw_event;
+   if_type = CCI_IF_MASTER;
break;
+   default:
+   return -ENOENT;
}
 
+   if (ev_code >= pmu->model->event_ranges[if_type].min &&
+   ev_code <= pmu->model->event_ranges[if_type].max)
+   return hw_event;
+
return -ENOENT;
 }
 
@@ -234,11 +215,9 @@ static int probe_cci_revision(void)
return CCI_REV_R1;
 }
 
-static struct pmu_port_event_ranges *port_range_by_rev(void)
+static const struct cci_pmu_model *probe_cci_model(struct platform_device 
*pdev)
 {
-   int rev = probe_cci_revision();
-
-   return _event_range[rev];
+   return _pmu_models[probe_cci_revision()];
 }
 
 static int pmu_is_valid_counter(struct cci_pmu *cci_pmu, int idx)
@@ -807,9 +786,9 @@ static const struct attribute_group 

Re: [PATCH v2 1/2] cgroups: allow a cgroup subsystem to reject a fork

[Tejun Heo]

Hello,

On Wed, Mar 11, 2015 at 01:51:06AM +1100, Aleksa Sarai wrote:
> Actually, I'm fairly sure we can do it all inside cgroup_post_fork() because
> inside cgroup_post_fork() we have access to both the old css_set and the new
> one. Then it's just a matter of reverting and re-applying the charge to the
> hierarchies.

But the problem isn't whether we know both the old and new ones.  The
problem is that we can only abort before the fork commit point and the
"old" one may change between the abort point and post-commit point so
we need to trycharge the old one at the possible abort point, remember
to which css it got charged and then check whether the association has
changed inbetween at the post commit point and readjust if so.

Thanks.

-- 
tejun
--
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 1/5] arm-cci: Rearrange code for splitting PMU vs driver code

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

No functional changes, only code re-arrangements for easier split of the
PMU code vs low level driver code. Extracts the port handling code
to cci_probe_ports().

Change since V2:
 - Removed unnecessary goto. (Suggested-by: Sudeep Holla)

Signed-off-by: Suzuki K. Poulose 
---
 drivers/bus/arm-cci.c |  326 -
 1 file changed, 163 insertions(+), 163 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 84fd660..ea39fc2 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -29,42 +29,29 @@
 #include 
 #include 
 
-#define DRIVER_NAME"CCI-400"
-#define DRIVER_NAME_PMUDRIVER_NAME " PMU"
-
-#define CCI_PORT_CTRL  0x0
-#define CCI_CTRL_STATUS0xc
-
-#define CCI_ENABLE_SNOOP_REQ   0x1
-#define CCI_ENABLE_DVM_REQ 0x2
-#define CCI_ENABLE_REQ (CCI_ENABLE_SNOOP_REQ | CCI_ENABLE_DVM_REQ)
+static void __iomem *cci_ctrl_base;
+static unsigned long cci_ctrl_phys;
 
 struct cci_nb_ports {
unsigned int nb_ace;
unsigned int nb_ace_lite;
 };
 
-enum cci_ace_port_type {
-   ACE_INVALID_PORT = 0x0,
-   ACE_PORT,
-   ACE_LITE_PORT,
+static const struct cci_nb_ports cci400_ports = {
+   .nb_ace = 2,
+   .nb_ace_lite = 3
 };
 
-struct cci_ace_port {
-   void __iomem *base;
-   unsigned long phys;
-   enum cci_ace_port_type type;
-   struct device_node *dn;
+static const struct of_device_id arm_cci_matches[] = {
+   {.compatible = "arm,cci-400", .data = _ports },
+   {},
 };
 
-static struct cci_ace_port *ports;
-static unsigned int nb_cci_ports;
-
-static void __iomem *cci_ctrl_base;
-static unsigned long cci_ctrl_phys;
-
 #ifdef CONFIG_HW_PERF_EVENTS
 
+#define DRIVER_NAME"CCI-400"
+#define DRIVER_NAME_PMUDRIVER_NAME " PMU"
+
 #define CCI_PMCR   0x0100
 #define CCI_PID2   0x0fe8
 
@@ -75,6 +62,47 @@ static unsigned long cci_ctrl_phys;
 #define CCI_PID2_REV_MASK  0xf0
 #define CCI_PID2_REV_SHIFT 4
 
+#define CCI_PMU_EVT_SEL0x000
+#define CCI_PMU_CNTR   0x004
+#define CCI_PMU_CNTR_CTRL  0x008
+#define CCI_PMU_OVRFLW 0x00c
+
+#define CCI_PMU_OVRFLW_FLAG1
+
+#define CCI_PMU_CNTR_BASE(idx) ((idx) * SZ_4K)
+
+#define CCI_PMU_CNTR_MASK  ((1ULL << 32) -1)
+
+#define CCI_PMU_EVENT_MASK 0xff
+#define CCI_PMU_EVENT_SOURCE(event)((event >> 5) & 0x7)
+#define CCI_PMU_EVENT_CODE(event)  (event & 0x1f)
+
+#define CCI_PMU_MAX_HW_EVENTS 5   /* CCI PMU has 4 counters + 1 cycle counter 
*/
+
+struct cci_pmu_hw_events {
+   struct perf_event *events[CCI_PMU_MAX_HW_EVENTS];
+   unsigned long used_mask[BITS_TO_LONGS(CCI_PMU_MAX_HW_EVENTS)];
+   raw_spinlock_t pmu_lock;
+};
+
+struct cci_pmu {
+   void __iomem *base;
+   struct pmu pmu;
+   int nr_irqs;
+   int irqs[CCI_PMU_MAX_HW_EVENTS];
+   unsigned long active_irqs;
+   struct pmu_port_event_ranges *port_ranges;
+   struct cci_pmu_hw_events hw_events;
+   struct platform_device *plat_device;
+   int num_events;
+   atomic_t active_events;
+   struct mutex reserve_mutex;
+   cpumask_t cpus;
+};
+static struct cci_pmu *pmu;
+
+#define to_cci_pmu(c)  (container_of(c, struct cci_pmu, pmu))
+
 /* Port ids */
 #define CCI_PORT_S00
 #define CCI_PORT_S11
@@ -89,17 +117,6 @@ static unsigned long cci_ctrl_phys;
 #define CCI_REV_R1 1
 #define CCI_REV_R1_PX  5
 
-#define CCI_PMU_EVT_SEL0x000
-#define CCI_PMU_CNTR   0x004
-#define CCI_PMU_CNTR_CTRL  0x008
-#define CCI_PMU_OVRFLW 0x00c
-
-#define CCI_PMU_OVRFLW_FLAG1
-
-#define CCI_PMU_CNTR_BASE(idx) ((idx) * SZ_4K)
-
-#define CCI_PMU_CNTR_MASK  ((1ULL << 32) -1)
-
 /*
  * Instead of an event id to monitor CCI cycles, a dedicated counter is
  * provided. Use 0xff to represent CCI cycles and hope that no future revisions
@@ -109,12 +126,6 @@ enum cci400_perf_events {
CCI_PMU_CYCLES = 0xff
 };
 
-#define CCI_PMU_EVENT_MASK 0xff
-#define CCI_PMU_EVENT_SOURCE(event)((event >> 5) & 0x7)
-#define CCI_PMU_EVENT_CODE(event)  (event & 0x1f)
-
-#define CCI_PMU_MAX_HW_EVENTS 5   /* CCI PMU has 4 counters + 1 cycle counter 
*/
-
 #define CCI_PMU_CYCLE_CNTR_IDX 0
 #define CCI_PMU_CNTR0_IDX  1
 #define CCI_PMU_CNTR_LAST(cci_pmu) (CCI_PMU_CYCLE_CNTR_IDX + 
cci_pmu->num_events - 1)
@@ -172,60 +183,6 @@ static char *const pmu_names[] = {
[CCI_REV_R1] = "CCI_400_r1",
 };
 
-struct cci_pmu_hw_events {
-   struct perf_event *events[CCI_PMU_MAX_HW_EVENTS];
-   unsigned long used_mask[BITS_TO_LONGS(CCI_PMU_MAX_HW_EVENTS)];
-   raw_spinlock_t pmu_lock;
-};
-
-struct cci_pmu {
-   void __iomem *base;
-   struct pmu pmu;
-   int nr_irqs;
-   int irqs[CCI_PMU_MAX_HW_EVENTS];
-   unsigned long active_irqs;
-   

[PATCH] crypto: DRBG return code handling inside testmgr.c

[Alexander Bergmann]

Hi Herbert,

I just fixed a small DRBG return code issue inside testmgr.c directly 
related to the RNG changes Stephan submitted.


Regards,
Alex

-- 
Alexander Bergmann , Security Engineer,
SUSE Linux GmbH,
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
From 4348e8ae9361284c9bdd591a4e5988d575daa736 Mon Sep 17 00:00:00 2001
From: Alexander Bergmann 
Date: Tue, 10 Mar 2015 16:05:22 +0100
Subject: [PATCH] crypto: DRBG return code handling inside testmgr.c

This is a follow-up fix for the "RNGs must return 0 in success case"
changes. The drbg_cavs_test function has to handle the DRBG return codes
correctly as 0 is not an error anymore.

Signed-off-by: Alexander Bergmann 
---
 crypto/testmgr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index f4ed6d4..01b6967 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1759,7 +1759,7 @@ static int drbg_cavs_test(struct drbg_testvec *test, int pr,
 		ret = crypto_drbg_get_bytes_addtl(drng,
 			buf, test->expectedlen, );
 	}
-	if (ret <= 0) {
+	if (ret < 0) {
 		printk(KERN_ERR "alg: drbg: could not obtain random data for "
 		   "driver %s\n", driver);
 		goto outbuf;
@@ -1774,7 +1774,7 @@ static int drbg_cavs_test(struct drbg_testvec *test, int pr,
 		ret = crypto_drbg_get_bytes_addtl(drng,
 			buf, test->expectedlen, );
 	}
-	if (ret <= 0) {
+	if (ret < 0) {
 		printk(KERN_ERR "alg: drbg: could not obtain random data for "
 		   "driver %s\n", driver);
 		goto outbuf;
-- 
1.8.1.4



signature.asc
Description: Digital signature

Re: [PATCH v3 3/7] x86, boot: Don't overlap VO with ZO data

[Yinghai Lu]

On Tue, Mar 10, 2015 at 8:10 AM, Borislav Petkov  wrote:
> On Tue, Mar 10, 2015 at 08:05:52AM -0700, Yinghai Lu wrote:
>> We need to keep VO and ZO here...
>
> Why?

Make it not confusing.

ZO: arch/x86/boot/compressed/vmlinux
VO: vmlinux

setup + ZO ==> bzImage.

compressed kernel is just compressed VO.

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] mfd: menelaus: rmove incorrect __exit markups

[Lee Jones]

On Mon, 09 Mar 2015, Dmitry Torokhov wrote:

> Even if bus is not hot-pluggable, the devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_probe() which specifically disables sysfs bind/unbind
> attributes.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/mfd/menelaus.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
> index 9f01aef..5269ff2 100644
> --- a/drivers/mfd/menelaus.c
> +++ b/drivers/mfd/menelaus.c
> @@ -1259,7 +1259,7 @@ fail:
>   return err;
>  }
>  
> -static int __exit menelaus_remove(struct i2c_client *client)
> +static int menelaus_remove(struct i2c_client *client)
>  {
>   struct menelaus_chip*menelaus = i2c_get_clientdata(client);
>  
> @@ -1280,7 +1280,7 @@ static struct i2c_driver menelaus_i2c_driver = {
>   .name   = DRIVER_NAME,
>   },
>   .probe  = menelaus_probe,
> - .remove = __exit_p(menelaus_remove),
> + .remove = menelaus_remove,
>   .id_table   = menelaus_id,
>  };
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 2/7] x86, boot: Move ZO to end of buffer

[Borislav Petkov]

On Tue, Mar 10, 2015 at 08:11:03AM -0700, Yinghai Lu wrote:
> Also stop using "compressed kernel" please, that is confusing.

Why?

> Just use
> 
> ZO: arch/x86/boot/compressed/vmlinux
> VO: vmlinux

and this is not confusing?

Yeah, right.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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 1/7] Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl()

[Greg KH]

On Tue, Mar 10, 2015 at 03:05:26PM +, KY Srinivasan wrote:
> 
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Tuesday, March 10, 2015 12:42 AM
> > To: KY Srinivasan
> > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com
> > Subject: Re: [PATCH V2 1/7] Drivers: hv: vmbus: Export the
> > vmbus_sendpacket_pagebuffer_ctl()
> > 
> > On Fri, Mar 06, 2015 at 11:04:28PM -0800, K. Y. Srinivasan wrote:
> > > Export the vmbus_sendpacket_pagebuffer_ctl() interface.
> > 
> > Why?  Nothing in this patch needs it.  Please include this in the patch that
> > needs the symbol, or at least give a hint as to what is going on.
> > 
> > As it is, this just looks like a random export for no reason at all :(
> 
> This will be used by Hyper-V networking driver to optimize signaling on
> the send path. I wanted these patches committed before I sent the networking
> patch to David Miller. I implemented the two vmbus APIs for sending messages:
> 1) vmbus_sendpacket_ctl()
> 2) vmbus_sendpacket_pagebuffer_ctl()
> 
> and I forgot to export the second form of the send API in an earlier 
> patch-set that you have
> already  committed. I need both to be exported to
> for the netvsc patch I have.

Then just send it as part of the netvsc patches please.

> On a different note, upstream Linux is currently broken on Hyper-V and a 
> patch in this set
> Fixes it:
> 0002-Drivers-hv-vmbus-Perform-device-register-in-the-per-.patch

That should have been pointed out somewhere :)

> Do you want me to resend this set?

Yes, please do.  Break it up into two different sets, one for 4.0-final,
and one for 4.1-rc1.

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 2/9] selftests: Add install target

[Shuah Khan]

On 03/09/2015 04:29 PM, Shuah Khan wrote:
> On 03/09/2015 08:20 AM, Shuah Khan wrote:
>> On 03/05/2015 11:53 AM, Dave Jones wrote:
>>> On Tue, Mar 03, 2015 at 03:51:35PM +1100, Michael Ellerman wrote:
>>>  > This adds make install support to selftests. The basic usage is:
>>>  > 
>>>  > $ cd tools/testing/selftests
>>>  > $ make install
>>>  > 
>>>  > That installs into tools/testing/selftests/install, which can then be
>>>  > copied where ever necessary.
>>>  > 
>>>  > The install destination is also configurable using eg:
>>>  > 
>>>  > $ INSTALL_PATH=/mnt/selftests make install
>>>
>>>  ...
>>>
>>>  > +@# Ask all targets to emit their test scripts
>>>  > +echo "#!/bin/bash\n\n" > $(ALL_SCRIPT)
>>>
>>> $ ./all.sh 
>>> -bash: ./all.sh: /bin/bash\n\n: bad interpreter: No such file or directory
>>>
>>> Removing the \n\n fixes it.
>>>
>>>  > +echo "cd \$$ROOT\n" >> $(ALL_SCRIPT); \
>>>
>>> ditto
>>>
>>> Dave
>>
>> Michael,
>>
>> Could you please fix these problems and send the patch.
>>
> 
> Michael,
> 
> Did you happen to run run_kselftest.sh from the install
> directory to make sure all the dependent executables
> are installed? You are missing a few required dependencies.
> efivars test for example.
> 
> Please run kselftest_install.sh I sent out for review and
> compare the following:
> 
> - contents of install directory created with your patch vs.
>   my kselftest_install.sh tool
> - Compare your run_kselftest.sh run with the one that gets
>   generated with my kselftest_install.sh tool
> 
> General rule is all tests that get run when run_tests target
> is run should run from the install directory using the
> run_kselftest.sh generated during install.
> 

Couple more things. Please change the install directory name
to kselftest

tools/testing/selftests/kselftest
instead of
tools/testing/selftests/install

Also please flatten the directory structure under the install
directory. I don't see any value in creating directory for each
test for install. Also it is makes it cumbersome for users
to navigate and work with after the install. This would mean cpu
and memory hot-plug scripts need unique names.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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 v3] drivers/core/of: Add symlink to device-tree from devices with an OF node

[Greg Kroah-Hartman]

On Tue, Mar 10, 2015 at 09:22:51AM -0500, Rob Herring wrote:
> On Wed, Feb 18, 2015 at 3:50 AM, Benjamin Herrenschmidt
>  wrote:
> > On Tue, 2015-02-17 at 20:57 -0800, Greg Kroah-Hartman wrote:
> >
> >> > Acked-by: Rob Herring 
> >>
> >> Thanks, I'll queue these up after 3.20-rc1 is out.
> 
> It doesn't look like these 2 patches got applied.

My queue is still large, I'm still digging through it...
--
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 3/7] x86, boot: Don't overlap VO with ZO data

[Borislav Petkov]

On Tue, Mar 10, 2015 at 08:05:52AM -0700, Yinghai Lu wrote:
> We need to keep VO and ZO here...

Why?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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 1/6] zram: remove `num_migrated' device attr

[Sergey Senozhatsky]

Remove sysfs `num_migrated' attribute. We are moving away from
per-stat device attrs towards 3 stat files that will accumulate
io and mm stats in a format similar to block layer statistics in
/sys/block//stat. That will be easier to use in user space,
and reduce the number of syscalls needed to read zram device
statistics.

`num_migrated' will return back in zram/mm_stat file.

Signed-off-by: Sergey Senozhatsky 
---
 Documentation/ABI/testing/sysfs-block-zram | 7 ---
 drivers/block/zram/zram_drv.c  | 2 --
 2 files changed, 9 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-block-zram 
b/Documentation/ABI/testing/sysfs-block-zram
index bede902..91ad707 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -149,10 +149,3 @@ Description:
The compact file is write-only and trigger compaction for
allocator zrm uses. The allocator moves some objects so that
it could free fragment space.
-
-What:  /sys/block/zram/num_migrated
-Date:  August 2015
-Contact:   Minchan Kim 
-Description:
-   The compact file is read-only and shows how many object
-   migrated by compaction.
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 87f6671..2009a5a 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -392,7 +392,6 @@ ZRAM_ATTR_RO(invalid_io);
 ZRAM_ATTR_RO(notify_free);
 ZRAM_ATTR_RO(zero_pages);
 ZRAM_ATTR_RO(compr_data_size);
-ZRAM_ATTR_RO(num_migrated);
 
 static inline bool zram_meta_get(struct zram *zram)
 {
@@ -1069,7 +1068,6 @@ static struct attribute *zram_disk_attrs[] = {
_attr_num_writes.attr,
_attr_failed_reads.attr,
_attr_failed_writes.attr,
-   _attr_num_migrated.attr,
_attr_compact.attr,
_attr_invalid_io.attr,
_attr_notify_free.attr,
-- 
2.3.2.209.gd67f9d5

--
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 2/7] x86, boot: Move ZO to end of buffer

[Yinghai Lu]

On Tue, Mar 10, 2015 at 1:00 AM, Borislav Petkov  wrote:
> Final patch:
>
> ---
> From: Yinghai Lu 
> Date: Sat, 7 Mar 2015 14:07:16 -0800
> Subject: [PATCH] x86/setup: Move compressed kernel to the end of the buffer

setup should only about arch/x86/boot/setup.ld related.

So please keep x86, boot.

Also stop using "compressed kernel" please, that is confusing.

Just use

ZO: arch/x86/boot/compressed/vmlinux
VO: vmlinux

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 v2 11/18] pinctrl: Add pinctrl driver for STM32 MCUs

[Arnd Bergmann]

On Friday 20 February 2015 19:01:10 Maxime Coquelin wrote:
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/pinctrl-stm32.h
> @@ -0,0 +1,43 @@
> +#ifndef _DT_BINDINGS_PINCTRL_STM32_H
> +#define _DT_BINDINGS_PINCTRL_STM32_H
> +
> +/* Modes */
> +#define IN 0
> +#define OUT1
> +#define ALT2
> +#define ANALOG 3

I think it's better to prefix all the names with a
string to identify what they are for, otherwise these
are way too generic.

> +/* Alternate functions */
> +#define ALT0   ((0 << 2) | ALT)
> +#define ALT1   ((1 << 2) | ALT)
> +#define ALT2   ((2 << 2) | ALT)
> +#define ALT3   ((3 << 2) | ALT)
> +#define ALT4   ((4 << 2) | ALT)
> +#define ALT5   ((5 << 2) | ALT)
> +#define ALT6   ((6 << 2) | ALT)
> +#define ALT7   ((7 << 2) | ALT)
> +#define ALT8   ((8 << 2) | ALT)
> +#define ALT9   ((9 << 2) | ALT)
> +#define ALT10  ((10 << 2) | ALT)
> +#define ALT11  ((11 << 2) | ALT)
> +#define ALT12  ((12 << 2) | ALT)
> +#define ALT13  ((13 << 2) | ALT)
> +#define ALT14  ((14 << 2) | ALT)
> +#define ALT15  ((15 << 2) | ALT)

You can have a single macro for these like

#define STM32_PIN_ALT(x) ((x << 2) | ALT)

> +/* Pull-Up/Down */
> +#define NO_PULL0
> +#define PULL_UP1
> +#define PULL_DOWN  2
> +
> +/* Type */
> +#define PUSH_PULL  (0 << 2)
> +#define OPEN_DRAIN (1 << 2)
> +

These should probably not be stm32 specific at all, they sound
rather generic, so maybe put the definitions into a common file.



Arnd
--
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] staging: sm750fb: Cleanup the type of mmio750

[Greg KH]

On Tue, Mar 10, 2015 at 01:27:48PM +, Lorenzo Stoakes wrote:
> This patch assigns the more appropriate void* type to the mmio750 variable
> eliminating an unnecessary volatile qualifier in the process. Additionally it
> updates parameter types as necessary where those parameters interact with
> mmio750, removes unnecessary casts and updates the type of the
> lynx_share->pvReg field which is passed to the ddk750_set_mmio method.
> 
> As a consequence, this patch fixes the following sparse warning:-
> 
> drivers/staging/sm750fb/ddk750_help.c:12:17: warning: incorrect type in 
> assignment (different address spaces)
> 
> Signed-off-by: Lorenzo Stoakes 
> 
> ---
>  drivers/staging/sm750fb/ddk750_chip.h |  4 +++-
>  drivers/staging/sm750fb/ddk750_help.c |  4 ++--
>  drivers/staging/sm750fb/ddk750_help.h | 10 +-
>  drivers/staging/sm750fb/sm750.h   |  2 +-
>  4 files changed, 11 insertions(+), 9 deletions(-)

This doesn't apply either anymore, for the same reason :(
--
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/pmu: Reject groups spanning multiple hardware PMUs

[Mark Rutland]

> I think we could still solve this problem by deferring the 'context'
> validation to the core. The PMUs could validate the group, within its
> context. i.e, if it can accommodate its events as a group, during 
> event_init.  The problem we face now, is encountering an event from a 
> different PMU, which we could leave it to the core as we do already.

Good point: we're not reliant on other drivers because the core will
still check the context. We only hope that those other drivers don't
make similar mistakes and corrupt things.

[...]

>   static int
> -validate_event(struct pmu_hw_events *hw_events,
> -struct perf_event *event)
> +validate_event(struct pmu *pmu, struct pmu_hw_events *hw_events,
> +struct perf_event *event)
>   {
> - struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> + struct arm_pmu *armpmu;
> 
>   if (is_software_event(event))
>   return 1;
> 
> + /*
> +  * We are only worried if we can accommodate the events
> +  * from this pmu in this group.
> +  */
> + if (event->pmu != pmu)
> + return 1;

It's better to explicitly reject this case. We know it's non-sensical
and there's no point wasting any time on it. That will also make
big.LITTLE support a bit nicer, whenever I get that under control -- big
and LITTLE events could live in the same task context (so the core won't
reject grouping them) but mustn't be in the same group (so we have to
reject grouping in the backend).

I'd still prefer the group validation being triggered explicitly by the
core code, so that it's logically separate from initialising the event
in isolation, but that's looking like a much bigger job, and I don't
trust myself to correctly update every PMU driver for v4.0.

For the moment let's clean up the commit message for the original patch.
I'll add splitting group validation to my TODO list; there seems to be a
slot free around 2035...

Thanks,
Mark.
--
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 6/6] zram: export new 'mm_stat' sysfs attrs

[Sergey Senozhatsky]

Per-device `zram/mm_stat' file provides accumulated mm statistics
of particular zram device in a format similar to block layer statistics.
The file consists of a single line and represents the following stats
(separated by whitespace):
orig_data_size
compr_data_size
mem_used_total
mem_limit
mem_used_max
zero_pages
num_migrated

Since now we have three stat files (block layer zram/stat,
zram/io_stat and zram/mm_stat) document WARNING about
per-stat sysfs nodes being deprecated.

Signed-off-by: Sergey Senozhatsky 
---
 Documentation/ABI/testing/sysfs-block-zram |  8 
 Documentation/blockdev/zram.txt| 18 +
 drivers/block/zram/zram_drv.c  | 31 ++
 3 files changed, 57 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-block-zram 
b/Documentation/ABI/testing/sysfs-block-zram
index a7f622f..8114c81 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -158,3 +158,11 @@ Description:
statistics not accounted by block layer. For example,
failed_reads, failed_writes, etc. File format is similar to
block layer statistics file format.
+
+What:  /sys/block/zram/mm_stat
+Date:  August 2015
+Contact:   Sergey Senozhatsky 
+Description:
+   The mm_stat file is read-only and accumulates device's mm
+   statistics (orig_data_size, compr_data_size, etc.) in a format
+   similar to block layer statistics file format.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index eb62792..faf6270 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -148,6 +148,10 @@ num_migrated  ROthe number of objects migrated by 
compaction
 compact   WOtrigger memory compaction
 
 
+WARNING, per-stat sysfs attributes are considered to be deprecated and will
+eventually be removed. User space is advised to use the following files to
+read the device statistics.
+
 File /sys/block/zram/stat
 
 Represents block layer statistics. Read Documentation/block/stat.txt for
@@ -165,6 +169,20 @@ whitespace:
invalid_io
notify_free
 
+
+File /sys/block/zram/mm_stat
+
+The stat file represents device's mm statistics. It consists of a single
+line of text and contains the following stats separated by whitespace:
+   orig_data_size
+   compr_data_size
+   mem_used_total
+   mem_limit
+   mem_used_max
+   zero_pages
+   num_migrated
+
+
 9) Deactivate:
swapoff /dev/zram0
umount /dev/zram1
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index c02121f..7493096 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -402,7 +402,37 @@ static ssize_t io_stat_show(struct device *dev,
return ret;
 }
 
+static ssize_t mm_stat_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct zram *zram = dev_to_zram(dev);
+   u64 orig_size, mem_used = 0;
+   long max_used;
+   ssize_t ret;
+
+   down_read(>init_lock);
+   if (init_done(zram))
+   mem_used = zs_get_total_pages(zram->meta->mem_pool);
+
+   orig_size = atomic64_read(>stats.pages_stored);
+   max_used = atomic_long_read(>stats.max_used_pages);
+
+   ret = scnprintf(buf, PAGE_SIZE,
+   "%8llu %8llu %8llu %8lu %8ld %8llu %8llu\n",
+   orig_size << PAGE_SHIFT,
+   (u64)atomic64_read(>stats.compr_data_size),
+   mem_used << PAGE_SHIFT,
+   zram->limit_pages << PAGE_SHIFT,
+   max_used << PAGE_SHIFT,
+   (u64)atomic64_read(>stats.zero_pages),
+   (u64)atomic64_read(>stats.num_migrated));
+   up_read(>init_lock);
+
+   return ret;
+}
+
 static DEVICE_ATTR_RO(io_stat);
+static DEVICE_ATTR_RO(mm_stat);
 ZRAM_ATTR_RO(num_reads);
 ZRAM_ATTR_RO(num_writes);
 ZRAM_ATTR_RO(failed_reads);
@@ -1105,6 +1135,7 @@ static struct attribute *zram_disk_attrs[] = {
_attr_max_comp_streams.attr,
_attr_comp_algorithm.attr,
_attr_io_stat.attr,
+   _attr_mm_stat.attr,
NULL,
 };
 
-- 
2.3.2.209.gd67f9d5

--
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 5/6] zram: export new 'io_stat' sysfs attrs

[Sergey Senozhatsky]

Per-device `zram/io_stat' file provides accumulated I/O statistics
of particular zram device in a format similar to block layer statistics.
The file consists of a single line and represents the following stats
(separated by whitespace):
failed_reads
failed_writes
invalid_io
notify_free

Signed-off-by: Sergey Senozhatsky 
---
 Documentation/ABI/testing/sysfs-block-zram |  9 +
 Documentation/blockdev/zram.txt| 12 
 drivers/block/zram/zram_drv.c  | 20 
 3 files changed, 41 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-block-zram 
b/Documentation/ABI/testing/sysfs-block-zram
index 91ad707..a7f622f 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -149,3 +149,12 @@ Description:
The compact file is write-only and trigger compaction for
allocator zrm uses. The allocator moves some objects so that
it could free fragment space.
+
+What:  /sys/block/zram/io_stat
+Date:  August 2015
+Contact:   Sergey Senozhatsky 
+Description:
+   The io_stat file is read-only and accumulates device's I/O
+   statistics not accounted by block layer. For example,
+   failed_reads, failed_writes, etc. File format is similar to
+   block layer statistics file format.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 149b49a..eb62792 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -153,6 +153,18 @@ File /sys/block/zram/stat
 Represents block layer statistics. Read Documentation/block/stat.txt for
 details.
 
+
+File /sys/block/zram/io_stat
+
+The stat file represents device's I/O statistics not accounted by block
+layer and, thus, not available in zram/stat file. It consists of a
+single line of text and contains the following stats separated by
+whitespace:
+   failed_reads
+   failed_writes
+   invalid_io
+   notify_free
+
 9) Deactivate:
swapoff /dev/zram0
umount /dev/zram1
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 45319eb9..c02121f 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -384,6 +384,25 @@ static ssize_t compact_store(struct device *dev,
return len;
 }
 
+static ssize_t io_stat_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct zram *zram = dev_to_zram(dev);
+   ssize_t ret;
+
+   down_read(>init_lock);
+   ret = scnprintf(buf, PAGE_SIZE,
+   "%8llu %8llu %8llu %8llu\n",
+   (u64)atomic64_read(>stats.failed_reads),
+   (u64)atomic64_read(>stats.failed_writes),
+   (u64)atomic64_read(>stats.invalid_io),
+   (u64)atomic64_read(>stats.notify_free));
+   up_read(>init_lock);
+
+   return ret;
+}
+
+static DEVICE_ATTR_RO(io_stat);
 ZRAM_ATTR_RO(num_reads);
 ZRAM_ATTR_RO(num_writes);
 ZRAM_ATTR_RO(failed_reads);
@@ -1085,6 +1104,7 @@ static struct attribute *zram_disk_attrs[] = {
_attr_mem_used_max.attr,
_attr_max_comp_streams.attr,
_attr_comp_algorithm.attr,
+   _attr_io_stat.attr,
NULL,
 };
 
-- 
2.3.2.209.gd67f9d5

--
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-next: build failure after merge of the staging tree

[Greg KH]

On Tue, Mar 10, 2015 at 04:07:28PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the staging tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> In file included from include/linux/module.h:17:0,
>  from drivers/staging/sm750fb/sm750.c:2:
> drivers/staging/sm750fb/sm750.c: In function '__check_g_option':
> drivers/staging/sm750fb/sm750.c:1436:14: error: 'g_option' undeclared (first 
> use in this function)
>  module_param(g_option,charp,S_IRUGO);
>   ^
> 
> Caused by commit 81dee67e215b ("staging: sm750fb: add sm750 to staging").
> 
> This driver also produced a large number of warnings ... a lot like this:
> 
> drivers/staging/sm750fb/sm750.c: In function 'lynxfb_ops_mmap':
> drivers/staging/sm750fb/sm750.c:533:2: warning: format '%x' expects argument 
> of type 'unsigned int', but argument 2 has type 'long unsigned int' 
> [-Wformat=]
>   printk("lynxfb mmap pgoff: %x\n", vma->vm_pgoff);
>   ^
> 
> Also note:
> 
> In file included from drivers/staging/sm750fb/ddk750_mode.h:4:0,
>  from drivers/staging/sm750fb/ddk750.h:15,
>  from drivers/staging/sm750fb/sm750_hw.c:24:
> drivers/staging/sm750fb/ddk750_chip.h:4:0: warning: "SM750LE_REVISION_ID" 
> redefined
>  #define SM750LE_REVISION_ID (char)0xfe
>  ^
> In file included from drivers/staging/sm750fb/sm750_hw.c:23:0:
> drivers/staging/sm750fb/sm750_hw.h:8:0: note: this is the location of the 
> previous definition
>  #define SM750LE_REVISION_ID (unsigned char)0xfe
>  ^
> 
> I have disabled this driver for now, please let me know when it is OK
> to enable it again.

Sorry about that.  Yes, I know it's a mess.  The build error on ppc
should now be fixed in my tree.  The build warnings are still there
(some are gone).  I should just go fix them up myself, and will do so
tonight if I don't get a patch from someone else that does so first...

So it should be safe to enable again.

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/

[PATCH 3/6] zram: use generic start/end io accounting

[Sergey Senozhatsky]

Use bio generic_start_io_acct() and generic_end_io_acct() to account
device's block layer statistics. This will let users to monitor zram
activities using sysstat and similar packages/tools.

Apart from the usual per-stat sysfs attr, zram IO stats are now also
available in '/sys/block/zram/stat' and '/proc/diskstats' files.

We will slowly get rid of per-stat sysfs files.

Signed-off-by: Sergey Senozhatsky 
---
 drivers/block/zram/zram_drv.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 472c40c..45319eb9 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -743,8 +743,12 @@ static void zram_bio_discard(struct zram *zram, u32 index,
 static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
int offset, int rw)
 {
+   unsigned long start_time = jiffies;
int ret;
 
+   generic_start_io_acct(rw, bvec->bv_len >> SECTOR_SHIFT,
+   >disk->part0);
+
if (rw == READ) {
atomic64_inc(>stats.num_reads);
ret = zram_bvec_read(zram, bvec, index, offset);
@@ -753,6 +757,8 @@ static int zram_bvec_rw(struct zram *zram, struct bio_vec 
*bvec, u32 index,
ret = zram_bvec_write(zram, bvec, index, offset);
}
 
+   generic_end_io_acct(rw, >disk->part0, start_time);
+
if (unlikely(ret)) {
if (rw == READ)
atomic64_inc(>stats.failed_reads);
-- 
2.3.2.209.gd67f9d5

--
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 0/6] new zram statistics reporting scheme

[Sergey Senozhatsky]

Hello,

This patch introduces rework to zram stats. We have per-stat sysfs
nodes, and it makes things a bit hard to use in user space: it doesn't
give an immediate stats 'snapshot', it requires user space to use
more syscals -- open, read, close for every stat file, with 
appropriate error checks on every step, etc.

First, zram now accounts block layer statistics. available in
/sys/block/zram/stat and /proc/diskstats files. So some new
stats are available (see Documentation/block/stat.txt), besides,
zram's activities are now can be monitored by sysstat's iostat
or similar tools.

Example:
cat /sys/block/zram0/stat
248 019840   251029 0  2008232   5120   0   5116   5116



Second, group currently exported on per-stat basis nodes into two
categories (files):

-- zram/io_stat
accumulates device's IO stats, that are not accounted by block layer,
and contains:
failed_reads
failed_writes
invalid_io
notify_free

Example:
cat /sys/block/zram0/io_stat
000   652572


-- zram/mm_stat
accumulates zram mm stats and contains:
orig_data_size
compr_data_size
mem_used_total
mem_limit
mem_used_max
zero_pages
num_migrated

Example:
cat /sys/block/zram0/mm_stat
434634752 270288572 2791587840 579895296150600


per-stat sysfs nodes are now considered to be deprecated and we plan
to remove them (and clean up some of the existing stat code) in two
years (as of now, there is no warning printed to syslog about deprecated
stats being used). user space is advised to use the above mentioned 3
files.


note:
util-linux mailing list is not Cc-ed into this series. once we settle
it down, I'll write to Karel. (we have several months ahead until 4.1
will be released).


Sergey Senozhatsky (6):
  zram: remove `num_migrated' device attr
  zram: move compact_store() to sysfs functions area
  zram: use generic start/end io accounting
  zram: describe device attrs in documentation
  zram: export new 'io_stat' sysfs attrs
  zram: export new 'mm_stat' sysfs attrs

 Documentation/ABI/testing/sysfs-block-zram |  18 +++--
 Documentation/blockdev/zram.txt|  79 ++
 drivers/block/zram/zram_drv.c  | 101 ++---
 3 files changed, 157 insertions(+), 41 deletions(-)

-- 
2.3.2.209.gd67f9d5

--
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 12/18] dt-bindings: Document the STM32 USART bindings

[Arnd Bergmann]

On Friday 20 February 2015 19:01:11 Maxime Coquelin wrote:
> +
> +Example:
> +usart1: usart@40011000 {
> +   compatible = "st,stm32-usart";
> 

Please use generic node names everywhere. The standard name for a serial
port is "serial".

Arnd
--
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 4/6] zram: describe device attrs in documentation

[Sergey Senozhatsky]

Briefly describe exported device stat attrs in zram documentation.
We will eventually get rid of per-stat sysfs nodes and, thus,
clean up Documentation/ABI/testing/sysfs-block-zram file, which is
the only source of information about device sysfs nodes.

Add `num_migrated' description, since there is no independent
`num_migrated' sysfs node (and no corresponding sysfs-block-zram
entry), it will be exported via zram/mm_stat file.

At this point we can provide minimal attrs description, because
sysfs-block-zram still contains detailed information.

Signed-off-by: Sergey Senozhatsky 
---
 Documentation/blockdev/zram.txt | 49 +
 1 file changed, 35 insertions(+), 14 deletions(-)

diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 902c97c..149b49a 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -117,20 +117,41 @@ execute
echo X > /sys/class/zram-control/zram_remove
 
 8) Stats:
-   Per-device statistics are exported as various nodes under
-   /sys/block/zram/
-   disksize
-   num_reads
-   num_writes
-   failed_reads
-   failed_writes
-   invalid_io
-   notify_free
-   zero_pages
-   orig_data_size
-   compr_data_size
-   mem_used_total
-   mem_used_max
+Per-device statistics are exported as various nodes under /sys/block/zram/
+
+A brief description of exported device attritbutes. For more details please
+read Documentation/ABI/testing/sysfs-block-zram.
+
+Name mode description
+-----
+disksize  ROdisk size
+initstate ROshows the initialization state of the device
+reset WOtrigger device reset
+num_reads ROthe number of reads
+failed_reads  ROthe number of failed reads
+num_write ROthe number of writes
+failed_writes ROthe number of failed writes
+invalid_ioROthe number of non-page-size-aligned I/O requests
+max_comp_streams  RWthe number of possible concurrent compress operations
+comp_algorithmRWshow and change the compression algorithm
+notify_free   ROthe number of notifications to free pages (either
+slot free notifications or REQ_DISCARD requests)
+zero_pagesROthe number of zero filled pages written to this disk
+orig_data_sizeROuncompressed size of data stored in this disk
+compr_data_size   ROcompressed size of data stored in this disk
+mem_used_totalROthe amount of memory allocated for this disk
+mem_used_max  RWthe maximum amount of memory zram have consumed to
+store compressed data
+mem_limit RWthe maximum amount of memory ZRAM can use to store
+the compressed data
+num_migrated  ROthe number of objects migrated by compaction
+compact   WOtrigger memory compaction
+
+
+File /sys/block/zram/stat
+
+Represents block layer statistics. Read Documentation/block/stat.txt for
+details.
 
 9) Deactivate:
swapoff /dev/zram0
-- 
2.3.2.209.gd67f9d5

--
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: sm750fb: Cleanup the type of mmio750

[Lorenzo Stoakes]

On 10 March 2015 at 15:04, Greg KH  wrote:
> I can't apply patches that add new build warnings, sorry.  Please fix
> this up in the patch itself.
>
> greg k-h

Hi Greg,

Apologies for this, I've resolved this issue in v2 of the patch, no
warning messages are added in the updated version of this patch.

Best,

-- 
Lorenzo Stoakes
https:/ljs.io
--
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 2/6] zram: move compact_store() to sysfs functions area

[Sergey Senozhatsky]

A cosmetic change. We have a new code layout and keep zram per-device
sysfs store and show functions in one place. Move compact_store() to
that handlers block to conform to current layout.

Signed-off-by: Sergey Senozhatsky 
---
 drivers/block/zram/zram_drv.c | 42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 2009a5a..472c40c 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -67,27 +67,6 @@ static inline struct zram *dev_to_zram(struct device *dev)
return (struct zram *)dev_to_disk(dev)->private_data;
 }
 
-static ssize_t compact_store(struct device *dev,
-   struct device_attribute *attr, const char *buf, size_t len)
-{
-   unsigned long nr_migrated;
-   struct zram *zram = dev_to_zram(dev);
-   struct zram_meta *meta;
-
-   down_read(>init_lock);
-   if (!init_done(zram)) {
-   up_read(>init_lock);
-   return -EINVAL;
-   }
-
-   meta = zram->meta;
-   nr_migrated = zs_compact(meta->mem_pool);
-   atomic64_add(nr_migrated, >stats.num_migrated);
-   up_read(>init_lock);
-
-   return len;
-}
-
 /* flag operations require table entry bit_spin_lock() being held */
 static int zram_test_flag(struct zram_meta *meta, u32 index,
enum zram_pageflags flag)
@@ -384,6 +363,27 @@ static ssize_t comp_algorithm_store(struct device *dev,
return len;
 }
 
+static ssize_t compact_store(struct device *dev,
+   struct device_attribute *attr, const char *buf, size_t len)
+{
+   unsigned long nr_migrated;
+   struct zram *zram = dev_to_zram(dev);
+   struct zram_meta *meta;
+
+   down_read(>init_lock);
+   if (!init_done(zram)) {
+   up_read(>init_lock);
+   return -EINVAL;
+   }
+
+   meta = zram->meta;
+   nr_migrated = zs_compact(meta->mem_pool);
+   atomic64_add(nr_migrated, >stats.num_migrated);
+   up_read(>init_lock);
+
+   return len;
+}
+
 ZRAM_ATTR_RO(num_reads);
 ZRAM_ATTR_RO(num_writes);
 ZRAM_ATTR_RO(failed_reads);
-- 
2.3.2.209.gd67f9d5

--
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 3/7] x86, boot: Don't overlap VO with ZO data

[Yinghai Lu]

On Tue, Mar 10, 2015 at 2:34 AM, Borislav Petkov  wrote:
> Final patch:
>
> ---
> From: Yinghai Lu 
> Date: Sat, 7 Mar 2015 14:07:17 -0800
> Subject: [PATCH] x86/setup: Don't overlap vmlinux's brk with compressed 
> kernel's data

We need to keep VO and ZO here...

Should use ZO to replace "compressed kernel"

compressed kernel is compressed VO (vmlinux) actually.

ZO is arch/x86/boot/compressed/vmlinux

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 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration

[Nishanth Menon]

On 03/10/2015 05:39 AM, Linus Walleij wrote:
> On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon  wrote:
> 
>> +Configuration definition follows similar model as the pinctrl-single:
>> +The groups of pin configuration are defined under "pinctrl-single,pins"
>> +
>> +_iodelay_core {
>> +   mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
>> +   pinctrl-single,pins = <
>> +   0x18c (A_DELAY(0) | G_DELAY(120))   /* 
>> CFG_GPMC_A19_IN */
>> +   0x1a4 (A_DELAY(265) | G_DELAY(360)) /* 
>> CFG_GPMC_A20_IN */
>> +   0x1b0 (A_DELAY(0) | G_DELAY(120))   /* 
>> CFG_GPMC_A21_IN */
>> +   0x1bc (A_DELAY(0) | G_DELAY(120))   /* 
>> CFG_GPMC_A22_IN */
>> +   0x1c8 (A_DELAY(287) | G_DELAY(420)) /* 
>> CFG_GPMC_A23_IN */
>> +   0x1d4 (A_DELAY(144) | G_DELAY(240)) /* 
>> CFG_GPMC_A24_IN */
>> +   0x1e0 (A_DELAY(0) | G_DELAY(0)) /* 
>> CFG_GPMC_A25_IN */
>> +   0x1ec (A_DELAY(120) | G_DELAY(0))   /* 
>> CFG_GPMC_A26_IN */
>> +   0x1f8 (A_DELAY(120) | G_DELAY(180)) /* 
>> CFG_GPMC_A27_IN */
>> +   0x360 (A_DELAY(0) | G_DELAY(0)) /* 
>> CFG_GPMC_CS1_IN */
>> +   >;
>> +   };
>> +};
> 
> But wait.
> 
> The promise when we merged pinctrl-single was that this driver was to be used
> when the system had a one-register-per-pin layout and it was easy to do device
> trees based on that.
> 
> We were very reluctant to accept that even though we didn't even have the
> generic pin control bindings in place, the argument being that the driver
> should know the detailed register layout, it should not be described in the
> device tree. We eventually caved in and accepted it as an exception.
> 
> Since this pin controller is not using pinctrl-single it does not enjoy that
> privilege and you need to explain why this pin controller cannot use the
> generic bindings like so many other pin controllers have since started
> to do. ("It is in the same SoC" is not an acceptable argument.)
> 
> What is wrong with this:
> Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> 
> We can add generic delay bindings to the list, it even seems like
> a good idea to do so, as it is likely something that will come up in
> other hardware and will be needed for ACPI etc going forward.

Let me try to explain how the hardware works in this instance - it is
a quirk that we had'nt understood as being mandatory until very recently.

Apologies on pointing to TRM. Unfortunately, understanding this kind
of needs us to understand the hardware a little deeper.

http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf
18.5.2 CTRL_MODULE_CORE registers (page 4040) -> mux starts from
CTRL_CORE_PAD_GPMC_AD0 (page 4390)

This is the basic support needed for DRA7 family of SoC
handled by pinctrl-single. a single register for a single pin -> write
the mux mode, internal pull, wakeup capability etc. handled today as
part of pinctrl-single compatible "ti,dra7-padconf".

This works for almost 95%+ of the pins. few pins need tweaking of the
delay parameters to address per die, operational and board(rarely)
characteristics.

Here is where it gets a little complicated.

18.6.1 IODELAYCONFIG Module Instance Summary (page 4798) - starts at
CFG_RMII_MHZ_50_CLK_IN.

These registers are programmed per "18.4.6.1.4 Manual IO Timing Modes"
(page 4004).

Initial sequence of recalibration involves IO isolation - process
involving isolating every DRA7 pin from the external world - The only
logical place to do this is obviously as part of bootloader. Doing
this from kernel can be more than rationally complicated (IO isolation
for doing recalibration while a video playback or coprocessor like DSP
is active is just plain ridiculous in complexity).

The calibrated values then are read for programming these iodelay
registers per pin as described in the Section "18.4.6.1.4 Manual IO
Timing Modes" (page 4005).


In summary:
- This does not really control traditional points of pinctrl control
such as mux mode, pull direction etc. It is, in short, a tweaking of
delay paths from the IP to the external pin.

- Most pins do not need iodelay register programming. The ones that do
may have upto 3 other registers that may need programming (IN, OUT, OUTEN)

- Unlike pinctrl-single where a value is read from dts and programmed
straight to the register, programming iodelay involves taking two
parameter(a_delay and g_delay) per iodelay register, value for the
registers computed based on two other parameters(cdpe, fdpe). Where
cdpe and fdpe are computed based on "recalibration sequence" generated
values programmed in register fields for ref_count, delay_count and
ref_clk_period.
- This is also why pinctrl-single wont work here - it is not
  a copy from dts to register sequence, it is a compute from
  dts to register 

Re: [PATCH 0/6] Drivers: hv: Miscellaneous fixes

[gre...@linuxfoundation.org]

On Tue, Mar 10, 2015 at 02:54:16PM +, KY Srinivasan wrote:
> 
> 
> > -Original Message-
> > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> > Sent: Tuesday, March 10, 2015 12:41 AM
> > To: KY Srinivasan
> > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com
> > Subject: Re: [PATCH 0/6] Drivers: hv: Miscellaneous fixes
> > 
> > On Tue, Mar 10, 2015 at 03:31:44AM +, KY Srinivasan wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: KY Srinivasan
> > > > Sent: Friday, March 6, 2015 9:20 PM
> > > > To: KY Srinivasan; gre...@linuxfoundation.org; linux-
> > > > ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > > > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com
> > > > Subject: RE: [PATCH 0/6] Drivers: hv: Miscellaneous fixes
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: K. Y. Srinivasan [mailto:k...@microsoft.com]
> > > > > Sent: Friday, March 6, 2015 9:10 PM
> > > > > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> > > > > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> > > > > vkuzn...@redhat.com
> > > > > Cc: KY Srinivasan
> > > > > Subject: [PATCH 0/6] Drivers: hv: Miscellaneous fixes
> > > > >
> > > > > This patch-set has miscellaneous fixes for both the VMBUS as well
> > > > > as the balloon driver.
> > > > >
> > > > > Dan Carpenter (1):
> > > > >   hv: vmbus: missing curly braces in vmbus_process_offer()
> > > > >
> > > > > K. Y. Srinivasan (2):
> > > > >   Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl()
> > > > >   Drivers: hv: vmbus: Perform device register in the per-channel work
> > > > > element
> > >
> > > Greg, the upstream kernel is currently broken on Hyper-V under some
> > > configurations and this patch fixes the issue. Please apply.
> > 
> > Please apply what?
> > 
> > You said a while ago, in this email thread:
> > 
> > > > Please drop the patch-set; one of the patches I sent was incorrect.
> > > > I will resend.
> > 
> > so this series is long-gone from my patch queue.
> > 
> > I have others from my waiting to be reviewed, perhaps you meant those
> > instead?
> 
> Greg,
> 
> Yes, sorry for the confusion; I meant the second set of 7 patches that has 
> the V2 tag.

The one where I rejected the first patch?  :)

That didn't seem relevant for 4.0-final, if it was, please redo it such
that the bug fixes are "obvious".

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:STORVSC Use SCSI layer to allocate memory for per-command device request data

[Olaf Hering]

On Tue, Mar 10, Christoph Hellwig wrote:

> On Tue, Mar 10, 2015 at 12:42:33PM +0100, Olaf Hering wrote:
> > It would be nice to change .proc_name to KBUILD_MODNAME before v4.0 is
> > released. We carry a patch which adds this field. Of cource we can just
> > change the patch, but if code gets touched upstream anyway...
> 
> Please send a patch.  Would be nice if you had sent it long go insted of just
> including it in a vendor tree..

I was told .procname was dead, but since the patch adds it anyway it
should have a content thats in use (by us).

Olaf
--
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 05/18] reset: Add reset_controller_of_init() function

[Arnd Bergmann]

On Friday 20 February 2015 19:01:04 Maxime Coquelin wrote:
> Some platforms need to initialize the reset controller before the timers.
> 
> This patch introduces a reset_controller_of_init() function that can be
> called before the timers intialization.
> 
> Signed-off-by: Maxime Coquelin 
> 

Not sure about this. It seems like the cleanest approach if we get
a lot of these, but then again it is probably very rare, and I'd
like to avoid adding such infrastructure if it's just for one
SoC. Could we add a hack in the machine initialization instead?

I think ideally this would be done in the boot loader before we
even start Linux, but I don't know if that's possible for you.

Arnd
--
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: sm750fb: Cleanup the type of mmio750

[Greg KH]

On Tue, Mar 10, 2015 at 12:47:44PM +, Lorenzo Stoakes wrote:
> On 10 March 2015 at 12:36, Sudip Mukherjee  wrote:
> > but it is introducing two new build warnings:
> >
> > drivers/staging/sm750fb/sm750_hw.c: In function ‘hw_sm750_map’:
> > drivers/staging/sm750fb/sm750_hw.c:67:2: warning: passing argument 1 of 
> > ‘ddk750_set_mmio’ discards ‘volatile’ qualifier from pointer target type 
> > [enabled by default]
> > In file included from drivers/staging/sm750fb/ddk750_mode.h:4:0,
> > from drivers/staging/sm750fb/ddk750.h:15,
> > from drivers/staging/sm750fb/sm750_hw.c:24:
> >
> > and
> >
> > drivers/staging/sm750fb/ddk750_chip.h:77:6: note: expected ‘void *’ but 
> > argument is of type ‘volatile unsigned char *’
> >
> > care to make another patch to solve these two new warnings, and send this 
> > patch and the new one in a series and while sending mark the version number 
> > in the subject.
> 
> I think the second warning is simply additional information attached
> to the 1st to give context?
> 
> I noticed this issue but felt changing the type of this field would
> sit outside the purview of this patch as then I'm not only changing
> the type of mmio750 and code that *directly* interacts with this
> variable, but also code that indirectly interacts with it, so I felt
> that should perhaps be a separate patch.
> 
> I'd love to additionally provide some further patches to help out with
> issues here too, incidentally! I will try to prepare some further
> patches tonight in this vein.

I can't apply patches that add new build warnings, sorry.  Please fix
this up in the patch itself.

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 V2 1/7] Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl()

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, March 10, 2015 12:42 AM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com
> Subject: Re: [PATCH V2 1/7] Drivers: hv: vmbus: Export the
> vmbus_sendpacket_pagebuffer_ctl()
> 
> On Fri, Mar 06, 2015 at 11:04:28PM -0800, K. Y. Srinivasan wrote:
> > Export the vmbus_sendpacket_pagebuffer_ctl() interface.
> 
> Why?  Nothing in this patch needs it.  Please include this in the patch that
> needs the symbol, or at least give a hint as to what is going on.
> 
> As it is, this just looks like a random export for no reason at all :(

This will be used by Hyper-V networking driver to optimize signaling on
the send path. I wanted these patches committed before I sent the networking
patch to David Miller. I implemented the two vmbus APIs for sending messages:
1) vmbus_sendpacket_ctl()
2) vmbus_sendpacket_pagebuffer_ctl()

and I forgot to export the second form of the send API in an earlier patch-set 
that you have
already  committed. I need both to be exported to
for the netvsc patch I have.

On a different note, upstream Linux is currently broken on Hyper-V and a patch 
in this set
Fixes it:
0002-Drivers-hv-vmbus-Perform-device-register-in-the-per-.patch

Do you want me to resend this set?

Regards,

K. Y


> 
> 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 v2 07/18] drivers: reset: Add STM32 reset driver

[Arnd Bergmann]

On Friday 20 February 2015 19:01:06 Maxime Coquelin wrote:
> +/* AHB1 */
> +#define GPIOA_RESET0
> +#define GPIOB_RESET1
> +#define GPIOC_RESET2
> +#define GPIOD_RESET3
> +#define GPIOE_RESET4
> +#define GPIOF_RESET5
> +#define GPIOG_RESET6
> +#define GPIOH_RESET7
> +#define GPIOI_RESET8
> +#define GPIOJ_RESET9
> +#define GPIOK_RESET10
> 

As these are just the hardware numbers, it's better to not make them
part of the binding at all. Instead, just document in the binding that
one is supposed to pass the hardware number as the argument.

Arnd
--
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: Question on mutex code

[Valdis . Kletnieks]

On Tue, 10 Mar 2015 14:03:59 +0100, Yann Droneaud said:

> > Consider the following sequence of events:
> > 
> > 0. Suppose a mutex is locked by task A and has no waiters.
> > 
> > 1. Task B calls mutex_trylock().
> > 
> > 2. mutex_trylock() calls the architecture-specific
> > __mutex_fastpath_trylock(), with __mutex_trylock_slowpath() as
> > fail_fn.
> > 
> > 3. According to the description of __mutex_fastpath_trylock() (for
> > example in include/asm-generic/mutex-dec.h), "if the architecture
> > has no effective trylock variant, it should call the fail_fn
> > spinlock-based trylock variant unconditionally". So
> > __mutex_fastpath_trylock() may now call __mutex_trylock_slowpath().
> > 
> > 4. Task A releases the mutex.
> > 
> > 5. Task B, in __mutex_trylock_slowpath, executes:
> > 
> >  /* No need to trylock if the mutex is locked. */
> >  if (mutex_is_locked(lock))
> >  return 0;
> > 
> > Since the mutex is no longer locked, the function continues.
> > 
> > 6. Task C, which runs on a different cpu than task B, locks the mutex
> > again.
> > 
> > 7. Task B, in __mutex_trylock_slowpath(), continues:
> > 
> >  spin_lock_mutex(>wait_lock, flags);

B will spin here until C releases the lock.

When that spin exits, C no longer holds the lock.  Re-do the analysis
from this point.


pgpThlpyoPcRG.pgp
Description: PGP signature

Re: [PATCH v2] staging: sm750fb: Fix sparse warning

[Greg KH]

On Tue, Mar 10, 2015 at 08:51:59AM +, Lorenzo Stoakes wrote:
> This patch fixes the following sparse warning:-
> 
> drivers/staging/sm750fb/ddk750_help.c: warning: incorrect type in assignment 
> (different address spaces)
> 
> In addition it eliminates an unnecessary volatile.

This doesn't apply anymore due to other patches I just took, so can you
rebase this patch on my latest staging-testing branch of staging.git?

Also, how about someone fixing the real compiler warnings this driver is
spitting out first, before we worry about sparse warnings?  That's much
more relevant here as it's keeping the driver from being built in
linux-next at the moment.

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/

[PATCH] rsxx: match wait_for_completion_timeout return type

[Nicholas Mc Guire]

return type of wait_for_completion_timeout is unsigned long not int. An
appropriately named unsigned long is added and the
assignment fixed up.

Signed-off-by: Nicholas Mc Guire 
---

Note that there does not seem to be any protection against the on stack
struct completion going out of scope if timeout occurs ! Any call to
complete() after timeout occurred would be potentially corrupting the stack
(though with high probability incorrect spin_lock magic would cause an oops).

This was only compile tested for x86_64_defconfig + CONFIG_BLK_DEV_RSXX=m

Patch is against 4.0-rc2 linux-next (localversion-next is -next-20150306)

 drivers/block/rsxx/cregs.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/rsxx/cregs.c b/drivers/block/rsxx/cregs.c
index 926dce9..8b9d0e3 100644
--- a/drivers/block/rsxx/cregs.c
+++ b/drivers/block/rsxx/cregs.c
@@ -392,7 +392,7 @@ static int __issue_creg_rw(struct rsxx_cardinfo *card,
 {
DECLARE_COMPLETION_ONSTACK(cmd_done);
struct creg_completion completion;
-   unsigned long timeout;
+   unsigned long timeout, time_left;
int st;
 
completion.cmd_done = _done;
@@ -416,8 +416,8 @@ static int __issue_creg_rw(struct rsxx_cardinfo *card,
 * The creg interface is guaranteed to complete. It has a timeout
 * mechanism that will kick in if hardware does not respond.
 */
-   st = wait_for_completion_timeout(completion.cmd_done, timeout);
-   if (st == 0) {
+   time_left = wait_for_completion_timeout(completion.cmd_done, timeout);
+   if (!time_left) {
/*
 * This is really bad, because the kernel timer did not
 * expire and notify us of a timeout!
-- 
1.7.10.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/

Re: [PATCH] perf build: Fix libbabeltrace detection

[Arnaldo Carvalho de Melo]

Em Tue, Mar 10, 2015 at 10:44:00AM -0400, Jérémie Galarneau escreveu:
> On Tue, Mar 10, 2015 at 10:11 AM, Jiri Olsa  wrote:
> > On Tue, Mar 10, 2015 at 11:01:34AM -0300, Arnaldo Carvalho de Melo wrote:
> >> Em Tue, Mar 10, 2015 at 01:00:35PM +0100, Jiri Olsa escreveu:
> >> > Adding proper header and keeping the old one as it is needed
> >> > also (libbabeltrace quirk).
> >>
> >> > +#include 
> >>
> >> Right, that was the fix I found as well, well, I was trying to include
> >> _just_ babeltrace/ctf-ir/stream-class.h, but that is buggy in that it
> >> doesn't include the header file with the uint32_t and int64_t types:
> >
> > yep, thats the 'libbabeltrace quirk' I mentioned in the changelog ;-)

> Seems I missed that being discussed. Fixed in Babeltrace master as of 
> 48d711aa2.

Thanks for doing it, just refreshed by babeltrace git repo and found it
there!

Will add Jiri's patch tho, so that it works with the older git repos.

Ah, since you guys adopted the Signed-off-by tag, consider adopting the
Reported-by as well 8-)

- Arnaldo
--
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: fwupdate

[Peter Jones]

On Mon, Mar 09, 2015 at 06:54:12PM -0700, Roy Franz wrote:
> On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov  wrote:
> > + pjones.
> >
> > So reportedly, there is already a capsule-loading thing which doesn't
> > need the kernel at all:
> >
> > https://github.com/rhinstaller/fwupdate
> >
> > So why are we even wasting energy with this discussion here?
> >
> > --
> > Regards/Gruss,
> > Boris.
> 
> The network boot case can be taken care of as Peter described (ie
> taking network device paths, instead of just file paths), so
> this should work for those cases as well.  There would be some extra
> setup, as for this to work the EFI firmware update program
> would need to be run at boot (via the BootNext variable), but I don't
> think this is unreasonable.
> It looks like GnuEFI now supports Aarch64, so building the firmware
> update utility shouldn't be a problem.  Peter - have you you tried
> building
> this on Aarch64 yet?  If not I'll give it a try.

I tried a very early version of the code on an Aarch64 machine where I
also wrote the firmware feature, and it basically seemed to work, modulo
my buggy firmware ;)  I haven't tried it recently, but I do have all the
right makefile goo in there to build it reasonably, and I don't know of
any reason it wouldn't work.

That said, I haven't sent my patch to add the capsule headers to gnu-efi
yet, so you won't get very far - I'll make sure and send those this
week, hopefully today.  Also note that fwupdate is still a very active
work in progress; it's not /quite/ ready for general purpose deployment
even in a "trying it out" phase, but I'm hoping to get to that point
this week or next - in particular the code on github right now assumes
an HD() device path with a specific partition guid.

That is, it has literally worked on two machines ever.  Yes, it's a
thing we intend on supporting, but it's not /there/ yet.

> I think there is some value in using runtime update capsule calls, as
> that will help make sure the feature works in the firmware.  I think
> with arm64 servers in an early stage of development, we can influence
> the firmware support of various features by using them.  I don't know
> that this is a sufficient reason, but if runtime capsules are never
> used then there is a good chance that there will be many broken
> implementations.

That's certainly potentially valid, but it doesn't necessarily yield
something we (the OS vendor deploying features to customers) can
actually depend on.  Usually firmware features like this become
generally usable when there's some market maker causing hardware vendors
to have a large interest in making sure the feature works.  That means
most often the carrot being dangled is MS Logo certification marketing
dollars, and the testing all follows from the situations they require to
work.  So far, it appears MS has been using this only from Boot
Services, so that's what works.  

It looks to me like that's probably likely to remain true.  One reason
is peripheral cards.  My expectation (though possibly unfounded) is that
MS will require peripheral cards to use this same update mechanism for
option ROMs, and even if they don't I know some vendors are working on
it.  To do so, the card's UEFI driver (supplied on the option ROM) will
be using EFI's Firmware Management Protocol (FMP) to participate in the
capsule update system.

The 2.5 spec drafts that include FMP and UpdateCapsule() support for FMP
state that capsule updates for FMP aren't required to be available
during runtime - it expressly calls out the case where
CAPSULE_FLAGS_PERSIST_ACROSS_RESET is used.  (I don't think I'm allowed
to quote language from drafts in public, but if you have a copy, I'm
talking about the last paragraph of 22.2.1)  In my mind this means most
implementations are going to always try to do updates from before
ExitBootServices() for those option types - anything else and you're
just in an error case where you have to do that anyway.

So again, I'm not dead-set against having a kernel implementation, but I
think its use cases are severely constrained, and most of the time most
implementations will want to do this before the kernel loads.  The best
case for doing it in the kernel is embedded devices where a) there's no
persistent storage except the flash part you're updating anyway, and b)
the vendor nominally controls both the firmware and the deployed OS.

-- 
Peter, heading back to the code.
--
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/10] rcu: Cleanup RCU tree initialization

[Paul E. McKenney]

On Tue, Mar 10, 2015 at 02:33:37PM +, Alexander Gordeev wrote:
> On Mon, Mar 09, 2015 at 02:35:42PM -0700, Paul E. McKenney wrote:
> > On Mon, Mar 09, 2015 at 09:36:52AM +, Alexander Gordeev wrote:
> > > On Mon, Mar 09, 2015 at 09:34:04AM +0100, Alexander Gordeev wrote:
> > > > Hi Paul,
> > > > 
> > > > Here is cleanup of RCU tree initialization rebased on linux-rcu rcu/next
> > > > repo, as you requested. Please, note an extra patch #10 that was not
> > > > present in the first post.
> > > 
> > > Paul,
> > > 
> > > Please, ignore patch #10 for now. I missed to notice rcu_node::grpnum is
> > > used in tracing, so the patch is incomplete. I am not sure why trailing
> > > spaces in seq_printf(m, "%lx/%lx->%lx %c%c>%c %d:%d ^%d", ) are
> > > needed for, so not sure if "^%d" part should be removed (possibly with
> > > the traling spaces) or replaced with three spaces.
> > 
> > OK, dropping this one for the moment.
> > 
> > The original use of ->grpnum was for manual debugging purposes.  Yes, you
> > can get the same information out of ->grpmask, but the number is easier
> > to read.  And on the debugfs trace information, ->grpnum is printed,
> > but ->grpmask is not.
> > 
> > The trailing spaces on the seq_printf() allow the rcu_node data to be
> > printed on a single line, while still allowing the eye to pick out
> > where one rcu_node structure's data ends and the next one begins.
> > 
> > So here are the choices, as far as I can see:
> > 
> > 1.  Leave ->grpnum as is.
> > 
> > 2.  Remove ->grpnum, but regenerate it in print_one_rcu_state(),
> > for example, by counting the number of rcu_node structures
> > since the last ->level change.
> > 
> > 3.  Drop ->grpnum and also remove it from the debugfs tracing.
> > The reader can rely on the ->grplo and ->grphi fields to
> > work out where this rcu_node structure fits in, but we
> > lose the visual indication of any bugs in computing these
> > quantities.
> > 
> > 4.  Drop ->grpnum and replace it with ->grpmask.  This seems a
> > bit obtuse to me.
> > 
> > 5.  Redesign print_one_rcu_state()'s output from scratch.
> > 
> > #1 has certain advantages from a laziness viewpoint.  #2 would open up
> > some space in the rcu_node structure, but space really isn't an issue
> > for that structure given that huge systems have only 257 of them and
> > the really small systems use Tiny RCU instead.  #3 might be OK, but I
> > am not really convinced.  #4 seems a bit ugly.  I am not signing up
> > for #5, in part because not all that many people use RCU's debugfs
> > output, so I don't see the point in investing the time.
> > 
> > But what did you have in mind?
> 
> I probably should have marked this patch as an RFC. Given your summary
> #1 seems as the best choice.
> 
> However, I have something else in mind, indeed. What is the reason to
> have 'grpnum' and 'level' as u8 while, say 'grplo' and 'grphi' - as int?
> IOW, do we conserve on memory for this structure or not?

The ->grplo and ->grphi fields must hold a CPU number.  Since CPU numbers
are int elsewhere, they are int here.  I considered making them a short,
but there are systems uncomfortably close to the limit.  There have
been 4096-CPU systems for quite some time, and I have heard rumors of
16384-CPU systems.  A limit of 32768 seems uncomfortably tight, especially
given that memory footprint is at best a minor requirement for Tree RCU.
Tiny RCU is of course another story -- memory savings is Job One there.

And yes, I do owe the community a writeup of the requirements on RCU.

Thanx, Paul

--
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 1/2] Documentation: update the of_selftest.txt

[Rob Herring]

On Sun, Mar 8, 2015 at 9:35 PM, Wang Long  wrote:
> Since the directory "drivers/of/testcase-data" is renamed
> to "drivers/of/unittest-data". so we should update the path
> in the of_selftest.txt.
>
> When the kernel is built with OF_SELFUNIT enabled, the output

Still wrong...

> dtb is testcases.dtb instead of testcase.dtb, also update it
> (s/testcase/testcases/).
>
> Signed-off-by: Wang Long 
> ---
>  Documentation/devicetree/of_selftest.txt | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/of_selftest.txt 
> b/Documentation/devicetree/of_selftest.txt
> index 57a808b..3e4e7d4 100644
> --- a/Documentation/devicetree/of_selftest.txt
> +++ b/Documentation/devicetree/of_selftest.txt
> @@ -1,11 +1,11 @@
> -Open Firmware Device Tree Selftest
> +Open Firmware Device Tree Unittest
>  --
>
>  Author: Gaurav Minocha 
>
>  1. Introduction
>
> -This document explains how the test data required for executing OF selftest
> +This document explains how the test data required for executing OF unittest
>  is attached to the live tree dynamically, independent of the machine's
>  architecture.
>
> @@ -22,31 +22,31 @@ most of the device drivers in various use cases.
>
>  2. Test-data
>
> -The Device Tree Source file (drivers/of/testcase-data/testcases.dts) contains
> +The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
>  the test data required for executing the unit tests automated in
> -drivers/of/selftests.c. Currently, following Device Tree Source Include files
> -(.dtsi) are included in testcase.dts:
> +drivers/of/unittest.c. Currently, following Device Tree Source Include files
> +(.dtsi) are included in testcases.dts:
>
> -drivers/of/testcase-data/tests-interrupts.dtsi
> -drivers/of/testcase-data/tests-platform.dtsi
> -drivers/of/testcase-data/tests-phandle.dtsi
> -drivers/of/testcase-data/tests-match.dtsi
> +drivers/of/unittest-data/tests-interrupts.dtsi
> +drivers/of/unittest-data/tests-platform.dtsi
> +drivers/of/unittest-data/tests-phandle.dtsi
> +drivers/of/unittest-data/tests-match.dtsi
>
>  When the kernel is build with OF_SELFTEST enabled, then the following make 
> rule

Missed this one...

>
>  $(obj)/%.dtb: $(src)/%.dts FORCE
> $(call if_changed_dep, dtc)
>
> -is used to compile the DT source file (testcase.dts) into a binary blob
> -(testcase.dtb), also referred as flattened DT.
> +is used to compile the DT source file (testcases.dts) into a binary blob
> +(testcases.dtb), also referred as flattened DT.
>
>  After that, using the following rule the binary blob above is wrapped as an
> -assembly file (testcase.dtb.S).
> +assembly file (testcases.dtb.S).
>
>  $(obj)/%.dtb.S: $(obj)/%.dtb
> $(call cmd, dt_S_dtb)
>
> -The assembly file is compiled into an object file (testcase.dtb.o), and is
> +The assembly file is compiled into an object file (testcases.dtb.o), and is
>  linked into the kernel image.
>
>
> @@ -98,7 +98,7 @@ child11 -> sibling12 -> sibling13 -> sibling14 -> null
>  Figure 1: Generic structure of un-flattened device tree
>
>
> -Before executing OF selftest, it is required to attach the test data to
> +Before executing OF unittest, it is required to attach the test data to
>  machine's device tree (if present). So, when selftest_data_add() is called,

This one too.

>  at first it reads the flattened device tree data linked into the kernel image
>  via the following kernel symbols:
> --
> 1.8.3.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/

Re: [PATCH v5 3/3] scsi: ufs: add trace events and dump prints for debug

[Steven Rostedt]

On Tue, 10 Mar 2015 13:47:15 +0200
Gilad Broner  wrote:


> +++ b/include/trace/events/ufs.h
> @@ -0,0 +1,227 @@
> +/*
> + * Copyright (c) 2013-2015, The Linux Foundation. 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 version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM ufs
> +
> +#if !defined(_TRACE_UFS_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_UFS_H
> +
> +#include 
> +
> +TRACE_EVENT(ufshcd_clk_gating,
> +
> + TP_PROTO(const char *dev_name, const char *state),
> +
> + TP_ARGS(dev_name, state),
> +
> + TP_STRUCT__entry(
> + __string(dev_name, dev_name)
> + __string(state, state)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(dev_name, dev_name);
> + __assign_str(state, state);
> + ),
> +
> + TP_printk("%s: gating state changed to %s",
> + __get_str(dev_name), __get_str(state))
> +);

This and the auto_bkops_state is pretty much the same. Can't you use
the same TP_printk() and just have a DECLARE_EVENT_CLASS? The trace
point name is printed with the event to see different events.

At least use DEFINE_EVENT_PRINT() that lets you override a EVENT_CLASS
TP_printk(). This saves memory.

-- Steve


> +
> +TRACE_EVENT(ufshcd_clk_scaling,
> +
> + TP_PROTO(const char *dev_name, const char *state, const char *clk,
> + u32 prev_state, u32 curr_state),
> +
> + TP_ARGS(dev_name, state, clk, prev_state, curr_state),
> +
> + TP_STRUCT__entry(
> + __string(dev_name, dev_name)
> + __string(state, state)
> + __string(clk, clk)
> + __field(u32, prev_state)
> + __field(u32, curr_state)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(dev_name, dev_name);
> + __assign_str(state, state);
> + __assign_str(clk, clk);
> + __entry->prev_state = prev_state;
> + __entry->curr_state = curr_state;
> + ),
> +
> + TP_printk("%s: %s %s from %u to %u Hz",
> + __get_str(dev_name), __get_str(state), __get_str(clk),
> + __entry->prev_state, __entry->curr_state)
> +);
> +
> +TRACE_EVENT(ufshcd_auto_bkops_state,
> +
> + TP_PROTO(const char *dev_name, const char *state),
> +
> + TP_ARGS(dev_name, state),
> +
> + TP_STRUCT__entry(
> + __string(dev_name, dev_name)
> + __string(state, state)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(dev_name, dev_name);
> + __assign_str(state, state);
> + ),
> +
> + TP_printk("%s: auto bkops - %s",
> + __get_str(dev_name), __get_str(state))
> +);
> +
--
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 0/6] Drivers: hv: Miscellaneous fixes

[KY Srinivasan]

> -Original Message-
> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, March 10, 2015 12:41 AM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com
> Subject: Re: [PATCH 0/6] Drivers: hv: Miscellaneous fixes
> 
> On Tue, Mar 10, 2015 at 03:31:44AM +, KY Srinivasan wrote:
> >
> >
> > > -Original Message-
> > > From: KY Srinivasan
> > > Sent: Friday, March 6, 2015 9:20 PM
> > > To: KY Srinivasan; gre...@linuxfoundation.org; linux-
> > > ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com
> > > Subject: RE: [PATCH 0/6] Drivers: hv: Miscellaneous fixes
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: K. Y. Srinivasan [mailto:k...@microsoft.com]
> > > > Sent: Friday, March 6, 2015 9:10 PM
> > > > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> > > > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> > > > vkuzn...@redhat.com
> > > > Cc: KY Srinivasan
> > > > Subject: [PATCH 0/6] Drivers: hv: Miscellaneous fixes
> > > >
> > > > This patch-set has miscellaneous fixes for both the VMBUS as well
> > > > as the balloon driver.
> > > >
> > > > Dan Carpenter (1):
> > > >   hv: vmbus: missing curly braces in vmbus_process_offer()
> > > >
> > > > K. Y. Srinivasan (2):
> > > >   Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl()
> > > >   Drivers: hv: vmbus: Perform device register in the per-channel work
> > > > element
> >
> > Greg, the upstream kernel is currently broken on Hyper-V under some
> > configurations and this patch fixes the issue. Please apply.
> 
> Please apply what?
> 
> You said a while ago, in this email thread:
> 
> > > Please drop the patch-set; one of the patches I sent was incorrect.
> > > I will resend.
> 
> so this series is long-gone from my patch queue.
> 
> I have others from my waiting to be reviewed, perhaps you meant those
> instead?

Greg,

Yes, sorry for the confusion; I meant the second set of 7 patches that has the 
V2 tag.

Thank you,

K. Y
> 
> confused,
> 
> 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 v2 1/2] cgroups: allow a cgroup subsystem to reject a fork

[Aleksa Sarai]

Hello Tejun,

On Tue, Mar 10, 2015 at 11:47 PM, Tejun Heo  wrote:
>> of doing a charge that stops if you hit a certain `css` (unless we start
>> passing `css_set`s to the fork/exit callbacks -- and then we can uncharge the
>> old css_set and charge the new one).
>
> We'll have to pass the pointer from can_fork side to post_fork.  I'm
> not sure how that should be done either.

Actually, I'm fairly sure we can do it all inside cgroup_post_fork() because
inside cgroup_post_fork() we have access to both the old css_set and the new
one. Then it's just a matter of reverting and re-applying the charge to the
hierarchies.

I'll send a patch in a few days, I need to make sure that this method
*actually* works. :P

--
Aleksa Sarai (cyphar)
www.cyphar.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 v2 1/2] Documentation: update the of_selftest.txt

[Rob Herring]

On Tue, Mar 10, 2015 at 9:44 AM, Rob Herring  wrote:
> On Sun, Mar 8, 2015 at 9:35 PM, Wang Long  wrote:
>> Since the directory "drivers/of/testcase-data" is renamed
>> to "drivers/of/unittest-data". so we should update the path
>> in the of_selftest.txt.

[...]

>> -Before executing OF selftest, it is required to attach the test data to
>> +Before executing OF unittest, it is required to attach the test data to
>>  machine's device tree (if present). So, when selftest_data_add() is called,
>
> This one too.

Or not. The functions are all still "selftest". Not sure why Grant
left all those...

Rob
--
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] livepatch/module: Correctly handle coming and going modules

[Josh Poimboeuf]

On Tue, Mar 10, 2015 at 03:36:17PM +0100, Petr Mladek wrote:
> On Tue 2015-03-10 09:22:04, Josh Poimboeuf wrote:
> > On Tue, Mar 10, 2015 at 01:01:07PM +0100, Petr Mladek wrote:
> > > On Mon 2015-03-09 09:40:55, Josh Poimboeuf wrote:
> > > > On Mon, Mar 09, 2015 at 02:25:28PM +0100, Petr Mladek wrote:
> > > > > diff --git a/kernel/module.c b/kernel/module.c
> > > > > index d856e96a3cce..b3ffc231ce0d 100644
> > > > > --- a/kernel/module.c
> > > > > +++ b/kernel/module.c
> > > > > @@ -3271,6 +3271,10 @@ static int load_module(struct load_info *info, 
> > > > > const char __user *uargs,
> > > > >   }
> > > > >  #endif
> > > > >  
> > > > > +#ifdef CONFIG_LIVEPATCH
> > > > > + mod->klp_alive = false;
> > > > > +#endif
> > > > > +
> > > > 
> > > > I don't think you need this initialization.  It looks like the module
> > > > struct is embedded in the mod->module_core region which is initialized
> > > > to zero in move_module().
> > > 
> > > I have looked at this before but I was not able to find a code
> > > zeroing struct module. If I get it correctly, mod->module_core
> > > is a location where symbol table sections are copied or so.
> > 
> > Yeah, it's far from obvious.  AFAICT, it's cleared by the
> > "memset(ptr, 0, mod->core_size)" line.
> 
> What I wanted to say is that module_core is not struct module. It
> seems that it points to the module code. See within_module_core() and
> how it is used().
> 
> By other words, I think that struct module is not zeroed and we need
> to initialize the bool.
> 
> Or did I miss anything?

My understanding is that module_core is not only code.  It also contains the
struct module itself.  Verified in crash:

  crash> mod |head -n2
   MODULE   NAMESIZE  OBJECT FILE
  a0003180  video  19905  (not loaded)  
[CONFIG_KALLSYMS]
  crash> module.module_core,core_size 0xa0003180
module_core = 0xa000
core_size = 0x4dc1


-- 
Josh
--
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] dma: Add Xilinx ZDMA device tree Binding Documentation

[Punnaiah Choudary Kalluri]

Device-tree binding documentation for Xilinx ZDMA Engine

Signed-off-by: Punnaiah Choudary Kalluri 
---
 .../devicetree/bindings/dma/xilinx/zdma.txt|   76 
 1 files changed, 76 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zdma.txt

diff --git a/Documentation/devicetree/bindings/dma/xilinx/zdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/zdma.txt
new file mode 100644
index 000..399a3bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zdma.txt
@@ -0,0 +1,76 @@
+Xilinx ZDMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Xilinx ZynqMP has two instances of general purpose DMA(ZDMA).
+one is located in FPD(full power domain) and other is located in
+LPD(low power domain).
+
+ZDMA instance located in FPD is referred as FPDMA and instance located
+in LPD is referred as LPDMA.
+
+FPDMA is configured with 8 DMA channels and AXI bus width is 128 byte.
+LPDMA is configured with 8 DMA channels and AXI bus width is 64 byte.
+
+Each channel in a instance has its own address space and interrupt line
+but shares common reference and APB clock. So, each channel will be treated
+as a standalone dma device.
+Since its a general purpose dma controller, it has a rich set of configurable
+options with respect to data and descriptor attributes.
+
+Required properties:
+- compatible: Should be "xlnx,fpdma-1.0" or "xlnx,lpdma-1.0"
+- reg: Memory map for dma module access.
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain DMA channel interrupt.
+- xlnx,id: Channel Id
+
+Optional properties:
+- xlnx,include-sg: Indicates the controller to operate in simple or scatter
+  gather dma mode
+- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
+source AXI transaction
+- xlnx,overfetch: Tells whether the channel is allowed to over fetch the data
+- xlnx,src-issue: Number of AXI outstanding transactions on source side
+- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the
+   descriptor read are marked Non-coherent
+- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
+   source descriptor payload are marked Non-coherent
+- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
+   dst descriptor payload are marked Non-coherent
+- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
+- xlnx,src-axi-qos: AXI QOS bits to be used for data read
+- xlnx,dst-axi-qos: Axi QOS bits to be used for data write
+- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch
+- xlnx,desc-axi-cache: AXI cache bits to be used for data read
+- xlnx,desc-axi-cache: AXI cache bits to be used for data write
+- xlnx,src-burst-len: AXI length for data read. Support only power of 2 values
+ i.e 1,2,4,8 and 16.
+- xlnx,dst-burst-len: AXI length for data write. Support only power of 2 values
+ i.e 1,2,4,8 and 16.
+
+Example:
+
+fpdma0: dma@fd50 {
+   compatible = "xlnx,fpdma-1.0";
+   reg = <0x0 0xfd50 0x1000>;
+   interrupt-parent = <>;
+   interrupts = <0 117 4>;
+   xlnx,include-sg;
+   xlnx,overfetch;
+   xlnx,ratectrl = <0>;
+   xlnx,src-issue = <16>;
+   xlnx,id = <0>;
+   xlnx,desc-axi-cohrnt;
+   xlnx,src-axi-cohrnt;
+   xlnx,dst-axi-cohrnt;
+   xlnx,desc-axi-qos = <0>;
+   xlnx,desc-axi-cache = <0>;
+   xlnx,src-axi-qos = <0>;
+   xlnx,src-axi-cache = <2>;
+   xlnx,dst-axi-qos = <0>;
+   xlnx,dst-axi-cache = <2>;
+   xlnx,src-burst-len = <4>;
+   xlnx,dst-burst-len = <4>;
+};
+
-- 
1.7.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/

Re: [PATCH 00/10] rcu: Cleanup RCU tree initialization

[Paul E. McKenney]

On Tue, Mar 10, 2015 at 02:39:39PM +, Alexander Gordeev wrote:
> On Mon, Mar 09, 2015 at 09:43:18PM -0700, Paul E. McKenney wrote:
> > On Mon, Mar 09, 2015 at 04:49:43PM -0700, Paul E. McKenney wrote:
> > > On Mon, Mar 09, 2015 at 04:39:47PM -0700, Paul E. McKenney wrote:
> > > > On Mon, Mar 09, 2015 at 02:40:21PM -0700, Paul E. McKenney wrote:
> > > > > On Mon, Mar 09, 2015 at 09:34:04AM +0100, Alexander Gordeev wrote:
> > > > > > Hi Paul,
> > > > > > 
> > > > > > Here is cleanup of RCU tree initialization rebased on linux-rcu 
> > > > > > rcu/next
> > > > > > repo, as you requested. Please, note an extra patch #10 that was not
> > > > > > present in the first post.
> > > > > > 
> > > > > > The series successfully passes kernel build test with 
> > > > > > CONFIG_RCU_FANOUT
> > > > > > and CONFIG_RCU_FANOUT_LEAF equal to 5.
> > > > > 
> > > > > I queued up 1-9, as discussed and have started testing.  I will let 
> > > > > you
> > > > > know how it goes.
> > > > 
> > > > Initial testing went well except for the following warning:
> > > > 
> > > > /home/paulmck/public_git/linux-rcu/kernel/rcu/tree.c: In function 
> > > > ‘rcu_init_one.isra.63’:
> > > > /home/paulmck/public_git/linux-rcu/kernel/rcu/tree.c:3961:3: warning: 
> > > > ‘levelcnt[0]’ may be used uninitialized in this function 
> > > > [-Wmaybe-uninitialized]
> > > >for (j = 0; j < levelcnt[i]; j++, rnp++) {
> > > > 
> > > > This warning looks like a false positive to me, given that the loop
> > > > near the beginning of the function initializes levelcnt[0].  Am I
> > > > missing something here, and either way, what is the best way to shut
> > > > this warning up?
> > > 
> > > My suggestion is the following:
> > > 
> > >   if (rcu_num_lvls <= 0)
> > >   panic("rcu_init_one: rcu_num_lvls underflow");
> > > 
> > > Just following the other panic() in rcu_init_one().
> > 
> > As in the following patch.
> > 
> > Thanx, Paul
> > 
> > 
> > 
> > rcu: Shut up spurious gcc uninitialized-variable warning
> > 
> > Because gcc doesn't realize that rcu_num_lvls must be strictly greater
> > than zero, some versions give a spurious warning about levelcnt[0] being
> > uninitialized in rcu_init_one().  This commit adds a panic() in that
> > case in order to educate gcc on this point.
> > 
> > Signed-off-by: Paul E. McKenney 
> > 
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index bd5a9a1db048..5b42d94335e3 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -3942,6 +3942,8 @@ static void __init rcu_init_one(struct rcu_state *rsp,
> > /* Silence gcc 4.8 warning about array index out of range. */
> > if (rcu_num_lvls > RCU_NUM_LVLS)
> > panic("rcu_init_one: rcu_num_lvls overflow");
> > +   if (rcu_num_lvls <= 0)
> > +   panic("rcu_init_one: rcu_num_lvls underflow");
> 
> I believe '... else if (rcu_num_lvls <= 0)' is more appropriate here.

Good point.

> But do you think keeping two static strings just to shut the compiler
> worth it? May be a single complain would be enough?

As in the following?

if (rcu_num_lvls <= 0 || rcu_num_lvls > RCU_NUM_LVLS)
panic("rcu_init_one: rcu_num_lvls out of range");


For Tree RCU, I doubt that the memory size matters, but I do like
having two lines of code instead of four lines.  I took this approach.

Thanx, Paul

>   if (rcu_num_lvls <= 0 || rcu_num_lvls > RCU_NUM_LVLS)
>   panic("rcu_init_one: rcu_num_lvls is out of range");
> 
> > /* Initialize the level-tracking arrays. */
> >  
> > 
> 
> -- 
> Regards,
> Alexander Gordeev
> agord...@redhat.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] perf build: Fix libbabeltrace detection

[Jérémie Galarneau]

On Tue, Mar 10, 2015 at 10:11 AM, Jiri Olsa  wrote:
> On Tue, Mar 10, 2015 at 11:01:34AM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Tue, Mar 10, 2015 at 01:00:35PM +0100, Jiri Olsa escreveu:
>> > On Mon, Mar 09, 2015 at 08:28:45PM -0300, Arnaldo Carvalho de Melo wrote:
>> > > Em Mon, Mar 09, 2015 at 08:11:19PM -0300, Arnaldo Carvalho de Melo 
>> > > escreveu:
>> > > > Em Mon, Mar 09, 2015 at 06:51:21PM -0300, Arnaldo Carvalho de Melo 
>> > > > escreveu:
>> > > [root@zoo ~]# find /opt/libbabeltrace/include/babeltrace/ -type f | 
>> > > xargs grep bt_ctf_stream_class_get_packet_context_type
>> > > /opt/libbabeltrace/include/babeltrace/ctf-ir/stream-class.h:extern 
>> > > struct bt_ctf_field_type *bt_ctf_stream_class_get_packet_context_type(
>>
>> > > That seems to be included from the file included in the feature test 
>> > > code :-\
>> > > Really ran out of time now...
>>
>> > ouch, thanks a lot for debugging.. the reason is indeed the -Werror added 
>> > by:
>> >   b49f1a4be701 perf tools: Improve feature test debuggability
>>
>> > following patch seems to fix this for me
>> > ---
>> > Following patch added -Werror for feature builds:
>> >   b49f1a4be701 perf tools: Improve feature test debuggability
>>
>> > and broke libbabeltrace feature build, because it was including
>> > wrong header and gcc couldn't find the used symbol definition.
>>
>> > Adding proper header and keeping the old one as it is needed
>> > also (libbabeltrace quirk).
>>
>> > +++ b/tools/perf/config/feature-checks/test-libbabeltrace.c
>> >  #include 
>> > +#include 
>>
>> Right, that was the fix I found as well, well, I was trying to include
>> _just_ babeltrace/ctf-ir/stream-class.h, but that is buggy in that it
>> doesn't include the header file with the uint32_t and int64_t types:
>
> yep, thats the 'libbabeltrace quirk' I mentioned in the changelog ;-)
>

Seems I missed that being discussed. Fixed in Babeltrace master as of 48d711aa2.

Jérémie

>>
>> [acme@zoo linux]$ cat 
>> /tmp/build/perf/config/feature-checks/make-libbabeltrace
>> make[1]: Entering directory 
>> `/home/git/linux/tools/perf/config/feature-checks'
>> gcc -MD -I/opt/libbabeltrace//include -Wall -Werror -o 
>> /tmp/build/perf/config/feature-checks/test-libbabeltrace.bin 
>> test-libbabeltrace.c -Wl,-z,noexecstack -L/opt/libbabeltrace//lib 
>> -lbabeltrace-ctf # -lbabeltrace provided by
>> In file included from test-libbabeltrace.c:2:0:
>> /opt/libbabeltrace//include/babeltrace/ctf-ir/stream-class.h:118:1: error: 
>> unknown type name ‘int64_t’
>>  extern int64_t bt_ctf_stream_class_get_id(
>>  ^
>> /opt/libbabeltrace//include/babeltrace/ctf-ir/stream-class.h:134:45: error: 
>> unknown type name ‘uint32_t’
>>struct bt_ctf_stream_class *stream_class, uint32_t id);
>>  ^
>> make[1]: *** [test-libbabeltrace.bin] Error 1
>> make[1]: Leaving directory `/home/git/linux/tools/perf/config/feature-checks'
>> [acme@zoo linux]$
>>
>> >
>> >  int main(void)
>> >  {
>> > --
>> > 1.9.3
>>
>> Ah, I found the following patch useful in debugging this, if you're ok with 
>> it,
>> I'll put it in my tree with your Acked-by, ok?
>>
>> - Arnaldo
>>
>> [acme@zoo linux]$ git diff tools/perf/config/Makefile
>> diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
>> index e2350ada6ccd..4992c39652e6 100644
>> --- a/tools/perf/config/Makefile
>> +++ b/tools/perf/config/Makefile
>> @@ -184,7 +184,7 @@ endif
>>
>>  feature_check = $(eval $(feature_check_code))
>>  define feature_check_code
>> -  feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) 
>> CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" LDFLAGS="$(LDFLAGS) 
>> $(FEATURE_CHECK_LDFLAGS-$(1))" -C config/feature-checks test-$1.bin 
>> >/dev/null 2>/dev/null && echo 1 ||
>> +  feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) 
>> CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" LDFLAGS="$(LDFLAGS) 
>> $(FEATURE_CHECK_LDFLAGS-$(1))" -C config/feature-checks test-$1.bin > 
>> $(OUTPUT_FEATURES)make-$(1) 2>&1
>>  endef
>
> ack, that seem usefull.. I always redirected this to '>> /tmp/krava'
> never got enough will to make it nice and generic ;-)
>
> thanks,
> jirka



-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.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 2/4] soc: Mediatek: Add SCPSYS power domain driver

[Sascha Hauer]

On Tue, Mar 10, 2015 at 10:41:42AM +0100, Sascha Hauer wrote:
> > > + if (data->bus_prot_mask) {
> > > + u32 mask = data->bus_prot_mask;
> > > + struct regmap *infracfg = scp->infracfg;
> > > +
> > > + regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
> > > +
> > > + expired = jiffies + HZ;
> > > +
> > > + while (1) {
> > > + u32 val;
> > > +
> > > + ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, 
> > > );
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (!(val & mask))
> > > + break;
> > > +
> > > + cpu_relax();
> > > + if (time_after(jiffies, expired))
> > > + return -EIO;
> > > + }
> > > + }
> > 
> > This whole "Clear bus protection bits" part seems like it should be an
> > API in the infracfg driver.
> 
> Ok, can do.

Since the infracfg driver (which is really a clk driver) currently is
pending for inclusion I don't want to add more patches to it. I decided
to drop the protection bits for now and come back to this once the
infracfg driver is merged.

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/

[PATCH 1/7] ppc: Remove unused cpp symbols in kvm headers

[Frederic Weisbecker]

These don't seem to be used anywhere.

Acked-by: Rik van Riel 
Cc: Benjamin Herrenschmidt 
Cc: Alexander Graf 
Cc: Paul E. McKenney 
Cc: Andy Lutomirski 
Cc: Will deacon 
Cc: Marcelo Tosatti 
Cc: Christian Borntraeger 
Cc: Luiz Capitulino 
Cc: Paolo Bonzini 
Signed-off-by: Frederic Weisbecker 
---
 arch/powerpc/include/asm/kvm_book3s.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index 942c7b1..9930904 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -106,10 +106,6 @@ struct kvmppc_vcpu_book3s {
spinlock_t mmu_lock;
 };
 
-#define CONTEXT_HOST   0
-#define CONTEXT_GUEST  1
-#define CONTEXT_GUEST_END  2
-
 #define VSID_REAL  0x07c0ULL
 #define VSID_BAT   0x07b0ULL
 #define VSID_64K   0x0800ULL
-- 
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 4/7] context_tracking: Add stub context_tracking_is_enabled

[Frederic Weisbecker]

From: Rik van Riel 

With code elsewhere doing something conditional on whether or not
context tracking is enabled, we want a stub function that tells us
context tracking is not enabled, when CONFIG_CONTEXT_TRACKING is
not set.

Reviewed-by: Paul E. McKenney 
Signed-off-by: Rik van Riel 
Cc: Paul E. McKenney 
Cc: Andy Lutomirski 
Cc: Will deacon 
Cc: Marcelo Tosatti 
Cc: Christian Borntraeger 
Cc: Luiz Capitulino 
Cc: Paolo Bonzini 
Signed-off-by: Frederic Weisbecker 
---
 include/linux/context_tracking_state.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/context_tracking_state.h 
b/include/linux/context_tracking_state.h
index 8076f87..ad44585 100644
--- a/include/linux/context_tracking_state.h
+++ b/include/linux/context_tracking_state.h
@@ -39,6 +39,8 @@ static inline bool context_tracking_in_user(void)
 #else
 static inline bool context_tracking_in_user(void) { return false; }
 static inline bool context_tracking_active(void) { return false; }
+static inline bool context_tracking_is_enabled(void) { return false; }
+static inline bool context_tracking_cpu_is_enabled(void) { return false; }
 #endif /* CONFIG_CONTEXT_TRACKING */
 
 #endif
-- 
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/

Re: [PATCH v3] livepatch/module: Correctly handle coming and going modules

[Petr Mladek]

On Tue 2015-03-10 09:22:04, Josh Poimboeuf wrote:
> On Tue, Mar 10, 2015 at 01:01:07PM +0100, Petr Mladek wrote:
> > On Mon 2015-03-09 09:40:55, Josh Poimboeuf wrote:
> > > On Mon, Mar 09, 2015 at 02:25:28PM +0100, Petr Mladek wrote:
> > > > diff --git a/kernel/module.c b/kernel/module.c
> > > > index d856e96a3cce..b3ffc231ce0d 100644
> > > > --- a/kernel/module.c
> > > > +++ b/kernel/module.c
> > > > @@ -3271,6 +3271,10 @@ static int load_module(struct load_info *info, 
> > > > const char __user *uargs,
> > > > }
> > > >  #endif
> > > >  
> > > > +#ifdef CONFIG_LIVEPATCH
> > > > +   mod->klp_alive = false;
> > > > +#endif
> > > > +
> > > 
> > > I don't think you need this initialization.  It looks like the module
> > > struct is embedded in the mod->module_core region which is initialized
> > > to zero in move_module().
> > 
> > I have looked at this before but I was not able to find a code
> > zeroing struct module. If I get it correctly, mod->module_core
> > is a location where symbol table sections are copied or so.
> 
> Yeah, it's far from obvious.  AFAICT, it's cleared by the
> "memset(ptr, 0, mod->core_size)" line.

What I wanted to say is that module_core is not struct module. It
seems that it points to the module code. See within_module_core() and
how it is used().

By other words, I think that struct module is not zeroed and we need
to initialize the bool.

Or did I miss anything?

Best Regards,
Petr
--
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 3/7] context_tracking: Generalize context tracking APIs to support user and guest

[Frederic Weisbecker]

From: Rik van Riel 

Generalize the context tracking APIs to support various nature of
contexts. This is performed by splitting out the mechanism from
context_tracking_user_enter and context_tracking_user_exit into
context_tracking_enter and context_tracking_exit.

The nature of the context we track is now detailed in a ctx_state
parameter pushed to these APIs, allowing the same functions to not just
track kernel <> user space switching, but also kernel <> guest transitions.

But leave the old functions in order to avoid breaking ARM, which calls
these functions from assembler code, and cannot easily use C enum
parameters.

Reviewed-by: Paul E. McKenney 
Signed-off-by: Rik van Riel 
Cc: Paul E. McKenney 
Cc: Andy Lutomirski 
Cc: Will deacon 
Cc: Marcelo Tosatti 
Cc: Christian Borntraeger 
Cc: Luiz Capitulino 
Cc: Paolo Bonzini 
Signed-off-by: Frederic Weisbecker 
---
 include/linux/context_tracking.h |  9 ++---
 kernel/context_tracking.c| 43 ++--
 2 files changed, 34 insertions(+), 18 deletions(-)

diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h
index 427b056..7f1810a 100644
--- a/include/linux/context_tracking.h
+++ b/include/linux/context_tracking.h
@@ -10,6 +10,8 @@
 #ifdef CONFIG_CONTEXT_TRACKING
 extern void context_tracking_cpu_set(int cpu);
 
+extern void context_tracking_enter(enum ctx_state state);
+extern void context_tracking_exit(enum ctx_state state);
 extern void context_tracking_user_enter(void);
 extern void context_tracking_user_exit(void);
 extern void __context_tracking_task_switch(struct task_struct *prev,
@@ -35,7 +37,8 @@ static inline enum ctx_state exception_enter(void)
return 0;
 
prev_ctx = this_cpu_read(context_tracking.state);
-   context_tracking_user_exit();
+   if (prev_ctx != CONTEXT_KERNEL)
+   context_tracking_exit(prev_ctx);
 
return prev_ctx;
 }
@@ -43,8 +46,8 @@ static inline enum ctx_state exception_enter(void)
 static inline void exception_exit(enum ctx_state prev_ctx)
 {
if (context_tracking_is_enabled()) {
-   if (prev_ctx == CONTEXT_USER)
-   context_tracking_user_enter();
+   if (prev_ctx != CONTEXT_KERNEL)
+   context_tracking_enter(prev_ctx);
}
 }
 
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 8ad53c9..17715d8 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -39,15 +39,15 @@ void context_tracking_cpu_set(int cpu)
 }
 
 /**
- * context_tracking_user_enter - Inform the context tracking that the CPU is 
going to
- *   enter userspace mode.
+ * context_tracking_enter - Inform the context tracking that the CPU is going
+ *  enter user or guest space mode.
  *
  * This function must be called right before we switch from the kernel
- * to userspace, when it's guaranteed the remaining kernel instructions
- * to execute won't use any RCU read side critical section because this
- * function sets RCU in extended quiescent state.
+ * to user or guest space, when it's guaranteed the remaining kernel
+ * instructions to execute won't use any RCU read side critical section
+ * because this function sets RCU in extended quiescent state.
  */
-void context_tracking_user_enter(void)
+void context_tracking_enter(enum ctx_state state)
 {
unsigned long flags;
 
@@ -75,7 +75,7 @@ void context_tracking_user_enter(void)
WARN_ON_ONCE(!current->mm);
 
local_irq_save(flags);
-   if ( __this_cpu_read(context_tracking.state) != CONTEXT_USER) {
+   if ( __this_cpu_read(context_tracking.state) != state) {
if (__this_cpu_read(context_tracking.active)) {
trace_user_enter(0);
/*
@@ -101,24 +101,31 @@ void context_tracking_user_enter(void)
 * OTOH we can spare the calls to vtime and RCU when 
context_tracking.active
 * is false because we know that CPU is not tickless.
 */
-   __this_cpu_write(context_tracking.state, CONTEXT_USER);
+   __this_cpu_write(context_tracking.state, state);
}
local_irq_restore(flags);
 }
+NOKPROBE_SYMBOL(context_tracking_enter);
+
+void context_tracking_user_enter(void)
+{
+   context_tracking_enter(CONTEXT_USER);
+}
 NOKPROBE_SYMBOL(context_tracking_user_enter);
 
 /**
- * context_tracking_user_exit - Inform the context tracking that the CPU is
- *  exiting userspace mode and entering the kernel.
+ * context_tracking_exit - Inform the context tracking that the CPU is
+ * exiting user or guest mode and entering the kernel.
  *
- * This function must be called after we entered the kernel from userspace
- * before any use of RCU read side critical section. This potentially include
- * any high level kernel code like 

[PATCH 6/7] context_tracking: Export context_tracking_user_enter/exit

[Frederic Weisbecker]

From: Rik van Riel 

Export context_tracking_user_enter/exit so it can be used by KVM.

Reviewed-by: Paul E. McKenney 
Signed-off-by: Rik van Riel 
Cc: Paul E. McKenney 
Cc: Andy Lutomirski 
Cc: Will deacon 
Cc: Marcelo Tosatti 
Cc: Christian Borntraeger 
Cc: Luiz Capitulino 
Cc: Paolo Bonzini 
Signed-off-by: Frederic Weisbecker 
---
 kernel/context_tracking.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index a2c0866..72d59a1 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -108,6 +108,7 @@ void context_tracking_enter(enum ctx_state state)
local_irq_restore(flags);
 }
 NOKPROBE_SYMBOL(context_tracking_enter);
+EXPORT_SYMBOL_GPL(context_tracking_enter);
 
 void context_tracking_user_enter(void)
 {
@@ -155,6 +156,7 @@ void context_tracking_exit(enum ctx_state state)
local_irq_restore(flags);
 }
 NOKPROBE_SYMBOL(context_tracking_exit);
+EXPORT_SYMBOL_GPL(context_tracking_exit);
 
 void context_tracking_user_exit(void)
 {
-- 
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/