Re: [PATCH 1/7] ARM: dts: qcom: Add PM8841 functions device nodes

[Ivan T. Ivanov]

On Wed, 2015-04-01 at 14:54 -0500, Kumar Gala wrote:
> On Apr 1, 2015, at 10:05 AM, Ivan T. Ivanov iva...@linaro.org> wrote:
> 
> > Add configuration nodes for multi purpose pins and
> > thermal sensor devices. Thermal sensor will report
> > PMIC die temperature.
> > 
> > Signed-off-by: Ivan T. Ivanov iva...@linaro.org>
> > ---
> > arch/arm/boot/dts/qcom-pm8841.dtsi | 14 ++
> > 1 file changed, 14 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/qcom-pm8841.dtsi 
> > b/arch/arm/boot/dts/qcom-pm8841.dtsi
> > index 73813cc..5c109bd 100644
> > --- a/arch/arm/boot/dts/qcom-pm8841.dtsi
> > +++ b/arch/arm/boot/dts/qcom-pm8841.dtsi
> > @@ -7,6 +7,20 @@
> > reg = <0x4 SPMI_USID>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > +
> > +   pm8841_mpps: mpps@a000 {
> > +   compatible = "qcom,pm8841-mpp";
> > +   reg = <0xa000 0x400>;
> > +   gpio-controller;
> > +   #gpio-cells = <2>;
> > +   interrupts = <4 0xa0 0 0>, <4 0xa1 0 0>, <4 0xa2 0 
> > 0>, <4 0xa3 0 0>;
> 
> What’s the interrupt parent here with 4 cells? 

SPMI PMIC Arbiter controller.

Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting

[Omar Sandoval]

On Wed, Apr 08, 2015 at 02:06:14PM +0800, Qu Wenruo wrote:
> 
> 
>  Original Message  
> Subject: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
> From: Omar Sandoval 
> To: Chris Mason , Josef Bacik , David Sterba
> , 
> Date: 2015年04月08日 13:34
> 
> >Currently, mounting a subvolume with subvolid= takes a different code
> >path than mounting with subvol=. This isn't really a big deal except for
> >the fact that mounts done with subvolid= or the default subvolume don't
> >have a dentry that's connected to the dentry tree like in the subvol=
> >case. To unify the code paths, when given subvolid= or using the default
> >subvolume ID, translate it into a subvolume name by walking
> >ROOT_BACKREFs in the root tree and INODE_REFs in the filesystem trees.

Hi, Qu,

> Oh, this patch is what I have tried long long ago, and want to do the same
> thing, to show subvolume mount for btrfs.

Thanks for pointing that out, I didn't come across your post when I was
looking around. I figured that someone must have thought of it first :) 

> But it came to me that, superblock->show_path() is a better method to do it.
> 
> You can implement btrfs_show_path() to allow mountinfo to get the subvolume
> name from subvolid, and don't change the mount routine much.

Hm, I don't think that the changes to the mount code would be
unwarranted. Having one code path makes it more obvious what's going on.
Do you mind elaborating on why you preferred doing it in ->show_path()?

Thanks!

> Thanks,
> Qu

-- 
Omar
--
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 1/4] drm/layerscape: Add Freescale DCU DRM driver

[jianwei.w...@freescale.com]

Hi Stefan,

> -Original Message-
> From: Stefan Agner [mailto:ste...@agner.ch]
> Sent: Tuesday, April 07, 2015 8:12 PM
> To: Wang Jianwei-B52261
> Cc: Wood Scott-B07421; airl...@linux.ie; dri-de...@lists.freedesktop.org;
> devicet...@vger.kernel.org; Xiubo Li; Wang Huan-B18965; linux-
> ker...@vger.kernel.org; Jin Zhengxiong-R64188; linux-arm-
> ker...@lists.infradead.org
> Subject: RE: [PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM driver
> 
> Hi Jianwei,
> 
> On 2015-04-07 08:44, jianwei.w...@freescale.com wrote:
> > Hi Stefan,
> >
> > Thank you for your review and testing on Vybrid F610 device. This driver
> > just implement the basic functions and it only support the exported
> > framebuffer access. Some DRM interfaces are not implemented now. So your
> > test result is normal. I will implement these interfaces with patches
> soon
> > afterwards. I don't plan to add new features for the initial version
> driver,
> > otherwise it will be a long term for this version.
> >
> > I tested on ls1021a using TFT panel, there are no flickers on the screen
> > when inserting a USB HID device. I will do more test if time permits.
> >
> > By the way, could please give me some guidance on how X-Server use DRM
> > Interface directly? Do you have some papers or webpage about this?
> 
> I'm using the modesetting X.org driver. Lots of distributions ship that
> driver as a package (e.g. xserver-xorg-video-modesetting in Debian, or
> xf86-video-modesetting in OpenEmbedded). Since 1.17 this driver has even
> been included into the main source tree of Xorg X-Server
> (http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesett
> ing)
> 
> This driver is using KMS/DRM interface and should work well for
> un-accelerated graphic devices. This is a a much nicer way to use X.org
> on top of a DRM driver, since it avoids going through the legacy fbdev
> interface. The man page shows how to use it:
> http://linux.die.net/man/4/modesetting
> 
> So, when the driver is installed, it is just choosing that driver in
> xorg.conf:
> 
> Section "Device"
> Identifier  "dcu"
> Driver  "modesetting"
> EndSection
> 

Thank you for your guidance.

> Some more comments below...
> 
> >
> > My reply below...
> >
> >>
> >> Hi Jianwei,
> >>
> >> The driver worked on a Vybrid VF610 device using the exported
> >> framebuffer. However, when using X-Server through the DRM interface
> >> directly (by using the modesetting driver) I get just a black screen so
> >> far, still investigating the reason. What user-space interfaces did you
> >> test?
> >>
> >> When using the FB device and insert a USB HID device, I get some
> >> flickers on the screen. I didn't had those on the dcufb driver, did you
> >> notice something like this too? Probably related to the resolution, I'm
> >> using VGA resolution.
> >>
> >> Some comments below.
> >>
> >>
> >> On 2015-03-26 06:37, Jianwei Wang wrote:
> >> > This patch add support for Two Dimensional Animation and Compositing
> >> > Engine (2D-ACE) on the Freescale SoCs.
> >> >
> >> > 2D-ACE is a Freescale display controller. 2D-ACE describes
> >> > the functionality of the module extremely well its name is a value
> >> > that cannot be used as a token in programming languages.
> >> > Instead the valid token "DCU" is used to tag the register names and
> >> > function names.
> >> >
> >> > The Display Controller Unit (DCU) module is a system master that
> >> > fetches graphics stored in internal or external memory and displays
> >> > them on a TFT LCD panel. A wide range of panel sizes is supported
> >> > and the timing of the interface signals is highly configurable.
> >> > Graphics are read directly from memory and then blended in real-time,
> >> > which allows for dynamic content creation with minimal CPU
> >> > intervention.
> >> >
> >> > The features:
> >> > (1) Full RGB888 output to TFT LCD panel.
> >> > (2) For the current LCD panel, WQVGA "480x272" is supported.
> >> > (3) Blending of each pixel using up to 4 source layers
> >> > dependent on size of panel.
> >>
> >> modetest only shows one layer currently...
> >
> > Yes, only one plane and one framebuffer were created now, others
> > maybe create as user requirement or create all when initializing,
> > I'm not sure now. This describe the hardware feature
> >
> >>
> >> > (4) Each graphic layer can be placed with one pixel resolution
> >> > in either axis.
> >> > (5) Each graphic layer support RGB565 and RGB888 direct colors
> >> > without alpha channel
> >> > and BGRA direct colors with an alpha channel.
> >>
> >> The array fsl_dcu_drm_plane_formats below shows more formats, does this
> >> commit log needs updating?
> >>
> >
> > I agree with your suggestion, I will update this commit log
> >
> >> > (6) Each graphic layer support alpha blending with 8-bit
> >> > resolution.
> >> >
> >> > This is a simplified version, only one primary plane, one
> >> > framebuffer created for fbdev, one crtc, one connector for

Re: [PATCH] x86/asm/entry/64: Add forgotten CFI annotation

[Ingo Molnar]

* Denys Vlasenko  wrote:

> Signed-off-by: Denys Vlasenko 
> CC: Linus Torvalds 
> CC: Steven Rostedt 
> CC: Ingo Molnar 
> CC: Borislav Petkov 
> CC: "H. Peter Anvin" 
> CC: Andy Lutomirski 
> CC: Oleg Nesterov 
> CC: Frederic Weisbecker 
> CC: Alexei Starovoitov 
> CC: Will Drewry 
> CC: Kees Cook 
> CC: x...@kernel.org
> CC: linux-kernel@vger.kernel.org
> ---
>  arch/x86/kernel/entry_64.S | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index 65485b3..15261ba 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -429,6 +429,7 @@ return_from_execve:
>  1:
>   /* must use IRET code path (pt_regs->cs may have changed) */
>   addq$8, %rsp
> + CFI_ADJUST_CFA_OFFSET -8
>   ZERO_EXTRA_REGS
>   movq%rax,RAX(%rsp)
>   jmp int_ret_from_sys_call

So given that this is a pretty common pattern:

triton:~/tip> git grep -A 1 'addq.*%rsp' arch/x86/kernel/entry_64.S
arch/x86/kernel/entry_64.S: addq$8, %rsp
arch/x86/kernel/entry_64.S- CFI_ADJUST_CFA_OFFSET -8
--
arch/x86/kernel/entry_64.S: addq $8, %rsp
arch/x86/kernel/entry_64.S- DEFAULT_FRAME 0
--
arch/x86/kernel/entry_64.S: addq $8, %rsp
arch/x86/kernel/entry_64.S- DEFAULT_FRAME 0
--
arch/x86/kernel/entry_64.S: addq $-0x80,(%rsp)  /* Adjust 
vector to [-256,-1] range */
arch/x86/kernel/entry_64.S- interrupt do_IRQ
--
arch/x86/kernel/entry_64.S: addq $0x30,%rsp
arch/x86/kernel/entry_64.S- CFI_ADJUST_CFA_OFFSET -0x30
--
arch/x86/kernel/entry_64.S: addq $0x30,%rsp
arch/x86/kernel/entry_64.S- CFI_ADJUST_CFA_OFFSET -0x30
--
arch/x86/kernel/entry_64.S: addq $(6*8), %rsp
arch/x86/kernel/entry_64.S- CFI_ADJUST_CFA_OFFSET -6*8
--
arch/x86/kernel/entry_64.S: addq $(10*8), %rsp
arch/x86/kernel/entry_64.S- CFI_ADJUST_CFA_OFFSET -10*8


it might make sense to introduce addq_cfi, to further hide the dwarf 
uglies?

btw., doesn't:

arch/x86/kernel/entry_64.S: addq $-0x80,(%rsp)  /* Adjust 
vector to [-256,-1] range */

before the do_IRQ() call need a CFI adjustment as well?

Thanks,

Ingo
--
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: [PATCHv2 1/2] timekeeping: Provide new API to get the current time resolution

[Richard Weinberger]

Am 08.04.2015 um 00:30 schrieb Richard Weinberger:
> Am 07.04.2015 um 13:12 schrieb Harald Geyer:
>> This patch series introduces a new function
>> u32 ktime_get_resolution_ns(void)
>> which allows to clean up some driver code.
>>
>> In particular the IIO subsystem has a function to provide timestamps for
>> events but no means to get their resolution. So currently the dht11 driver
>> tries to guess the resolution in a rather messy and convoluted way. We
>> can do much better with the new code.
>>
>> This API is not designed to be exposed to user space.
>>
>> This has been tested on i386, sunxi and mxs.
>>
>> Signed-off-by: Harald Geyer 
>> ---
>> changes since V1:
>> Improved commit message.
>>
>>  include/linux/timekeeping.h |1 +
>>  kernel/time/timekeeping.c   |   17 +
>>  2 files changed, 18 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
>> index 3eaae47..983b61e 100644
>> --- a/include/linux/timekeeping.h
>> +++ b/include/linux/timekeeping.h
>> @@ -163,6 +163,7 @@ extern ktime_t ktime_get(void);
>>  extern ktime_t ktime_get_with_offset(enum tk_offsets offs);
>>  extern ktime_t ktime_mono_to_any(ktime_t tmono, enum tk_offsets offs);
>>  extern ktime_t ktime_get_raw(void);
>> +extern u32 ktime_get_resolution_ns(void);
>>  
>>  /**
>>   * ktime_get_real - get the real (wall-) time in ktime_t format
>> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
>> index 91db941..8efd964 100644
>> --- a/kernel/time/timekeeping.c
>> +++ b/kernel/time/timekeeping.c
>> @@ -586,6 +586,23 @@ ktime_t ktime_get(void)
>>  }
>>  EXPORT_SYMBOL_GPL(ktime_get);
>>  
>> +u32 ktime_get_resolution_ns(void)
>> +{
>> +struct timekeeper *tk = &tk_core.timekeeper;
>> +unsigned int seq;
>> +u32 nsecs;
>> +
>> +WARN_ON(timekeeping_suspended);
>> +
>> +do {
>> +seq = read_seqcount_begin(&tk_core.seq);
>> +nsecs = tk->tkr.mult >> tk->tkr.shift;
>> +} while (read_seqcount_retry(&tk_core.seq, seq));
>> +
>> +return nsecs;
>> +}
>> +EXPORT_SYMBOL_GPL(ktime_get_resolution_ns);
> 
> Hmm, isn't this ktime_get_raw_ns()?

Whoops, it is of course not the same.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tpm: unified PPI interface for TPM 1.x/2.0 devices

[Jarkko Sakkinen]

On Wed, Apr 01, 2015 at 12:19:25PM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 01, 2015 at 03:28:52PM +0300, Jarkko Sakkinen wrote:
> > Added PPI interface to the character device. PPI interface is also kept
> > in the pdev for backwards compatibility.
> 
> Could you look at just completely moving the PPI interface to the char
> dev and then adding a symlink from the pdev? That would be really
> ideal.
> 
> symlinks have the advantage that they actually fully fix the lifetime
> issues.
> 
> This seems doable, if we replace the ppi_attrs group with a bunch of
> calls to sysfs_create_link it should work ?

If we follow the pattern in [1] by the book, how would you use
sysfs_create_link()? To be more specific, how would you get the driver
core to create the symlinks for you? 

If we decide not to follow [1] by the book, then this might be doable 
(thinking off my head, that's the reason why I use *might be* instead
of *is*). Wouldn't we get non-racy behavior if sysfs_create_link()'s
are executed after device_initialize() and before device_add()?

> > +static struct tpm_chip *ppi_dev_to_chip(struct device *dev)
> > +{
> > +   struct tpm_chip *chip = dev_get_drvdata(dev);
> > +
> > +   if (chip == NULL)
> > +   chip = to_tpm_chip(chip);
> > +
> > +   return chip;
> > +}
> 
> If symlinks don't work out, we should probably just set the drvdata on
> the tpm_chip itself to avoid this.

I'll experiment with this. Thanks for the comment.

> > +   if (!(chip->flags & TPM_CHIP_FLAG_PPI))
> > +   return -EINVAL;
> 
> Hum, I don't think the PPI files should be created if there is no PPI
> support..

Again, following [1] by the book. And again, I think we could just as
well do our sysfs stuff in-between device_initialize() and device_add()
and get the non-racy behavior.

> > +void __init tpm_ppi_init(struct class *tpm_class)
> > +{
> > +   tpm_class->dev_groups = tpm_groups;
> >  }
> 
> So this shouldn't be unconditional.
> 
> Also, ultimately PPI can't just claim the dev_groups, other parts of
> the driver will need to add groups too.
> 
> I think it makes more sense to do
> 
> struct attribute_group *tpm_ppi_get_sysfs(struct tpm_chip *chip)
> {
> }
> 
> And take care of building the list in the caller.
> 
> And tpm_ppi_get_sysfs should be called after the driver is readied but
> before adding the device.

I don't think this would matter. Things could be refactored when more
sysfs attributes are needed.

> Jason

/Jarkko


[1] http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/

--
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 "drivers: thermal: st: remove several sparse warnings" added to thermal-soc tree

[Lee Jones]

On Tue, 07 Apr 2015, Eduardo Valentin wrote:

> 
> This is a simple automated notification to let you know that 
> I've just added the patch titled
> 
> drivers: thermal: st: remove several sparse warnings
> 
> to my thermal-soc git tree which can be found at
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
> in the fixes branch.
> 
> The patch will show up in the next release of the linux-next tree
> (usually sometime within the next 24 hours during the week.)
> 
> The patch will hopefully also be merged in Linus's tree for the
> next -rc kernel release.
> 
> If you have any questions about this process, please let me know.
> 
> All the best,
> 
> Eduardo Valentin
> 
> --
> From 541d529f9845d249d1cb84f1b395e48f0a117e3f Mon Sep 17 00:00:00 2001
> From: Eduardo Valentin 
> Date: Tue, 7 Apr 2015 13:42:12 -0700
> Subject: drivers: thermal: st: remove several sparse warnings
> 
> Simple patch to make symbols static. Symbols that are not
> shared with other parts of the kernel can be made static.
> This change also removes several sparse complains.
> 
> Cc: Zhang Rui 
> Cc: Lee Jones 
> Cc: Pavel Machek 
> Cc: Ajit Pal Singh 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org

Hold on a second, you can't do that.

Adding these Cc: tags means "this person has been given the opportunity
to comment on the patch but has chosen not to".  However, you've
applied this patch ~1min after sending it to the lists.

Please leave this patch on the lists for some time (I suggest at least
one week) before applying.  This process can be sped-up if the correct
Acks are received.

> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/st/st_thermal.c|  2 +-
>  drivers/thermal/st/st_thermal_memmap.c |  8 
>  drivers/thermal/st/st_thermal_syscfg.c | 12 ++--
>  3 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/thermal/st/st_thermal.c b/drivers/thermal/st/st_thermal.c
> index d1ec580..76c515d 100644
> --- a/drivers/thermal/st/st_thermal.c
> +++ b/drivers/thermal/st/st_thermal.c
> @@ -25,7 +25,7 @@
>   * Function to allocate regfields which are common
>   * between syscfg and memory mapped based sensors
>   */
> -int st_thermal_alloc_regfields(struct st_thermal_sensor *sensor)
> +static int st_thermal_alloc_regfields(struct st_thermal_sensor *sensor)
>  {
>   struct device *dev = sensor->dev;
>   struct regmap *regmap = sensor->regmap;
> diff --git a/drivers/thermal/st/st_thermal_memmap.c 
> b/drivers/thermal/st/st_thermal_memmap.c
> index bd22339..fc0c9e1 100644
> --- a/drivers/thermal/st/st_thermal_memmap.c
> +++ b/drivers/thermal/st/st_thermal_memmap.c
> @@ -157,7 +157,7 @@ static const struct st_thermal_sensor_ops 
> st_mmap_sensor_ops = {
>  };
>  
>  /* Compatible device data stih416 mpe thermal sensor */
> -const struct st_thermal_compat_data st_416mpe_cdata = {
> +static const struct st_thermal_compat_data st_416mpe_cdata = {
>   .reg_fields = st_mmap_thermal_regfields,
>   .ops= &st_mmap_sensor_ops,
>   .calibration_val= 14,
> @@ -166,7 +166,7 @@ const struct st_thermal_compat_data st_416mpe_cdata = {
>  };
>  
>  /* Compatible device data stih407 thermal sensor */
> -const struct st_thermal_compat_data st_407_cdata = {
> +static const struct st_thermal_compat_data st_407_cdata = {
>   .reg_fields = st_mmap_thermal_regfields,
>   .ops= &st_mmap_sensor_ops,
>   .calibration_val= 16,
> @@ -181,12 +181,12 @@ static const struct of_device_id 
> st_mmap_thermal_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, st_mmap_thermal_of_match);
>  
> -int st_mmap_probe(struct platform_device *pdev)
> +static int st_mmap_probe(struct platform_device *pdev)
>  {
>   return st_thermal_register(pdev,  st_mmap_thermal_of_match);
>  }
>  
> -int st_mmap_remove(struct platform_device *pdev)
> +static int st_mmap_remove(struct platform_device *pdev)
>  {
>   return st_thermal_unregister(pdev);
>  }
> diff --git a/drivers/thermal/st/st_thermal_syscfg.c 
> b/drivers/thermal/st/st_thermal_syscfg.c
> index 65eab72..3df5b789 100644
> --- a/drivers/thermal/st/st_thermal_syscfg.c
> +++ b/drivers/thermal/st/st_thermal_syscfg.c
> @@ -104,7 +104,7 @@ static const struct st_thermal_sensor_ops 
> st_syscfg_sensor_ops = {
>  };
>  
>  /* Compatible device data for stih415 sas thermal sensor */
> -const struct st_thermal_compat_data st_415sas_cdata = {
> +static const struct st_thermal_compat_data st_415sas_cdata = {
>   .sys_compat = "st,stih415-front-syscfg",
>   .reg_fields = st_415sas_regfields,
>   .ops= &st_syscfg_sensor_ops,
> @@ -114,7 +114,7 @@ const struct st_thermal_compat_data st_415sas_cdata = {
>  };
>  
>  /* Compatible device data for stih415 mpe thermal sensor */
> -const struct st_thermal_compat_data st_415mpe_cdata = {
> +static const struct st_thermal

Re: [PATCH] x86, aperture: Check for GART before accessing GART registers

[Borislav Petkov]

On Tue, Apr 07, 2015 at 03:34:19PM -0500, Aravind Gopalakrishnan wrote:
> On 4/7/2015 9:57 AM, Borislav Petkov wrote:
> >On Tue, Apr 07, 2015 at 09:46:26AM -0500, Aravind Gopalakrishnan wrote:
> >>Okay. I'll do that and correct the typos Ingo pointed out earlier and
> >>resend.
> >Btw, I think you should do the same in early_gart_iommu_check() too.
> >
> >Doing the testing this way would mean that we first are testing for GART
> >hw presence and then do the rest of checks. If no GART hw, the rest of
> >the checks are meaningless.
> >
> >Also, when testing do a "pci=noearly" boot which should make
> >
> > !early_pci_allowed()
> >
> >true and thus test that path too.
> >
> 
> Here are results from further testing:
> 1. on platforms with both iommu and gart
> - with pci=noearly, we break out of init routines in aperture_64.c
> early. amd_iommu_init() will run through it's init routine.
> - if amd_iommu_init() fails somewhere, we fall back to
> gart_iommu_init()
> - gart_iommu_init() fails since gart_iommu_aperture is not set.
> - fall back to swiotlb.
> - with amd_iommu=off
> - init routines in aperture_64.c run fine as both amd_gart_present()
> and early_pci_allowed() are true
> -  amd_iommu_detect() fails due to command line arg.
> - fall back to gart iommu
> - with pci=noearly and amd_iommu=off
> - break out of aperture_64.c init routines, and amd_iommu_detect()
> fails.
> - fall back to swiotlb
> 
> 2. on platform with no gart but iommu present,
> - pci=noearly option is not relevant as we break before that due to
> !amd_gart_present()
> - if amd_iommu_init() fails somewhere, we fall back to swiotlb, else use
> iommu
> 
> 3. on platforms with no gart and no iommu
> - use swiotlb regardless of any command line options passed

I don't see anything out of the ordinary but then again I don't know
this code so...

@joro, can you please double-check?

Thanks.

-- 
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 0/2][RFC] mmc: cast to avoid unexpected error

[Kuninori Morimoto]

Hi Ulf

These 2 patches adds cast to avoid unexpected error.
It tries copy to u64 without cast.
The data will be 0xfff... if 1st bit was 1.
These are reported by coverity tool, but I couldn't test it.
So, I added [RFC] on these patches.
I'm happy if someone tests it, or can get deep review.

Kuninori Morimoto (2):
  mmc: cast u8 to unsigned long long to avoid unexpected error
  mmc: cast unsigned int to typeof(sector_t) to avoid unexpected error

 drivers/mmc/card/block.c | 2 +-
 drivers/mmc/core/mmc.c   | 6 --
 2 files changed, 5 insertions(+), 3 deletions(-)
--
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] brcmsmac: Move each system tracepoints to their own header

[Arend van Spriel]

On 04/07/15 18:11, Steven Rostedt wrote:


Every tracing file must have its own TRACE_SYSTEM defined.
The brcmsmac tracepoint header broke this and added in the middle
of the file:

  #undef TRACE_SYSTEM
  #define TRACE_SYSTEM brcmsmac

  #undef TRACE_SYSTEM
  #define TRACE_SYSTEM brcmsmac_tx

  #undef TRACE_SYSTEM
  #define TRACE_SYSTEM brcmsmac_msg

Unfortunately, this broke new code in the ftrace infrastructure.
Moving each of these TRACE_SYSTEMs into their own trace file with
just one TRACE_SYSTEM per file fixes the issue.

Cc: Arend van Spriel


All right. Go ahead and change Cc: into Acked-by:

Regards,
Arend


Signed-off-by: Steven Rostedt
---

Requesting an Acked-by so I can pull this into my tree where this is a
prerequisite for my new code.

  .../brcm80211/brcmsmac/brcms_trace_brcmsmac.h  | 102 ++
  .../brcm80211/brcmsmac/brcms_trace_brcmsmac_msg.h  |  88 
  .../brcm80211/brcmsmac/brcms_trace_brcmsmac_tx.h   | 110 ++
  .../brcm80211/brcmsmac/brcms_trace_events.h| 225 +
  4 files changed, 305 insertions(+), 220 deletions(-)
  create mode 100644 
drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_brcmsmac.h
  create mode 100644 
drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_brcmsmac_msg.h
  create mode 100644 
drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_brcmsmac_tx.h

diff --git a/drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_brcmsmac.h 
b/drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_brcmsmac.h
new file mode 100644
index ..a0da3248b942
--- /dev/null
+++ b/drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_brcmsmac.h
@@ -0,0 +1,102 @@
+/*
+ * Copyright (c) 2011 Broadcom Corporation
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+ * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+ * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#if !defined(__TRACE_BRCMSMAC_H) || defined(TRACE_HEADER_MULTI_READ)
+#define __TRACE_BRCMSMAC_H
+
+#include
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM brcmsmac
+
+/*
+ * We define a tracepoint, its arguments, its printk format and its
+ * 'fast binary record' layout.
+ */
+TRACE_EVENT(brcms_timer,
+   /* TPPROTO is the prototype of the function called by this tracepoint */
+   TP_PROTO(struct brcms_timer *t),
+   /*
+* TPARGS(firstarg, p) are the parameters names, same as found in the
+* prototype.
+*/
+   TP_ARGS(t),
+   /*
+* Fast binary tracing: define the trace record via TP_STRUCT__entry().
+* You can think about it like a regular C structure local variable
+* definition.
+*/
+   TP_STRUCT__entry(
+   __field(uint, ms)
+   __field(uint, set)
+   __field(uint, periodic)
+   ),
+   TP_fast_assign(
+   __entry->ms = t->ms;
+   __entry->set = t->set;
+   __entry->periodic = t->periodic;
+   ),
+   TP_printk(
+   "ms=%u set=%u periodic=%u",
+   __entry->ms, __entry->set, __entry->periodic
+   )
+);
+
+TRACE_EVENT(brcms_dpc,
+   TP_PROTO(unsigned long data),
+   TP_ARGS(data),
+   TP_STRUCT__entry(
+   __field(unsigned long, data)
+   ),
+   TP_fast_assign(
+   __entry->data = data;
+   ),
+   TP_printk(
+   "data=%p",
+   (void *)__entry->data
+   )
+);
+
+TRACE_EVENT(brcms_macintstatus,
+   TP_PROTO(const struct device *dev, int in_isr, u32 macintstatus,
+u32 mask),
+   TP_ARGS(dev, in_isr, macintstatus, mask),
+   TP_STRUCT__entry(
+   __string(dev, dev_name(dev))
+   __field(int, in_isr)
+   __field(u32, macintstatus)
+   __field(u32, mask)
+   ),
+   TP_fast_assign(
+   __assign_str(dev, dev_name(dev));
+   __entry->in_isr = in_isr;
+   __entry->macintstatus = macintstatus;
+   __entry->mask = mask;
+   ),
+   TP_printk("[%s] in_isr=%d macintstatus=%#x mask=%#x", __get_str(dev),
+ __entry->in_isr, __entry->macintstatus, __entry->mask)
+);
+#endif /* __TRACE_BRCMSMAC_H */
+
+#ifdef CONFIG_BRCM_TRACING
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH .
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE brcms_trace_brcmsmac
+#include
+
+#endif /* C

Re: [PATCH] irq: Remove unnecessary warning with affinity_hint

[Seiichi Ikarashi]

Hi,

On 2015-04-08 15:28, Ingo Molnar wrote:
> 
> * Seiichi Ikarashi  wrote:
> 
>> Hi,
>>
>> If you turn off a PCI device whose driver has set affinity_hint,
>> you will get warning message which does _not_ explain the reason
>> why it appeared from the user's point of view.
>>
>>   # echo 0 > /sys/bus/pci/slots/65/power
>>
>>   Apr 28 20:29:39 localhost kernel: [ cut here ]
>>   Apr 28 20:29:39 localhost kernel: WARNING: at kernel/irq/manage.c:1002 
>> __free_irq+0x22d/0x250() (Tainted: P   ---   )
>>   (snip)
>>
>> Users will misunderstand some problem has happened
>> even though he or she succeeded to turn off the device.
>> I suppose this warning was originally for a debug purpose
>> for driver developers and has incidentally been left.
>>
>> Just remove the warning is good and enough.
>>
>> Signed-off-by: Seiichi Ikarashi 
>>
>> --- a/kernel/irq/manage.c
>> +++ b/kernel/irq/manage.c
>> @@ -1335,7 +1335,7 @@ static struct irqaction *__free_irq(unsi
>>  
>>  #ifdef CONFIG_SMP
>>  /* make sure affinity_hint is cleaned up */
>> -if (WARN_ON_ONCE(desc->affinity_hint))
>> +if (desc->affinity_hint)
>>  desc->affinity_hint = NULL;
> 
> Well, drivers that are using irq_set_affinity_hint() are expected to 
> call:
> 
>   irq_set_affinity_hint(irq, NULL);
> 
> to clear the affinity mask, before releasing the irq. This warning 
> flags drivers that forgot to do that and which might thus leak a 
> dynamically allocated CPU mask (and/or other resources).

Calling irq_set_affinity_hint(irq, NULL) does not guarantee that
the driver does not forget to deallocate a dynamically allocated
CPU mask and/or other resources. But if calling it with NULL 2nd-arg
before releasing the irq is a virtual rule of using irq_set_affinity_hint()
interface, I understand it.

> 
> Feel free to turn the warning message into a more informative WARN() 
> that will blame the driver that triggered it, if the stack dump into 
> the driver wasn't a clue enough ...

Still, I do not know leaving the warning message is effective to
prevent drivers from potentially leaking resource... considering
a kind of cost-effectivenss. Business users (not developers) hate
such kind of messages for developers.

Thanks,
Seiichi

--
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][RFC] mmc: cast u8 to unsigned long long to avoid unexpected error

[Kuninori Morimoto]

From: Kuninori Morimoto 

card->ext_csd.enhanced_area_offset is defined as "unsigned long long",
and, ext_csd[] is defined as u8.
unsigned long long data might have strange data if first bit of ext_csd[]
was 1. this patch cast it to (unsigned long long)
ex)
u8  data8;
u64 data64;

data8 = 0x80;
data64 = (data8 << 24); // 0x8000
data64 = (((unsigned long long)data8) << 24); // 0x8000;

Reported-by: coverity 
Signed-off-by: Kuninori Morimoto 
---
 drivers/mmc/core/mmc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 1d41e85..3c663a2 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -265,8 +265,10 @@ static void mmc_manage_enhanced_area(struct mmc_card 
*card, u8 *ext_csd)
 * calculate the enhanced data area offset, in bytes
 */
card->ext_csd.enhanced_area_offset =
-   (ext_csd[139] << 24) + (ext_csd[138] << 16) +
-   (ext_csd[137] << 8) + ext_csd[136];
+   (((unsigned long long)ext_csd[139]) << 24) +
+   (((unsigned long long)ext_csd[138]) << 16) +
+   (((unsigned long long)ext_csd[137]) << 8) +
+   (((unsigned long long)ext_csd[136]));
if (mmc_card_blockaddr(card))
card->ext_csd.enhanced_area_offset <<= 9;
/*
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2][RFC] mmc: cast unsigned int to typeof(sector_t) to avoid unexpected error

[Kuninori Morimoto]

From: Kuninori Morimoto 

card->csd.capacity is defined as "unsigned int",
and, sector_t is defined as "u64" or "unsigned long" (depends on CONFIG_LBDAF)
sector_t data might have strange data if first bit of unsigned int
was 1. this patch cast it to typeof(sector_t)

ex) if sector_t was u64

unsigned int data;
sector_t sector;

data = 0x8000;
sector = (data << 8); // 0xff80
sector = (((typeof(sector_t))data) << 8); // 0x80

Reported-by: coverity 
Signed-off-by: Kuninori Morimoto 
---
 drivers/mmc/card/block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c69afb5..4d09b0c 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2205,7 +2205,7 @@ static struct mmc_blk_data *mmc_blk_alloc(struct mmc_card 
*card)
 * The CSD capacity field is in units of read_blkbits.
 * set_capacity takes units of 512 bytes.
 */
-   size = card->csd.capacity << (card->csd.read_blkbits - 9);
+   size = (typeof(sector_t))card->csd.capacity << 
(card->csd.read_blkbits - 9);
}
 
return mmc_blk_alloc_req(card, &card->dev, size, false, NULL,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting

[Qu Wenruo]

 Original Message  
Subject: Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
From: Omar Sandoval 
To: Qu Wenruo 
Date: 2015年04月08日 15:17


On Wed, Apr 08, 2015 at 02:06:14PM +0800, Qu Wenruo wrote:



 Original Message  
Subject: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
From: Omar Sandoval 
To: Chris Mason , Josef Bacik , David Sterba
, 
Date: 2015年04月08日 13:34


Currently, mounting a subvolume with subvolid= takes a different code
path than mounting with subvol=. This isn't really a big deal except for
the fact that mounts done with subvolid= or the default subvolume don't
have a dentry that's connected to the dentry tree like in the subvol=
case. To unify the code paths, when given subvolid= or using the default
subvolume ID, translate it into a subvolume name by walking
ROOT_BACKREFs in the root tree and INODE_REFs in the filesystem trees.


Hi, Qu,


Oh, this patch is what I have tried long long ago, and want to do the same
thing, to show subvolume mount for btrfs.


Thanks for pointing that out, I didn't come across your post when I was
looking around. I figured that someone must have thought of it first :)


But it came to me that, superblock->show_path() is a better method to do it.

You can implement btrfs_show_path() to allow mountinfo to get the subvolume
name from subvolid, and don't change the mount routine much.


Hm, I don't think that the changes to the mount code would be
unwarranted. Having one code path makes it more obvious what's going on.
Do you mind elaborating on why you preferred doing it in ->show_path()?

The story seems to be long.

At that time, I also tried to do the subvolid->path convert and it seems 
works.


But another problem, IIRC, btrfs losing its security label bug,
will be triggered more easy if we all go through the "subvol=" routine,
as that routine will use vfs_mount twice. The second time it will
definitely lost the security label.

Although the problem is later resolved by handling security label 
internally, but it drove me not touching the mount routine.



Also another problem is, "subvolid=" routine can also happen when the fs 
is already mounted, so there may be some operations ,like deleting files 
and dirs, interfere your subvolid->path search codes.
(During your while loop, there is a race windows between your 
release_path() and search_slot())

Resulting a mount failure even nothing goes wrong.

->show_path() method can't avoid above race problem, but the good thing 
is, even race happens, it won't disturb our mount.

Just a -EBUSY when showing /proc/self/mountinfo, not a mount failure.


Thanks,
Qu


Thanks!


Thanks,
Qu



--
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 7/7] vhost: feature to set the vring endianness

[Greg Kurz]

On Tue, 7 Apr 2015 17:01:31 +0200
Cornelia Huck  wrote:

> On Tue, 07 Apr 2015 14:19:31 +0200
> Greg Kurz  wrote:
> 
> > This patch brings cross-endian support to vhost when used to implement
> > legacy virtio devices. Since it is a relatively rare situation, the
> > feature availability is controlled by a kernel config option (not set
> > by default).
> > 
> > The ioctls introduced by this patch are for legacy only: virtio 1.0
> > devices are returned EPERM.
> > 
> > Signed-off-by: Greg Kurz 
> > ---
> >  drivers/vhost/Kconfig  |   10 
> >  drivers/vhost/vhost.c  |   55 
> > 
> >  drivers/vhost/vhost.h  |   17 +-
> >  include/uapi/linux/vhost.h |5 
> >  4 files changed, 86 insertions(+), 1 deletion(-)
> 
> > +#ifdef CONFIG_VHOST_SET_ENDIAN_LEGACY
> > +static long vhost_set_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + void __user *argp)
> > +{
> > +   struct vhost_vring_state s;
> > +
> > +   if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
> > +   return -EPERM;
> > +
> > +   if (copy_from_user(&s, argp, sizeof(s)))
> > +   return -EFAULT;
> > +
> > +   vq->legacy_is_little_endian = !!s.num;
> > +   return 0;
> > +}
> > +
> > +static long vhost_get_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + u32 idx,
> > + void __user *argp)
> > +{
> > +   struct vhost_vring_state s = {
> > +   .index = idx,
> > +   .num = vq->legacy_is_little_endian
> > +   };
> > +
> > +   if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
> > +   return -EPERM;
> > +
> > +   if (copy_to_user(argp, &s, sizeof(s)))
> > +   return -EFAULT;
> > +
> > +   return 0;
> > +}
> > +#else
> > +static long vhost_set_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + void __user *argp)
> > +{
> > +   return 0;
> 
> I'm wondering whether this handler should return an error if the
> feature is not configured for the kernel? How can the userspace caller
> find out whether it has successfully prompted the kernel to handle the
> endianness correctly?
> 

Yes you're right. I think -ENOIOCTLCMD as suggested by Michael is a good
candidate.

Thanks.

> > +}
> > +
> > +static long vhost_get_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + u32 idx,
> > + void __user *argp)
> > +{
> > +   return 0;
> > +}
> > +#endif /* CONFIG_VHOST_SET_ENDIAN_LEGACY */

