Re: [PATCH] drm: move allocation out of drm_get_format_name()
For the vmwgfx part:
Acked-by: Thomas Hellstrom
On 11/05/2016 08:33 AM, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
> Signed-off-by: Eric Engestrom
> [danvet: Clarify that the returned pointer must be freed with
> kfree().]
> Signed-off-by: Daniel Vetter
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Eric Engestrom
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 7 ++---
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 7 ++---
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 7 ++---
> drivers/gpu/drm/drm_atomic.c| 7 +++--
> drivers/gpu/drm/drm_crtc.c | 7 +++--
> drivers/gpu/drm/drm_fourcc.c| 12 +++-
> drivers/gpu/drm/drm_framebuffer.c | 7 +++--
> drivers/gpu/drm/drm_modeset_helper.c| 7 +++--
> drivers/gpu/drm/drm_plane.c | 7 +++--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 7 ++---
> drivers/gpu/drm/i915/i915_debugfs.c | 8 ++---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 8 ++---
> drivers/gpu/drm/i915/intel_display.c| 41
> ++---
> drivers/gpu/drm/radeon/atombios_crtc.c | 14 -
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +-
> include/drm/drm_fourcc.h| 3 +-
> 17 files changed, 71 insertions(+), 84 deletions(-)
>
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index dc0aafa..5a8cb4b 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -54,6 +54,7 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
> int drm_format_vert_chroma_subsampling(uint32_t format);
> int drm_format_plane_width(int width, uint32_t format, int plane);
> int drm_format_plane_height(int height, uint32_t format, int plane);
> -char *drm_get_format_name(uint32_t format) __malloc;
> +typedef char drm_format_name_buf[32];
> +char *drm_get_format_name(uint32_t format, drm_format_name_buf buf);
>
> #endif /* __DRM_FOURCC_H__ */
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index cbb8b77..34ed520 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t
> depth)
> EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>
> /**
> - * drm_get_format_name - return a string for drm fourcc format
> + * drm_get_format_name - fill a string with a drm fourcc format's name
> * @format: format to compute name of
> + * @buf: caller-supplied buffer
> - *
> - * Note that the buffer returned by this function is owned by the caller
> - * and will need to be freed using kfree().
> */
> -char *drm_get_format_name(uint32_t format)
> +char *drm_get_format_name(uint32_t format, drm_format_name_buf buf)
> {
> - char *buf = kmalloc(32, GFP_KERNEL);
> -
> - snprintf(buf, 32,
> + snprintf(buf, sizeof(drm_format_name_buf),
>"%c%c%c%c %s-endian (0x%08x)",
>printable_char(format & 0xff),
>printable_char((format >> 8) & 0xff),
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 199d3f7..cefa3d8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc
> *crtc,
> u32 tmp, viewport_w, viewport_h;
> int r;
> bool bypass_lut = false;
> - char *format_name;
> + drm_format_name_buf format_name;
>
> /* no fb bound */
> if (!atomic && !crtc->primary->fb) {
> @@ -2144,9 +2144,8 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc
> *crtc,
> bypass_lut = true;
> break;
> default:
> - format_name = drm_get_format_name(target_fb->pixel_format);
> - DRM_ERROR("Unsupported screen format %s\n", format_name);
> - kfree(format_name);
> + DRM_ERROR("Unsupported screen format %s\n",
> + drm_get_format_name(target_fb->pixel_format,
> format_name));
> return -EINVAL;
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index ecd000e..462abb8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -2013,7 +2013,7 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc
> *crtc,
> u32 tmp, viewport_w, viewport_h;
> int r;
> bool bypass_lut = false;
> - char *format_name;
> + drm_format_name_buf format_name;
>
> /* no fb bound */
> if (!atomic && !crtc->primary->fb) {
> @@ -2125,9 +2125,8 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc
Re: [PATCH 2/2] f2fs: don't skip recovering inode depend on i_times
On Sat, Nov 05, 2016 at 11:12:00AM +0800, Chao Yu wrote:
> On 2016/11/5 6:53, Jaegeuk Kim wrote:
> > On Fri, Nov 04, 2016 at 04:30:09PM +0800, Chao Yu wrote:
> >> On 2016/11/4 2:02, Jaegeuk Kim wrote:
> >>> On Fri, Nov 04, 2016 at 12:26:56AM +0800, Chao Yu wrote:
> From: Chao Yu
>
> i_times of inode will be set with current system time which can be
> configured through 'date', so it's not safe to judge dnode block as
> garbage data depend on i_times.
> >>>
> >>> This is not to detect garbage data, but to skip redundant unchanged inode.
> >>
> >> Oops, seems 807b1e1c8e08 ("f2fs: do not recover from previous remained
> >> wrong
> >> dnodes") did't describe like that. But after reading the codes, it looks
> >> like
> >> the purpose of this change is to skip unchanged inode. So, commit log in
> >> original is incorrect, right?
> >
> > Oh, right. This indicats both of purposes: stale data and detecting same
> > inodes.
>
> Alright.
>
> > Let me just revert the original patch.
>
> I can see that you have did reverting it in your git tree, but seems commit
> number is not right.
>
> Could you please merge my updated v2 patch instead?
Oops, yeah. :)
>
> Thanks,
>
> >
> > Thanks,
> >
> >>
> >> Thanks,
Re: [f2fs-dev] [PATCH 3/3 v2] f2fs: keep dirty inodes selectively for checkpoint
On Sat, Nov 05, 2016 at 10:44:07AM +0800, Chao Yu wrote: > On 2016/10/20 10:26, Jaegeuk Kim wrote: > > Change log from v1: > > o avoid performance regression > > > >>From b34a3d3c4c3fa2d6e000acc99bc5216a247bd6cb Mon Sep 17 00:00:00 2001 > > From: Jaegeuk Kim > > Date: Fri, 14 Oct 2016 11:51:23 -0700 > > Subject: [PATCH] f2fs: keep dirty inodes selectively for checkpoint > > > > This is to avoid no free segment bug during checkpoint caused by a number of > > dirty inodes. > > > > The case was reported by Chao like this. > > > > 1. mount with lazytime option > > 2. fragment space > > 3. touch all files in the image > > 4. umount > > > > In this case, we actually don't need to flush dirty inode to inode page > > during > > checkpoint. > > > > Reported-by: Chao Yu > > Signed-off-by: Jaegeuk Kim > > Good job! IMO, main job of checkpoint is to keep filesystem being consistent, > not flush dirty datas of vfs/fs as much as possible, if there are some > restrictions for the interface like fsync, syncfs, sync, the caller of > checkpoint() should do related job like marking lazytime inode I_DIRTY_SYNC or > flush last data in dirty inode into filesystem's cache, and so on. :) > > BTW, can you change commit log a bit as below: Okay, not a big deal. > > 1. mount with lazytime option > 2. fill 4k file until disk is full > 3. sync filesystem > 4. read all files in the image > 5. umount > > Reviewed-by: Chao Yu > > Thanks,
Re: [PATCH v2 1/2] ARM: imx: mmdc perf function support i.MX6QP
On Wed, Nov 02, 2016 at 01:00:03PM -0500, Frank Li wrote:
> i.MX6QP added new reigster bit PROFILE_SEL in MADPCR0.
s/reigster/register
> need set it at perf start.
>
> Signed-off-by: Frank Li
We probably need a 'for' in patch subject after 'support'?
> ---
> V1 to V2: remove fsl_mmdc_devtype
>
> arch/arm/mach-imx/mmdc.c | 38 --
> 1 file changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
> index d82d14c..032cbe0 100644
> --- a/arch/arm/mach-imx/mmdc.c
> +++ b/arch/arm/mach-imx/mmdc.c
> @@ -44,6 +44,7 @@
> #define DBG_RST 0x2
> #define PRF_FRZ 0x4
> #define CYC_OVF 0x8
> +#define PROFILE_SEL 0x10
>
> #define MMDC_MADPCR0 0x410
> #define MMDC_MADPSR0 0x418
> @@ -55,10 +56,29 @@
>
> #define MMDC_NUM_COUNTERS6
>
> +#define FSL_MMDC_QUIRK_PROFILE_SEL 0x1
> +
What about naming it MMDC_FLAG_PROFILE_SEL?
> #define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
>
> static int ddr_type;
>
> +struct fsl_mmdc_devtype_data {
> + int driver_data;
> +};
What about the following?
struct imx_mmdc_data {
unsigned int flags;
};
> +
> +static struct fsl_mmdc_devtype_data imx6q_data = {
> +};
> +
> +static struct fsl_mmdc_devtype_data imx6qp_data = {
> + .driver_data = FSL_MMDC_QUIRK_PROFILE_SEL,
> +};
Have a const for better?
> +
> +static const struct of_device_id imx_mmdc_dt_ids[] = {
> + { .compatible = "fsl,imx6q-mmdc", .data = (void *)&imx6q_data},
> + { .compatible = "fsl,imx6qp-mmdc", .data = (void *)&imx6qp_data},
> + { /* sentinel */ }
> +};
> +
> #ifdef CONFIG_PERF_EVENTS
>
> static DEFINE_IDA(mmdc_ida);
> @@ -83,6 +103,7 @@ struct mmdc_pmu {
> struct device *dev;
> struct perf_event *mmdc_events[MMDC_NUM_COUNTERS];
> struct hlist_node node;
> + struct fsl_mmdc_devtype_data *devtype_data;
mmdc_data
> };
>
> /*
> @@ -307,6 +328,7 @@ static void mmdc_pmu_event_start(struct perf_event
> *event, int flags)
> struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> struct hw_perf_event *hwc = &event->hw;
> void __iomem *mmdc_base, *reg;
> + int val;
Shouldn't it be u32 for better?
Shawn
>
> mmdc_base = pmu_mmdc->mmdc_base;
> reg = mmdc_base + MMDC_MADPCR0;
> @@ -321,7 +343,12 @@ static void mmdc_pmu_event_start(struct perf_event
> *event, int flags)
> local64_set(&hwc->prev_count, 0);
>
> writel(DBG_RST, reg);
> - writel(DBG_EN, reg);
> +
> + val = DBG_EN;
> + if (pmu_mmdc->devtype_data->driver_data & FSL_MMDC_QUIRK_PROFILE_SEL)
> + val |= PROFILE_SEL;
> +
> + writel(val, reg);
> }
>
> static int mmdc_pmu_event_add(struct perf_event *event, int flags)
> @@ -436,6 +463,8 @@ static int imx_mmdc_perf_init(struct platform_device
> *pdev, void __iomem *mmdc_b
> char *name;
> int mmdc_num;
> int ret;
> + const struct of_device_id *of_id =
> + of_match_device(imx_mmdc_dt_ids, &pdev->dev);
>
> pmu_mmdc = kzalloc(sizeof(*pmu_mmdc), GFP_KERNEL);
> if (!pmu_mmdc) {
> @@ -450,6 +479,8 @@ static int imx_mmdc_perf_init(struct platform_device
> *pdev, void __iomem *mmdc_b
> name = devm_kasprintf(&pdev->dev,
> GFP_KERNEL, "mmdc%d", mmdc_num);
>
> + pmu_mmdc->devtype_data = (struct fsl_mmdc_devtype_data *)of_id->data;
> +
> hrtimer_init(&pmu_mmdc->hrtimer, CLOCK_MONOTONIC,
> HRTIMER_MODE_REL);
> pmu_mmdc->hrtimer.function = mmdc_pmu_timer_handler;
> @@ -524,11 +555,6 @@ int imx_mmdc_get_ddr_type(void)
> return ddr_type;
> }
>
> -static const struct of_device_id imx_mmdc_dt_ids[] = {
> - { .compatible = "fsl,imx6q-mmdc", },
> - { /* sentinel */ }
> -};
> -
> static struct platform_driver imx_mmdc_driver = {
> .driver = {
> .name = "imx-mmdc",
> --
> 2.5.2
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH] mtd: nand: denali_pci: add missing pci_release_regions() calls
On 11/02/2016 06:13 PM, Masahiro Yamada wrote:
> The probe function calls pci_request_regions(), but I do not see
> corresponding pci_release_regions() calls.
>
> While we are here, rename the jump labels to follow the guideline
> "Choose label names which say what the goto does" suggested by
> Documentation/CodingStyle.
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Marek Vasut
> ---
>
> drivers/mtd/nand/denali_pci.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
> index de31514..be8152f 100644
> --- a/drivers/mtd/nand/denali_pci.c
> +++ b/drivers/mtd/nand/denali_pci.c
> @@ -76,28 +76,31 @@ static int denali_pci_probe(struct pci_dev *dev, const
> struct pci_device_id *id)
> denali->flash_reg = ioremap_nocache(csr_base, csr_len);
> if (!denali->flash_reg) {
> dev_err(&dev->dev, "Spectra: Unable to remap memory region\n");
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto release_regions;
> }
>
> denali->flash_mem = ioremap_nocache(mem_base, mem_len);
> if (!denali->flash_mem) {
> dev_err(&dev->dev, "Spectra: ioremap_nocache failed!");
> ret = -ENOMEM;
> - goto failed_remap_reg;
> + goto unmap_reg;
> }
>
> ret = denali_init(denali);
> if (ret)
> - goto failed_remap_mem;
> + goto unmap_mem;
>
> pci_set_drvdata(dev, denali);
>
> return 0;
>
> -failed_remap_mem:
> +unmap_mem:
> iounmap(denali->flash_mem);
> -failed_remap_reg:
> +unmap_reg:
> iounmap(denali->flash_reg);
> +release_regions:
> + pci_release_regions(dev);
> return ret;
> }
>
> @@ -109,6 +112,7 @@ static void denali_pci_remove(struct pci_dev *dev)
> denali_remove(denali);
> iounmap(denali->flash_reg);
> iounmap(denali->flash_mem);
> + pci_release_regions(dev);
> }
>
> static struct pci_driver denali_pci_driver = {
>
--
Best regards,
Marek Vasut
Re: [PATCH v1 1/2] mtd: m25p80: lock module while used
On 11/03/2016 12:39 PM, Sandeep Jain wrote:
> Dear Maintainers,
> Requesting for your attention for patch review/merge.
>
> Thanks & Regards,
> Sandeep Jain
>
> On Thu, Aug 04, 2016 at 07:46:33PM +0530, Sandeep Jain wrote:
>> From: Vladimir Zapolskiy
>>
>> The change controls module users counter, which prevents to get
>> accidental oops on module unload while it is in use by mtd subsystem:
>>
>> % dd if=/dev/mtd0 of=/dev/null &
>> % rmmod m25p80
>>
>> Removing MTD device #0 (spi32766.0) with use count 1
>> Unable to handle kernel paging request at virtual address 7f4fb7f8
>> pgd = bd094000
>> [7f4fb7f8] *pgd=4cb66811, *pte=, *ppte=
>> Internal error: Oops: 8007 [#1] PREEMPT SMP ARM
>>
>> Signed-off-by: Vladimir Zapolskiy
>> Signed-off-by: Sandeep Jain
>> ---
>> drivers/mtd/devices/m25p80.c | 15 +++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index 9cf7fcd..2eb1530 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -185,6 +185,19 @@ static ssize_t m25p80_read(struct spi_nor *nor, loff_t
>> from, size_t len,
>> return ret;
>> }
>>
>> +static void m25p80_put(struct mtd_info *mtd)
>> +{
>> +module_put(THIS_MODULE);
>> +}
>> +
>> +static int m25p80_get(struct mtd_info *mtd)
>> +{
>> +if (!try_module_get(THIS_MODULE))
>> +return -ENODEV;
>> +
>> +return 0;
>> +}
>> +
>> /*
>> * board specific setup should have ensured the SPI clock used here
>> * matches what the READ command supports, at least until this driver
>> @@ -212,6 +225,8 @@ static int m25p_probe(struct spi_device *spi)
>> nor->write = m25p80_write;
>> nor->write_reg = m25p80_write_reg;
>> nor->read_reg = m25p80_read_reg;
>> +nor->mtd._put_device = m25p80_put;
>> +nor->mtd._get_device = m25p80_get;
>>
>> nor->dev = &spi->dev;
>> spi_nor_set_flash_node(nor, spi->dev.of_node);
This makes me ponder how many other drivers suffer from this issue and
whether you shouldn't fix this in the core code instead. What do you think?
--
Best regards,
Marek Vasut
Re: [PATCH] mtd: Allocate bdi objects dynamically
On 11/03/2016 12:34 PM, Sandeep Jain wrote: > Dear Maintainers, > This patch is reviewed by Richard. > Requesting for Maintainer's attention for patch merge. > > Thanks & Regards, > Sandeep Jain > > On Sat, Sep 17, 2016 at 04:41:47PM +0200, Richard Weinberger wrote: >> On Thu, Aug 4, 2016 at 4:01 PM, Sandeep Jain wrote: >>> From: Steve Longerbeam >>> >>> The MTD backing dev info objects mtd_bdi was statically allocated. >>> So when MTD is built as a loadable module, this object fall in the >>> vmalloc address space. >>> >>> The problem with that, is that the BDI APIs use wake_up_bit(), which calls >>> virt_to_page() to retrieve the memory zone of the page containing the >>> wait_queue to wake up, and virt_to_page() is not valid for vmalloc or >>> highmem addresses. >>> >>> Fix this by allocating the BDI objects dynamically with kmalloc. The >>> objects now fall in the logical address space so that BDI APIs will >>> work in all cases (mtd builtin or module). >>> >>> Signed-off-by: Steve Longerbeam >>> Signed-off-by: Jim Baxter >>> Signed-off-by: Sandeep Jain >> >> Reviewed-by: Richard Weinberger I don't see any obvious problem either: Reviewed-by: Marek Vasut -- Best regards, Marek Vasut
Re: [PATCH] mtd: nand: denali_dt: replace clk_disable() with clk_disable_unprepare()
On 11/02/2016 06:21 PM, Masahiro Yamada wrote: > The denali_dt_probe() calls clk_disable_unprepare() in the bailout > path, whereas denali_dt_remove calls clk_disable(), inconsistently. > Replace the latter with clk_disable_unprepare() to make sure to > unprepare the clock. > > Signed-off-by: Masahiro Yamada Reviewed-by: Marek Vasut > --- > > drivers/mtd/nand/denali_dt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c > index 0cb1e8d..f821dc1 100644 > --- a/drivers/mtd/nand/denali_dt.c > +++ b/drivers/mtd/nand/denali_dt.c > @@ -110,7 +110,7 @@ static int denali_dt_remove(struct platform_device *ofdev) > struct denali_dt *dt = platform_get_drvdata(ofdev); > > denali_remove(&dt->denali); > - clk_disable(dt->clk); > + clk_disable_unprepare(dt->clk); > > return 0; > } > -- Best regards, Marek Vasut
Re: [PATCH 00/22] mtd: nand: return error code of nand_scan(_ident, _tail) on error
On 11/04/2016 11:42 AM, Masahiro Yamada wrote: > > nand_scan(), nand_scan_ident(), nand_scan_tail() return > an appropriate negative value on error. > > Most of drivers return the value from them on error, > but some of them return the fixed error code -ENXIO > (and a few return -ENODEV). > > This series make those drivers return more precise error code. > Reviewed-by: Marek Vasut Nice cleanup, thanks! -- Best regards, Marek Vasut
Re: [PATCH V2 2/2] ARM: dts: add new compatible stream for i.MX6QP mmdc
On Wed, Nov 02, 2016 at 01:00:04PM -0500, Frank Li wrote:
> mmdc of i.MX6QP are little difference with i.MX6Q.
> added new compatible stream fsl,imx6qp-mmdc
s/stream/string
>
> Signed-off-by: Frank Li
> ---
> No change for this patch.
> suspend resume code need fsl,imx6q-mmdc
You should probably add such info into commit log, e.g. although
MMDC has a slightly different programming model between imx6q and imx6qp
in terms of perf support, it's exactly same for suspend support, so we
have fsl,imx6q-mmdc here to save patching suspend driver with the new
compatible.
>
> arch/arm/boot/dts/imx6qp.dtsi | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qp.dtsi b/arch/arm/boot/dts/imx6qp.dtsi
> index 886dbf2..e0fdd0f 100644
> --- a/arch/arm/boot/dts/imx6qp.dtsi
> +++ b/arch/arm/boot/dts/imx6qp.dtsi
> @@ -85,5 +85,12 @@
> pcie: pcie@0x0100 {
> compatible = "fsl,imx6qp-pcie", "snps,dw-pcie";
> };
> +
> + aips-bus@0210 {
> + mmdc0: mmdc@021b { /* MMDC0 */
> + compatible = "fsl,imx6qp-mmdc",
> "fsl,imx6q-mmdc";
> + reg = <0x021b 0x4000>;
> + };
> + };
It seems that pcie already went wrong, but please still try to add
devices in order of unit-address.
Shawn
> };
> };
> --
> 2.5.2
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[RFC][PATCH] mm: merge as soon as possible when pcp alloc/free
Usually the memory of android phones is very small, so after a long running, the fragment is very large. Kernel stack which called by alloc_thread_stack_node() usually alloc 16K memory, and it failed frequently. However we have CONFIG_VMAP_STACK now, but it do not support arm64, and maybe it has some regression because of vmalloc, it need to find an area and create page table dynamically, this will take a short time. I think we can merge as soon as possible when pcp alloc/free to reduce fragment. The pcp page is hot page, so free it will cause cache miss, I use perf to test it, but it seems the regression is not so much, maybe it need to test more. Any reply is welcome. no patch: perf stat -e cache-misses make -j50 Kernel: arch/x86/boot/bzImage is ready (#10) Performance counter stats for 'make -j50': 17,845,292,704 cache-misses 157.605906725 seconds time elapsed patched: perf stat -e cache-misses make -j50 Kernel: arch/x86/boot/bzImage is ready (#8) Performance counter stats for 'make -j50': 17,876,726,774 cache-misses 156.293720662 seconds time elapsed nopatch: make clean, dropcache, then make -j50, CONFIG_VMAP_STACK is off [root@localhost ~]# cat /proc/buddyinfo Node 0, zone DMA 3 0 2 1 3 2 2 1 0 1 3 Node 0, zoneDMA32 4 4 1 5 2 4 2 2 3 1447 Node 0, zone Normal 2389418668707738451246 93 42 21 15147 Node 1, zone Normal 1137386583631878311 80 12 2 8 15640 Node 2, zone Normal 1875230323462729453177 67 12 9 15749 Node 3, zone Normal 1675452503898928628256 70 25 14 11688 Node 4, zone Normal 1917407306 2706 1722909477218 54 34 15682 Node 5, zone Normal 4330 9785 6265 2612 1404703276113 33 7 15730 Node 6, zone Normal754211 1093 1023748599352193 107 43 15672 Node 7, zone Normal 1092133819807729549254120 52 28 15500 [root@localhost ~]# cat /sys/kernel/debug/extfrag/unusable_index Node 0, zone DMA 0.000 0.000 0.000 0.002 0.004 0.016 0.032 0.065 0.097 0.097 0.226 Node 0, zoneDMA32 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.001 0.002 0.004 Node 0, zone Normal 0.000 0.000 0.000 0.000 0.000 0.001 0.002 0.003 0.004 0.004 0.005 Node 1, zone Normal 0.000 0.000 0.000 0.000 0.000 0.001 0.002 0.002 0.002 0.002 0.002 Node 2, zone Normal 0.000 0.000 0.000 0.000 0.000 0.001 0.002 0.002 0.003 0.003 0.003 Node 3, zone Normal 0.000 0.000 0.000 0.000 0.000 0.002 0.003 0.005 0.005 0.006 0.007 Node 4, zone Normal 0.000 0.000 0.000 0.000 0.001 0.003 0.005 0.006 0.008 0.009 0.010 Node 5, zone Normal 0.000 0.000 0.001 0.003 0.004 0.005 0.007 0.008 0.009 0.009 0.009 Node 6, zone Normal 0.000 0.000 0.000 0.000 0.000 0.001 0.002 0.004 0.005 0.007 0.008 Node 7, zone Normal 0.000 0.000 0.000 0.000 0.000 0.001 0.002 0.003 0.004 0.005 0.006 patched: make clean, dropcache, then make -j50, CONFIG_VMAP_STACK is off [root@localhost ~]# cat /proc/buddyinfo Node 0, zone DMA 1 1 2 1 3 2 2 1 0 1 3 Node 0, zoneDMA32 3 3 0 2 2 4 2 2 3 1447 Node 0, zone Normal 1293 1097159564620392242 89 49 21 15154 Node 1, zone Normal 1195369155 73295260 92 32 8 10 15769 Node 2, zone Normal 1478434160846 1397590274118 39 25 15753 Node 3, zone Normal892285176625691450226 78 33 14 11596 Node 4, zone Normal604217 28468 1560690292126 46 31 15741 Node 5, zone Normal888225101263483319196 97 30 24 15726 Node 6, zone Normal 1908 9294 7075 3373 1765759243128 21 20 15591 Node 7, zone Normal 1362 1126 1271646558377170 84 37 35 15602 [root@localhost ~]# cat /sys/kernel/debug/extfrag/unusable_index Node 0, zone DMA 0.000 0.000 0.000 0.002 0.004 0.016 0.032 0.065 0.097 0.097 0.226 Node 0, zoneDMA32 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.001 0.002 0.004 Node 0, zone Normal 0.000 0.000 0.000 0.000 0.000 0.001 0.001 0.002 0.003 0.004 0.005 Node 1, zone Normal 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.001 0.001 0.001 0.001 Node 2, zone Normal 0.000 0.000 0.000 0.000 0.000 0.002 0.003 0.004 0.005 0.005 0.006 Node 3, zone Normal 0.000 0.000 0.000 0.000 0.000 0.001 0.002 0.003 0.004 0.005 0.005 Node 4, zone Normal 0.000 0.000 0.000 0.000 0.000 0.001 0.003 0.004 0.005 0.006 0.007 Node 5, zone
[PATCH v2 1/1] ARM: dmaengine: sun6i: share the dma driver with sun50i
Add soc a64 dma support.
Signed-off-by: Hao Zhang
---
drivers/dma/sun6i-dma.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 8346199..00fcfc7 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -1028,11 +1028,23 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
.nr_max_vchans = 34,
};
+/*
+ * The A64 has 8 physical channels, a maximum DRQ port id of 27,
+ * and a total of 38 usable source and destination endpoints.
+ */
+
+static struct sun6i_dma_config sun50i_a64_dma_cfg = {
+ .nr_max_channels = 8,
+ .nr_max_requests = 27,
+ .nr_max_vchans = 38,
+};
+
static const struct of_device_id sun6i_dma_match[] = {
{ .compatible = "allwinner,sun6i-a31-dma", .data = &sun6i_a31_dma_cfg },
{ .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
{ .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg
},
{ .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
+ { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg
},
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun6i_dma_match);
@@ -1110,6 +1122,13 @@ static int sun6i_dma_probe(struct platform_device *pdev)
sdc->slave.dst_addr_widths =
BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+
+ if (of_device_is_compatible(pdev->dev.of_node,
+ "allwinner,sun50i-a64-dma")) {
+ sdc->slave.src_addr_widths |=
BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
+ sdc->slave.dst_addr_widths |=
BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
+ }
+
sdc->slave.directions = BIT(DMA_DEV_TO_MEM) |
BIT(DMA_MEM_TO_DEV);
sdc->slave.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
--
2.7.4
[PATCH v2 0/1] ARM: dmaengine: sun6i: share the dma driver with sun50i
Hi, This patch add the allwinner soc a64 dma support on already done driver sun6i-dma. A64 is a 64bit SOC, it has 8 channel DMA which flexible data width of 8/16/32/64-bit. Detailed info about it is on Allwinner_A64_User_Manual_V1.0 page 196 and A64_Datasheet_V1.1 page 8. Due to the patch of clocks, device tree and other support for a64 is not merged, this patch does not contain the support about them. It has been test on pin64 using dmatest. Regards, Hao Zhang
Re: [PATCH v3 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
Hi Laurent,
Thanks for your prompt reply. I will fix them in patch v4.
On Sat, 2016-11-05 at 01:32 +0200, Laurent Pinchart wrote:
> Hi Rick,
>
> Thank you for the patch.
>
> On Friday 04 Nov 2016 13:51:18 Rick Chang wrote:
> > Add a DT binding documentation for Mediatek JPEG Decoder of
> > MT2701 SoC.
>
> This version looks much better !
I'm glad to hear that!
> > Signed-off-by: Rick Chang
> > Signed-off-by: Minghsiu Tsai
> > ---
> > .../bindings/media/mediatek-jpeg-codec.txt | 35 +++
> > 1 file changed, 35 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt new file
> > mode 100644
> > index 000..b2b19ed
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > @@ -0,0 +1,35 @@
> > +* Mediatek JPEG Decoder
> > +
> > +Mediatek JPEG Decoder is the JPEG decode hw present in Mediatek SoCs
>
> Nitpicking, I'd write hardware instead of hw.
OK.
> > +Required properties:
> > +- compatible : "mediatek,mt2701-jpgdec"
>
> As commented on the previous version, is this JPEG decoder unique to the
> MT2701, or is it also used (possibly with different interrupts, clocks, ...)
> in other SoCs ? In the latter case, if the JPEG decoder IP core is identical
> in multiple SoCs, a more generic compatible string would be better.
I understand your question. The essence of this patch series targeting
is the JPEG decoder IP which is integrated in mt2701.I will check it
with our hardware engineer and making a more generic compatible string
if the IP is used in multiple SoCs.
> > +- reg : physical base address of the jpeg decoder registers and length of
> > + memory mapped region.
> > +- interrupts : interrupt number to the interrupt controller.
> > +- clocks: device clocks, see
> > + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> > +- clock-names: must contain "jpgdec-smi" and "jpgdec".
> > +- power-domains: a phandle to the power domain, see
> > + Documentation/devicetree/bindings/power/power_domain.txt for details.
> > +- mediatek,larb: must contain the local arbiters in the current Socs, see
> > +
> > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > + for details.
> > +- iommus: should point to the respective IOMMU block with master port as
> > + argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> > + for details.
> > +
> > +Example:
> > + jpegdec: jpegdec@15004000 {
> > + compatible = "mediatek,mt2701-jpgdec";
> > + reg = <0 0x15004000 0 0x1000>;
> > + interrupts = ;
> > + clocks = <&imgsys CLK_IMG_JPGDEC_SMI>,
> > + <&imgsys CLK_IMG_JPGDEC>;
> > + clock-names = "jpgdec-smi",
> > + "jpgdec";
> > + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
> > + mediatek,larb = <&larb2>;
> > + iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>,
> > +<&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
> > + };
>
Re: [PATCH v4 2/6] Add Advantech iManager GPIO driver
On Wed, Nov 2, 2016 at 9:37 AM, Richard Vidal-Dorsch
wrote:
> Signed-off-by: Richard Vidal-Dorsch
> +#include
> +#include
#include
should be enough.
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define EC_GPIOF_DIR_OUT BIT(6)
> +#define EC_GPIOF_DIR_INBIT(7)
> +
> +struct imanager_gpio_data {
> + struct imanager_device_data *imgr;
> + struct gpio_chip chip;
> +};
Maybe some kerneldoc for this. Not necessary though since its sort of
self-explanatory.
> +static int imanager_gpio_direction_in(struct gpio_chip *chip, uint offset)
> +{
> + struct imanager_gpio_data *data = gpiochip_get_data(chip);
> + struct imanager_device_data *imgr = data->imgr;
> + struct imanager_device_attribute *attr = imgr->ec.gpio.attr[offset];
> +
> + mutex_lock(&imgr->lock);
> + imanager_write8(&imgr->ec, EC_CMD_GPIO_DIR_WR, attr->did,
> + EC_GPIOF_DIR_IN);
> + mutex_unlock(&imgr->lock);
It kind of looks like it would be smarter if the imanager_write8() was
taking and releasing the lock so you don't have to do it everywhere.
> +static int imanager_gpio_get_direction(struct gpio_chip *chip, uint offset)
> +{
> + struct imanager_gpio_data *data = gpiochip_get_data(chip);
> + struct imanager_device_data *imgr = data->imgr;
> + struct imanager_device_attribute *attr = imgr->ec.gpio.attr[offset];
> + int ret;
> +
> + mutex_lock(&imgr->lock);
> + ret = imanager_read8(&imgr->ec, EC_CMD_GPIO_DIR_RD, attr->did);
> + mutex_unlock(&imgr->lock);
> +
> + return ret & EC_GPIOF_DIR_IN ? GPIOF_DIR_IN : GPIOF_DIR_OUT;
Don't use GPIOF* flags, those are for consumers. Just return 0/1.
> +static int imanager_gpio_get(struct gpio_chip *chip, uint offset)
> +{
> + struct imanager_gpio_data *data = gpiochip_get_data(chip);
> + struct imanager_device_data *imgr = data->imgr;
> + struct imanager_device_attribute *attr = imgr->ec.gpio.attr[offset];
> + int ret;
> +
> + mutex_lock(&imgr->lock);
> + ret = imanager_read8(&imgr->ec, EC_CMD_HWP_RD, attr->did);
> + mutex_unlock(&imgr->lock);
> +
> + return ret;
> +}
Can the read function return an error code? In that case it should be checked
everywhere.
Also be sure to clamp ret like this:
return !!ret;
Apart from this it looks good.
Yours,
Linus Walleij
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > > 4.9-rc2 has bios_limit: > > > > pavel@duo:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit > > 1833000 > > > > and it has thermal zones: > > > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp 127000 > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_type critical > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp 97000 > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_type critical > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_temp 92500 > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_type passive > > > It will not act if there is no binding information. Do you have more > files in this folder? > > grep -r . * in /sys/class/thermal will be helpful. Yes, I do. Here you go: pavel@duo:/data/l/linux$ sudo grep -ri . /sys/class/thermal/* /sys/class/thermal/cooling_device0/cur_state:0 /sys/class/thermal/cooling_device0/power/runtime_active_kids:0 /sys/class/thermal/cooling_device0/power/runtime_suspended_time:0 grep: /sys/class/thermal/cooling_device0/power/autosuspend_delay_ms: Input/output error /sys/class/thermal/cooling_device0/power/runtime_enabled:disabled /sys/class/thermal/cooling_device0/power/runtime_active_time:0 /sys/class/thermal/cooling_device0/power/control:auto /sys/class/thermal/cooling_device0/power/async:disabled /sys/class/thermal/cooling_device0/power/runtime_usage:0 /sys/class/thermal/cooling_device0/power/runtime_status:unsupported /sys/class/thermal/cooling_device0/type:LCD /sys/class/thermal/cooling_device0/max_state:7 /sys/class/thermal/cooling_device1/cur_state:0 /sys/class/thermal/cooling_device1/power/runtime_active_kids:0 /sys/class/thermal/cooling_device1/power/runtime_suspended_time:0 grep: /sys/class/thermal/cooling_device1/power/autosuspend_delay_ms: Input/output error /sys/class/thermal/cooling_device1/power/runtime_enabled:disabled /sys/class/thermal/cooling_device1/power/runtime_active_time:0 /sys/class/thermal/cooling_device1/power/control:auto /sys/class/thermal/cooling_device1/power/async:disabled /sys/class/thermal/cooling_device1/power/runtime_usage:0 /sys/class/thermal/cooling_device1/power/runtime_status:unsupported /sys/class/thermal/cooling_device1/type:Processor /sys/class/thermal/cooling_device1/max_state:10 /sys/class/thermal/cooling_device2/cur_state:0 /sys/class/thermal/cooling_device2/power/runtime_active_kids:0 /sys/class/thermal/cooling_device2/power/runtime_suspended_time:0 grep: /sys/class/thermal/cooling_device2/power/autosuspend_delay_ms: Input/output error /sys/class/thermal/cooling_device2/power/runtime_enabled:disabled /sys/class/thermal/cooling_device2/power/runtime_active_time:0 /sys/class/thermal/cooling_device2/power/control:auto /sys/class/thermal/cooling_device2/power/async:disabled /sys/class/thermal/cooling_device2/power/runtime_usage:0 /sys/class/thermal/cooling_device2/power/runtime_status:unsupported /sys/class/thermal/cooling_device2/type:Processor /sys/class/thermal/cooling_device2/max_state:10 /sys/class/thermal/thermal_zone0/passive:0 /sys/class/thermal/thermal_zone0/available_policies:step_wise /sys/class/thermal/thermal_zone0/policy:step_wise /sys/class/thermal/thermal_zone0/mode:enabled grep: /sys/class/thermal/thermal_zone0/offset: Input/output error grep: /sys/class/thermal/thermal_zone0/integral_cutoff: Input/output error /sys/class/thermal/thermal_zone0/power/runtime_active_kids:0 /sys/class/thermal/thermal_zone0/power/runtime_suspended_time:0 grep: /sys/class/thermal/thermal_zone0/power/autosuspend_delay_ms: Input/output error /sys/class/thermal/thermal_zone0/power/runtime_enabled:disabled /sys/class/thermal/thermal_zone0/power/runtime_active_time:0 /sys/class/thermal/thermal_zone0/power/control:auto /sys/class/thermal/thermal_zone0/power/async:disabled /sys/class/thermal/thermal_zone0/power/runtime_usage:0 /sys/class/thermal/thermal_zone0/power/runtime_status:unsupported grep: /sys/class/thermal/thermal_zone0/k_d: Input/output error /sys/class/thermal/thermal_zone0/trip_point_0_type:critical /sys/class/thermal/thermal_zone0/type:acpitz grep: /sys/class/thermal/thermal_zone0/slope: Input/output error grep: /sys/class/thermal/thermal_zone0/k_po: Input/output error grep: /sys/class/thermal/thermal_zone0/k_i: Input/output error grep: /sys/class/thermal/thermal_zone0/sustainable_power: Input/output error /sys/class/thermal/thermal_zone0/trip_point_0_temp:127000 grep: /sys/class/thermal/thermal_zone0/k_pu: Input/output error /sys/class/thermal/thermal_zone0/temp:58000 /sys/class/thermal/thermal_zone1/available_policies:step_wise /sys/class/thermal/thermal_zone1/policy:step_wise /sys/class/thermal/thermal_zone1/mode:enabled /sys/class/thermal/thermal_zone1/trip_point_1_type:passive grep: /sys/class/thermal/thermal_zone1/offset: Input/output error grep: /sys/class/thermal/thermal_zone1/integral_cutoff: Input/output error /sys/class/thermal/thermal_zone1/power/runtime_active_kids:0 /sys/class/thermal/thermal_zone1/power/runtime_suspended_time:0
[PATCH v2] KVM: nVMX: add tracepoint for vmwrite
Both the field and the value are in registers, so they are not clear from
existing tracepoints.
Cc: Ladi Prosek
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/trace.h | 23 +++
arch/x86/kvm/vmx.c | 2 ++
arch/x86/kvm/x86.c | 1 +
3 files changed, 26 insertions(+)
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 0a6cc6754ec5..b3d4dec78ae2 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -723,6 +723,29 @@ TRACE_EVENT(kvm_skinit,
flags; \
})
+/*
+ * Tracepoint for nested #vmexit because of vmwrite
+ */
+TRACE_EVENT(kvm_vmwrite,
+ TP_PROTO(__u64 vmptr, __u16 field, __u64 value),
+ TP_ARGS(vmptr, field, value),
+
+ TP_STRUCT__entry(
+ __field(__u64, vmptr )
+ __field(__u16, field )
+ __field(__u64, value )
+ ),
+
+ TP_fast_assign(
+ __entry->vmptr = vmptr;
+ __entry->field = field;
+ __entry->value = value;
+ ),
+
+ TP_printk("vmcs: 0x%016llx field: 0x%04x value: 0x%llx",
+ __entry->vmptr, __entry->field, __entry->value)
+);
+
TRACE_EVENT(kvm_emulate_insn,
TP_PROTO(struct kvm_vcpu *vcpu, __u8 failed),
TP_ARGS(vcpu, failed),
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 5382b82462fc..e7d01d7d350b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7474,6 +7474,7 @@ static int handle_vmwrite(struct kvm_vcpu *vcpu)
{
unsigned long field;
gva_t gva;
+ struct vcpu_vmx *vmx = to_vmx(vcpu);
unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
u32 vmx_instruction_info = vmcs_read32(VMX_INSTRUCTION_INFO);
/* The value to write might be 32 or 64 bits, depending on L1's long
@@ -7512,6 +7513,7 @@ static int handle_vmwrite(struct kvm_vcpu *vcpu)
return 1;
}
+ trace_kvm_vmwrite(vmx->nested.current_vmptr, field, field_value);
if (vmcs12_write_any(vcpu, field, field_value) < 0) {
nested_vmx_failValid(vcpu, VMXERR_UNSUPPORTED_VMCS_COMPONENT);
skip_emulated_instruction(vcpu);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 7e30c720d0c5..2be66e90f297 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8495,3 +8495,4 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_pml_full);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_pi_irte_update);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_unaccelerated_access);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_incomplete_ipi);
+EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_vmwrite);
--
2.7.4
Re: [PATCH v6 7/7] arm64: dts: NS2: add AMAC ethernet support
On 11/4/2016 7:30 PM, Jon Mason wrote:
Add support for the AMAC ethernet to the Broadcom Northstar2 SoC device
tree
Signed-off-by: Jon Mason
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 5 +
arch/arm64/boot/dts/broadcom/ns2.dtsi| 12
2 files changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index b09f3bc..c4d5442 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -56,6 +56,10 @@
};
};
+&enet {
+ status = "ok";
The spec dictates it should be "okay" (although "ok" is also recognized).
The rest of the file uses "ok". So, the addition above is consistent
with the other entries.
Perhaps a patch outside this series to convert the entire file from
"ok" to "okay" would be acceptable to you.
OK, it would...
Thanks,
Jon
MBR, Sergei
Re: [PATCH net-next 2/2] net: phy: Add Meson GXL Internal PHY driver
On Fri, Nov 04, 2016 at 04:51:23PM +0100, Neil Armstrong wrote: > Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs. > > This PHY seems to only implement some standard registers and need some > workarounds to provide autoneg values from vendor registers. > > Some magic values are currently used to configure the PHY, and this a > temporary setup until clarification about these registers names and > registers fields are provided by Amlogic. > > Signed-off-by: Neil Armstrong Reviewed-by: Andrew Lunn Andrew
[GIT PULL for v4.9-rc4] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.9-3 For a series of fixup patches meant to fix the usage of DMA on stack, plus one warning fixup. --- PS.: I tried to send it earlier, but I was unable to send this patch series from Santa Fé. I guess kernel.org doesn't like very much a different IP block than the one I usually use. The following changes since commit 9fce0c226536fc36c7fb0a8ca38a995be43e: Merge tag 'v4.8' into patchwork (2016-10-05 16:43:53 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.9-3 for you to fetch changes up to 1aeb5b615cd10db7324d4e4d167c4916dfeca311: [media] radio-bcm2048: don't ignore errors (2016-10-17 12:13:36 -0200) media fixes for v4.9-rc4 Mauro Carvalho Chehab (31): [media] af9005: don't do DMA on stack [media] cinergyT2-core: don't do DMA on stack [media] cinergyT2-core: handle error code on RC query [media] cinergyT2-fe: cache stats at cinergyt2_fe_read_status() [media] cinergyT2-fe: don't do DMA on stack [media] cxusb: don't do DMA on stack [media] dib0700: be sure that dib0700_ctrl_rd() users can do DMA [media] dib0700_core: don't use stack on I2C reads [media] dibusb: don't do DMA on stack [media] dibusb: handle error code on RC query [media] digitv: don't do DMA on stack [media] dtt200u-fe: don't keep waiting for lock at set_frontend() [media] dtt200u-fe: don't do DMA on stack [media] dtt200u-fe: handle errors on USB control messages [media] dtt200u: don't do DMA on stack [media] dtt200u: handle USB control message errors [media] dtv5100: don't do DMA on stack [media] gp8psk: don't do DMA on stack [media] gp8psk: don't go past the buffer size [media] nova-t-usb2: don't do DMA on stack [media] pctv452e: don't do DMA on stack [media] pctv452e: don't call BUG_ON() on non-fatal error [media] technisat-usb2: use DMA buffers for I2C transfers [media] nova-t-usb2: handle error code on RC query [media] dw2102: return error if su3000_power_ctrl() fails [media] digitv: handle error code on RC query [media] cpia2_usb: don't use stack for DMA [media] s2255drv: don't use stack for DMA [media] stk-webcam: don't use stack for DMA [media] flexcop-usb: don't use stack for DMA [media] radio-bcm2048: don't ignore errors kbuild test robot (1): [media] pctv452e: fix semicolon.cocci warnings drivers/media/usb/b2c2/flexcop-usb.c | 105 ++--- drivers/media/usb/b2c2/flexcop-usb.h | 4 + drivers/media/usb/cpia2/cpia2_usb.c | 34 ++- drivers/media/usb/dvb-usb/af9005.c| 319 +++--- drivers/media/usb/dvb-usb/cinergyT2-core.c| 90 ++-- drivers/media/usb/dvb-usb/cinergyT2-fe.c | 100 +++- drivers/media/usb/dvb-usb/cxusb.c | 62 ++--- drivers/media/usb/dvb-usb/cxusb.h | 6 + drivers/media/usb/dvb-usb/dib0700_core.c | 31 ++- drivers/media/usb/dvb-usb/dib0700_devices.c | 25 +- drivers/media/usb/dvb-usb/dibusb-common.c | 113 ++--- drivers/media/usb/dvb-usb/dibusb.h| 3 + drivers/media/usb/dvb-usb/digitv.c| 26 ++- drivers/media/usb/dvb-usb/digitv.h| 5 +- drivers/media/usb/dvb-usb/dtt200u-fe.c| 128 +++ drivers/media/usb/dvb-usb/dtt200u.c | 120 +++--- drivers/media/usb/dvb-usb/dtv5100.c | 10 +- drivers/media/usb/dvb-usb/dw2102.c| 2 +- drivers/media/usb/dvb-usb/gp8psk.c| 25 +- drivers/media/usb/dvb-usb/nova-t-usb2.c | 25 +- drivers/media/usb/dvb-usb/pctv452e.c | 136 ++- drivers/media/usb/dvb-usb/technisat-usb2.c| 16 +- drivers/media/usb/s2255/s2255drv.c| 15 +- drivers/media/usb/stkwebcam/stk-webcam.c | 16 +- drivers/staging/media/bcm2048/radio-bcm2048.c | 2 + 25 files changed, 919 insertions(+), 499 deletions(-)
[BUG 4.4.26] bio->bi_bdev == NULL in raid6 return_io()
return_io() resolves request_queue even if trace point isn't active:
static inline struct request_queue *bdev_get_queue(struct block_device *bdev)
{
return bdev->bd_disk->queue; /* this is never NULL */
}
static void return_io(struct bio_list *return_bi)
{
struct bio *bi;
while ((bi = bio_list_pop(return_bi)) != NULL) {
bi->bi_iter.bi_size = 0;
trace_block_bio_complete(bdev_get_queue(bi->bi_bdev),
bi, 0);
bio_endio(bi);
}
}
kernel build with gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) from ubuntu
precise
<6>[ 1659.710716] md: md2: resync done.
<6>[ 1659.968273] md: resync of RAID array md0
<6>[ 1659.968281] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
<6>[ 1659.968284] md: using maximum available idle IO bandwidth (but not more
than 20 KB/sec) for resync.
<6>[ 1659.968310] md: using 128k window, over a total of 16770816k.
<6>[ 1659.968311] md: resuming resync of md0 from checkpoint.
<7>[ 1659.968674] RAID conf printout:
<7>[ 1659.968678] --- level:6 rd:6 wd:6
<7>[ 1659.968680] disk 0, o:1, dev:sda3
<7>[ 1659.968682] disk 1, o:1, dev:sdc3
<7>[ 1659.968683] disk 2, o:1, dev:sdb3
<7>[ 1659.968684] disk 3, o:1, dev:sdd3
<7>[ 1659.968685] disk 4, o:1, dev:sde3
<7>[ 1659.968686] disk 5, o:1, dev:sdf3
<7>[ 1779.468199] RAID conf printout:
<7>[ 1779.468204] --- level:6 rd:6 wd:6
<7>[ 1779.468206] disk 0, o:1, dev:sda1
<7>[ 1779.468208] disk 1, o:1, dev:sdc1
<7>[ 1779.468209] disk 2, o:1, dev:sdb1
<7>[ 1779.468210] disk 3, o:1, dev:sdd1
<7>[ 1779.468211] disk 4, o:1, dev:sde1
<7>[ 1779.468212] disk 5, o:1, dev:sdf1
<1>[ 4658.730260] IP: return_io (include/linux/blkdev.h:825
drivers/md/raid5.c:231) raid456
<4>[ 4658.737189] PGD 0
<4>[ 4658.739452] Oops: [#1] SMP
<4>[ 4658.743080] Modules linked in: netconsole(E) configfs(E) unix_diag(E) tcp_diag(E) inet_diag(E) ip6t_REJECT(E) nf_reject_ipv6(E)
ip6table_filter(E) ip6table_mangle(E) ip6_tables(E) ipt_R
EJECT(E) nf_reject_ipv4(E) iptable_filter(E) iptable_mangle(E) ip_tables(E) x_tables(E) ipmi_devintf(E) nfsd(E) nfs_acl(E) auth_rpcgss(E)
nfs(E) fscache(E) lockd(E) sunrpc(E) grace(E) cls_u32
(E) sch_prio(E) ipmi_ssif(E) intel_rapl(E) iosf_mbi(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) 8021q(E) coretemp(E) mrp(E) garp(E)
stp(E) kvm_intel(E) llc(E) kvm(E) irqbypass(E) crc32_pcl
mul(E) sb_edac(E) serio_raw(E) joydev(E) input_leds(E) edac_core(E) mei_me(E) mei(E) ioatdma(E) lpc_ich(E) ipmi_si(E) 8250_fintek(E)
ipmi_msghandler(E) shpchp(E) wmi(E) mac_hid(E) ip6_tunnel(
E) tunnel6(E) ipip(E) ip_tunnel(E) tunnel4(E) xfs(E)<4>[ 4658.822823] raid10(E) raid456(E) async_raid6_recov(E) async_memcpy(E) async_pq(E)
async_xor(E) async_tx(E) xor(E) hid_generic(E) usb
hid(E) raid6_pq(E) libcrc32c(E) hid(E) igb(E) i2c_algo_bit(E) raid1(E) isci(E) dca(E) raid0(E) ptp(E) multipath(E) libsas(E) ahci(E)
pps_core(E) scsi_transport_sas(E) psmouse(E) libahci(E) fj
es(E) linear(E)
<4>[ 4658.855131] CPU: 14 PID: 501 Comm: md2_raid6 Tainted: GE
4.4.26-9 #1
<4>[ 4658.863621] Hardware name: Supermicro X9DRW/X9DRW, BIOS 3.00 07/05/2013
<4>[ 4658.871041] task: 882035781a80 ti: 882033c08000 task.ti:
882033c08000
<4>[ 4658.879455] RIP: return_io (include/linux/blkdev.h:825
drivers/md/raid5.c:231) raid456
<4>[ 4658.889155] RSP: 0018:882033c0bb18 EFLAGS: 00010246
<4>[ 4658.895118] RAX: RBX: 881ff22af2c0 RCX:
881ff22af4e0
<4>[ 4658.903122] RDX: RSI: 881ff22af2c0 RDI:
882033c0bc28
<4>[ 4658.911127] RBP: 882033c0bb48 R08: R09:
<4>[ 4658.919130] R10: R11: R12:
88203643db00
<4>[ 4658.927134] R13: 0006 R14: 0004 R15:
882033c0bc28
<4>[ 4658.935139] FS: () GS:88203f38()
knlGS:
<4>[ 4658.944233] CS: 0010 DS: ES: CR0: 80050033
<4>[ 4658.950683] CR2: 0098 CR3: 01e0b000 CR4:
000406e0
<4>[ 4658.958682] Stack:
<4>[ 4658.960952] 882033c0bb78 881ff22af2c0 8820354b0800
0006
<4>[ 4658.969329] 0004 0006 882033c0bc88
a015c0dd
<4>[ 4658.977697] 8820354b0a78
<4>[ 4658.986067] Call Trace:
<4>[ 4658.988827] handle_stripe (drivers/md/raid5.c:4635) raid456
<4>[ 4658.996156] ? default_wake_function (kernel/sched/core.c:3376)
<4>[ 4659.003190] ? autoremove_wake_function (kernel/sched/wait.c:295)
<4>[ 4659.010516] ? __wake_up_common (kernel/sched/wait.c:73)
<4>[ 4659.017065] handle_active_stripes.isra.49 (drivers/md/raid5.c:5776)
raid456
<4>[ 4659.025877] raid5d (drivers/md/raid5.c:5889) raid456
<4>[ 4659.032428] ? _raw_spin_lock_irqsave (./arch/x86/include/asm/paravirt.h:696 ./arch/x86/include/asm/qspinlock.h:28
include/asm-generic/qspinlock.h:102 i
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Fri, 2016-11-04 at 23:16 +0100, Pavel Machek wrote: > Hi! > > > > > I'd prefer mails over bugzilla for now... > > > > 4.9-rc2 has bios_limit: > > > > pavel@duo:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit > > 1833000 > > > > and it has thermal zones: > > > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp 127000 > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_type > > critical > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp 97000 > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_type > > critical > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_temp 92500 > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_type > > passive > > > > ..so it should slow down CPU at 92C. > > > > So lets push the temperature up a bit... > > > > sudo watch cat /proc/acpi/ibm/thermal > > /sys/devices/system/cpu/cpu0/cpufreq/bios_limit > > /sys/devices/virtual/thermal/thermal_zone1/temp /sys/devices/syste > > m/cpu/cpu0/cpufreq/cpuinfo_cur_freq > > > > temperatures: 98 49 -128 85 28 -128 28 -128 49 58 -128 -128 -128 > > -128 -128 -128 > > 1833000 > > 95000 > > 1833000 > > > > Hmm. bios_limit does not seem to change, even when the temperature > > is > > clearly above the trip point. (It is also interestng that acpi/ibm > > reports bigger temperatures than > > /sys/devices/virtual/thermal/thermal_zone1/temp . I have seen 103C > > there.) > Under v4.8-rc, behaviour is different: bios_limit goes to 1GHz there > when temperature is around 84C at the thermal zone. > That keeps > ibm/thermal temperatures under 90C, and no "thermal emergency" > messages in syslog. > > So we seem to have thermal or ACPI regression in v4.9-rc3. > To me, there are two problems, the first one is a 4.9-rc regression that BIOS limit stops working, results in overheating because of high cpu frequency. I agree with Srinivas to check acpi_cpufreq driver code for this one. the second problem is that thermal passive cooling can not prevent the system from overheating, when there is no BIOS limit. To debug this, you can enable thermal dynamic debug by echo 'module thermal_sys +fp' > /sys/kernel/debug/dynamic_debug/control thanks, rui > Best regards, > > > Pavel >
Re: [PATCH] ARM: dts: imx6: Add imx-weim parameters to dtsi's
On Tue, Nov 01, 2016 at 04:51:45PM -0700, Joshua Clayton wrote: > imx-weim should always set address-cells to 2, > and size_cells to 1. > On imx6, fsl,weim-cs-gpr will always be &gpr > > Set these common parameters in the dtsi file, > rather than in a downstream dts. > > Signed-off-by: Joshua Clayton Applied, thanks.
Re: [PATCH 1/2] Input: gpio_keys - Also send release events for ABS codes
On 03/11/2016 17:21, Dmitry Torokhov wrote: On Tue, Nov 01, 2016 at 11:25:03AM +0100, Paul Cercueil wrote: Right now, the gpio-keys driver is mostly used with EV_KEY event types. However, this driver (and its devicetree bindings) support specifying a different input type, like EV_ABS, even though this doesn't work in practice: "key pressed" events are correctly received and treated, but "key released" are silently ignored. With this commit, keys configured as EV_ABS will inject an event with the value 0 when released. No, this will break setups like this: gpio0 - ABS_X - 0 gpio1 - ABS_X - 1 gpio2 - ABS_X - 2 ... gpio7 - ABS_X - 7 - something like a slider built on top of gpios. So what would you suggest for the implementation of a hat / d-pad on top of GPIOs? Thanks, - Paul
Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards
On Friday, 4 November 2016 14:22:17 GMT Hans de Goede wrote:
> Hi,
>
> On 04-11-16 13:30, Paul Burton wrote:
> > Hi Hans,
> >
> > On Friday, 4 November 2016 13:11:34 GMT Hans de Goede wrote:
> >> Hi All,
> >>
> >> While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
> >> I noticed that after u-boot the LCD display stayed black. It turns out
> >> that there was an issue which caused X to never get up, and all kernel
> >> (and other startup) messages prior to that only went to ttyS0 which
> >> consists of 2 tiny testpads on the PCB with this tablet.
> >>
> >> The same issue will also happen on any ARM boards which have a HDMI or
> >> composite video output and which use a stdout-path pointing to their
> >> serial console. I think this will e.g. also impact the Raspberry Pi,
> >> I know for certain that this will impact the 99 different Allwinnner
> >> boards currently supported by mainline u-boot + the mainline kernel.
> >>
> >> This is a behavior changes from previous kernels and I consider this
> >> a regression. Thus I propose to revert the commit in question, for more
> >> info here is a partial copy of the commit message of the proposed revert:
> >>
> >> The reverted commit changes existing behavior on which many ARM boards
> >> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> >> both a video output and a serial console. Depending on whether the user
> >> is using the device as a more regular computer; or as a headless device
> >> we need to have the console on either one or the other.
> >>
> >> Many users rely on the kernel behavior of the console being present on
> >> both outputs, before the reverted commit the console setup with no
> >> console= kernel arguments on an ARM board which sets stdout-path in dt
> >> would look like this:
> >>
> >> [root@localhost ~]# cat /proc/consoles
> >> ttyS0-W- (EC p a)4:64
> >> tty0 -WU (E p )4:1
> >>
> >> Where as after the reverted commit, it looks like this:
> >>
> >> [root@localhost ~]# cat /proc/consoles
> >> ttyS0-W- (EC p a)4:64
> >>
> >> This commit reverts commit 05fd007e4629 ("console: don't prefer first
> >> registered if DT specifies stdout-path") restoring the original behavior.
> >>
> >> Regards,
> >>
> >> Hans
> >
> > Ugh... so the devices you're talking about rely upon set stdout-path in
> > their device tree but effectively rely upon us ignoring it?
>
> No they rely on the kernel using stdout-path as an extra console while
> keeping tty0 as console, not ignoring it. This how stdout-path has always
> worked (at least as long as the Allwinner boards have used it, which has
> been 2 - 3 years now).
>
> If you want only the console specified by stdout-path you can get this by
> specifying it with console=... on the kernel cmdline.
>
> > If that's the case then I guess reverting is probably the best option, but
> > it does restore us to a position where we honor stdout-path for earlycon
> > & then essentially ignore it for the proper kernel console. That seems
> > pretty bust to me...
>
> We do not ignore it, we use both the tty pointed to by stdout-path and tty0.
>
> Regards,
>
> Hans
Hi Hans,
Could you walk me though how you're getting that behaviour from the current
code? I don't see how that would happen besides perhaps if drivers are probed
in a fortunate order. Is that what you're relying upon?
What I see in my systems, and what 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") addressed, is that if there are for
example 2 UARTs uart0 & uart1 that are probed in that order and stdout-path
indicates that we should use uart1 we wind up essentially ignoring it because
the ordering of the relevant calls goes:
- of_console_check() for uart0
- add_preferred_console() for uart0
- register_console() for uart0
- of_console_check() for uart1
- add_preferred_console() for uart1
- register_console() for uart1
Since of_check_console() doesn't get called for uart1 until after uart0 has
been probed, we don't add an entry for it to the console_cmdline array until
after register_console() has already decided to enable uart0 because
preferred_console == -1.
I'm not the only one seeing this oddity either, for example see the discussion
on this patch:
https://patchwork.kernel.org/patch/9263753/
By simply reverting my patch you restore us to a position where so far as I
can see we simply do not honor stdout-path for the real kernel console.
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH v6 0/5] Functional dependencies between devices
On Wed, Nov 02, 2016 at 08:58:38AM +0100, Marek Szyprowski wrote: > Hi Greg, > > > On 2016-10-31 18:47, Greg Kroah-Hartman wrote: > > On Sun, Oct 30, 2016 at 05:22:13PM +0100, Rafael J. Wysocki wrote: > > > Let me quote from the previous intro messages for this series first: > > > > > > > > Time for another update. :-) > > > > > > > > > > Fewer changes this time, mostly to address issues found by Lukas and > > > > > Marek. > > > > > > > > > > The most significant one is to make device_link_add() cope with the > > > > > case > > > > > when > > > > > the consumer device has not been registered yet when it is called. > > > > > The > > > > > supplier device still is required to be registered and the function > > > > > will > > > > > return NULL if that is not the case. > > > > > > > > > > Another significant change is in patch [4/5] that now makes the core > > > > > apply > > > > > pm_runtime_get_sync()/pm_runtime_put() to supplier devices around the > > > > > probing of a consumer one (in analogy with the parent). > > > > One more update after some conversations during LinuxCon Europe. > > > > > > > > The main point was to make it possible for device_link_add() to figure > > > > out > > > > the initial state of the link instead of expecting the caller to > > > > provide it > > > > which might not be reliable enough in general. > > > > > > > > In this version device_link_add() takes three arguments, the supplier > > > > and > > > > consumer pointers and flags and it sets the correct initial state of the > > > > link automatically (unless invoked with the "stateless" flag, of > > > > course). > > > > The cost is one additional field in struct device (I moved all of the > > > > links-related fields in struct device to a separate sub-structure while > > > > at > > > > it) to track the "driver presence status" of the device (to be used by > > > > device_link_add()). > > > > > > > > In addition to that, the links list walks in the core.c and dd.c code > > > > are > > > > under the device links mutex now, so the iternal link spinlock is not > > > > needed > > > > any more and I have renamed symbols to distinguish between flags, link > > > > states and device "driver presence statuses". > > > The most significant change in this revision with respect to the previous > > > one is > > > related to the fact that SRCU is not available on some architectures, so > > > the > > > code falls back to using an RW semaphore for synchronization if SRCU is > > > not > > > there. Fortunately, the code changes needed for that turned out to be > > > quite > > > straightforward and confined to the second patch. > > > > > > Apart from this, the flags are defined using BIT(x) now (instead of open > > > coding > > > the latter in the flag definitions). > > > > > > Updated is mostly patch [2/5]. Patches [1,3,5/5] have not changed > > > (except for > > > trivial rebasing) and patch [4/5] needed to be refreshed on top of the > > > modified > > > [2/5]. > > > > > > FWIW, I've run the series through 0-day which has not reported any > > > problems > > > with it. > > Great, they are now applied to my tree, thanks again for doing this > > work. > > Thanks for merging those patches! Could you provide a stable tag with them, > so I can > ask Joerg to merge my Exynos IOMMU PM patches on top of it via IOMMU tree? My trees do not get rebased so you can pull from it directly right now, or if you really need a signed tag, I can make one up, but it will not be until Monday that I can do that. thanks, greg k-h
Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards
On Friday, 4 November 2016 14:22:17 GMT Hans de Goede wrote:
> Hi,
>
> On 04-11-16 13:30, Paul Burton wrote:
> > Hi Hans,
> >
> > On Friday, 4 November 2016 13:11:34 GMT Hans de Goede wrote:
> >> Hi All,
> >>
> >> While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
> >> I noticed that after u-boot the LCD display stayed black. It turns out
> >> that there was an issue which caused X to never get up, and all kernel
> >> (and other startup) messages prior to that only went to ttyS0 which
> >> consists of 2 tiny testpads on the PCB with this tablet.
> >>
> >> The same issue will also happen on any ARM boards which have a HDMI or
> >> composite video output and which use a stdout-path pointing to their
> >> serial console. I think this will e.g. also impact the Raspberry Pi,
> >> I know for certain that this will impact the 99 different Allwinnner
> >> boards currently supported by mainline u-boot + the mainline kernel.
> >>
> >> This is a behavior changes from previous kernels and I consider this
> >> a regression. Thus I propose to revert the commit in question, for more
> >> info here is a partial copy of the commit message of the proposed revert:
> >>
> >> The reverted commit changes existing behavior on which many ARM boards
> >> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> >> both a video output and a serial console. Depending on whether the user
> >> is using the device as a more regular computer; or as a headless device
> >> we need to have the console on either one or the other.
> >>
> >> Many users rely on the kernel behavior of the console being present on
> >> both outputs, before the reverted commit the console setup with no
> >> console= kernel arguments on an ARM board which sets stdout-path in dt
> >> would look like this:
> >>
> >> [root@localhost ~]# cat /proc/consoles
> >> ttyS0-W- (EC p a)4:64
> >> tty0 -WU (E p )4:1
> >>
> >> Where as after the reverted commit, it looks like this:
> >>
> >> [root@localhost ~]# cat /proc/consoles
> >> ttyS0-W- (EC p a)4:64
> >>
> >> This commit reverts commit 05fd007e4629 ("console: don't prefer first
> >> registered if DT specifies stdout-path") restoring the original behavior.
> >>
> >> Regards,
> >>
> >> Hans
> >
> > Ugh... so the devices you're talking about rely upon set stdout-path in
> > their device tree but effectively rely upon us ignoring it?
>
> No they rely on the kernel using stdout-path as an extra console while
> keeping tty0 as console, not ignoring it. This how stdout-path has always
> worked (at least as long as the Allwinner boards have used it, which has
> been 2 - 3 years now).
>
> If you want only the console specified by stdout-path you can get this by
> specifying it with console=... on the kernel cmdline.
>
> > If that's the case then I guess reverting is probably the best option, but
> > it does restore us to a position where we honor stdout-path for earlycon
> > & then essentially ignore it for the proper kernel console. That seems
> > pretty bust to me...
>
> We do not ignore it, we use both the tty pointed to by stdout-path and tty0.
>
> Regards,
>
> Hans
Hi Hans,
Could you walk me though how you're getting that behaviour from the current
code? I don't see how that would happen besides perhaps if drivers are probed
in a fortunate order. Is that what you're relying upon?
What I see in my systems, and what 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") addressed, is that if there are for
example 2 UARTs uart0 & uart1 that are probed in that order and stdout-path
indicates that we should use uart1 we wind up essentially ignoring it because
the ordering of the relevant calls goes:
- of_console_check() for uart0
- add_preferred_console() for uart0
- register_console() for uart0
- of_console_check() for uart1
- add_preferred_console() for uart1
- register_console() for uart1
Since of_check_console() doesn't get called for uart1 until after uart0 has
been probed, we don't add an entry for it to the console_cmdline array until
after register_console() has already decided to enable uart0 because
preferred_console == -1.
I'm not the only one seeing this oddity either, for example see the discussion
on this patch:
https://patchwork.kernel.org/patch/9263753/
By simply reverting my patch you restore us to a position where so far as I
can see we simply do not honor stdout-path for the real kernel console.
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part.
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > Under v4.8-rc, behaviour is different: bios_limit goes to 1GHz there > when temperature is around 84C at the thermal zone. That keeps > ibm/thermal temperatures under 90C, and no "thermal emergency" > messages in syslog. Argh. So v4.9 thermal management does not work. v4.8 passive thermal management works _too well_, keeping fan at cca 3200 rpm, far below 3700 rpm it can reach. CPU is getting throttled, and fan is not even running at full speed. I can manually control the fan with thinkpad_acpi.fan_control=1... I guess I can write some scripts? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [RFC][PATCH] mm: merge as soon as possible when pcp alloc/free
On 11/05/2016 01:27 PM, Xishi Qiu wrote: > Usually the memory of android phones is very small, so after a long > running, the fragment is very large. Kernel stack which called by > alloc_thread_stack_node() usually alloc 16K memory, and it failed > frequently. > > However we have CONFIG_VMAP_STACK now, but it do not support arm64, > and maybe it has some regression because of vmalloc, it need to > find an area and create page table dynamically, this will take a short > time. > > I think we can merge as soon as possible when pcp alloc/free to reduce > fragment. The pcp page is hot page, so free it will cause cache miss, > I use perf to test it, but it seems the regression is not so much, maybe > it need to test more. Any reply is welcome. The idea of PCP is to have a fast allocation mechanism which does not depend on an interrupt safe spin lock for every allocation. I am not very familiar with this part of code but the following documentation from Mel Gorman kind of explains that the this type of fragmentation problem which you might be observing as one of the limitations of PCP mechanism. https://www.kernel.org/doc/gorman/html/understand/understand009.html "Per CPU page list" sub header.
[PATCH] befs: add NFS export support
Implement mandatory export_operations, so it is possible to export befs via
nfs.
Signed-off-by: Luis de Bethencourt
---
Hi,
NFS exporting is a very useful feature. I implement here fh_to_dentry because
it is the mandatory member of struct export_operations, and fh_to_parent since
it is easy once you have the previous one and recommended [0].
I can't trigger a call for get_parent, so not adding that one yet.
With this befs via NFS becomes available.
Thanks,
Luis
[0] Documentation/filesystems/nfs/Exporting
fs/befs/linuxvfs.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c
index 8e4e18e..6ff7d01 100644
--- a/fs/befs/linuxvfs.c
+++ b/fs/befs/linuxvfs.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "befs.h"
#include "btree.h"
@@ -52,6 +53,10 @@ static void befs_put_super(struct super_block *);
static int befs_remount(struct super_block *, int *, char *);
static int befs_statfs(struct dentry *, struct kstatfs *);
static int parse_options(char *, struct befs_mount_options *);
+static struct dentry *befs_fh_to_dentry(struct super_block *sb,
+ struct fid *fid, int fh_len, int fh_type);
+static struct dentry *befs_fh_to_parent(struct super_block *sb,
+ struct fid *fid, int fh_len, int fh_type);
static const struct super_operations befs_sops = {
.alloc_inode= befs_alloc_inode, /* allocate a new inode */
@@ -84,6 +89,11 @@ static const struct address_space_operations
befs_symlink_aops = {
.readpage = befs_symlink_readpage,
};
+static const struct export_operations befs_export_operations = {
+ .fh_to_dentry = befs_fh_to_dentry,
+ .fh_to_parent = befs_fh_to_parent,
+};
+
/*
* Called by generic_file_read() to read a page of data
*
@@ -629,6 +639,33 @@ befs_nls2utf(struct super_block *sb, const char *in,
return -EILSEQ;
}
+static struct inode *befs_nfs_get_inode(struct super_block *sb, uint64_t ino,
+uint32_t generation)
+{
+ /* No need to handle i_generation */
+ return befs_iget(sb, ino);
+}
+
+/*
+ * Map a NFS file handle to a corresponding dentry
+ */
+static struct dentry *befs_fh_to_dentry(struct super_block *sb,
+ struct fid *fid, int fh_len, int fh_type)
+{
+ return generic_fh_to_dentry(sb, fid, fh_len, fh_type,
+ befs_nfs_get_inode);
+}
+
+/*
+ * Find the parent for a file specified by NFS handle
+ */
+static struct dentry *befs_fh_to_parent(struct super_block *sb,
+ struct fid *fid, int fh_len, int fh_type)
+{
+ return generic_fh_to_parent(sb, fid, fh_len, fh_type,
+ befs_nfs_get_inode);
+}
+
enum {
Opt_uid, Opt_gid, Opt_charset, Opt_debug, Opt_err,
};
@@ -829,6 +866,7 @@ befs_fill_super(struct super_block *sb, void *data, int
silent)
/* Set real blocksize of fs */
sb_set_blocksize(sb, (ulong) befs_sb->block_size);
sb->s_op = &befs_sops;
+ sb->s_export_op = &befs_export_operations;
root = befs_iget(sb, iaddr2blockno(sb, &(befs_sb->root_dir)));
if (IS_ERR(root)) {
ret = PTR_ERR(root);
--
2.10.2
Re: [PATCH] befs: add NFS export support
On 05/11/16 12:42, Luis de Bethencourt wrote: > Implement mandatory export_operations, so it is possible to export befs via > nfs. > > Signed-off-by: Luis de Bethencourt > --- Forgot to add Richard. Sorry Richard, Luis
Re: [PATCH 1/6] staging: iio: set proper supply name to devm_regulator_get()
On 01/11/16 19:58, Lars-Peter Clausen wrote: > On 11/01/2016 05:03 AM, Matt Ranostay wrote: >> On Mon, Oct 31, 2016 at 10:04 AM, Eva Rachel Retuya >> wrote: >>> The name passed to devm_regulator_get() should match the name of the >>> supply as specified in the device datasheet. This makes it clear what >>> power supply is being referred to in case of presence of other >>> regulators. >>> >>> Currently, the supply name specified on the affected devices is 'vcc'. >>> Use lowercase version of the datasheet name to specify the supply >>> voltage. >>> >> >> Aren't we possibly breaking current device tree definitions that >> people may have? We should still check the old name after the new >> datasheet name in my opinion. > > None of those drivers have DT bindings, so I think we are OK. And they are > in staging anyway. > I agree on this. These are technically in kernel interfaces so we are fine to change them. Would have been more interesting if there were DT bindings however and we would have had to support the old and new naming for a while at least (i.e. probably forever as we'd never get around to cleaning it up!) Jonathan
Re: [PATCH v3 2/2] net: ethernet: nb8800: handle all RGMII definitions
Sebastian Frias writes:
> Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition")
> and commit 7d400a4c5897 ("phylib: add PHY interface modes for internal
> delay for tx and rx only") added several RGMII definitions:
> PHY_INTERFACE_MODE_RGMII_ID, PHY_INTERFACE_MODE_RGMII_RXID and
> PHY_INTERFACE_MODE_RGMII_TXID to deal with internal delays.
>
> Those are all RGMII modes (1Gbit) and must be considered that way when
> setting the MAC mode or the pad mode for the HW to work properly.
>
> Signed-off-by: Sebastian Frias
> ---
> drivers/net/ethernet/aurora/nb8800.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/aurora/nb8800.c
> b/drivers/net/ethernet/aurora/nb8800.c
> index d2855c9..fba2699 100644
> --- a/drivers/net/ethernet/aurora/nb8800.c
> +++ b/drivers/net/ethernet/aurora/nb8800.c
> @@ -598,6 +598,7 @@ static irqreturn_t nb8800_irq(int irq, void *dev_id)
> static void nb8800_mac_config(struct net_device *dev)
> {
> struct nb8800_priv *priv = netdev_priv(dev);
> + struct phy_device *phydev = dev->phydev;
> bool gigabit = priv->speed == SPEED_1000;
> u32 mac_mode_mask = RGMII_MODE | HALF_DUPLEX | GMAC_MODE;
> u32 mac_mode = 0;
> @@ -609,7 +610,7 @@ static void nb8800_mac_config(struct net_device *dev)
> mac_mode |= HALF_DUPLEX;
>
> if (gigabit) {
> - if (priv->phy_mode == PHY_INTERFACE_MODE_RGMII)
> + if (phy_interface_is_rgmii(phydev))
> mac_mode |= RGMII_MODE;
>
> mac_mode |= GMAC_MODE;
As I said before, this part can/should be applied separately, although
personally I probably wouldn't have bothered adding a single-use variable.
> @@ -1278,9 +1279,8 @@ static int nb8800_tangox_init(struct net_device *dev)
> break;
>
> case PHY_INTERFACE_MODE_RGMII:
> - pad_mode = PAD_MODE_RGMII;
> - break;
> -
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> pad_mode = PAD_MODE_RGMII;
> break;
> --
> 1.7.11.2
>
--
Måns Rullgård
[PATCH] net: adaptec: starfire: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/adaptec/starfire.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/adaptec/starfire.c
b/drivers/net/ethernet/adaptec/starfire.c
index 4a9a16e..3aaad33 100644
--- a/drivers/net/ethernet/adaptec/starfire.c
+++ b/drivers/net/ethernet/adaptec/starfire.c
@@ -1816,21 +1816,23 @@ static void get_drvinfo(struct net_device *dev, struct
ethtool_drvinfo *info)
strlcpy(info->bus_info, pci_name(np->pci_dev), sizeof(info->bus_info));
}
-static int get_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+static int get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
{
struct netdev_private *np = netdev_priv(dev);
spin_lock_irq(&np->lock);
- mii_ethtool_gset(&np->mii_if, ecmd);
+ mii_ethtool_get_link_ksettings(&np->mii_if, cmd);
spin_unlock_irq(&np->lock);
return 0;
}
-static int set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+static int set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
{
struct netdev_private *np = netdev_priv(dev);
int res;
spin_lock_irq(&np->lock);
- res = mii_ethtool_sset(&np->mii_if, ecmd);
+ res = mii_ethtool_set_link_ksettings(&np->mii_if, cmd);
spin_unlock_irq(&np->lock);
check_duplex(dev);
return res;
@@ -1861,12 +1863,12 @@ static void set_msglevel(struct net_device *dev, u32
val)
static const struct ethtool_ops ethtool_ops = {
.begin = check_if_running,
.get_drvinfo = get_drvinfo,
- .get_settings = get_settings,
- .set_settings = set_settings,
.nway_reset = nway_reset,
.get_link = get_link,
.get_msglevel = get_msglevel,
.set_msglevel = set_msglevel,
+ .get_link_ksettings = get_link_ksettings,
+ .set_link_ksettings = set_link_ksettings,
};
static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
--
1.7.4.4
Re: [PATCH] iio: light and pressure: change data fields for ambient light and pressure sensor
On 03/11/16 13:35, Srinivas Pandruvada wrote:
> On Thu, 2016-11-03 at 18:43 +0800, Ooi, Joyce wrote:
>> Sensitivity Percent Relative is added for ambient light sensor as it
>> is
>> used based on HID Sensor Usages specifications.
> The same patch is submitted by Song Hongyan
> . We may need new IIO ABI to specify relative percent hyst.
It is a particularly 'hideous' way of reporting something - particularly
as we head towards very low values. Ah well. Yes, would need
some additional ABI. We do already have ratio attributes so
maybe -
hysteresis_ratio or something like that. Ugly though. Ah well.
Jonathan
>
> Thanks,
> Srinivas
>
>>
>> Other changes include adding HID_USAGE_SENSOR_LIGHT_ILLUM and
>> HID_USAGE_SENSOR_ATMOSPHERIC_PRESSURE for ambient light and pressure
>> sensor respectively to be in sync with HID Sensor Usages
>> specifications.
>>
>> Signed-off-by: Ooi, Joyce
>> ---
>> drivers/iio/light/hid-sensor-als.c | 10 ++
>> drivers/iio/pressure/hid-sensor-press.c | 10 ++
>> include/linux/hid-sensor-ids.h | 1 +
>> 3 files changed, 21 insertions(+)
>>
>> diff --git a/drivers/iio/light/hid-sensor-als.c
>> b/drivers/iio/light/hid-sensor-als.c
>> index 8bb1f90..6f3ca18 100644
>> --- a/drivers/iio/light/hid-sensor-als.c
>> +++ b/drivers/iio/light/hid-sensor-als.c
>> @@ -252,6 +252,16 @@ static int als_parse_report(struct
>> platform_device *pdev,
>> st->common_attributes.sensitivity.index,
>> st-
>>> common_attributes.sensitivity.report_id);
>> }
>> +if (st->common_attributes.sensitivity.index < 0) {
>> +sensor_hub_input_get_attribute_info(hsdev,
>> +HID_FEATURE_REPORT, usage_id,
>> +HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY
>> _REL_PCT |
>> +HID_USAGE_SENSOR_LIGHT_ILLUM,
>> +&st->common_attributes.sensitivity);
>> +dev_dbg(&pdev->dev, "Sensitivity index:report
>> %d:%d\n",
>> +st->common_attributes.sensitivity.index,
>> +st-
>>> common_attributes.sensitivity.report_id);
>> +}
>> return ret;
>> }
>>
>> diff --git a/drivers/iio/pressure/hid-sensor-press.c
>> b/drivers/iio/pressure/hid-sensor-press.c
>> index 6848d8c..4cbbf88 100644
>> --- a/drivers/iio/pressure/hid-sensor-press.c
>> +++ b/drivers/iio/pressure/hid-sensor-press.c
>> @@ -249,6 +249,16 @@ static int press_parse_report(struct
>> platform_device *pdev,
>> st->common_attributes.sensitivity.index,
>> st-
>>> common_attributes.sensitivity.report_id);
>> }
>> +if (st->common_attributes.sensitivity.index < 0) {
>> +sensor_hub_input_get_attribute_info(hsdev,
>> +HID_FEATURE_REPORT, usage_id,
>> +HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY
>> _ABS |
>> +HID_USAGE_SENSOR_ATMOSPHERIC_PRESSURE,
>> +&st->common_attributes.sensitivity);
>> +dev_dbg(&pdev->dev, "Sensitivity index:report
>> %d:%d\n",
>> +st->common_attributes.sensitivity.index,
>> +st-
>>> common_attributes.sensitivity.report_id);
>> +}
>> return ret;
>> }
>>
>> diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-
>> sensor-ids.h
>> index f2ee90a..755f5e2 100644
>> --- a/include/linux/hid-sensor-ids.h
>> +++ b/include/linux/hid-sensor-ids.h
>> @@ -141,6 +141,7 @@
>> /* Per data field properties */
>> #define HID_USAGE_SENSOR_DATA_MOD_NONE
>> 0x00
>> #define HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS
>> 0x1000
>> +#define HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_REL_PCT
>> 0xE000
>>
>> /* Power state enumerations */
>> #define HID_USAGE_SENSOR_PROP_POWER_STATE_UNDEFINED_ENUM0x20
>> 0850
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > To me, there are two problems, > the first one is a 4.9-rc regression that BIOS limit stops working, > results in overheating because of high cpu frequency. I agree with > Srinivas to check acpi_cpufreq driver code for this one. Ok. > the second problem is that thermal passive cooling can not prevent the > system from overheating, when there is no BIOS limit. To debug this, > you can enable thermal dynamic debug by > echo 'module thermal_sys +fp' > /sys/kernel/debug/dynamic_debug/control How is thermal passive cooling different from BIOS limit? Is this related? pavel@duo:/sys/class/thermal/cooling_device1$ grep -r . . ./cur_state:0 ./power/runtime_active_kids:0 ./power/runtime_suspended_time:0 grep: ./power/autosuspend_delay_ms: Input/output error ./power/runtime_enabled:disabled ./power/runtime_active_time:0 ./power/control:auto ./power/async:disabled ./power/runtime_usage:0 ./power/runtime_status:unsupported ./type:Processor ./max_state:10 Hmm. I seem to get _some_ throttling, even when bios_limit is still 1.8GHz, but I don't understand where it comes from. And yes, 'thermal_sys +fp' seems to produce some output. [I did not get absolute records in >100C range this time, but still there are "THERMAL EMERGENCY:" messages from thinkpad_acpi already...] [14049.733423] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is extremely hot! [14049.735412] thinkpad_acpi: temperatures (Celsius): 92 50 N/A 80 32 N/A 32 N/A 50 59 N/A N/A N/A N/A N/A N/A [14049.736557] update_temperature: thermal thermal_zone1: last_temperature=92000, current_temperature=93000 [14049.736570] thermal_zone_trip_update: thermal thermal_zone1: Trip1[type=1,temp=92500]:trend=1,throttle=1 [14049.736577] get_target_state: thermal cooling_device2: cur_state=0 [14049.736580] thermal_zone_trip_update: thermal cooling_device2: old_target=0, target=1 [14049.736586] get_target_state: thermal cooling_device1: cur_state=0 [14049.736589] thermal_zone_trip_update: thermal cooling_device1: old_target=0, target=1 [14049.736593] thermal_cdev_update: thermal cooling_device2: zone1->target=1 [14049.736643] thermal_cdev_update: thermal cooling_device2: set to state 1 [14049.736647] thermal_cdev_update: thermal cooling_device1: zone1->target=1 [14049.73] thermal_cdev_update: thermal cooling_device1: set to state 1 [14049.808333] update_temperature: thermal thermal_zone1: last_temperature=93000, current_temperature=91000 [14049.808352] thermal_zone_trip_update: thermal thermal_zone1: Trip1[type=1,temp=92500]:trend=2,throttle=0 [14049.808360] get_target_state: thermal cooling_device2: cur_state=1 [14049.808364] thermal_zone_trip_update: thermal cooling_device2: old_target=1, target=0 [14049.808371] get_target_state: thermal cooling_device1: cur_state=1 [14049.808375] thermal_zone_trip_update: thermal cooling_device1: old_target=1, target=0 [14049.808381] thermal_cdev_update: thermal cooling_device2: zone1->target=0 [14049.808409] thermal_cdev_update: thermal cooling_device2: set to state 0 [14049.808414] thermal_cdev_update: thermal cooling_device1: zone1->target=0 [14049.808432] thermal_cdev_update: thermal cooling_device1: set to state 0 [14049.888385] update_temperature: thermal thermal_zone1: last_temperature=91000, current_temperature=92000 [14049.888401] thermal_zone_trip_update: thermal thermal_zone1: Trip1[type=1,temp=92500]:trend=1,throttle=0 [14049.888408] get_target_state: thermal cooling_device2: cur_state=0 [14049.888411] thermal_zone_trip_update: thermal cooling_device2: old_target=0, target=0 [14049.888416] get_target_state: thermal cooling_device1: cur_state=0 [14049.888419] thermal_zone_trip_update: thermal cooling_device1: old_target=0, target=0 [14051.312646] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is extremely hot! [14051.314442] thinkpad_acpi: temperatures (Celsius): 93 50 N/A 80 32 N/A 32 N/A 50 59 N/A N/A N/A N/A N/A N/A [14051.315544] update_temperature: thermal thermal_zone1: last_temperature=92000, current_temperature=94000 [14051.315557] thermal_zone_trip_update: thermal thermal_zone1: Trip1[type=1,temp=92500]:trend=1,throttle=1 [14051.315564] get_target_state: thermal cooling_device2: cur_state=0 [14051.315567] thermal_zone_trip_update: thermal cooling_device2: old_target=0, target=1 [14051.315572] get_target_state: thermal cooling_device1: cur_state=0 [14051.315575] thermal_zone_trip_update: thermal cooling_device1: old_target=0, target=1 [14051.315579] thermal_cdev_update: thermal cooling_device2: zone1->target=1 [14051.315629] thermal_cdev_update: thermal cooling_device2: set to state 1 [14051.315633] thermal_cdev_update: thermal cooling_device1: zone1->target=1 [14051.315652] thermal_cdev_update: thermal cooling_device1: set to state 1 [14051.334873] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is extremely hot! [14051.337322] thinkpad_acpi: temperatures (Celsius): 93 50 N/A 8
[PATCH] x86/MCE: Remove MCP_TIMESTAMP
Whoops,
one more:
---
From: Borislav Petkov
Date: Sat, 5 Nov 2016 12:47:03 +0100
Subject: [PATCH] x86/MCE: Remove MCP_TIMESTAMP
MCP_TIMESTAMP controls whether current TSC value should be added to
the MCE record. Most of machine_check_poll() callers supply it, except
__mcheck_cpu_init_generic() but this is wrong because we could be
logging an MCE right at the same time and thus log one without the TSC
value.
What is more, machine_check_poll() did unconditionally clear mce.tsc
which is another bug.
So, get rid of all that and simply log an MCE with a TSC value always.
Simplifies the code a bit too.
Signed-off-by: Borislav Petkov
Cc: Tony Luck
---
arch/x86/include/asm/mce.h | 5 ++---
arch/x86/kernel/cpu/mcheck/mce.c | 6 +-
arch/x86/kernel/cpu/mcheck/mce_intel.c | 6 +++---
3 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 748b8da8e627..3b53c260e0be 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -265,9 +265,8 @@ typedef DECLARE_BITMAP(mce_banks_t, MAX_NR_BANKS);
DECLARE_PER_CPU(mce_banks_t, mce_poll_banks);
enum mcp_flags {
- MCP_TIMESTAMP = BIT(0), /* log time stamp */
- MCP_UC = BIT(1), /* log uncorrected errors */
- MCP_DONTLOG = BIT(2), /* only clear, don't log */
+ MCP_UC = BIT(0), /* log uncorrected errors */
+ MCP_DONTLOG = BIT(1), /* only clear, don't log */
};
bool machine_check_poll(enum mcp_flags flags, mce_banks_t *b);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 4ca00474804b..82564156d6ab 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -713,7 +713,6 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
m.misc = 0;
m.addr = 0;
m.bank = i;
- m.tsc = 0;
barrier();
m.status = mce_rdmsrl(msr_ops.status(i));
@@ -735,9 +734,6 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
mce_read_aux(&m, i);
- if (!(flags & MCP_TIMESTAMP))
- m.tsc = 0;
-
severity = mce_severity(&m, mca_cfg.tolerant, NULL, false);
if (severity == MCE_DEFERRED_SEVERITY && memory_error(&m))
@@ -1394,7 +1390,7 @@ static void mce_timer_fn(unsigned long data)
iv = __this_cpu_read(mce_next_interval);
if (mce_available(this_cpu_ptr(&cpu_info))) {
- machine_check_poll(MCP_TIMESTAMP,
this_cpu_ptr(&mce_poll_banks));
+ machine_check_poll(0, this_cpu_ptr(&mce_poll_banks));
if (mce_intel_cmci_poll()) {
iv = mce_adjust_timer(iv);
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index 1defb8ea882c..3262f0d726bb 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -130,7 +130,7 @@ bool mce_intel_cmci_poll(void)
* Reset the counter if we've logged an error in the last poll
* during the storm.
*/
- if (machine_check_poll(MCP_TIMESTAMP, this_cpu_ptr(&mce_banks_owned)))
+ if (machine_check_poll(0, this_cpu_ptr(&mce_banks_owned)))
this_cpu_write(cmci_backoff_cnt, INITIAL_CHECK_INTERVAL);
else
this_cpu_dec(cmci_backoff_cnt);
@@ -250,7 +250,7 @@ static void intel_threshold_interrupt(void)
if (cmci_storm_detect())
return;
- machine_check_poll(MCP_TIMESTAMP, this_cpu_ptr(&mce_banks_owned));
+ machine_check_poll(0, this_cpu_ptr(&mce_banks_owned));
}
/*
@@ -342,7 +342,7 @@ void cmci_recheck(void)
return;
local_irq_save(flags);
- machine_check_poll(MCP_TIMESTAMP, this_cpu_ptr(&mce_banks_owned));
+ machine_check_poll(0, this_cpu_ptr(&mce_banks_owned));
local_irq_restore(flags);
}
--
2.10.0
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Fri 2016-11-04 23:20:53, Pandruvada, Srinivas wrote: > On Fri, 2016-11-04 at 23:16 +0100, Pavel Machek wrote: > > Hi! > > > > [...] > > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > It is possible. Can you add either add printk > in acpi_processor_ppc_has_changed() or use ftrace and see do you get to > these functions > > acpi_processor_ppc_init() > acpi_processor_ppc_has_changed() > acpi_processor_ppc_notifier() > > ? Ok, can do, let me recompile and reboot. > When temperature limit is reached acpi_processor_ppc_notifier() should > be called. No, that's not correct for ACPI passive trip points, is it? If I recall correctly, those should be monitored even when temperature is below them so that it does not reach them...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[GIT PULL] SCSI fixes for 4.9-rc3
Two more important data integrity fixes related to RAID device drivers
which wrongly throw away the SYNCHRONIZE CACHE command in the non-RAID
path and a memory leak fix in the scsi_debug driver.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Ching Huang (1):
scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware
Ewan D. Milne (1):
scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded
Kashyap Desai (1):
scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices
And the diffstat:
drivers/scsi/arcmsr/arcmsr_hba.c | 9 -
drivers/scsi/megaraid/megaraid_sas_base.c | 13 +
drivers/scsi/scsi_debug.c | 1 +
3 files changed, 6 insertions(+), 17 deletions(-)
With full diff below.
James
---
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index 3d53d63..f0cfb04 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -2636,18 +2636,9 @@ static int arcmsr_queue_command_lck(struct scsi_cmnd
*cmd,
struct AdapterControlBlock *acb = (struct AdapterControlBlock *)
host->hostdata;
struct CommandControlBlock *ccb;
int target = cmd->device->id;
- int lun = cmd->device->lun;
- uint8_t scsicmd = cmd->cmnd[0];
cmd->scsi_done = done;
cmd->host_scribble = NULL;
cmd->result = 0;
- if ((scsicmd == SYNCHRONIZE_CACHE) ||(scsicmd == SEND_DIAGNOSTIC)){
- if(acb->devstate[target][lun] == ARECA_RAID_GONE) {
- cmd->result = (DID_NO_CONNECT << 16);
- }
- cmd->scsi_done(cmd);
- return 0;
- }
if (target == 16) {
/* virtual device for iop message transfer */
arcmsr_handle_virtual_command(acb, cmd);
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 9ff57de..d8b1fbd 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1700,16 +1700,13 @@ megasas_queue_command(struct Scsi_Host *shost, struct
scsi_cmnd *scmd)
goto out_done;
}
- switch (scmd->cmnd[0]) {
- case SYNCHRONIZE_CACHE:
- /*
-* FW takes care of flush cache on its own
-* No need to send it down
-*/
+ /*
+* FW takes care of flush cache on its own for Virtual Disk.
+* No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to
FW.
+*/
+ if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
scmd->result = DID_OK << 16;
goto out_done;
- default:
- break;
}
return instance->instancet->build_and_issue_cmd(instance, scmd);
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index c905709..cf04a36 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -5134,6 +5134,7 @@ static void __exit scsi_debug_exit(void)
bus_unregister(&pseudo_lld_bus);
root_device_unregister(pseudo_primary);
+ vfree(map_storep);
vfree(dif_storep);
vfree(fake_storep);
kfree(sdebug_q_arr);
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat, 2016-11-05 at 14:20 +0100, Pavel Machek wrote: > On Fri 2016-11-04 23:20:53, Pandruvada, Srinivas wrote: > > > > On Fri, 2016-11-04 at 23:16 +0100, Pavel Machek wrote: > > > > > > Hi! > > > > > > > [...] > > > > > > > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > > > It is possible. Can you add either add printk > > in acpi_processor_ppc_has_changed() or use ftrace and see do you > > get to > > these functions > > > > acpi_processor_ppc_init() > > acpi_processor_ppc_has_changed() > > acpi_processor_ppc_notifier() > > > > ? > > Ok, can do, let me recompile and reboot. > > > > > When temperature limit is reached acpi_processor_ppc_notifier() > > should > > be called. > > No, that's not correct for ACPI passive trip points, is it? If I > recall correctly, those should be monitored even when temperature is > below them so that it does not reach them...? No if BIOS is sending PPC, it will be called. You can try first in 4.8. Also try Don't run workload, just on an idle system. # echo 1 > /sys/class/thermal/cooling_device2/cur_state monitor the scaling_max_freq, it should reduce # echo 2 > /sys/class/thermal/cooling_device2/cur_state monitor the scaling_max_freq, it should reduce Thanks, Srinivas
Re: crash by cdc_acm driver in kernels 4.8-rc1/5
On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote: > On Mon, 2016-10-17 at 17:20 +0200, Wim Osterholt wrote: > > On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote: > > > Hi, > > > > > > I got one of those devices. However, I don't get a crash. > > > Could you please give me instructions on how you trigger it? > > > > That's not too hard, just plug it in. :-) > It definitely does not crash and is probed and your .config is not > extremely unusual. Hmmm. > ... Something odd is going on. You didn't try it on many machines, did you? The latest install on a 'new' laptop (Dell latitude D610) did also crash. For if it matters, they all have Intel chipset here. Crashes now on five machines. An worn-out Dell laptop (Inspiron 510m) suddenly got stuck in a reboot loop for 4.7.10 and 4.9-rc3, but a 4.8-rc4 kept running. Even more miraculously, it didn't crash on inserting the modem. I could even compile a 4.9-rc3 that didn't crash on that machine. The effect was even portable! I now have a crashing and a non-crashing 4.9-rc3 kernel. You can find the configs here: http://webserver.djo.tudelft.nl/.config-4.9-rc3.notOK http://webserver.djo.tudelft.nl/.config-4.9-rc3.OK They are very different, so it will take a lot of time to eliminate the options one by one. So if you have an idea of which options, or combination of options are evil, I'd like to hear. Regards, Wim.
[PATCH 1/4] phy: Add reset callback for not generic phy
From: Randy Li
Add a dummy function for phy_reset in case the CONFIG_GENERIC_PHY
is disabled.
Signed-off-by: Randy Li
Signed-off-by: Kishon Vijay Abraham I
---
include/linux/phy/phy.h |7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index ee1bed7..78bb0d7 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -253,6 +253,13 @@ static inline int phy_set_mode(struct phy *phy, enum
phy_mode mode)
return -ENOSYS;
}
+static inline int phy_reset(struct phy *phy)
+{
+ if (!phy)
+ return 0;
+ return -ENOSYS;
+}
+
static inline int phy_get_bus_width(struct phy *phy)
{
return -ENOSYS;
--
1.7.9.5
[GIT PULL] phy: for 4.9 -rc
Hi Greg, Please find the pull request for the phy fixes below. It includes a fix in phy core to add a static inline function when CONFIG_GENERIC_PHY is not selected and 3 fixes in different phy drivers. The phy device name in the phy lookup table used for non-dt boot is fixed for da8xx-usb phy, NULL pointer dereferencing error is fixed for sun4i phy and an incorrect programming sequence w.r.t deassert of phy_rst in phy-rockchip-pcie is also fixed. Consider merging it in this -rc cyle and let me know if you want me to change something. Cheers Kishon The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git tags/phy-for-4.9-rc for you to fetch changes up to 4320f9d4c1831fd4d244a9de8f81bc27ea67699c: phy: sun4i: check PMU presence when poking unknown bit of pmu (2016-11-05 13:45:02 +0530) phy: for 4.9 -rc phy fixes: *) Add a empty function for phy_reset when CONFIG_GENERIC_PHY is not set *) change the phy lookup table for da8xx-usb to match it with the name present in the board configuraion file (used for non-dt boot) *) Fix incorrect programming sequence in w.r.t deassert of phy_rst in phy-rockchip-pcie *) Fix to avoid NULL pointer dereferencing error in sun4i phy Signed-off-by: Kishon Vijay Abraham I Axel Haslam (1): phy: da8xx-usb: rename the ohci device to ohci-da8xx Icenowy Zheng (1): phy: sun4i: check PMU presence when poking unknown bit of pmu Randy Li (1): phy: Add reset callback for not generic phy Shawn Lin (1): phy-rockchip-pcie: remove deassert of phy_rst from exit callback drivers/phy/phy-da8xx-usb.c |5 +++-- drivers/phy/phy-rockchip-pcie.c | 13 + drivers/phy/phy-sun4i-usb.c |2 +- include/linux/phy/phy.h |7 +++ 4 files changed, 12 insertions(+), 15 deletions(-) -- 1.7.9.5
[PATCH 2/4] phy: da8xx-usb: rename the ohci device to ohci-da8xx
From: Axel Haslam
The ohci device name has changed in the board configuraion files,
hence, change the phy lookup table to match the new name.
Signed-off-by: Axel Haslam
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/phy-da8xx-usb.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
index 32ae78c..c85fb0b 100644
--- a/drivers/phy/phy-da8xx-usb.c
+++ b/drivers/phy/phy-da8xx-usb.c
@@ -198,7 +198,8 @@ static int da8xx_usb_phy_probe(struct platform_device *pdev)
} else {
int ret;
- ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
+ ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy",
+ "ohci-da8xx");
if (ret)
dev_warn(dev, "Failed to create usb11 phy lookup\n");
ret = phy_create_lookup(d_phy->usb20_phy, "usb-phy",
@@ -216,7 +217,7 @@ static int da8xx_usb_phy_remove(struct platform_device
*pdev)
if (!pdev->dev.of_node) {
phy_remove_lookup(d_phy->usb20_phy, "usb-phy", "musb-da8xx");
- phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
+ phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci-da8xx");
}
return 0;
--
1.7.9.5
[PATCH 3/4] phy-rockchip-pcie: remove deassert of phy_rst from exit callback
From: Shawn Lin
The deassert of phy_rst from exit callback is incorrect as when
doing phy_exit, we expect the phy_rst is on asserted state which was
done by power_off callback, but not deasserted state. Meanwhile when
disabling clk_pciephy_ref, the assert/deassert signal can't actually
take effect on the phy. So let's fix it anyway.
Signed-off-by: Shawn Lin
Reviewed-by: Heiko Stuebner
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/phy-rockchip-pcie.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/phy/phy-rockchip-pcie.c b/drivers/phy/phy-rockchip-pcie.c
index a2b4c6b..6904633 100644
--- a/drivers/phy/phy-rockchip-pcie.c
+++ b/drivers/phy/phy-rockchip-pcie.c
@@ -249,21 +249,10 @@ static int rockchip_pcie_phy_init(struct phy *phy)
static int rockchip_pcie_phy_exit(struct phy *phy)
{
struct rockchip_pcie_phy *rk_phy = phy_get_drvdata(phy);
- int err = 0;
clk_disable_unprepare(rk_phy->clk_pciephy_ref);
- err = reset_control_deassert(rk_phy->phy_rst);
- if (err) {
- dev_err(&phy->dev, "deassert phy_rst err %d\n", err);
- goto err_reset;
- }
-
- return err;
-
-err_reset:
- clk_prepare_enable(rk_phy->clk_pciephy_ref);
- return err;
+ return 0;
}
static const struct phy_ops ops = {
--
1.7.9.5
[PATCH 4/4] phy: sun4i: check PMU presence when poking unknown bit of pmu
From: Icenowy Zheng
Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
The code that poke some unknown bit of PMU for H3/A64 didn't check
the PHY, and will cause kernel oops when PHY 0 is used.
This patch will check whether the pmu is not NULL before poking.
Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
Signed-off-by: Icenowy Zheng
Acked-by: Maxime Ripard
Reviewed-by: Hans de Goede
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/phy-sun4i-usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index b9342a2..fec34f5 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -264,7 +264,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
return ret;
}
- if (data->cfg->enable_pmu_unk1) {
+ if (phy->pmu && data->cfg->enable_pmu_unk1) {
val = readl(phy->pmu + REG_PMU_UNK1);
writel(val & ~2, phy->pmu + REG_PMU_UNK1);
}
--
1.7.9.5
Re: [PATCH] drm: move allocation out of drm_get_format_name()
Am 05.11.2016 um 02:33 schrieb Eric Engestrom: +typedef char drm_format_name_buf[32]; Please don't use a typedef for this, just define the maximum size of characters the function might write somewhere. See the kernel coding style as well: In general, a pointer, or a struct that has elements that can reasonably be directly accessed should **never** be a typedef. Regards, Christian.
[PATCH/RFC] z3fold: use per-page read/write lock
Most of z3fold operations are in-page, such as modifying z3fold
page header or moving z3fold objects within a page. Taking
per-pool spinlock to protect per-page objects is therefore
suboptimal, and the idea of having a per-page spinlock (or rwlock)
has been around for some time. However, adding one directly to the
z3fold header makes the latter quite big on some systems so that
it won't fit in a signle chunk.
This patch implements custom per-page read/write locking mechanism
which is lightweight enough to fit into the z3fold header.
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 148 ++--
1 file changed, 105 insertions(+), 43 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index fea6791..3e30930 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -23,6 +23,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
+#include
#include
#include
#include
@@ -98,6 +99,7 @@ enum buddy {
* struct z3fold_header - z3fold page metadata occupying the first chunk of
each
* z3fold page, except for HEADLESS pages
* @buddy: links the z3fold page into the relevant list in the pool
+ * @page_lock: per-page atomic variable used for locking
* @first_chunks: the size of the first buddy in chunks, 0 if free
* @middle_chunks: the size of the middle buddy in chunks, 0 if free
* @last_chunks: the size of the last buddy in chunks, 0 if free
@@ -105,6 +107,7 @@ enum buddy {
*/
struct z3fold_header {
struct list_head buddy;
+ atomic_t page_lock;
unsigned short first_chunks;
unsigned short middle_chunks;
unsigned short last_chunks;
@@ -144,6 +147,7 @@ static struct z3fold_header *init_z3fold_page(struct page
*page)
clear_bit(PAGE_HEADLESS, &page->private);
clear_bit(MIDDLE_CHUNK_MAPPED, &page->private);
+ atomic_set(&zhdr->page_lock, 0);
zhdr->first_chunks = 0;
zhdr->middle_chunks = 0;
zhdr->last_chunks = 0;
@@ -159,6 +163,39 @@ static void free_z3fold_page(struct z3fold_header *zhdr)
__free_page(virt_to_page(zhdr));
}
+#define Z3FOLD_PAGE_WRITE_FLAG (1 << 15)
+
+/* Read-lock a z3fold page */
+static void z3fold_page_rlock(struct z3fold_header *zhdr)
+{
+ while (!atomic_add_unless(&zhdr->page_lock, 1, Z3FOLD_PAGE_WRITE_FLAG))
+ cpu_relax();
+ smp_mb();
+}
+
+/* Read-unlock a z3fold page */
+static void z3fold_page_runlock(struct z3fold_header *zhdr)
+{
+ atomic_dec(&zhdr->page_lock);
+ smp_mb();
+}
+
+/* Write-lock a z3fold page */
+static void z3fold_page_wlock(struct z3fold_header *zhdr)
+{
+ while (atomic_cmpxchg(&zhdr->page_lock, 0, Z3FOLD_PAGE_WRITE_FLAG) != 0)
+ cpu_relax();
+ smp_mb();
+}
+
+/* Write-unlock a z3fold page */
+static void z3fold_page_wunlock(struct z3fold_header *zhdr)
+{
+ atomic_sub(Z3FOLD_PAGE_WRITE_FLAG, &zhdr->page_lock);
+ smp_mb();
+}
+
+
/*
* Encodes the handle of a particular buddy within a z3fold page
* Pool lock should be held as this function accesses first_num
@@ -343,50 +380,60 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t
size, gfp_t gfp,
bud = HEADLESS;
else {
chunks = size_to_chunks(size);
- spin_lock(&pool->lock);
/* First, try to find an unbuddied z3fold page. */
zhdr = NULL;
for_each_unbuddied_list(i, chunks) {
- if (!list_empty(&pool->unbuddied[i])) {
- zhdr = list_first_entry(&pool->unbuddied[i],
+ spin_lock(&pool->lock);
+ zhdr = list_first_entry_or_null(&pool->unbuddied[i],
struct z3fold_header, buddy);
- page = virt_to_page(zhdr);
- if (zhdr->first_chunks == 0) {
- if (zhdr->middle_chunks != 0 &&
- chunks >= zhdr->start_middle)
- bud = LAST;
- else
- bud = FIRST;
- } else if (zhdr->last_chunks == 0)
+ if (!zhdr) {
+ spin_unlock(&pool->lock);
+ continue;
+ }
+ list_del(&zhdr->buddy);
+ spin_unlock(&pool->lock);
+
+ page = virt_to_page(zhdr);
+ z3fold_page_wlock(zhdr);
+ if (zhdr->first_chunks == 0) {
+ if (zhdr->middle_chunks != 0 &&
+ chunks >= zhdr->start_middle)
bud = LAST;
- else if (zh
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > > Ok, can do, let me recompile and reboot. > > > > > > > > When temperature limit is reached acpi_processor_ppc_notifier() > > > should > > > be called. > > > > No, that's not correct for ACPI passive trip points, is it? If I > > recall correctly, those should be monitored even when temperature is > > below them so that it does not reach them...? > No if BIOS is sending PPC, it will be called. You can try first in 4.8. > > Also try > > Don't run workload, just on an idle system. > > # echo 1 > /sys/class/thermal/cooling_device2/cur_state > monitor the scaling_max_freq, it should reduce > > # echo 2 > /sys/class/thermal/cooling_device2/cur_state > monitor the scaling_max_freq, it should reduce Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also under load, scaling_max_freq changes. But at that point, we are already around 98C... and bios_limit stays the same all the time in v4.9. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat, 2016-11-05 at 14:37 +0100, Pavel Machek wrote: > Hi! > > > > > [...] > > > > > > > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > > > It is possible. Can you add either add printk > > in acpi_processor_ppc_has_changed() or use ftrace and see do you > > get to > > these functions > > > > acpi_processor_ppc_init() > > acpi_processor_ppc_has_changed() > > acpi_processor_ppc_notifier() > > > > ? > > Yes, these seem to be called. Here's the log: Try this 1. Either enable dyndebug or add #define DEBUG 1 at the top of acpi-cpufreq.c 2. diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c index bb01dea..6074995 100644 --- a/drivers/acpi/processor_perflib.c +++ b/drivers/acpi/processor_perflib.c @@ -94,9 +94,14 @@ static int acpi_processor_ppc_notifier(struct notifier_block *nb, ppc = (unsigned int)pr->performance_platform_limit; + printk(KERN_ERR "ppc = %d\n", ppc); + if (ppc >= pr->performance->state_count) goto out; + printk(KERN_ERR "ppc = %d freq-limit %d\n", ppc, pr- >performance->states[ppc]. + core_frequency * 1000); + cpufreq_verify_within_limits(policy, 0, pr->performance->states[ppc]. core_frequency * 1000); Thanks, Srinivas
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat 2016-11-05 14:53:13, Pavel Machek wrote: > Hi! > > > > Ok, can do, let me recompile and reboot. > > > > > > > > > > > When temperature limit is reached acpi_processor_ppc_notifier() > > > > should > > > > be called. > > > > > > No, that's not correct for ACPI passive trip points, is it? If I > > > recall correctly, those should be monitored even when temperature is > > > below them so that it does not reach them...? > > No if BIOS is sending PPC, it will be called. You can try first in 4.8. > > > > Also try > > > > Don't run workload, just on an idle system. > > > > # echo 1 > /sys/class/thermal/cooling_device2/cur_state > > monitor the scaling_max_freq, it should reduce > > > > # echo 2 > /sys/class/thermal/cooling_device2/cur_state > > monitor the scaling_max_freq, it should reduce > > Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also under > load, scaling_max_freq changes. But at that point, we are already > around 98C... and bios_limit stays the same all the time in v4.9. ...while in v4.8-rc1, bios limit goes to 1.0 GHz at 90C, and temperature just doesn't go above that. Does it make sense to try with v4.8-final? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat, 2016-11-05 at 15:04 +0100, Pavel Machek wrote: > On Sat 2016-11-05 14:53:13, Pavel Machek wrote: > > > > Hi! > > > > > > > > > > > > > Ok, can do, let me recompile and reboot. > > > > > > > > > > > > > > > > > > > When temperature limit is > > > > > reached acpi_processor_ppc_notifier() > > > > > should > > > > > be called. > > > > > > > > No, that's not correct for ACPI passive trip points, is it? If > > > > I > > > > recall correctly, those should be monitored even when > > > > temperature is > > > > below them so that it does not reach them...? > > > No if BIOS is sending PPC, it will be called. You can try first > > > in 4.8. > > > > > > Also try > > > > > > Don't run workload, just on an idle system. > > > > > > # echo 1 > /sys/class/thermal/cooling_device2/cur_state > > > monitor the scaling_max_freq, it should reduce > > > > > > # echo 2 > /sys/class/thermal/cooling_device2/cur_state > > > monitor the scaling_max_freq, it should reduce > > > > Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also > > under > > load, scaling_max_freq changes. But at that point, we are already > > around 98C... and bios_limit stays the same all the time in v4.9. > > ...while in v4.8-rc1, bios limit goes to 1.0 GHz at 90C, and > temperature just doesn't go above that. > > Does it make sense to try with v4.8-final? I sent some suggestion to try in previous email to add more prints and enable debug in acpi-cpufreq. Let's try that first. We need to fix anyway even if 4.8-final has this issue. Thanks, Srinivas > > Best regards, > Pavel
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > > > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > > > > > It is possible. Can you add either add printk > > > in acpi_processor_ppc_has_changed() or use ftrace and see do you > > > get to > > > these functions > > > > > > acpi_processor_ppc_init() > > > acpi_processor_ppc_has_changed() > > > acpi_processor_ppc_notifier() > > > > > > ? > > > > Yes, these seem to be called. Here's the log: Ok, burnP6 pushes cpu to 102C rather quickly. dmesg is below. Thanks, Pavel cpu: scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 temp: 82 [65, 82, 65, 44, 66, 33, 33, 44, 51] fan: 2874 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 85 [82, 85, 82, 44, 69, 33, 33, 44, 51] fan: 2874 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 91 [91, 87, 91, 44, 72, 33, 33, 44, 51] fan: 3151 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 94 [94, 88, 94, 44, 74, 33, 33, 44, 51] fan: 3151 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 96 [96, 90, 96, 44, 76, 33, 33, 44, 52] fan: 3531 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 98 [98, 91, 98, 45, 78, 33, 33, 44, 52] fan: 3566 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 100 [100, 92, 100, 44, 79, 33, 33, 44, 52] fan: 3575 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 101 [101, 93, 101, 44, 81, 33, 33, 44, 52] fan: 3594 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 102 [102, 93, 102, 45, 82, 33, 33, 44, 53] fan: 3596 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 102 [102, 91, 102, 44, 83, 33, 33, 44, 53] fan: 3598 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 101 [101, 78, 101, 45, 83, 33, 33, 44, 54] fan: 3599 cpu: scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 temp: 84 [84, 75, 84, 45, 81, 33, 33, 44, 54] [ 21.594684] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 21.703638] NFSD: starting 90-second grace period (net c5015600) [ 27.941612] ppc_notifier [ 27.944682] ppc_notifier: mutex [ 27.947639] ppc = 0 [ 27.950576] ppc_notifier: verify within [ 27.953522] ppc = 0 freq-limit 1833000 [ 27.956474] ppc_notifier [ 27.961414] ppc_notifier [ 27.963050] ppc_notifier: mutex [ 27.964674] ppc = 0 [ 27.966246] ppc_notifier: verify within [ 27.967808] ppc = 0 freq-limit 1833000 [ 27.969404] ppc_notifier [ 32.974593] iwl3945 :03:00.0: loaded firmware version 15.32.2.9 [ 46.298794] wlan0: authenticate with 00:00:00:00:00:01 [ 46.303301] wlan0: send auth to 00:00:00:00:00:01 (try 1/3) [ 46.305173] wlan0: authenticated [ 46.308558] wlan0: associate with 00:00:00:00:00:01 (try 1/3) [ 46.311352] wlan0: RX AssocResp from 00:00:00:00:00:01 (capab=0x401 status=0 aid=4) [ 46.313568] wlan0: associated [ 80.213718] acpi_cpufreq: get_cur_freq_on_cpu (0) [ 80.213744] acpi_cpufreq: get_cur_val = 1555 [ 80.213746] acpi_cpufreq: cur freq = 100 [ 80.215276] acpi_cpufreq: get_cur_freq_on_cpu (1) [ 80.215280] acpi_cpufreq: get_cur_val = 2077 [ 80.215282] acpi_cpufreq: cur freq = 1333000 [ 85.233419] acpi_cpufreq: get_cur_freq_on_cpu (0) [ 85.233441] acpi_cpufreq: get_cur_val = 1555 [ 85.233444] acpi_cpufreq: cur freq = 100 [ 85.235230] acpi_cpufreq: get_cur_freq_on_cpu (1) [ 85.235235] acpi_cpufreq: get_cur_val = 1555 [ 85.235238] acpi_cpufreq: cur freq = 100 [ 90.241835] acpi_cpufreq: get_cur_freq_on_cpu (0) [ 90.241841] acpi_cpufreq: get_cur_val = 2860 [ 90.241843] acpi_cpufreq: cur freq = 1833000 [ 90.242820] acpi_cpufreq: get_cur_freq_on_cpu (1) [ 90.242825] acpi_cpufreq: get_cur_val = 2860 [ 90.242826] acpi_cpufreq: cur freq = 1833000 [ 95.249622] acpi_cpufreq: get_cur_freq_on_cpu (0) [ 95.249628] acpi_cpufreq: get_cur_val = 2860 [ 95.249630] acpi_cpufreq: cur freq = 1833000 [ 95.250608] acpi_cpufreq: get_cur_freq_on_cpu (1) [ 95.250613] acpi_cpufreq: get_cur_val = 2860 [ 95.250614] acpi_cpufreq: cur freq = 1833000 [ 100.257505] acpi_cpufreq: get_cur_freq_on_cpu (0) [ 100.257510] acpi_cpufreq: get_cur_val = 1555 [ 100.257513] acpi_cpufreq: cur freq = 100 [ 100.258490] acpi_cpufreq: get_cur_freq_on_cpu (1) [ 100.258496] acpi_cpufreq: get_cur_val = 2860 [ 100.
[PATCH 1/1] pinctrl: st: st_pinconf_dbg_show wrong format string
function is defined as unsigned int. So we need %u to print it. Signed-off-by: Heinrich Schuchardt --- drivers/pinctrl/pinctrl-st.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c index b7bb371..8308f15 100644 --- a/drivers/pinctrl/pinctrl-st.c +++ b/drivers/pinctrl/pinctrl-st.c @@ -1006,7 +1006,7 @@ static void st_pinconf_dbg_show(struct pinctrl_dev *pctldev, function = st_pctl_get_pin_function(pc, offset); if (function) - snprintf(f, 10, "Alt Fn %d", function); + snprintf(f, 10, "Alt Fn %u", function); else snprintf(f, 5, "GPIO"); -- 2.10.1
[PATCH 1/1] pinctrl: st: st_pctl_dt_parse_groups simplify expression
for_each_property_of_node(pins, pp) checks that pp is not NULL.
So there is no need to check it inside the loop.
Signed-off-by: Heinrich Schuchardt
---
drivers/pinctrl/pinctrl-st.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c
index 8308f15..676efcc 100644
--- a/drivers/pinctrl/pinctrl-st.c
+++ b/drivers/pinctrl/pinctrl-st.c
@@ -1181,7 +1181,7 @@ static int st_pctl_dt_parse_groups(struct device_node *np,
if (!strcmp(pp->name, "name"))
continue;
- if (pp && (pp->length/sizeof(__be32)) >= OF_GPIO_ARGS_MIN) {
+ if (pp->length / sizeof(__be32) >= OF_GPIO_ARGS_MIN) {
npins++;
} else {
pr_warn("Invalid st,pins in %s node\n", np->name);
--
2.10.1
[PATCH 1/1] watchdog: pcipcwd_show_card_info: wrong format string
fw_rev_major and fw_rev_minor are defined as int. Use %d to print them. Signed-off-by: Heinrich Schuchardt --- drivers/watchdog/pcwd_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/pcwd_pci.c b/drivers/watchdog/pcwd_pci.c index c0d07ee..e1fbbf6 100644 --- a/drivers/watchdog/pcwd_pci.c +++ b/drivers/watchdog/pcwd_pci.c @@ -234,7 +234,7 @@ static void pcipcwd_show_card_info(void) got_fw_rev = send_command(CMD_GET_FIRMWARE_VERSION, &fw_rev_major, &fw_rev_minor); if (got_fw_rev) - sprintf(fw_ver_str, "%u.%02u", fw_rev_major, fw_rev_minor); + sprintf(fw_ver_str, "%d.%02d", fw_rev_major, fw_rev_minor); else sprintf(fw_ver_str, ""); -- 2.10.1
[PATCH] net: 3com: typhoon: fix typhoon_get_link_ksettings
When moving from typhoon_get_settings to typhoon_getlink_ksettings
in the commit commit f7a5537cd2a5 ("net: 3com: typhoon: use new api
ethtool_{get|set}_link_ksettings"), we use a local variable supported
but we forgot to update the struct ethtool_link_ksettings with
this value.
We also initialize advertising to zero, because otherwise it may
be uninitialized if no case of the switch (tp->xcvr_select) is used.
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/3com/typhoon.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/3com/typhoon.c
b/drivers/net/ethernet/3com/typhoon.c
index dbdf06f..a0cacbe 100644
--- a/drivers/net/ethernet/3com/typhoon.c
+++ b/drivers/net/ethernet/3com/typhoon.c
@@ -1000,7 +1000,7 @@ enum state_values {
struct ethtool_link_ksettings *cmd)
{
struct typhoon *tp = netdev_priv(dev);
- u32 supported, advertising;
+ u32 supported, advertising = 0;
supported = SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full |
SUPPORTED_Autoneg;
@@ -1049,6 +1049,11 @@ enum state_values {
else
cmd->base.autoneg = AUTONEG_DISABLE;
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
+
return 0;
}
--
1.7.4.4
[PATCH] HID: intel-ish-hid: initialize ts_format.reserved
From: Jiri Kosina ts_format.reserved is not used anywhere yet, but the compiler generates a warning when the struct's (uninitialized) field is being copied around drivers/hid/intel-ish-hid/ipc/ipc.c: In function ‘write_ipc_from_queue’: drivers/hid/intel-ish-hid/ipc/ipc.c:316: warning: ‘ts_format.reserved’ may be used uninitialized in this function Avoid this by force-initializing the field to zero. Signed-off-by: Jiri Kosina --- drivers/hid/intel-ish-hid/ipc/ipc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c index 0c9ac4d..417cd07 100644 --- a/drivers/hid/intel-ish-hid/ipc/ipc.c +++ b/drivers/hid/intel-ish-hid/ipc/ipc.c @@ -310,6 +310,7 @@ static int write_ipc_from_queue(struct ishtp_device *dev) ((uint32_t)tv_utc.tv_usec); ts_format.ts1_source = HOST_SYSTEM_TIME_USEC; ts_format.ts2_source = HOST_UTC_TIME_USEC; + ts_format.reserved = 0; time_update.primary_host_time = usec_system; time_update.secondary_host_time = usec_utc; -- 1.9.2
[PATCH] net: alteon: acenic: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/alteon/acenic.c | 65 ++---
1 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/alteon/acenic.c
b/drivers/net/ethernet/alteon/acenic.c
index a5c1e29..16f0c70 100644
--- a/drivers/net/ethernet/alteon/acenic.c
+++ b/drivers/net/ethernet/alteon/acenic.c
@@ -429,14 +429,16 @@
"acenic.c: v0.92 08/05/2002 Jes Sorensen, linux-ace...@sunsite.dk\n"
"http://home.cern.ch/~jes/gige/acenic.html\n";;
-static int ace_get_settings(struct net_device *, struct ethtool_cmd *);
-static int ace_set_settings(struct net_device *, struct ethtool_cmd *);
+static int ace_get_link_ksettings(struct net_device *,
+ struct ethtool_link_ksettings *);
+static int ace_set_link_ksettings(struct net_device *,
+ const struct ethtool_link_ksettings *);
static void ace_get_drvinfo(struct net_device *, struct ethtool_drvinfo *);
static const struct ethtool_ops ace_ethtool_ops = {
- .get_settings = ace_get_settings,
- .set_settings = ace_set_settings,
.get_drvinfo = ace_get_drvinfo,
+ .get_link_ksettings = ace_get_link_ksettings,
+ .set_link_ksettings = ace_set_link_ksettings,
};
static void ace_watchdog(struct net_device *dev);
@@ -2579,43 +2581,44 @@ static int ace_change_mtu(struct net_device *dev, int
new_mtu)
return 0;
}
-static int ace_get_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+static int ace_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
{
struct ace_private *ap = netdev_priv(dev);
struct ace_regs __iomem *regs = ap->regs;
u32 link;
+ u32 supported;
- memset(ecmd, 0, sizeof(struct ethtool_cmd));
- ecmd->supported =
- (SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full |
-SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full |
-SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full |
-SUPPORTED_Autoneg | SUPPORTED_FIBRE);
+ memset(cmd, 0, sizeof(struct ethtool_link_ksettings));
- ecmd->port = PORT_FIBRE;
- ecmd->transceiver = XCVR_INTERNAL;
+ supported = (SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full |
+SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full |
+SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full |
+SUPPORTED_Autoneg | SUPPORTED_FIBRE);
+
+ cmd->base.port = PORT_FIBRE;
link = readl(®s->GigLnkState);
- if (link & LNK_1000MB)
- ethtool_cmd_speed_set(ecmd, SPEED_1000);
- else {
+ if (link & LNK_1000MB) {
+ cmd->base.speed = SPEED_1000;
+ } else {
link = readl(®s->FastLnkState);
if (link & LNK_100MB)
- ethtool_cmd_speed_set(ecmd, SPEED_100);
+ cmd->base.speed = SPEED_100;
else if (link & LNK_10MB)
- ethtool_cmd_speed_set(ecmd, SPEED_10);
+ cmd->base.speed = SPEED_10;
else
- ethtool_cmd_speed_set(ecmd, 0);
+ cmd->base.speed = 0;
}
if (link & LNK_FULL_DUPLEX)
- ecmd->duplex = DUPLEX_FULL;
+ cmd->base.duplex = DUPLEX_FULL;
else
- ecmd->duplex = DUPLEX_HALF;
+ cmd->base.duplex = DUPLEX_HALF;
if (link & LNK_NEGOTIATE)
- ecmd->autoneg = AUTONEG_ENABLE;
+ cmd->base.autoneg = AUTONEG_ENABLE;
else
- ecmd->autoneg = AUTONEG_DISABLE;
+ cmd->base.autoneg = AUTONEG_DISABLE;
#if 0
/*
@@ -2626,13 +2629,15 @@ static int ace_get_settings(struct net_device *dev,
struct ethtool_cmd *ecmd)
ecmd->txcoal = readl(®s->TuneTxCoalTicks);
ecmd->rxcoal = readl(®s->TuneRxCoalTicks);
#endif
- ecmd->maxtxpkt = readl(®s->TuneMaxTxDesc);
- ecmd->maxrxpkt = readl(®s->TuneMaxRxDesc);
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
return 0;
}
-static int ace_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+static int ace_set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
{
struct ace_private *ap = netdev_priv(dev);
struct ace_regs __iomem *regs = ap->regs;
@@ -2655,11 +2660,11 @@ static int ace_set_settings(struct net_device *dev,
struct ethtool_cmd *ecmd)
LNK_RX_FLOW_CTL_Y | LNK_NEG_FCTL;
if (!ACE_IS_TIGON_I(ap))
link |= LNK_TX_FLOW_CT
Re: [PATCH 1/1] watchdog: pcipcwd_show_card_info: wrong format string
On 11/05/2016 07:50 AM, Heinrich Schuchardt wrote: fw_rev_major and fw_rev_minor are defined as int. Use %d to print them. Signed-off-by: Heinrich Schuchardt --- drivers/watchdog/pcwd_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/pcwd_pci.c b/drivers/watchdog/pcwd_pci.c index c0d07ee..e1fbbf6 100644 --- a/drivers/watchdog/pcwd_pci.c +++ b/drivers/watchdog/pcwd_pci.c @@ -234,7 +234,7 @@ static void pcipcwd_show_card_info(void) got_fw_rev = send_command(CMD_GET_FIRMWARE_VERSION, &fw_rev_major, &fw_rev_minor); if (got_fw_rev) - sprintf(fw_ver_str, "%u.%02u", fw_rev_major, fw_rev_minor); + sprintf(fw_ver_str, "%d.%02d", fw_rev_major, fw_rev_minor); else sprintf(fw_ver_str, ""); Hmm ... I don't think that a negative version number makes much sense. Turns out inb() returns a char on some architectures, meaning it is signed, meaning it _could_ return a negative number if the version number is 128 or above. I don't want to risk us reporting version number -128.-110 just to make compilers happy. Guenter
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > > > Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also > > > under > > > load, scaling_max_freq changes. But at that point, we are already > > > around 98C... and bios_limit stays the same all the time in v4.9. > > > > ...while in v4.8-rc1, bios limit goes to 1.0 GHz at 90C, and > > temperature just doesn't go above that. > > > > Does it make sense to try with v4.8-final? > I sent some suggestion to try in previous email to add more prints and > enable debug in acpi-cpufreq. Let's try that first. We need to fix > anyway even if 4.8-final has this issue. Ok, you should have results in your mailbox now. If you want me to do some more testing, let me know. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v4] ARM: mmp: let clk_disable() return immediately if clk is NULL
Hi Eric Miao, Haojian Zhuang,
Could you pick up this patch, please?
2016-09-19 2:58 GMT+09:00 Masahiro Yamada :
> In many of clk_disable() implementations, it is a no-op for a NULL
> pointer input, but this is one of the exceptions.
>
> Making it treewide consistent will allow clock consumers to call
> clk_disable() without NULL pointer check.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v4:
> - Split into per-arch patches
>
> Changes in v3:
> - Return only when clk is NULL. Do not take care of error pointer.
>
> Changes in v2:
> - Rebase on Linux 4.6-rc1
>
> arch/arm/mach-mmp/clock.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-mmp/clock.c b/arch/arm/mach-mmp/clock.c
> index ac6633d..28fe64c 100644
> --- a/arch/arm/mach-mmp/clock.c
> +++ b/arch/arm/mach-mmp/clock.c
> @@ -67,6 +67,9 @@ void clk_disable(struct clk *clk)
> {
> unsigned long flags;
>
> + if (!clk)
> + return;
> +
> WARN_ON(clk->enabled == 0);
>
> spin_lock_irqsave(&clocks_lock, flags);
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best Regards
Masahiro Yamada
Re: [PATCH 02/10] iio: adc: Add stm32 support
On 03/11/16 08:20, Fabrice Gasnier wrote: > On 10/30/2016 04:27 PM, Jonathan Cameron wrote: >> On 25/10/16 17:25, Fabrice Gasnier wrote: >>> This patch adds support for STMicroelectronics STM32 MCU's analog to >>> digital converter. >>> >>> Signed-off-by: Fabrice Gasnier >> Hi Fabrice, >> >> Sometimes I hate SoC ADCs. For some reason the hardware designers seem to >> try and throw everything and the kitchen sink at them. Discontinuous mode >> as an example in this device. Not seen that particular piece of fun before >> and glad to see you haven't 'yet' tried to support it! >> >> Anyhow, the complexity of the hardware leads to an initially complex driver. >> My first thought it that this would be easier to follow / review if we >> built it up in smaller steps. Perhaps ditch the injected channel support >> entirely in the first instance. I also wonder if you don't need to support >> that whole thing (injected sampling) as another iio device entirely using the >> same channels. That's kind of what it is from a data flow point of view >> (we've had arbitary sequencers before with priorities - don't think anyone >> ever decided the pain was worth supporting the complexity, but right answer >> has always been multiple IIO devices). > Hi Jonathan, > > First, many thanks for your review. I agree with you, most reasonable > approach is to remove some > complexity to ease the review. Regarding injected support, basically, bellow > approach is to use > separate IIO devices for regular and injected. But, I'll remove this, at > least for now, in next patch set. > >> You also have at least one layer of abstraction in here that serves no >> current purpose. Please clear that out for now. It'll make the code >> shorter and easier to follow. If/when other parts are introduced then >> is the time to do that transistion to having the abstraction. > > From your suggestion, this may end-up in a single driver file in drivers/iio. > I think I'll try to keep simple routines like start, stop, conf_scan and so > on, but > remove indirection routines from stm32-adc.h file (e.g. stm32_adc_ops). > Is it in line with your suggestions ? Sure, some of those will want to be in their own functions so it sounds about right. > >> >> My first thought on the double / tripple adc handling is that you'd be better >> off handling them as 3 separate devices then doing some 'unusual' trigger >> handling to support the weird sequencing. Guessing you thought about that? >> If so could you lay out your reasoning for the single driver instance >> approach. >> I'm not arguing against it btw, merely want to understand your reasoning! > > I mainly came up with a single driver instance approach because there are > basically > 3 identical ADC instances 'mapped' in a single IP with few common resources. > I usually see mfd are more heterogeneous and declare cells for various > subsystem drivers. > But I can try to move to mfd as you're suggesting. > I just hope this will not bring more complexity. If anything I suspect it'll end up simpler to read (be it a tiny bit longer in terms of lines of code). > >> >> It would be tricky given one set of channels are selectable over 3 devices >> and there are constraints to enforce (not sampling same channel on two ADCs >> at the same time) but not impossible... Perhaps what you have here is >> indeed simpler! >> >> Whilst it's been a nasty job to review, I'm guessing writing it was >> much worse ;) Pretty good starting point though might take a little while >> to pin down the remaining questions on how best to handle this particular >> monster. > My apologies... I hope you didn't had much of a headache :-) by reading me. > More questions bellow. > >> Jonathan >>> --- >>> drivers/iio/adc/Kconfig | 2 + >>> drivers/iio/adc/Makefile| 1 + >>> drivers/iio/adc/stm32/Kconfig | 34 ++ >>> drivers/iio/adc/stm32/Makefile | 4 + >>> drivers/iio/adc/stm32/stm32-adc.c | 999 >>> >>> drivers/iio/adc/stm32/stm32-adc.h | 442 >>> drivers/iio/adc/stm32/stm32f4-adc.c | 574 + >>> 7 files changed, 2056 insertions(+) >>> create mode 100644 drivers/iio/adc/stm32/Kconfig >>> create mode 100644 drivers/iio/adc/stm32/Makefile >>> create mode 100644 drivers/iio/adc/stm32/stm32-adc.c >>> create mode 100644 drivers/iio/adc/stm32/stm32-adc.h >>> create mode 100644 drivers/iio/adc/stm32/stm32f4-adc.c >>> >>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig >>> index 7edcf32..5c96a55 100644 >>> --- a/drivers/iio/adc/Kconfig >>> +++ b/drivers/iio/adc/Kconfig >>> @@ -583,4 +583,6 @@ config XILINX_XADC >>> The driver can also be build as a module. If so, the module will be >>> called >>> xilinx-xadc. >>> +source "drivers/iio/adc/stm32/Kconfig" >>> + >>> endmenu >>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile >>> index 7a40c04..a9db
Re: [PATCH v4] ARM: w90x900: let clk_disable() return immediately if clk is NULL
Hi Wan,
This patch was acked by you long before,
but it has not been pulled-in yet for some reasons.
Now the patch was split per platform.
So, could you apply this patch to your tree, please?
2016-09-19 2:59 GMT+09:00 Masahiro Yamada :
> In many of clk_disable() implementations, it is a no-op for a NULL
> pointer input, but this is one of the exceptions.
>
> Making it treewide consistent will allow clock consumers to call
> clk_disable() without NULL pointer check.
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Wan Zongshun
> ---
>
> Changes in v4:
> - Split into per-arch patches
>
> Changes in v3:
> - Return only when clk is NULL. Do not take care of error pointer.
>
> Changes in v2:
> - Rebase on Linux 4.6-rc1
>
> arch/arm/mach-w90x900/clock.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-w90x900/clock.c b/arch/arm/mach-w90x900/clock.c
> index 2c371ff..ac6fd1a 100644
> --- a/arch/arm/mach-w90x900/clock.c
> +++ b/arch/arm/mach-w90x900/clock.c
> @@ -46,6 +46,9 @@ void clk_disable(struct clk *clk)
> {
> unsigned long flags;
>
> + if (!clk)
> + return;
> +
> WARN_ON(clk->enabled == 0);
>
> spin_lock_irqsave(&clocks_lock, flags);
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best Regards
Masahiro Yamada
Re: [PATCH v4] blackfin: bf609: let clk_disable() return immediately if clk is NULL
Hi Steven,
Could you take a look at this patch, please?
2016-09-19 3:03 GMT+09:00 Masahiro Yamada :
> In many of clk_disable() implementations, it is a no-op for a NULL
> pointer input, but this is one of the exceptions.
>
> Making it treewide consistent will allow clock consumers to call
> clk_disable() without NULL pointer check.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v4:
> - Split into per-arch patches
>
> Changes in v3:
> - Return only when clk is NULL. Do not take care of error pointer.
>
> Changes in v2:
> - Rebase on Linux 4.6-rc1
>
> arch/blackfin/mach-bf609/clock.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/blackfin/mach-bf609/clock.c
> b/arch/blackfin/mach-bf609/clock.c
> index 3783058..392a59b 100644
> --- a/arch/blackfin/mach-bf609/clock.c
> +++ b/arch/blackfin/mach-bf609/clock.c
> @@ -97,6 +97,9 @@ EXPORT_SYMBOL(clk_enable);
>
> void clk_disable(struct clk *clk)
> {
> + if (!clk)
> + return;
> +
> if (clk->ops && clk->ops->disable)
> clk->ops->disable(clk);
> }
> --
> 1.9.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 2/9] drm/sun4i: support A33 tcon
Hi,
On Tue, Sep 6, 2016 at 10:46 PM, Maxime Ripard
wrote:
> The A33 has a significantly different pipeline, with components that differ
> too.
>
> Make sure we had compatible for them.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 7 ++-
> drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
> drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +---
> drivers/gpu/drm/sun4i/sun4i_tcon.c| 8 +++-
> 4 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index df8f4aeefe4c..bd3136a5cba5 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -26,7 +26,9 @@ TCON
> The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
>
> Required properties:
> - - compatible: value should be "allwinner,sun5i-a13-tcon".
> + - compatible: value must be either:
> + * allwinner,sun5i-a13-tcon
> + * allwinner,sun8i-a33-tcon
> - reg: base address and size of memory-mapped region
> - interrupts: interrupt associated to this IP
> - clocks: phandles to the clocks feeding the TCON. Three are needed:
> @@ -59,6 +61,7 @@ system.
> Required properties:
>- compatible: value must be one of:
> * allwinner,sun5i-a13-display-backend
> +* allwinner,sun8i-a33-display-backend
>- reg: base address and size of the memory-mapped region.
>- clocks: phandles to the clocks feeding the frontend and backend
> * ahb: the backend interface clock
> @@ -80,6 +83,7 @@ deinterlacing and color space conversion.
> Required properties:
>- compatible: value must be one of:
> * allwinner,sun5i-a13-display-frontend
> +* allwinner,sun8i-a33-display-frontend
I just looked at the A23. It seems it's the same display frontend as the A33.
Should we change the compatible string to a23 while it's still in RC?
The backend is probably different. The A33 only claims to support 2048x2048
layers, while the A23 claims to support 8192x8192 layers.
Regards
ChenYu
>- reg: base address and size of the memory-mapped region.
>- interrupts: interrupt associated to this IP
>- clocks: phandles to the clocks feeding the frontend and backend
> @@ -104,6 +108,7 @@ extra node.
> Required properties:
>- compatible: value must be one of:
> * allwinner,sun5i-a13-display-engine
> +* allwinner,sun8i-a33-display-engine
>
>- allwinner,pipelines: list of phandle to the display engine
> frontends available.
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 3ab560450a82..9bfd2e45fceb 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -345,6 +345,7 @@ static int sun4i_backend_remove(struct platform_device
> *pdev)
>
> static const struct of_device_id sun4i_backend_of_table[] = {
> { .compatible = "allwinner,sun5i-a13-display-backend" },
> + { .compatible = "allwinner,sun8i-a33-display-backend" },
> { }
> };
> MODULE_DEVICE_TABLE(of, sun4i_backend_of_table);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 942f62e2441c..c4d03c1b6db8 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -199,13 +199,14 @@ static const struct component_master_ops
> sun4i_drv_master_ops = {
>
> static bool sun4i_drv_node_is_frontend(struct device_node *node)
> {
> - return of_device_is_compatible(node,
> -
> "allwinner,sun5i-a13-display-frontend");
> + return of_device_is_compatible(node,
> "allwinner,sun5i-a13-display-frontend") ||
> + of_device_is_compatible(node,
> "allwinner,sun8i-a33-display-frontend");
> }
>
> static bool sun4i_drv_node_is_tcon(struct device_node *node)
> {
> - return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon");
> + return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
> + of_device_is_compatible(node, "allwinner,sun8i-a33-tcon");
> }
>
> static int compare_of(struct device *dev, void *data)
> @@ -320,6 +321,7 @@ static int sun4i_drv_remove(struct platform_device *pdev)
>
> static const struct of_device_id sun4i_drv_of_table[] = {
> { .compatible = "allwinner,sun5i-a13-display-engine" },
> + { .compatible = "allwinner,sun8i-a33-display-engine" },
> { }
> };
> MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index fde6af1230d2..cadacb517f95 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -488,8 +488,13 @@ static int sun4i_tcon_bi
Re: [PATCH] hid: sensor: fix input and feature attributes in HID sensor custom sysfs interface
On Thu, 3 Nov 2016, Ooi, Joyce wrote: > User is unable to access to input-X-yyy and feature-X-yyy where > X is a hex value and more than 9 (e.g. input-a-yyy, feature-b-yyy) in HID > sensor custom sysfs interface. > This is because when creating the attribute, the attribute index is > written to using %x (hex). However, when reading and writing values into > the attribute, the attribute index is scanned using %d (decimal). Hence, > user is unable to access to attributes with index in hex values > (e.g. 'a', 'b', 'c') but able to access to attributes with index in > decimal values (e.g. 1, 2, 3,..). > This fix will change input-%d-%x-%s and feature-%d-%x-%s to input-%x-%x-%s > and feature-%x-%x-%s in show_values() and store_values() accordingly. > > Signed-off-by: Ooi, Joyce Applied to hid.git#for-4.9/upstream-fixes. Thanks, -- Jiri Kosina SUSE Labs
Re: task isolation discussion at Linux Plumbers
On Sat, 5 Nov 2016, Chris Metcalf wrote: > Here are the notes I took; I welcome any corrections and follow-up. Thank you for writing this up. I hope we can now move forward further on these issues. > == Remote statistics == > > We discussed the possibility of remote statistics gathering, i.e. load > average etc. The idea would be that we could have housekeeping > core(s) periodically iterate over the nohz cores to load their rq > remotely and do update_current etc. Presumably it should be possible > for a single housekeeping core to handle doing this for all the > nohz_full cores, as we only need to do it quite infrequently. > > Thomas suggested that this might be the last remaining thing that > needed to be done to allow disabling the current behavior of falling > back to a 1 Hz clock in nohz_full. > > I believe Thomas said he had a patch to do this already. Note that the vmstat_shepherd already scans idle cpus ever 2 seconds to see if there are new updates top vm statistics that require the reactivation of the vmstat updater. It would be possible to opportunistically update the thread statistics should the remove cpu be in user space (if one figures out the synchronization issues for remote per cpu updates) > == Quiescing vmstat == > > Another issue that task isolation handles is ensuring that the vmstat > worker is quiesced before returning to user space. Currently we > cancel the vmstat delayed work, then invoke refresh_cpu_vm_stats(). > Currently neither of these things appears safe to do in the > interrupts-disabled context just before return to userspace, because > they both can call schedule(): refresh_cpu_vm_stats() via a > cond_resched() under CONFIG_NUMA, and cancel_delayed_work_sync() via a > schedule() in __cancel_work_timer(). > > Christoph offered to work with me to make sure that we could do the > appropriate quiescing with interrupts disabled, and seemed confident > it should be doable. This is already implemented. You can call refresh_cpu_vm_stats(false) to do the quiescing with interrupts disabled.
Re: [PATCH 1/6] staging: iio: set proper supply name to devm_regulator_get()
On 05/11/16 12:58, Jonathan Cameron wrote: > On 01/11/16 19:58, Lars-Peter Clausen wrote: >> On 11/01/2016 05:03 AM, Matt Ranostay wrote: >>> On Mon, Oct 31, 2016 at 10:04 AM, Eva Rachel Retuya >>> wrote: The name passed to devm_regulator_get() should match the name of the supply as specified in the device datasheet. This makes it clear what power supply is being referred to in case of presence of other regulators. Currently, the supply name specified on the affected devices is 'vcc'. Use lowercase version of the datasheet name to specify the supply voltage. >>> >>> Aren't we possibly breaking current device tree definitions that >>> people may have? We should still check the old name after the new >>> datasheet name in my opinion. >> >> None of those drivers have DT bindings, so I think we are OK. And they are >> in staging anyway. >> > I agree on this. These are technically in kernel interfaces so we > are fine to change them. Would have been more interesting if > there were DT bindings however and we would have had to support > the old and new naming for a while at least (i.e. probably forever > as we'd never get around to cleaning it up!) Of course, the old 'magic matching' that i2c and spi do which could allow these devices to be instantiated with regulators from the device tree makes it just possible someone is doing this. We'll take the good kernel approach of perhaps considering a adding in compatibility support for the old option if someone screams. We are find for some of them though as they NEED platform data to probe anyway which device tree obviously can't magically supply. The ad7780 is the only risky one I think. Jonathan > > Jonathan > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH 1/6] staging: iio: set proper supply name to devm_regulator_get()
On 31/10/16 17:04, Eva Rachel Retuya wrote:
> The name passed to devm_regulator_get() should match the name of the
> supply as specified in the device datasheet. This makes it clear what
> power supply is being referred to in case of presence of other
> regulators.
>
> Currently, the supply name specified on the affected devices is 'vcc'.
> Use lowercase version of the datasheet name to specify the supply
> voltage.
>
> Suggested-by: Lars-Peter Clausen
> Signed-off-by: Eva Rachel Retuya
Applied to the togreg branch of iio.git which will be initially pushed
out as testing for the autobuilders to play with them.
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c| 2 +-
> drivers/staging/iio/adc/ad7780.c| 2 +-
> drivers/staging/iio/frequency/ad9832.c | 2 +-
> drivers/staging/iio/frequency/ad9834.c | 2 +-
> drivers/staging/iio/impedance-analyzer/ad5933.c | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index bfa12ce..41fb32d 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -633,7 +633,7 @@ static int ad7192_probe(struct spi_device *spi)
>
> st = iio_priv(indio_dev);
>
> - st->reg = devm_regulator_get(&spi->dev, "vcc");
> + st->reg = devm_regulator_get(&spi->dev, "avdd");
> if (!IS_ERR(st->reg)) {
> ret = regulator_enable(st->reg);
> if (ret)
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index c9a0c2a..a88236e 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -173,7 +173,7 @@ static int ad7780_probe(struct spi_device *spi)
>
> ad_sd_init(&st->sd, indio_dev, spi, &ad7780_sigma_delta_info);
>
> - st->reg = devm_regulator_get(&spi->dev, "vcc");
> + st->reg = devm_regulator_get(&spi->dev, "avdd");
> if (!IS_ERR(st->reg)) {
> ret = regulator_enable(st->reg);
> if (ret)
> diff --git a/drivers/staging/iio/frequency/ad9832.c
> b/drivers/staging/iio/frequency/ad9832.c
> index 358400b..744c8ee 100644
> --- a/drivers/staging/iio/frequency/ad9832.c
> +++ b/drivers/staging/iio/frequency/ad9832.c
> @@ -212,7 +212,7 @@ static int ad9832_probe(struct spi_device *spi)
> return -ENODEV;
> }
>
> - reg = devm_regulator_get(&spi->dev, "vcc");
> + reg = devm_regulator_get(&spi->dev, "avdd");
> if (!IS_ERR(reg)) {
> ret = regulator_enable(reg);
> if (ret)
> diff --git a/drivers/staging/iio/frequency/ad9834.c
> b/drivers/staging/iio/frequency/ad9834.c
> index 6366216..ca3cea6 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -329,7 +329,7 @@ static int ad9834_probe(struct spi_device *spi)
> return -ENODEV;
> }
>
> - reg = devm_regulator_get(&spi->dev, "vcc");
> + reg = devm_regulator_get(&spi->dev, "avdd");
> if (!IS_ERR(reg)) {
> ret = regulator_enable(reg);
> if (ret)
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index 5eecf1c..62f61bc 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -723,7 +723,7 @@ static int ad5933_probe(struct i2c_client *client,
> if (!pdata)
> pdata = &ad5933_default_pdata;
>
> - st->reg = devm_regulator_get(&client->dev, "vcc");
> + st->reg = devm_regulator_get(&client->dev, "vdd");
> if (!IS_ERR(st->reg)) {
> ret = regulator_enable(st->reg);
> if (ret)
>
[GIT pull] scheduler fixes for 4.9
Linus, please pull the latest sched-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-urgent-for-linus Two small patches related to sched_show_task(): - Make sure to hold a reference on the task stack while accessing it - Remove the thread_saved_pc printout Thanks, tglx --> Linus Torvalds (1): sched/core: Remove pointless printout in sched_show_task() Tetsuo Handa (1): sched/core: Fix oops in sched_show_task() kernel/sched/core.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 42d4027f9e26..154fd689fe02 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5192,21 +5192,14 @@ void sched_show_task(struct task_struct *p) int ppid; unsigned long state = p->state; + if (!try_get_task_stack(p)) + return; if (state) state = __ffs(state) + 1; printk(KERN_INFO "%-15.15s %c", p->comm, state < sizeof(stat_nam) - 1 ? stat_nam[state] : '?'); -#if BITS_PER_LONG == 32 - if (state == TASK_RUNNING) - printk(KERN_CONT " running "); - else - printk(KERN_CONT " %08lx ", thread_saved_pc(p)); -#else if (state == TASK_RUNNING) printk(KERN_CONT " running task"); - else - printk(KERN_CONT " %016lx ", thread_saved_pc(p)); -#endif #ifdef CONFIG_DEBUG_STACK_USAGE free = stack_not_used(p); #endif @@ -5221,6 +5214,7 @@ void sched_show_task(struct task_struct *p) print_worker_info(KERN_INFO, p); show_stack(p, NULL); + put_task_stack(p); } void show_state_filter(unsigned long state_filter)
[git pull] FireWire fixes
Linus, please pull from the tag "firewire-fixes" at git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git firewire-fixes to receive the following FireWire (IEEE 1394) subsystem fixes: - Add missing input validation to the firewire-net driver. Invalid IP-over-1394 encapsulation headers could trigger buffer overflows (CVE 2016-8633). - IP-over-1394 link fragmentation headers were read and written incorrectly, breaking fragmented RX/TX with other OS's stacks. Stefan Richter (2): firewire: net: guard against rx buffer overflows firewire: net: fix fragmented datagram_size off-by-one drivers/firewire/net.c | 59 -- 1 file changed, 39 insertions(+), 20 deletions(-) Thanks, -- Stefan Richter -==- =-== --=-= http://arcgraph.de/sr/
[GIT pull] core fix for 4.9
Linus,
please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
Add a sanity check into release_task_stack() to catch problems with task
stack references.
Thanks,
tglx
-->
Andy Lutomirski (1):
fork: Add task stack refcounting sanity check and prevent premature task
stack freeing
kernel/fork.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index 623259fc794d..997ac1d584f7 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -315,6 +315,9 @@ static void account_kernel_stack(struct task_struct *tsk,
int account)
static void release_task_stack(struct task_struct *tsk)
{
+ if (WARN_ON(tsk->state != TASK_DEAD))
+ return; /* Better to leak the stack than to free prematurely */
+
account_kernel_stack(tsk, -1);
arch_release_thread_stack(tsk->stack);
free_thread_stack(tsk);
@@ -1862,6 +1865,7 @@ static __latent_entropy struct task_struct *copy_process(
atomic_dec(&p->cred->user->processes);
exit_creds(p);
bad_fork_free:
+ p->state = TASK_DEAD;
put_task_stack(p);
free_task(p);
fork_out:
Re: [PATCH 2/6] staging: iio: rework regulator handling
On 31/10/16 17:04, Eva Rachel Retuya wrote:
> Currently, the affected drivers ignore all errors from regulator_get().
> The way it is now, it also breaks probe deferral (EPROBE_DEFER). The
> correct behavior is to propagate the error to the upper layers so they
> can handle it accordingly.
>
> Rework the regulator handling so that it matches the standard behavior.
> If the specific design uses a static always-on regulator and does not
> explicitly specify it, regulator_get() will return the dummy regulator.
>
> The following semantic patch was used to apply the change:
> @r1@
> expression reg, dev, en, volt;
> @@
>
> reg = \(devm_regulator_get\|regulator_get\)(dev, ...);
> if (
> - !
>IS_ERR(reg))
> + return PTR_ERR(reg);
> (
> - { en = regulator_enable(reg);
> - if (en) return en; }
> +
> + en = regulator_enable(reg);
> + if (en) {
> + dev_err(dev, "Failed to enable specified supply\n");
> + return en; }
> |
> +
> - { en = regulator_enable(reg);
> - if (en) return en;
> - volt = regulator_get_voltage(reg); }
> + en = regulator_enable(reg);
> + if (en) {
> + dev_err(dev, "Failed to enable specified supply\n");
> + return en;
> + }
> + volt = regulator_get_voltage(reg);
> )
>
> @r2@
> expression arg;
> @@
>
> - if (!IS_ERR(arg)) regulator_disable(arg);
> + regulator_disable(arg);
>
> Hand-edit the debugging prints with the supply name to become more
> specific.
>
> Suggested-by: Lars-Peter Clausen
> Signed-off-by: Eva Rachel Retuya
Nice patch.
Applied to the togreg branch of iio.git and will be pushed out as
testing for the autobuilders to play with them.
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c| 18 +-
> drivers/staging/iio/adc/ad7780.c| 18 +-
> drivers/staging/iio/frequency/ad9832.c | 17 +
> drivers/staging/iio/frequency/ad9834.c | 17 +
> drivers/staging/iio/impedance-analyzer/ad5933.c | 19 ++-
> 5 files changed, 46 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index 41fb32d..29e32b7 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -634,13 +634,15 @@ static int ad7192_probe(struct spi_device *spi)
> st = iio_priv(indio_dev);
>
> st->reg = devm_regulator_get(&spi->dev, "avdd");
> - if (!IS_ERR(st->reg)) {
> - ret = regulator_enable(st->reg);
> - if (ret)
> - return ret;
> + if (IS_ERR(st->reg))
> + return PTR_ERR(st->reg);
>
> - voltage_uv = regulator_get_voltage(st->reg);
> + ret = regulator_enable(st->reg);
> + if (ret) {
> + dev_err(&spi->dev, "Failed to enable specified AVdd supply\n");
> + return ret;
> }
> + voltage_uv = regulator_get_voltage(st->reg);
>
> if (pdata->vref_mv)
> st->int_vref_mv = pdata->vref_mv;
> @@ -689,8 +691,7 @@ static int ad7192_probe(struct spi_device *spi)
> error_remove_trigger:
> ad_sd_cleanup_buffer_and_trigger(indio_dev);
> error_disable_reg:
> - if (!IS_ERR(st->reg))
> - regulator_disable(st->reg);
> + regulator_disable(st->reg);
>
> return ret;
> }
> @@ -703,8 +704,7 @@ static int ad7192_remove(struct spi_device *spi)
> iio_device_unregister(indio_dev);
> ad_sd_cleanup_buffer_and_trigger(indio_dev);
>
> - if (!IS_ERR(st->reg))
> - regulator_disable(st->reg);
> + regulator_disable(st->reg);
>
> return 0;
> }
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index a88236e..e149600 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -174,13 +174,15 @@ static int ad7780_probe(struct spi_device *spi)
> ad_sd_init(&st->sd, indio_dev, spi, &ad7780_sigma_delta_info);
>
> st->reg = devm_regulator_get(&spi->dev, "avdd");
> - if (!IS_ERR(st->reg)) {
> - ret = regulator_enable(st->reg);
> - if (ret)
> - return ret;
> + if (IS_ERR(st->reg))
> + return PTR_ERR(st->reg);
>
> - voltage_uv = regulator_get_voltage(st->reg);
> + ret = regulator_enable(st->reg);
> + if (ret) {
> + dev_err(&spi->dev, "Failed to enable specified AVdd supply\n");
> + return ret;
> }
> + voltage_uv = regulator_get_voltage(st->reg);
>
> st->chip_info =
> &ad7780_chip_info_tbl[spi_get_device_id(spi)->driver_data];
> @@ -222,8 +224,7 @@ static int ad7780_probe(struct spi_device *spi)
> error_cleanup_buffer_and_trigger:
> ad_sd_cleanup_buffer_and_trigger(indio_dev);
> error_disable_reg:
> - if (!IS_ERR(st->reg))
> - regulator_disable(st->reg);
> +
Re: [PATCH 3/6] staging: iio: ad7192: add DVdd regulator
On 31/10/16 17:04, Eva Rachel Retuya wrote:
> The AD7190/AD7192/AD7193/AD7195 is supplied with two power sources:
> AVdd as analog supply voltage and DVdd as digital supply voltage.
>
> Attempt to fetch and enable the regulator 'dvdd'. Bail out if any error
> occurs.
>
> Suggested-by: Lars-Peter Clausen
> Signed-off-by: Eva Rachel Retuya
Looks good. Applied to the togreg branch of iio.git etc etc.
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index 29e32b7..3f8dc66 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -153,6 +153,7 @@
>
> struct ad7192_state {
> struct regulator*reg;
> + struct regulator*dvdd;
> u16 int_vref_mv;
> u32 mclk;
> u32 f_order;
> @@ -642,6 +643,19 @@ static int ad7192_probe(struct spi_device *spi)
> dev_err(&spi->dev, "Failed to enable specified AVdd supply\n");
> return ret;
> }
> +
> + st->dvdd = devm_regulator_get(&spi->dev, "dvdd");
> + if (IS_ERR(st->dvdd)) {
> + ret = PTR_ERR(st->dvdd);
> + goto error_disable_reg;
> + }
> +
> + ret = regulator_enable(st->dvdd);
> + if (ret) {
> + dev_err(&spi->dev, "Failed to enable specified DVdd supply\n");
> + goto error_disable_reg;
> + }
> +
> voltage_uv = regulator_get_voltage(st->reg);
>
> if (pdata->vref_mv)
> @@ -677,7 +691,7 @@ static int ad7192_probe(struct spi_device *spi)
>
> ret = ad_sd_setup_buffer_and_trigger(indio_dev);
> if (ret)
> - goto error_disable_reg;
> + goto error_disable_dvdd;
>
> ret = ad7192_setup(st, pdata);
> if (ret)
> @@ -690,6 +704,8 @@ static int ad7192_probe(struct spi_device *spi)
>
> error_remove_trigger:
> ad_sd_cleanup_buffer_and_trigger(indio_dev);
> +error_disable_dvdd:
> + regulator_disable(st->dvdd);
> error_disable_reg:
> regulator_disable(st->reg);
>
> @@ -704,6 +720,7 @@ static int ad7192_remove(struct spi_device *spi)
> iio_device_unregister(indio_dev);
> ad_sd_cleanup_buffer_and_trigger(indio_dev);
>
> + regulator_disable(st->dvdd);
> regulator_disable(st->reg);
>
> return 0;
>
[PATCH 2/2] regulator: rn5t618: add RC5T619 PMIC support
Extend the driver to support Ricoh RC5T619.
Support the additional regulators and slightly different voltage ranges.
Signed-off-by: Pierre-Hugues Husson
---
drivers/regulator/Kconfig | 4 ++--
drivers/regulator/rn5t618-regulator.c | 35 +++
include/linux/mfd/rn5t618.h | 6 ++
3 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 936f7cc..7b48b1a 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -656,8 +656,8 @@ config REGULATOR_RN5T618
tristate "Ricoh RN5T567/618 voltage regulators"
depends on MFD_RN5T618
help
- Say y here to support the regulators found on Ricoh RN5T567 or
- RN5T618 PMIC.
+ Say y here to support the regulators found on Ricoh RN5T567,
+ RN5T618 or RC5T619 PMIC.
config REGULATOR_RT5033
tristate "Richtek RT5033 Regulators"
diff --git a/drivers/regulator/rn5t618-regulator.c
b/drivers/regulator/rn5t618-regulator.c
index 9c930eb..e7bc15b 100644
--- a/drivers/regulator/rn5t618-regulator.c
+++ b/drivers/regulator/rn5t618-regulator.c
@@ -79,6 +79,29 @@ static struct regulator_desc rn5t618_regulators[] = {
REG(LDORTC2, LDOEN2, BIT(5), LDORTC2DAC, 0x7f, 90, 350, 25000),
};
+static struct regulator_desc rc5t619_regulators[] = {
+ /* DCDC */
+ REG(DCDC1, DC1CTL, BIT(0), DC1DAC, 0xff, 60, 350, 12500),
+ REG(DCDC2, DC2CTL, BIT(0), DC2DAC, 0xff, 60, 350, 12500),
+ REG(DCDC3, DC3CTL, BIT(0), DC3DAC, 0xff, 60, 350, 12500),
+ REG(DCDC4, DC4CTL, BIT(0), DC4DAC, 0xff, 60, 350, 12500),
+ REG(DCDC5, DC5CTL, BIT(0), DC5DAC, 0xff, 60, 350, 12500),
+ /* LDO */
+ REG(LDO1, LDOEN1, BIT(0), LDO1DAC, 0x7f, 90, 350, 25000),
+ REG(LDO2, LDOEN1, BIT(1), LDO2DAC, 0x7f, 90, 350, 25000),
+ REG(LDO3, LDOEN1, BIT(2), LDO3DAC, 0x7f, 90, 350, 25000),
+ REG(LDO4, LDOEN1, BIT(3), LDO4DAC, 0x7f, 90, 350, 25000),
+ REG(LDO5, LDOEN1, BIT(4), LDO5DAC, 0x7f, 60, 350, 25000),
+ REG(LDO6, LDOEN1, BIT(5), LDO6DAC, 0x7f, 60, 350, 25000),
+ REG(LDO7, LDOEN1, BIT(6), LDO7DAC, 0x7f, 90, 350, 25000),
+ REG(LDO8, LDOEN1, BIT(7), LDO8DAC, 0x7f, 90, 350, 25000),
+ REG(LDO9, LDOEN2, BIT(0), LDO9DAC, 0x7f, 90, 350, 25000),
+ REG(LDO10, LDOEN2, BIT(0), LDO10DAC, 0x7f, 90, 350, 25000),
+ /* LDO RTC */
+ REG(LDORTC1, LDOEN2, BIT(4), LDORTCDAC, 0x7f, 170, 350, 25000),
+ REG(LDORTC2, LDOEN2, BIT(5), LDORTC2DAC, 0x7f, 90, 350, 25000),
+};
+
static int rn5t618_regulator_probe(struct platform_device *pdev)
{
struct rn5t618 *rn5t618 = dev_get_drvdata(pdev->dev.parent);
@@ -86,13 +109,20 @@ static int rn5t618_regulator_probe(struct platform_device
*pdev)
struct regulator_dev *rdev;
struct regulator_desc *regulators;
int i;
+ int num_regulators = 0;
switch (rn5t618->variant) {
case RN5T567:
regulators = rn5t567_regulators;
+ num_regulators = ARRAY_SIZE(rn5t567_regulators);
break;
case RN5T618:
regulators = rn5t618_regulators;
+ num_regulators = ARRAY_SIZE(rn5t618_regulators);
+ break;
+ case RC5T619:
+ regulators = rc5t619_regulators;
+ num_regulators = ARRAY_SIZE(rc5t619_regulators);
break;
default:
return -EINVAL;
@@ -101,10 +131,7 @@ static int rn5t618_regulator_probe(struct platform_device
*pdev)
config.dev = pdev->dev.parent;
config.regmap = rn5t618->regmap;
- for (i = 0; i < RN5T618_REG_NUM; i++) {
- if (!regulators[i].name)
- continue;
-
+ for (i = 0; i < num_regulators; i++) {
rdev = devm_regulator_register(&pdev->dev,
®ulators[i],
&config);
diff --git a/include/linux/mfd/rn5t618.h b/include/linux/mfd/rn5t618.h
index e5a6cde..d61bc58 100644
--- a/include/linux/mfd/rn5t618.h
+++ b/include/linux/mfd/rn5t618.h
@@ -226,11 +226,17 @@ enum {
RN5T618_DCDC2,
RN5T618_DCDC3,
RN5T618_DCDC4,
+ RN5T618_DCDC5,
RN5T618_LDO1,
RN5T618_LDO2,
RN5T618_LDO3,
RN5T618_LDO4,
RN5T618_LDO5,
+ RN5T618_LDO6,
+ RN5T618_LDO7,
+ RN5T618_LDO8,
+ RN5T618_LDO9,
+ RN5T618_LDO10,
RN5T618_LDORTC1,
RN5T618_LDORTC2,
RN5T618_REG_NUM,
--
2.10.1
[PATCH 1/2] mfd: rn5t618: Add Ricoh RC5T619 PMIC support
The Ricoh RN5T567 is from the same family as the Ricoh RN5T618 is,
the differences are:
+ DCDC4/DCDC5
+ LDO7-10
+ Slightly different output voltage/currents
+ 32kHz Output
+ RTC
+ USB Charger detection
Signed-off-by: Pierre-Hugues Husson
---
Documentation/devicetree/bindings/mfd/rn5t618.txt | 16 ++--
drivers/mfd/Kconfig | 3 ++-
drivers/mfd/rn5t618.c | 1 +
include/linux/mfd/rn5t618.h | 9 +
4 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt
b/Documentation/devicetree/bindings/mfd/rn5t618.txt
index 9e6770b..65c2326 100644
--- a/Documentation/devicetree/bindings/mfd/rn5t618.txt
+++ b/Documentation/devicetree/bindings/mfd/rn5t618.txt
@@ -1,21 +1,25 @@
* Ricoh RN5T567/RN5T618 PMIC
-Ricoh RN5T567/RN5T618 is a power management IC family which integrates
-3 to 4 step-down DCDC converters, 7 low-dropout regulators, GPIOs and
-a watchdog timer. The RN5T618 provides additionally a Li-ion battery
-charger, fuel gauge and an ADC. It can be controlled through an I2C
-interface.
+Ricoh RN5T567/RN5T618/RC5T619 is a power management IC family which
+integrates 3 to 5 step-down DCDC converters, 7 to 10 low-dropout regulators,
+GPIOs, and a watchdog timer. It can be controlled through an I2C interface.
+The RN5T618/RC5T619 provides additionally a Li-ion battery charger,
+fuel gauge, and an ADC.
+The RC5T619 additionnally includes USB charger detection and an RTC.
Required properties:
- compatible: must be one of
"ricoh,rn5t567"
"ricoh,rn5t618"
+ "ricoh,rc5t619"
- reg: the I2C slave address of the device
Sub-nodes:
- regulators: the node is required if the regulator functionality is
needed. The valid regulator names are: DCDC1, DCDC2, DCDC3, DCDC4
- (RN5T567), LDO1, LDO2, LDO3, LDO4, LDO5, LDORTC1 and LDORTC2.
+ (RN5T567/RC5T619), LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7, LDO8,
+ LDO9, LDO10, LDORTC1 and LDORTC2.
+ LDO7-10 are specific to RC5T619.
The common bindings for each individual regulator can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c6df644..65d0a65 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -881,7 +881,8 @@ config MFD_RN5T618
select MFD_CORE
select REGMAP_I2C
help
- Say yes here to add support for the Ricoh RN5T567 or R5T618 PMIC.
+ Say yes here to add support for the Ricoh RN5T567,
+ RN5T618, RC5T619 PMIC.
This driver provides common support for accessing the device,
additional drivers must be enabled in order to use the
functionality of the device.
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index 9d377d6..0b5a2a1 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -87,6 +87,7 @@ static int rn5t618_restart(struct notifier_block *this,
static const struct of_device_id rn5t618_of_match[] = {
{ .compatible = "ricoh,rn5t567", .data = (void *)RN5T567 },
{ .compatible = "ricoh,rn5t618", .data = (void *)RN5T618 },
+ { .compatible = "ricoh,rc5t619", .data = (void *)RC5T619 },
{ }
};
MODULE_DEVICE_TABLE(of, rn5t618_of_match);
diff --git a/include/linux/mfd/rn5t618.h b/include/linux/mfd/rn5t618.h
index cadc654..e5a6cde 100644
--- a/include/linux/mfd/rn5t618.h
+++ b/include/linux/mfd/rn5t618.h
@@ -58,10 +58,13 @@
#define RN5T618_DC3CTL20x31
#define RN5T618_DC4CTL 0x32
#define RN5T618_DC4CTL20x33
+#define RN5T618_DC5CTL 0x34
+#define RN5T618_DC5CTL20x35
#define RN5T618_DC1DAC 0x36
#define RN5T618_DC2DAC 0x37
#define RN5T618_DC3DAC 0x38
#define RN5T618_DC4DAC 0x39
+#define RN5T618_DC5DAC 0x3a
#define RN5T618_DC1DAC_SLP 0x3b
#define RN5T618_DC2DAC_SLP 0x3c
#define RN5T618_DC3DAC_SLP 0x3d
@@ -77,6 +80,11 @@
#define RN5T618_LDO3DAC0x4e
#define RN5T618_LDO4DAC0x4f
#define RN5T618_LDO5DAC0x50
+#define RN5T618_LDO6DAC0x51
+#define RN5T618_LDO7DAC0x52
+#define RN5T618_LDO8DAC0x53
+#define RN5T618_LDO9DAC0x54
+#define RN5T618_LDO10DAC 0x55
#define RN5T618_LDORTCDAC 0x56
#define RN5T618_LDORTC2DAC 0x57
#define RN5T618_LDO1DAC_SLP0x58
@@ -231,6 +239,7 @@ enum {
enum {
RN5T567 = 0,
RN5T618,
+ RC5T619,
};
struct rn5t618 {
--
2.10.1
[PATCH 0/2] mfd: add Ricoh RC5T619 PMIC support
This patchset adds RC5T619 support. This PMIC is used on many rockchip-based devices, for instance the GPD XD, or the Archos 101 Oxygen --- Documentation/devicetree/bindings/mfd/rn5t618.txt | 16 +++-- drivers/mfd/Kconfig |3 - drivers/mfd/rn5t618.c |1 drivers/regulator/Kconfig |4 - drivers/regulator/rn5t618-regulator.c | 35 ++-- include/linux/mfd/rn5t618.h | 15 + 6 files changed, 61 insertions(+), 13 deletions(-)
Re: [PATCH 4/6] staging: iio: ad7192: rename regulator 'reg' to 'avdd'
On 31/10/16 17:04, Eva Rachel Retuya wrote:
> Rename regulator 'reg' to 'avdd' so as to be clear what regulator it
> stands for specifically. Also, update the goto label accordingly.
>
> Signed-off-by: Eva Rachel Retuya
Applied.
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index 3f8dc66..1fb68c0 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -152,7 +152,7 @@
> */
>
> struct ad7192_state {
> - struct regulator*reg;
> + struct regulator*avdd;
> struct regulator*dvdd;
> u16 int_vref_mv;
> u32 mclk;
> @@ -634,11 +634,11 @@ static int ad7192_probe(struct spi_device *spi)
>
> st = iio_priv(indio_dev);
>
> - st->reg = devm_regulator_get(&spi->dev, "avdd");
> - if (IS_ERR(st->reg))
> - return PTR_ERR(st->reg);
> + st->avdd = devm_regulator_get(&spi->dev, "avdd");
> + if (IS_ERR(st->avdd))
> + return PTR_ERR(st->avdd);
>
> - ret = regulator_enable(st->reg);
> + ret = regulator_enable(st->avdd);
> if (ret) {
> dev_err(&spi->dev, "Failed to enable specified AVdd supply\n");
> return ret;
> @@ -647,16 +647,16 @@ static int ad7192_probe(struct spi_device *spi)
> st->dvdd = devm_regulator_get(&spi->dev, "dvdd");
> if (IS_ERR(st->dvdd)) {
> ret = PTR_ERR(st->dvdd);
> - goto error_disable_reg;
> + goto error_disable_avdd;
> }
>
> ret = regulator_enable(st->dvdd);
> if (ret) {
> dev_err(&spi->dev, "Failed to enable specified DVdd supply\n");
> - goto error_disable_reg;
> + goto error_disable_avdd;
> }
>
> - voltage_uv = regulator_get_voltage(st->reg);
> + voltage_uv = regulator_get_voltage(st->avdd);
>
> if (pdata->vref_mv)
> st->int_vref_mv = pdata->vref_mv;
> @@ -706,8 +706,8 @@ static int ad7192_probe(struct spi_device *spi)
> ad_sd_cleanup_buffer_and_trigger(indio_dev);
> error_disable_dvdd:
> regulator_disable(st->dvdd);
> -error_disable_reg:
> - regulator_disable(st->reg);
> +error_disable_avdd:
> + regulator_disable(st->avdd);
>
> return ret;
> }
> @@ -721,7 +721,7 @@ static int ad7192_remove(struct spi_device *spi)
> ad_sd_cleanup_buffer_and_trigger(indio_dev);
>
> regulator_disable(st->dvdd);
> - regulator_disable(st->reg);
> + regulator_disable(st->avdd);
>
> return 0;
> }
>
Re: [PATCH 5/6] staging: iio: ad9832: add DVDD regulator
On 31/10/16 17:04, Eva Rachel Retuya wrote:
> The AD9832/AD9835 is supplied with two power sources: AVDD as analog
> supply voltage and DVDD as digital supply voltage.
>
> Attempt to fetch and enable the regulator 'dvdd'. Bail out if any error
> occurs.
>
> Suggested-by: Lars-Peter Clausen
> Signed-off-by: Eva Rachel Retuya
Applied.
Thanks,
Jonathan
> ---
> drivers/staging/iio/frequency/ad9832.c | 33 -
> drivers/staging/iio/frequency/ad9832.h | 2 ++
> 2 files changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/iio/frequency/ad9832.c
> b/drivers/staging/iio/frequency/ad9832.c
> index 7d8dc6c..6a5ab02 100644
> --- a/drivers/staging/iio/frequency/ad9832.c
> +++ b/drivers/staging/iio/frequency/ad9832.c
> @@ -222,10 +222,22 @@ static int ad9832_probe(struct spi_device *spi)
> return ret;
> }
>
> + st->dvdd = devm_regulator_get(&spi->dev, "dvdd");
> + if (IS_ERR(st->dvdd)) {
> + ret = PTR_ERR(st->dvdd);
> + goto error_disable_reg;
> + }
> +
> + ret = regulator_enable(st->dvdd);
> + if (ret) {
> + dev_err(&spi->dev, "Failed to enable specified DVDD supply\n");
> + goto error_disable_reg;
> + }
> +
> indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
> if (!indio_dev) {
> ret = -ENOMEM;
> - goto error_disable_reg;
> + goto error_disable_dvdd;
> }
> spi_set_drvdata(spi, indio_dev);
> st = iio_priv(indio_dev);
> @@ -280,39 +292,41 @@ static int ad9832_probe(struct spi_device *spi)
> ret = spi_sync(st->spi, &st->msg);
> if (ret) {
> dev_err(&spi->dev, "device init failed\n");
> - goto error_disable_reg;
> + goto error_disable_dvdd;
> }
>
> ret = ad9832_write_frequency(st, AD9832_FREQ0HM, pdata->freq0);
> if (ret)
> - goto error_disable_reg;
> + goto error_disable_dvdd;
>
> ret = ad9832_write_frequency(st, AD9832_FREQ1HM, pdata->freq1);
> if (ret)
> - goto error_disable_reg;
> + goto error_disable_dvdd;
>
> ret = ad9832_write_phase(st, AD9832_PHASE0H, pdata->phase0);
> if (ret)
> - goto error_disable_reg;
> + goto error_disable_dvdd;
>
> ret = ad9832_write_phase(st, AD9832_PHASE1H, pdata->phase1);
> if (ret)
> - goto error_disable_reg;
> + goto error_disable_dvdd;
>
> ret = ad9832_write_phase(st, AD9832_PHASE2H, pdata->phase2);
> if (ret)
> - goto error_disable_reg;
> + goto error_disable_dvdd;
>
> ret = ad9832_write_phase(st, AD9832_PHASE3H, pdata->phase3);
> if (ret)
> - goto error_disable_reg;
> + goto error_disable_dvdd;
>
> ret = iio_device_register(indio_dev);
> if (ret)
> - goto error_disable_reg;
> + goto error_disable_dvdd;
>
> return 0;
>
> +error_disable_dvdd:
> + regulator_disable(st->dvdd);
> error_disable_reg:
> regulator_disable(reg);
>
> @@ -325,6 +339,7 @@ static int ad9832_remove(struct spi_device *spi)
> struct ad9832_state *st = iio_priv(indio_dev);
>
> iio_device_unregister(indio_dev);
> + regulator_disable(st->dvdd);
> regulator_disable(st->reg);
>
> return 0;
> diff --git a/drivers/staging/iio/frequency/ad9832.h
> b/drivers/staging/iio/frequency/ad9832.h
> index d32323b..eb0e7f2 100644
> --- a/drivers/staging/iio/frequency/ad9832.h
> +++ b/drivers/staging/iio/frequency/ad9832.h
> @@ -59,6 +59,7 @@
> * struct ad9832_state - driver instance specific data
> * @spi: spi_device
> * @reg: supply regulator
> + * @dvdd:supply regulator for the digital section
> * @mclk:external master clock
> * @ctrl_fp: cached frequency/phase control word
> * @ctrl_ss: cached sync/selsrc control word
> @@ -77,6 +78,7 @@
> struct ad9832_state {
> struct spi_device *spi;
> struct regulator*reg;
> + struct regulator*dvdd;
> unsigned long mclk;
> unsigned short ctrl_fp;
> unsigned short ctrl_ss;
>
Re: [PATCH 6/6] staging: iio: ad9832: clean-up regulator 'reg'
On 31/10/16 17:04, Eva Rachel Retuya wrote:
> Rename regulator 'reg' to 'avdd' so as to be clear what regulator it
> stands for specifically. Additionally, get rid of local variable 'reg'
> and use direct assignment instead. Update also the goto label pertaining
> to the avdd regulator during disable.
>
> Signed-off-by: Eva Rachel Retuya
Applied to the togreg branch of iio.git and shortly pushed out as
testing for the autobuilders to play with it.
A nice little series, thanks!
Jonathan
> ---
> drivers/staging/iio/frequency/ad9832.c | 20 +---
> drivers/staging/iio/frequency/ad9832.h | 4 ++--
> 2 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/iio/frequency/ad9832.c
> b/drivers/staging/iio/frequency/ad9832.c
> index 6a5ab02..639047f 100644
> --- a/drivers/staging/iio/frequency/ad9832.c
> +++ b/drivers/staging/iio/frequency/ad9832.c
> @@ -204,7 +204,6 @@ static int ad9832_probe(struct spi_device *spi)
> struct ad9832_platform_data *pdata = dev_get_platdata(&spi->dev);
> struct iio_dev *indio_dev;
> struct ad9832_state *st;
> - struct regulator *reg;
> int ret;
>
> if (!pdata) {
> @@ -212,11 +211,11 @@ static int ad9832_probe(struct spi_device *spi)
> return -ENODEV;
> }
>
> - reg = devm_regulator_get(&spi->dev, "avdd");
> - if (IS_ERR(reg))
> - return PTR_ERR(reg);
> + st->avdd = devm_regulator_get(&spi->dev, "avdd");
> + if (IS_ERR(st->avdd))
> + return PTR_ERR(st->avdd);
>
> - ret = regulator_enable(reg);
> + ret = regulator_enable(st->avdd);
> if (ret) {
> dev_err(&spi->dev, "Failed to enable specified AVDD supply\n");
> return ret;
> @@ -225,13 +224,13 @@ static int ad9832_probe(struct spi_device *spi)
> st->dvdd = devm_regulator_get(&spi->dev, "dvdd");
> if (IS_ERR(st->dvdd)) {
> ret = PTR_ERR(st->dvdd);
> - goto error_disable_reg;
> + goto error_disable_avdd;
> }
>
> ret = regulator_enable(st->dvdd);
> if (ret) {
> dev_err(&spi->dev, "Failed to enable specified DVDD supply\n");
> - goto error_disable_reg;
> + goto error_disable_avdd;
> }
>
> indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
> @@ -241,7 +240,6 @@ static int ad9832_probe(struct spi_device *spi)
> }
> spi_set_drvdata(spi, indio_dev);
> st = iio_priv(indio_dev);
> - st->reg = reg;
> st->mclk = pdata->mclk;
> st->spi = spi;
>
> @@ -327,8 +325,8 @@ static int ad9832_probe(struct spi_device *spi)
>
> error_disable_dvdd:
> regulator_disable(st->dvdd);
> -error_disable_reg:
> - regulator_disable(reg);
> +error_disable_avdd:
> + regulator_disable(st->avdd);
>
> return ret;
> }
> @@ -340,7 +338,7 @@ static int ad9832_remove(struct spi_device *spi)
>
> iio_device_unregister(indio_dev);
> regulator_disable(st->dvdd);
> - regulator_disable(st->reg);
> + regulator_disable(st->avdd);
>
> return 0;
> }
> diff --git a/drivers/staging/iio/frequency/ad9832.h
> b/drivers/staging/iio/frequency/ad9832.h
> index eb0e7f2..1b08b04 100644
> --- a/drivers/staging/iio/frequency/ad9832.h
> +++ b/drivers/staging/iio/frequency/ad9832.h
> @@ -58,7 +58,7 @@
> /**
> * struct ad9832_state - driver instance specific data
> * @spi: spi_device
> - * @reg: supply regulator
> + * @avdd:supply regulator for the analog section
> * @dvdd:supply regulator for the digital section
> * @mclk:external master clock
> * @ctrl_fp: cached frequency/phase control word
> @@ -77,7 +77,7 @@
>
> struct ad9832_state {
> struct spi_device *spi;
> - struct regulator*reg;
> + struct regulator*avdd;
> struct regulator*dvdd;
> unsigned long mclk;
> unsigned short ctrl_fp;
>
AMD error message at an Intel CPU system since 4.6.5
I do wonder about this new dmesg entry at a ThinkdPad T440s since 4.6.5: amd_nb: Cannot enumerate AMD northbridges -- Toralf PGP: C4EACDDE 0076E94E
Re: [PATCH v2] iio: adc: at91: add suspend and resume callback
On 03/11/16 14:16, Ludovic Desroches wrote:
> On Wed, Nov 02, 2016 at 05:21:48PM +0800, Wenyou Yang wrote:
>> Add suspend/resume callback, support the pinctrl sleep state when
>> the system suspend as well.
>>
>> Signed-off-by: Wenyou Yang
> Acked-by: Ludovic Desroches
Applied to the togreg branch of iio.git. Initially pushed out
as testing for the autobuilders to play with it.
Thanks,
Jonathan
>
> Thanks
>
>> ---
>>
>> Changes in v2:
>> - Use CONFIG_PM_SLEEP.
>> - Use SIMPLE_DEV_PM_OPS macro.
>>
>> drivers/iio/adc/at91_adc.c | 28
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>> index bbdac07..34b928c 100644
>> --- a/drivers/iio/adc/at91_adc.c
>> +++ b/drivers/iio/adc/at91_adc.c
>> @@ -30,6 +30,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /* Registers */
>> #define AT91_ADC_CR 0x00/* Control Register */
>> @@ -1347,6 +1348,32 @@ static int at91_adc_remove(struct platform_device
>> *pdev)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_PM_SLEEP
>> +static int at91_adc_suspend(struct device *dev)
>> +{
>> +struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
>> +struct at91_adc_state *st = iio_priv(idev);
>> +
>> +pinctrl_pm_select_sleep_state(dev);
>> +clk_disable_unprepare(st->clk);
>> +
>> +return 0;
>> +}
>> +
>> +static int at91_adc_resume(struct device *dev)
>> +{
>> +struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
>> +struct at91_adc_state *st = iio_priv(idev);
>> +
>> +clk_prepare_enable(st->clk);
>> +pinctrl_pm_select_default_state(dev);
>> +
>> +return 0;
>> +}
>> +#endif
>> +
>> +static SIMPLE_DEV_PM_OPS(at91_adc_pm_ops, at91_adc_suspend,
>> at91_adc_resume);
>> +
>> static struct at91_adc_caps at91sam9260_caps = {
>> .calc_startup_ticks = calc_startup_ticks_9260,
>> .num_channels = 4,
>> @@ -1441,6 +1468,7 @@ static struct platform_driver at91_adc_driver = {
>> .driver = {
>> .name = DRIVER_NAME,
>> .of_match_table = of_match_ptr(at91_adc_dt_ids),
>> + .pm = &at91_adc_pm_ops,
>> },
>> };
>>
>> --
>> 2.7.4
>>
Re: AMD error message at an Intel CPU system since 4.6.5
On Sat, Nov 05, 2016 at 05:26:22PM +0100, Toralf Förster wrote:
> I do wonder about this new dmesg entry at a ThinkdPad T440s since 4.6.5:
>
> amd_nb: Cannot enumerate AMD northbridges
Those are gone:
09c6c30e72ce ("x86/amd_nb: Clean up init path")
but you can disregard them - they're innocuous anyway.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] drm: move allocation out of drm_get_format_name()
On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
> Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
> > +typedef char drm_format_name_buf[32];
>
> Please don't use a typedef for this, just define the maximum size of
> characters the function might write somewhere.
>
> See the kernel coding style as well:
> > In general, a pointer, or a struct that has elements that can reasonably
> > be directly accessed should **never** be a typedef.
>
I would normally agree as I tend to hate typedefs ($DAYJOB {ab,mis}uses
them way too much), and your way was what I wrote at first, but Rob Clark's
typedef idea makes it much harder for someone to allocate a buffer of
the wrong size, which IMO is good thing here.
I can rewrite the typedef out if you think it's better.
Cheers,
Eric
Re: [PATCH] drm: move allocation out of drm_get_format_name()
On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom wrote:
> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
>> Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
>> > +typedef char drm_format_name_buf[32];
>>
>> Please don't use a typedef for this, just define the maximum size of
>> characters the function might write somewhere.
>>
>> See the kernel coding style as well:
>> > In general, a pointer, or a struct that has elements that can reasonably
>> > be directly accessed should **never** be a typedef.
>>
>
> I would normally agree as I tend to hate typedefs ($DAYJOB {ab,mis}uses
> them way too much), and your way was what I wrote at first, but Rob Clark's
> typedef idea makes it much harder for someone to allocate a buffer of
> the wrong size, which IMO is good thing here.
IMHO I would make a small test program to verify this actually helps
the compiler catch problems. And if it does, I would stick with it.
The coding-style should be guidelines, not something that supersedes
common sense / practicality.
That is my $0.02 anyways.. if others vehemently disagree and want to
dogmatically stick to the coding-style guidelines, ok then. OTOH, if
this approach doesn't help the compiler catch issues, then it isn't
worth it.
BR,
-R
> I can rewrite the typedef out if you think it's better.
>
> Cheers,
> Eric
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] HID: intel-ish-hid: initialize ts_format.reserved
On Sat, 2016-11-05 at 16:15 +0100, Jiri Kosina wrote: > From: Jiri Kosina > > ts_format.reserved is not used anywhere yet, but the compiler > generates a > warning when the struct's (uninitialized) field is being copied > around > > drivers/hid/intel-ish-hid/ipc/ipc.c: In function > ‘write_ipc_from_queue’: > drivers/hid/intel-ish-hid/ipc/ipc.c:316: warning: > ‘ts_format.reserved’ may be used uninitialized in this function > > Avoid this by force-initializing the field to zero. > > Signed-off-by: Jiri Kosina Acked-by: Srinivas Pandruvada > --- > drivers/hid/intel-ish-hid/ipc/ipc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel- > ish-hid/ipc/ipc.c > index 0c9ac4d..417cd07 100644 > --- a/drivers/hid/intel-ish-hid/ipc/ipc.c > +++ b/drivers/hid/intel-ish-hid/ipc/ipc.c > @@ -310,6 +310,7 @@ static int write_ipc_from_queue(struct > ishtp_device *dev) > ((uint32_t)tv_utc.tv_ > usec); > ts_format.ts1_source = HOST_SYSTEM_TIME_USEC; > ts_format.ts2_source = HOST_UTC_TIME_USEC; > + ts_format.reserved = 0; > > time_update.primary_host_time = usec_system; > time_update.secondary_host_time = usec_utc; > -- > 1.9.2 >
Re: [PATCH v3 2/4] drivers: iio: ti_am335x_adc: add dma support
On 05/10/16 10:26, Peter Ujfalusi wrote:
> On 10/05/16 12:04, Mugunthan V N wrote:
>> This patch adds the required pieces to ti_am335x_adc driver for
>> DMA support
>>
>> Signed-off-by: Mugunthan V N
Applied to a special branch in iio.git that I'll pull into togreg and then
push out as testing in a few minutes for the autobuilders to play with it.
(the special branch is incase Lee needs to later pull this into mfd as well).
Jonathan
>> ---
>> drivers/iio/adc/ti_am335x_adc.c | 148
>> ++-
>> include/linux/mfd/ti_am335x_tscadc.h | 7 ++
>> 2 files changed, 152 insertions(+), 3 deletions(-)
>
> Reviewed-by: Peter Ujfalusi
>
>>
>> diff --git a/drivers/iio/adc/ti_am335x_adc.c
>> b/drivers/iio/adc/ti_am335x_adc.c
>> index c3cfacca..ad9dec3 100644
>> --- a/drivers/iio/adc/ti_am335x_adc.c
>> +++ b/drivers/iio/adc/ti_am335x_adc.c
>> @@ -30,10 +30,28 @@
>> #include
>> #include
>>
>> +#include
>> +#include
>> +
>> +#define DMA_BUFFER_SIZE SZ_2K
>> +
>> +struct tiadc_dma {
>> +struct dma_slave_config conf;
>> +struct dma_chan *chan;
>> +dma_addr_t addr;
>> +dma_cookie_tcookie;
>> +u8 *buf;
>> +int current_period;
>> +int period_size;
>> +u8 fifo_thresh;
>> +};
>> +
>> struct tiadc_device {
>> struct ti_tscadc_dev *mfd_tscadc;
>> +struct tiadc_dma dma;
>> struct mutex fifo1_lock; /* to protect fifo access */
>> int channels;
>> +int total_ch_enabled;
>> u8 channel_line[8];
>> u8 channel_step[8];
>> int buffer_en_ch_steps;
>> @@ -198,6 +216,67 @@ static irqreturn_t tiadc_worker_h(int irq, void
>> *private)
>> return IRQ_HANDLED;
>> }
>>
>> +static void tiadc_dma_rx_complete(void *param)
>> +{
>> +struct iio_dev *indio_dev = param;
>> +struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> +struct tiadc_dma *dma = &adc_dev->dma;
>> +u8 *data;
>> +int i;
>> +
>> +data = dma->buf + dma->current_period * dma->period_size;
>> +dma->current_period = 1 - dma->current_period; /* swap the buffer ID */
>> +
>> +for (i = 0; i < dma->period_size; i += indio_dev->scan_bytes) {
>> +iio_push_to_buffers(indio_dev, data);
>> +data += indio_dev->scan_bytes;
>> +}
>> +}
>> +
>> +static int tiadc_start_dma(struct iio_dev *indio_dev)
>> +{
>> +struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> +struct tiadc_dma *dma = &adc_dev->dma;
>> +struct dma_async_tx_descriptor *desc;
>> +
>> +dma->current_period = 0; /* We start to fill period 0 */
>> +/*
>> + * Make the fifo thresh as the multiple of total number of
>> + * channels enabled, so make sure that cyclic DMA period
>> + * length is also a multiple of total number of channels
>> + * enabled. This ensures that no invalid data is reported
>> + * to the stack via iio_push_to_buffers().
>> + */
>> +dma->fifo_thresh = rounddown(FIFO1_THRESHOLD + 1,
>> + adc_dev->total_ch_enabled) - 1;
>> +/* Make sure that period length is multiple of fifo thresh level */
>> +dma->period_size = rounddown(DMA_BUFFER_SIZE / 2,
>> +(dma->fifo_thresh + 1) * sizeof(u16));
>> +
>> +dma->conf.src_maxburst = dma->fifo_thresh + 1;
>> +dmaengine_slave_config(dma->chan, &dma->conf);
>> +
>> +desc = dmaengine_prep_dma_cyclic(dma->chan, dma->addr,
>> + dma->period_size * 2,
>> + dma->period_size, DMA_DEV_TO_MEM,
>> + DMA_PREP_INTERRUPT);
>> +if (!desc)
>> +return -EBUSY;
>> +
>> +desc->callback = tiadc_dma_rx_complete;
>> +desc->callback_param = indio_dev;
>> +
>> +dma->cookie = dmaengine_submit(desc);
>> +
>> +dma_async_issue_pending(dma->chan);
>> +
>> +tiadc_writel(adc_dev, REG_FIFO1THR, dma->fifo_thresh);
>> +tiadc_writel(adc_dev, REG_DMA1REQ, dma->fifo_thresh);
>> +tiadc_writel(adc_dev, REG_DMAENABLE_SET, DMA_FIFO1);
>> +
>> +return 0;
>> +}
>> +
>> static int tiadc_buffer_preenable(struct iio_dev *indio_dev)
>> {
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> @@ -218,20 +297,30 @@ static int tiadc_buffer_preenable(struct iio_dev
>> *indio_dev)
>> static int tiadc_buffer_postenable(struct iio_dev *indio_dev)
>> {
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> +struct tiadc_dma *dma = &adc_dev->dma;
>> +unsigned int irq_enable;
>> unsigned int enb = 0;
>> u8 bit;
>>
>> tiadc_step_config(indio_dev);
>> -for_each_set_bit(bit, indio_dev->active_scan_mask, adc_dev->channels)
>> +for_each_set_bit(bit, indio_dev->active_scan_mask, adc_dev->channels) {
>> enb |= (get_adc_step_bit(adc_dev, bit) << 1);
>> +adc_dev->total_ch_enabled++
Re: [PATCH v3 3/4] ARM: dts: am33xx: add DMA properties for tscadc
On 05/10/16 10:04, Mugunthan V N wrote:
> Add DMA properties for tscadc
>
> Signed-off-by: Mugunthan V N
The support in the driver is now working it's way through iio.git towards
linux-next. I'm guessing this and the next patch will ultimately go through
arm-soc.
Shout if you'd rather I took them through the iio tree.
Thanks,
Jonathan
> ---
> arch/arm/boot/dts/am33xx.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 98748c6..6d607b8 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -917,6 +917,8 @@
> interrupts = <16>;
> ti,hwmods = "adc_tsc";
> status = "disabled";
> + dmas = <&edma 53 0>, <&edma 57 0>;
> + dma-names = "fifo0", "fifo1";
>
> tsc {
> compatible = "ti,am3359-tsc";
>
Re: [PATCH] power: supply: bq27xxx_battery: Fix register map for BQ27510 and BQ27520
On Friday 04 November 2016 19:33:13 Andrew F. Davis wrote:
> The BQ27510 and BQ27520 use a slightly different register map than
> the BQ27500, add a new type enum and add these gauges to it.
>
> Fixes: d74534c27775 ("power: bq27xxx_battery: Add support for
> additional bq27xxx family devices") Based-on-patch-by: Kenneth R.
> Crudup
> Signed-off-by: Andrew F. Davis
> ---
> drivers/power/supply/bq27xxx_battery.c | 41
> +-
> drivers/power/supply/bq27xxx_battery_i2c.c | 4 +--
> include/linux/power/bq27xxx_battery.h | 3 ++-
> 3 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c
> b/drivers/power/supply/bq27xxx_battery.c index 3b0dbc6..bccb3f5
> 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -164,6 +164,25 @@ static u8 bq27xxx_regs[][BQ27XXX_REG_MAX] = {
> [BQ27XXX_REG_DCAP] = 0x3c,
> [BQ27XXX_REG_AP] = INVALID_REG_ADDR,
> },
> + [BQ27510] = {
> + [BQ27XXX_REG_CTRL] = 0x00,
> + [BQ27XXX_REG_TEMP] = 0x06,
> + [BQ27XXX_REG_INT_TEMP] = 0x28,
> + [BQ27XXX_REG_VOLT] = 0x08,
> + [BQ27XXX_REG_AI] = 0x14,
> + [BQ27XXX_REG_FLAGS] = 0x0a,
> + [BQ27XXX_REG_TTE] = 0x16,
> + [BQ27XXX_REG_TTF] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_TTES] = 0x1a,
> + [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_NAC] = 0x0c,
> + [BQ27XXX_REG_FCC] = 0x12,
> + [BQ27XXX_REG_CYCT] = 0x1e,
> + [BQ27XXX_REG_AE] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_SOC] = 0x20,
> + [BQ27XXX_REG_DCAP] = 0x2e,
> + [BQ27XXX_REG_AP] = INVALID_REG_ADDR,
> + },
> [BQ27530] = {
> [BQ27XXX_REG_CTRL] = 0x00,
> [BQ27XXX_REG_TEMP] = 0x06,
> @@ -302,6 +321,24 @@ static enum power_supply_property
> bq27500_battery_props[] = { POWER_SUPPLY_PROP_MANUFACTURER,
> };
>
> +static enum power_supply_property bq27510_battery_props[] = {
> + POWER_SUPPLY_PROP_STATUS,
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_CURRENT_NOW,
> + POWER_SUPPLY_PROP_CAPACITY,
> + POWER_SUPPLY_PROP_CAPACITY_LEVEL,
> + POWER_SUPPLY_PROP_TEMP,
> + POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
> + POWER_SUPPLY_PROP_TECHNOLOGY,
> + POWER_SUPPLY_PROP_CHARGE_FULL,
> + POWER_SUPPLY_PROP_CHARGE_NOW,
> + POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
> + POWER_SUPPLY_PROP_CYCLE_COUNT,
> + POWER_SUPPLY_PROP_HEALTH,
> + POWER_SUPPLY_PROP_MANUFACTURER,
> +};
> +
> static enum power_supply_property bq27530_battery_props[] = {
> POWER_SUPPLY_PROP_STATUS,
> POWER_SUPPLY_PROP_PRESENT,
> @@ -385,6 +422,7 @@ static struct {
> BQ27XXX_PROP(BQ27000, bq27000_battery_props),
> BQ27XXX_PROP(BQ27010, bq27010_battery_props),
> BQ27XXX_PROP(BQ27500, bq27500_battery_props),
> + BQ27XXX_PROP(BQ27510, bq27510_battery_props),
> BQ27XXX_PROP(BQ27530, bq27530_battery_props),
> BQ27XXX_PROP(BQ27541, bq27541_battery_props),
> BQ27XXX_PROP(BQ27545, bq27545_battery_props),
> @@ -635,7 +673,8 @@ static int bq27xxx_battery_read_pwr_avg(struct
> bq27xxx_device_info *di) */
> static bool bq27xxx_battery_overtemp(struct bq27xxx_device_info *di,
> u16 flags) {
> - if (di->chip == BQ27500 || di->chip == BQ27541 || di->chip ==
> BQ27545) +if (di->chip == BQ27500 || di->chip == BQ27510 ||
> + di->chip == BQ27541 || di->chip == BQ27545)
> return flags & (BQ27XXX_FLAG_OTC | BQ27XXX_FLAG_OTD);
> if (di->chip == BQ27530 || di->chip == BQ27421)
> return flags & BQ27XXX_FLAG_OT;
This function should be converted to switch/case blocks... those
if/or/return conditions are now too big.
> diff --git a/drivers/power/supply/bq27xxx_battery_i2c.c
> b/drivers/power/supply/bq27xxx_battery_i2c.c index 85d4ea2..5c5c3a6
> 100644
> --- a/drivers/power/supply/bq27xxx_battery_i2c.c
> +++ b/drivers/power/supply/bq27xxx_battery_i2c.c
> @@ -149,8 +149,8 @@ static const struct i2c_device_id
> bq27xxx_i2c_id_table[] = { { "bq27200", BQ27000 },
> { "bq27210", BQ27010 },
> { "bq27500", BQ27500 },
> - { "bq27510", BQ27500 },
> - { "bq27520", BQ27500 },
> + { "bq27510", BQ27510 },
> + { "bq27520", BQ27510 },
> { "bq27530", BQ27530 },
> { "bq27531", BQ27530 },
> { "bq27541", BQ27541 },
> diff --git a/include/linux/power/bq27xxx_battery.h
> b/include/linux/power/bq27xxx_battery.h index e30deb0..bed9557
> 100644
> --- a/include/linux/power/bq27xxx_battery.h
> +++ b/include/linux/power/bq27xxx_battery.h
> @@ -4,7 +4,8 @@
> enum bq27xxx_chip {
> BQ27000 = 1, /* bq27000, bq27200 */
> BQ27010, /* bq27010, bq27210 */
> - BQ27500, /* bq27500, bq27510, bq27520 */
> + BQ27500, /* bq27500 */
> + BQ
Re: [GIT PULL] overlayfs fixes for 4.9-rc3
On Fri, Nov 4, 2016 at 11:44 PM, Amir Goldstein wrote: > > Can you please clarify your objection? There are several: - timing. No way in hell will I take a new feature like this during an rc - lack of explanation. Why is this bad feature needed in the first place? Why would overlayfs versioning _ever_ be a good idea? - is the implementation even sane? Right now I don't think overlayfs even requires xattr support in the upper filesystem, so the whole concept seems frankly totally misdesigned. > I suppose you do not object to the concept of on-disk format version nor > on-disk > format compatible/incompatible features sets. I object both to the concept and to the implementation and to the timing. The thing seems broken. Doing it during the rc cycle makes it doubly so. > Just to fact that overlayfs didn't have those form day one, so it > should find a way to cope with that situation without patching > stable kernels? What "situation"? There's no f*cking explanation of why we'd even want this crap. Not in the commit message, not in the pull request, not *anywhere*. And then the commit marks that shit for stable? When it clearly doesn't fix anything, and it has never ever been needed before? NO. Linus
Re: [PATCH 1/4] mfd: ti_am335x_tscadc: store physical address
On 31/10/16 08:16, Lee Jones wrote:
> On Sun, 30 Oct 2016, Jonathan Cameron wrote:
>
>> On 26/10/16 13:17, Lee Jones wrote:
>>> On Fri, 30 Sep 2016, Mugunthan V N wrote:
>>>
On Wednesday 28 September 2016 01:10 AM, Lee Jones wrote:
> On Wed, 21 Sep 2016, Mugunthan V N wrote:
>
>> store the physical address of the device in its priv to use it
>> for DMA addressing in the client drivers.
>>
>> Signed-off-by: Mugunthan V N
>> ---
>> drivers/mfd/ti_am335x_tscadc.c | 1 +
>> include/linux/mfd/ti_am335x_tscadc.h | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/drivers/mfd/ti_am335x_tscadc.c
>> b/drivers/mfd/ti_am335x_tscadc.c
>> index c8f027b..0f3fab4 100644
>> --- a/drivers/mfd/ti_am335x_tscadc.c
>> +++ b/drivers/mfd/ti_am335x_tscadc.c
>> @@ -183,6 +183,7 @@ static int ti_tscadc_probe(struct
>> platform_device *pdev)
>> tscadc->irq = err;
>>
>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +tscadc->tscadc_phys_base = res->start;
>
> This is unusual. Can't you use a virt_to_phys() variant instead?
>
I tried using virt_to_phys(), but its not working for me.
Also saw many drivers uses like this to get physical address
("git grep -n " res->start;" drivers/*").
>>>
>>> Very well:
>>>
>>> For my own reference:
>>> Acked-for-MFD-by: Lee Jones
>>>
>>> Let me know how you wish this set to be handled.
>> I'm happy to pick up the whole series. There are some more mfd
>> header changes in patch 2 but as they only add defines, I
>> don't mind that much if I don't an Ack from you on those
>> (btw this got to V3 but as patch 1 didn't change I'll carry
>> your ack forwards).
>>
>> Do you want an immutable branch? Seems unlikely to cause
>> much trouble even if there is a merge issue on all 10ish
>> lines of mfd code in the next merge window.
>
> Not at the moment, but if you could set things up so it's possible to
> create one at a later date if things go Pete Tong, that would be
> great.
Couldn't think of an easy way to do this without creating a branch
and merging it into my normal branch. I'll not push it out to
kernel.org though unless you tell me you need it.
Applied to the togreg branch (indirectly ;) of iio.git pushed out
as testing for the autobuilders to play with it.
Thanks,
Jonathan
>
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat, 05 Nov 2016, Pavel Machek wrote: > Hmm, thanks for the pointer. But it seems like I'll have to build my > own, as /proc/acpi/ibm does not follow the usual infrastructure... /proc/acpi/ibm has been deprecated for years. 99% of the functionality is available through more modern, standard interfaces. thinkpad-acpi is supposed to export standard hwmon temperature sensors as well. Try them instead, please. Also, thinkpad-acpi will report the EC thermal sensors. They don't need to (and most often won't) match whatever you read from the processor core(s). -- Henrique Holschuh
Re: [RFC 0/8] Define coherent device memory node
On Sat, Nov 05, 2016 at 10:51:21AM +0530, Anshuman Khandual wrote: > On 10/25/2016 09:56 AM, Aneesh Kumar K.V wrote: > > I looked at the hmm-v13 w.r.t migration and I guess some form of device > > callback/acceleration during migration is something we should definitely > > have. I still haven't figured out how non addressable and coherent device > > memory can fit together there. I was waiting for the page cache > > migration support to be pushed to the repository before I start looking > > at this closely. > > Aneesh, did not get that. Currently basic page cache migration is supported, > right ? The device callback during migration, fault etc are supported through > page->pgmap pointer and extending dev_pagemap structure to accommodate new > members. IIUC that is the reason ZONE_DEVICE is being modified so that page > ->pgmap overloading can be used for various driver/device specific callbacks > while inside core VM functions or HMM functions. > > HMM V13 has introduced non-addressable ZONE_DEVICE based device memory which > can have it's struct pages in system RAM but they cannot be accessed from the > CPU. Now coherent device memory is kind of similar to persistent memory like > NVDIMM which is already supported through ZONE_DEVICE (though we might not > want to use vmemap_altmap instead have the struct pages in the system RAM). > Now HMM has to learn working with 'dev_pagemap->addressable' type of device > memory and then support all possible migrations through it's API. So in a > nutshell, these are the changes we need to do to make HMM work with coherent > device memory. > > (0) Support all possible migrations between system RAM and device memory > for current un-addressable device memory and make the HMM migration > API layer comprehensive and complete. What is no comprehensive or complete in the API layer ? I think the API is pretty clear the migrate function does not rely on anything except HMM pfn. > > (1) Create coherent device memory representation in ZONE_DEVICE > (a) Make it exactly the same as that of persistent memory/NVDIMM > > or > > (b) Create a new type for coherent device memory representation So i will soon push an updated tree with modification to HMM API (from device driver point of view but the migrate stuff is virtually the same). I slpitted the addressable and movable concept and thus it is now easy to support coherent addressable memory and non addressable memory. > > (2) Support all possible migrations between system RAM and device memory > for new addressable coherent device memory represented in ZONE_DEVICE > extending the HMM migration API layer. > > Right now, HMM V13 patch series supports migration for a subset of private > anonymous pages for un-addressable device memory. I am wondering how difficult > is it to implement all possible anon, file mapping migration support for both > un-addressable and addressable coherent device memory through ZONE_DEVICE. > There is no need to extend the API to support file back as matter of fact the 2 patches i sent you do support migration of file back page (page->mapping) to and from ZONE_DEVICE as long as this ZONE_DEVICE memory is accessible by the CPU and coherent. What i am still working on is the non addressable case that is way more tedious (handle direct IO, read, write and writeback). So difficulty for coherent memory is nill, it is the non addressable memory that is hard to support in respect to file back page. Cheers, Jérôme
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat, 05 Nov 2016, Pavel Machek wrote: > [ 825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something > is extremely hot! > [ 825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/A 78 33 N/A 33 > N/A 47 50 N/A N/A N/A N/A N/A N/A Oh boy, that must be the second time in a decade that I see that codepath triggering. It is the second-level alert that the ThinkPad is about to catch fire. It should have logged a "is too hot!" first-level alert earlier, but this depends on the EC and not the driver. Maybe the temperature raised too fast. In Windows, the system would attempt to hibernate or shutdown. I would be quite happy to have thinkpad-acpi trigger such behavior as well, patches (or guidance) are welcome ;-) Anyway, if that temperature goes about 1~2°C higher, the EC should cut power to your motherboard. Apparently, the built-in thermal protection clock modulation on the Intel processor is somehow saving your box from that forced power-off. -- Henrique Holschuh
[git pull] Input updates for 4.9-rc3
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Changelog: - Dmitry Tunin (1): Input: psmouse - cleanup Focaltech code Patrick Scheuring (1): Input: i8042 - add XMG C504 to keyboard reset table Diffstat: drivers/input/mouse/focaltech.c | 6 +++--- drivers/input/serio/i8042-x86ia64io.h | 7 +++ 2 files changed, 10 insertions(+), 3 deletions(-) -- Dmitry
Re: [PATCH 1/1] watchdog: pcipcwd_show_card_info: wrong format string
On 11/05/2016 04:29 PM, Guenter Roeck wrote: > On 11/05/2016 07:50 AM, Heinrich Schuchardt wrote: >> fw_rev_major and fw_rev_minor are defined as int. >> Use %d to print them. >> >> Signed-off-by: Heinrich Schuchardt >> --- >> drivers/watchdog/pcwd_pci.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/watchdog/pcwd_pci.c b/drivers/watchdog/pcwd_pci.c >> index c0d07ee..e1fbbf6 100644 >> --- a/drivers/watchdog/pcwd_pci.c >> +++ b/drivers/watchdog/pcwd_pci.c >> @@ -234,7 +234,7 @@ static void pcipcwd_show_card_info(void) >> got_fw_rev = send_command(CMD_GET_FIRMWARE_VERSION, &fw_rev_major, >> &fw_rev_minor); >> if (got_fw_rev) >> -sprintf(fw_ver_str, "%u.%02u", fw_rev_major, fw_rev_minor); >> +sprintf(fw_ver_str, "%d.%02d", fw_rev_major, fw_rev_minor); >> else >> sprintf(fw_ver_str, ""); >> >> > Hmm ... I don't think that a negative version number makes much sense. > Turns out inb() returns a char on some architectures, meaning it is signed, > meaning it _could_ return a negative number if the version number is 128 > or above. I don't want to risk us reporting version number -128.-110 just > to make compilers happy. send_command uses inb_p to read single bytes. The signature of inb_p is u8 inb_p(unsigned long addr) So fw_rev_major and fw_rev_minor should always be in the range of 0..255. Regards Heinrich
Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Fri, 04 Nov 2016, Viresh Kumar wrote: > On 04-11-16, 10:26, Pavel Machek wrote: > > How would I know if it is thermal capping? There's nothing in dmesg. > > I am not sure what code is responsible for doing that in case of x86, maybe > Rafael and Rui can explain it that better. > > But surely it involves userspace in this case as scaling_max_freq is getting > changed. Note that a X60 might limit the maximum frequency through ACPI when on AC *and* its battery is not installed or not in working order. The EC tries to detect the power brick type (65W, 90W), which often doesn't work well on non-Lenovo power bricks, and signals the BIOS to limit the maximum frequency if it thinks its only power source is a 65W power brick. This behavior would be readly visible by the X60 refusing to reach the maximum clock frequency *at all* -- it is a static limit, only removed when a sufficiently charged battery becomes available. This indirect power draw capping should never engage if your battery is installed and working, regardless of type and brand of power adapter, AFAIK. I am only mentioning it so that you are aware of this possible behavior while debugging. Anyway, this overheating thinkpad very, very likely needs a hardware repair (on top of the kernel bug fixes ;-) ). Regardless of any kernel/userspace bugs, the X60 was engineered to not require thermal capping on reasonable indoor environmental temperature ranges. If it needs the kernel to do something at all to avoid overheating just because it has been running at full CPU power, and ambient temperature is below 28°C, it very likely has a hardware issue (lint on the heatsink/fan, and/or cracked thermal interface between heatsink and processor). Every old-style ThinkPad (like the X60) that I have ever seen overheating when running at full CPU power (after fan lint was removed) in a cool place (say, 26°C), stopped overheating after a heatsink reseat and thermal compound replacement (and if you're going to do it, use non-shelf-aged Arctic Silver 5 or something better, and "cure" it properly -- something rather easy to do on a ThinkPad X60). -- Henrique Holschuh
Re: [PATCH v2] platform/x86/asus-nb-wmi.c: Add X45U quirk
On Mon, Oct 31, 2016 at 11:56:10PM -0200, Marcos Paulo de Souza wrote: > Without this patch, the Asus X45U wireless card can't be turned > on (hard-blocked), but after a suspend/resume it just starts working. > > Following this bug report[1], there are other cases like this one, but > this Asus is the only model that I can test. > > [1] https://ubuntuforums.org/showthread.php?t=2181558 > > Signed-off-by: Marcos Paulo de Souza > Cc: > > --- > This patch applies smoothly in 4.8.6 and 4.4.29. I hope now I followed > the instructions correctly. Hi Marcos, You'll find exact steps in the stable_kernel_rules.txt document regarding how to annotate the commit message with Cc lines indicating to which versions this patch should be applied. If, for example, you have verified that this patch is relevant only to 4.4 and forward, you would include: Cc: # 4.4.x- But this should mean that the patch is explicitly broken or otherwise inappropriate for 4.3 and earlier. Thanks, -- Darren Hart Intel Open Source Technology Center
Re: [PATCH] acer-wmi: only supports AMW0_GUID1 on acer family
On Thu, Nov 03, 2016 at 11:40:15AM +0800, Anthony Wong wrote: > On 1 November 2016 at 12:30, Lee, Chun-Yi wrote: > > > > The AMW0_GUID1 wmi is not only found on Acer family but also other > > machines like Lenovo, Fujitsu and Medion. In the past days, acer-wmi > > driver handled those non-Acer machines by quirks list. > > > > But actually acer-wmi driver was loaded on any machines that have > > AMW0_GUID1. This behavior is strange because those machines should > > be supported by appropriate wmi drivers. e.g. fujitsu-laptop, > > ideapad-laptop. > > > > So, This patch adds the logic to check the machine that has AMW0_GUID1 > > should be in Acer/Packard Bell/Gateway white list. But, it still keeps > > the quirk list of those supported non-acer machines for backward > > compatible. > > > > Tested-by: Bjørn Mork > > Cc: Darren Hart > > Signed-off-by: Lee, Chun-Yi > > Xiaomi Air 13.3 notebook suffers from the same issue, acer-wmi > basically has no use on this machine. With your patch, acer-wmi no > longer loads. > > Tested-by: Anthony Wong I've already pushed this to -next, but thank you for the confirmation. -- Darren Hart Intel Open Source Technology Center