--
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] irq: Remove unnecessary warning with affinity_hint

[Ingo Molnar]

* Seiichi Ikarashi  wrote:

> Hi,
> 
> On 2015-04-08 15:28, Ingo Molnar wrote:
> > 
> > * Seiichi Ikarashi  wrote:
> > 
> >> Hi,
> >>
> >> If you turn off a PCI device whose driver has set affinity_hint,
> >> you will get warning message which does _not_ explain the reason
> >> why it appeared from the user's point of view.
> >>
> >>   # echo 0 > /sys/bus/pci/slots/65/power
> >>
> >>   Apr 28 20:29:39 localhost kernel: [ cut here ]
> >>   Apr 28 20:29:39 localhost kernel: WARNING: at kernel/irq/manage.c:1002 
> >> __free_irq+0x22d/0x250() (Tainted: P   ---   )
> >>   (snip)
> >>
> >> Users will misunderstand some problem has happened
> >> even though he or she succeeded to turn off the device.
> >> I suppose this warning was originally for a debug purpose
> >> for driver developers and has incidentally been left.
> >>
> >> Just remove the warning is good and enough.
> >>
> >> Signed-off-by: Seiichi Ikarashi 
> >>
> >> --- a/kernel/irq/manage.c
> >> +++ b/kernel/irq/manage.c
> >> @@ -1335,7 +1335,7 @@ static struct irqaction *__free_irq(unsi
> >>  
> >>  #ifdef CONFIG_SMP
> >>/* make sure affinity_hint is cleaned up */
> >> -  if (WARN_ON_ONCE(desc->affinity_hint))
> >> +  if (desc->affinity_hint)
> >>desc->affinity_hint = NULL;
> > 
> > Well, drivers that are using irq_set_affinity_hint() are expected to 
> > call:
> > 
> > irq_set_affinity_hint(irq, NULL);
> > 
> > to clear the affinity mask, before releasing the irq. This warning 
> > flags drivers that forgot to do that and which might thus leak a 
> > dynamically allocated CPU mask (and/or other resources).
> 
> Calling irq_set_affinity_hint(irq, NULL) does not guarantee that the 
> driver does not forget to deallocate a dynamically allocated CPU 
> mask and/or other resources. [...]

I said 'might leak', not 'guaranteed to leak'.

Calling irq_set_affinity_hint(irq, NULL) is the way this kernel API is 
specified to be used. Forgetting to do it is a kernel driver bug and 
triggers a warning message from the kernel's IRQ subsystem.

> [...] But if calling it with NULL 2nd-arg before releasing the irq 
> is a virtual rule of using irq_set_affinity_hint() interface, I 
> understand it.
> 
> > Feel free to turn the warning message into a more informative 
> > WARN() that will blame the driver that triggered it, if the stack 
> > dump into the driver wasn't a clue enough ...
> 
> Still, I do not know leaving the warning message is effective to 
> prevent drivers from potentially leaking resource... considering a 
> kind of cost-effectivenss. Business users (not developers) hate such 
> kind of messages for developers.

it's a warning message pointing out a kernel bug: that 
irq_set_affinity_hint(irq, NULL) was not called properly.

Messages pointing out kernel bugs should be fixed, not hidden.

Thanks,

Ingo
--
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/

[tip:x86/asm] x86/asm/entry/64: Move opportunistic sysret code to syscall code path

[tip-bot for Denys Vlasenko]

Commit-ID:  fffbb5dcfd29f8831e41b4dd2ab938bd36d35283
Gitweb: http://git.kernel.org/tip/fffbb5dcfd29f8831e41b4dd2ab938bd36d35283
Author: Denys Vlasenko 
AuthorDate: Thu, 2 Apr 2015 18:46:59 +0200
Committer:  Ingo Molnar 
CommitDate: Wed, 8 Apr 2015 09:02:12 +0200

x86/asm/entry/64: Move opportunistic sysret code to syscall code path

This change does two things:

Copy-pastes "retint_swapgs:" code into syscall handling code,
the copy is under "syscall_return:" label. The code is unchanged
apart from some label renames.

Removes "opportunistic sysret" code from "retint_swapgs:" code
block, since now it won't be reached by syscall return. This in
fact removes most of the code in question.

   textdata bss dec hex filename
  12530   0   0   1253030f2 entry_64.o.before
  12562   0   0   125623112 entry_64.o

Run-tested.

Acked-and-Tested-by: Borislav Petkov 
Signed-off-by: Denys Vlasenko 
Cc: Alexei Starovoitov 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Steven Rostedt 
Cc: Will Drewry 
Link: 
http://lkml.kernel.org/r/1427993219-7291-1-git-send-email-dvlas...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/entry_64.S | 158 -
 1 file changed, 86 insertions(+), 72 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 65485b3..e4c8103 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -354,8 +354,8 @@ GLOBAL(int_with_check)
movl TI_flags(%rcx),%edx
andl %edi,%edx
jnz   int_careful
-   andl$~TS_COMPAT,TI_status(%rcx)
-   jmp   retint_swapgs
+   andl$~TS_COMPAT,TI_status(%rcx)
+   jmp syscall_return
 
/* Either reschedule or signal or syscall exit tracking needed. */
/* First do a reschedule test. */
@@ -399,9 +399,86 @@ int_restore_rest:
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
jmp int_with_check
+
+syscall_return:
+   /* The IRETQ could re-enable interrupts: */
+   DISABLE_INTERRUPTS(CLBR_ANY)
+   TRACE_IRQS_IRETQ
+
+   /*
+* Try to use SYSRET instead of IRET if we're returning to
+* a completely clean 64-bit userspace context.
+*/
+   movq RCX(%rsp),%rcx
+   cmpq %rcx,RIP(%rsp) /* RCX == RIP */
+   jne opportunistic_sysret_failed
+
+   /*
+* On Intel CPUs, SYSRET with non-canonical RCX/RIP will #GP
+* in kernel space.  This essentially lets the user take over
+* the kernel, since userspace controls RSP.  It's not worth
+* testing for canonicalness exactly -- this check detects any
+* of the 17 high bits set, which is true for non-canonical
+* or kernel addresses.  (This will pessimize vsyscall=native.
+* Big deal.)
+*
+* If virtual addresses ever become wider, this will need
+* to be updated to remain correct on both old and new CPUs.
+*/
+   .ifne __VIRTUAL_MASK_SHIFT - 47
+   .error "virtual address width changed -- SYSRET checks need update"
+   .endif
+   shr $__VIRTUAL_MASK_SHIFT, %rcx
+   jnz opportunistic_sysret_failed
+
+   cmpq $__USER_CS,CS(%rsp)/* CS must match SYSRET */
+   jne opportunistic_sysret_failed
+
+   movq R11(%rsp),%r11
+   cmpq %r11,EFLAGS(%rsp)  /* R11 == RFLAGS */
+   jne opportunistic_sysret_failed
+
+   /*
+* SYSRET can't restore RF.  SYSRET can restore TF, but unlike IRET,
+* restoring TF results in a trap from userspace immediately after
+* SYSRET.  This would cause an infinite loop whenever #DB happens
+* with register state that satisfies the opportunistic SYSRET
+* conditions.  For example, single-stepping this user code:
+*
+*   movq $stuck_here,%rcx
+*   pushfq
+*   popq %r11
+*   stuck_here:
+*
+* would never get past 'stuck_here'.
+*/
+   testq $(X86_EFLAGS_RF|X86_EFLAGS_TF), %r11
+   jnz opportunistic_sysret_failed
+
+   /* nothing to check for RSP */
+
+   cmpq $__USER_DS,SS(%rsp)/* SS must match SYSRET */
+   jne opportunistic_sysret_failed
+
+   /*
+* We win!  This label is here just for ease of understanding
+* perf profiles.  Nothing jumps here.
+*/
+syscall_return_via_sysret:
+   CFI_REMEMBER_STATE
+   /* r11 is already restored (see code above) */
+   RESTORE_C_REGS_EXCEPT_R11
+   movq RSP(%rsp),%rsp
+   USERGS_SYSRET64
+   CFI_RESTORE_STATE
+
+opportunistic_sysret_failed:
+   SWAPGS
+   jmp restore_c_regs_and_iret
CFI_ENDPROC
 END(system_call)
 
+
.macro FORK_LIKE func
 ENTRY(stub_\func)
CFI_STARTPROC
@@ -673,76 +750,8 @@ retint_swapgs: /* return to u

[tip:x86/asm] x86/asm/entry/irq: Simplify interrupt dispatch table (IDT) layout

[tip-bot for Denys Vlasenko]

Commit-ID:  3304c9c37bef30ebd2ef71d986e6568372ce80f8
Gitweb: http://git.kernel.org/tip/3304c9c37bef30ebd2ef71d986e6568372ce80f8
Author: Denys Vlasenko 
AuthorDate: Fri, 3 Apr 2015 21:49:13 +0200
Committer:  Ingo Molnar 
CommitDate: Wed, 8 Apr 2015 09:02:13 +0200

x86/asm/entry/irq: Simplify interrupt dispatch table (IDT) layout

Interrupt entry points are handled with the following code,
each 32-byte code block contains seven entry points:

...
[push][jump 22] // 4 bytes
[push][jump 18] // 4 bytes
[push][jump 14] // 4 bytes
[push][jump 10] // 4 bytes
[push][jump  6] // 4 bytes
[push][jump  2] // 4 bytes
[push][jump common_interrupt][padding] // 8 bytes

[push][jump]
[push][jump]
[push][jump]
[push][jump]
[push][jump]
[push][jump]
[push][jump common_interrupt][padding]

[padding_2]
common_interrupt:

And there is a table which holds pointers to every entry point,
IOW: to every push.

In cold cache, two jumps are still costlier than one, even
though we get the benefit of them residing in the same
cacheline.

This change replaces short jumps with near ones to
'common_interrupt', and pads every push+jump pair to 8 bytes. This
way, each interrupt takes only one jump.

This change replaces ".p2align CONFIG_X86_L1_CACHE_SHIFT" before
dispatch table with ".align 8" - we do not need anything
stronger than that.

The table of entry addresses (the interrupt[] array) is no
longer necessary, the address of entries can be easily
calculated as (irq_entries_start + i*8).

   textdata bss dec hex filename
  12546   0   0   125463102 entry_64.o.before
  11626   0   0   116262d6a entry_64.o

The size decrease is because 1656 bytes of .init.rodata are
gone. That's initdata, though. The resident size does go up a
bit.

Run-tested (32 and 64 bits).

Acked-and-Tested-by: Borislav Petkov 
Signed-off-by: Denys Vlasenko 
Cc: Alexei Starovoitov 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Steven Rostedt 
Cc: Will Drewry 
Link: 
http://lkml.kernel.org/r/1428090553-7283-1-git-send-email-dvlas...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/hw_irq.h |  5 ++---
 arch/x86/kernel/entry_32.S| 41 ++---
 arch/x86/kernel/entry_64.S| 41 ++---
 arch/x86/kernel/irqinit.c |  3 ++-
 arch/x86/lguest/boot.c|  3 ++-
 5 files changed, 26 insertions(+), 67 deletions(-)

diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 9662290..e9571dd 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -181,10 +181,9 @@ extern __visible void 
smp_call_function_single_interrupt(struct pt_regs *);
 extern __visible void smp_invalidate_interrupt(struct pt_regs *);
 #endif
 
-extern void (*__initconst interrupt[FIRST_SYSTEM_VECTOR
-   - FIRST_EXTERNAL_VECTOR])(void);
+extern char irq_entries_start[];
 #ifdef CONFIG_TRACING
-#define trace_interrupt interrupt
+#define trace_irq_entries_start irq_entries_start
 #endif
 
 #define VECTOR_UNDEFINED   (-1)
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index effa279..02bec0f 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -723,43 +723,22 @@ END(sysenter_badsys)
 .endm
 
 /*
- * Build the entry stubs and pointer table with some assembler magic.
- * We pack 7 stubs into a single 32-byte chunk, which will fit in a
- * single cache line on all modern x86 implementations.
+ * Build the entry stubs with some assembler magic.
+ * We pack 1 stub into every 8-byte block.
  */
-.section .init.rodata,"a"
-ENTRY(interrupt)
-.section .entry.text, "ax"
-   .p2align 5
-   .p2align CONFIG_X86_L1_CACHE_SHIFT
+   .align 8
 ENTRY(irq_entries_start)
RING0_INT_FRAME
-vector=FIRST_EXTERNAL_VECTOR
-.rept (FIRST_SYSTEM_VECTOR-FIRST_EXTERNAL_VECTOR+6)/7
-   .balign 32
-  .rept7
-.if vector < FIRST_SYSTEM_VECTOR
-  .if vector <> FIRST_EXTERNAL_VECTOR
+vector=FIRST_EXTERNAL_VECTOR
+.rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR)
+   pushl_cfi $(~vector+0x80)   /* Note: always in signed byte range */
+vector=vector+1
+   jmp common_interrupt
CFI_ADJUST_CFA_OFFSET -4
-  .endif
-1: pushl_cfi $(~vector+0x80)   /* Note: always in signed byte range */
-  .if ((vector-FIRST_EXTERNAL_VECTOR)%7) <> 6
-   jmp 2f
-  .endif
-  .previous
-   .long 1b
-  .section .entry.text, "ax"
-vector=vector+1
-.endif
-  .endr
-2: jmp common_interrupt
-.endr
+   .align  8
+.endr
 END(irq_entri

[tip:x86/asm] x86/asm/entry/64: Add forgotten CFI annotation

[tip-bot for Denys Vlasenko]

Commit-ID:  8b3607b5b8c591d8bf045911cb7c90ecaa6e7b73
Gitweb: http://git.kernel.org/tip/8b3607b5b8c591d8bf045911cb7c90ecaa6e7b73
Author: Denys Vlasenko 
AuthorDate: Tue, 7 Apr 2015 18:42:47 +0200
Committer:  Ingo Molnar 
CommitDate: Wed, 8 Apr 2015 09:18:36 +0200

x86/asm/entry/64: Add forgotten CFI annotation

Signed-off-by: Denys Vlasenko 
Cc: Alexei Starovoitov 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: Will Drewry 
Link: 
http://lkml.kernel.org/r/1428424967-14460-1-git-send-email-dvlas...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/entry_64.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 4ca03c5..3197f41 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -506,6 +506,7 @@ return_from_execve:
 1:
/* must use IRET code path (pt_regs->cs may have changed) */
addq$8, %rsp
+   CFI_ADJUST_CFA_OFFSET -8
ZERO_EXTRA_REGS
movq%rax,RAX(%rsp)
jmp int_ret_from_sys_call
--
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 v6 4/4] clk: dt: Introduce binding for always-on clock support

[Maxime Ripard]

Hi Lee,

On Tue, Apr 07, 2015 at 07:43:59PM +0100, Lee Jones wrote:
> Signed-off-by: Lee Jones 
> ---
>  .../devicetree/bindings/clock/clock-bindings.txt   | 38 
> ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt 
> b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> index 06fc6d5..daf3323 100644
> --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> @@ -44,6 +44,44 @@ For example:
>clocks by index. The names should reflect the clock output signal
>names for the device.
>  
> +clock-always-on:Some hardware contains bunches of clocks which must 
> never be
> + turned off.  If drivers a) fail to obtain a reference to any
> + of these or b) give up a previously obtained reference
> + during suspend, the common clk framework will attempt to
> + disable them and a platform can fail irrecoverably as a
> + result.  Usually the only way to recover from these failures
> + is to reboot.
> +
> + To avoid either of these two scenarios from catastrophically
> + disabling an otherwise perfectly healthy running system,
> + clocks can be identified as always-on using this property
> + from inside a clocksource's node.

Isn't "clocksource" here way too similar to, I don't know, the
clocksource framework? Wouln't clock provider be better?

> +
> + This property is not to be abused.  It is only to be used to
> + protect platforms from being crippled by gated clocks, not
> + as a convenience function to avoid using the framework
> + correctly inside device drivers.

Disregarding what's stated here, I'm pretty sure that this will
actually happen. Where do you place the cursor?

Should we create a new driver for our RAM controller, or do we want to
use clock-always-on?

Do we really want to enforce this if we ever gain a driver that would
actually be able to manage its clock (like do we want the CPU clock to
never *ever* be gated just because we don't have a cpuidle/hotplug
driver yet?)

Have you seen the numerous NAK on such approach Mike did?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH] iwlwifi: Move each system tracepoints to their own header

[Johannes Berg]

On Tue, 2015-04-07 at 12:13 -0400, Steven Rostedt wrote:
> Every tracing file must have its own TRACE_SYSTEM defined.
> The iwlwifi tracepoint header broke this and added in the middle
> of the file:
[...]
> Unfortunately, this broke new code in the ftrace infrastructure.
> Moving each of these TRACE_SYSTEMs into their own trace file with
> just one TRACE_SYSTEM per file fixes the issue.
> 
> Cc: Johannes Berg 
> Signed-off-by: Steven Rostedt 


>  drivers/net/wireless/iwlwifi/iwl-devtrace-data.h   |  79 
>  drivers/net/wireless/iwlwifi/iwl-devtrace-io.h | 155 
>  .../net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h| 200 ++
>  drivers/net/wireless/iwlwifi/iwl-devtrace-msg.h|  97 +
>  drivers/net/wireless/iwlwifi/iwl-devtrace-ucode.h  |  81 
>  drivers/net/wireless/iwlwifi/iwl-devtrace.h| 438 
> +
>  6 files changed, 618 insertions(+), 432 deletions(-)
>  create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-data.h
>  create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-io.h
>  create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-iwlwifi.h
>  create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-msg.h
>  create mode 100644 drivers/net/wireless/iwlwifi/iwl-devtrace-ucode.h

Looks good to me.

Reviewed-by: Johannes Berg 

johannes

--
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/

[tip:x86/asm] x86, selftests: Add sigreturn selftest

[tip-bot for Andy Lutomirski]

Commit-ID:  3f705dfdf85a6416f5f12e52b7610144a99cbedc
Gitweb: http://git.kernel.org/tip/3f705dfdf85a6416f5f12e52b7610144a99cbedc
Author: Andy Lutomirski 
AuthorDate: Mon, 6 Apr 2015 23:11:06 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 8 Apr 2015 08:22:02 +0200

x86, selftests: Add sigreturn selftest

This is my sigreturn test, added mostly unchanged from its old
home. It exercises the sigreturn(2) syscall, specifically
focusing on its interactions with various IRET corner cases.

It tests for correct behavior in several areas that were
historically dangerously buggy. For example, it exercises espfix
on kernels of both bitnesses under various conditions, and it
contains testcases for several now-fixed bugs in IRET error
handling.

If you run it on older kernels without the fixes, your system will
crash. It probably won't eat your data in the process.

There is no released kernel on which the sigreturn_64 test will
pass, but it passes on tip:x86/asm.

I plan to switch to lib.mk for Linux 4.2.

I'm not using the ksft_ helpers at all yet.  I can do that later.

Signed-off-by: Andy Lutomirski 
Acked-by: Shuah Khan 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Michael Ellerman 
Cc: Shuah Khan 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/89d10b76b92c7202d8123654dc8d36701c017b3d.1428386971.git.l...@kernel.org
[ Fixed empty format string GCC build warning in trivial_32bit_program.c ]
Signed-off-by: Ingo Molnar 
---
 tools/testing/selftests/Makefile   |   1 +
 tools/testing/selftests/x86/.gitignore |   2 +
 tools/testing/selftests/x86/Makefile   |  48 ++
 tools/testing/selftests/x86/run_x86_tests.sh   |  11 +
 tools/testing/selftests/x86/sigreturn.c| 684 +
 .../testing/selftests/x86/trivial_32bit_program.c  |  14 +
 6 files changed, 760 insertions(+)

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 4e51122..2ad56d4 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -17,6 +17,7 @@ TARGETS += sysctl
 TARGETS += timers
 TARGETS += user
 TARGETS += vm
+TARGETS += x86
 #Please keep the TARGETS list alphabetically sorted
 
 TARGETS_HOTPLUG = cpu-hotplug
diff --git a/tools/testing/selftests/x86/.gitignore 
b/tools/testing/selftests/x86/.gitignore
new file mode 100644
index 000..15034fe
--- /dev/null
+++ b/tools/testing/selftests/x86/.gitignore
@@ -0,0 +1,2 @@
+*_32
+*_64
diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
new file mode 100644
index 000..f0a7918
--- /dev/null
+++ b/tools/testing/selftests/x86/Makefile
@@ -0,0 +1,48 @@
+.PHONY: all all_32 all_64 check_build32 clean run_tests
+
+TARGETS_C_BOTHBITS := sigreturn
+
+BINARIES_32 := $(TARGETS_C_BOTHBITS:%=%_32)
+BINARIES_64 := $(TARGETS_C_BOTHBITS:%=%_64)
+
+CFLAGS := -O2 -g -std=gnu99 -pthread -Wall
+
+UNAME_P := $(shell uname -p)
+
+# Always build 32-bit tests
+all: all_32
+
+# If we're on a 64-bit host, build 64-bit tests as well
+ifeq ($(shell uname -p),x86_64)
+all: all_64
+endif
+
+all_32: check_build32 $(BINARIES_32)
+
+all_64: $(BINARIES_64)
+
+clean:
+   $(RM) $(BINARIES_32) $(BINARIES_64)
+
+run_tests:
+   ./run_x86_tests.sh
+
+$(TARGETS_C_BOTHBITS:%=%_32): %_32: %.c
+   $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
+
+$(TARGETS_C_BOTHBITS:%=%_64): %_64: %.c
+   $(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
+
+check_build32:
+   @if ! $(CC) -m32 -o /dev/null trivial_32bit_program.c; then \
+ echo "Warning: you seem to have a broken 32-bit build" 2>&1;  \
+ echo "environment.  If you are using a Debian-like";  \
+ echo " distribution, try:";   \
+ echo "";  \
+ echo "  apt-get install gcc-multilib libc6-i386 libc6-dev-i386"; \
+ echo "";  \
+ echo "If you are using a Fedora-like distribution, try:"; \
+ echo "";  \
+ echo "  yum install glibc-devel.*i686";   \
+ exit 1;   \
+   fi
diff --git a/tools/testing/selftests/x86/run_x86_tests.sh 
b/tools/testing/selftests/x86/run_x86_tests.sh
new file mode 100644
index 000..3d3ec65
--- /dev/null
+++ b/tools/testing/selftests/x86/run_x86_tests.sh
@@ -0,0 +1,11 @@
+#!/bin/bash
+
+# This is deliberately minimal.  IMO kselftests should provide a standard
+# script here.
+./sigreturn_32 || exit 1
+
+if [[ "$uname -p" -eq "x86_64" ]]; then
+./sigreturn_64 || exit 1
+fi
+
+exit 0
diff --git a/tools/testing/selftests/x86/sigreturn.c 
b/tools/testing/selftests/x86/sigreturn.c
new file mode 10

[PATCH, resend] kerneldoc: Convert error messages to GNU error message format

[Bart Van Assche]

Editors like emacs and vi recognize a number of error message
formats. The format used by the kerneldoc tool is not recognized
by emacs. Change the kerneldoc error message format to the GNU
style such that the emacs prev-error and next-error commands can
be used to navigate through kerneldoc error messages. For more
information about the GNU error message format, see also
https://www.gnu.org/prep/standards/html_node/Errors.html.

This patch has been generated via the following sed command:

sed -i.orig 's/Error(\${file}:\$.):/\${file}:\$.: 
error:/g;s/Warning(\${file}:\$.):/\${file}:\$.: 
warning:/g;s/Warning(\${file}):/\${file}:1: 
warning:/g;s/Info(\${file}:\$.):/\${file}:\$.: info:/g' scripts/kernel-doc

Signed-off-by: Bart Van Assche 
Cc: Johannes Berg 
---
 scripts/kernel-doc | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 9922e66..286e90d 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -423,7 +423,7 @@ sub dump_section {
 } else {
 #  print STDERR "other section '$name' = '$contents'\n";
if (defined($sections{$name}) && ($sections{$name} ne "")) {
-   print STDERR "Error(${file}:$.): duplicate section name 
'$name'\n";
+   print STDERR "${file}:$.: error: duplicate section name 
'$name'\n";
++$errors;
}
$sections{$name} = $contents;
@@ -1772,7 +1772,7 @@ sub dump_struct($$) {
   });
 }
 else {
-   print STDERR "Error(${file}:$.): Cannot parse struct or union!\n";
+   print STDERR "${file}:$.: error: Cannot parse struct or union!\n";
++$errors;
 }
 }
@@ -1793,7 +1793,7 @@ sub dump_enum($$) {
push @parameterlist, $arg;
if (!$parameterdescs{$arg}) {
$parameterdescs{$arg} = $undescribed;
-   print STDERR "Warning(${file}:$.): Enum value '$arg' ".
+   print STDERR "${file}:$.: warning: Enum value '$arg' ".
"not described in enum '$declaration_name'\n";
}
 
@@ -1811,7 +1811,7 @@ sub dump_enum($$) {
   });
 }
 else {
-   print STDERR "Error(${file}:$.): Cannot parse enum!\n";
+   print STDERR "${file}:$.: error: Cannot parse enum!\n";
++$errors;
 }
 }
@@ -1839,7 +1839,7 @@ sub dump_typedef($$) {
   });
 }
 else {
-   print STDERR "Error(${file}:$.): Cannot parse typedef!\n";
+   print STDERR "${file}:$.: error: Cannot parse typedef!\n";
++$errors;
 }
 }
@@ -1971,11 +1971,11 @@ sub push_parameter($$$) {
$parameterdescs{$param_name} = $undescribed;
 
if (($type eq 'function') || ($type eq 'enum')) {
-   print STDERR "Warning(${file}:$.): Function parameter ".
+   print STDERR "${file}:$.: warning: Function parameter ".
"or member '$param' not " .
"described in '$declaration_name'\n";
}
-   print STDERR "Warning(${file}:$.):" .
+   print STDERR "${file}:$.: warning:" .
 " No description found for parameter '$param'\n";
++$warnings;
}
@@ -2026,14 +2026,14 @@ sub check_sections($$) {
}
if ($err) {
if ($decl_type eq "function") {
-   print STDERR "Warning(${file}:$.): " .
+   print STDERR "${file}:$.: warning: " .
"Excess function parameter " .
"'$sects[$sx]' " .
"description in '$decl_name'\n";
++$warnings;
} else {
if ($nested !~ m/\Q$sects[$sx]\E/) {
-   print STDERR "Warning(${file}:$.): " .
+   print STDERR "${file}:$.: warning: " .
"Excess struct/union/enum/typedef 
member " .
"'$sects[$sx]' " .
"description in '$decl_name'\n";
@@ -2059,7 +2059,7 @@ sub check_return_section {
 
 if (!defined($sections{$section_return}) ||
 $sections{$section_return} eq "") {
-print STDERR "Warning(${file}:$.): " .
+print STDERR "${file}:$.: warning: " .
 "No description found for return value of " .
 "'$declaration_name'\n";
 ++$warnings;
@@ -2138,7 +2138,7 @@ sub dump_function($$) {
 
create_parameterlist($args, ',', $file);
 } else {
-   print STDERR "Warning(${file}:$.): cannot understand function 
prototype: '$prototype'\n";
+   print STDERR "${file}:$.: warning: cannot understand function 
protot

Re: [PATCH 1/6] ARM: dts :exynos5422-odroidxu3 Add pwm-fan node to the Odroid-XU3 board.

[Lukasz Majewski]

Hi Anand,

> Add pwm-fan node to the OdroidXU3 board.
> 
> Tested on OdroidXU3 board.
> 
> Signed-off-by: Anand Moon 
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index a519c86..eaec006
> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -278,6 +278,15 @@
>   rtc@101E {
>   status = "okay";
>   };
> +
> + fan0: pwm-fan {
> + compatible = "pwm-fan";
> + pwms = <&pwm 0 20972 0>;
> + cooling-min-state = <0>;
> + cooling-max-state = <3>;
> + #cooling-cells = <2>;
> + cooling-levels = <0 90 130 170 230>;
> + };
>  };
>  
>  &hdmi {
> @@ -369,3 +378,10 @@
>   shunt-resistor = <1>;
>   };
>  };
> +
> +&pwm {
> + pinctrl-0 = <&pwm0_out>;
> + pinctrl-names = "default";
> + samsung,pwm-outputs = <0>;
> + status = "okay";
> +};

Acked-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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/6] ARM: dts exynos5420 update the cooling cells for core cpu0

[Lukasz Majewski]

Hi Anand,

> update the cooling level for cpu0 to avoid following message.
> 
> root@odroidxu3:~# dmesg | grep ther
> [0.241511] /thermal-zones/cpu-thermal/cooling-maps/map0:
>could not get #cooling-cells for /cpus/cpu@0
> 
> Signed-off-by: Anand Moon 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi index c0e98cf..6b49f3c 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -61,6 +61,10 @@
>   reg = <0x0>;
>   clock-frequency = <18>;
>   cci-control-port = <&cci_control1>;
> +
> + cooling-min-level = <10>;
> + cooling-max-level = <7>;
> + #cooling-cells = <2>; /* min followed by max
> */ };
>  
>   cpu1: cpu@1 {

Acked-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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 1/4] drm/layerscape: Add Freescale DCU DRM driver

[Stefan Agner]

On 2015-04-08 09:17, jianwei.w...@freescale.com wrote:
> Hi Stefan,
> 
>> -Original Message-
>> From: Stefan Agner [mailto:ste...@agner.ch]
>> Sent: Tuesday, April 07, 2015 8:12 PM
>> To: Wang Jianwei-B52261
>> Cc: Wood Scott-B07421; airl...@linux.ie; dri-de...@lists.freedesktop.org;
>> devicet...@vger.kernel.org; Xiubo Li; Wang Huan-B18965; linux-
>> ker...@vger.kernel.org; Jin Zhengxiong-R64188; linux-arm-
>> ker...@lists.infradead.org
>> Subject: RE: [PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM driver
>>
>> Hi Jianwei,
>>
>> On 2015-04-07 08:44, jianwei.w...@freescale.com wrote:
>> > Hi Stefan,
>> >
>> > Thank you for your review and testing on Vybrid F610 device. This driver
>> > just implement the basic functions and it only support the exported
>> > framebuffer access. Some DRM interfaces are not implemented now. So your
>> > test result is normal. I will implement these interfaces with patches
>> soon
>> > afterwards. I don't plan to add new features for the initial version
>> driver,
>> > otherwise it will be a long term for this version.
>> >
>> > I tested on ls1021a using TFT panel, there are no flickers on the screen
>> > when inserting a USB HID device. I will do more test if time permits.
>> >
>> > By the way, could please give me some guidance on how X-Server use DRM
>> > Interface directly? Do you have some papers or webpage about this?
>>
>> I'm using the modesetting X.org driver. Lots of distributions ship that
>> driver as a package (e.g. xserver-xorg-video-modesetting in Debian, or
>> xf86-video-modesetting in OpenEmbedded). Since 1.17 this driver has even
>> been included into the main source tree of Xorg X-Server
>> (http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesett
>> ing)
>>
>> This driver is using KMS/DRM interface and should work well for
>> un-accelerated graphic devices. This is a a much nicer way to use X.org
>> on top of a DRM driver, since it avoids going through the legacy fbdev
>> interface. The man page shows how to use it:
>> http://linux.die.net/man/4/modesetting
>>
>> So, when the driver is installed, it is just choosing that driver in
>> xorg.conf:
>>
>> Section "Device"
>> Identifier  "dcu"
>> Driver  "modesetting"
>> EndSection
>>
> 
> Thank you for your guidance.
> 
>> Some more comments below...
>>
>> >
>> > My reply below...
>> >
>> >>
>> >> Hi Jianwei,
>> >>
>> >> The driver worked on a Vybrid VF610 device using the exported
>> >> framebuffer. However, when using X-Server through the DRM interface
>> >> directly (by using the modesetting driver) I get just a black screen so
>> >> far, still investigating the reason. What user-space interfaces did you
>> >> test?
>> >>
>> >> When using the FB device and insert a USB HID device, I get some
>> >> flickers on the screen. I didn't had those on the dcufb driver, did you
>> >> notice something like this too? Probably related to the resolution, I'm
>> >> using VGA resolution.
>> >>
>> >> Some comments below.
>> >>
>> >>
>> >> On 2015-03-26 06:37, Jianwei Wang wrote:
>> >> > This patch add support for Two Dimensional Animation and Compositing
>> >> > Engine (2D-ACE) on the Freescale SoCs.
>> >> >
>> >> > 2D-ACE is a Freescale display controller. 2D-ACE describes
>> >> > the functionality of the module extremely well its name is a value
>> >> > that cannot be used as a token in programming languages.
>> >> > Instead the valid token "DCU" is used to tag the register names and
>> >> > function names.
>> >> >
>> >> > The Display Controller Unit (DCU) module is a system master that
>> >> > fetches graphics stored in internal or external memory and displays
>> >> > them on a TFT LCD panel. A wide range of panel sizes is supported
>> >> > and the timing of the interface signals is highly configurable.
>> >> > Graphics are read directly from memory and then blended in real-time,
>> >> > which allows for dynamic content creation with minimal CPU
>> >> > intervention.
>> >> >
>> >> > The features:
>> >> > (1) Full RGB888 output to TFT LCD panel.
>> >> > (2) For the current LCD panel, WQVGA "480x272" is supported.
>> >> > (3) Blending of each pixel using up to 4 source layers
>> >> > dependent on size of panel.
>> >>
>> >> modetest only shows one layer currently...
>> >
>> > Yes, only one plane and one framebuffer were created now, others
>> > maybe create as user requirement or create all when initializing,
>> > I'm not sure now. This describe the hardware feature
>> >
>> >>
>> >> > (4) Each graphic layer can be placed with one pixel resolution
>> >> > in either axis.
>> >> > (5) Each graphic layer support RGB565 and RGB888 direct colors
>> >> > without alpha channel
>> >> > and BGRA direct colors with an alpha channel.
>> >>
>> >> The array fsl_dcu_drm_plane_formats below shows more formats, does this
>> >> commit log needs updating?
>> >>
>> >
>> > I agree with your suggestion, I will update this commit log
>> >
>> >> > (6) Each graphic layer support alpha ble

Re: [PATCH] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in of parsing

[Benjamin Herrenschmidt]

On Tue, 2015-04-07 at 22:39 -0700, Yinghai Lu wrote:
> On Tue, Apr 7, 2015 at 8:49 PM, Benjamin Herrenschmidt
>  wrote:
> > On Tue, 2015-04-07 at 17:24 -0700, Yinghai Lu wrote:
> >> For device resource PREF bit setting under bridge 64-bit pref resource,
> >> we need to make sure only set PREF for 64bit resource, so set 
> >> IORESOUCE_MEM_64
> >> for 64bit resource during of device resource flags parsing.
> >
> >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
> >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
> >
> > These patches (from the above BZ) aren't right for one thing: You
> > shouldn't set the IORESOURCE_PREFETCH in the resource itself. This
> > *will* break stuff.
> >
> > You can put the resource in a prefetchable region indeed, if you
> > are on a PCIe-only path (though we should have some arch flag
> > to check that the host bridge indeed doesn't do any prefetch,
> > on powerpc we are good there).
> 
> The patch is at:
> 
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=for-linus&id=1a3ec5e7b00dcd9cac24efe3d65bfccf82597ce5
> 
> and we limit to set pref bit for pcie end devices mmio 64bit resource.

This is still completely wrong. Please revert.

> >
> > But you can't set the "prefetch" bit on the resource because that would
> > be losing the indication that this resource has side effects. This bit
> > is used in some cases to enable store gathering when mmap'ing via sysfs
> > and can be used for similar uses by drivers.
> 
> Any pointer for that?
>
> >
> > It's one thing to say "you can put non-prefetch BARs in prefetch windows
> > on that path", it's another one to completely make the BAR looks like
> > it's prefetchable when it's not.
> 
> Too hard for me to tell the difference.

Fix it. Add a new bit if necessary "CAN_BE_IN_PREFETCH" or whatever but
you just cannot randomly fuck around with the flag like that.

You are basically dropping the information that the BAR has side effects
completely. This is WRONG.

The fact that you can put a non-prefetchable BAR in a prefetchable
window doesn't make the BAR itself prefetchable. Your patch makes it so.

That means that anything that rely on the BAR flag to establish
prefetchable or write-combining mappings will be fucked. Drivers might
test that, arch code will, powerpc sysfs mmap will (see our
implementation of __pci_mmap_set_pgprot), and quite possibly others
architectures or drivers doing the same thing.

This is utterly WRONG.

Use a different flag to indicate the BAR policy or temporarily tweak a
local copy of the resource flag during BAR assignment or whatever you
prefer to fix the original problem but do *not* change the Linux overall
view of that BAR to lie about prefetchability.

Bjorn, please revert this ASAP.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0

[Lukasz Majewski]

Hi Anand,

> Move the registration of thermal sensors for tmu_cpu0 from
> exynos5420.dtsi to exynos5-cpu-thermal.dtsi, to avoid duplicate
> registration of the sensors.
> 
> Tested on OdroidXU3 board.
> 
> Signed-off-by: Anand Moon 
> ---
>  arch/arm/boot/dts/exynos5-cpu-thermal.dtsi | 58
> ++
> arch/arm/boot/dts/exynos5420.dtsi  |  4 ---
> arch/arm/boot/dts/exynos5422-odroidxu3.dts |  1 + 3 files changed, 59
> insertions(+), 4 deletions(-) create mode 100644
> arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> 
> diff --git a/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi new file mode 100644
> index 000..8fede70
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> @@ -0,0 +1,58 @@
> +/*
> + * Device tree sources for Exynos5 thermal zone
> + *
> + * Copyright (c) 2014 Lukasz Majewski 

 Could you update this
line :-). I'm just reviewer here :-)

> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include 
> +
> +/ {
> + thermal-zones {
> + cpu0_thermal: cpu0-thermal {
> + thermal-sensors = <&tmu_cpu0>;
> + polling-delay-passive = <0>;
> + polling-delay = <0>;
> + trips {
> + cpu_alert0: cpu-alert-0 {
> + temperature = <48000>; /* ms
> */
> + hysteresis = <3000>; /* ms */
^
We already have
"millicelsius"
instead od ms
> + type = "active";
> + };
> + cpu_alert1: cpu-alert-1 {
> + temperature = <53000>; /* ms
> */
> + hysteresis = <3000>; /* ms */
> + type = "active";
> + };
> + cpu_alert2: cpu-alert-2 {
> + temperature = <59000>; /* ms
> */
> + hysteresis = <3000>; /* ms */
> + type = "active";
> + };
> + cpu_crit0: cpu-crit-0 {
> + temperature = <75000>; /* ms
> */
> + hysteresis = <0>; /* ms */
> + type = "critical";

Is there any special reasons why we need special values
for cpu0_thermal sensor at XU3? Is something wrong with
default values defined at exynos4-cpu-thermal.dtsi?

If this is Odroid XU3 specific, then IMHO it should be
added to exynos5422-odroidxu3.dts

> + };
> + };
> + cooling-maps {
> + map0 {
> +  trip = <&cpu_alert0>;
> +  cooling-device = <&fan0 0 1>;
> + };
> + map1 {
> +  trip = <&cpu_alert1>;
> +  cooling-device = <&fan0 1 2>;
> + };
> + map2 {
> +  trip = <&cpu_alert2>;
> +  cooling-device = <&fan0 2 3>;
> + };
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi index 6b49f3c..eb0f16c 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -827,10 +827,6 @@
>   };
>  
>   thermal-zones {
> - cpu0_thermal: cpu0-thermal {
> - thermal-sensors = <&tmu_cpu0>;
> - #include "exynos5420-trip-points.dtsi"
^^ [1]

> - };
>   cpu1_thermal: cpu1-thermal {
>  thermal-sensors = <&tmu_cpu1>;
>  #include "exynos5420-trip-points.dtsi"
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index eaec006..c8b3e3e
> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -12,6 +12,7 @@
>  
>  /dts-v1/;
>  #include "ex

Re: [PATCH v3 0/9] Add sd/emmc support for stih407 family silicon

[Ulf Hansson]

On 30 March 2015 at 16:39, Peter Griffin  wrote:
> Hi,
>
> This series adds sd/emmc support to the sdhci-st.c driver for stih407
> family silicon. The changes mainly involve configuring some extra glue
> registers in the flashSS which configure the Arasan controller.
>
> This series also adds support for UHS modes for eMMC. To allow
> UHS HS200/SD104 modes to function correctly, due to the
> tight timing constriants, support for delay management is also added.
> Two types of delay management are supported, static delay management and
> dynamic delay management, this delay management is only available
> on eMMC pads on stih410 and later silicon.
>
> This series has been tested with stih410-b2120 revd on eMMC and sd, at
> various clock speeds. As part of this testing a bug was also found in the
> upstream flexgen clock set_rate implementation (now fixed upstream).
>
> max-frequency = 200Mhz
> /dev/mmcblk0p1:
>  Timing buffered disk reads: 270 MB in  3.02 seconds =  89.54 MB/sec
>
> max-frequency = 100Mhz
> root@debian-armhf:~# hdparm -t /dev/mmcblk0p1
> /dev/mmcblk0p1:
>  Timing buffered disk reads: 210 MB in  3.00 seconds =  70.00 MB/sec
>
> max-frequency = 50Mhz
> root@debian-armhf:~# hdparm -t /dev/mmcblk0p1
> /dev/mmcblk0p1:
>  Timing buffered disk reads: 118 MB in  3.00 seconds =  39.28 MB/sec
>
> It has also been tested on stih416-b2020 to ensure we have caused no
> regressions. Finally the dt documentation has been updated to reflect
> the changes in the driver code. Intrestingly it seems we are the first
> upstream platform to be using some of the uhs bindings such as
> sd-uhs-sdr104.
>
> Changes since v2:
>  - Some whitespace fixups (Max)
>  - if (!ioaddr) suggestion (Max)
>  - Add stih418-b2199 suport (Max)
>  - Stih410 to STiH410 fixes (Max)
>  - rebased on v4.0-rc6 (Pete)
>
> Changes since v1:
>  - Partition the changes into smaller patches to aid review process (Ulf)
>
> regards,
>
> Peter.
>
> Peter Griffin (9):
>   mmc: sdhci-st: Add macros for register offsets and bitfields for mmcss
> glue regs
>   mmc: sdhci-st: Add support for de-asserting reset signal and top regs
> resource
>   mmc: sdhci-st: Add delay management functions for top registers
> (eMMC).
>   mmc: sdhci-st: Add st_mmcss_cconfig function to configure mmcss glue
> registers.
>   mmc: sdhci-st: Add sdhci_st_set_uhs_signaling function.
>   mmc: sdhci-st: Update the quirks for this controller.
>   mmc: sdhci-st: Update ST SDHCI binding documentation.
>   ARM: STi: DT: STiH407: Add dt nodes for sdhci and emmc.
>   ARM: STi: DT: STiH418: Add dt nodes for sdhci and emmc.
>
>  Documentation/devicetree/bindings/mmc/sdhci-st.txt | 100 +-
>  arch/arm/boot/dts/stih407-family.dtsi  |  30 ++
>  arch/arm/boot/dts/stih410-b2120.dts|  10 +
>  arch/arm/boot/dts/stih418-b2199.dts|  12 +
>  arch/arm/boot/dts/stihxxx-b2120.dtsi   |   8 +
>  drivers/mmc/host/sdhci-st.c| 346 
> -
>  6 files changed, 492 insertions(+), 14 deletions(-)
>

Hi Peter,

I was about to apply patches 1->7. Patch2, I can't apply, it needs a rebase.
While doing that, please also fix the checkpatch warning for patch5.

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] ARM: dts: OdroidXU3: Enable TMU at Exynos5422 base.

[Lukasz Majewski]

Hi Anand,

> This commit enables TMU IP block on the Exynos5422 OdroidXU3
> device.
> 
> Tested on OdroidXU3 board.
> 
> Signed-off-by: Anand Moon 
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 25
> + 1 file changed, 25 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index c8b3e3e..e1635b5
> 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -288,6 +288,31 @@
>   #cooling-cells = <2>;
>   cooling-levels = <0 90 130 170 230>;
>   };
> +
> + tmu@1006 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu@10064000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu@10068000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu@1006c000 {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
> +
> + tmu@100a {
> + vtmu-supply = <&ldo10_reg>;
> + status = "okay";
> + };
>  };
>  
>  &hdmi {

This seems correct. However please consider my comment to the previous
patch.

Acked-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] drm:msm: Initial Add Writeback Support

[Daniel Vetter]

On Tue, Apr 07, 2015 at 03:55:45PM -, jil...@codeaurora.org wrote:
> > On Thu, Apr 02, 2015 at 10:29:52AM -0400, Rob Clark wrote:
> >> So, from a quick look, it seems like there is a lot of potential to
> >> split the v4l part out into some drm helpers.. it looks pretty
> >> generic(ish), or at least it could be with some strategically placed
> >> vfuncs in drm_v4l2_helper_funcs.
> >>
> >> I do think we need to figure out the auth/security situation.  We
> >> probably don't want to let arbitrary processes open a v4l device and
> >> snoop on the screen contents.  We perhaps could re-use the dri2 drm
> >> auth stuff (v4l2_drm_get_magic ioctl?).  Or, well, it would be nice if
> >> the wb device could be made to not exist in /dev at all, and
> >> pre-open'd fd returned from an ioctl on the drm device, but not really
> >> sure if that is possible (or too weird).  Once the compositor process
> >> has the v4l device open and authenticated somehow, I expect it would
> >> use fd passing to pass the fd off to a trusted helper process.
> >
> > Please don't resurrect the magic stuff ;-)
> >
> > Anyway I discussed this a bit with Laurent and we figured the best way to
> > wire up writeback support is by using drm framebuffers. Then you can use
> > atomic flips to create a new snapshot. Of course that won't work with hw
> > where writeback is continuous, there v4l is a much better fit. And we also
> > have hardware where some v4l pipeline could directly feed into a drm
> > output pipeline, so we need a generic way to connect v4l and drm anyway.
> > For that I think we should add a new flag to addfb2 (or a new addfbv4l)
> > which creates a magic framebuffer from a v4l input/output. Some values
> > like stride don't make sense in such a virtual framebuffer, but pixel
> > format and size are all needed.
> >
> > This way we don't need parallel abis for single-shot writeback directly
> > into framebuffers and for continuous writeback through v4l, we can reuse
> > the same drm framebuffer ones. And this also solves the security issues
> > since no one can start writeback without the drm device owner's consent,
> > so no need to reinvent anything there. And with atomic we already have
> > almost everything there: For the writeback framebuffer we only need a new
> > "WRITEBACK" property (which takes an fb id) and the small extension to
> > create v4l-backed framebuffers.
> >
> > Cheers, Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
> Hi Daniel,
> 
> 1. This change is to implement a continuous writeback.
> 2. As you said, we need "a generic way to connect v4l and drm".
> Especially how to share the buffer information between v4l and drm for
> writeback output.
> 
> Below are just some details of this change:
> 
> In current implementation, I expect the output buffer is dma buffer
> which could be from GEM object (drm) or from video encoder (V4l). Once
> the buffer is queued into V4l driver, it will be converted into a GEM
> object and then pass it to drm as writeback output buffer. Once the
> buffer is captured, it will notify V4l driver to let user dequeue
> buffer.
> 
> Drm will notice there is a Virtual Connector (maybe a new type WRITEBACK
> can be added), but it will only be "connected" until V4l
> starts streaming.

Yes we definitely should add a new connector type WRITEBACK. And just the
connector kinda works for your hw design where writeback works like a
separate encoder. But there's also hw out there where any crtc can be
written back, and for those cases we need explicit properties. Then
there's also the one-shot vs. continuous issues.

Given all that I still think you want an explicit drm framebuffer to
connect the kms and the v4l side of things. That would also help a bit
with making it clear which v4l connects to which drm device.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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] irq: Remove unnecessary warning with affinity_hint

[Seiichi Ikarashi]

On 2015-04-08 16:39, Ingo Molnar wrote:
> 
> * Seiichi Ikarashi  wrote:
> 
>> Hi,
>>
>> On 2015-04-08 15:28, Ingo Molnar wrote:
>>>
>>> * Seiichi Ikarashi  wrote:
>>>
 Hi,

 If you turn off a PCI device whose driver has set affinity_hint,
 you will get warning message which does _not_ explain the reason
 why it appeared from the user's point of view.

   # echo 0 > /sys/bus/pci/slots/65/power

   Apr 28 20:29:39 localhost kernel: [ cut here ]
   Apr 28 20:29:39 localhost kernel: WARNING: at kernel/irq/manage.c:1002 
 __free_irq+0x22d/0x250() (Tainted: P   ---   )
   (snip)

 Users will misunderstand some problem has happened
 even though he or she succeeded to turn off the device.
 I suppose this warning was originally for a debug purpose
 for driver developers and has incidentally been left.

 Just remove the warning is good and enough.

 Signed-off-by: Seiichi Ikarashi 

 --- a/kernel/irq/manage.c
 +++ b/kernel/irq/manage.c
 @@ -1335,7 +1335,7 @@ static struct irqaction *__free_irq(unsi
  
  #ifdef CONFIG_SMP
/* make sure affinity_hint is cleaned up */
 -  if (WARN_ON_ONCE(desc->affinity_hint))
 +  if (desc->affinity_hint)
desc->affinity_hint = NULL;
>>>
>>> Well, drivers that are using irq_set_affinity_hint() are expected to 
>>> call:
>>>
>>> irq_set_affinity_hint(irq, NULL);
>>>
>>> to clear the affinity mask, before releasing the irq. This warning 
>>> flags drivers that forgot to do that and which might thus leak a 
>>> dynamically allocated CPU mask (and/or other resources).
>>
>> Calling irq_set_affinity_hint(irq, NULL) does not guarantee that the 
>> driver does not forget to deallocate a dynamically allocated CPU 
>> mask and/or other resources. [...]
> 
> I said 'might leak', not 'guaranteed to leak'.

Yes, I know.
I wrote it because I was not sure about the primary purpose of
showing the warning message.

> 
> Calling irq_set_affinity_hint(irq, NULL) is the way this kernel API is 
> specified to be used. Forgetting to do it is a kernel driver bug and 
> triggers a warning message from the kernel's IRQ subsystem.
> 
>> [...] But if calling it with NULL 2nd-arg before releasing the irq 
>> is a virtual rule of using irq_set_affinity_hint() interface, I 
>> understand it.
>>
>>> Feel free to turn the warning message into a more informative 
>>> WARN() that will blame the driver that triggered it, if the stack 
>>> dump into the driver wasn't a clue enough ...
>>
>> Still, I do not know leaving the warning message is effective to 
>> prevent drivers from potentially leaking resource... considering a 
>> kind of cost-effectivenss. Business users (not developers) hate such 
>> kind of messages for developers.
> 
> it's a warning message pointing out a kernel bug: that 
> irq_set_affinity_hint(irq, NULL) was not called properly.
> 
> Messages pointing out kernel bugs should be fixed, not hidden.

OK, the conclusion is that a kernel bug on using irq_set_affinity_hint().

Thanks, Ingo.

Seiichi


--
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/17] soc: tegra: pmc: Add generic PM domain support

[Thierry Reding]

On Mon, Apr 06, 2015 at 03:37:37PM -0700, Kevin Hilman wrote:
> Hi Vince,
> 
> Vince Hsu  writes:
[...]
> > +static int tegra_pmc_powergate_power_off(struct generic_pm_domain *domain)
> > +{
> > +   struct tegra_powergate *powergate = to_powergate(domain);
> > +   struct tegra_pmc *pmc = powergate->pmc;
> > +   int err;
> > +
> > +   dev_dbg(pmc->dev, "> %s(domain=%p)\n", __func__, domain);
> > +   dev_dbg(pmc->dev, "  name: %s\n", domain->name);
> > +
> > +   /* never turn off these partitions */
> > +   switch (powergate->id) {
> > +   case TEGRA_POWERGATE_CPU:
> > +   case TEGRA_POWERGATE_CPU1:
> > +   case TEGRA_POWERGATE_CPU2:
> > +   case TEGRA_POWERGATE_CPU3:
> > +   case TEGRA_POWERGATE_CPU0:
> > +   case TEGRA_POWERGATE_C0NC:
> > +   case TEGRA_POWERGATE_IRAM:
> > +   dev_dbg(pmc->dev, "not disabling always-on partition %s\n",
> > +   domain->name);
> > +   err = -EINVAL;
> > +   goto out;
> > +   }
> 
> You're re-inventing the per-device QoS flag: PM_QOS_FLAG_NO_POWER_OFF
> which could be used here to prevent ->power_off from ever being called.
> 
> Alternately, if this really a static configuraion, why even register the
> ->power_off hook for these domains in the first place?

This isn't really a static configuration. The problem here is that there
is code elsewhere to deal with these domains. The CPU power partitions
for example are dealt with in the cpuidle code (or PSCI firmware). What
complicates this even further is that we have an existing custom API for
enabling/disabling power partitions (cpuidle uses that API).

Although, thinking about it some more, it seems that for the purposes of
power domains perhaps we should just not consider these power partitions
at all (i.e. not even register them).

[...]
> > @@ -831,12 +1405,19 @@ static int tegra_pmc_probe(struct platform_device 
> > *pdev)
> >  
> > tegra_pmc_init_tsense_reset(pmc);
> >  
> > +   if (IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS)) {
> > +   err = tegra_powergate_init(pmc);
> > +   if (err < 0)
> > +   return err;
> > +   }
> 
> On many SoCs there's some special handling for the !CONFIG_PM case here
> such that all the PM domains are enabled by default in case they are not
> enabled by the bootloader.

Yeah, I think we'll need something like that for backwards-compatibility
with the old API. Converting to power domains should be done in the same
step as stubbing out the old API, and then to prevent devices using some
old DTBs to fail we'd need to enable all domains that are currently
controlled by existing drivers using the custom API.

So we don't only need this fallback for !PM_GENERIC_DOMAINS but also for
cases where we detect a DTB that's missing the nodes to describe the
domains.

Thierry


pgp7cfwSWYBcb.pgp
Description: PGP signature

Re: [PATCH v9 23/30] PCI/mvebu: Use pci_common_init_dev() to simplify code

[Gregory CLEMENT]

Hi Yijing,

On 03/04/2015 11:25, Yijing Wang wrote:
> Mvebu_pcie_scan_bus() is not necessary, we could use
> pci_common_init_dev() instead of pci_common_init(),
> and pass the device pointer as the parent. Then
> pci_scan_root_bus() will be called to scan the pci busses.
> 

2 months ago, Thomas Petazzoni was concerned about the removal of
mvebu_pcie_scan_bus(). So I dig the archives of the discussion
surrounding the pcie-mvebu drive. I found that the main purpose
of using this function was to allow to pass "struct device *" pointer.

Thanks to the introduction of pci_common_init_dev it was not needed
anymore. Actually we should have done this change when this function
had been introduced. So for the point of view of the code it's fine.
Then I tested your full series on Armada XP, Armada 375 and Armada 38x
SoCs, and I didn't saw any regression. So you can add my:

Reviewed-by: Gregory CLEMENT 
Tested-by: Gregory CLEMENT 

Thanks,

Gregory



> Signed-off-by: Yijing Wang 
> CC: Thomas Petazzoni 
> CC: Jason Cooper 
> ---
>  drivers/pci/host/pci-mvebu.c |   18 +-
>  1 files changed, 1 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 0cfc494..d5a2b70 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -750,21 +750,6 @@ static int mvebu_pcie_setup(int nr, struct pci_sys_data 
> *sys)
>   return 1;
>  }
>  
> -static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
> -{
> - struct mvebu_pcie *pcie = sys_to_pcie(sys);
> - struct pci_bus *bus;
> -
> - bus = pci_create_root_bus(&pcie->pdev->dev, -1, sys->busnr,
> -   &mvebu_pcie_ops, sys, &sys->resources);
> - if (!bus)
> - return NULL;
> -
> - pci_scan_child_bus(bus);
> -
> - return bus;
> -}
> -
>  static resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
>const struct resource *res,
>resource_size_t start,
> @@ -808,12 +793,11 @@ static void mvebu_pcie_enable(struct mvebu_pcie *pcie)
>   hw.nr_controllers = 1;
>   hw.private_data   = (void **)&pcie;
>   hw.setup  = mvebu_pcie_setup;
> - hw.scan   = mvebu_pcie_scan_bus;
>   hw.map_irq= of_irq_parse_and_map_pci;
>   hw.ops= &mvebu_pcie_ops;
>   hw.align_resource = mvebu_pcie_align_resource;
>  
> - pci_common_init(&hw);
> + pci_common_init_dev(&pcie->pdev->dev, &hw);
>  }
>  
>  /*
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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: [alsa-devel] Audio Jack Out does not work

[Dan Carpenter]

On Wed, Apr 08, 2015 at 09:57:13AM +0800, Raymond Yau wrote:
> This patch only change the name of control, you will also need pulseaudio
> patch if you are using pulseaudio
> 
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa/mixer?id=aec811798cd883a454b9b5cd82c77831906bbd2d

Ugh...  You are going to make Linus start cursing.

https://lkml.org/lkml/2012/12/23/75

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 03/30] PCI: Save domain in pci_host_bridge

[Gregory CLEMENT]

Hi Yijing,

On 03/04/2015 11:25, Yijing Wang wrote:
> Save domain in pci_host_bridge, so we could get domain
> from pci_host_bridge, and at the end of series, we could
> clean up the arch specific pci_domain_nr(). For arm,
> we pass -1 as the domain number, we would update the
> domain number in core by pci_bus_assign_domain_nr().
> 
For the mvebu part I tested on Armada XP, Armada 375 and Armada 38x
SoCs, and I didn't saw any regression. So you can add my:

Tested-by: Gregory CLEMENT 

Thanks,

Gregory

> Signed-off-by: Yijing Wang 
> ---
>  arch/alpha/kernel/pci.c|4 ++--
>  arch/alpha/kernel/sys_nautilus.c   |2 +-
>  arch/arm/kernel/bios32.c   |2 +-
>  arch/arm/mach-dove/pcie.c  |2 +-
>  arch/arm/mach-iop13xx/pci.c|4 ++--
>  arch/arm/mach-mv78xx0/pcie.c   |2 +-
>  arch/arm/mach-orion5x/pci.c|4 ++--
>  arch/frv/mb93090-mb00/pci-vdk.c|3 ++-
>  arch/ia64/pci/pci.c|4 ++--
>  arch/ia64/sn/kernel/io_init.c  |4 ++--
>  arch/m68k/coldfire/pci.c   |2 +-
>  arch/microblaze/pci/pci-common.c   |4 ++--
>  arch/mips/pci/pci.c|4 ++--
>  arch/mn10300/unit-asb2305/pci.c|3 ++-
>  arch/powerpc/kernel/pci-common.c   |4 ++--
>  arch/s390/pci/pci.c|4 ++--
>  arch/sh/drivers/pci/pci.c  |4 ++--
>  arch/sparc/kernel/leon_pci.c   |2 +-
>  arch/sparc/kernel/pci.c|4 ++--
>  arch/sparc/kernel/pcic.c   |2 +-
>  arch/tile/kernel/pci.c |4 ++--
>  arch/tile/kernel/pci_gx.c  |4 ++--
>  arch/unicore32/kernel/pci.c|2 +-
>  arch/x86/pci/acpi.c|4 ++--
>  arch/x86/pci/common.c  |2 +-
>  arch/xtensa/kernel/pci.c   |2 +-
>  drivers/parisc/dino.c  |2 +-
>  drivers/parisc/lba_pci.c   |2 +-
>  drivers/pci/host/pci-mvebu.c   |2 +-
>  drivers/pci/host/pci-tegra.c   |4 ++--
>  drivers/pci/host/pci-versatile.c   |3 ++-
>  drivers/pci/host/pci-xgene.c   |2 +-
>  drivers/pci/host/pcie-designware.c |2 +-
>  drivers/pci/host/pcie-xilinx.c |2 +-
>  drivers/pci/hotplug/ibmphp_core.c  |2 +-
>  drivers/pci/probe.c|   21 +
>  drivers/pci/xen-pcifront.c |2 +-
>  include/linux/pci.h|8 +---
>  38 files changed, 72 insertions(+), 62 deletions(-)
> 
> diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
> index 82f738e..2b0bce9 100644
> --- a/arch/alpha/kernel/pci.c
> +++ b/arch/alpha/kernel/pci.c
> @@ -336,8 +336,8 @@ common_init_pci(void)
>   pci_add_resource_offset(&resources, hose->mem_space,
>   hose->mem_space->start);
>  
> - bus = pci_scan_root_bus(NULL, next_busno, alpha_mv.pci_ops,
> - hose, &resources);
> + bus = pci_scan_root_bus(NULL, hose->index, next_busno,
> + alpha_mv.pci_ops, hose, &resources);
>   if (!bus)
>   continue;
>   hose->bus = bus;
> diff --git a/arch/alpha/kernel/sys_nautilus.c 
> b/arch/alpha/kernel/sys_nautilus.c
> index 700686d..9614e4e 100644
> --- a/arch/alpha/kernel/sys_nautilus.c
> +++ b/arch/alpha/kernel/sys_nautilus.c
> @@ -206,7 +206,7 @@ nautilus_init_pci(void)
>   unsigned long memtop = max_low_pfn << PAGE_SHIFT;
>  
>   /* Scan our single hose.  */
> - bus = pci_scan_bus(0, alpha_mv.pci_ops, hose);
> + bus = pci_scan_bus(hose->index, 0, alpha_mv.pci_ops, hose);
>   if (!bus)
>   return;
>  
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index ab19b7c..fec2c90 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -486,7 +486,7 @@ static void pcibios_init_hw(struct device *parent, struct 
> hw_pci *hw,
>   if (hw->scan)
>   sys->bus = hw->scan(nr, sys);
>   else
> - sys->bus = pci_scan_root_bus(parent, sys->busnr,
> + sys->bus = pci_scan_root_bus(parent, -1, 
> sys->busnr,
>   hw->ops, sys, &sys->resources);
>  
>   if (!sys->bus)
> diff --git a/arch/arm/mach-dove/pcie.c b/arch/arm/mach-dove/pcie.c
> index 91fe971..a379287 100644
> --- a/arch/arm/mach-dove/pcie.c
> +++ b/arch/arm/mach-dove/pcie.c
> @@ -160,7 +160,7 @@ dove_pcie_scan_bus(int nr, struct pci_sys_data *sys)
>   return NULL;
>   }
>  
> - return pci_scan_root_bus(NULL, sys->busnr, &pcie_ops, sys,
> + return pci_scan_root_bus(NULL, -1, sys->busnr, &pcie_ops, sys,
>&sys->resources);
>  }
>  
> diff --git a/arch/arm/mach-iop13xx/pci.c b/arch/arm/mach-iop13xx/pci.c
> index 9082b84..bc4ba7e 100644
> --- a/arch/arm/

[PATCH v2 2/2] ARM: at91/dt: add support for kizboxmini

[Gaël PORTAY]

Add DT file for Kizbox mini board.
This board is based on Atmel's AT91SAM9G25 SoC.

Signed-off-by: Gaël PORTAY 
---
 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/at91-kizboxmini.dts | 129 ++
 2 files changed, 130 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-kizboxmini.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a1c776b..9c11888 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -30,6 +30,7 @@ dtb-$(CONFIG_SOC_SAM_V4_V5) += \
at91sam9rlek.dtb \
at91-ariag25.dtb \
at91-cosino_mega2560.dtb \
+   at91-kizboxmini.dtb \
at91sam9g15ek.dtb \
at91sam9g25ek.dtb \
at91sam9g35ek.dtb \
diff --git a/arch/arm/boot/dts/at91-kizboxmini.dts 
b/arch/arm/boot/dts/at91-kizboxmini.dts
new file mode 100644
index 000..b25cae4
--- /dev/null
+++ b/arch/arm/boot/dts/at91-kizboxmini.dts
@@ -0,0 +1,129 @@
+/*
+ * at91-kizboxmini.dts - Device Tree file for Overkiz Kizbox mini board
+ *
+ * Copyright (C) 2014 Gaël PORTAY 
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include "at91sam9g25.dtsi"
+#include "at91sam9x5.dtsi"
+#include 
+
+/ {
+   model = "Overkiz Kizbox mini";
+   compatible = "overkiz,kizboxmini", "atmel,at91sam9g25", 
"atmel,at91sam9x5", "atmel,at91sam9";
+
+   chosen {
+   bootargs = "ubi.mtd=ubi";
+   linux,stdout-path = &dbgu;
+   };
+
+   memory {
+   reg = <0x2000 0x800>;
+   };
+
+   clocks {
+   slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal {
+   clock-frequency = <1200>;
+   };
+   };
+
+   ahb {
+   apb {
+   usart0: serial@f801c000 {
+   status = "okay";
+   };
+
+   macb0: ethernet@f802c000 {
+   phy-mode = "rmii";
+   status = "okay";
+   };
+
+   pwm0: pwm@f8034000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_pwm0_pwm0_1
+&pinctrl_pwm0_pwm1_1>;
+   status = "okay";
+   };
+
+   dbgu: serial@f200 {
+   status = "okay";
+   };
+
+   watchdog@fe40 {
+   status = "okay";
+   };
+   };
+
+   usb0: ohci@0060 {
+   status = "okay";
+   };
+
+   usb1: ehci@0070 {
+   status = "okay";
+   };
+
+   nand0: nand@4000 {
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   atmel,has-pmecc;
+   atmel,pmecc-cap = <4>;
+   atmel,pmecc-sector-size = <512>;
+   nand-on-flash-bbt;
+   status = "okay";
+
+   bootstrap@0 {
+   label = "bootstrap";
+   reg = <0x0 0x2>;
+   };
+
+   ubi@2 {
+   label = "ubi";
+   reg = <0x2 0x7fe>;
+   };
+   };
+   };
+
+   pwm_leds {
+   compatible = "pwm-leds";
+
+   green {
+   label = "pwm:green:user";
+   pwms = <&pwm0 0 1000 0>;
+   max-brightness = <255>;
+   linux,default-trigger = "default-on";
+   };
+
+   red {
+   label = "pwm:red:user";
+   pwms = <&pwm0 1 1000 0>;
+   max-brightness = <255>;
+   linux,default-trigger = "default-on";
+   };
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   prog {
+   label = "PB_PROG";
+   gpios = <&pioC 17 GPIO_ACTIVE_LOW>;
+   linux,code = <0x102>;
+   gpio-key,wakeup;
+   };
+
+   reset {
+   label = "PB_RST";
+   gpios = <&pioC 16 GPIO_ACTIVE_LOW>;
+   linux,code = <0x100>;
+   gpio-key,wakeup;
+   };
+   };
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majord

Re: [PATCH v2 03/17] IB/Verbs: Use management helper cap_ib_mad() for mad-check

[Michael Wang]

On 04/07/2015 07:26 PM, Jason Gunthorpe wrote:
> On Tue, Apr 07, 2015 at 02:30:22PM +0200, Michael Wang wrote:
> 
>> -if (rdma_node_get_transport(device->node_type) != RDMA_TRANSPORT_IB)
>> -return;
>> -
>>  if (device->node_type == RDMA_NODE_IB_SWITCH) {
>>  start = 0;
>>  end   = 0;
>> @@ -3069,6 +3066,9 @@ static void ib_mad_init_device(struct ib_device 
>> *device)
>>  }
>>  
>>  for (i = start; i <= end; i++) {
>> +if (!cap_ib_mad(device, i))
>> +continue;
>> +
> 
> I would prefer to see these changes in control flow as dedicated
> patches, at the top of your patch stack.
> 
> For this kind of work a patch should be mechanical changes only, it is
> easier to review that way.
> 
> Same comment applies throughout.

Make sense :-) I will re-organize the sequence and put them at last.

Regards,
Michael Wang

> 
> Jason
> 
--
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: manual merge of the kvm-arm tree with Linus' tree

[Marc Zyngier]

On Tue, 7 Apr 2015 17:20:15 +0100
Paolo Bonzini  wrote:

Hi Paolo,

> On 18/03/2015 08:55, Christoffer Dall wrote:
> > Hi Stephen,
> > 
> > On Wed, Mar 18, 2015 at 02:41:11PM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Today's linux-next merge of the kvm-arm tree got a conflict in
> >> virt/kvm/arm/vgic.c between commit ae705930fca6 ("arm/arm64: KVM: Keep
> >> elrsr/aisr in sync with software model") from Linus' tree and commit
> >> 71760950bf3d ("arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn")
> >> from the kvm-arm tree.
> >>
> >> I fixed it up (I think - see below) and can carry the fix as necessary
> >> (no action is required).
> >>
> >> -- 
> >> Cheers,
> >> Stephen Rothwells...@canb.auug.org.au
> >>
> >> diff --cc virt/kvm/arm/vgic.c
> >> index c9f60f524588,ffd937ca5141..
> >> --- a/virt/kvm/arm/vgic.c
> >> +++ b/virt/kvm/arm/vgic.c
> >> @@@ -982,9 -1092,7 +1098,8 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
> >>if (vlr.source == sgi_source_id) {
> >>kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
> >>BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
> >> -  vlr.state |= LR_STATE_PENDING;
> >> -  vgic_set_lr(vcpu, lr, vlr);
> >> +  vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> >>  + vgic_sync_lr_elrsr(vcpu, lr, vlr);
> >>return true;
> >>}
> >>}
> >> @@@ -1001,12 -1109,8 +1116,9 @@@
> >>   
> >>vlr.irq = irq;
> >>vlr.source = sgi_source_id;
> >> -  vlr.state = LR_STATE_PENDING;
> >> -  if (!vgic_irq_is_edge(vcpu, irq))
> >> -  vlr.state |= LR_EOI_INT;
> >> - 
> >> -  vgic_set_lr(vcpu, lr, vlr);
> >> +  vlr.state = 0;
> >> +  vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> >>  + vgic_sync_lr_elrsr(vcpu, lr, vlr);
> >>   
> >>return true;
> >>   }
> > 
> > Looks great, thanks!
> > -Christoffer
> 
> Got the same conflict when pulling from the kvm-arm tree, I used
> a different resolution though:
> 
> diff --cc virt/kvm/arm/vgic.c
> index c9f60f524588,b70174e74868..8d550ff14700
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@@ -955,6 -1095,25 +1101,26 @@@ static void vgic_retire_disabled_irqs(s
>   }
>   }
>   
> + static void vgic_queue_irq_to_lr(struct kvm_vcpu *vcpu, int irq,
> +  int lr_nr, struct vgic_lr vlr)
> + {
> + if (vgic_irq_is_active(vcpu, irq)) {
> + vlr.state |= LR_STATE_ACTIVE;
> + kvm_debug("Set active, clear distributor: 0x%x\n", vlr.state);
> + vgic_irq_clear_active(vcpu, irq);
> + vgic_update_state(vcpu->kvm);
> + } else if (vgic_dist_irq_is_pending(vcpu, irq)) {
> + vlr.state |= LR_STATE_PENDING;
> + kvm_debug("Set pending: 0x%x\n", vlr.state);
> + }
> + 
> + if (!vgic_irq_is_edge(vcpu, irq))
> + vlr.state |= LR_EOI_INT;
> + 
> + vgic_set_lr(vcpu, lr_nr, vlr);
> ++vgic_sync_lr_elrsr(vcpu, lr_nr, vlr);
> + }
> + 
>   /*
>* Queue an interrupt to a CPU virtual interface. Return true on success,
>* or false if it wasn't possible to queue it.
> @@@ -982,9 -1141,7 +1148,7 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
> if (vlr.source == sgi_source_id) {
> kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
> BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
> -   vlr.state |= LR_STATE_PENDING;
> -   vgic_set_lr(vcpu, lr, vlr);
> -   vgic_sync_lr_elrsr(vcpu, lr, vlr);
> +   vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> return true;
> }
> }
> @@@ -1001,12 -1158,8 +1165,8 @@@
>   
> vlr.irq = irq;
> vlr.source = sgi_source_id;
> -   vlr.state = LR_STATE_PENDING;
> -   if (!vgic_irq_is_edge(vcpu, irq))
> -   vlr.state |= LR_EOI_INT;
> - 
> -   vgic_set_lr(vcpu, lr, vlr);
> -   vgic_sync_lr_elrsr(vcpu, lr, vlr);
> +   vlr.state = 0;
> +   vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
>   
> return true;
>   }
> 
> 
> Christoffer, this is the same logic as Stephen's resolution, but
> can you confirm that it makes sense "semantically" as well?

This looks like a sensible resolution to me. I've given it a spin, and
it seems to behave as expected.

Thanks,

M.
-- 
Without deviation from the norm, progress is not possible.
--
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 v6 4/4] clk: dt: Introduce binding for always-on clock support

[Lee Jones]

On Tue, 07 Apr 2015, Maxime Ripard wrote:
> On Tue, Apr 07, 2015 at 07:43:59PM +0100, Lee Jones wrote:
> > Signed-off-by: Lee Jones 
> > ---
> >  .../devicetree/bindings/clock/clock-bindings.txt   | 38 
> > ++
> >  1 file changed, 38 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt 
> > b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> > index 06fc6d5..daf3323 100644
> > --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> > @@ -44,6 +44,44 @@ For example:
> >clocks by index. The names should reflect the clock output signal
> >names for the device.
> >  
> > +clock-always-on:Some hardware contains bunches of clocks which must 
> > never be
> > +   turned off.  If drivers a) fail to obtain a reference to any
> > +   of these or b) give up a previously obtained reference
> > +   during suspend, the common clk framework will attempt to
> > +   disable them and a platform can fail irrecoverably as a
> > +   result.  Usually the only way to recover from these failures
> > +   is to reboot.
> > +
> > +   To avoid either of these two scenarios from catastrophically
> > +   disabling an otherwise perfectly healthy running system,
> > +   clocks can be identified as always-on using this property
> > +   from inside a clocksource's node.
> 
> Isn't "clocksource" here way too similar to, I don't know, the
> clocksource framework? Wouln't clock provider be better?

Yes, I think you're right.  Stephen also mentioned it.

> > +
> > +   This property is not to be abused.  It is only to be used to
> > +   protect platforms from being crippled by gated clocks, not
> > +   as a convenience function to avoid using the framework
> > +   correctly inside device drivers.
> 
> Disregarding what's stated here, I'm pretty sure that this will
> actually happen. Where do you place the cursor?

That's up to Mike.

> Should we create a new driver for our RAM controller, or do we want to
> use clock-always-on?

I would say that if all the driver did was to enable clocks, then you
should use this instead.  This binding was designed specifically for
that purpose.

However, if the aforementioned driver clock can be safely gated, then
it should not be an always-on clock.

> Do we really want to enforce this if we ever gain a driver that would
> actually be able to manage its clock (like do we want the CPU clock to
> never *ever* be gated just because we don't have a cpuidle/hotplug
> driver yet?)

As I've just mentioned, if a clock 'can' be turned off, this binding
should never be used.  Situations where using always-on as a stop-gap
due to a lack of current functionality is what the paragraph above is
trying to mitigate.

> Have you seen the numerous NAK on such approach Mike did?

I haven't, but the folks reviewing previous versions have.  Do you
have something specific in mind that you'd like to bring to my
attention?

-- 
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 v9 07/30] PCI: Add default bus resource in pci_host_bridge

[Yijing Wang]

>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 1542df8..f189dfb 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -404,6 +404,8 @@ struct pci_host_bridge {
>>  int domain;
>>  struct device dev;
>>  struct pci_bus *bus;/* root bus */
>> +/* we use default bus resource if no bus resource provided */
>> +struct resource busn_res;
> 
> I don't understand the need for another busn_res here.  The host bridge bus
> range should be identical to the root bus range.  Having two copies will
> confuse things.
> 
> And apparently this host->busn_res is only filled in if the arch doesn't
> provide a busn resource?
> 
> To check for conflicts between host bridges, can you iterate through the
> existing ones and check the range of their root buses?

Checking root buses is not enough, there is time gap between pci_host_bridge 
creation and
pci root bus creation.
E.g. A and B do pci scan sync in two cpus, A first check the buses resource, 
and find free
bus resource, then it go to create pci_host_bridge and scan root bus, at the 
same time, B
also check the buses resource, because A has not created root bus, B also think 
there are
free buses, this is a problem.

I agree you that having two copies is not a good idea.

For pci bus resource, we have the following request path:
1. arch supplies the busn_res or PCI core add the default bus resource(in 
pci_scan_bus);
2. Call pci_bus_insert_busn_res() to insert the bus resource for root bus.
3. Call get_pci_domain_busn_res() to return the per-domain bus resource.
4. Request root bus resource under per-domain bus resource.

We have the per-domain structure pci_domain_busn_res to manage the bus 
resources in one domain,
so what about add a bitmap to manage the free bus resource ?
In pci_create_host_bridge(), first check whether the new pci_host_bridge bus 
resources required
is free, if yes, we set the bitmap to occupy the bus resource at once,  then 
create the host bridge
and add it to the global list.

struct pci_domain_busn_res {
struct list_head list;
struct resource res;
int domain_nr;
bitmap used;
};

Another problem, I found it's unnecessary to add bus resource to 
pci_host_bridge->windows.
Unlike the IO and MEM resource, we never use the pci_host_bridge bus resource 
again after
pci enumeration. I think we could clean it up, or in some cases, when arch 
supplies the
bus resource, we still have the two copies.

Thanks!
Yijing.

> 
>>  struct list_head windows;   /* resource_entry */
>>  void (*release_fn)(struct pci_host_bridge *);
>>  void *release_data;
>> -- 
>> 1.7.1
>>
> 
> .
> 


-- 
Thanks!
Yijing

--
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 0/2] ARM: at91/dt: add support for at91-kizboxmini

[Gaël PORTAY]

Hi,

Here are two patches to bring support for a new hardware based on SAM9G25 SoC.

The first one adds the PIN controller definition for PWM0.
The second defines the new board.

Changes since v1:
- drop useless comments
- move pwm0 pinctrl's node close to tcb0
- drop ek boards from compatible machine
- add at91sam9g25 board to compatible machine

Best regards,
Gaël PORTAY (2):
  ARM: at91/dt: sam9x5: add pinctrl for pwm0
  ARM: at91/dt: add support for kizboxmini

 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/at91-kizboxmini.dts | 129 ++
 arch/arm/boot/dts/at91sam9x5.dtsi |  46 
 3 files changed, 176 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-kizboxmini.dts

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kvm: x86: fix x86 eflags fixed bit

[Nadav Amit]

Sorry for that - fixes 0efb04406de834d820f7ba150a00d1d3194aa8a6 ("KVM: x86:
removing redundant eflags bits definitions”).

Nadav

Wanpeng Li  wrote:

> Guest can't be booted w/ ept=0, there is a message dumped as below:
> 
> If you're running a guest on an Intel machine without unrestricted mode
> support, the failure can be most likely due to the guest entering an invalid
> state for Intel VT. For example, the guest maybe running in big real mode
> which is not supported on less recent Intel processors.
> 
> EAX=0011 EBX=f000d2f6 ECX=6cac EDX=000f8956
> ESI=bffbdf62 EDI= EBP=6c68 ESP=6c68
> EIP=d187 EFL=0004 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =e000 000e  00809300 DPL=0 DS16 [-WA]
> CS =f000 000f  00809b00 DPL=0 CS16 [-RA]
> SS =   00809300 DPL=0 DS16 [-WA]
> DS =   00809300 DPL=0 DS16 [-WA]
> FS =   00809300 DPL=0 DS16 [-WA]
> GS =   00809300 DPL=0 DS16 [-WA]
> LDT=   8200 DPL=0 LDT
> TR =   8b00 DPL=0 TSS32-busy
> GDT= 000f6a80 0037
> IDT= 000f6abe 
> CR0=0011 CR2= CR3= CR4=
> DR0= DR1= DR2= 
> DR3= 
> DR6=0ff0 DR7=0400
> EFER=
> Code=01 1e b8 6a 2e 0f 01 16 74 6a 0f 20 c0 66 83 c8 01 0f 22 c0 <66> ea 8f 
> d1 0f 00 08 00 b8 10 00 00 00 8e d8 8e c0 8e d0 8e e0 8e e8 89 c8 ff e2 89 c1 
> b8X
> 
> X86 eflags bit 1 is fixed set, which means that 1 << 1 is set instead of 1, 
> this patch fix it.
> 
> Signed-off-by: Wanpeng Li 
> ---
> arch/x86/kvm/emulate.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index b304728..630bcb0 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -2033,7 +2033,7 @@ static int emulate_iret_real(struct x86_emulate_ctxt 
> *ctxt)
>X86_EFLAGS_IF | X86_EFLAGS_DF | X86_EFLAGS_OF |
>X86_EFLAGS_IOPL | X86_EFLAGS_NT | X86_EFLAGS_RF |
>X86_EFLAGS_AC | X86_EFLAGS_ID |
> -  X86_EFLAGS_FIXED_BIT;
> +  X86_EFLAGS_FIXED;
>   unsigned long vm86_mask = X86_EFLAGS_VM | X86_EFLAGS_VIF |
> X86_EFLAGS_VIP;
> 
> @@ -2072,7 +2072,7 @@ static int emulate_iret_real(struct x86_emulate_ctxt 
> *ctxt)
>   }
> 
>   ctxt->eflags &= ~EFLG_RESERVED_ZEROS_MASK; /* Clear reserved zeros */
> - ctxt->eflags |= X86_EFLAGS_FIXED_BIT;
> + ctxt->eflags |= X86_EFLAGS_FIXED;
>   ctxt->ops->set_nmi_mask(ctxt, false);
> 
>   return rc;
> @@ -2390,7 +2390,7 @@ static int em_syscall(struct x86_emulate_ctxt *ctxt)
> 
>   ops->get_msr(ctxt, MSR_SYSCALL_MASK, &msr_data);
>   ctxt->eflags &= ~msr_data;
> - ctxt->eflags |= X86_EFLAGS_FIXED_BIT;
> + ctxt->eflags |= X86_EFLAGS_FIXED;
> #endif
>   } else {
>   /* legacy mode */
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
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: [RESEND PATCH 4.0-rc5 v19 3/6] irqchip: gic: Introduce plumbing for IPI FIQ

[Hillf Danton]

> +/*
> + * Fully acknowledge (both ack and eoi) any outstanding FIQ-based IPI,
> + * otherwise do nothing.
> + */
> +void gic_handle_fiq_ipi(void)
> +{
> + struct gic_chip_data *gic = &gic_data[0];
> + void __iomem *cpu_base = gic_data_cpu_base(gic);
> + unsigned long irqstat, irqnr;
> +
> + if (WARN_ON(!in_nmi()))
> + return;
> +
> + while ((1u << readl_relaxed(cpu_base + GIC_CPU_HIGHPRI)) &
> +SMP_IPI_FIQ_MASK) {
> + irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK);
> + writel_relaxed(irqstat, cpu_base + GIC_CPU_EOI);
> +
> + irqnr = irqstat & GICC_IAR_INT_ID_MASK;
> + WARN_RATELIMIT(irqnr > 16,
> +"Unexpected irqnr %lu (bad prioritization?)\n",

Help more if s/Unexpected/Unexpected FIQ/ ?

> +irqnr);
> + }
> +}
> +

--
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: Audio Jack Out does not work

[Takashi Iwai]

At Tue, 07 Apr 2015 21:07:06 -0400,
Taylor Smock wrote:
> 
> Yes; reverting the patch does fix the problem.

What if you just adjust the new volume manually without reverting the
patch?  Run "alsamixer -c0" (or -c1, depending on the setup).  Once
after the setup, run "alsactl store" as root to save as the system
default volume.

The renamed volume should have been set in full volume as default by
the driver, and this shouldn't matter whether PA is new or old.  If
the mixer adjustment isn't kept after relogin or reboot, it means that
some user-space stuff overrides it.

In anyway, please give alsa-info.sh output before and after the
commit.


Takashi

> On Wed, 2015-04-08 at 01:56 +0300, Dan Carpenter wrote:
> > So it's 03ad6a8c93b6df2 ('ALSA: hda - Fix "PCM" name being used on > one
> > DAC when there are two DACs') which causes the problem?  Have you 
> > tried
> > to just revert that patch?
> > 
> > git show 03ad6a8c93b6df2d65c305b5b5f9474068b45bfb | patch -p1 -R
> > 
> > regards,
> > dan carpenter
> > 
> 
--
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 7/7] vhost: feature to set the vring endianness

[Greg Kurz]

On Tue, 7 Apr 2015 17:52:28 +0200
"Michael S. Tsirkin"  wrote:

> On Tue, Apr 07, 2015 at 02:19:31PM +0200, Greg Kurz wrote:
> > This patch brings cross-endian support to vhost when used to implement
> > legacy virtio devices. Since it is a relatively rare situation, the
> > feature availability is controlled by a kernel config option (not set
> > by default).
> > 
> > The ioctls introduced by this patch are for legacy only: virtio 1.0
> > devices are returned EPERM.
> > 
> > Signed-off-by: Greg Kurz 
> 
> EINVAL probably makes more sense?
> 

I had choosen EPERM because the error isn't related to the arguments
being passed by userspace. It simply does not make sense to set the
vring endianness for a virtio 1.0 device.

That being said, I am perfectly fine with EINVAL. :)

> > ---
> >  drivers/vhost/Kconfig  |   10 
> >  drivers/vhost/vhost.c  |   55 
> > 
> >  drivers/vhost/vhost.h  |   17 +-
> >  include/uapi/linux/vhost.h |5 
> >  4 files changed, 86 insertions(+), 1 deletion(-)
> > 
> > Changes since v2:
> > - fixed typos in Kconfig description
> > - renamed vq->legacy_big_endian to vq->legacy_is_little_endian
> > - vq->legacy_is_little_endian reset to default in vhost_vq_reset()
> > - dropped VHOST_F_SET_ENDIAN_LEGACY feature
> > - dropped struct vhost_vring_endian from the user API (re-use
> >   struct vhost_vring_state instead)
> > - added VHOST_GET_VRING_ENDIAN_LEGACY ioctl
> > - introduced more helpers and stubs to avoid polluting the code with ifdefs
> > 
> > 
> > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> > index 017a1e8..0aec88c 100644
> > --- a/drivers/vhost/Kconfig
> > +++ b/drivers/vhost/Kconfig
> > @@ -32,3 +32,13 @@ config VHOST
> > ---help---
> >   This option is selected by any driver which needs to access
> >   the core of vhost.
> > +
> > +config VHOST_SET_ENDIAN_LEGACY
> > +   bool "Cross-endian support for host kernel accelerator"
> > +   default n
> > +   ---help---
> > + This option allows vhost to support guests with a different byte
> > + ordering from host. It is disabled by default since it adds overhead
> > + and it is only needed by a few platforms (powerpc and arm).
> > +
> > + If unsure, say "N".
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 2ee2826..3529a3c 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -199,6 +199,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
> > vq->call = NULL;
> > vq->log_ctx = NULL;
> > vq->memory = NULL;
> > +   vq->legacy_is_little_endian = virtio_legacy_is_little_endian();
> >  }
> >  
> >  static int vhost_worker(void *data)
> > @@ -630,6 +631,54 @@ static long vhost_set_memory(struct vhost_dev *d, 
> > struct vhost_memory __user *m)
> > return 0;
> >  }
> >  
> > +#ifdef CONFIG_VHOST_SET_ENDIAN_LEGACY
> > +static long vhost_set_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + void __user *argp)
> > +{
> > +   struct vhost_vring_state s;
> > +
> > +   if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
> > +   return -EPERM;
> 
> EINVAL probably makes more sense? But I'm not sure this
> is helpful: one can set VIRTIO_F_VERSION_1 afterwards,
> and your patch does not seem to detect this.
> 

Yeah, when I dropped the *bogus* feature from v2, I forgot to patch
VHOST_SET_FEATURES accordingly... But thinking about it now, the choice
to error out when setting VIRTIO_F_VERSION_1 because cross-endian legacy
was set before looks terrible... :-\

> 
> 
> > +
> > +   if (copy_from_user(&s, argp, sizeof(s)))
> > +   return -EFAULT;
> > +
> > +   vq->legacy_is_little_endian = !!s.num;
> > +   return 0;
> > +}
> > +
> > +static long vhost_get_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + u32 idx,
> > + void __user *argp)
> > +{
> > +   struct vhost_vring_state s = {
> > +   .index = idx,
> > +   .num = vq->legacy_is_little_endian
> > +   };
> > +
> > +   if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
> > +   return -EPERM;
> > +
> > +   if (copy_to_user(argp, &s, sizeof(s)))
> > +   return -EFAULT;
> > +
> > +   return 0;
> > +}
> > +#else
> > +static long vhost_set_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + void __user *argp)
> > +{
> > +   return 0;
> > +}
> > +
> > +static long vhost_get_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + u32 idx,
> > + void __user *argp)
> > +{
> > +   return 0;
> > +}
> 
> Should be -ENOIOCTLCMD?
> 

Sure.

> > +#endif /* CONFIG_VHOST_SET_ENDIAN_LEGACY */
> > +
> >  long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp)
> >  {
> > struct file *eventfp, *filep = NULL;
> > @@ -806,6 +855,12 @@ long vhost_vring_ioc

Re: [PATCH v2 10/17] IB/Verbs: Adopt management helpers for IB helpers

[Michael Wang]

On 04/07/2015 08:40 PM, Hefty, Sean wrote:
[snip]
>> @@ -200,11 +200,9 @@ int ib_init_ah_from_wc(struct ib_device *device, u8
>> port_num, struct ib_wc *wc,
>>  u32 flow_class;
>>  u16 gid_index;
>>  int ret;
>> -int is_eth = (rdma_port_get_link_layer(device, port_num) ==
>> -IB_LINK_LAYER_ETHERNET);
>>
>>  memset(ah_attr, 0, sizeof *ah_attr);
>> -if (is_eth) {
>> +if (!rdma_transport_ib(device, port_num)) {
>>  if (!(wc->wc_flags & IB_WC_GRH))
>>  return -EPROTOTYPE;
>>
>> @@ -873,7 +871,7 @@ int ib_resolve_eth_l2_attrs(struct ib_qp *qp,
>>  union ib_gid  sgid;
>>
>>  if ((*qp_attr_mask & IB_QP_AV)  &&
>> -(rdma_port_get_link_layer(qp->device, qp_attr->ah_attr.port_num)
>> == IB_LINK_LAYER_ETHERNET)) {
>> +(!rdma_transport_ib(qp->device, qp_attr->ah_attr.port_num))) {
>>  ret = ib_query_gid(qp->device, qp_attr->ah_attr.port_num,
>> qp_attr->ah_attr.grh.sgid_index, &sgid);
>>  if (ret)
> 
> The above checks would be better as:
> 
>   force_grh = rdma_transport_iboe(...)
> 
> They are RoCE/IBoE specific checks.

Got it, will be in next version :-)

Regards,
Michael Wang

> 
--
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/

linux-next: manual merge of the akpm-current tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
drivers/rtc/class.c between commit 0fa88cb4b82b ("time, drivers/rtc:
Don't bother with rtc_resume() for the nonstop clocksource") from the
tip tree and commit df9d6ec42558 ("rtc: restore alarm after resume")
from the akpm-current tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/rtc/class.c
index c29ba7e14304,d46549ce8fd9..
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@@ -55,7 -55,9 +55,9 @@@ static int rtc_suspend(struct device *d
struct timespec64   delta, delta_delta;
int err;
  
+   rtc->valid_alarm = !rtc_read_alarm(rtc, &rtc->alarm);
+ 
 -  if (has_persistent_clock())
 +  if (timekeeping_rtc_skipsuspend())
return 0;
  
if (strcmp(dev_name(&rtc->dev), CONFIG_RTC_HCTOSYS_DEVICE) != 0)
@@@ -102,7 -104,28 +104,28 @@@ static int rtc_resume(struct device *de
struct timespec64   sleep_time;
int err;
  
+   /*
+* Ensure that the platform hasn't overwritten a pending alarm while
+* suspended
+*/
+   if (rtc->valid_alarm) {
+   long now, scheduled;
+ 
+   rtc_read_time(rtc, &tm);
+   rtc_tm_to_time(&rtc->alarm.time, &scheduled);
+   rtc_tm_to_time(&tm, &now);
+ 
+   /* Clear the alarm registers if it went off during suspend */
+   if (scheduled <= now) {
+   rtc_time_to_tm(0, &rtc->alarm.time);
+   rtc->alarm.enabled = 0;
+   }
+ 
+   if (rtc->ops && rtc->ops->set_alarm)
+   rtc->ops->set_alarm(rtc->dev.parent, &rtc->alarm);
+   }
+ 
 -  if (has_persistent_clock())
 +  if (timekeeping_rtc_skipresume())
return 0;
  
rtc_hctosys_ret = -ENODEV;


pgpeYFmg5JYt6.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 7/7] vhost: feature to set the vring endianness

[Greg Kurz]

On Tue, 7 Apr 2015 18:11:29 +0200
"Michael S. Tsirkin"  wrote:

> On Tue, Apr 07, 2015 at 02:19:31PM +0200, Greg Kurz wrote:
> > This patch brings cross-endian support to vhost when used to implement
> > legacy virtio devices. Since it is a relatively rare situation, the
> > feature availability is controlled by a kernel config option (not set
> > by default).
> > 
> > The ioctls introduced by this patch are for legacy only: virtio 1.0
> > devices are returned EPERM.
> > 
> > Signed-off-by: Greg Kurz 
> > ---
> >  drivers/vhost/Kconfig  |   10 
> >  drivers/vhost/vhost.c  |   55 
> > 
> >  drivers/vhost/vhost.h  |   17 +-
> >  include/uapi/linux/vhost.h |5 
> >  4 files changed, 86 insertions(+), 1 deletion(-)
> > 
> > Changes since v2:
> > - fixed typos in Kconfig description
> > - renamed vq->legacy_big_endian to vq->legacy_is_little_endian
> > - vq->legacy_is_little_endian reset to default in vhost_vq_reset()
> > - dropped VHOST_F_SET_ENDIAN_LEGACY feature
> > - dropped struct vhost_vring_endian from the user API (re-use
> >   struct vhost_vring_state instead)
> > - added VHOST_GET_VRING_ENDIAN_LEGACY ioctl
> > - introduced more helpers and stubs to avoid polluting the code with ifdefs
> > 
> > 
> > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> > index 017a1e8..0aec88c 100644
> > --- a/drivers/vhost/Kconfig
> > +++ b/drivers/vhost/Kconfig
> > @@ -32,3 +32,13 @@ config VHOST
> > ---help---
> >   This option is selected by any driver which needs to access
> >   the core of vhost.
> > +
> > +config VHOST_SET_ENDIAN_LEGACY
> > +   bool "Cross-endian support for host kernel accelerator"
> > +   default n
> > +   ---help---
> > + This option allows vhost to support guests with a different byte
> > + ordering from host. It is disabled by default since it adds overhead
> > + and it is only needed by a few platforms (powerpc and arm).
> > +
> > + If unsure, say "N".
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 2ee2826..3529a3c 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -199,6 +199,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
> > vq->call = NULL;
> > vq->log_ctx = NULL;
> > vq->memory = NULL;
> > +   vq->legacy_is_little_endian = virtio_legacy_is_little_endian();
> >  }
> >  
> >  static int vhost_worker(void *data)
> > @@ -630,6 +631,54 @@ static long vhost_set_memory(struct vhost_dev *d, 
> > struct vhost_memory __user *m)
> > return 0;
> >  }
> >  
> > +#ifdef CONFIG_VHOST_SET_ENDIAN_LEGACY
> > +static long vhost_set_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + void __user *argp)
> > +{
> > +   struct vhost_vring_state s;
> > +
> > +   if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
> > +   return -EPERM;
> > +
> > +   if (copy_from_user(&s, argp, sizeof(s)))
> > +   return -EFAULT;
> > +
> > +   vq->legacy_is_little_endian = !!s.num;
> > +   return 0;
> > +}
> > +
> > +static long vhost_get_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + u32 idx,
> > + void __user *argp)
> > +{
> > +   struct vhost_vring_state s = {
> > +   .index = idx,
> > +   .num = vq->legacy_is_little_endian
> > +   };
> > +
> > +   if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
> > +   return -EPERM;
> > +
> > +   if (copy_to_user(argp, &s, sizeof(s)))
> > +   return -EFAULT;
> > +
> > +   return 0;
> > +}
> > +#else
> > +static long vhost_set_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + void __user *argp)
> > +{
> > +   return 0;
> > +}
> > +
> > +static long vhost_get_vring_endian_legacy(struct vhost_virtqueue *vq,
> > + u32 idx,
> > + void __user *argp)
> > +{
> > +   return 0;
> > +}
> > +#endif /* CONFIG_VHOST_SET_ENDIAN_LEGACY */
> > +
> >  long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp)
> >  {
> > struct file *eventfp, *filep = NULL;
> > @@ -806,6 +855,12 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, 
> > void __user *argp)
> > } else
> > filep = eventfp;
> > break;
> > +   case VHOST_SET_VRING_ENDIAN_LEGACY:
> > +   r = vhost_set_vring_endian_legacy(vq, argp);
> > +   break;
> > +   case VHOST_GET_VRING_ENDIAN_LEGACY:
> > +   r = vhost_get_vring_endian_legacy(vq, idx, argp);
> > +   break;
> > default:
> > r = -ENOIOCTLCMD;
> > }
> > diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> > index 4e9a186..981ba06 100644
> > --- a/drivers/vhost/vhost.h
> > +++ b/drivers/vhost/vhost.h
> > @@ -106,6 +106,9 @@ struct vhost_virtqueue {
> > /* Log write descriptors */
> > void __user *log_base

[PATCH] Documentation/memory-barriers.txt: typo fix

[Michael S. Tsirkin]

Fix an obvious typo in the documentation.

Signed-off-by: Michael S. Tsirkin 
---
 Documentation/memory-barriers.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/memory-barriers.txt 
b/Documentation/memory-barriers.txt
index ca2387e..a3a94ff 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1711,7 +1711,7 @@ There are some more advanced barrier functions:
}
 
  The dma_rmb() allows us guarantee the device has released ownership
- before we read the data from the descriptor, and he dma_wmb() allows
+ before we read the data from the descriptor, and the dma_wmb() allows
  us to guarantee the data is written to the descriptor before the device
  can see it now has ownership.  The wmb() is needed to guarantee that the
  cache coherent memory writes have completed before attempting a write to
-- 
MST
--
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 5/6] pwm: samsung: Fix output race on disabling

[Lukasz Majewski]

Hi Anand,

> From: Sjoerd Simons 
> 
> When disabling the samsung PWM the output state remains at the level
> it was in the end of a pwm cycle. In other words, calling pwm_disable
> when at 100% duty will keep the output active, while at all other
> setting the output will go/stay inactive. On top of that the samsung
> PWM settings are double-buffered, which means the new settings only
> get applied at the start of a new PWM cycle.
> 
> This results in a race if the PWM is at 100% duty and a driver calls:
>   pwm_config (pwm, 0, period);
>   pwm_disable (pwm);
> 
> In this case the PWMs output will unexpectedly stay active, unless a
> new PWM cycle happened to start between the register writes in
> _config and _disable. As far as i can tell this is a regression
> introduced by 3bdf878, before that a call to pwm_config would call
> pwm_samsung_enable which, while heavy-handed, made sure the expected
> settings were live.
> 
> To resolve this, while not re-introducing the issues 3bdf878
> (flickering as the PWM got reset while in a PWM cycle). Only force an
> update of the settings when at 100% duty, which shouldn't have a
> noticeable effect on the output but is enough to ensure the behaviour
> is as expected on disable.
> 
> Signed-off-by: Sjoerd Simons 
> Signed-off-by: Anand Moon 
> ---
>  drivers/pwm/pwm-samsung.c | 31 ++-
>  1 file changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> index 3e9b583..649f6c4 100644
> --- a/drivers/pwm/pwm-samsung.c
> +++ b/drivers/pwm/pwm-samsung.c
> @@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct pwm_chip
> *chip, struct pwm_device *pwm)
> spin_unlock_irqrestore(&samsung_pwm_lock, flags); }
>  
> +static void pwm_samsung_manual_update(struct samsung_pwm_chip *chip,
> +   struct pwm_device *pwm)
> +{
> + unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
> + u32 tcon;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&samsung_pwm_lock, flags);
> +
> + tcon = readl(chip->base + REG_TCON);
> + tcon |= TCON_MANUALUPDATE(tcon_chan);
> + writel(tcon, chip->base + REG_TCON);
> +
> + tcon &= ~TCON_MANUALUPDATE(tcon_chan);
> + writel(tcon, chip->base + REG_TCON);
> +
> + spin_unlock_irqrestore(&samsung_pwm_lock, flags);
> +}
> +
>  static int pwm_samsung_config(struct pwm_chip *chip, struct
> pwm_device *pwm, int duty_ns, int period_ns)
>  {
>   struct samsung_pwm_chip *our_chip =
> to_samsung_pwm_chip(chip); struct samsung_pwm_channel *chan =
> pwm_get_chip_data(pwm);
> - u32 tin_ns = chan->tin_ns, tcnt, tcmp;
> + u32 tin_ns = chan->tin_ns, tcnt, tcmp, oldtcmp;
>  
>   /*
>* We currently avoid using 64bit arithmetic by using the
> @@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip
> *chip, struct pwm_device *pwm, return 0;
>  
>   tcnt = readl(our_chip->base + REG_TCNTB(pwm->hwpwm));
> + oldtcmp = readl(our_chip->base + REG_TCMPB(pwm->hwpwm));
>  
>   /* We need tick count for calculation, not last tick. */
>   ++tcnt;
> @@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip
> *chip, struct pwm_device *pwm, writel(tcnt, our_chip->base +
> REG_TCNTB(pwm->hwpwm)); writel(tcmp, our_chip->base +
> REG_TCMPB(pwm->hwpwm)); 
> + /* In case the PWM is currently at 100% duty, force a manual
> update

Cosmetic comment:

Wasn't checkpatch complaining about this comment style?
/* .
 * .

instead of:
/*
 * .
 * .

> +  * to prevent the signal staying high in the pwm is disabled
> shortly
> +  * afer this update (before it autoreloaded the new values) .
> +  */
> + if (oldtcmp == (u32) -1) {
> + dev_dbg(our_chip->chip.dev, "Forcing manual update");
> + pwm_samsung_manual_update(our_chip, pwm);
> + }
> +
>   chan->period_ns = period_ns;
>   chan->tin_ns = tin_ns;
>   chan->duty_ns = duty_ns;

Despite the above,

Acked-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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 10/17] IB/Verbs: Adopt management helpers for IB helpers

[Michael Wang]

Hi, Steve

Thanks for the comment :-)

On 04/07/2015 10:16 PM, Steve Wise wrote:
[snip]
>>>
>>> -   force_grh = rdma_port_get_link_layer(device, port_num) == 
>>> IB_LINK_LAYER_ETHERNET;
>>> +   force_grh = !rdma_transport_ib(device, port_num);
>>
>> Maybe these tests should be called cap_mandatory_grh - but I'm not
>> really sure how iWarp uses the GRH fields in the AH...
>>
> 
> iWARP runs on top of TCP...this SA code is all IB-specific.  The reason it 
> was checking for ETHERNET, I think, is for RoCE.So
> this change is totally incorrect,  I think,  because RoCE is an IB transport, 
> but it runs on ETHERNET.

I guess it's the name 'transport' which confusing folks... actually 
(!rdma_transport_ib)
including RoCE/IBoE, but yes, here it's for IBoE only, so let's change it to
rdma_transport_iboe ;-)

Regards,
Michael Wang

> 
> Steve.
> 
> 
> 
--
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/

linux-next: manual merge of the akpm-current tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
drivers/rtc/rtc-mc13xxx.c between commit 0307b0d77a08
("drivers/rtc/mc13xxx: Update driver to address y2038/y2106 issues")
from the tip tree and commit 219451fa4da4 ("drivers/rtc/rtc-mc13xxx.c:
fix obfuscated and wrong format string") from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/rtc/rtc-mc13xxx.c
index 32df1d812367,c8e78a560de7..
--- a/drivers/rtc/rtc-mc13xxx.c
+++ b/drivers/rtc/rtc-mc13xxx.c
@@@ -214,10 -215,12 +214,10 @@@ static int mc13xxx_rtc_set_alarm(struc
if (unlikely(ret))
goto out;
  
 -  ret = rtc_tm_to_time(&alarm->time, &s1970);
 -  if (unlikely(ret))
 -  goto out;
 +  s1970 = rtc_tm_to_time64(&alarm->time);
  
-   dev_dbg(dev, "%s: o%2.s %lld\n", __func__, alarm->enabled ? "n" : "ff",
 -  dev_dbg(dev, "%s: %s %lu\n", __func__, alarm->enabled ? "on" : "off",
 -  s1970);
++  dev_dbg(dev, "%s: %s %lld\n", __func__, alarm->enabled ? "on" : "off",
 +  (long long)s1970);
  
ret = mc13xxx_rtc_irq_enable_unlocked(dev, alarm->enabled,
MC13XXX_IRQ_TODA);


pgpnz5hebqbdV.pgp
Description: OpenPGP digital signature

[PATCH v2 1/2] ARM: at91/dt: sam9x5: add pinctrl for pwm0

[Gaël PORTAY]

Defines the pinctrl configurations for PWM0.

Signed-off-by: Gaël PORTAY 
---
 arch/arm/boot/dts/at91sam9x5.dtsi | 46 +++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi 
b/arch/arm/boot/dts/at91sam9x5.dtsi
index d221179..98977ad 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -694,6 +694,52 @@
};
};
 
+   pwm0 {
+   pinctrl_pwm0_pwm0_0: pwm0_pwm0-0 {
+   atmel,pins =
+   ;
+   };
+   pinctrl_pwm0_pwm0_1: pwm0_pwm0-1 {
+   atmel,pins =
+   ;
+   };
+   pinctrl_pwm0_pwm0_2: pwm0_pwm0-2 {
+   atmel,pins =
+   ;
+   };
+
+   pinctrl_pwm0_pwm1_0: pwm0_pwm1-0 {
+   atmel,pins =
+   ;
+   };
+   pinctrl_pwm0_pwm1_1: pwm0_pwm1-1 {
+   atmel,pins =
+   ;
+   };
+   pinctrl_pwm0_pwm1_2: pwm0_pwm1-2 {
+   atmel,pins =
+   ;
+   };
+
+   pinctrl_pwm0_pwm2_0: pwm0_pwm2-0 {
+   atmel,pins =
+   ;
+   };
+   pinctrl_pwm0_pwm2_1: pwm0_pwm2-1 {
+   atmel,pins =
+   ;
+   };
+
+   pinctrl_pwm0_pwm3_0: pwm0_pwm3-0 {
+   atmel,pins =
+   ;
+   };
+   pinctrl_pwm0_pwm3_1: pwm0_pwm3-1 {
+   atmel,pins =
+   ;
+   };
+   };
+
tcb0 {
pinctrl_tcb0_tclk0: tcb0_tclk0-0 {
atmel,pins = ;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 11/17] IB/Verbs: Reform link_layer_show() and ib_uverbs_query_port()

[Michael Wang]

On 04/07/2015 08:49 PM, Hefty, Sean wrote:
[snip]
>> @@ -515,8 +515,10 @@ ssize_t ib_uverbs_query_port(struct ib_uverbs_file
>> *file,
>>  resp.active_width= attr.active_width;
>>  resp.active_speed= attr.active_speed;
>>  resp.phys_state  = attr.phys_state;
>> -resp.link_layer  = rdma_port_get_link_layer(file->device-
>>> ib_dev,
>> -cmd.port_num);
>> +resp.link_layer  = rdma_transport_ib(file->device->ib_dev,
>> +cmd.port_num) ?
>> +   IB_LINK_LAYER_INFINIBAND :
>> +   IB_LINK_LAYER_ETHERNET;
>>
>>  if (copy_to_user((void __user *) (unsigned long) cmd.response,
>>   &resp, sizeof resp))
> 
> Both of the above check the transport in order to determine the link layer.
> 
> These values are exposed to user space.  Does anyone know what link layer 
> iWarp returns to user space? 

It should be ETH for IWARP according to the old logical :-)

Regards,
Michael Wang

> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 23/30] PCI/mvebu: Use pci_common_init_dev() to simplify code

[Yijing Wang]

> 2 months ago, Thomas Petazzoni was concerned about the removal of
> mvebu_pcie_scan_bus(). So I dig the archives of the discussion
> surrounding the pcie-mvebu drive. I found that the main purpose
> of using this function was to allow to pass "struct device *" pointer.
> 
> Thanks to the introduction of pci_common_init_dev it was not needed
> anymore. Actually we should have done this change when this function
> had been introduced. So for the point of view of the code it's fine.
> Then I tested your full series on Armada XP, Armada 375 and Armada 38x
> SoCs, and I didn't saw any regression. So you can add my:
> 
> Reviewed-by: Gregory CLEMENT 
> Tested-by: Gregory CLEMENT 

Great, thanks very much!

Thanks!
Yijing.


> 
> 
> 
>> Signed-off-by: Yijing Wang 
>> CC: Thomas Petazzoni 
>> CC: Jason Cooper 
>> ---
>>  drivers/pci/host/pci-mvebu.c |   18 +-
>>  1 files changed, 1 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
>> index 0cfc494..d5a2b70 100644
>> --- a/drivers/pci/host/pci-mvebu.c
>> +++ b/drivers/pci/host/pci-mvebu.c
>> @@ -750,21 +750,6 @@ static int mvebu_pcie_setup(int nr, struct pci_sys_data 
>> *sys)
>>  return 1;
>>  }
>>  
>> -static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
>> -{
>> -struct mvebu_pcie *pcie = sys_to_pcie(sys);
>> -struct pci_bus *bus;
>> -
>> -bus = pci_create_root_bus(&pcie->pdev->dev, -1, sys->busnr,
>> -  &mvebu_pcie_ops, sys, &sys->resources);
>> -if (!bus)
>> -return NULL;
>> -
>> -pci_scan_child_bus(bus);
>> -
>> -return bus;
>> -}
>> -
>>  static resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
>>   const struct resource *res,
>>   resource_size_t start,
>> @@ -808,12 +793,11 @@ static void mvebu_pcie_enable(struct mvebu_pcie *pcie)
>>  hw.nr_controllers = 1;
>>  hw.private_data   = (void **)&pcie;
>>  hw.setup  = mvebu_pcie_setup;
>> -hw.scan   = mvebu_pcie_scan_bus;
>>  hw.map_irq= of_irq_parse_and_map_pci;
>>  hw.ops= &mvebu_pcie_ops;
>>  hw.align_resource = mvebu_pcie_align_resource;
>>  
>> -pci_common_init(&hw);
>> +pci_common_init_dev(&pcie->pdev->dev, &hw);
>>  }
>>  
>>  /*
>>
> 
> 


-- 
Thanks!
Yijing

--
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/

Kernel 3.18.11 hangs when inserting netconsle module on a DELL M620 VRTX Blade

[Urban Loesch]

Hi,

I'have installed a new DELL VRTX M620 Blade with kernel 3.18.11.
After system startup I tried to activate the kernel netconsole with remote 
logging enabled.

I executed the following command and the shell I issued it becomes unresponsive 
and hangs.

#  modprobe netconsole netconsole="@/eth0,514@10.1.10.197/00:10:db:fc:60:0c"

The system load increases slowly and the CPU #11 uses 100% of soft irq. Only a 
soft reset
witohut loading the netconsole module after startup solves the issue.

# mpstat -P 11
09:23:52 CPU%usr   %nice%sys %iowait%irq   %soft  %steal  
%guest   %idle
09:23:53  110,000,000,000,000,00  100,000,00
0,000,00


I found the following error in the kernel log:

...
Apr  8 09:22:27 server2 kernel: [  216.788670] [ cut here 
]
Apr  8 09:22:27 server2 kernel: [  216.788676] WARNING: CPU: 11 PID: 2929 at 
kernel/softirq.c:147 __local_bh_enable_ip+0x72/0xa0()
Apr  8 09:22:27 server2 kernel: [  216.788687] CPU: 11 PID: 2929 Comm: modprobe 
Not tainted 3.18.11-em64t-efigpt #1
Apr  8 09:22:27 server2 kernel: [  216.788688] Hardware name: Dell Inc. 
PowerEdge M620/0NJVT7, BIOS 2.4.3 07/02/2014
Apr  8 09:22:27 server2 kernel: [  216.788690]  0009 
881fcfaa39e8 8174434a 19af19af
Apr  8 09:22:27 server2 kernel: [  216.788690]   
881fcfaa3a28 81051fac 81f4a080
Apr  8 09:22:27 server2 kernel: [  216.788691]  0200 
881fcf624dd4 881fcf624d58 
Apr  8 09:22:27 server2 kernel: [  216.788692] Call Trace:
Apr  8 09:22:27 server2 kernel: [  216.788696]  [] 
dump_stack+0x46/0x58
Apr  8 09:22:27 server2 kernel: [  216.788698]  [] 
warn_slowpath_common+0x8c/0xc0
Apr  8 09:22:27 server2 kernel: [  216.788699]  [] 
warn_slowpath_null+0x1a/0x20
Apr  8 09:22:27 server2 kernel: [  216.788701]  [] 
__local_bh_enable_ip+0x72/0xa0
Apr  8 09:22:27 server2 kernel: [  216.788704]  [] 
_raw_spin_unlock_bh+0x1b/0x20
Apr  8 09:22:27 server2 kernel: [  216.788716]  [] 
bnx2x_poll+0x83/0x3e0 [bnx2x]
Apr  8 09:22:27 server2 kernel: [  216.788720]  [] 
netpoll_poll_dev+0x110/0x1b0
Apr  8 09:22:27 server2 kernel: [  216.788721]  [] 
netpoll_send_skb_on_dev+0x167/0x240
Apr  8 09:22:27 server2 kernel: [  216.788722]  [] 
netpoll_send_udp+0x2d2/0x400
Apr  8 09:22:27 server2 kernel: [  216.788724]  [] 
write_msg+0xcf/0x110 [netconsole]
Apr  8 09:22:27 server2 kernel: [  216.788728]  [] 
call_console_drivers.constprop.27+0x9b/0x100
Apr  8 09:22:27 server2 kernel: [  216.788730]  [] 
console_unlock+0x3ca/0x450
Apr  8 09:22:27 server2 kernel: [  216.788731]  [] 
register_console+0x29a/0x360
Apr  8 09:22:27 server2 kernel: [  216.788733]  [] ? 
0xa0191000
Apr  8 09:22:27 server2 kernel: [  216.788735]  [] 
init_netconsole+0x1c5/0x1000 [netconsole]
Apr  8 09:22:27 server2 kernel: [  216.788737]  [] 
do_one_initcall+0x8c/0x1c0
Apr  8 09:22:27 server2 kernel: [  216.788740]  [] ? 
__vunmap+0xc2/0x110
Apr  8 09:22:27 server2 kernel: [  216.788743]  [] 
load_module+0x1dbd/0x25b0
Apr  8 09:22:27 server2 kernel: [  216.788744]  [] ? 
show_initstate+0x60/0x60
Apr  8 09:22:27 server2 kernel: [  216.788746]  [] ? 
page_fault+0x1f/0x30
Apr  8 09:22:27 server2 kernel: [  216.788747]  [] 
SyS_init_module+0x9a/0xc0
Apr  8 09:22:27 server2 kernel: [  216.788749]  [] 
system_call_fastpath+0x12/0x17
Apr  8 09:22:27 server2 kernel: [  216.788750] ---[ end trace 224709e18793096d 
]---
...

I installed the latest firmware driver from DELL for the Broadcom Nic's. Same 
problem
and I don't know if there is only affected the netconsole module or something 
else.

Linked modules are:
#  lsmod
Module  Size  Used by
netconsole 23883  1
configfs   30744  2 netconsole
iTCO_wdt   13480  0
iTCO_vendor_support13718  1 iTCO_wdt
ipmi_si53458  0
ipmi_msghandler45284  1 ipmi_si
tpm_tis18227  0
tpm35790  1 tpm_tis
sb_edac26792  0
lpc_ich21093  0
edac_core  57597  1 sb_edac
dcdbas 14478  0
shpchp 37047  0
pcspkr 12718  0
joydev 17389  0
hed13247  0
acpi_pad   17942  0
evbug  12672  0
hid_generic12559  0
usbkbd 12926  0
usbmouse   12789  0
usbhid 46465  0
hid   110129  2 hid_generic,usbhid
ahci   34019  0
libahci32177  1 ahci
bnx2x 726130  0
ptp19445  1 bnx2x
megaraid_sas  113654  3
pps_core   14386  1 ptp
mdio   13561  1 bnx2x


The system runs with 256GB RAM:
#  free -m
 total   used   free sharedbuffers cached
Mem:257918   1834 256084  0 19 44
-/+ buffers/cache:   1770 

[PATCH v2] ARM: at91/dt: add support for kizbox2

[Gaël PORTAY]

Add DT file for Kizbox 2 board.
This board is based on Atmel's SAMA5D31 Cortex-A5 SoC.

Signed-off-by: Gaël PORTAY 
Acked-by: Boris Brezillon 
---
Changes since v1:
- drop ek boards from compatible machine
- drop useless pmc node

 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/at91-kizbox2.dts | 217 +
 2 files changed, 218 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-kizbox2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c11888..d2b559d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -37,6 +37,7 @@ dtb-$(CONFIG_SOC_SAM_V4_V5) += \
at91sam9x25ek.dtb \
at91sam9x35ek.dtb
 dtb-$(CONFIG_SOC_SAM_V7) += \
+   at91-kizbox2.dtb \
at91-sama5d3_xplained.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
diff --git a/arch/arm/boot/dts/at91-kizbox2.dts 
b/arch/arm/boot/dts/at91-kizbox2.dts
new file mode 100644
index 000..3f52835
--- /dev/null
+++ b/arch/arm/boot/dts/at91-kizbox2.dts
@@ -0,0 +1,217 @@
+/*
+ * at91-kizbox2.dts - Device Tree file for Overkiz Kizbox 2 board
+ *
+ * Copyright (C) 2014 Gaël PORTAY 
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include "sama5d31.dtsi"
+#include "sama5d3_emac.dtsi"
+#include 
+
+/ {
+   model = "Overkiz Kizbox 2";
+   compatible = "overkiz,kizbox2", "atmel,sama5d31", "atmel,sama5d3", 
"atmel,sama5";
+
+   chosen {
+   bootargs = "ubi.mtd=ubi";
+   linux,stdout-path = &dbgu;
+   };
+
+   memory {
+   reg = <0x2000 0x1000>;
+   };
+
+   clocks {
+   slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal {
+   clock-frequency = <1200>;
+   };
+   };
+
+   ahb {
+   apb {
+   i2c1: i2c@f0018000 {
+   status = "okay";
+
+   pmic: act8865@5b {
+   compatible = "active-semi,act8865";
+   reg = <0x5b>;
+   status = "okay";
+
+   regulators {
+   vcc_1v8_reg: DCDC_REG1 {
+   regulator-name = 
"VCC_1V8";
+   regulator-min-microvolt 
= <180>;
+   regulator-max-microvolt 
= <180>;
+   regulator-always-on;
+   };
+
+   vcc_1v2_reg: DCDC_REG2 {
+   regulator-name = 
"VCC_1V2";
+   regulator-min-microvolt 
= <120>;
+   regulator-max-microvolt 
= <120>;
+   regulator-always-on;
+   };
+
+   vcc_3v3_reg: DCDC_REG3 {
+   regulator-name = 
"VCC_3V3";
+   regulator-min-microvolt 
= <330>;
+   regulator-max-microvolt 
= <330>;
+   regulator-always-on;
+   };
+
+   vddfuse_reg: LDO_REG1 {
+   regulator-name = 
"FUSE_2V5";
+   regulator-min-microvolt 
= <250>;
+   regulator-max-microvolt 
= <250>;
+   };
+
+   vddana_reg: LDO_REG2 {
+   regulator-name = 
"VDDANA";
+   regulator-min-microvolt 
= <330>;
+   regulator-max-microvolt 
= <330>;
+   regulator-always-on;
+   };
+
+   vled_reg: LDO_REG3 {
+   regulator-name = "VLED";
+   regulator-min-microvolt 
= <330>;
+   regulator-max-microvolt 
= <330>;
+   regulator-always-on;
+  

Re: [RESEND PATCH 4.0-rc5 v19 6/6] ARM: Add support for on-demand backtrace of other CPUs

[Hillf Danton]

> 
> +void ipi_cpu_backtrace(struct pt_regs *regs)
> +{
> + int cpu = smp_processor_id();
> +
> + if (cpumask_test_cpu(cpu, to_cpumask(backtrace_mask))) {
> + printk_nmi_backtrace_this_cpu_begin();
> + pr_warn("FIQ backtrace for cpu %d\n", cpu);
> + if (regs != NULL)
> + show_regs(regs);
> + else
> + dump_stack();

Help more if we could print both register and stack info.

> + printk_nmi_backtrace_this_cpu_end();
> +
> + cpumask_clear_cpu(cpu, to_cpumask(backtrace_mask));
> + }
> +}



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 03/30] PCI: Save domain in pci_host_bridge

[Yijing Wang]

On 2015/4/8 16:09, Gregory CLEMENT wrote:
> Hi Yijing,
> 
> On 03/04/2015 11:25, Yijing Wang wrote:
>> Save domain in pci_host_bridge, so we could get domain
>> from pci_host_bridge, and at the end of series, we could
>> clean up the arch specific pci_domain_nr(). For arm,
>> we pass -1 as the domain number, we would update the
>> domain number in core by pci_bus_assign_domain_nr().
>>
> For the mvebu part I tested on Armada XP, Armada 375 and Armada 38x
> SoCs, and I didn't saw any regression. So you can add my:
> 
> Tested-by: Gregory CLEMENT 

Thanks a lot for your test!

Thanks!
Yijing.


>>
> 
> 


-- 
Thanks!
Yijing

--
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] clk: qcom: Fix parent_map translations

[Nicolas Dechesne]

On Tue, Apr 7, 2015 at 4:14 PM, Georgi Djakov  wrote:
> When we introduced the parent_map tables, we missed to update some
> of the functions where mapping is translated. Fix this.
>
> Signed-off-by: Georgi Djakov 
> ---
>
> Changes since v1:
>  * Pass parent map to _freq_tbl_determine_rate()

tested this v2 as well, on ifc6410, I have done the same functional
tests as mentioned in [1].

Tested-by: Nicolas Dechesne 

[1] https://lkml.org/lkml/2015/4/3/298
--
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 13/17] IB/Verbs: Reform cma/ucma with management helpers

[Michael Wang]

On 04/07/2015 11:11 PM, Steve Wise wrote:
[snip]
>> @@ -1006,17 +997,14 @@ static void cma_leave_mc_groups(struct 
>> rdma_id_private *id_priv)
>>  mc = container_of(id_priv->mc_list.next,
>>struct cma_multicast, list);
>>  list_del(&mc->list);
>> -switch (rdma_port_get_link_layer(id_priv->cma_dev->device, 
>> id_priv->id.port_num)) {
>> -case IB_LINK_LAYER_INFINIBAND:
>> +if (rdma_transport_ib(id_priv->cma_dev->device,
>> +  id_priv->id.port_num)) {
>>  ib_sa_free_multicast(mc->multicast.ib);
>>  kfree(mc);
>>  break;
>> -case IB_LINK_LAYER_ETHERNET:
>> +} else if (rdma_transport_ib(id_priv->cma_dev->device,
>> + id_priv->id.port_num))
>>  kref_put(&mc->mcref, release_mc);
>> -break;
>> -default:
>> -break;
>> -}
>>  }
>>  }
>>
> 
> Doesn't the above change result in:
> 
> if (rdma_transport_ib()) {
> } else if (rdma_transport_ib()) {
> }
>  

My bad here.. I guess 'else' is enough.

Regards,
Michael Wang

> 
> 
>> @@ -1037,17 +1025,13 @@ void rdma_destroy_id(struct rdma_cm_id *id)
>>  mutex_unlock(&id_priv->handler_mutex);
>>
>>  if (id_priv->cma_dev) {
>> -switch (rdma_node_get_transport(id_priv->id.device->node_type)) 
>> {
>> -case RDMA_TRANSPORT_IB:
>> +if (rdma_ib_mgmt(id_priv->id.device, id_priv->id.port_num)) {
>>  if (id_priv->cm_id.ib)
>>  ib_destroy_cm_id(id_priv->cm_id.ib);
>> -break;
>> -case RDMA_TRANSPORT_IWARP:
>> +} else if (rdma_transport_iwarp(id_priv->id.device,
>> +id_priv->id.port_num)) {
>>  if (id_priv->cm_id.iw)
>>  iw_destroy_cm_id(id_priv->cm_id.iw);
>> -break;
>> -default:
>> -break;
>>  }
>>  cma_leave_mc_groups(id_priv);
>>  cma_release_dev(id_priv);
>> @@ -1966,26 +1950,14 @@ int rdma_resolve_route(struct rdma_cm_id *id, int 
>> timeout_ms)
>>  return -EINVAL;
>>
>>  atomic_inc(&id_priv->refcount);
>> -switch (rdma_node_get_transport(id->device->node_type)) {
>> -case RDMA_TRANSPORT_IB:
>> -switch (rdma_port_get_link_layer(id->device, id->port_num)) {
>> -case IB_LINK_LAYER_INFINIBAND:
>> -ret = cma_resolve_ib_route(id_priv, timeout_ms);
>> -break;
>> -case IB_LINK_LAYER_ETHERNET:
>> -ret = cma_resolve_iboe_route(id_priv);
>> -break;
>> -default:
>> -ret = -ENOSYS;
>> -}
>> -break;
>> -case RDMA_TRANSPORT_IWARP:
>> +if (rdma_transport_ib(id->device, id->port_num))
>> +ret = cma_resolve_ib_route(id_priv, timeout_ms);
>> +else if (rdma_transport_iboe(id->device, id->port_num))
>> +ret = cma_resolve_iboe_route(id_priv);
>> +else if (rdma_transport_iwarp(id->device, id->port_num))
>>  ret = cma_resolve_iw_route(id_priv, timeout_ms);
>> -break;
>> -default:
>> +else
>>  ret = -ENOSYS;
>> -break;
>> -}
>>  if (ret)
>>  goto err;
>>
>> @@ -2059,7 +2031,7 @@ port_found:
>>  goto out;
>>
>>  id_priv->id.route.addr.dev_addr.dev_type =
>> -(rdma_port_get_link_layer(cma_dev->device, p) == 
>> IB_LINK_LAYER_INFINIBAND) ?
>> +(rdma_transport_ib(cma_dev->device, p)) ?
>>  ARPHRD_INFINIBAND : ARPHRD_ETHER;
>>
>>  rdma_addr_set_sgid(&id_priv->id.route.addr.dev_addr, &gid);
>> @@ -2536,18 +2508,15 @@ int rdma_listen(struct rdma_cm_id *id, int backlog)
>>
>>  id_priv->backlog = backlog;
>>  if (id->device) {
>> -switch (rdma_node_get_transport(id->device->node_type)) {
>> -case RDMA_TRANSPORT_IB:
>> +if (rdma_ib_mgmt(id->device, id->port_num)) {
>>  ret = cma_ib_listen(id_priv);
>>  if (ret)
>>  goto err;
>> -break;
>> -case RDMA_TRANSPORT_IWARP:
>> +} else if (rdma_transport_iwarp(id->device, id->port_num)) {
>>  ret = cma_iw_listen(id_priv, backlog);
>>  if (ret)
>>  goto err;
>> -break;
>> -default:
>> +} else {
>>  ret = -ENOSYS;
>>  goto err;
>>  }
>> @@ -2883,20 +2852,15 @@ int rdma_connect(struct rdma_cm_id *id, struct 
>> rdma_conn_param *conn_param)
>>  

Re: [PATCH] Documentation/memory-barriers.txt: typo fix

[Jonathan Corbet]

On Wed, 8 Apr 2015 10:27:57 +0200
"Michael S. Tsirkin"  wrote:

> Fix an obvious typo in the documentation.

Makes sense, applied to the docs tree.

Thanks,

jon
--
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 02/17] IB/Verbs: Implement raw management helpers

[Michael Wang]

On 04/07/2015 11:25 PM, Hefty, Sean wrote:
>> +static inline int rdma_transport_ib(struct ib_device *device, u8
>> port_num)
>> +{
>> +return device->query_transport(device, port_num)
>> +== RDMA_TRANSPORT_IB;
>> +}
>> +
>> +static inline int rdma_transport_iboe(struct ib_device *device, u8
>> port_num)
>> +{
>> +return device->query_transport(device, port_num)
>> +== RDMA_TRANSPORT_IBOE;
>> +}
> 
> We need to do something with the function names to make their use more 
> obvious.  Both IB and IBoE have transport IB.  I think Jason suggested 
> rdma_tech_ib / rdma_tech_iboe.
> 
> Regarding transport types, I believe that usnic supports 2 different 
> transports.  Although usnic isn't used by anything else in the core layer, we 
> should probably be able to handle a device that supports multiple protocols.  
> I'm not sure what the 'transport' should be for iWarp, since iWarp is layered 
> over TCP.  But that may just mean that the term transport isn't great.

Agree, it do confusing folks, I will use tech instead in next version :-)

Regards,
Michael Wang

> 
> - Sean
> 
--
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 5/6] pwm: samsung: Fix output race on disabling

[Sjoerd Simons]

On Wed, 2015-04-08 at 10:28 +0200, Lukasz Majewski wrote:
> Hi Anand,
> 
> > From: Sjoerd Simons 
> > When disabling the samsung PWM the output state remains at the level
> > it was in the end of a pwm cycle. In other words, calling pwm_disable
> > when at 100% duty will keep the output active, while at all other
> > setting the output will go/stay inactive. On top of that the samsung
> > PWM settings are double-buffered, which means the new settings only
> > get applied at the start of a new PWM cycle.

This patch is already in the linux-pwm for-next tree so should probably
be dropped form this patchset to prevent conflicts.

-- 
Sjoerd Simons 
Collabora Ltd.
--
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] virtio_ring: Update weak barriers to use dma_wmb/rmb

[Michael S. Tsirkin]

On Tue, Apr 07, 2015 at 05:47:42PM -0700, Alexander Duyck wrote:
> This change makes it so that instead of using smp_wmb/rmb which varies
> depending on the kernel configuration we can can use dma_wmb/rmb which for
> most architectures should be equal to or slightly more strict than
> smp_wmb/rmb.
> 
> The advantage to this is that these barriers are available to uniprocessor
> builds as well so the performance should improve under such a
> configuration.
> 
> Signed-off-by: Alexander Duyck 

Well the generic implementation has:
#ifndef dma_rmb
#define dma_rmb()   rmb()
#endif

#ifndef dma_wmb
#define dma_wmb()   wmb()
#endif

So for these arches you are slightly speeding up UP but slightly hurting SMP -
I think we did benchmark the difference as measureable in the past.

Additionally, isn't this relying on undocumented behaviour?
The documentation says:
"These are for use with consistent memory"
and virtio does not bother to request consistent memory
allocations.

One wonders whether these will always be strong enough.



> ---
>  include/linux/virtio_ring.h |   23 ---
>  1 file changed, 4 insertions(+), 19 deletions(-)
> 
> diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
> index 67e06fe18c03..8e50888a6d59 100644
> --- a/include/linux/virtio_ring.h
> +++ b/include/linux/virtio_ring.h
> @@ -21,19 +21,20 @@
>   * actually quite cheap.
>   */
>  
> -#ifdef CONFIG_SMP
>  static inline void virtio_mb(bool weak_barriers)
>  {
> +#ifdef CONFIG_SMP
>   if (weak_barriers)
>   smp_mb();
>   else
> +#endif
>   mb();
>  }
>  
>  static inline void virtio_rmb(bool weak_barriers)
>  {
>   if (weak_barriers)
> - smp_rmb();
> + dma_rmb();
>   else
>   rmb();
>  }
> @@ -41,26 +42,10 @@ static inline void virtio_rmb(bool weak_barriers)
>  static inline void virtio_wmb(bool weak_barriers)
>  {
>   if (weak_barriers)
> - smp_wmb();
> + dma_wmb();
>   else
>   wmb();
>  }
> -#else
> -static inline void virtio_mb(bool weak_barriers)
> -{
> - mb();
> -}
> -
> -static inline void virtio_rmb(bool weak_barriers)
> -{
> - rmb();
> -}
> -
> -static inline void virtio_wmb(bool weak_barriers)
> -{
> - wmb();
> -}
> -#endif
>  
>  struct virtio_device;
>  struct virtqueue;
--
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 6/6] hwmon: pwm-fan: Update the duty cycle inorder to control the pwm-fan

[Lukasz Majewski]

Hi Anand,

> Below changes depend on following patch.
> https://patchwork.kernel.org/patch/5944061/
> 
> Update the pwm_config with duty then update the pwm_disable
> to poweroff the cpu fan.
> 
> Tested on OdroidXU3 board.
> 
> Signed-off-by: Anand Moon 
> ---
>  drivers/hwmon/pwm-fan.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> index 7c83dc4..f25c841 100644
> --- a/drivers/hwmon/pwm-fan.c
> +++ b/drivers/hwmon/pwm-fan.c
> @@ -44,26 +44,24 @@ static int  __set_pwm(struct pwm_fan_ctx *ctx,
> unsigned long pwm) int ret = 0;
>  
>   mutex_lock(&ctx->lock);
> +
>   if (ctx->pwm_value == pwm)
>   goto exit_set_pwm_err;
>  
> - if (pwm == 0) {
> - pwm_disable(ctx->pwm);
> - goto exit_set_pwm;
> - }
> -
>   duty = DIV_ROUND_UP(pwm * (ctx->pwm->period - 1), MAX_PWM);
>   ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
>   if (ret)
>   goto exit_set_pwm_err;
>  
> + if (pwm == 0)
> + pwm_disable(ctx->pwm);
> +
>   if (ctx->pwm_value == 0) {
>   ret = pwm_enable(ctx->pwm);
>   if (ret)
>   goto exit_set_pwm_err;
>   }
>  
> -exit_set_pwm:
>   ctx->pwm_value = pwm;
>  exit_set_pwm_err:
>   mutex_unlock(&ctx->lock);

Reviewed-by: Lukasz Majewski 

BTW: I've added Guenter to CC.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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] kvm: x86: fix x86 eflags fixed bit

[Paolo Bonzini]

On 08/04/2015 08:08, Wanpeng Li wrote:
> Guest can't be booted w/ ept=0, there is a message dumped as below:
> 
> If you're running a guest on an Intel machine without unrestricted mode
> support, the failure can be most likely due to the guest entering an invalid
> state for Intel VT. For example, the guest maybe running in big real mode
> which is not supported on less recent Intel processors.
> 
> EAX=0011 EBX=f000d2f6 ECX=6cac EDX=000f8956
> ESI=bffbdf62 EDI= EBP=6c68 ESP=6c68
> EIP=d187 EFL=0004 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =e000 000e  00809300 DPL=0 DS16 [-WA]
> CS =f000 000f  00809b00 DPL=0 CS16 [-RA]
> SS =   00809300 DPL=0 DS16 [-WA]
> DS =   00809300 DPL=0 DS16 [-WA]
> FS =   00809300 DPL=0 DS16 [-WA]
> GS =   00809300 DPL=0 DS16 [-WA]
> LDT=   8200 DPL=0 LDT
> TR =   8b00 DPL=0 TSS32-busy
> GDT= 000f6a80 0037
> IDT= 000f6abe 
> CR0=0011 CR2= CR3= CR4=
> DR0= DR1= DR2= 
> DR3= 
> DR6=0ff0 DR7=0400
> EFER=
> Code=01 1e b8 6a 2e 0f 01 16 74 6a 0f 20 c0 66 83 c8 01 0f 22 c0 <66> ea 8f 
> d1 0f 00 08 00 b8 10 00 00 00 8e d8 8e c0 8e d0 8e e0 8e e8 89 c8 ff e2 89 c1 
> b8X
> 
> X86 eflags bit 1 is fixed set, which means that 1 << 1 is set instead of 1, 
> this patch fix it.
> 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/emulate.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index b304728..630bcb0 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -2033,7 +2033,7 @@ static int emulate_iret_real(struct x86_emulate_ctxt 
> *ctxt)
>X86_EFLAGS_IF | X86_EFLAGS_DF | X86_EFLAGS_OF |
>X86_EFLAGS_IOPL | X86_EFLAGS_NT | X86_EFLAGS_RF |
>X86_EFLAGS_AC | X86_EFLAGS_ID |
> -  X86_EFLAGS_FIXED_BIT;
> +  X86_EFLAGS_FIXED;
>   unsigned long vm86_mask = X86_EFLAGS_VM | X86_EFLAGS_VIF |
> X86_EFLAGS_VIP;
>  
> @@ -2072,7 +2072,7 @@ static int emulate_iret_real(struct x86_emulate_ctxt 
> *ctxt)
>   }
>  
>   ctxt->eflags &= ~EFLG_RESERVED_ZEROS_MASK; /* Clear reserved zeros */
> - ctxt->eflags |= X86_EFLAGS_FIXED_BIT;
> + ctxt->eflags |= X86_EFLAGS_FIXED;
>   ctxt->ops->set_nmi_mask(ctxt, false);
>  
>   return rc;
> @@ -2390,7 +2390,7 @@ static int em_syscall(struct x86_emulate_ctxt *ctxt)
>  
>   ops->get_msr(ctxt, MSR_SYSCALL_MASK, &msr_data);
>   ctxt->eflags &= ~msr_data;
> - ctxt->eflags |= X86_EFLAGS_FIXED_BIT;
> + ctxt->eflags |= X86_EFLAGS_FIXED;
>  #endif
>   } else {
>   /* legacy mode */
> 

Thanks Wanpeng.  Applied.

Paolo
--
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 5/7] sched/deadline: drop duplicate init_sched_dl_class declaration

[Juri Lelli]

Hi,

On 06/04/2015 09:53, Wanpeng Li wrote:
> There are two init_sched_dl_class declarations, this patch drop the 
> duplicated one.
> 

I guess the changelog needs to be trimmed. Apart from this, the
patch looks of course good, thanks!

Best,

- Juri

> Signed-off-by: Wanpeng Li 
> ---
>  kernel/sched/sched.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index e0e1299..c9b2689 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1284,7 +1284,6 @@ extern void update_max_interval(void);
>  extern void init_sched_dl_class(void);
>  extern void init_sched_rt_class(void);
>  extern void init_sched_fair_class(void);
> -extern void init_sched_dl_class(void);
>  
>  extern void resched_curr(struct rq *rq);
>  extern void resched_cpu(int cpu);
> 

--
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] KVM: dirty all pages in kvm_write_guest_cached()

[Paolo Bonzini]

On 07/04/2015 22:34, Radim Krčmář wrote:
> We dirtied only one page because writes originally couldn't span more.
> Use improved syntax for '>> PAGE_SHIFT' while at it.
> 
> Fixes: 8f964525a121 ("KVM: Allow cross page reads and writes from cached 
> translations.")
> Signed-off-by: Radim Krčmář 

Cross-page reads and writes should never get here; they have
ghc->memslot set to NULL and go through the slow path in kvm_write_guest.

What am I missing?

Paolo

> ---
>  The function handles cross memslot writes in a different path.
> 
>  I think we should dirty pages after partial writes too (r < len),
>  but it probably won't happen and I already started refactoring :)
> 
>  virt/kvm/kvm_main.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index aadef264bed1..863df9dcab6f 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1665,6 +1665,7 @@ int kvm_write_guest_cached(struct kvm *kvm, struct 
> gfn_to_hva_cache *ghc,
>  {
>   struct kvm_memslots *slots = kvm_memslots(kvm);
>   int r;
> + gfn_t gfn;
>  
>   BUG_ON(len > ghc->len);
>  
> @@ -1680,7 +1681,10 @@ int kvm_write_guest_cached(struct kvm *kvm, struct 
> gfn_to_hva_cache *ghc,
>   r = __copy_to_user((void __user *)ghc->hva, data, len);
>   if (r)
>   return -EFAULT;
> - mark_page_dirty_in_slot(kvm, ghc->memslot, ghc->gpa >> PAGE_SHIFT);
> +
> + for (gfn =  gpa_to_gfn(ghc->gpa);
> +  gfn <= gpa_to_gfn(ghc->gpa + len - 1); gfn++)
> + mark_page_dirty_in_slot(kvm, ghc->memslot, gfn);
>  
>   return 0;
>  }
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/cpu/common.c between commit 6b51311c9765
("x86/asm/entry/64: Use a define for an invalid segment selector") from
the tip tree and commit f28c11e4b695 ("arch/x86/kernel/cpu/common.c:
fix warning") from the akpm tree.

I fixed it up (I just used the tip tree version) and can carry the fix
as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpasDU5NXrOP.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997!

[Thomas Gleixner]

On Tue, 7 Apr 2015, Thavatchai Makphaibulchoke wrote:
> On 04/06/2015 07:59 PM, Steven Rostedt wrote:
> In this case we are not actually boosting the idle_task priority, which
> should be OK.  But the warning could be very overwhelming on some
> platforms. TO keep the warning, I decided not to boots priority.  Please
> let me know if you have any suggestion.

Don't even try to get this working. Taking the lock in idle/interrupt
context is just plain wrong.

The proper solution is to get rid of the locking requirement and that
needs some thought on the timer wheel code.

Thanks,

tglx
--
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 09/17] IB/Verbs: Use helper cap_read_multi_sge() and reform svc_rdma_accept()

[Michael Wang]

On 04/07/2015 07:42 PM, Jason Gunthorpe wrote:
[snip]
>>> @@ -992,8 +992,8 @@ static struct svc_xprt *svc_rdma_accept(struct svc_xprt 
>>> *xprt)
>>> dma_mr_acc = IB_ACCESS_LOCAL_WRITE;
>>> } else
>>> need_dma_mr = 0;
>>> -   break;
>>> -   case RDMA_TRANSPORT_IB:
>>> +   } else if (rdma_ib_mgmt(newxprt->sc_cm_id->device,
>>> +   newxprt->sc_cm_id->port_num)) {
>>> if (!(newxprt->sc_dev_caps & SVCRDMA_DEVCAP_FAST_REG)) {
>>> need_dma_mr = 1;
>>> dma_mr_acc = IB_ACCESS_LOCAL_WRITE;
>>
>> Now I'm even more confused. How is the presence of IB management
>> related to needing a privileged lmr?
> 
> Agree, this needs to be someone else. 
> 
> I think the test is probably based on this comment:
> 
> * NB:  iWARP requires remote write access for the data sink
> *  of an RDMA_READ. IB does not.
> 
> So the if should be:
> 
>   if (cap_rdma_read_needs_write(..) && 
> !(newxprt->sc_dev_caps & SVCRDMA_DEVCAP_FAST_REG)) {
>need_dma_mr = 1;
>dma_mr_acc =
>(IB_ACCESS_LOCAL_WRITE |
> IB_ACCESS_REMOTE_WRITE);
> 
> And the identical if blocks merged.
> 
> Plus the
>   if (rdma_transport_iwarp(newxprt->sc_cm_id->device,
>newxprt->sc_cm_id->port_num))
>   newxprt->sc_dev_caps |= SVCRDMA_DEVCAP_READ_W_INV

Sounds good :-) I'll give this part a reform in next version.

Regards,
Michael Wang

> 
> Jason
> 
--
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 5/7] sched/deadline: drop duplicate init_sched_dl_class declaration

[Wanpeng Li]

Hi Juri,
On Wed, Apr 08, 2015 at 09:47:33AM +0100, Juri Lelli wrote:
>Hi,
>
>On 06/04/2015 09:53, Wanpeng Li wrote:
>> There are two init_sched_dl_class declarations, this patch drop the 
>> duplicated one.
>> 
>
>I guess the changelog needs to be trimmed. Apart from this, the

Will do in v2, thanks for your review. :)

Regards,
Wanpeng Li 

>patch looks of course good, thanks!
>
>Best,
>
>- Juri
>
>> Signed-off-by: Wanpeng Li 
>> ---
>>  kernel/sched/sched.h | 1 -
>>  1 file changed, 1 deletion(-)
>> 
>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
>> index e0e1299..c9b2689 100644
>> --- a/kernel/sched/sched.h
>> +++ b/kernel/sched/sched.h
>> @@ -1284,7 +1284,6 @@ extern void update_max_interval(void);
>>  extern void init_sched_dl_class(void);
>>  extern void init_sched_rt_class(void);
>>  extern void init_sched_fair_class(void);
>> -extern void init_sched_dl_class(void);
>>  
>>  extern void resched_curr(struct rq *rq);
>>  extern void resched_cpu(int cpu);
>> 
--
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/1] ASoC: max98090: add shutdown callback for max98090

[Caesar Wang]

Tested on veyron devices,play music then shutdown device,here carefully
to speaker or headphone.



Caesar Wang (1):
  ASoC: max98090: add shutdown callback for max98090

 sound/soc/codecs/max98090.c | 17 +
 1 file changed, 17 insertions(+)

-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] pwm: samsung: Fix output race on disabling

[Anand Moon]

Hi Sjoerd,

Correct. Will do so. I just included in this series. As it relevant to
my changes and testing.

-Anand Moon

On 8 April 2015 at 14:12, Sjoerd Simons  wrote:
>
>
> On Wed, 2015-04-08 at 10:28 +0200, Lukasz Majewski wrote:
>> Hi Anand,
>>
>> > From: Sjoerd Simons 
>> > When disabling the samsung PWM the output state remains at the level
>> > it was in the end of a pwm cycle. In other words, calling pwm_disable
>> > when at 100% duty will keep the output active, while at all other
>> > setting the output will go/stay inactive. On top of that the samsung
>> > PWM settings are double-buffered, which means the new settings only
>> > get applied at the start of a new PWM cycle.
>
> This patch is already in the linux-pwm for-next tree so should probably
> be dropped form this patchset to prevent conflicts.
>
> --
> Sjoerd Simons 
> Collabora Ltd.
--
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] scripts/checkpatch: check for uses of trace_printk

[Juri Lelli]

Production kernels will scream if trace_printk() is used (thanks to
Steve's banner). Rather than waiting for that to happen, let's check
patches beforehand.

Signed-off-by: Juri Lelli 
Cc: Andy Whitcroft 
Cc: Joe Perches 
Cc: Steven Rostedt 
Cc: Juri Lelli 
Cc: linux-kernel@vger.kernel.org
---
Changes since v1:

 o added an exception when the code is in kernel/trace/, as suggested
   by Steve and Joe;

 scripts/checkpatch.pl | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d124359..c36b2b7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3257,6 +3257,13 @@ sub process {
 "Prefer printk_ratelimited or 
pr__ratelimited to printk_ratelimit\n" . $herecurr);
}
 
+# check for uses of trace_printk
+   if ($realfile !~ m@kernel/trace/@ &&
+   $line =~ /\btrace_printk\s*\(/) {
+   ERROR("TRACE_PRINTK",
+ "Never use trace_printk in production code!\n" . 
$herecurr);
+   }
+
 # printk should use KERN_* levels.  Note that follow on printk's on the
 # same line do not need a level, so we use the current block context
 # to try and find and validate the current printk.  In summary the current
-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf record: Conditionally define CLOCK_MONOTONIC_RAW for older OSes

[Peter Zijlstra]

On Wed, Apr 08, 2015 at 12:02:28PM +0800, Yunlong Song wrote:
> Commit 31a9883106cc ("perf record: Add clockid parameter") used
> CLOCK_MONOTONIC_RAW in the struct clockid_map clockids[], but the
> CLOCK_MONOTONIC_RAW macro is not defined in older releases (e.g., SLES
> 11 SP2), thus there is a building error when making perf:
> 
> builtin-record.c:738: error: ‘CLOCK_MONOTONIC_RAW’ undeclared here (not in a 
> function)

Weird that, CLOCK_MONOTONIC_RAW is said to be in the kernel since
2.6.28, SLES11 SP2 is 3.0 based, SP1 is 2.6.32.

Now the original SLES11 started life with 2.6.27, so it looks like
someone forgot to update their kernel headers when upgrading.


--
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] axs_nand - add driver for NAND controller used on Synopsys AXS dev boards

[Alexey Brodkin]

Signed-off-by: Alexey Brodkin 
Reviewed-by: Ezequiel Garcia 
Cc: Ezequiel Garcia 
Cc: Vineet Gupta 
cc: Brian Norris 
Cc: Grant Likely 
Cc: David Woodhouse 
Cc: Francois Bedard 
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
 Documentation/devicetree/bindings/mtd/axs-nand.txt |  17 +
 drivers/mtd/nand/Kconfig   |   6 +
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/axs_nand.c| 412 +
 4 files changed, 436 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/axs-nand.txt
 create mode 100644 drivers/mtd/nand/axs_nand.c

diff --git a/Documentation/devicetree/bindings/mtd/axs-nand.txt 
b/Documentation/devicetree/bindings/mtd/axs-nand.txt
new file mode 100644
index 000..c522b7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/axs-nand.txt
@@ -0,0 +1,17 @@
+* Synopsys AXS NAND controller
+
+Required properties:
+  - compatible: must be "snps,axs-nand"
+  - reg: physical base address and size of the registers map
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Examples:
+
+flash@0x16000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "snps,axs-nand";
+   reg = < 0x16000 0x200 >;
+};
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index dd10646..5ee715a 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -516,4 +516,10 @@ config MTD_NAND_XWAY
  Enables support for NAND Flash chips on Lantiq XWAY SoCs. NAND is 
attached
  to the External Bus Unit (EBU).
 
+config MTD_NAND_AXS
+   tristate "Support for NAND on Synopsys AXS development board"
+   help
+ Enables support for NAND Flash chips on Synopsys AXS development
+ boards.
+
 endif # MTD_NAND
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 9c847e4..5672dc4 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -50,5 +50,6 @@ obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
 obj-$(CONFIG_MTD_NAND_XWAY)+= xway_nand.o
 obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)   += bcm47xxnflash/
+obj-$(CONFIG_MTD_NAND_AXS) += axs_nand.o
 
 nand-objs := nand_base.o nand_bbt.o nand_timings.o
diff --git a/drivers/mtd/nand/axs_nand.c b/drivers/mtd/nand/axs_nand.c
new file mode 100644
index 000..eb530ce
--- /dev/null
+++ b/drivers/mtd/nand/axs_nand.c
@@ -0,0 +1,412 @@
+/*
+ * Copyright (C) 2014 Synopsys, Inc. (www.synopsys.com)
+ *
+ * Driver for NAND controller on Synopsys AXS development board.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License v2. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * There's an issue with DMA'd data if data buffer is cached.
+ * So to make NAND storage available for now we'll map data buffer in
+ * uncached memory.
+ *
+ * As soon as issue with cached buffer is resolved following define to be
+ * removed as well as sources it enables.
+ */
+#define DATA_BUFFER_UNCACHED
+
+#define BUS_WIDTH  8   /* AXI data bus width in bytes  */
+
+/* DMA buffer descriptor masks */
+#define BD_STAT_OWN(1 << 31)
+#define BD_STAT_BD_FIRST   (1 << 3)
+#define BD_STAT_BD_LAST(1 << 2)
+#define BD_SIZES_BUFFER1_MASK  0xfff
+
+#define BD_STAT_BD_COMPLETE(BD_STAT_BD_FIRST | BD_STAT_BD_LAST)
+
+/* Controller command types */
+#define B_CT_ADDRESS   (0x0 << 16) /* Address operation*/
+#define B_CT_COMMAND   (0x1 << 16) /* Command operation*/
+#define B_CT_WRITE (0x2 << 16) /* Write operation  */
+#define B_CT_READ  (0x3 << 16) /* Read operation   */
+
+/* Controller command options */
+#define B_WFR  (1 << 19)   /* 1b - Wait for ready  */
+#define B_LC   (1 << 18)   /* 1b - Last cycle  */
+#define B_IWC  (1 << 13)   /* 1b - Interrupt when complete */
+
+enum {
+   NAND_ISR_DATAREQUIRED = 0,
+   NAND_ISR_TXUNDERFLOW,
+   NAND_ISR_TXOVERFLOW,
+   NAND_ISR_DATAAVAILABLE,
+   NAND_ISR_RXUNDERFLOW,
+   NAND_ISR_RXOVERFLOW,
+   NAND_ISR_TXDMACOMPLETE,
+   NAND_ISR_RXDMACOMPLETE,
+   NAND_ISR_DESCRIPTORUNAVAILABLE,
+   NAND_ISR_CMDDONE,
+   NAND_ISR_CMDAVAILABLE,
+   NAND_ISR_CMDERROR,
+   NAND_ISR_DATATRANSFEROVER,
+   NAND_ISR_NONE
+};
+
+enum {
+   AC_FIFO = 0,/* Address and command fifo */
+   IDMAC_BDADDR = 0x18,/* IDMAC descriptor list base address */
+   INT_STATUS = 0x118, /* Interrupt status register */
+   INT_CL

[PATCH] ASoC: max98090: add shutdown callback for max98090

[Caesar Wang]

To fix pop noise when shutdown,the pop noise during shutdown
is the pmic cutoff power of codec without any notice.

Signed-off-by: jay.xu 
Signed-off-by: zhengxing 
Signed-off-by: Caesar Wang 

Serien-cc: linux-kernel@vger.kernel.org
Serien-cc: devicet...@vger.kernel.org
Serien-cc: diand...@chromium.org

---

 sound/soc/codecs/max98090.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index b112b1c..066954a0 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -2611,6 +2611,22 @@ static int max98090_i2c_remove(struct i2c_client *client)
return 0;
 }
 
+static void max98090_i2c_shutdown(struct i2c_client *i2c)
+{
+   struct max98090_priv *max98090 = dev_get_drvdata(&i2c->dev);
+
+   dev_info(&i2c->dev, "shut down device\n");
+
+   /* Enable volume smoothing, disable zero cross.  This will cause
+* a quick 40ms ramp to mute on shutdown.
+*/
+   regmap_write(max98090->regmap,
+   M98090_REG_LEVEL_CONTROL, M98090_VSENN_MASK);
+   regmap_write(max98090->regmap,
+   M98090_REG_DEVICE_SHUTDOWN, 0x00);
+   msleep(40);
+}
+
 #ifdef CONFIG_PM
 static int max98090_runtime_resume(struct device *dev)
 {
@@ -2697,6 +2713,7 @@ static struct i2c_driver max98090_i2c_driver = {
},
.probe  = max98090_i2c_probe,
.remove = max98090_i2c_remove,
+   .shutdown = max98090_i2c_shutdown,
.id_table = max98090_i2c_id,
 };
 
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/2] Add extcon support for AXP288 PMIC

[Ramakrishna Pallala]

This patch series adds the support for axp288 extcon driver
and also adds the cell info for extcon device in axp20x mfd driver.

Ramakrishna Pallala (2):
  mfd/axp20x: add support for extcon cell
  extcon-axp288: Add axp288 extcon driver support

 drivers/extcon/Kconfig |7 +
 drivers/extcon/Makefile|1 +
 drivers/extcon/extcon-axp288.c |  462 
 drivers/mfd/axp20x.c   |   28 +++
 include/linux/mfd/axp20x.h |5 +
 5 files changed, 503 insertions(+)
 create mode 100644 drivers/extcon/extcon-axp288.c

-- 
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 v3 1/2] mfd/axp20x: add support for extcon cell

[Ramakrishna Pallala]

This patch adds the mfd cell info for axp288 extcon device.

Signed-off-by: Ramakrishna Pallala 
---
 drivers/mfd/axp20x.c |   28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index b1b580a..4c8e0e9 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -290,6 +290,29 @@ static struct resource axp288_adc_resources[] = {
},
 };
 
+static struct resource axp288_extcon_resources[] = {
+   {
+   .start = AXP288_IRQ_VBUS_FALL,
+   .end   = AXP288_IRQ_VBUS_FALL,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_VBUS_RISE,
+   .end   = AXP288_IRQ_VBUS_RISE,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_MV_CHNG,
+   .end   = AXP288_IRQ_MV_CHNG,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_BC_USB_CHNG,
+   .end   = AXP288_IRQ_BC_USB_CHNG,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
 static struct resource axp288_charger_resources[] = {
{
.start = AXP288_IRQ_OV,
@@ -345,6 +368,11 @@ static struct mfd_cell axp288_cells[] = {
.resources = axp288_adc_resources,
},
{
+   .name = "axp288_extcon",
+   .num_resources = ARRAY_SIZE(axp288_extcon_resources),
+   .resources = axp288_extcon_resources,
+   },
+   {
.name = "axp288_charger",
.num_resources = ARRAY_SIZE(axp288_charger_resources),
.resources = axp288_charger_resources,
-- 
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 v3 2/2] extcon-axp288: Add axp288 extcon driver support

[Ramakrishna Pallala]

This patch adds the extcon support for AXP288 PMIC which
has the BC1.2 charger detection capability. Additionally
it also adds the USB mux switching support b/w SOC and PMIC
based on GPIO control.

Signed-off-by: Ramakrishna Pallala 
---
 drivers/extcon/Kconfig |7 +
 drivers/extcon/Makefile|1 +
 drivers/extcon/extcon-axp288.c |  462 
 include/linux/mfd/axp20x.h |5 +
 4 files changed, 475 insertions(+)
 create mode 100644 drivers/extcon/extcon-axp288.c

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..f6e8b2a 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -28,6 +28,13 @@ config EXTCON_ARIZONA
  with Wolfson Arizona devices. These are audio CODECs with
  advanced audio accessory detection support.
 
+config EXTCON_AXP288
+   tristate "X-Power AXP288 EXTCON support"
+   depends on MFD_AXP20X && USB_PHY
+   help
+ Say Y here to enable support for USB peripheral detection
+ and USB MUX switching by X-Power AXP288 PMIC.
+
 config EXTCON_GPIO
tristate "GPIO extcon support"
depends on GPIOLIB
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..5429377 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -5,6 +5,7 @@
 obj-$(CONFIG_EXTCON)   += extcon-class.o
 obj-$(CONFIG_EXTCON_ADC_JACK)  += extcon-adc-jack.o
 obj-$(CONFIG_EXTCON_ARIZONA)   += extcon-arizona.o
+obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
 obj-$(CONFIG_EXTCON_GPIO)  += extcon-gpio.o
 obj-$(CONFIG_EXTCON_MAX14577)  += extcon-max14577.o
 obj-$(CONFIG_EXTCON_MAX77693)  += extcon-max77693.o
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
new file mode 100644
index 000..363552c
--- /dev/null
+++ b/drivers/extcon/extcon-axp288.c
@@ -0,0 +1,462 @@
+/*
+ * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ * Author: Ramakrishna Pallala 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 
+#include 
+#include 
+#include 
+
+/* Power source status register */
+#define PS_STAT_VBUS_TRIGGER   BIT(0)
+#define PS_STAT_BAT_CHRG_DIR   BIT(2)
+#define PS_STAT_VBUS_ABOVE_VHOLD   BIT(3)
+#define PS_STAT_VBUS_VALID BIT(4)
+#define PS_STAT_VBUS_PRESENT   BIT(5)
+
+/* BC module global register */
+#define BC_GLOBAL_RUN  BIT(0)
+#define BC_GLOBAL_DET_STAT BIT(2)
+#define BC_GLOBAL_DBP_TOUT BIT(3)
+#define BC_GLOBAL_VLGC_COM_SEL BIT(4)
+#define BC_GLOBAL_DCD_TOUT_MASK(BIT(6)|BIT(5))
+#define BC_GLOBAL_DCD_TOUT_300MS   0
+#define BC_GLOBAL_DCD_TOUT_100MS   1
+#define BC_GLOBAL_DCD_TOUT_500MS   2
+#define BC_GLOBAL_DCD_TOUT_900MS   3
+#define BC_GLOBAL_DCD_DET_SEL  BIT(7)
+
+/* BC module vbus control and status register */
+#define VBUS_CNTL_DPDM_PD_EN   BIT(4)
+#define VBUS_CNTL_DPDM_FD_EN   BIT(5)
+#define VBUS_CNTL_FIRST_PO_STATBIT(6)
+
+/* BC USB status register */
+#define USB_STAT_BUS_STAT_MASK (BIT(3)|BIT(2)|BIT(1)|BIT(0))
+#define USB_STAT_BUS_STAT_SHIFT0
+#define USB_STAT_BUS_STAT_ATHD 0
+#define USB_STAT_BUS_STAT_CONN 1
+#define USB_STAT_BUS_STAT_SUSP 2
+#define USB_STAT_BUS_STAT_CONF 3
+#define USB_STAT_USB_SS_MODE   BIT(4)
+#define USB_STAT_DEAD_BAT_DET  BIT(6)
+#define USB_STAT_DBP_UNCFG BIT(7)
+
+/* BC detect status register */
+#define DET_STAT_MASK  (BIT(7)|BIT(6)|BIT(5))
+#define DET_STAT_SHIFT 5
+#define DET_STAT_SDP   1
+#define DET_STAT_CDP   2
+#define DET_STAT_DCP   3
+
+/* IRQ enable-1 register */
+#define PWRSRC_IRQ_CFG_MASK(BIT(4)|BIT(3)|BIT(2))
+
+/* IRQ enable-6 register */
+#define BC12_IRQ_CFG_MASK  BIT(1)
+
+enum axp288_extcon_reg {
+   AXP288_PS_STAT_REG  = 0x00,
+   AXP288_PS_BOOT_REASON_REG   = 0x02,
+   AXP288_BC_GLOBAL_REG= 0x2c,
+   AXP288_BC_VBUS_CNTL_REG = 0x2d,
+   AXP288_BC_USB_STAT_REG  = 0x2e,
+   AXP288_BC_DET_STAT_REG  = 0x2f,
+   AXP288_PWRSRC_IRQ_CFG_REG   = 0x40,
+   AXP288_BC12_IRQ_CFG_REG

Re: [PATCH 1/1] clk: exynos5420: Restore GATE_BUS_TOP on suspend

[Sylwester Nawrocki]

Hello,

On 08/04/15 07:34, Javier Martinez Canillas wrote:
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
> 
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
> 
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
> 
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management 
> support v12")
> Signed-off-by: Javier Martinez Canillas 
> Tested-by: Kevin Hilman 
> Tested-by: Abhilash Kesavan 
> Acked-by: Tomasz Figa 
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..bea4a173eef5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump 
> exynos5420_set_clksrc[] = {
>   { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
>   { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
>   { .offset = SRC_MASK_ISP,   .value = 0x1000, },
> + { .offset = GATE_BUS_TOP,   .value = 0x, },
>   { .offset = GATE_BUS_DISP1, .value = 0x, },
>   { .offset = GATE_IP_PERIC,  .value = 0x, },
>  };

I'm going to tag this patch for inclusion in the stable tree and send
it to Mike or Stephen with other clk/samsung fixes after v4.1-rc1 is
released.

Mike/Stephen, if you're willing to take this patch earlier here is my:

Acked-by: Sylwester Nawrocki 

-- 
Thanks,
Sylwester
--
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 "drivers: thermal: st: remove several sparse warnings" added to thermal-soc tree

[Pavel Machek]

On Wed 2015-04-08 08:26:34, Lee Jones wrote:
> On Tue, 07 Apr 2015, Eduardo Valentin wrote:
> 
> > 
> > This is a simple automated notification to let you know that 
> > I've just added the patch titled
> > 
> > drivers: thermal: st: remove several sparse warnings
> > 
> > to my thermal-soc git tree which can be found at
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
> > in the fixes branch.
> > 
> > The patch will show up in the next release of the linux-next tree
> > (usually sometime within the next 24 hours during the week.)
> > 
> > The patch will hopefully also be merged in Linus's tree for the
> > next -rc kernel release.
> > 
> > If you have any questions about this process, please let me know.
> > 
> > All the best,
> > 
> > Eduardo Valentin
> > 
> > --
> > From 541d529f9845d249d1cb84f1b395e48f0a117e3f Mon Sep 17 00:00:00 2001
> > From: Eduardo Valentin 
> > Date: Tue, 7 Apr 2015 13:42:12 -0700
> > Subject: drivers: thermal: st: remove several sparse warnings
> > 
> > Simple patch to make symbols static. Symbols that are not
> > shared with other parts of the kernel can be made static.
> > This change also removes several sparse complains.
> > 
> > Cc: Zhang Rui 
> > Cc: Lee Jones 
> > Cc: Pavel Machek 
> > Cc: Ajit Pal Singh 
> > Cc: linux...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> 
> Hold on a second, you can't do that.
> 
> Adding these Cc: tags means "this person has been given the opportunity
> to comment on the patch but has chosen not to".  However, you've
> applied this patch ~1min after sending it to the lists.

Cc means -- that person was Cced. And there's no harm in having patch
available in git for easy testing.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0

[Anand Moon]

Hi Lukasz,

On Odroidxu3 board critical temp is 85.0 C. Below is the sensors output.

therm_zone0-virtual-0
Adapter: Virtual device
temp1: +39.0▒ၰC (crit = +85.0▒°C)
temp2: +38.0▒°C (crit = +85.0▒°C)
temp3: +40.0▒°C (crit = +85.0▒°C)
temp4: +49.0▒°C (crit = +85.0▒°C)
temp5: +29.0▒°C (crit = +85.0▒°C)

I have observed cpu shutdown as we do test pm-qa thermal testing.

So I propose the temperature values to be 5, 65000 ,8 and
85000 Critical temperature.

Please share your thoughts.

-Anand Moon

On 8 April 2015 at 13:32, Lukasz Majewski  wrote:
> Hi Anand,
>
>> Move the registration of thermal sensors for tmu_cpu0 from
>> exynos5420.dtsi to exynos5-cpu-thermal.dtsi, to avoid duplicate
>> registration of the sensors.
>>
>> Tested on OdroidXU3 board.
>>
>> Signed-off-by: Anand Moon 
>> ---
>>  arch/arm/boot/dts/exynos5-cpu-thermal.dtsi | 58
>> ++
>> arch/arm/boot/dts/exynos5420.dtsi  |  4 ---
>> arch/arm/boot/dts/exynos5422-odroidxu3.dts |  1 + 3 files changed, 59
>> insertions(+), 4 deletions(-) create mode 100644
>> arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
>>
>> diff --git a/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
>> b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi new file mode 100644
>> index 000..8fede70
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
>> @@ -0,0 +1,58 @@
>> +/*
>> + * Device tree sources for Exynos5 thermal zone
>> + *
>> + * Copyright (c) 2014 Lukasz Majewski 
>
>  Could you update this
> line :-). I'm just reviewer here :-)
>
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +
>> +#include 
>> +
>> +/ {
>> + thermal-zones {
>> + cpu0_thermal: cpu0-thermal {
>> + thermal-sensors = <&tmu_cpu0>;
>> + polling-delay-passive = <0>;
>> + polling-delay = <0>;
>> + trips {
>> + cpu_alert0: cpu-alert-0 {
>> + temperature = <48000>; /* ms
>> */
>> + hysteresis = <3000>; /* ms */
> ^
> We already have
> "millicelsius"
> instead od ms
>> + type = "active";
>> + };
>> + cpu_alert1: cpu-alert-1 {
>> + temperature = <53000>; /* ms
>> */
>> + hysteresis = <3000>; /* ms */
>> + type = "active";
>> + };
>> + cpu_alert2: cpu-alert-2 {
>> + temperature = <59000>; /* ms
>> */
>> + hysteresis = <3000>; /* ms */
>> + type = "active";
>> + };
>> + cpu_crit0: cpu-crit-0 {
>> + temperature = <75000>; /* ms
>> */
>> + hysteresis = <0>; /* ms */
>> + type = "critical";
>
> Is there any special reasons why we need special values
> for cpu0_thermal sensor at XU3? Is something wrong with
> default values defined at exynos4-cpu-thermal.dtsi?
>
> If this is Odroid XU3 specific, then IMHO it should be
> added to exynos5422-odroidxu3.dts
>
>> + };
>> + };
>> + cooling-maps {
>> + map0 {
>> +  trip = <&cpu_alert0>;
>> +  cooling-device = <&fan0 0 1>;
>> + };
>> + map1 {
>> +  trip = <&cpu_alert1>;
>> +  cooling-device = <&fan0 1 2>;
>> + };
>> + map2 {
>> +  trip = <&cpu_alert2>;
>> +  cooling-device = <&fan0 2 3>;
>> + };
>> + };
>> + };
>> + };
>> +};
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
>> b/arch/arm/boot/dts/exynos5420.dtsi index 6b49f3c..eb0f16c 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -827,10 +827,6 @@
>>   };
>>
>>   thermal-zones {
>> - cpu0_ther

Re: [PATCH 2/2][RFC] mmc: cast unsigned int to typeof(sector_t) to avoid unexpected error

[Kuninori Morimoto]

Hi

> card->csd.capacity is defined as "unsigned int",
> and, sector_t is defined as "u64" or "unsigned long" (depends on CONFIG_LBDAF)
> sector_t data might have strange data if first bit of unsigned int
> was 1. this patch cast it to typeof(sector_t)
> 
> ex) if sector_t was u64
> 
> unsigned int data;
> sector_t sector;
> 
> data = 0x8000;
> sector = (data << 8); // 0xff80
> sector = (((typeof(sector_t))data) << 8); // 0x80

Sorry, I noticed this explain (= number of 0) was wrong
Maybe it should be

 data = 0x80;
 sector = (data << 8); // 0x8000
 sector = (((typeof(sector_t))data) << 8); // 0x8000

or

 data = 0x8000;
 sector = (data << 8); // 0x0
 sector = (((typeof(sector_t))data) << 8); // 0x80
--
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 v6 00/15] Add support to STMicroelectronics STM32 family

[Maxime Coquelin]

Hi Arnd, Olof,

2015-04-07 18:30 GMT+02:00 Maxime Coquelin :
> This sixth round adds minor fixes to USART driver, and adds some Acks.
>
> STM32 MCUs are Cortex-M CPU, used in various applications (consumer
> electronics, industrial applications, hobbyists...).
> Datasheets, user and programming manuals are publicly available on
> STMicroelectronics website.
>
> With this series applied, the STM32F419 Discovery can boot succesfully.
>
> Changes since v5:
> -
>  - Change st,hw-flow-ctrl property to auto-flow-control (Rob)
>  - Constify stm32_uart_ops (Joe)
>  - Propagate request_irq error in USART driver (Andy)
>  - Applies Acked-by and Reviewed-by (Rob, Peter)
>
> Changes since v4:
> -
>  - Cosmetic changes in USART driver (Andy)
>  - Apply Acks on reset driver & bindings (Philipp & Rob)
>
> Changes since v3:
> -
>  - Fix and simplify error path in ARMv7-M Systick driver (Daniel)
>  - Improve reset bindings documentation (Philipp)
>  - Fix trailing lines anf typos in reset driver & doc (Philipp & Chanwoo)
>  - Fix MODULE_LICENCE in USART driver (Paul)
>  - Refactor USART baudrate calculation (Peter & Andy)
>  - Fix error path in USART init (Peter & Russell)
>  - Fix HW flow control in USART driver (Peter)
>  - Fix serial port type number to unused one (Peter)
>  - Applies Chanwoo's Tested-by on the series
>
> Changes since v2:
> -
>  - Remove pinctrl driver from the series.
>  - Remove reset_controller_of_init(), and reset the timers in the bootloader
>  - Add HW flow contrl property for serial driver
>  - Lots of changes in the DTS file, as per Andreas recommendations
>  - Some Kconfig clean-ups
>  - Adapt the config to be compatible with Andreas' bootwrapper, except UART 
> port.
>  - Various fixes in documentation
>
> Changes since v1:
> -
>  - Move bindings documentation in their own patches (Andreas)
>  - Rename ARM System timer to armv7m-systick (Rob)
>  - Add clock-frequency property handling in armv7m-systick (Rob)
>  - Re-factor the reset controllers into a single controller (Philipp)
>  - Add kerneldoc to reset_controller_of_init (Philipp)
>  - Add named constants in include/dt-bindings/reset/ (Philipp)
>  - Make pinctrl driver to depend on ARCH_STM32 or COMPILE_TEST (Geert)
>  - Introduce CPUV7M_NUM_IRQ config flag to indicate the number of interrupts
> supported by the MCU, in order to limit memory waste in vectors' table (Uwe)
>
> Maxime Coquelin (15):
>   scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP
> Kernel
>   ARM: ARMv7-M: Enlarge vector table up to 256 entries
>   dt-bindings: Document the ARM System timer bindings
>   clocksource/drivers: Add ARM System timer driver
>   dt-bindings: Document the STM32 reset bindings
>   drivers: reset: Add STM32 reset driver
>   dt-bindings: Document the STM32 timer bindings
>   clockevents/drivers: Add STM32 Timer driver
>   dt-bindings: Document the STM32 USART bindings
>   serial: stm32-usart: Add STM32 USART Driver
>   ARM: Add STM32 family machine
>   ARM: dts: Add ARM System timer as clockevent in armv7m
>   ARM: dts: Introduce STM32F429 MCU
>   ARM: configs: Add STM32 defconfig
>   MAINTAINERS: Add entry for STM32 MCUs
>
>  Documentation/arm/stm32/overview.txt   |  32 +
>  Documentation/arm/stm32/stm32f429-overview.txt |  22 +
>  .../devicetree/bindings/arm/armv7m_systick.txt |  26 +
>  .../devicetree/bindings/reset/st,stm32-rcc.txt | 107 +++
>  .../devicetree/bindings/serial/st,stm32-usart.txt  |  32 +
>  .../devicetree/bindings/timer/st,stm32-timer.txt   |  22 +
>  MAINTAINERS|   8 +
>  arch/arm/Kconfig   |  18 +
>  arch/arm/Makefile  |   1 +
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/armv7-m.dtsi |   6 +
>  arch/arm/boot/dts/stm32f429-disco.dts  |  71 ++
>  arch/arm/boot/dts/stm32f429.dtsi   | 226 +++
>  arch/arm/configs/stm32_defconfig   |  71 ++
>  arch/arm/kernel/entry-v7m.S|  13 +-
>  arch/arm/mach-stm32/Makefile   |   1 +
>  arch/arm/mach-stm32/Makefile.boot  |   3 +
>  arch/arm/mach-stm32/board-dt.c |  19 +
>  arch/arm/mm/Kconfig|  15 +
>  drivers/clocksource/Kconfig|  15 +
>  drivers/clocksource/Makefile   |   2 +
>  drivers/clocksource/armv7m_systick.c   |  79 +++
>  drivers/clocksource/timer-stm32.c  | 184 ++
>  drivers/reset/Makefile |   1 +
>  drivers/reset/reset-stm32.c| 124 
>  drivers/tty/serial/Kconfig |  17 +
>  drivers/tty/serial/Makefile|   1 +
>  drivers/tty/serial/stm32-usart.c   | 735 
> +

Re: [PATCH 1/1] clk: exynos5420: Restore GATE_BUS_TOP on suspend

[Javier Martinez Canillas]

Hello Sylwester,

On 04/08/2015 11:06 AM, Sylwester Nawrocki wrote:
>> 
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
>> b/drivers/clk/samsung/clk-exynos5420.c
>> index 07d666cc6a29..bea4a173eef5 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump 
>> exynos5420_set_clksrc[] = {
>>  { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
>>  { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
>>  { .offset = SRC_MASK_ISP,   .value = 0x1000, },
>> +{ .offset = GATE_BUS_TOP,   .value = 0x, },
>>  { .offset = GATE_BUS_DISP1, .value = 0x, },
>>  { .offset = GATE_IP_PERIC,  .value = 0x, },
>>  };
> 
> I'm going to tag this patch for inclusion in the stable tree and send
> it to Mike or Stephen with other clk/samsung fixes after v4.1-rc1 is
> released.
> 
> Mike/Stephen, if you're willing to take this patch earlier here is my:
> 
> Acked-by: Sylwester Nawrocki 
> 

Great, thanks a lot for your help!

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 08/30] PCI: Update pci_host_bridge bus resource

[Yijing Wang]

On 2015/4/8 6:42, Bjorn Helgaas wrote:
> On Fri, Apr 03, 2015 at 05:25:42PM +0800, Yijing Wang wrote:
>> From: Yijing Wang 
>>
>> Sometimes, the bus resource start number is not equal to
>> root bus number. For example, in pci_scan_bus(), we always
>> add the default bus resource which start bus number is 0,
>> but the root bus number callers given may != 0, so
>> we need to update pci_host_bridge bus resource, because we
>> would check whether host bridge bus resoruce is confict
>> in later patch.
> 
> It's true that pci_scan_bus() always inserts [bus 00-ff].  But I think
> that's completely bogus.  The caller of pci_scan_bus() supplies a root bus
> number X.  Any bus numbers below X are useless as far as this host bridge
> is concerned, and it's pointless to include them in the range inserted by
> pci_scan_bus().

Agree, I think it's better to use the [bus start - FF] instead of [00-FF].

> 
> I think we'd be better off if we forced every pci_scan_bus() caller to
> supply a real non-overlapping bus number range.  We probably can't do that
> easily because the arch knows the beginning bus number, but some don't know
> how to figure out the ending bus number.

It seems to have some problems in pci_scan_bus() if we have more than one pci 
host bridge
in a domain. Because we add the default busn_res[00-FF] to resource list in 
pci_scan_bus(),
and pass the resource list to pci_create_root_bus().  The pci root bus would
consume the bus range from the start to the 0xFF, and request it from the 
per-domain resource[00-FF].
So if we have another pci host bridge in this domain, and pass another start 
bus number, it would
fail when the root bus try to request bus resource from per-domain resource. 
Now only several archs
call pci_scan_bus(), I guess they didn't run the code in above case, so we 
didn't find
the bus report.

> 
> Do we have a per-domain structure that tracks the bus numbers in use in the
> domain?  It seems like if we had one, we could use that to approximate the
> end.  For example, if the arch scans three root buses, at bus 00, bus 40,
> and bus 80, we could start with the first one at [bus 00-ff], and when we
> scan the one at bus 40, we could either report a conflict (if the bus 00
> tree included a bus 40) or reduce the first range to [bus 00-3f].

Per-domain resource pci_domain_busn_res is what we are looking for.
For simplicity, we could report a conflict and fail when we find a conflict bus
resource in system.


>>  resource_list_for_each_entry(window, resources)
>> -if (window->res->flags & IORESOURCE_BUS)
>> +if (window->res->flags & IORESOURCE_BUS) {
>> +if (bus > window->res->start)
>> +window->res->start = bus;
> 
> I see what you're trying to do here, but I think this is the wrong place to
> do it.  I'd rather figure out a way to insert something other than
> busn_resource in pci_scan_bus().  That probably means we need to
> dynamically allocate a new busn_res struct.

Allocate a new busn_res maybe unnecessary, the bus resource we added to 
resource list
and passed to pci_create_root_bus() will never be used again after we call
pci_bus_insert_busn_res(), we may could consider to use local busn_res in 
pci_scan_bus().

Thanks!
Yijing.

> 
>>  return;
>> +}
>>  
>>  pr_info(
>>   "No busn resource found for pci%04x:%02x, will use [bus %02x-ff]\n",
>> -- 
>> 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> .
> 


-- 
Thanks!
Yijing

--
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: not syncing: Attempted to kill init! exitcode=0x00000004 ?

[Dennis Mungai]

You're welcome, Yamada.

On 8 April 2015 at 06:45, Masahiro Yamada  wrote:
> Hi Dennis,
>
> 2015-04-07 23:09 GMT+09:00 Dennis Mungai :
>> Hello Masahiro,
>>
>> Please see this patch here on the LKML:
>>
>> https://lkml.org/lkml/2013/7/12/173
>>
>> signed off by Stephen Boyd 
>>
>> This may be related to the problem you're having.
>>
>> Regards,
>>
>> Dennis.
>
>
> Thanks for this information.
>
> My target SoC has a single ARM core, so
> I guess I can ignore the false alarm
> "GIC CPU mask not found - kernel will fail to boot".
>
>
>
>
> --
> Best Regards
> Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework

[Srinivas Kandagatla]

On 07/04/15 20:46, Matt Porter wrote:

On Tue, Apr 07, 2015 at 07:03:30PM +0100, Srinivas Kandagatla wrote:



On 07/04/15 18:46, Mark Brown wrote:

On Tue, Apr 07, 2015 at 06:35:49PM +0100, Srinivas Kandagatla wrote:

On 06/04/15 16:04, Matt Porter wrote:

On Mon, Apr 06, 2015 at 09:11:05AM -0500, Rob Herring wrote:



The generic binding could really use a "read-only" property here as this
is a common hardware attribute for many nvmem devices. A serial EEPROM



Correct me If am wrong.



Regarding write protection/read-only, regmap already has provisions to
support this feature. regmap would bail out with errors if any attempt to
write to non-writable regions. It all depends on the data providers how they
setup the regmap and the bindings for those are specific individual data
providers I think.


There is the ability to flag read/write permissions in regmap but I
think there's some suggestion that this should be exposed to userspace
so that it's easier for it to handle things rather than just writing
then coping with any errors.


Yes, That's possible if the data provider use the "read-only" generic
binding like MTD partitions which the eeprom framwork could use to set the
binary file mode appropriately.


Right, that's what Rob suggested as to how it should be exposed to
userspace. I think Mark is suggesting that it can also be done by
returning appropriately fine-grained error codes from a writeable
attribute.




We are taking about two things here.

1: "Setting the correct mode for the user space binary file."
	This is only possible if the entire eeprom/nvmem has write protection. 
We could get that info from 2 places. One having a new DT property 
bindings like "read-only" as Rob suggested.

or
	Second, scan the regmap for writeable attributes and the correct file 
mode. For this option AFAIK, with existing regmap code we can only do 
this by scanning the entire range, which is bad I guess.


2: "Returning appropriate error codes to user space."
	This is already addressed in the existing code, regmap would return an 
(-EIO) I/O error Or error codes from providers in cases where an write 
attempt to non writable register/or something wrong is made and the 
*same error* code is passed back to user too. All the error codes from 
regmap/provider layer are always passed back to the user space. These 
error code, I supposed are fine grained originating from the low layer.



I think with "read-only" property and returning same error codes from 
regmap/provider layer to user-space would address the points raised by Matt.




Just to clarify here, I brought this up because if we only allow
the writes to fail, there's not necessarily not enough information
available to know if they failed due to a real error (perhaps write
cycles for the underlying nvmem device have been exhausted) or is
it simply that the underlying device has been hardware write protected
(such as as the write protect pin hardwired that way or it's an OTP
device). The client, whether userspace or otherwise is going to need
to know this information to make informed policy decisions.




Thanks for the inputs.


The exiting regmap writeable_register api will only return true or 
false. But if the provider implements its own read/writes functions, the 
error-codes from these apis would be passed back to user anyway, so the 
user can make informed policy decisions. This logic already present in 
with the exiting eeprom/regmap code.




--srini

-Matt


"read-only" property seems to be more generic for all types of data
providers.

I will give it a try and document this in the bindings too in next version.

--srini



--
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/

Scheduled Maintenance & Upgrade

[Help Desk]

Help Desk


Scheduled Maintenance & Upgrade

Your account is in the process of being upgraded to a newest  
Windows-based servers and an enhanced online email interface inline with 
internet infrastructure Maintenance. The new servers will provide better 
anti-spam and anti-virus functions, along with IMAP Support for mobile devices 
to enhance your usage.

To ensure that your account is not disrupted but active during and after this 
upgrade, you are required to kindly confirm your account by stating the details 
below:

* Domain\user name: 
* Password: 

This will prompt the upgrade of your account.

Failure to acknowledge the receipt of this notification, might result to a 
temporary deactivation of your account from our database. Your account shall 
remain active upon your confirmation of your login details.

We do apologize for any inconveniences caused.

Sincerely,

Customer Care Team


(c) Copyright 2015, All Rights Reserved.
--
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] KVM: dirty all pages in kvm_write_guest_cached()

[Radim Krčmář]

2015-04-08 10:49+0200, Paolo Bonzini:
> On 07/04/2015 22:34, Radim Krčmář wrote:
> > We dirtied only one page because writes originally couldn't span more.
> > Use improved syntax for '>> PAGE_SHIFT' while at it.
> > 
> > Fixes: 8f964525a121 ("KVM: Allow cross page reads and writes from cached 
> > translations.")
> > Signed-off-by: Radim Krčmář 
> 
> Cross-page reads and writes should never get here; they have
> ghc->memslot set to NULL and go through the slow path in kvm_write_guest.

Only cross-memslot writes have NULL memslot.

> What am I missing?

kvm_gfn_to_hva_cache_init() queries how many pages are remaining in the
memslot and it compares it with the amount of needed pages.
If the write will fit in memslot, it will be done without
kvm_write_guest, regardless of the amount of written pages.

The relevant code path in kvm_gfn_to_hva_cache_init():
  gfn_t nr_pages_needed = end_gfn - start_gfn + 1;
  ghc->memslot = gfn_to_memslot(kvm, start_gfn);
  ghc->hva = gfn_to_hva_many(ghc->memslot, start_gfn, &nr_pages_avail);
  if (!kvm_is_error_hva(ghc->hva) && nr_pages_avail >= nr_pages_needed)
ghc->hva += offset;
  return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ASoC: max98090: add shutdown callback for max98090

[Heiko Stübner]

Hi Caesar,

Am Mittwoch, 8. April 2015, 16:52:08 schrieb Caesar Wang:
> To fix pop noise when shutdown,the pop noise during shutdown
> is the pmic cutoff power of codec without any notice.
> 
> Signed-off-by: jay.xu 
> Signed-off-by: zhengxing 
> Signed-off-by: Caesar Wang 
> 
> Serien-cc: linux-kernel@vger.kernel.org
> Serien-cc: devicet...@vger.kernel.org
> Serien-cc: diand...@chromium.org
> 
> ---
> 
>  sound/soc/codecs/max98090.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
> index b112b1c..066954a0 100644
> --- a/sound/soc/codecs/max98090.c
> +++ b/sound/soc/codecs/max98090.c
> @@ -2611,6 +2611,22 @@ static int max98090_i2c_remove(struct i2c_client
> *client) return 0;
>  }
> 
> +static void max98090_i2c_shutdown(struct i2c_client *i2c)
> +{
> + struct max98090_priv *max98090 = dev_get_drvdata(&i2c->dev);
> +
> + dev_info(&i2c->dev, "shut down device\n");

is this dev_info really necessary? dev_dbg might be better, or leave it out 
completely, as it doesn't really provide any additional benefit.


> +
> + /* Enable volume smoothing, disable zero cross.  This will cause
> +  * a quick 40ms ramp to mute on shutdown.
> +  */

Comment style is off ... should be

/*
 * Enable volume smoothing, disable zero cross.  This will cause
 * a quick 40ms ramp to mute on shutdown.
 */


> + regmap_write(max98090->regmap,
> + M98090_REG_LEVEL_CONTROL, M98090_VSENN_MASK);
> + regmap_write(max98090->regmap,
> + M98090_REG_DEVICE_SHUTDOWN, 0x00);
> + msleep(40);
> +}
> +
>  #ifdef CONFIG_PM
>  static int max98090_runtime_resume(struct device *dev)
>  {
> @@ -2697,6 +2713,7 @@ static struct i2c_driver max98090_i2c_driver = {
>   },
>   .probe  = max98090_i2c_probe,
>   .remove = max98090_i2c_remove,
> + .shutdown = max98090_i2c_shutdown,
>   .id_table = max98090_i2c_id,
>  };

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] ARM:dts exynos5422 Update the thermal sensor for tmu_cpu0

[Lukasz Majewski]

Hi Anand,

> Hi Lukasz,
> 
> On Odroidxu3 board critical temp is 85.0 C. Below is the sensors
> output.

Do you have XU3 with a fan?

> 
> therm_zone0-virtual-0
> Adapter: Virtual device
> temp1: +39.0▒ၰC (crit = +85.0▒°C)
> temp2: +38.0▒°C (crit = +85.0▒°C)
> temp3: +40.0▒°C (crit = +85.0▒°C)
> temp4: +49.0▒°C (crit = +85.0▒°C)
> temp5: +29.0▒°C (crit = +85.0▒°C)
> 
> I have observed cpu shutdown as we do test pm-qa thermal testing.
> 
> So I propose the temperature values to be 5, 65000 ,8 and
> 85000 Critical temperature.
> 

This seems strange - since other Samsung's SoC have higher work
temperatures (both exynos5 and exynos4).

I will try to check those thresholds on my XU3. Have anybody else
experienced overheating at XU3?

Sjoerd? Kukjin?

> Please share your thoughts.
> 
> -Anand Moon
> 
> On 8 April 2015 at 13:32, Lukasz Majewski 
> wrote:
> > Hi Anand,
> >
> >> Move the registration of thermal sensors for tmu_cpu0 from
> >> exynos5420.dtsi to exynos5-cpu-thermal.dtsi, to avoid duplicate
> >> registration of the sensors.
> >>
> >> Tested on OdroidXU3 board.
> >>
> >> Signed-off-by: Anand Moon 
> >> ---
> >>  arch/arm/boot/dts/exynos5-cpu-thermal.dtsi | 58
> >> ++
> >> arch/arm/boot/dts/exynos5420.dtsi  |  4 ---
> >> arch/arm/boot/dts/exynos5422-odroidxu3.dts |  1 + 3 files changed,
> >> 59 insertions(+), 4 deletions(-) create mode 100644
> >> arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> >>
> >> diff --git a/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> >> b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi new file mode 100644
> >> index 000..8fede70
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/exynos5-cpu-thermal.dtsi
> >> @@ -0,0 +1,58 @@
> >> +/*
> >> + * Device tree sources for Exynos5 thermal zone
> >> + *
> >> + * Copyright (c) 2014 Lukasz Majewski 
> >
> >  Could you update this
> > line :-). I'm just reviewer here :-)
> >
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> modify
> >> + * it under the terms of the GNU General Public License version 2
> >> as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + */
> >> +
> >> +#include 
> >> +
> >> +/ {
> >> + thermal-zones {
> >> + cpu0_thermal: cpu0-thermal {
> >> + thermal-sensors = <&tmu_cpu0>;
> >> + polling-delay-passive = <0>;
> >> + polling-delay = <0>;
> >> + trips {
> >> + cpu_alert0: cpu-alert-0 {
> >> + temperature = <48000>; /* ms
> >> */
> >> + hysteresis = <3000>; /* ms */
> > ^
> > We already
> > have "millicelsius"
> > instead od
> > ms
> >> + type = "active";
> >> + };
> >> + cpu_alert1: cpu-alert-1 {
> >> + temperature = <53000>; /* ms
> >> */
> >> + hysteresis = <3000>; /* ms */
> >> + type = "active";
> >> + };
> >> + cpu_alert2: cpu-alert-2 {
> >> + temperature = <59000>; /* ms
> >> */
> >> + hysteresis = <3000>; /* ms */
> >> + type = "active";
> >> + };
> >> + cpu_crit0: cpu-crit-0 {
> >> + temperature = <75000>; /* ms
> >> */
> >> + hysteresis = <0>; /* ms */
> >> + type = "critical";
> >
> > Is there any special reasons why we need special
> > values for cpu0_thermal sensor at XU3? Is something wrong with
> > default values defined at exynos4-cpu-thermal.dtsi?
> >
> > If this is Odroid XU3 specific, then IMHO it should
> > be added to exynos5422-odroidxu3.dts
> >
> >> + };
> >> + };
> >> + cooling-maps {
> >> + map0 {
> >> +  trip = <&cpu_alert0>;
> >> +  cooling-device = <&fan0 0 1>;
> >> + };
> >> + map1 {
> >> +  trip = <&cpu_alert1>;
> >> +  cooling-device = <&fan0 1 2>;
> >> + };
> >> + map2 {
> >> +  trip = <&cpu_alert2>;
> >> +  c

Re: [PATCH] Documentation/scheduler/sched-deadline.txt: correct definition of density as C_i/min{D_i,P_i}

[Juri Lelli]

Hi Luca,

On 03/04/15 11:52, Luca Abeni wrote:
> Hi,
> 
> On Fri, 3 Apr 2015 16:18:33 +0800
> Zhiqiang Zhang  wrote:
> 
>> >From the contex,the definition of the destiny of a task
>> C_i/min{D_i,T_i},where T_i is not referred before, should be
>> substituted by C_i/min{D_i,P_i}.
> You are right, "T_i" should be substituted with "P_i"...
> But now that I look at it more carefully, I think that "C_i" is also
> wrong... It should be "WCET_i".
> 
> 
> BTW, speaking about documentation: I still have some SCHED_DEADLINE
> documentation patches in my local tree... I'll update and send them in
> next week. Juri, should I send the patches to you, or submit directly
> to the mailing list?
> 

As you prefer, I'll review them anyway :). I guess you can just
send them on the list if you like, so that you'll receive more
comments in one go.

Thanks a lot,

- Juri

>   Thanks,
>   Luca
>>
>> 
>>
>> Signed-off-by: Zhiqiang Zhang 
>> ---
>>  Documentation/scheduler/sched-deadline.txt | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/scheduler/sched-deadline.txt
>> b/Documentation/scheduler/sched-deadline.txt index 21461a0..194664b
>> 100644 --- a/Documentation/scheduler/sched-deadline.txt
>> +++ b/Documentation/scheduler/sched-deadline.txt
>> @@ -169,8 +169,8 @@ CONTENTS
>>   of all the tasks executing on a CPU if and only if the total
>> utilisation of the tasks running on such a CPU is smaller or equal
>> than 1. If D_i != P_i for some task, then it is possible to define
>> the density of
>> - a task as C_i/min{D_i,T_i}, and EDF is able to respect all the
>> deadlines
>> - of all the tasks running on a CPU if the sum sum_i C_i/min{D_i,T_i}
>> of the
>> + a task as C_i/min{D_i,P_i}, and EDF is able to respect all the
>> deadlines
>> + of all the tasks running on a CPU if the sum sum_i C_i/min{D_i,P_i}
>> of the densities of the tasks running on such a CPU is smaller or
>> equal than 1 (notice that this condition is only sufficient, and not
>> necessary). 
> 

--
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] x86/setup: update boot_command_line with builtin_cmdline in separate function

[Alexander Kuleshov]

This patch introduces setup_cmdline function which appends/overrides
boot_command_linew with builtin_cmdline if CONFIG_CMDLINE_BOOL is set.
Previously this functional was in the setup_arch, but we need to move
it for getting actual command line as early as possible in the
arch/x86/kernel/head{32,64}.c

Signed-off-by: Alexander Kuleshov 
---
 arch/x86/kernel/head32.c |  1 +
 arch/x86/kernel/head64.c |  1 +
 arch/x86/kernel/setup.c  | 31 ++-
 include/linux/init.h |  6 +-
 4 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/head32.c b/arch/x86/kernel/head32.c
index 2911ef3..7ad0ad0 100644
--- a/arch/x86/kernel/head32.c
+++ b/arch/x86/kernel/head32.c
@@ -31,6 +31,7 @@ static void __init i386_default_early_setup(void)
 
 asmlinkage __visible void __init i386_start_kernel(void)
 {
+   setup_cmdline();
cr4_init_shadow();
sanitize_boot_params(&boot_params);
 
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index c4f8d46..6eea2de 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -171,6 +171,7 @@ asmlinkage __visible void __init x86_64_start_kernel(char * 
real_mode_data)
load_idt((const struct desc_ptr *)&idt_descr);
 
copy_bootdata(__va(real_mode_data));
+   setup_cmdline();
 
/*
 * Load microcode early on BSP.
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 0a2421c..d578f37 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -841,6 +841,24 @@ dump_kernel_offset(struct notifier_block *self, unsigned 
long v, void *p)
 }
 
 /*
+ * Append/Override boot command line with builtin command line if need
+ */
+void __init setup_cmdline(void) {
+#ifdef CONFIG_CMDLINE_BOOL
+#ifdef CONFIG_CMDLINE_OVERRIDE
+   strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+#else
+   if (builtin_cmdline[0]) {
+   /* append boot loader cmdline to builtin */
+   strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
+   strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
+   strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+   }
+#endif
+#endif
+}
+
+/*
  * Determine if we were loaded by an EFI loader.  If so, then we have also been
  * passed the efi memmap, systab, etc., so we should use these data structures
  * for initialization.  Note, the efi init code path is determined by the
@@ -968,19 +986,6 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = __pa_symbol(__bss_start);
bss_resource.end = __pa_symbol(__bss_stop)-1;
 
-#ifdef CONFIG_CMDLINE_BOOL
-#ifdef CONFIG_CMDLINE_OVERRIDE
-   strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-#else
-   if (builtin_cmdline[0]) {
-   /* append boot loader cmdline to builtin */
-   strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
-   strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
-   strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-   }
-#endif
-#endif
-
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
 
diff --git a/include/linux/init.h b/include/linux/init.h
index 2df8e8d..af8f2ec 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -152,7 +152,11 @@ void setup_arch(char **);
 void prepare_namespace(void);
 void __init load_default_modules(void);
 int __init init_rootfs(void);
-
+#ifdef CONFIG_CMDLINE_BOOL
+void __init setup_cmdline(void);
+#else
+static void __init setup_cmdline(void) {};
+#endif
 extern void (*late_time_init)(void);
 
 extern bool initcall_debug;
-- 
2.3.3.611.g09038fc.dirty

--
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/2] x86/earlyprintk: setup earlyprintk as early as possible

[Alexander Kuleshov]

As setup_early_printk passed to the early_param, it will be usable only after
'parse_early_param' function will be called from the 'setup_arch'. So we have
earlyprintk during early boot and decompression. Next point after decompression
of the kernel where we can use early_printk is after call of the
'parse_early_param'.

This patch provides initialization of earlyprintk serial console as early
as possible in the arch/x86/kerne/head{32,64}.c

Alexander Kuleshov (2):
  x86/setup: update boot_command_line with builtin_cmdline in separate
function
  x86/earlyprintk: setup earlyprintk as early as possible

 arch/x86/kernel/early_printk.c |  2 +-
 arch/x86/kernel/head.c | 14 ++
 arch/x86/kernel/head32.c   |  3 +++
 arch/x86/kernel/head64.c   |  8 +++-
 arch/x86/kernel/setup.c| 31 ++-
 include/linux/init.h   |  6 +-
 include/linux/printk.h |  4 
 kernel/printk/printk.c | 11 +++
 8 files changed, 59 insertions(+), 20 deletions(-)

-- 
2.3.3.611.g09038fc.dirty

--
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] x86/earlyprintk: setup earlyprintk as early as possible

[Alexander Kuleshov]

As setup_early_printk passed to the early_param, it will be usable only after
'parse_early_param' function will be called from the 'setup_arch'. So we have
earlyprintk during early boot and decompression. Next point after decompression
of the kernel where we can use early_printk is after call of the
'parse_early_param'.

This patch makes setup_early_printk visible for head{32,64}.c So 'early_printk'
function will be usabable after decompression of the kernel and before
parse_early_param will be called. It also must be safe if CONFIG_CMDLINE_BOOL
and CONFIG_CMDLINE_OVERRIDE are set, because setup_cmdline function will be
called before setup_early_printk.

Tested it with qemu, so early_printk() is usable and prints to serial console
right after setup_early_printk function called from arch/x86/kerne/head64.c

Changes v1->v2:

* Comment added before the setup_early_printk call;
* Added information about testing to the commit message.

Changes v2->v3:

* Call setup_cmdline before setup_early_printk;
* setup_early_printk call wrapped with the setup_early_serial_console which
checks that 'serial' given to the earlyprintk command line option. This
prevents call of the setup_early_printk with the given pciserial/dbgp/efi,
because they are using early_ioremap.

Signed-off-by: Alexander Kuleshov 
---
 arch/x86/kernel/early_printk.c |  2 +-
 arch/x86/kernel/head.c | 14 ++
 arch/x86/kernel/head32.c   |  2 ++
 arch/x86/kernel/head64.c   |  7 ++-
 include/linux/printk.h |  4 
 kernel/printk/printk.c | 11 +++
 6 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index a62536a..19a94e0 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -329,7 +329,7 @@ static inline void early_console_register(struct console 
*con, int keep_early)
register_console(early_console);
 }
 
-static int __init setup_early_printk(char *buf)
+int __init setup_early_printk(char *buf)
 {
int keep;
 
diff --git a/arch/x86/kernel/head.c b/arch/x86/kernel/head.c
index 992f442..b6e72aa 100644
--- a/arch/x86/kernel/head.c
+++ b/arch/x86/kernel/head.c
@@ -69,3 +69,17 @@ void __init reserve_ebda_region(void)
/* reserve all memory between lowmem and the 1MB mark */
memblock_reserve(lowmem, 0x10 - lowmem);
 }
+
+void setup_early_serial_console() {
+#ifdef CONFIG_EARLY_PRINTK
+   char *arg;
+
+   arg = strstr(boot_command_line, "earlyprintk=serial");
+   if (!arg)
+   arg = strstr(boot_command_line, "earlyprintk=ttyS");
+   if (!arg)
+   return;
+
+   setup_early_printk(boot_command_line);
+#endif
+}
diff --git a/arch/x86/kernel/head32.c b/arch/x86/kernel/head32.c
index 7ad0ad0..64c7a80 100644
--- a/arch/x86/kernel/head32.c
+++ b/arch/x86/kernel/head32.c
@@ -32,6 +32,8 @@ static void __init i386_default_early_setup(void)
 asmlinkage __visible void __init i386_start_kernel(void)
 {
setup_cmdline();
+   /* setup serial console as early as possible */
+   setup_early_serial_console();
cr4_init_shadow();
sanitize_boot_params(&boot_params);
 
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 6eea2de..f0c03bd 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -172,12 +172,15 @@ asmlinkage __visible void __init x86_64_start_kernel(char 
* real_mode_data)
 
copy_bootdata(__va(real_mode_data));
setup_cmdline();
+   /* setup serial console as early as possible */
+   setup_early_serial_console();
 
/*
 * Load microcode early on BSP.
 */
load_ucode_bsp();
 
+
if (console_loglevel >= CONSOLE_LOGLEVEL_DEBUG)
early_printk("Kernel alive\n");
 
@@ -193,8 +196,10 @@ asmlinkage __visible void __init x86_64_start_kernel(char 
* real_mode_data)
 void __init x86_64_start_reservations(char *real_mode_data)
 {
/* version is always not zero if it is copied */
-   if (!boot_params.hdr.version)
+   if (!boot_params.hdr.version) {
copy_bootdata(__va(real_mode_data));
+   setup_early_serial_console();
+   }
 
reserve_ebda_region();
 
diff --git a/include/linux/printk.h b/include/linux/printk.h
index baa3f97..17358dd 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -115,9 +115,13 @@ int no_printk(const char *fmt, ...)
 #ifdef CONFIG_EARLY_PRINTK
 extern asmlinkage __printf(1, 2)
 void early_printk(const char *fmt, ...);
+int setup_early_printk(char *buf);
+void setup_early_serial_console(void);
 #else
 static inline __printf(1, 2) __cold
 void early_printk(const char *s, ...) { }
+int setup_early_printk(char *buf) { }
+static void setup_early_serial_console(void) { }
 #endif
 
 typedef int(*printk_func_t)(const char *fmt, va_list args);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index bb0635b..e56285c 1