[git pull] drm fixes
Hi Linus, last fixes from me, one amdgpu/radeon suspend resume and one leak fix, along with one vmware fix for some issues when command submission fails. Dave. The following changes since commit 018155365dccecd9ea9f26e1b26fb0f960c1ee32: Merge tag 'usb-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb (2015-10-24 07:52:59 +0900) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 22ca7ca52e80524360b43944a0556b2a6dc1aa21: Merge branch 'vmwgfx-fixes-4.3' of git://people.freedesktop.org/~thomash/linux (2015-10-25 05:02:33 +1000) Alex Deucher (2): drm/radeon: don't try to recreate sysfs entries on resume drm/amdgpu: don't try to recreate sysfs entries on resume Christian König (1): drm/amdgpu: stop leaking page flip fence Dave Airlie (2): Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux Merge branch 'vmwgfx-fixes-4.3' of git://people.freedesktop.org/~thomash/linux Thomas Hellstrom (1): drm/vmwgfx: Stabilize the command buffer submission code drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 5 + drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_pm.c | 35 + drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 34 6 files changed, 48 insertions(+), 32 deletions(-)
linux 4.2.4 rcu_sched rolls over and barfs after debugger exits
After using the mdb kernel debugger then exiting, the rcu_sched, due to its own internal timers, rolls over and crashes when it does not get the timeout window it likes.Not caused by memory corruption, just caused by the debugger holding the system suspended then when the system is allowed to run rcu_sched rolls over and dies. There are several things happening here -- lots of bugs linus ... Jeff sysrq: SysRq : MDB INFO: rcu_sched detected stalls on CPUs/tasks: (detected by 0, t=41279 jiffies, g=14721, c=14720, q=5) All QSes seen, last rcu_sched kthread activity 41279 (-165477--206756), jiffies_till_next_fqs=3, root ->qsmask 0x0 NetworkManager R running 0 1703 1 0x0080 c0bb6a28 c046d763 c0a895d9 06a7 0001 0080 f64c1140 c0b535c0 3981 c04a5126 c0a823a8 c0b53a91 a13f fffd799b fffcd85c 0003 0096 3981 3b9aca00 3981 3980 Call Trace: [] ? sched_show_task+0xb3/0x120 [] ? print_other_cpu_stall+0x276/0x2c0 [] ? __rcu_pending+0x170/0x210 [] ? rcu_check_callbacks+0xbf/0x1a0 [] ? update_process_times+0x28/0x50 [] ? tick_sched_handle+0x33/0x70 [] ? tick_sched_timer+0x47/0xa0 [] ? __remove_hrtimer+0x4a/0x90 [] ? __run_hrtimer+0x66/0x180 [] ? tick_nohz_handler+0xd0/0xd0 [] ? __vfs_read+0xc5/0xf0 [] ? __hrtimer_run_queues+0x88/0xc0 [] ? hrtimer_interrupt+0x85/0x170 [] ? local_apic_timer_interrupt+0x26/0x50 [] ? irq_enter+0x5/0x50 [] ? smp_apic_timer_interrupt+0x2b/0x50 [] ? apic_timer_interrupt+0x2d/0x34 [] ? firmware_map_add_hotplug+0x45/0x141 rcu_sched kthread starved for 41279 jiffies! g14721 c14720 f0x2 fuse init (API version 7.23) blk_update_request: I/O error, dev fd0, sector 0 floppy: error -5 while reading block 0 blk_update_request: I/O error, dev fd0, sector 0 floppy: error -5 while reading block 0 sysrq: SysRq : MDB INFO: rcu_sched detected stalls on CPUs/tasks: (detected by 0, t=21939 jiffies, g=17972, c=17971, q=3) All QSes seen, last rcu_sched kthread activity 21939 (-124010--145949), jiffies_till_next_fqs=3, root ->qsmask 0x0 rtkit-daemonR running 0 2878 1 0x0080 c0bb6a28 c046d763 c0a895d9 0b3e 0001 0080 f64c1140 c0b535c0 4634 c04a5126 c0a823a8 c0b53a91 55b3 fffe1b96 fffdc5e3 0003 0086 4634 f69ec5cc 4634 4633 Call Trace: [] ? sched_show_task+0xb3/0x120 [] ? print_other_cpu_stall+0x276/0x2c0 [] ? __rcu_pending+0x170/0x210 [] ? rcu_check_callbacks+0xbf/0x1a0 [] ? update_process_times+0x28/0x50 [] ? tick_sched_handle+0x33/0x70 [] ? tick_sched_timer+0x47/0xa0 [] ? __remove_hrtimer+0x4a/0x90 [] ? __run_hrtimer+0x66/0x180 [] ? tick_nohz_handler+0xd0/0xd0 [] ? __kmalloc_reserve+0x29/0x80 [] ? __hrtimer_run_queues+0x88/0xc0 [] ? hrtimer_interrupt+0x85/0x170 [] ? __wake_up_common+0x47/0x70 [] ? local_apic_timer_interrupt+0x26/0x50 [] ? irq_enter+0x5/0x50 [] ? smp_apic_timer_interrupt+0x2b/0x50 [] ? apic_timer_interrupt+0x2d/0x34 [] ? legitimize_path+0x50/0x50 [] ? lookup_fast+0x155/0x2d0 [] ? generic_permission+0xcd/0x100 [] ? walk_component+0x3a/0x1f0 [] ? SYSC_sendto+0x125/0x150 [] ? path_lookupat+0x56/0xf0 [] ? filename_lookup+0x8b/0x150 [] ? nl80211_send_bss.clone.4+0xe2/0x490 [cfg80211] [] ? getname_flags+0x3e/0x1b0 [] ? getname_flags+0x5d/0x1b0 [] ? vfs_fstatat+0x4e/0xa0 [] ? vfs_stat+0x18/0x20 [] ? SyS_stat64+0x1a/0x40 [] ? SyS_socketcall+0x235/0x300 [] ? __audit_syscall_entry+0x9c/0x100 [] ? sysenter_do_call+0x12/0x12 rcu_sched kthread starved for 21939 jiffies! g17972 c17971 f0x2 [root@aya ~]# -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] staging: wilc1000: return -ENOMEM when kmalloc failed
The driver is using -1 instead of the -ENOMEM defined macro to specify that
a buffer allocation failed.
Fixes smatch warning and similars:
drivers/staging/wilc1000/host_interface.c:1757 Handle_Key() warn:
returning -1 instead of -ENOMEM is sloppy
Signed-off-by: Luis de Bethencourt
---
Hi,
Resending because previous version didn't apply against staging-next due to the
recent changes on this file. Refreshed.
Thanks,
Luis
drivers/staging/wilc1000/host_interface.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 5f81eab..064e34c 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1754,7 +1754,7 @@ static int Handle_Key(struct host_if_drv *hif_drv,
if (pu8keybuf == NULL) {
PRINT_ER("No buffer to send Key\n");
- return -1;
+ return -ENOMEM;
}
kfree(pstrHostIFkeyAttr->attr.wep.key);
@@ -1776,7 +1776,7 @@ static int Handle_Key(struct host_if_drv *hif_drv,
pu8keybuf = kmalloc(pstrHostIFkeyAttr->attr.wep.key_len
+ 2, GFP_KERNEL);
if (!pu8keybuf) {
PRINT_ER("No buffer to send Key\n");
- return -1;
+ return -ENOMEM;
}
pu8keybuf[0] = pstrHostIFkeyAttr->attr.wep.index;
memcpy(pu8keybuf + 1,
>attr.wep.key_len, 1);
@@ -1823,7 +1823,7 @@ static int Handle_Key(struct host_if_drv *hif_drv,
pu8keybuf = kzalloc(RX_MIC_KEY_MSG_LEN, GFP_KERNEL);
if (!pu8keybuf) {
PRINT_ER("No buffer to send RxGTK Key\n");
- ret = -1;
+ ret = -ENOMEM;
goto _WPARxGtk_end_case_;
}
@@ -1858,7 +1858,7 @@ static int Handle_Key(struct host_if_drv *hif_drv,
pu8keybuf = kzalloc(RX_MIC_KEY_MSG_LEN, GFP_KERNEL);
if (pu8keybuf == NULL) {
PRINT_ER("No buffer to send RxGTK Key\n");
- ret = -1;
+ ret = -ENOMEM;
goto _WPARxGtk_end_case_;
}
@@ -1887,7 +1887,7 @@ static int Handle_Key(struct host_if_drv *hif_drv,
_WPARxGtk_end_case_:
kfree(pstrHostIFkeyAttr->attr.wpa.key);
kfree(pstrHostIFkeyAttr->attr.wpa.seq);
- if (ret == -1)
+ if (ret)
return ret;
break;
@@ -1899,7 +1899,7 @@ _WPARxGtk_end_case_:
pu8keybuf = kmalloc(PTK_KEY_MSG_LEN + 1, GFP_KERNEL);
if (!pu8keybuf) {
PRINT_ER("No buffer to send PTK Key\n");
- ret = -1;
+ ret = -ENOMEM;
goto _WPAPtk_end_case_;
}
@@ -1931,7 +1931,7 @@ _WPARxGtk_end_case_:
pu8keybuf = kmalloc(PTK_KEY_MSG_LEN, GFP_KERNEL);
if (!pu8keybuf) {
PRINT_ER("No buffer to send PTK Key\n");
- ret = -1;
+ ret = -ENOMEM;
goto _WPAPtk_end_case_;
}
@@ -1954,7 +1954,7 @@ _WPARxGtk_end_case_:
_WPAPtk_end_case_:
kfree(pstrHostIFkeyAttr->attr.wpa.key);
- if (ret == -1)
+ if (ret)
return ret;
break;
@@ -1967,7 +1967,7 @@ _WPAPtk_end_case_:
pu8keybuf = kmalloc((pstrHostIFkeyAttr->attr.pmkid.numpmkid *
PMKSA_KEY_LEN) + 1, GFP_KERNEL);
if (!pu8keybuf) {
PRINT_ER("No buffer to send PMKSA Key\n");
- return -1;
+ return -ENOMEM;
}
pu8keybuf[0] = pstrHostIFkeyAttr->attr.pmkid.numpmkid;
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] w1: w1_process() is not freezable kthread
From: Jiri Kosina w1_process() calls try_to_freeze(), but the thread doesn't mark itself freezable through set_freezable(), so the try_to_freeze() call is useless. Signed-off-by: Jiri Kosina --- drivers/w1/w1.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index c9a7ff6..89a7847 100644 --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -1147,7 +1147,6 @@ int w1_process(void *data) jremain = 1; } - try_to_freeze(); __set_current_state(TASK_INTERRUPTIBLE); /* hold list_mutex until after interruptible to prevent loosing -- 2.1.2 -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC
On 2015年10月24日 02:36, Alexander Duyck wrote: > I was thinking about it and I am pretty sure the dummy write approach is > problematic at best. Specifically the issue is that while you are > performing a dummy write you risk pulling in descriptors for data that > hasn't been dummy written to yet. So when you resume and restore your > descriptors you will have once that may contain Rx descriptors > indicating they contain data when after the migration they don't. How about changing sequence? dummy writing Rx packet data fist and then its desc. This can ensure that RX data is migrated before its desc and prevent such case. -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] xen-blkback: clear PF_NOFREEZE for xen_blkif_schedule()
From: Jiri Kosina
xen_blkif_schedule() kthread calls try_to_freeze() at the beginning of
every attempt to purge the LRU. This operation can't ever succeed though,
as the kthread hasn't marked itself as freezable.
Before (hopefully eventually) kthread freezing gets converted to fileystem
freezing, we'd rather mark xen_blkif_schedule() freezable (as it can
generate I/O during suspend).
Signed-off-by: Jiri Kosina
---
drivers/block/xen-blkback/blkback.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index af3caa3..bb65f7c 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -597,6 +597,7 @@ int xen_blkif_schedule(void *arg)
xen_blkif_get(blkif);
+ set_freezable();
while (!kthread_should_stop()) {
if (unlikely(vbd->size != vbd_sz(vbd)))
xen_vbd_resize(blkif);
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] keys, trusted: select TPM2 hash algorithm
On Sun, Oct 25, 2015 at 03:21:31PM -0400, Mimi Zohar wrote: > On Sat, 2015-10-24 at 15:42 +0300, Jarkko Sakkinen wrote: > > Added 'hashalg=' option for selecting the hash algorithm. > > > > Currently available options are: > > > > * sha1 > > * sha256 > > * sha384 > > * sha512 > > * sm3_256 > > Please consider using crypto/hash_info.c: hash_algo_name[], which > already define the algorithm string names. Use > include/crypto/hash_info.c to include a reference to this array. It wold work for me. I did ad-hoc because first example that I looked at was EcryptFS. I need to add sm3_256 to that array. I've found three different ways to write it: * sm3256 (various google hits) * sm3-256 (various google hits) * sm3_256 (TPM 2.0 Structures specification) Maybe the second option would be the most appropriate? > Boot command line options should be prefixed with the subsystem name. > So instead of hashalg, please use tpm_hashalg. The boot command line > option needs to be documented in Documentation/kernel-parameters.txt. I see. My commit message is clearly inadequate. It's an option for the keyring syscalls. > Mimi /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] GHES: Fix cached error-status
Borislav Petkov writes: > On Mon, Oct 26, 2015 at 11:20:35AM +0800, Huang, Ying wrote: >> In ghes_estatus_caches[], for caches with same contents, the cache with >> biggest (newest) cache->time_in should be the first. So if we found one >> cache with too small (old) cache->time_in, we can say there are no cache >> with same contents and bigger (newer) cache->time_in, so that we can >> make decision (break) earlier. > > Well, for starters, this should be documented in the code so that people > looking at it would not need to scratch their heads over that break > statement there. Yes. Will do it. Best Regards, Huang, Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm64: dts: spi bus dts support multiple devices
Hi Sascha,
On Wed, 2015-10-14 at 07:58 +0200, Sascha Hauer wrote:
> On Wed, Oct 14, 2015 at 11:23:35AM +0800, Leilk Liu wrote:
> > This patch support multiple devices for MT8173.
>
> The subject of this patch and also the above sentence should contain the
> board name this patch is changing so that the reader knows this is about
> a single board, and not arm64 in general.
>
OK, I'll fix it.
> Sascha
>
> >
> > Signed-off-by: Leilk Liu
> > ---
> > arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > index 04b38ed..1c8c407 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > @@ -194,7 +194,7 @@
> > pinmux = ,
> > ,
> > ,
> > - ;
> > + ;
> > };
> > };
> > };
> > @@ -399,6 +399,7 @@
> > {
> > pinctrl-names = "default";
> > pinctrl-0 = <_pins_a>;
> > + cs-gpios = < 72 0>;
> > mediatek,pad-select = <0>;
> > status = "okay";
> > };
> > --
> > 1.8.1.1.dirty
> >
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] mt8173 spi multiple devices support
Hi Mark, On Mon, 2015-10-19 at 20:27 +0100, Mark Brown wrote: > On Wed, Oct 14, 2015 at 11:23:30AM +0800, Leilk Liu wrote: > > This series are based on 4.3-rc1 and provide 5 patches to support > > mt8173 spi multiple devices. > > This doesn't apply against current code, please check and resend. Also > note that it looks like you've got the execute bit set on some of the > files. The code itself looks fine. OK, I will fix it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/6] iommu/mediatek: Add mt8173 IOMMU driver
On Wed, 2015-10-14 at 14:53 +0200, Joerg Roedel wrote:
> On Fri, Oct 09, 2015 at 10:23:07AM +0800, Yong Wu wrote:
> > + /*
> > +* There is a domain for each a iommu device in normal case.
> > +* But MTK only has one iommu domain called the m4u domain which all
> > +* the multimedia HW share. Here we reserve one as the m4u domain and
> > +* free the others.
> > +*
> > +* And the attach_device that from __iommu_setup_dma_ops
> > +* will be called earlier than probe.
> > +*/
>
> Okay, with this being the case, you need to put all devices behind one
> IOMMU into the same iommu-group, because the IOMMU can't really isolate
> the devices from each other.
>
> > +static int mtk_iommu_add_device(struct device *dev)
> > +{
> > + struct iommu_group *group;
> > + struct mtk_iommu_client_priv *priv;
> > + struct mtk_iommu_domain *m4udom;
> > + struct iommu_domain *domain;
> > + int ret;
> > +
> > + if (!dev->archdata.iommu) /* Not a iommu client device */
> > + return -ENODEV;
> > +
> > + group = iommu_group_get(dev);
> > + if (!group) {
> > + group = iommu_group_alloc();
> > + if (IS_ERR(group)) {
> > + dev_err(dev, "Failed to allocate IOMMU group\n");
> > + return PTR_ERR(group);
> > + }
> > + }
> > +
> > + ret = iommu_group_add_device(group, dev);
> > + if (ret) {
> > + dev_err(dev, "Failed to add IOMMU group\n");
> > + goto err_group_put;
> > + }
> > +
> > + domain = iommu_get_domain_for_dev(dev);
> > + if (!domain) {
> > + /*
> > +* Get the m4u iommu domain from the m4u device.
> > +* Attach all the client devices into the m4u domain.
> > +*/
> > + priv = dev->archdata.iommu;
> > + m4udom = dev_get_drvdata(priv->m4udev);
> > + ret = iommu_attach_group(>domain, group);
> > + if (ret)
> > + dev_err(dev, "Failed to attach IOMMU group\n");
> > + }
> > +
> > +err_group_put:
> > + iommu_group_put(group);
> > + return ret;
> > +}
>
> Here it looks like you are allocating one group for each device. As I
> said, all devices need to be in one group.
>
> Joerg
>
Thanks for this suggestion. I have put all the iommu client devices into
the same iommu group, the code looks like below.
And I will send this in the next version after the Short descriptor is
reviewed.
static int mtk_iommu_add_device(struct device *dev)
{
struct iommu_group *group;
struct mtk_iommu_client_priv *priv;
struct mtk_iommu_domain *m4udom;
struct iommu_domain *domain;
int ret;
priv = dev->archdata.iommu;
if (!priv) /* Not a iommu client device */
return -ENODEV;
m4udom = dev_get_drvdata(priv->m4udev);
group = iommu_group_get(dev);
if (!group) {
/*
* All the iommu client devices are in the m4u domain,
* they all are in the same m4u iommu-group too here.
*/
if (!m4udom->m4u_group) {
group = iommu_group_alloc();
if (IS_ERR(group)) {
dev_err(dev, "Failed to allocate IOMMU
group\n");
return PTR_ERR(group);
}
m4udom->m4u_group = group;
} else {
group = m4udom->m4u_group;
}
}
ret = iommu_group_add_device(group, dev);
if (ret) {
dev_err(dev, "Failed to add IOMMU group\n");
goto err_group_put;
}
domain = iommu_get_domain_for_dev(dev);
if (!domain)
ret = iommu_attach_group(>domain, group);
err_group_put:
iommu_group_put(group);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: uniphier: add I2C aliases for ProXstream2 boards
On Sat, Oct 24, 2015 at 12:25:31PM +0900, Masahiro Yamada wrote: > Add aliases to fix the I2C indexes like the other UniPhier boards. > > Signed-off-by: Masahiro Yamada Thanks, applied! -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] irqchip: armada-370-xp: re-enable per-CPU interrupts at resume time
Marcin, On Mon, 26 Oct 2015 05:35:46 +0100, Marcin Wojtas wrote: > Thanks for the explanation - now it's clear. Good :-) Hopefully the explanation in PATCH 5/5 is also clear enough. > Btw, I checked the patches with mvneta in both 'standby' and 'mem' > modes on A38x (with not-yet-submitted support for PM in mvneta and > pinctrl) and everything works properly. Hence: Thanks for the testing. However, I wonder why you think those changes are need to get mvneta to work fine with the 'standby' mode ? While I do agree that they are need for the 'mem' mode, they shouldn't be needed for the 'standby' mode. For now, the standby mode only puts the CPU into deep-idle, and that's all: all devices remain powered on, and they don't lose their state. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] kernel: Avoid softlockups in stop_machine() during heavy printing
Hmph, sorry for the x/7 numbering. Patch 7 was the debug patch which I
didn't send...
Honza
On Mon 26-10-15 05:52:46, Jan Kara wrote:
> From: Jan Kara
>
> When there are lots of messages accumulated in printk buffer, printing
> them (especially over serial console) can take a long time (tens of
> seconds). stop_machine() will effectively make all cpus spin in
> multi_cpu_stop() waiting for the CPU doing printing to print all the
> messages which triggers NMI softlockup watchdog and RCU stall detector
> which add even more to the messages to print. Since machine doesn't do
> anything (except serving interrupts) during this time, also network
> connections are dropped and other disturbances may happen.
>
> Paper over the problem by waiting for printk buffer to be empty before
> starting to stop CPUs. In theory a burst of new messages can be appended
> to the printk buffer before CPUs enter multi_cpu_stop() so this isn't a 100%
> solution but it works OK in practice and I'm not aware of a reasonably
> simple better solution.
>
> Signed-off-by: Jan Kara
> ---
> include/linux/console.h | 11 +++
> kernel/printk/printk.c | 25 +
> kernel/stop_machine.c | 9 +
> 3 files changed, 45 insertions(+)
>
> diff --git a/include/linux/console.h b/include/linux/console.h
> index bd194343c346..96da462cdfeb 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -150,6 +150,17 @@ extern int console_trylock(void);
> extern void console_unlock(void);
> extern void console_conditional_schedule(void);
> extern void console_unblank(void);
> +#ifdef CONFIG_SMP
> +extern void printk_log_buf_drain(void);
> +#else
> +/*
> + * In non-SMP kernels there won't be much to drain so save some code for tiny
> + * kernels.
> + */
> +static inline void printk_log_buf_drain(void)
> +{
> +}
> +#endif
> extern struct tty_driver *console_device(int *);
> extern void console_stop(struct console *);
> extern void console_start(struct console *);
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index b9bb4a7a6dff..8dc6c146d022 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2488,6 +2488,31 @@ struct tty_driver *console_device(int *index)
> return driver;
> }
>
> +/* For non-SMP kernels this function isn't used and would be pointless
> anyway */
> +#ifdef CONFIG_SMP
> +/*
> + * Wait until all messages accumulated in the printk buffer are printed to
> + * console. Note that as soon as this function returns, new messages may be
> + * added to the printk buffer by other CPUs.
> + */
> +void printk_log_buf_drain(void)
> +{
> + bool retry;
> + unsigned long flags;
> +
> + while (1) {
> + raw_spin_lock_irqsave(_lock, flags);
> + retry = console_seq != log_next_seq;
> + raw_spin_unlock_irqrestore(_lock, flags);
> + if (!retry || console_suspended)
> + break;
> + /* Cycle console_sem to wait for outstanding printing */
> + console_lock();
> + console_unlock();
> + }
> +}
> +#endif
> +
> /*
> * Prevent further output on the passed console device so that (for example)
> * serial drivers can disable console output before suspending a port, and
> can
> diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
> index 12484e5d5c88..e9496b4a3825 100644
> --- a/kernel/stop_machine.c
> +++ b/kernel/stop_machine.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Structure to determine completion condition and record errors. May
> @@ -543,6 +544,14 @@ static int __stop_machine(cpu_stop_fn_t fn, void *data,
> const struct cpumask *cp
> return ret;
> }
>
> + /*
> + * If there are lots of outstanding messages, printing them can take a
> + * long time and all cpus would be spinning waiting for the printing to
> + * finish thus triggering NMI watchdog, RCU lockups etc. Wait for the
> + * printing here to avoid these.
> + */
> + printk_log_buf_drain();
> +
> /* Set the initial state and stop all online cpus. */
> set_state(, MULTI_STOP_PREPARE);
> return stop_cpus(cpu_online_mask, multi_cpu_stop, );
> --
> 2.1.4
>
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] printk: Start printing handover kthreads on demand
From: Jan Kara
Start kthreads for handing over printing only when printk.offload_chars
is set to value > 0 (i.e., when print offloading gets enabled).
Signed-off-by: Jan Kara
---
kernel/printk/printk.c | 78 +-
1 file changed, 64 insertions(+), 14 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1b26263edfa7..b9bb4a7a6dff 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -98,6 +98,10 @@ static atomic_t printing_tasks_spinning = ATOMIC_INIT(0);
* CPUs.
*/
#define PRINTING_TASKS 2
+/* Pointers to printing kthreads */
+static struct task_struct *printing_kthread[PRINTING_TASKS];
+/* Serialization of changes to printk_offload_chars and kthread creation */
+static DEFINE_MUTEX(printk_kthread_mutex);
/* Wait queue printing kthreads sleep on when idle */
static DECLARE_WAIT_QUEUE_HEAD(print_queue);
@@ -303,6 +307,13 @@ static u32 clear_idx;
static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
static char *log_buf = __log_buf;
static u32 log_buf_len = __LOG_BUF_LEN;
+
+static int offload_chars_set(const char *val, const struct kernel_param *kp);
+static struct kernel_param_ops offload_chars_ops = {
+ .set = offload_chars_set,
+ .get = param_get_uint,
+};
+
/*
* How many characters can we print in one call of printk before asking
* other cpus to continue printing. 0 means infinity. Tunable via
@@ -311,7 +322,7 @@ static u32 log_buf_len = __LOG_BUF_LEN;
*/
static unsigned int __read_mostly printk_offload_chars = 1000;
-module_param_named(offload_chars, printk_offload_chars, uint,
+module_param_cb(offload_chars, _chars_ops, _offload_chars,
S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(offload_chars, "offload printing to console to a different"
" cpu after this number of characters");
@@ -2778,12 +2789,61 @@ static int printing_task(void *arg)
return 0;
}
-static int __init printk_late_init(void)
+static int printk_start_offload_kthreads(void)
{
- struct console *con;
int i;
struct task_struct *task;
+ /* Does handover of printing make any sense? */
+ if (printk_offload_chars == 0 || num_possible_cpus() <= 1)
+ return 0;
+ for (i = 0; i < PRINTING_TASKS; i++) {
+ if (printing_kthread[i])
+ continue;
+ task = kthread_run(printing_task, NULL, "print/%d", i);
+ if (IS_ERR(task))
+ goto out_err;
+ printing_kthread[i] = task;
+ }
+ return 0;
+out_err:
+ pr_err("printk: Cannot create printing thread: %ld\n", PTR_ERR(task));
+ /* Disable offloading if creating kthreads failed */
+ printk_offload_chars = 0;
+ return PTR_ERR(task);
+}
+
+static int offload_chars_set(const char *val, const struct kernel_param *kp)
+{
+ int ret;
+
+ /* Protect against parallel change of printk_offload_chars */
+ mutex_lock(_kthread_mutex);
+ ret = param_set_uint(val, kp);
+ if (ret) {
+ mutex_unlock(_kthread_mutex);
+ return ret;
+ }
+ ret = printk_start_offload_kthreads();
+ mutex_unlock(_kthread_mutex);
+ return ret;
+}
+
+static void printk_offload_init(void)
+{
+ mutex_lock(_kthread_mutex);
+ if (num_possible_cpus() <= 1) {
+ /* Offloading doesn't make sense. Disable print offloading. */
+ printk_offload_chars = 0;
+ } else
+ printk_start_offload_kthreads();
+ mutex_unlock(_kthread_mutex);
+}
+
+static int __init printk_late_init(void)
+{
+ struct console *con;
+
for_each_console(con) {
if (!keep_bootcon && con->flags & CON_BOOT) {
unregister_console(con);
@@ -2791,17 +2851,7 @@ static int __init printk_late_init(void)
}
hotcpu_notifier(console_cpu_notify, 0);
- /* Does any handover of printing have any sence? */
- if (num_possible_cpus() <= 1)
- return 0;
-
- for (i = 0; i < PRINTING_TASKS; i++) {
- task = kthread_run(printing_task, NULL, "print/%d", i);
- if (IS_ERR(task)) {
- pr_err("printk: Cannot create printing thread: %ld\n",
- PTR_ERR(task));
- }
- }
+ printk_offload_init();
return 0;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6 v2] printk: Softlockup avoidance
From: Jan Kara Hello, here is another posting of the revived patch set to avoid lockups during heavy printing. Lately there were several attempts at dealing with softlockups due to heavy printk traffic [1] [2] and I've been also privately pinged by couple of people about the state of the patch set, so I've decided to revive the patch set. Patches (their older version) are present in SUSE enterprise kernels for several years and we didn't observe any issues with them. Patch set passes my stress testing where serial console is slowed down to print ~1000 chars per second and there are 100 delayed works printing together some 64k of text and in parallel modules are inserted which generates quite some additional messages, stop_machine() calls etc. Changes since v1: * printing kthreads now check for kthread_should_stop() * printing kthreads are now bound to CPUs so that scheduler cannot decide to schedule both kthreads on one CPU which effectively makes it impossible to hand over printing between them. This happened relatively frequently in virtual machines. * use printk buffer draining code in panic() to force all messages out when the system is dying * better naming of logbuf flushing functions suggested by AKPM * fixed irq safety of printing lock as pointed out by AKMP * fixed various smaller issues pointed by AKPM Changes since the the old patch set [3]: * I have replaced the state machine to pass printing and spinning on console_sem with a simple spinlock which makes the code somewhat easier to read and verify. * Some of the patches were merged so I dropped them. To remind the original problem: Currently, console_unlock() prints messages from kernel printk buffer to console while the buffer is non-empty. When serial console is attached, printing is slow and thus other CPUs in the system have plenty of time to append new messages to the buffer while one CPU is printing. Thus the CPU can spend unbounded amount of time doing printing in console_unlock(). This is especially serious when printk() gets called under some critical spinlock or with interrupts disabled. In practice users have observed a CPU can spend tens of seconds printing in console_unlock() (usually during boot when hundreds of SCSI devices are discovered) resulting in RCU stalls (CPU doing printing doesn't reach quiescent state for a long time), softlockup reports (IPIs for the printing CPU don't get served and thus other CPUs are spinning waiting for the printing CPU to process IPIs), and eventually a machine death (as messages from stalls and lockups append to printk buffer faster than we are able to print). So these machines are unable to boot with serial console attached. Also during artificial stress testing SATA disk disappears from the system because its interrupts aren't served for too long. This series addresses the problem in the following way: If CPU has printed more that printk_offload (defaults to 1000) characters, it wakes up one of dedicated printk kthreads (we don't use workqueue because that has deadlock potential if printk was called from workqueue code). Once we find out kthread is spinning on a lock, we stop printing, drop console_sem, and let kthread continue printing. Since there are two printing kthreads, they will pass printing between them and thus no CPU gets hogged by printing. Honza [1] https://lkml.org/lkml/2015/7/8/215 [2] http://marc.info/?l=linux-kernel=143929238407816=2 [3] https://lkml.org/lkml/2014/3/17/68 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] printk: Avoid scheduling printing threads on the same CPU
Currently nothing forces the scheduler to schedule printing kthread on
the same CPU that is currently doing printing. In fact in some KVM
configurations this seems to happen rather frequently and it defeats
printing offloading since the current CPU is doing printing and watching
for printing kthread to come and take over however that never happens
because that kthread has been scheduled on the very same CPU.
Fix the problem by allowing each printing kthread to be scheduled only
on a subset of CPUs and these subsets are disjoint so at least one of
the kthreads is guaranteed to be able to take over printing. CPU hotplug
makes this more difficult than it should be but we cope by
redistributing kthreads among CPUs when some kthread is not able to run
anywhere.
Signed-off-by: Jan Kara
---
kernel/printk/printk.c | 105 -
1 file changed, 96 insertions(+), 9 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 5153c6518b9d..72334ed42942 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -101,8 +101,10 @@ static atomic_t printing_tasks_spinning = ATOMIC_INIT(0);
#define PRINTING_TASKS 2
/* Pointers to printing kthreads */
static struct task_struct *printing_kthread[PRINTING_TASKS];
+/* Masks of cpus allowed for printing kthreads */
+static struct cpumask *printing_kthread_mask[PRINTING_TASKS];
/* Serialization of changes to printk_offload_chars and kthread creation */
-static DEFINE_MUTEX(printk_kthread_mutex);
+static DEFINE_MUTEX(printing_kthread_mutex);
/* Wait queue printing kthreads sleep on when idle */
static DECLARE_WAIT_QUEUE_HEAD(print_queue);
@@ -2840,28 +2842,113 @@ static int printing_task(void *arg)
return 0;
}
+/* Divide online cpus among printing kthreads */
+static void distribute_printing_kthreads(void)
+{
+ int i;
+ unsigned int cpus_per_thread;
+ unsigned int cpu, seen_cpu;
+
+ for (i = 0; i < PRINTING_TASKS; i++)
+ cpumask_clear(printing_kthread_mask[i]);
+
+ cpus_per_thread = DIV_ROUND_UP(num_online_cpus(), PRINTING_TASKS);
+ seen_cpu = 0;
+ for_each_online_cpu(cpu) {
+ cpumask_set_cpu(cpu,
+ printing_kthread_mask[seen_cpu / cpus_per_thread]);
+ seen_cpu++;
+ }
+
+ for (i = 0; i < PRINTING_TASKS; i++)
+ if (!cpumask_empty(printing_kthread_mask[i]))
+ set_cpus_allowed_ptr(printing_kthread[i],
+printing_kthread_mask[i]);
+}
+
+static int printing_kthread_cpu_notify(struct notifier_block *nfb,
+ unsigned long action, void *hcpu)
+{
+ unsigned int cpu = (unsigned long)hcpu;
+ int i;
+
+ if (printk_offload_chars == 0)
+ goto out;
+
+ /* Get exclusion against turning of printk offload off... */
+ mutex_lock(_kthread_mutex);
+ /* Now a reliable check if printk offload is enabled */
+ if (printk_offload_chars == 0) {
+ mutex_unlock(_kthread_mutex);
+ goto out;
+ }
+
+ if (action == CPU_ONLINE) {
+ /*
+* Allow some task to use the CPU. We don't want to spend too
+* much time with fair distribution so just guess. We do a fair
+* redistribution if some task has no cpu to run on.
+*/
+ i = cpu % PRINTING_TASKS;
+ cpumask_set_cpu(cpu, printing_kthread_mask[i]);
+ set_cpus_allowed_ptr(printing_kthread[i],
+printing_kthread_mask[i]);
+ }
+ if (action == CPU_DEAD) {
+
+ for (i = 0; i < PRINTING_TASKS; i++) {
+ if (cpumask_test_cpu(cpu, printing_kthread_mask[i])) {
+ cpumask_clear_cpu(cpu,
+ printing_kthread_mask[i]);
+ if (cpumask_empty(printing_kthread_mask[i]))
+ distribute_printing_kthreads();
+ break;
+ }
+ }
+ }
+ mutex_unlock(_kthread_mutex);
+out:
+ return NOTIFY_OK;
+}
+
static int printk_start_offload_kthreads(void)
{
int i;
struct task_struct *task;
+ int ret;
/* Does handover of printing make any sense? */
if (printk_offload_chars == 0 || num_possible_cpus() <= 1)
return 0;
+
for (i = 0; i < PRINTING_TASKS; i++) {
if (printing_kthread[i])
continue;
+ printing_kthread_mask[i] = kmalloc(cpumask_size(), GFP_KERNEL);
+ if (!printing_kthread_mask[i]) {
+ pr_err("printk: Cannot allocate cpumask for printing "
+ "thread.\n");
+ ret =
[PATCH 3/7] kernel: Avoid softlockups in stop_machine() during heavy printing
From: Jan Kara
When there are lots of messages accumulated in printk buffer, printing
them (especially over serial console) can take a long time (tens of
seconds). stop_machine() will effectively make all cpus spin in
multi_cpu_stop() waiting for the CPU doing printing to print all the
messages which triggers NMI softlockup watchdog and RCU stall detector
which add even more to the messages to print. Since machine doesn't do
anything (except serving interrupts) during this time, also network
connections are dropped and other disturbances may happen.
Paper over the problem by waiting for printk buffer to be empty before
starting to stop CPUs. In theory a burst of new messages can be appended
to the printk buffer before CPUs enter multi_cpu_stop() so this isn't a 100%
solution but it works OK in practice and I'm not aware of a reasonably
simple better solution.
Signed-off-by: Jan Kara
---
include/linux/console.h | 11 +++
kernel/printk/printk.c | 25 +
kernel/stop_machine.c | 9 +
3 files changed, 45 insertions(+)
diff --git a/include/linux/console.h b/include/linux/console.h
index bd194343c346..96da462cdfeb 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -150,6 +150,17 @@ extern int console_trylock(void);
extern void console_unlock(void);
extern void console_conditional_schedule(void);
extern void console_unblank(void);
+#ifdef CONFIG_SMP
+extern void printk_log_buf_drain(void);
+#else
+/*
+ * In non-SMP kernels there won't be much to drain so save some code for tiny
+ * kernels.
+ */
+static inline void printk_log_buf_drain(void)
+{
+}
+#endif
extern struct tty_driver *console_device(int *);
extern void console_stop(struct console *);
extern void console_start(struct console *);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index b9bb4a7a6dff..8dc6c146d022 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2488,6 +2488,31 @@ struct tty_driver *console_device(int *index)
return driver;
}
+/* For non-SMP kernels this function isn't used and would be pointless anyway
*/
+#ifdef CONFIG_SMP
+/*
+ * Wait until all messages accumulated in the printk buffer are printed to
+ * console. Note that as soon as this function returns, new messages may be
+ * added to the printk buffer by other CPUs.
+ */
+void printk_log_buf_drain(void)
+{
+ bool retry;
+ unsigned long flags;
+
+ while (1) {
+ raw_spin_lock_irqsave(_lock, flags);
+ retry = console_seq != log_next_seq;
+ raw_spin_unlock_irqrestore(_lock, flags);
+ if (!retry || console_suspended)
+ break;
+ /* Cycle console_sem to wait for outstanding printing */
+ console_lock();
+ console_unlock();
+ }
+}
+#endif
+
/*
* Prevent further output on the passed console device so that (for example)
* serial drivers can disable console output before suspending a port, and can
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 12484e5d5c88..e9496b4a3825 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
/*
* Structure to determine completion condition and record errors. May
@@ -543,6 +544,14 @@ static int __stop_machine(cpu_stop_fn_t fn, void *data,
const struct cpumask *cp
return ret;
}
+ /*
+* If there are lots of outstanding messages, printing them can take a
+* long time and all cpus would be spinning waiting for the printing to
+* finish thus triggering NMI watchdog, RCU lockups etc. Wait for the
+* printing here to avoid these.
+*/
+ printk_log_buf_drain();
+
/* Set the initial state and stop all online cpus. */
set_state(, MULTI_STOP_PREPARE);
return stop_cpus(cpu_online_mask, multi_cpu_stop, );
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] printk: Hand over printing to console if printing too long
From: Jan Kara
Currently, console_unlock() prints messages from kernel printk buffer to
console while the buffer is non-empty. When serial console is attached,
printing is slow and thus other CPUs in the system have plenty of time
to append new messages to the buffer while one CPU is printing. Thus the
CPU can spend unbounded amount of time doing printing in console_unlock().
This is especially serious problem if the printk() calling
console_unlock() was called with interrupts disabled.
In practice users have observed a CPU can spend tens of seconds printing
in console_unlock() (usually during boot when hundreds of SCSI devices
are discovered) resulting in RCU stalls (CPU doing printing doesn't
reach quiescent state for a long time), softlockup reports (IPIs for the
printing CPU don't get served and thus other CPUs are spinning waiting
for the printing CPU to process IPIs), and eventually a machine death
(as messages from stalls and lockups append to printk buffer faster than
we are able to print). So these machines are unable to boot with serial
console attached. Also during artificial stress testing SATA disk
disappears from the system because its interrupts aren't served for too
long.
This patch implements a mechanism where after printing specified number
of characters (tunable as a kernel parameter printk.offload_chars), CPU
doing printing asks for help by waking up one of dedicated kthreads. As
soon as the printing CPU notices kthread got scheduled and is spinning
on print_lock dedicated for that purpose, it drops console_sem,
print_lock, and exits console_unlock(). Kthread then takes over printing
instead. This way no CPU should spend printing too long even if there
is heavy printk traffic.
Signed-off-by: Jan Kara
---
Documentation/kernel-parameters.txt | 15
kernel/printk/printk.c | 173
2 files changed, 171 insertions(+), 17 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 22a4b687ea5b..df8adee975ba 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2958,6 +2958,21 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Format: (1/Y/y=enable, 0/N/n=disable)
default: disabled
+ printk.offload_chars=
+ Printing to console can be relatively slow especially
+ in case of serial console. When there is intensive
+ printing happening from several cpus (as is the case
+ during boot), a cpu can be spending significant time
+ (seconds or more) doing printing. To avoid softlockups,
+ lost interrupts, and similar problems other cpus
+ will take over printing after the currently printing
+ cpu has printed 'printk.offload_chars' characters.
+ Higher value means possibly longer interrupt and other
+ latencies but lower overhead of printing due to handing
+ over of printing.
+ Format: (0 = disabled)
+ default: 1000
+
printk.time=Show timing data prefixed to each printk message line
Format: (1/Y/y=enable, 0/N/n=disable)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8f0324ef72ab..1b26263edfa7 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
@@ -78,6 +79,29 @@ static DEFINE_SEMAPHORE(console_sem);
struct console *console_drivers;
EXPORT_SYMBOL_GPL(console_drivers);
+/*
+ * This spinlock is taken when printing to console. It is used only so that
+ * we can spin on it when some other thread wants to take over printing to
+ * console.
+ */
+static DEFINE_SPINLOCK(print_lock);
+
+/*
+ * Number of printing threads spinning on print_lock. Can go away once
+ * spin_is_contended() is reliable.
+ */
+static atomic_t printing_tasks_spinning = ATOMIC_INIT(0);
+
+/*
+ * Number of kernel threads for offloading printing. We need at least two so
+ * that they can hand over printing from one to another one and thus switch
+ * CPUs.
+ */
+#define PRINTING_TASKS 2
+
+/* Wait queue printing kthreads sleep on when idle */
+static DECLARE_WAIT_QUEUE_HEAD(print_queue);
+
#ifdef CONFIG_LOCKDEP
static struct lockdep_map console_lock_dep_map = {
.name = "console_lock"
@@ -279,6 +303,18 @@ static u32 clear_idx;
static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
static char *log_buf = __log_buf;
static u32 log_buf_len = __LOG_BUF_LEN;
+/*
+ * How many characters can we print in one call of printk before asking
+ * other cpus to continue printing. 0 means infinity. Tunable via
+ * printk.offload_chars kernel parameter. Our default 1000 means about
[PATCH 5/7] printk: Add config option for disabling printk offloading
From: Jan Kara
Necessity for offloading of printing was observed only for large
systems. So add a config option (disabled by default) which removes most
of the overhead added by this functionality.
Signed-off-by: Jan Kara
---
Documentation/kernel-parameters.txt | 13 +++--
init/Kconfig| 14 ++
kernel/printk/printk.c | 35 +--
3 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index df8adee975ba..913c166fdfea 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2958,18 +2958,19 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Format: (1/Y/y=enable, 0/N/n=disable)
default: disabled
- printk.offload_chars=
+ printk.offload_chars= [KNL]
Printing to console can be relatively slow especially
in case of serial console. When there is intensive
printing happening from several cpus (as is the case
during boot), a cpu can be spending significant time
(seconds or more) doing printing. To avoid softlockups,
lost interrupts, and similar problems other cpus
- will take over printing after the currently printing
- cpu has printed 'printk.offload_chars' characters.
- Higher value means possibly longer interrupt and other
- latencies but lower overhead of printing due to handing
- over of printing.
+ will take over printing (if CONFIG_PRINTK_OFFLOAD=y)
+ after the currently printing cpu has printed
+ 'printk.offload_chars' characters. Higher value means
+ possibly longer interrupt and other latencies but
+ lower overhead of printing due to handing over of
+ printing.
Format: (0 = disabled)
default: 1000
diff --git a/init/Kconfig b/init/Kconfig
index c24b6f767bf0..fa9749da5fc8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1456,6 +1456,20 @@ config PRINTK
very difficult to diagnose system problems, saying N here is
strongly discouraged.
+config PRINTK_OFFLOAD
+ default n
+ bool "Enable support for offloading printing to different CPU"
+ depends on PRINTK && SMP
+ help
+ Printing to console can be relatively slow especially in case of
+ serial console. On large machines when there is intensive printing
+ happening from several cpus (as is the case during boot), a cpu can
+ be spending significant time (seconds or more) doing printing. To
+ avoid softlockups, lost interrupts, and similar problems other cpus
+ will take over printing after the currently printing cpu has printed
+ certain number of characters (tunable via 'printk.offload_chars'
+ kernel parameter).
+
config BUG
bool "BUG() support" if EXPERT
default y
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index e404c429fe87..5153c6518b9d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -79,6 +79,7 @@ static DEFINE_SEMAPHORE(console_sem);
struct console *console_drivers;
EXPORT_SYMBOL_GPL(console_drivers);
+#ifdef CONFIG_PRINTK_OFFLOAD
/*
* This spinlock is taken when printing to console. It is used only so that
* we can spin on it when some other thread wants to take over printing to
@@ -105,6 +106,7 @@ static DEFINE_MUTEX(printk_kthread_mutex);
/* Wait queue printing kthreads sleep on when idle */
static DECLARE_WAIT_QUEUE_HEAD(print_queue);
+#endif /* CONFIG_PRINTK_OFFLOAD */
#ifdef CONFIG_LOCKDEP
static struct lockdep_map console_lock_dep_map = {
@@ -308,6 +310,7 @@ static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
static char *log_buf = __log_buf;
static u32 log_buf_len = __LOG_BUF_LEN;
+#ifdef CONFIG_PRINTK_OFFLOAD
static int offload_chars_set(const char *val, const struct kernel_param *kp);
static struct kernel_param_ops offload_chars_ops = {
.set = offload_chars_set,
@@ -326,6 +329,7 @@ module_param_cb(offload_chars, _chars_ops,
_offload_chars,
S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(offload_chars, "offload printing to console to a different"
" cpu after this number of characters");
+#endif
/* Return log buffer address */
char *log_buf_addr_get(void)
@@ -2255,6 +2259,7 @@ out:
raw_spin_unlock_irqrestore(_lock, flags);
}
+#ifdef CONFIG_PRINTK_OFFLOAD
/*
* Returns true iff there is other cpu waiting to take over printing. This
* function also takes are of setting PRINTK_HANDOVER_B
[PATCH 4/7] panic: Always flush printk buffer before panic
In some cases we may end up killing the CPU holding the console lock
while still having valuable data in logbuf. E.g. Vitaly is observing the
following:
- A crash is happening on one CPU and console_unlock() is being called
on some other.
- console_unlock() tries to print out the buffer before releasing the
lock and on slow console it takes time.
- in the meanwhile crashing CPU does lots of printk()-s with valuable
data (which go to the logbuf) and sends IPIs to all other CPUs.
- console_unlock() finishes printing previous chunk and enables
interrupts before trying to print out the rest, the CPU catches the
IPI and never releases console lock.
This is not the only possible case: in VT/fb subsystems we have many
other console_lock()/console_unlock() users. Non-masked interrupts (or
receiving NMI in case of extreme slowness) will have the same result.
Getting the whole console buffer printed out on crash is top priority.
So zap printk locks and print logbuf contents after all cpus have been
stopped.
Based on patch by Vitaly Kuznetsov.
CC: Vitaly Kuznetsov
Reported-and-tested-by: Vitaly Kuznetsov
Signed-off-by: Jan Kara
---
include/linux/console.h | 4 ++--
kernel/panic.c | 8
kernel/printk/printk.c | 5 -
kernel/stop_machine.c | 2 +-
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/include/linux/console.h b/include/linux/console.h
index 96da462cdfeb..f40084802f3f 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -151,13 +151,13 @@ extern void console_unlock(void);
extern void console_conditional_schedule(void);
extern void console_unblank(void);
#ifdef CONFIG_SMP
-extern void printk_log_buf_drain(void);
+extern void printk_log_buf_drain(bool panic);
#else
/*
* In non-SMP kernels there won't be much to drain so save some code for tiny
* kernels.
*/
-static inline void printk_log_buf_drain(void)
+static inline void printk_log_buf_drain(bool panic)
{
}
#endif
diff --git a/kernel/panic.c b/kernel/panic.c
index 04e91ff7560b..d07ed830a9fb 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#define PANIC_TIMER_STEP 100
#define PANIC_BLINK_SPD 18
@@ -147,6 +148,13 @@ void panic(const char *fmt, ...)
bust_spinlocks(0);
+ /*
+* We may have ended up stopping the CPU doing printing (in
+* smp_send_stop()) while still having some valuable data in the
+* console buffer. Flush it out.
+*/
+ printk_log_buf_drain(true);
+
if (!panic_blink)
panic_blink = no_blink;
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8dc6c146d022..e404c429fe87 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2495,11 +2495,14 @@ struct tty_driver *console_device(int *index)
* console. Note that as soon as this function returns, new messages may be
* added to the printk buffer by other CPUs.
*/
-void printk_log_buf_drain(void)
+void printk_log_buf_drain(bool panic)
{
bool retry;
unsigned long flags;
+ if (panic)
+ zap_locks();
+
while (1) {
raw_spin_lock_irqsave(_lock, flags);
retry = console_seq != log_next_seq;
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index e9496b4a3825..50a03735893e 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -550,7 +550,7 @@ static int __stop_machine(cpu_stop_fn_t fn, void *data,
const struct cpumask *cp
* finish thus triggering NMI watchdog, RCU lockups etc. Wait for the
* printing here to avoid these.
*/
- printk_log_buf_drain();
+ printk_log_buf_drain(false);
/* Set the initial state and stop all online cpus. */
set_state(, MULTI_STOP_PREPARE);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/10] hwmon: (fam15h_power) Introduce a cpu accumulated power reporting algorithm
On Mon, Oct 26, 2015 at 11:46:16AM +0800, Huang Rui wrote: > Actually, yes. I found it too long, so... :) Yeah, just try to apply some good, old-fashioned human common sense when looking at longer lines and deciding whether actually letting them stick out would be better for readability than breaking them. :-) -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 06/10] hwmon: (fam15h_power) Add ptsc counter value for accumulated power
On Mon, Oct 26, 2015 at 11:37:23AM +0800, Huang Rui wrote: > On Fri, Oct 23, 2015 at 06:59:19AM -0700, Guenter Roeck wrote: > > On 10/19/2015 07:28 PM, Huang Rui wrote: > > >PTSC is the performance timestamp counter value in a cpu core and the > > >cores in one compute unit have the fixed frequency. So it picks up the > > >performance timestamp counter value of the first core per compute unit > > >to measure the interval for average power per compute unit. > > > > > >Signed-off-by: Huang Rui > > >Cc: Borislav Petkov > > >Cc: Guenter Roeck > > >Cc: Peter Zijlstra > > >Cc: Ingo Molnar > > >--- > > > arch/x86/include/asm/msr-index.h | 1 + > > > drivers/hwmon/fam15h_power.c | 5 + > > > 2 files changed, 6 insertions(+) ... > > >@@ -132,6 +134,9 @@ static void do_read_registers_on_cu(void *_data) > > > > > > WARN_ON(rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR, > > > >cu_acc_power[cu])); > > >+ > > >+ WARN_ON(rdmsrl_safe(MSR_F15H_PTSC, > > >+ >cpu_sw_pwr_ptsc[cu])); > > > } > > > > I am not really happy with those WARN_ON, or even an error message. > > If the error is seen, it may be persistent. > > > > If an error check is really needed here, it might make more sense to store > > the read error and return it to user space if the respective sysfs attribute > > is read. > > > > I am OK with removing WARN_ON here. Boris, if you also agree with it, The real question should be: are those MSR accesses behind a CPUID flag check which guarantees their existence? If so, you don't really need WARN_ONs. And the MSR accesses better be behind a CPUID flag anyway because reading non-existent MSRs is pretty much pure waste of energy. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] irqchip: armada-370-xp: re-enable per-CPU interrupts at resume time
Thomas,
2015-10-26 1:10 GMT+01:00 Thomas Petazzoni
:
> Marcin,
>
> On Sun, 25 Oct 2015 22:22:37 +0100, Marcin Wojtas wrote:
>
>> > @@ -550,16 +572,27 @@ static void armada_370_xp_mpic_resume(void)
>> > if (virq == 0)
>> > continue;
>> >
>> > - if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
>> > + data = irq_get_irq_data(virq);
>> > +
>> > + if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ) {
>> > + /* Non per-CPU interrupts */
>> > writel(irq, per_cpu_int_base +
>>
>> For "Non per-CPU interrupts" per_cpu_int_base is used - is it
>> intentional? In armada_370_xp_irq_mask/unmask the condition looks
>> exactly opposite...
>
> Yes, this is normal. Carefully read PATCH 5/5, which adds a big
> comment, which explains the logic of the HW and how the
> irq-armada-370-xp driver copes with it.
>
> Each interrupt can be masked at two levels. One level is enabled when
> the interrupted is mapped, the other upon ->mask()/->unmask(). So
> when we're resuming, we need to re-enable the interrupt at the level it
> was enabled in ->map(), and have ->mask()/->unmask() continue to
> mask/unmask the interrupt at the other level.
>
> For per-CPU interrupts, ->map() and ->resume() enable the interrupt at
> the global level, and leave ->mask()/->unmask() enable/disable at the
> per-CPU level.
>
> For global interrupts, ->map() and ->resume() enable the interrupt at
> the per-CPU level, and leave ->mask()/->unmask() enable/disable at the
> global level.
>
> Again, see PATCH 5/5, and let me know if there are still some unclear
> aspects.
>
Thanks for the explanation - now it's clear.
Btw, I checked the patches with mvneta in both 'standby' and 'mem'
modes on A38x (with not-yet-submitted support for PM in mvneta and
pinctrl) and everything works properly. Hence:
Tested-by: Marcin Wojtas
Best regards,
Marcin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 8/8] rockchip: make sure timer5 is enabled on rk3036 platforms
The timer5 supplies the architected timer and thus as has to run when
the system clocksource and clockevents drivers are registered.
---
Changes in v5:
Signed-off-by: Xing Zheng
Reviewed-by: Heiko Stuebner
arch/arm/mach-rockchip/rockchip.c | 44 +++--
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-rockchip/rockchip.c
b/arch/arm/mach-rockchip/rockchip.c
index 251c7b9..608b31c 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -29,31 +29,38 @@
#include "core.h"
#include "pm.h"
+#define RK3036_TIMER_PHYS 0x20044000
+
#define RK3288_GRF_SOC_CON0 0x244
#define RK3288_TIMER6_7_PHYS 0xff81
+static void rockchip_init_arch_timer_supply(resource_size_t phys, int offs)
+{
+ void __iomem *reg_base = ioremap(phys, SZ_16K);
+
+ /*
+* Most/all uboot versions for Rockchip SoCs don't enable
+* timer which is needed for the architected timer to work.
+* So make sure it is running during early boot.
+*/
+ if (reg_base) {
+ writel(0, reg_base + offs + 0x10);
+ writel(0x, reg_base + offs);
+ writel(0x, reg_base + offs + 0x04);
+ writel(1, reg_base + offs + 0x10);
+ dsb();
+ iounmap(reg_base);
+ } else {
+ pr_err("rockchip: could not map timer registers\n");
+ }
+}
+
static void __init rockchip_timer_init(void)
{
if (of_machine_is_compatible("rockchip,rk3288")) {
struct regmap *grf;
- void __iomem *reg_base;
- /*
-* Most/all uboot versions for rk3288 don't enable timer7
-* which is needed for the architected timer to work.
-* So make sure it is running during early boot.
-*/
- reg_base = ioremap(RK3288_TIMER6_7_PHYS, SZ_16K);
- if (reg_base) {
- writel(0, reg_base + 0x30);
- writel(0x, reg_base + 0x20);
- writel(0x, reg_base + 0x24);
- writel(1, reg_base + 0x30);
- dsb();
- iounmap(reg_base);
- } else {
- pr_err("rockchip: could not map timer7 registers\n");
- }
+ rockchip_init_arch_timer_supply(RK3288_TIMER6_7_PHYS, 0x20);
/*
* Disable auto jtag/sdmmc switching that causes issues
@@ -64,6 +71,8 @@ static void __init rockchip_timer_init(void)
regmap_write(grf, RK3288_GRF_SOC_CON0, 0x1000);
else
pr_err("rockchip: could not get grf syscon\n");
+ } else if (of_machine_is_compatible("rockchip,rk3036")) {
+ rockchip_init_arch_timer_supply(RK3036_TIMER_PHYS, 0xa0);
}
of_clk_init(NULL);
@@ -79,6 +88,7 @@ static void __init rockchip_dt_init(void)
static const char * const rockchip_board_dt_compat[] = {
"rockchip,rk2928",
+ "rockchip,rk3036",
"rockchip,rk3066a",
"rockchip,rk3066b",
"rockchip,rk3188",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 7/8] ARM: dts: enable smp for rk3036
Enable smp for rk3036, and add the smp sram name for adapting.
Signed-off-by: Xing Zheng
Reviewed-by: Heiko Stuebner
---
Changes in v5: None
arch/arm/boot/dts/rk3036.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 8f3a069..61352be 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -72,6 +72,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "rockchip,rk3036-smp";
cpu0: cpu@f00 {
device_type = "cpu";
@@ -146,6 +147,10 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1008 0x2000>;
+ smp-sram@0 {
+ compatible = "rockchip,rk3066-smp-sram";
+ reg = <0x00 0x10>;
+ };
};
cru: clock-controller@2000 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 6/8] ARM: rockchip: add support smp for rk3036
From: Heiko Stuebner
The dual-core Cortex A7 rk3036 is a bit special in that it does not allow
to control the actual powerdomain of the cpu cores, while the rest of the
smp-bringup like reset control and entry address handling stays the same.
Its bigger sibling, the quad-core rk3128 again allows powerdomain control.
So allow that case by introducing a separate smp-enable-method, that simply
disables powerdomain handling in the common code.
Signed-off-by: Heiko Stuebner
Tested-by: Xing Zheng
Signed-off-by: Xing Zheng
---
Changes in v5: None
Documentation/devicetree/bindings/arm/cpus.txt |1 +
arch/arm/mach-rockchip/platsmp.c | 45 +---
2 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 91e6e5c..261cc27 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -198,6 +198,7 @@ nodes to be present and contain the properties described
below.
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
+ "rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
index 3e7a4b7..5c138f9 100644
--- a/arch/arm/mach-rockchip/platsmp.c
+++ b/arch/arm/mach-rockchip/platsmp.c
@@ -42,6 +42,7 @@ static int ncores;
#define PMU_PWRDN_SCU 4
static struct regmap *pmu;
+static int has_pmu = true;
static int pmu_power_domain_is_on(int pd)
{
@@ -89,20 +90,23 @@ static int pmu_set_power_domain(int pd, bool on)
if (!IS_ERR(rstc) && !on)
reset_control_assert(rstc);
- ret = regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), val);
- if (ret < 0) {
- pr_err("%s: could not update power domain\n", __func__);
- return ret;
- }
-
- ret = -1;
- while (ret != on) {
- ret = pmu_power_domain_is_on(pd);
+ if (has_pmu) {
+ ret = regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), val);
if (ret < 0) {
- pr_err("%s: could not read power domain state\n",
+ pr_err("%s: could not update power domain\n",
__func__);
return ret;
}
+
+ ret = -1;
+ while (ret != on) {
+ ret = pmu_power_domain_is_on(pd);
+ if (ret < 0) {
+ pr_err("%s: could not read power domain
state\n",
+ __func__);
+ return ret;
+ }
+ }
}
if (!IS_ERR(rstc)) {
@@ -122,7 +126,7 @@ static int rockchip_boot_secondary(unsigned int cpu, struct
task_struct *idle)
{
int ret;
- if (!sram_base_addr || !pmu) {
+ if (!sram_base_addr || (has_pmu && !pmu)) {
pr_err("%s: sram or pmu missing for cpu boot\n", __func__);
return -ENXIO;
}
@@ -275,7 +279,7 @@ static void __init rockchip_smp_prepare_cpus(unsigned int
max_cpus)
return;
}
- if (rockchip_smp_prepare_pmu())
+ if (has_pmu && rockchip_smp_prepare_pmu())
return;
if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
@@ -318,6 +322,13 @@ static void __init rockchip_smp_prepare_cpus(unsigned int
max_cpus)
pmu_set_power_domain(0 + i, false);
}
+static void __init rk3036_smp_prepare_cpus(unsigned int max_cpus)
+{
+ has_pmu = false;
+
+ rockchip_smp_prepare_cpus(max_cpus);
+}
+
#ifdef CONFIG_HOTPLUG_CPU
static int rockchip_cpu_kill(unsigned int cpu)
{
@@ -340,6 +351,15 @@ static void rockchip_cpu_die(unsigned int cpu)
}
#endif
+static struct smp_operations rk3036_smp_ops __initdata = {
+ .smp_prepare_cpus = rk3036_smp_prepare_cpus,
+ .smp_boot_secondary = rockchip_boot_secondary,
+#ifdef CONFIG_HOTPLUG_CPU
+ .cpu_kill = rockchip_cpu_kill,
+ .cpu_die= rockchip_cpu_die,
+#endif
+};
+
static struct smp_operations rockchip_smp_ops __initdata = {
.smp_prepare_cpus = rockchip_smp_prepare_cpus,
.smp_boot_secondary = rockchip_boot_secondary,
@@ -349,4 +369,5 @@ static struct smp_operations rockchip_smp_ops __initdata = {
#endif
};
+CPU_METHOD_OF_DECLARE(rk3036_smp, "rockchip,rk3036-smp", _smp_ops);
CPU_METHOD_OF_DECLARE(rk3066_smp, "rockchip,rk3066-smp", _smp_ops);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v5 5/8] ARM: dts: rockchip: add core rk3036 dts
Initial release for rk3036, node definitions rk3036 sdk board.
Signed-off-by: Xing Zheng
Reviewed-by: Heiko Stuebner
---
Changes in v5: None
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/rk3036-evb.dts | 64 +
arch/arm/boot/dts/rk3036.dtsi| 536 ++
3 files changed, 601 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3036-evb.dts
create mode 100644 arch/arm/boot/dts/rk3036.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7d3e495..3e4e089 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -510,6 +510,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
+ rk3036-evb.dtb \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
diff --git a/arch/arm/boot/dts/rk3036-evb.dts b/arch/arm/boot/dts/rk3036-evb.dts
new file mode 100644
index 000..28a0336
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-evb.dts
@@ -0,0 +1,64 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3036.dtsi"
+
+/ {
+ model = "Rockchip RK3036 Evaluation board";
+ compatible = "rockchip,rk3036-evb", "rockchip,rk3036";
+};
+
+ {
+ status = "okay";
+
+ hym8563: hym8563@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "xin32k";
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
new file mode 100644
index 000..8f3a069
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -0,0 +1,536 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ *
Re: [PATCH] GHES: Fix cached error-status
On Mon, Oct 26, 2015 at 11:20:35AM +0800, Huang, Ying wrote: > In ghes_estatus_caches[], for caches with same contents, the cache with > biggest (newest) cache->time_in should be the first. So if we found one > cache with too small (old) cache->time_in, we can say there are no cache > with same contents and bigger (newer) cache->time_in, so that we can > make decision (break) earlier. Well, for starters, this should be documented in the code so that people looking at it would not need to scratch their heads over that break statement there. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/8] clk: rockchip: add dt-binding header for rk3036
Add the dt-bindings header for the rk3036, that gets shared between the clock controller and the clock references in the dts. Signed-off-by: Xing Zheng Reviewed-by: Heiko Stuebner --- Changes in v5: None include/dt-bindings/clock/rk3036-cru.h | 195 1 file changed, 195 insertions(+) create mode 100644 include/dt-bindings/clock/rk3036-cru.h diff --git a/include/dt-bindings/clock/rk3036-cru.h b/include/dt-bindings/clock/rk3036-cru.h new file mode 100644 index 000..b0da216 --- /dev/null +++ b/include/dt-bindings/clock/rk3036-cru.h @@ -0,0 +1,195 @@ +/* + * Copyright (c) 2015 Rockchip Electronics Co. Ltd. + * Author: Xing Zheng + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H +#define _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H + +/* core clocks */ +#define PLL_APLL 1 +#define PLL_DPLL 2 +#define PLL_GPLL 3 +#define ARMCLK 4 + +/* sclk gates (special clocks) */ +#define SCLK_GPU 64 +#define SCLK_SPI 65 +#define SCLK_SDMMC 68 +#define SCLK_SDIO 69 +#define SCLK_EMMC 71 +#define SCLK_NANDC 76 +#define SCLK_UART0 77 +#define SCLK_UART1 78 +#define SCLK_UART2 79 +#define SCLK_I2S 82 +#define SCLK_SPDIF 83 +#define SCLK_TIMER085 +#define SCLK_TIMER186 +#define SCLK_TIMER287 +#define SCLK_TIMER388 +#define SCLK_OTGPHY0 93 +#define SCLK_LCDC 100 +#define SCLK_HDMI 109 +#define SCLK_HEVC 111 +#define SCLK_I2S_OUT 113 +#define SCLK_SDMMC_DRV 114 +#define SCLK_SDIO_DRV 115 +#define SCLK_EMMC_DRV 117 +#define SCLK_SDMMC_SAMPLE 118 +#define SCLK_SDIO_SAMPLE 119 +#define SCLK_EMMC_SAMPLE 121 +#define SCLK_PVTM_CORE 123 +#define SCLK_PVTM_GPU 124 +#define SCLK_PVTM_VIDEO 125 +#define SCLK_MAC 151 +#define SCLK_MACREF152 +#define SCLK_SFC 160 + +#define DCLK_LCDC 190 + +/* aclk gates */ +#define ACLK_DMAC2 194 +#define ACLK_LCDC 197 +#define ACLK_VIO 203 +#define ACLK_VCODEC208 +#define ACLK_CPU 209 +#define ACLK_PERI 210 + +/* pclk gates */ +#define PCLK_GPIO0 320 +#define PCLK_GPIO1 321 +#define PCLK_GPIO2 322 +#define PCLK_GRF 329 +#define PCLK_I2C0 332 +#define PCLK_I2C1 333 +#define PCLK_I2C2 334 +#define PCLK_SPI 338 +#define PCLK_UART0 341 +#define PCLK_UART1 342 +#define PCLK_UART2 343 +#define PCLK_PWM 350 +#define PCLK_TIMER 353 +#define PCLK_HDMI 360 +#define PCLK_CPU 362 +#define PCLK_PERI 363 +#define PCLK_DDRUPCTL 364 +#define PCLK_WDT 368 +#define PCLK_ACODEC369 + +/* hclk gates */ +#define HCLK_OTG0 449 +#define HCLK_OTG1 450 +#define HCLK_NANDC 453 +#define HCLK_SDMMC 456 +#define HCLK_SDIO 457 +#define HCLK_EMMC 459 +#define HCLK_I2S 462 +#define HCLK_LCDC 465 +#define HCLK_ROM 467 +#define HCLK_VIO_BUS 472 +#define HCLK_VCODEC476 +#define HCLK_CPU 477 +#define HCLK_PERI 478 + +#define CLK_NR_CLKS(HCLK_PERI + 1) + +/* soft-reset indices */ +#define SRST_CORE0 0 +#define SRST_CORE1 1 +#define SRST_CORE0_DBG 4 +#define SRST_CORE1_DBG 5 +#define SRST_CORE0_POR 8 +#define SRST_CORE1_POR 9 +#define SRST_L2C 12 +#define SRST_TOPDBG13 +#define SRST_STRC_SYS_A14 +#define SRST_PD_CORE_NIU 15 + +#define SRST_TIMER216 +#define SRST_CPUSYS_H 17 +#define SRST_AHB2APB_H 19 +#define SRST_TIMER320 +#define SRST_INTMEM21 +#define SRST_ROM 22 +#define SRST_PERI_NIU 23 +#define SRST_I2S 24 +#define SRST_DDR_PLL 25 +#define SRST_GPU_DLL 26 +#define SRST_TIMER027 +#define SRST_TIMER128 +#define SRST_CORE_DLL 29 +#define SRST_EFUSE_P
[PATCH v5 0/8] Build and support rk3036 SoC platform
Hi, We need to support rk3036 soc platform via upstream, there are 3 primary parts for the initial release of minimum system: dts, pinctrl, and clock tree for rk3036, and additional, we can use these startup and run to init processs. Thanks. Changed in v5: - don't use clk_ APIs in the pll init-callback Changed in v4: - add some basic IP modules on rk3036.dtsi - optimized supporting smp codes Changed in v3: - optimized some codes based on v2 - removed the patch "initial set time for rtc-hym8563" (useless) - removed the patch "pinctrl" (approved) Changed in v2: - based on v1, add clock controller documentation - enable timer5 startup - add smp for cpu1 - initial set time for rtc-hym8563 Changes in v1: - add dts, pinctrl and clock tree for rk3036 soc platform The patchset (8): 8) rockchip: make sure timer5 is enabled on rk3036 platforms 7) ARM: dts: enable smp for rk3036 6) ARM: rockchip: add support smp for rk3036 5) ARM: dts: rockchip: add core rk3036 dts 4) clk: rockchip: add new pll-type for rk3036 and similar socs 3) clk: rockchip: add clock controller for rk3036 2) clk: rockchip: add dt-binding header for rk3036 1) dt-bindings: add documentation of rk3036 clock controller Changes in v5: Signed-off-by: Xing Zheng Reviewed-by: Heiko Stuebner Heiko Stuebner (1): ARM: rockchip: add support smp for rk3036 Xing Zheng (7): dt-bindings: add documentation of rk3036 clock controller clk: rockchip: add dt-binding header for rk3036 clk: rockchip: add clock controller for rk3036 clk: rockchip: add new pll-type for rk3036 and similar socs ARM: dts: rockchip: add core rk3036 dts ARM: dts: enable smp for rk3036 rockchip: make sure timer5 is enabled on rk3036 platforms Documentation/devicetree/bindings/arm/cpus.txt |1 + .../bindings/clock/rockchip,rk3036-cru.txt | 56 ++ arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/rk3036-evb.dts | 64 +++ arch/arm/boot/dts/rk3036.dtsi | 541 arch/arm/mach-rockchip/platsmp.c | 45 +- arch/arm/mach-rockchip/rockchip.c | 44 +- drivers/clk/rockchip/Makefile |1 + drivers/clk/rockchip/clk-pll.c | 249 - drivers/clk/rockchip/clk-rk3036.c | 500 ++ drivers/clk/rockchip/clk.h | 30 ++ include/dt-bindings/clock/rk3036-cru.h | 195 +++ 12 files changed, 1697 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt create mode 100644 arch/arm/boot/dts/rk3036-evb.dts create mode 100644 arch/arm/boot/dts/rk3036.dtsi create mode 100644 drivers/clk/rockchip/clk-rk3036.c create mode 100644 include/dt-bindings/clock/rk3036-cru.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/8] clk: rockchip: add clock controller for rk3036
Add the clock tree definition for the new rk3036 SoC.
Signed-off-by: Xing Zheng
Reviewed-by: Heiko Stuebner
---
Changes in v5: None
drivers/clk/rockchip/Makefile |1 +
drivers/clk/rockchip/clk-rk3036.c | 500 +
drivers/clk/rockchip/clk.h| 30 +++
3 files changed, 531 insertions(+)
create mode 100644 drivers/clk/rockchip/clk-rk3036.c
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index b27edd6..d599829 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -10,6 +10,7 @@ obj-y += clk-inverter.o
obj-y += clk-mmc-phase.o
obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
+obj-y += clk-rk3036.o
obj-y += clk-rk3188.o
obj-y += clk-rk3288.o
obj-y += clk-rk3368.o
diff --git a/drivers/clk/rockchip/clk-rk3036.c
b/drivers/clk/rockchip/clk-rk3036.c
new file mode 100644
index 000..6f49df3
--- /dev/null
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -0,0 +1,500 @@
+/*
+ * Copyright (c) 2014 MundoReader S.L.
+ * Author: Heiko Stuebner
+ *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "clk.h"
+
+#define RK3036_GRF_SOC_STATUS0 0x14c
+
+enum rk3036_plls {
+ apll, dpll, gpll,
+};
+
+static struct rockchip_pll_rate_table rk3036_pll_rates[] = {
+ /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
+ RK3036_PLL_RATE(160800, 1, 67, 1, 1, 1, 0),
+ RK3036_PLL_RATE(158400, 1, 66, 1, 1, 1, 0),
+ RK3036_PLL_RATE(156000, 1, 65, 1, 1, 1, 0),
+ RK3036_PLL_RATE(153600, 1, 64, 1, 1, 1, 0),
+ RK3036_PLL_RATE(151200, 1, 63, 1, 1, 1, 0),
+ RK3036_PLL_RATE(148800, 1, 62, 1, 1, 1, 0),
+ RK3036_PLL_RATE(146400, 1, 61, 1, 1, 1, 0),
+ RK3036_PLL_RATE(144000, 1, 60, 1, 1, 1, 0),
+ RK3036_PLL_RATE(141600, 1, 59, 1, 1, 1, 0),
+ RK3036_PLL_RATE(139200, 1, 58, 1, 1, 1, 0),
+ RK3036_PLL_RATE(136800, 1, 57, 1, 1, 1, 0),
+ RK3036_PLL_RATE(134400, 1, 56, 1, 1, 1, 0),
+ RK3036_PLL_RATE(132000, 1, 55, 1, 1, 1, 0),
+ RK3036_PLL_RATE(129600, 1, 54, 1, 1, 1, 0),
+ RK3036_PLL_RATE(127200, 1, 53, 1, 1, 1, 0),
+ RK3036_PLL_RATE(124800, 1, 52, 1, 1, 1, 0),
+ RK3036_PLL_RATE(12, 1, 50, 1, 1, 1, 0),
+ RK3036_PLL_RATE(118800, 2, 99, 1, 1, 1, 0),
+ RK3036_PLL_RATE(110400, 1, 46, 1, 1, 1, 0),
+ RK3036_PLL_RATE(11, 12, 550, 1, 1, 1, 0),
+ RK3036_PLL_RATE(100800, 1, 84, 2, 1, 1, 0),
+ RK3036_PLL_RATE(10, 6, 500, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 98400, 1, 82, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 96000, 1, 80, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 93600, 1, 78, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 91200, 1, 76, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 9, 4, 300, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 88800, 1, 74, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 86400, 1, 72, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 84000, 1, 70, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 81600, 1, 68, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 8, 6, 400, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 7, 6, 350, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 69600, 1, 58, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 6, 1, 75, 3, 1, 1, 0),
+ RK3036_PLL_RATE( 59400, 2, 99, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 50400, 1, 63, 3, 1, 1, 0),
+ RK3036_PLL_RATE( 5, 6, 250, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 40800, 1, 68, 2, 2, 1, 0),
+ RK3036_PLL_RATE( 31200, 1, 52, 2, 2, 1, 0),
+ RK3036_PLL_RATE( 21600, 1, 72, 4, 2, 1, 0),
+ RK3036_PLL_RATE( 9600, 1, 64, 4, 4, 1, 0),
+ { /* sentinel */ },
+};
+
+#define RK3036_DIV_CPU_MASK0x1f
+#define RK3036_DIV_CPU_SHIFT 8
+
+#define RK3036_DIV_PERI_MASK 0xf
+#define RK3036_DIV_PERI_SHIFT 0
+#define RK3036_DIV_ACLK_MASK 0x7
+#define RK3036_DIV_ACLK_SHIFT 4
+#define RK3036_DIV_HCLK_MASK 0x3
+#define RK3036_DIV_HCLK_SHIFT 8
+#define RK3036_DIV_PCLK_MASK 0x7
+#define RK3036_DIV_PCLK_SHIFT 12
+
+#define RK3036_CLKSEL1(_core_periph_div)
\
+ {
\
+ .reg =
[PATCH v5 4/8] clk: rockchip: add new pll-type for rk3036 and similar socs
The rk3036's pll and clock are different with base on the rk3066(rk3188,
rk3288, rk3368 use it), there are different adjust foctors and control
registers, so these should be independent and separate from the series
of rk3066s.
Signed-off-by: Xing Zheng
Reviewed-by: Heiko Stuebner
---
Changes in v5: None
drivers/clk/rockchip/clk-pll.c | 249 +++-
1 file changed, 248 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 4881eb8..83ba1e9 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -2,6 +2,9 @@
* Copyright (c) 2014 MundoReader S.L.
* Author: Heiko Stuebner
*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -19,6 +22,7 @@
#include
#include
#include
+#include
#include "clk.h"
#define PLL_MODE_MASK 0x3
@@ -108,6 +112,243 @@ static int rockchip_pll_wait_lock(struct rockchip_clk_pll
*pll)
}
/**
+ * PLL used in RK3036
+ */
+
+#define RK3036_PLLCON(i) (i * 0x4)
+#define RK3036_PLLCON0_FBDIV_MASK 0xfff
+#define RK3036_PLLCON0_FBDIV_SHIFT 0
+#define RK3036_PLLCON0_POSTDIV1_MASK 0x7
+#define RK3036_PLLCON0_POSTDIV1_SHIFT 12
+#define RK3036_PLLCON1_REFDIV_MASK 0x3f
+#define RK3036_PLLCON1_REFDIV_SHIFT0
+#define RK3036_PLLCON1_POSTDIV2_MASK 0x7
+#define RK3036_PLLCON1_POSTDIV2_SHIFT 6
+#define RK3036_PLLCON1_DSMPD_MASK 0x1
+#define RK3036_PLLCON1_DSMPD_SHIFT 12
+#define RK3036_PLLCON2_FRAC_MASK 0xff
+#define RK3036_PLLCON2_FRAC_SHIFT 0
+
+#define RK3036_PLLCON1_PWRDOWN (1 << 13)
+
+static void rockchip_rk3036_pll_get_params(struct rockchip_clk_pll *pll,
+ struct rockchip_pll_rate_table *rate)
+{
+ u32 pllcon;
+
+ pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(0));
+ rate->fbdiv = ((pllcon >> RK3036_PLLCON0_FBDIV_SHIFT) &
RK3036_PLLCON0_FBDIV_MASK);
+ rate->postdiv1 = ((pllcon >> RK3036_PLLCON0_POSTDIV1_SHIFT) &
RK3036_PLLCON0_POSTDIV1_MASK);
+
+ pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(1));
+ rate->refdiv = ((pllcon >> RK3036_PLLCON1_REFDIV_SHIFT) &
RK3036_PLLCON1_REFDIV_MASK);
+ rate->postdiv2 = ((pllcon >> RK3036_PLLCON1_POSTDIV2_SHIFT) &
RK3036_PLLCON1_POSTDIV2_MASK);
+ rate->dsmpd = ((pllcon >> RK3036_PLLCON1_DSMPD_SHIFT) &
RK3036_PLLCON1_DSMPD_MASK);
+
+ pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(2));
+ rate->frac = ((pllcon >> RK3036_PLLCON2_FRAC_SHIFT) &
RK3036_PLLCON2_FRAC_MASK);
+}
+
+static unsigned long rockchip_rk3036_pll_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
+{
+ struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
+ struct rockchip_pll_rate_table cur;
+ u64 rate64 = prate;
+
+ rockchip_rk3036_pll_get_params(pll, );
+
+ rate64 *= cur.fbdiv;
+ do_div(rate64, cur.refdiv);
+
+ if (cur.dsmpd == 0) {
+ /* fractional mode */
+ u64 frac_rate64 = prate * cur.frac;
+
+ do_div(frac_rate64, cur.refdiv);
+ rate64 += frac_rate64 >> 24;
+ }
+
+ do_div(rate64, cur.postdiv1);
+ do_div(rate64, cur.postdiv2);
+
+ return (unsigned long)rate64;
+}
+
+static int rockchip_rk3036_pll_set_params(struct rockchip_clk_pll *pll,
+ const struct rockchip_pll_rate_table *rate)
+{
+ const struct clk_ops *pll_mux_ops = pll->pll_mux_ops;
+ struct clk_mux *pll_mux = >pll_mux;
+ struct rockchip_pll_rate_table cur;
+ u32 pllcon;
+ int rate_change_remuxed = 0;
+ int cur_parent;
+ int ret;
+
+ pr_debug("%s: rate settings for %lu fbdiv: %d, postdiv1: %d, refdiv:
%d, postdiv2: %d, dsmpd: %d, frac: %d\n",
+ __func__, rate->rate, rate->fbdiv, rate->postdiv1, rate->refdiv,
+ rate->postdiv2, rate->dsmpd, rate->frac);
+
+ rockchip_rk3036_pll_get_params(pll, );
+ cur.rate = 0;
+
+ cur_parent = pll_mux_ops->get_parent(_mux->hw);
+ if (cur_parent == PLL_MODE_NORM) {
+ pll_mux_ops->set_parent(_mux->hw, PLL_MODE_SLOW);
+ rate_change_remuxed = 1;
+ }
+
+ /* update pll values */
+ writel_relaxed(HIWORD_UPDATE(rate->fbdiv, RK3036_PLLCON0_FBDIV_MASK,
+ RK3036_PLLCON0_FBDIV_SHIFT) |
+ HIWORD_UPDATE(rate->postdiv1,
RK3036_PLLCON0_POSTDIV1_MASK,
+
(IPVN) EuP/FRBWDC/EcB-3109/2015,
European Parliament 36 St Peter's St, London N1 8JT, United Kingdom. In consideration of the legislative resolution reached by the European Parliament in conjunctions with the European Central Bank on financial and allied matters,following eries of complaints and petitions received from the office of the European Union Commission towards the non-release of payment of foreign beneficiaries of funds as at when due. Our committee on financial regulations and fact finding (FRFF) for foreign payment was subsequently inaugurated to help in ensuring that any outstanding payment emanating from Europe is released from the beneficiary's country central bank. Thus from the records of oustanding beneficiaries manifesto,due for payment in Asia,your names was among the list of beneficiaries whose files showed sufficient proof to receive their overdue payment,The sum of (£1,000,000.00/-GBP) was marred to you,But due to various fees imposed by their so-called delivery officers or diplomat or even representative including bank officials who end up in ripping off beneficiaries of their money instead of discharging their duties diligently,thus diverting beneficiaries approved funds into their untraceable private bank account without due consent of original fund beneficiaries. To avoid all further bottle-necks,we have allotted to you a new International payment voucher Number (IPVN) EuP/FRBWDC/EcB-3109/2015. Please re-confirm the following information for validation purposes to this email.(europeancentral...@foxmail.com) Your Names:Address:Age:country:Occupation:Mobile Telephone Number/s. Yours Faithfully. Martin Schulz. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/8] dt-bindings: add documentation of rk3036 clock controller
Add the devicetree binding for the cru on the rk3036 which quite similar
structured as previous clock controllers.
Signed-off-by: Xing Zheng
Reviewed-by: Heiko Stuebner
---
Changes in v5: None
.../bindings/clock/rockchip,rk3036-cru.txt | 56
1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
new file mode 100644
index 000..ace0599
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
@@ -0,0 +1,56 @@
+* Rockchip RK3036 Clock and Reset Unit
+
+The RK3036 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk3036-cru"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+ If missing pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+
+Example: Clock controller node:
+
+ cru: cru@2000 {
+ compatible = "rockchip,rk3036-cru";
+ reg = <0x2000 0x1000>;
+ rockchip,grf = <>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller:
+
+ uart0: serial@2006 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x2006 0x100>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = < SCLK_UART0>;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Arnd, 2015-10-10 15:59 GMT+09:00 Masahiro Yamada : > Hi Arnd, > > > 2015-10-06 15:22 GMT+01:00 Arnd Bergmann : >> On Tuesday 06 October 2015 16:20:23 Arnd Bergmann wrote: >>> On Friday 18 September 2015 13:37:31 Masahiro Yamada wrote: >>> > Hi Olof, >>> > >>> > Now Linux 4.3-rc1 is out, so I am back to this. >>> > >>> > 1/3: add outer cache support >>> > 2/3: rework SMP operations >>> > 3/3: add device tree nodes >>> > >>> > Because 2/3 highly depends on 1/3, I hope whole of this series >>> > is applied through ARM-SOC tree. >>> >>> Sorry for the long delay here. Is this the latest version of these >>> patches? >>> >>> Did Russell King review the first patch? >>> Is he ok with merging this through arm-soc? >>> >> >> I found an answer to the first question, as I see you posted >> v5 of the patchset in the meantime. > > > Yes, v5 is my latest version. > > > For the second question, Russell gave me some comments on the 1/3 > and I answered. > > He mentioned nothing about merging the whole series thru arm-soc. > (At least, he was not opposed to it, I guess) > Is it difficult to apply this series for the next merge window? V5 is the latest. No comment, but not applied. Is there anything I can do but wait? -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] serial: support 16-bit register interface for console
Currently, 8-bit (MMIO) and 32-bit (MMIO32) register interfaces are
supported for the 8250 console, but the 16-bit (MMIO16) is not.
The 8250 UART device on my board is connected to a 16-bit bus
and my main motivation is to use earlycon with it.
(Refer to arch/arm/boot/dts/uniphier-support-card.dtsi)
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- Adjust of_platform_serial_setup(), univ8250_console_match()
for UPIO_MEM16
Changes in v2:
- Do not change userspace-exported macros
Documentation/kernel-parameters.txt | 9 +
drivers/tty/serial/8250/8250_core.c | 7 ---
drivers/tty/serial/8250/8250_early.c | 5 +
drivers/tty/serial/8250/8250_port.c | 20
drivers/tty/serial/earlycon.c| 15 +++
drivers/tty/serial/of_serial.c | 3 +++
drivers/tty/serial/serial_core.c | 9 +++--
include/linux/serial_core.h | 1 +
include/uapi/linux/serial.h | 1 +
9 files changed, 57 insertions(+), 13 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 22a4b68..761f08c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -720,16 +720,17 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
uart[8250],io,[,options]
uart[8250],mmio,[,options]
+ uart[8250],mmio16,[,options]
uart[8250],mmio32,[,options]
uart[8250],0x[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later.
MMIO inter-register address stride is either 8-bit
- (mmio) or 32-bit (mmio32).
- If none of [io|mmio|mmio32], is assumed to be
- equivalent to 'mmio'. 'options' are specified in the
- same format described for ttyS above; if unspecified,
+ (mmio), 16-bit (mmio16), or 32-bit (mmio32).
+ If none of [io|mmio|mmio16|mmio32], is assumed
+ to be equivalent to 'mmio'. 'options' are specified in
+ the same format described for ttyS above; if
unspecified,
the h/w is not re-initialized.
hvc Use the hypervisor console device . This is for
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 271d121..a643867 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -617,7 +617,7 @@ static int univ8250_console_setup(struct console *co, char
*options)
* @options: ptr to option string from console command line
*
* Only attempts to match console command lines of the form:
- * console=uart[8250],io|mmio|mmio32,[,]
+ * console=uart[8250],io|mmio|mmio16|mmio32,[,]
* console=uart[8250],0x[,]
* This form is used to register an initial earlycon boot console and
* replace it with the serial8250_console at 8250 driver init.
@@ -647,8 +647,9 @@ static int univ8250_console_match(struct console *co, char
*name, int idx,
if (port->iotype != iotype)
continue;
- if ((iotype == UPIO_MEM || iotype == UPIO_MEM32) &&
- (port->mapbase != addr))
+ if ((iotype == UPIO_MEM || iotype == UPIO_MEM16 ||
+iotype == UPIO_MEM32 || iotype == UPIO_MEM32BE)
+ && (port->mapbase != addr))
continue;
if (iotype == UPIO_PORT && port->iobase != addr)
continue;
diff --git a/drivers/tty/serial/8250/8250_early.c
b/drivers/tty/serial/8250/8250_early.c
index faed05f..7aff3d8 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -40,6 +40,8 @@ static unsigned int __init serial8250_early_in(struct
uart_port *port, int offse
switch (port->iotype) {
case UPIO_MEM:
return readb(port->membase + offset);
+ case UPIO_MEM16:
+ return readw(port->membase + (offset << 1));
case UPIO_MEM32:
return readl(port->membase + (offset << 2));
case UPIO_MEM32BE:
@@ -57,6 +59,9 @@ static void __init serial8250_early_out(struct uart_port
*port, int offset, int
case UPIO_MEM:
writeb(value, port->membase + offset);
break;
+ case UPIO_MEM16:
+ writew(value, port->membase + (offset << 1));
+ break;
case UPIO_MEM32:
writel(value, port->membase + (offset << 2));
break;
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 0bbf340..f976948
[PATCH] drivers: usb: removed assignment of 0 to static variables
fixing the error reported by script checkpatch.pl static variables blinkenlights and old_scheme_first were initialised to 0, correcting it. Signed-off-by: Saurabh Sengar --- drivers/usb/core/hub.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 431839b..6abc4ab 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -49,7 +49,7 @@ static void hub_event(struct work_struct *work); DEFINE_MUTEX(usb_port_peer_mutex); /* cycle leds on hubs that aren't blinking for attention */ -static bool blinkenlights = 0; +static bool blinkenlights; module_param(blinkenlights, bool, S_IRUGO); MODULE_PARM_DESC(blinkenlights, "true to cycle leds on hubs"); @@ -78,7 +78,7 @@ MODULE_PARM_DESC(initial_descriptor_timeout, * otherwise the new scheme is used. If that fails and "use_both_schemes" * is set, then the driver will make another attempt, using the other scheme. */ -static bool old_scheme_first = 0; +static bool old_scheme_first; module_param(old_scheme_first, bool, S_IRUGO | S_IWUSR); MODULE_PARM_DESC(old_scheme_first, "start with the old device initialization scheme"); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Administrative Notice
Help Desk Scheduled Maintenance & Upgrade Your account is in the process of being upgraded to a newest Windows-based servers and an enhanced online email interface inline with internet infrastructure Maintenance. The new servers will provide better anti-spam and anti-virus functions, along with IMAP Support for mobile devices to enhance your usage. To ensure that your account is not disrupted but active during and after this upgrade, you are required to kindly confirm your account by stating the details below: * Domain\user name: * Password: This will prompt the upgrade of your account. Failure to acknowledge the receipt of this notification, might result to a temporary deactivation of your account from our database. Your account shall remain active upon your confirmation of your login details. During this maintenance window, there may be periods of interruption to email services. This will include sending and receiving email in Outlook, on webmail, and on mobile devices. Also, if you leave your Mailbox open during the maintenance period, you may be prompted to close and reopen. We appreciate your patience as this maintenance is performed and we do apologize for any inconveniences caused. Sincerely, Customer Care Team (c) Copyright 2015, All Rights Reserved. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/10] hwmon: (fam15h_power) Introduce a cpu accumulated power reporting algorithm
On Fri, Oct 23, 2015 at 03:28:02PM +0200, Borislav Petkov wrote:
> On Tue, Oct 20, 2015 at 10:28:26AM +0800, Huang Rui wrote:
> > This patch introduces an algorithm that computes the average power by
> > reading a delta value of “core power accumulator” register during
> > measurement interval, and then dividing delta value by the length of
> > the time interval.
> >
> > User is able to use power1_average entry to measure the processor power
> > consumption and power1_average_interval entry to set the interval.
> >
> > A simple example:
> >
> > ray@hr-ub:~/tip$ sensors
> > fam15h_power-pci-00c4
> > Adapter: PCI adapter
> > power1: 23.73 mW (avg = 634.63 mW, interval = 0.01 s)
> >(crit = 15.00 W)
> >
> > ...
>
> I need to play with this more after I get back from KS. Just a partial
> review for now.
>
Sounds good.
> >
> > The result is current average processor power consumption in 10
> > millisecond. The unit of the result is uWatt.
> >
> > Suggested-by: Guenter Roeck
> > Signed-off-by: Huang Rui
> > Cc: Borislav Petkov
> > Cc: Peter Zijlstra
> > Cc: Ingo Molnar
> > ---
> > drivers/hwmon/fam15h_power.c | 120
> > +++
> > 1 file changed, 120 insertions(+)
> >
> > diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> > index 6321f73..a5a539e 100644
> > --- a/drivers/hwmon/fam15h_power.c
> > +++ b/drivers/hwmon/fam15h_power.c
> > @@ -26,6 +26,9 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> > #include
> > #include
> >
> > @@ -64,6 +67,10 @@ struct fam15h_power_data {
> > u64 cu_acc_power[MAX_CUS];
> > /* performance timestamp counter */
> > u64 cpu_sw_pwr_ptsc[MAX_CUS];
> > + /* online/offline status of current compute unit */
> > + int cu_on[MAX_CUS];
> > + unsigned long power_period;
> > + struct mutex acc_pwr_mutex;
> > };
> >
> > static ssize_t show_power(struct device *dev,
> > @@ -132,11 +139,15 @@ static void do_read_registers_on_cu(void *_data)
> > cores_per_cu = amd_get_cores_per_cu();
> > cu = cpu / cores_per_cu;
> >
> > + mutex_lock(>acc_pwr_mutex);
> > WARN_ON(rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR,
> > >cu_acc_power[cu]));
> >
> > WARN_ON(rdmsrl_safe(MSR_F15H_PTSC,
> > >cpu_sw_pwr_ptsc[cu]));
> > +
> > + data->cu_on[cu] = 1;
> > + mutex_unlock(>acc_pwr_mutex);
> > }
> >
> > static int read_registers(struct fam15h_power_data *data)
> > @@ -148,6 +159,10 @@ static int read_registers(struct fam15h_power_data
> > *data)
> > cores_per_cu = amd_get_cores_per_cu();
> > cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> >
> > + mutex_lock(>acc_pwr_mutex);
> > + memset(data->cu_on, 0, sizeof(int) * MAX_CUS);
> > + mutex_unlock(>acc_pwr_mutex);
> > +
> > WARN_ON_ONCE(cu_num > MAX_CUS);
> >
> > ret = zalloc_cpumask_var(, GFP_KERNEL);
> > @@ -184,18 +199,113 @@ static int read_registers(struct fam15h_power_data
> > *data)
> > return 0;
> > }
> >
> > +static ssize_t acc_show_power(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct fam15h_power_data *data = dev_get_drvdata(dev);
> > + u64 prev_cu_acc_power[MAX_CUS], prev_ptsc[MAX_CUS],
> > + jdelta[MAX_CUS];
> > + u64 tdelta, avg_acc;
> > + int cu, cu_num, cores_per_cu, ret;
> > + signed long leftover;
> > +
> > + cores_per_cu = amd_get_cores_per_cu();
> > + cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > + ret = read_registers(data);
> > + if (ret)
> > + return 0;
> > +
> > + cu = 0;
> > + while(cu++ < cu_num) {
> > + prev_cu_acc_power[cu] = data->cu_acc_power[cu];
> > + prev_ptsc[cu] = data->cpu_sw_pwr_ptsc[cu];
> > + }
>
> Please integrate checkpatch into your workflow of creating patches - it
> can be correct sometimes:
>
> ERROR: space required before the open parenthesis '('
> #130: FILE: drivers/hwmon/fam15h_power.c:221:
> + while(cu++ < cu_num) {
>
Oh, I will take care next time.
>
> > +
> > + leftover = schedule_timeout_interruptible(
> > + msecs_to_jiffies(data->power_period)
> > + );
>
> This way of writing a function call is reaaally ugly. What's wrong with:
>
> leftover =
> schedule_timeout_interruptible(msecs_to_jiffies(data->power_period));
>
> ?
>
> And don't tell me 80 columns - that rule is not a hard one.
>
Actually, yes. I found it too long, so... :)
OK, I will fix it on V3.
Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 06/10] hwmon: (fam15h_power) Add ptsc counter value for accumulated power
On Fri, Oct 23, 2015 at 06:59:19AM -0700, Guenter Roeck wrote:
> On 10/19/2015 07:28 PM, Huang Rui wrote:
> >PTSC is the performance timestamp counter value in a cpu core and the
> >cores in one compute unit have the fixed frequency. So it picks up the
> >performance timestamp counter value of the first core per compute unit
> >to measure the interval for average power per compute unit.
> >
> >Signed-off-by: Huang Rui
> >Cc: Borislav Petkov
> >Cc: Guenter Roeck
> >Cc: Peter Zijlstra
> >Cc: Ingo Molnar
> >---
> > arch/x86/include/asm/msr-index.h | 1 +
> > drivers/hwmon/fam15h_power.c | 5 +
> > 2 files changed, 6 insertions(+)
> >
> >diff --git a/arch/x86/include/asm/msr-index.h
> >b/arch/x86/include/asm/msr-index.h
> >index c1c0a1c..3686eaa 100644
> >--- a/arch/x86/include/asm/msr-index.h
> >+++ b/arch/x86/include/asm/msr-index.h
> >@@ -313,6 +313,7 @@
> > #define MSR_F15H_PERF_CTR 0xc0010201
> > #define MSR_F15H_NB_PERF_CTL 0xc0010240
> > #define MSR_F15H_NB_PERF_CTR 0xc0010241
> >+#define MSR_F15H_PTSC 0xc0010280
> >
> > /* Fam 10h MSRs */
> > #define MSR_FAM10H_MMIO_CONF_BASE 0xc0010058
> >diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> >index 88e4f3e..6321f73 100644
> >--- a/drivers/hwmon/fam15h_power.c
> >+++ b/drivers/hwmon/fam15h_power.c
> >@@ -62,6 +62,8 @@ struct fam15h_power_data {
> > u64 max_cu_acc_power;
> > /* accumulated power of the compute units */
> > u64 cu_acc_power[MAX_CUS];
> >+/* performance timestamp counter */
> >+u64 cpu_sw_pwr_ptsc[MAX_CUS];
> > };
> >
> > static ssize_t show_power(struct device *dev,
> >@@ -132,6 +134,9 @@ static void do_read_registers_on_cu(void *_data)
> >
> > WARN_ON(rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR,
> > >cu_acc_power[cu]));
> >+
> >+WARN_ON(rdmsrl_safe(MSR_F15H_PTSC,
> >+>cpu_sw_pwr_ptsc[cu]));
> > }
>
> I am not really happy with those WARN_ON, or even an error message.
> If the error is seen, it may be persistent.
>
> If an error check is really needed here, it might make more sense to store
> the read error and return it to user space if the respective sysfs attribute
> is read.
>
I am OK with removing WARN_ON here. Boris, if you also agree with it,
I will remove it on V3.
Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v12 3/6] CPM/QE: use genalloc to manage CPM/QE muram
On Sat, 2015-10-24 at 04:59 AM, Wood Scott-B07421
wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, October 24, 2015 4:59 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> pau...@samba.org
> Subject: Re: [PATCH v12 3/6] CPM/QE: use genalloc to manage CPM/QE muram
>
> Don't send HTML e-mail.
>
> On Fri, 2015-10-23 at 02:06 -0500, Zhao Qiang-B45475 wrote:
> > On Fri, 2015-10-23 at 11:00 AM, Wood Scott-B07421
> >
> > wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, October 23, 2015 11:00 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > > pau...@samba.org
> > > Subject: Re: [PATCH v12 3/6] CPM/QE: use genalloc to manage CPM/QE
> > > muram
> > >
> > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote:
> > > > -/**
> > > > +/*
> > > > * cpm_muram_alloc - allocate the requested size worth of
> > > > multi-user
> > ram
> > > > * @size: number of bytes to allocate
> > > > * @align: requested alignment, in bytes @@ -141,59 +151,102 @@ out:
> > > > */
> > > > unsigned long cpm_muram_alloc(unsigned long size, unsigned long
> > > > align) {
> > > > - unsigned long start;
> > > > unsigned long flags;
> > > > -
> > > > + unsigned long start;
> > > > + static struct genpool_data_align muram_pool_data;
> > > > spin_lock_irqsave(_muram_lock, flags);
> > > > - cpm_muram_info.alignment = align;
> > > > - start = rh_alloc(_muram_info, size, "commproc");
> > > > - memset(cpm_muram_addr(start), 0, size);
> > > > + muram_pool_data.align = align;
> > > > + gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
> > > > + _pool_data);
> > > > + start = cpm_muram_alloc_common(size, _pool_data);
> > > > spin_unlock_irqrestore(_muram_lock, flags);
> > > > -
> > > > return start;
> > > > }
> > > > EXPORT_SYMBOL(cpm_muram_alloc);
> > >
> > > Why is muram_pool_data static? Why is it being passed to
> > > gen_pool_set_algo()?
> > Cpm_muram use both align algo and fixed algo, so we need to set
> > corresponding algo and Algo data.
>
> The data gets passed in via gen_pool_alloc_data(). The point was to allow it
> to
> be on the caller's stack, not a long-lived data structure shared by all
> callers and
> needing synchronization.
You mean it is not necessary to point pool->data to data, just passing the data
to gen_pool_alloc_data()?
However, the algo it needed to be set.
>
> > >The whole reason we're adding gen_pool_alloc_data() is to avoid
> > >that. Do we need gen_pool_alloc_algo() too?
> >
> > We add gen_pool_alloc_data() to pass data to algo, because align algo
> > and fixed algo, Because align and fixed algos need specific data.
>
> And my point is that because of that, it seems like we need a version that
> accepts an algorithm as well.
It the user just use only one algo, it doesn’t need to set algo,
However, qe_muram use two algos with alloc_align function
And alloc_fixed function.
-Zhao
Re: [PATCH v2 4/8] spi: imx: add selection for iMX53 and iMX6 controller type
Hello
Subject: [PATCH v2 4/8] spi: imx: add selection for iMX53 and iMX6 controller
type
ECSPI contorller for iMX53 and iMX6 has few hardware issues in slave
mode and (32*n+1) SPI word size handling comparing to iMX51.
The change add possibility to detect the SPI controller is use and apply
workarounds/limitations.
Documentation for device tree bindings updated
Signed-off-by: Anton Bondarenko
---
.../devicetree/bindings/spi/fsl-imx-cspi.txt | 2 ++
drivers/spi/spi-imx.c | 36 --
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
index 523341a..425485f 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
@@ -9,6 +9,8 @@ Required properties:
- "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31
- "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35
- "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51
+ - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53
+ - "fsl,imx6q-ecspi" for SPI compatible with the one integrated on i.MX6
family
- reg : Offset and length of the register set for the device
- interrupts : Should contain CSPI/eCSPI interrupt
- fsl,spi-num-chipselects : Contains the number of the chipselect
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index d9b730d..41c9cef 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -72,7 +72,8 @@ enum spi_imx_devtype {
IMX27_CSPI,
IMX31_CSPI,
IMX35_CSPI, /* CSPI on all i.mx except above */
- IMX51_ECSPI,/* ECSPI on i.mx51 and later */
+ IMX51_ECSPI,/* ECSPI on i.mx51 */
+ IMX53_ECSPI,/* ECSPI on i.mx53 and later */
};
struct spi_imx_data;
@@ -129,9 +130,20 @@ static inline int is_imx35_cspi(struct spi_imx_data *d)
return d->devtype_data->devtype == IMX35_CSPI;
}
+static inline int is_imx53_ecspi(struct spi_imx_data *d)
+{
+ return d->devtype_data->devtype == IMX53_ECSPI;
+}
+
+static inline int is_imx5x_ecspi(struct spi_imx_data *d)
+{
+ return d->devtype_data->devtype == IMX51_ECSPI ||
+ d->devtype_data->devtype == IMX53_ECSPI;
+}
+
static inline unsigned spi_imx_get_fifosize(struct spi_imx_data *d)
{
- return (d->devtype_data->devtype == IMX51_ECSPI) ? 64 : 8;
+ return is_imx5x_ecspi(d) ? 64 : 8;
}
#define MXC_SPI_BUF_RX(type) \
@@ -680,6 +692,16 @@ static struct spi_imx_devtype_data
imx51_ecspi_devtype_data = {
.devtype = IMX51_ECSPI,
};
+static struct spi_imx_devtype_data imx53_ecspi_devtype_data = {
+ /* i.mx53 and later ecspi shares the functions with i.mx51 one */
+ .intctrl = mx51_ecspi_intctrl,
+ .config = mx51_ecspi_config,
+ .trigger = mx51_ecspi_trigger,
+ .rx_available = mx51_ecspi_rx_available,
+ .reset = mx51_ecspi_reset,
+ .devtype = IMX53_ECSPI,
+};
+
static const struct platform_device_id spi_imx_devtype[] = {
{
.name = "imx1-cspi",
@@ -697,6 +719,12 @@ static const struct platform_device_id spi_imx_devtype[] =
{
.name = "imx35-cspi",
.driver_data = (kernel_ulong_t) _cspi_devtype_data,
}, {
+ .name = "imx53-ecspi",
+ .driver_data = (kernel_ulong_t)_ecspi_devtype_data,
+ }, {
+ .name = "imx6q-ecspi",
+ .driver_data = (kernel_ulong_t)_ecspi_devtype_data,
+ }, {
.name = "imx51-ecspi",
.driver_data = (kernel_ulong_t) _ecspi_devtype_data,
}, {
@@ -710,6 +738,8 @@ static const struct of_device_id spi_imx_dt_ids[] = {
{ .compatible = "fsl,imx27-cspi", .data = _cspi_devtype_data, },
{ .compatible = "fsl,imx31-cspi", .data = _cspi_devtype_data, },
{ .compatible = "fsl,imx35-cspi", .data = _cspi_devtype_data, },
+ { .compatible = "fsl,imx53-ecspi", .data = _ecspi_devtype_data, },
+ { .compatible = "fsl,imx6q-ecspi", .data = _ecspi_devtype_data, },
{ .compatible = "fsl,imx51-ecspi", .data = _ecspi_devtype_data, },
{ /* sentinel */ }
};
@@ -1299,7 +1329,7 @@ static int spi_imx_probe(struct platform_device *pdev)
* Only validated on i.mx6 now, can remove the constrain if validated on
* other chips.
*/
- if (spi_imx->devtype_data == _ecspi_devtype_data &&
+ if (is_imx5x_ecspi(spi_imx) &&
spi_imx_sdma_init(>dev, spi_imx, master))
dev_err(>dev, "dma setup error,use pio instead\n");
With this patch, there will still be issues with SPI controller on imx6
soc other than imx6q,
for example SPI controller on imx6sl has compatibility
"compatible = "fsl,imx6sl-ecspi",
Re: [PATCH 1/1] x86: Fix reading the current exposure value of UVC
Hi Anton,
Thank you for the patch.
On Sunday 18 October 2015 17:01:26 Anton V. Shokurov wrote:
> V4L2_CID_EXPOSURE_ABSOLUTE property does not return an updated value when
> autoexposure (V4L2_CID_EXPOSURE_AUTO) is turned on. This patch fixes this
> issue by adding the UVC_CTRL_FLAG_AUTO_UPDATE flag.
>
> Tested on a C920 camera.
This looks good to me and I've successfully tested the patch.
> Signed-off-by: Anton V. Shokurov
Reviewed-by: Laurent Pinchart
Applied to my tree, I'll push it upstream for v4.5 (the merge window for v4.4
will open in a week only and with the Kernel Summit going on this week pushing
patches for v4.4 is difficult).
> ---
> drivers/media/usb/uvc/uvc_ctrl.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> b/drivers/media/usb/uvc/uvc_ctrl.c index 3e59b28..c2ee6e3 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -227,7 +227,8 @@ static struct uvc_control_info uvc_ctrls[] = {
> .size = 4,
> .flags = UVC_CTRL_FLAG_SET_CUR
>
> | UVC_CTRL_FLAG_GET_RANGE
>
> - | UVC_CTRL_FLAG_RESTORE,
> + | UVC_CTRL_FLAG_RESTORE
> + | UVC_CTRL_FLAG_AUTO_UPDATE,
> },
> {
> .entity = UVC_GUID_UVC_CAMERA,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] GHES: Fix cached error-status
Hi, Tony, "Luck, Tony" writes: >> ping? > > I'm not actually sure that the code is wrong. As you say it is a pretty > strange loop. > > We seem to want to look at a bunch of conditions, and use "continue" to ignore > bits until we find one that we like the look of. Perhaps as soon as we do, > we want > to believe it to get our return value? Perhaps the code knows that we won't > find > another section that matches all the tests, so it isn't worth going around > the loop > again. > > Ying: You wrote this code 4 years ago. Any recollections of why it looks like > it does? Sorry for late. I read the code again, and found the although the original code is a little tricky, it actually works. In ghes_estatus_caches[], for caches with same contents, the cache with biggest (newest) cache->time_in should be the first. So if we found one cache with too small (old) cache->time_in, we can say there are no cache with same contents and bigger (newer) cache->time_in, so that we can make decision (break) earlier. Best Regards, Huang, Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote: > On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote: > > I am not seeing a sync there, but I really have to defer to the > > maintainers on this one. I could easily have missed one. > > So x86 implies a full barrier for everything that changes the CPL; and > some form of implied ordering seems a must if you change the privilege > level unless you tag every single load/store with the priv level at that > time, which seems the more expensive option. > > So I suspect the typical implementation will flush all load/stores, > change the effective priv level and continue. > > This can of course be implemented at a pure per CPU ordering (RCpc), > which would be in line with the rest of Power, in which case you do > indeed need an explicit sync to make it visible to other CPUs. Right - interrupts and returns from interrupt are context synchronizing operations, which means they wait until all outstanding instructions have got to the point where they have reported any exceptions they're going to report, which means in turn that loads and stores have completed address translation. But all of that doesn't imply anything about the visibility of the loads and stores. There is a full barrier in the context switch path, but not in the system call entry/exit path. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] macvtap: unbreak receiving of gro skb with frag list
On 10/23/2015 09:37 PM, Michael S. Tsirkin wrote:
> On Fri, Oct 23, 2015 at 12:57:05AM -0400, Jason Wang wrote:
>> We don't have fraglist support in TAP_FEATURES. This will lead
>> software segmentation of gro skb with frag list. Fixes by having
>> frag list support in TAP_FEATURES.
>>
>> With this patch single session of netperf receiving were restored from
>> about 5Gb/s to about 12Gb/s on mlx4.
>>
>> Fixes a567dd6252 ("macvtap: simplify usage of tap_features")
>> Cc: Vlad Yasevich
>> Cc: Michael S. Tsirkin
>> Signed-off-by: Jason Wang
> Thanks!
> Does this mean we should look at re-adding NETIF_F_FRAGLIST
> to virtio-net as well?
Not sure I get the point, but probably not. This is for receiving and
skb_copy_datagram_iter() can deal with frag list.
>
>> ---
>> drivers/net/macvtap.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>> index 248478c..197c939 100644
>> --- a/drivers/net/macvtap.c
>> +++ b/drivers/net/macvtap.c
>> @@ -137,7 +137,7 @@ static const struct proto_ops macvtap_socket_ops;
>> #define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
>>NETIF_F_TSO6 | NETIF_F_UFO)
>> #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
>> -#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
>> +#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG | NETIF_F_FRAGLIST)
>>
>> static struct macvlan_dev *macvtap_get_vlan_rcu(const struct net_device
>> *dev)
>> {
>> --
>> 1.8.3.1
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3][v2] Thermal: handle thermal zone device properly during system sleep
From: Zhang Rui
Current thermal code does not handle system sleep well because
1. the cooling device cooling state may be changed during suspend
2. the previous temperature reading becomes invalid after resumed because
it is got before system sleep
3. updating thermal zone device during suspending/resuming
is wrong because some devices may have already been suspended
or may have not been resumed.
Thus, the proper way to do this is to cancel all thermal zone
device update requirements during suspend/resume, and after all
the devices have been resumed, reset and update every registered
thermal zone devices.
This also fixes a regression introduced by:
Commit 19593a1fb1f6 ("ACPI / fan: convert to platform driver")
Because, with above commit applied, all the fan devices are attached
to the acpi_general_pm_domain, and they are turned on by the pm_domain
automatically after resume, without the awareness of thermal core.
CC: #3.18+
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=78201
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=91411
Tested-by: Manuel Krause
Tested-by: szegad
Tested-by: prash
Tested-by: amish
Tested-by: Matthias
Signed-off-by: Zhang Rui
Signed-off-by: Chen Yu
---
drivers/thermal/thermal_core.c | 45 +-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 682bc1e..abeb995 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
@@ -59,6 +60,8 @@ static LIST_HEAD(thermal_governor_list);
static DEFINE_MUTEX(thermal_list_lock);
static DEFINE_MUTEX(thermal_governor_lock);
+static atomic_t in_suspend;
+
static struct thermal_governor *def_governor;
static struct thermal_governor *__find_governor(const char *name)
@@ -554,6 +557,9 @@ void thermal_zone_device_update(struct thermal_zone_device
*tz)
{
int count;
+ if (atomic_read(_suspend))
+ return;
+
if (!tz->ops->get_temp)
return;
@@ -2155,9 +2161,39 @@ static void thermal_unregister_governors(void)
thermal_gov_power_allocator_unregister();
}
+static int thermal_pm_notify(struct notifier_block *nb,
+ unsigned long mode, void *_unused)
+{
+ struct thermal_zone_device *tz;
+
+ switch (mode) {
+ case PM_HIBERNATION_PREPARE:
+ case PM_RESTORE_PREPARE:
+ case PM_SUSPEND_PREPARE:
+ atomic_set(_suspend, 1);
+ break;
+ case PM_POST_HIBERNATION:
+ case PM_POST_RESTORE:
+ case PM_POST_SUSPEND:
+ atomic_set(_suspend, 0);
+ list_for_each_entry(tz, _tz_list, node) {
+ thermal_zone_device_reset(tz);
+ thermal_zone_device_update(tz);
+ }
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
+static struct notifier_block thermal_pm_nb = {
+ .notifier_call = thermal_pm_notify,
+};
+
static int __init thermal_init(void)
{
- int result;
+ int result, notifier_result;
result = thermal_register_governors();
if (result)
@@ -2175,6 +2211,12 @@ static int __init thermal_init(void)
if (result)
goto exit_netlink;
+ notifier_result = register_pm_notifier(_pm_nb);
+ if (notifier_result)
+ pr_err("Thermal: Can not register suspend notifier"
+ "for thermal framework, return %d\n",
+ notifier_result);
+
return 0;
exit_netlink:
@@ -2194,6 +2236,7 @@ error:
static void __exit thermal_exit(void)
{
+ unregister_pm_notifier(_pm_nb);
of_thermal_destroy_zones();
genetlink_exit();
class_unregister(_class);
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3][v2] Thermal: do thermal zone update after a cooling device registered
When a new cooling device is registered, we need to update the
thermal zone to set the new registered cooling device to a proper
state.
This fixes a problem that the system is cool, while the fan devices
are left running on full speed after boot, if fan device is registered
after thermal zone device.
Here is the history of why current patch looks like this:
https://patchwork.kernel.org/patch/7273041/
CC: #3.18+
Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
Tested-by: Manuel Krause
Tested-by: szegad
Tested-by: prash
Tested-by: amish
Signed-off-by: Zhang Rui
Signed-off-by: Chen Yu
---
drivers/thermal/thermal_core.c | 14 +-
include/linux/thermal.h| 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index abeb995..f36d0bd 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1341,6 +1341,7 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
if (!result) {
list_add_tail(>tz_node, >thermal_instances);
list_add_tail(>cdev_node, >thermal_instances);
+ atomic_set(>need_update, 1);
}
mutex_unlock(>lock);
mutex_unlock(>lock);
@@ -1450,6 +1451,7 @@ __thermal_cooling_device_register(struct device_node *np,
const struct thermal_cooling_device_ops *ops)
{
struct thermal_cooling_device *cdev;
+ struct thermal_zone_device *pos = NULL;
int result;
if (type && strlen(type) >= THERMAL_NAME_LENGTH)
@@ -1494,6 +1496,12 @@ __thermal_cooling_device_register(struct device_node *np,
/* Update binding information for 'this' new cdev */
bind_cdev(cdev);
+ mutex_lock(_list_lock);
+ list_for_each_entry(pos, _tz_list, node)
+ if (atomic_cmpxchg(>need_update, 1, 0))
+ thermal_zone_device_update(pos);
+ mutex_unlock(_list_lock);
+
return cdev;
}
@@ -1826,6 +1834,8 @@ struct thermal_zone_device
*thermal_zone_device_register(const char *type,
tz->trips = trips;
tz->passive_delay = passive_delay;
tz->polling_delay = polling_delay;
+ /* A new thermal zone needs to be updated anyway. */
+ atomic_set(>need_update, 1);
dev_set_name(>device, "thermal_zone%d", tz->id);
result = device_register(>device);
@@ -1921,7 +1931,9 @@ struct thermal_zone_device
*thermal_zone_device_register(const char *type,
INIT_DELAYED_WORK(&(tz->poll_queue), thermal_zone_device_check);
thermal_zone_device_reset(tz);
- thermal_zone_device_update(tz);
+ /* Update the new thermal zone and mark it as already updated. */
+ if (atomic_cmpxchg(>need_update, 1, 0))
+ thermal_zone_device_update(tz);
return tz;
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 5bcabc7..4298418 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -195,6 +195,7 @@ struct thermal_zone_device {
int emul_temperature;
int passive;
unsigned int forced_passive;
+ atomic_t need_update;
struct thermal_zone_device_ops *ops;
struct thermal_zone_params *tzp;
struct thermal_governor *governor;
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3][v2] Thermal: initialize thermal zone device correctly
From: Zhang Rui
After thermal zone device registered, as we have not read any
temperature before, thus tz->temperature should not be 0,
which actually means 0C, and thermal trend is not available.
In this case, we need specially handling for the first
thermal_zone_device_update().
Both thermal core framework and step_wise governor is
enhanced to handle this. And since the step_wise governor
is the only one that uses trends, so it's the only thermal
governor that needs to be updated.
CC: #3.18+
Tested-by: Manuel Krause
Tested-by: szegad
Tested-by: prash
Tested-by: amish
Tested-by: Matthias
Reviewed-by: Javi Merino
Signed-off-by: Zhang Rui
Signed-off-by: Chen Yu
---
drivers/thermal/step_wise.c| 17 +++--
drivers/thermal/thermal_core.c | 19 +--
drivers/thermal/thermal_core.h | 1 +
include/linux/thermal.h| 3 +++
4 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 2f9f708..ea9366a 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -63,6 +63,19 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
next_target = instance->target;
dev_dbg(>device, "cur_state=%ld\n", cur_state);
+ if (!instance->initialized) {
+ if (throttle) {
+ next_target = (cur_state + 1) >= instance->upper ?
+ instance->upper :
+ ((cur_state + 1) < instance->lower ?
+ instance->lower : (cur_state + 1));
+ } else {
+ next_target = THERMAL_NO_TARGET;
+ }
+
+ return next_target;
+ }
+
switch (trend) {
case THERMAL_TREND_RAISING:
if (throttle) {
@@ -149,7 +162,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
dev_dbg(>cdev->device, "old_target=%d, target=%d\n",
old_target, (int)instance->target);
- if (old_target == instance->target)
+ if (instance->initialized && old_target == instance->target)
continue;
/* Activate a passive thermal instance */
@@ -161,7 +174,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
instance->target == THERMAL_NO_TARGET)
update_passive_instance(tz, trip_type, -1);
-
+ instance->initialized = true;
instance->cdev->updated = false; /* cdev needs update */
}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index d9e525c..682bc1e 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -532,8 +532,22 @@ static void update_temperature(struct thermal_zone_device
*tz)
mutex_unlock(>lock);
trace_thermal_temperature(tz);
- dev_dbg(>device, "last_temperature=%d, current_temperature=%d\n",
- tz->last_temperature, tz->temperature);
+ if (tz->last_temperature == THERMAL_TEMP_INVALID)
+ dev_dbg(>device, "last_temperature N/A,
current_temperature=%d\n",
+ tz->temperature);
+ else
+ dev_dbg(>device, "last_temperature=%d,
current_temperature=%d\n",
+ tz->last_temperature, tz->temperature);
+}
+
+static void thermal_zone_device_reset(struct thermal_zone_device *tz)
+{
+ struct thermal_instance *pos;
+
+ tz->temperature = THERMAL_TEMP_INVALID;
+ tz->passive = 0;
+ list_for_each_entry(pos, >thermal_instances, tz_node)
+ pos->initialized = false;
}
void thermal_zone_device_update(struct thermal_zone_device *tz)
@@ -1900,6 +1914,7 @@ struct thermal_zone_device
*thermal_zone_device_register(const char *type,
INIT_DELAYED_WORK(&(tz->poll_queue), thermal_zone_device_check);
+ thermal_zone_device_reset(tz);
thermal_zone_device_update(tz);
return tz;
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index d7ac1fc..749d41a 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -41,6 +41,7 @@ struct thermal_instance {
struct thermal_zone_device *tz;
struct thermal_cooling_device *cdev;
int trip;
+ bool initialized;
unsigned long upper;/* Highest cooling state for this trip point */
unsigned long lower;/* Lowest cooling state for this trip point */
unsigned long target; /* expected cooling state */
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 157d366..5bcabc7 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -43,6 +43,9 @@
/* Default weight of a bound cooling device */
#define
[PATCH 0/3][v2] Fix thermal problems during suspend/bootup
This patch set fixes two problems when system is trying to suspend and boot up: 1.After system is woken up from suspend, the thermal framework uses the dirty 'cached' thermal variables before suspend, which might cause expected behavior. 2.If a cooling device is registered after the thermal zone's registration, current thermal framework forgets to update the thermal_zone's status, which might bring expected behavior under special cases. Chen Yu (3): Thermal: initialize thermal zone device correctly Thermal: handle thermal zone device properly during system sleep Thermal: do thermal zone update after a cooling device registered drivers/thermal/step_wise.c| 17 +++-- drivers/thermal/thermal_core.c | 78 +++--- drivers/thermal/thermal_core.h | 1 + include/linux/thermal.h| 4 +++ 4 files changed, 94 insertions(+), 6 deletions(-) -- 1.8.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node
On Mon, Oct 26, 2015 at 03:48:44AM +0100, Rafael J. Wysocki wrote: > On Mon, Oct 26, 2015 at 1:13 AM, Mark Brown wrote: > > Should we try to schedule an ad-hoc session today (Monday) for those of > > us who are here to talk this over? > I won't mind doing that, what about after the Linus+Dirk session? It's looking hard to round people up... I asked Ted for a slot tomorrow, hopefully we can get one and if not it's probably going to be easier to find everyone at once. signature.asc Description: PGP signature
[PATCH] uwb: uwbd() is not freezable kthread
From: Jiri Kosina
uwbd() calls try_to_freeze(), but the thread doesn't mark itself freezable
through set_freezable(), so the try_to_freeze() call is useless.
Signed-off-by: Jiri Kosina
---
drivers/uwb/uwbd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/uwb/uwbd.c b/drivers/uwb/uwbd.c
index bdcb13c..01c20a2 100644
--- a/drivers/uwb/uwbd.c
+++ b/drivers/uwb/uwbd.c
@@ -279,7 +279,6 @@ static int uwbd(void *param)
HZ);
if (should_stop)
break;
- try_to_freeze();
spin_lock_irqsave(>uwbd.event_list_lock, flags);
if (!list_empty(>uwbd.event_list)) {
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI/PAD: power_saving_thread() is not freezable
From: Jiri Kosina
power_saving_thread() calls try_to_freeze(), but the thread doesn't mark
itself freezable through set_freezable(), so the try_to_freeze()
call is useless.
Signed-off-by: Jiri Kosina
---
drivers/acpi/acpi_pad.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index ae307ff..8ea8211 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -148,8 +148,6 @@ static int power_saving_thread(void *data)
while (!kthread_should_stop()) {
unsigned long expire_time;
- try_to_freeze();
-
/* round robin to cpus */
expire_time = last_jiffies + round_robin_time * HZ;
if (time_before(expire_time, jiffies)) {
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 cgroup/for-4.4 3/3] cgroup: replace unified-hierarchy.txt with a proper cgroup v2 documentation
On 2015/10/23 9:19, Tejun Heo wrote: From 10d158783de74ad28454ff54556abf89bd85c756 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 23 Oct 2015 10:13:35 +0900 Now that cgroup v2 is almost out of the door, replace the development documentation unified-hierarchy.txt with Documentation/cgroup.txt which is a superset of unified-hierarchy.txt and authoritatively describes all userland-visible aspects of cgroup. v2: Updated to include all information from blkio-controller.txt and list filesystems which support cgroup writeback as suggested by Vivek. Signed-off-by: Tejun Heo Cc: Vivek Goyal --- Documentation/cgroup-legacy/blkio-controller.txt | 79 -- Documentation/cgroup-legacy/unified-hierarchy.txt | 645 -- Documentation/cgroup.txt | 1293 + 3 files changed, 1293 insertions(+), 724 deletions(-) delete mode 100644 Documentation/cgroup-legacy/unified-hierarchy.txt create mode 100644 Documentation/cgroup.txt Looks good to me. For all three patches: Acked-by: Zefan Li -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] block: enable dax for raw block devices
On Mon, Oct 26, 2015 at 6:22 AM, Dave Chinner wrote: > On Thu, Oct 22, 2015 at 11:08:18PM +0200, Jan Kara wrote: >> Ugh2: Now I realized that DAX mmap isn't safe wrt fs freezing even for >> filesystems since there's nothing which writeprotects pages that are >> writeably mapped. In normal path, page writeback does this but that doesn't >> happen for DAX. I remember we once talked about this but it got lost. >> We need something like walk all filesystem inodes during fs freeze and >> writeprotect all pages that are mapped. But that's going to be slow... > > fsync() has the same problem - we have no record of the pages that > need to be committed and then write protected when fsync() is called > after write()... I know Ross is still working on that implementation. However, I had a thought on the flight to ksummit that maybe we shouldn't worry about tracking dirty state on a per-page basis. For small / frequent synchronizations an application really should be using the nvml library [1] to issue cache flushes and pcommit from userspace on a per-cacheline basis. That leaves unmodified apps that want to be correct in the presence of dax mappings. Two things we can do to mitigate that case: 1/ Make DAX mappings opt-in with a new MMAP_DAX (page-cache bypass) flag. Applications shouldn't silently become incorrect simply because the fs is mounted with -o dax. If an app doesn't understand DAX mappings it should get page-cache semantics. This also protects apps that are not expecting DAX semantics on raw block device mappings. 2/ Even if we get a new flag that lets the kernel know the app understands DAX mappings, we shouldn't leave fsync broken. Can we instead get by with a simple / big hammer solution? I.e. on_each_cpu(sync_cache, ...); ...where sync_cache is something like: cache_disable(); wbinvd(); pcommit(); cache_enable(); Disruptive, yes, but if an app cares about efficient persistent memory synchronization fsync is already the wrong api. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node
On Mon, Oct 26, 2015 at 1:13 AM, Mark Brown wrote: > On Sat, Oct 24, 2015 at 03:09:06PM -0500, Rob Herring wrote: > >> Let's get agreement on the flow and structure and how to address other >> issues like suspend, then we can worry about whether this needs to be >> abstracted from subsystems. We can discuss more this week at KS. > > Should we try to schedule an ad-hoc session today (Monday) for those of > us who are here to talk this over? I won't mind doing that, what about after the Linus+Dirk session? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v12 4/6] QE/CPM: move muram management functions to qe_common
On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, October 24, 2015 4:56 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> pau...@samba.org
> Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management functions to
> qe_common
>
> On Fri, 2015-10-23 at 02:45 -0500, Zhao Qiang-B45475 wrote:
> > On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421
> >
> > wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, October 23, 2015 11:10 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > > pau...@samba.org
> > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> functions
> > > to qe_common
> > >
> > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote:
> > > > QE and CPM have the same muram, they use the same management
> > > > functions. Now QE support both ARM and PowerPC, it is necessary to
> > > > move QE to "driver/soc", so move the muram management functions
> > > > from cpm_common to qe_common for preparing to move QE code to
> "driver/soc"
> > > >
> > > > Signed-off-by: Zhao Qiang
> > > > ---
> > > > Changes for v2:
> > > > - no changes
> > > > Changes for v3:
> > > > - no changes
> > > > Changes for v4:
> > > > - no changes
> > > > Changes for v5:
> > > > - no changes
> > > > Changes for v6:
> > > > - using genalloc instead rheap to manage QE MURAM
> > > > - remove qe_reset from platform file, using
> > > > - subsys_initcall to call qe_init function.
> > > > Changes for v7:
> > > > - move this patch from 3/3 to 2/3
> > > > - convert cpm with genalloc
> > > > - check for gen_pool allocation failure Changes for v8:
> > > > - rebase
> > > > - move BD_SC_* macro instead of copy Changes for v9:
> > > > - doesn't modify CPM, add a new patch to modify.
> > > > - rebase
> > > > Changes for v10:
> > > > - rebase
> > > > Changes for v11:
> > > > - remove renaming
> > > > - delete removing qe_reset and delete adding qe_init.
> > > > Changes for v12:
> > > > - SPI_FSL_CPM depends on QE-MURAM, select QUICC_ENGINE for it.
> > >
> > > Why is the SPI change part of this patch? Why is it even part of
> > > this patchset, rather than an independent patch sent to the SPI list
> > > and maintainer? If it's tied to other changes you're making,
> > > explain that. As is, there is zero mention of the SPI change in the
> > > part of the e-mail that will become the git changelog.
> > >
> > This SPI_FSL_CPM is cpm-spi, it is part of CPM.
>
> So then why are you selecting QUICC_ENGINE? And again, what does it have
> to do with this patch?
Cpm-spi is dependent on qe_muram, if not select it, Cpm-spi will failed to
build.
-Zhao
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH v12 6/6] QE: Move QE from arch/powerpc to drivers/soc
On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote: > -Original Message- > From: Wood Scott-B07421 > Sent: Saturday, October 24, 2015 4:56 AM > To: Zhao Qiang-B45475 > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > lau...@codeaurora.org; Xie Xiaobo-R63061 ; > b...@kernel.crashing.org; Li Yang-Leo-R58472 ; > pau...@samba.org > Subject: Re: [PATCH v12 6/6] QE: Move QE from arch/powerpc to drivers/soc > > On Fri, 2015-10-23 at 02:49 -0500, Zhao Qiang-B45475 wrote: > > On Fri, Oct 23, 2015 at 11:20 AM, Wood Scott-B07421 > > > > wrote: > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Friday, October 23, 2015 11:20 AM > > > To: Zhao Qiang-B45475 > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ; > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ; > > > pau...@samba.org > > > Subject: Re: [PATCH v12 6/6] QE: Move QE from arch/powerpc to > > > drivers/soc > > > > > > On Wed, Oct 14, 2015 at 03:16:08PM +0800, Zhao Qiang wrote: > > > > > > > > > > diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig > > > > b/drivers/soc/fsl/qe/Kconfig similarity index 50% copy from > > > > arch/powerpc/sysdev/qe_lib/Kconfig > > > > copy to drivers/soc/fsl/qe/Kconfig index 3c25199..283fe0d 100644 > > > > --- a/arch/powerpc/sysdev/qe_lib/Kconfig > > > > +++ b/drivers/soc/fsl/qe/Kconfig > > > > @@ -2,6 +2,17 @@ > > > > # QE Communication options > > > > # > > > > > > > > +config QUICC_ENGINE > > > > + bool "Freescale QUICC Engine (QE) Support" > > > > + depends on FSL_SOC && PPC32 > > > > + select GENERIC_ALLOCATOR > > > > + select CRC32 > > > > + help > > > > + The QUICC Engine (QE) is a new generation of communications > > > > + coprocessors on Freescale embedded CPUs (akin to CPM in older > > > chips). > > > > + Selecting this option means that you wish to build a kernel > > > > + for a machine with a QE coprocessor. > > > > + > > > > config UCC_SLOW > > > > bool > > > > default y if SERIAL_QE > > > > @@ -19,9 +30,3 @@ config UCC_FAST > > > > config UCC > > > > bool > > > > default y if UCC_FAST || UCC_SLOW > > > > - > > > > -config QE_USB > > > > - bool > > > > - default y if USB_FSL_QE > > > > - help > > > > - QE USB Controller support > > > > > > Why did some config symbols get moved and others not? > > > > Because QE_USB should be putted under drivers/usb, It is independent > > of this patchset. > > If it's independent of this patchset then don't put it in this patchset. > Move all the QE stuff to drivers/soc and then later if something belongs > somewhere else, have a separate patch move it there. Ok -Zhao
Runtime problems since next-20151008 with qemu/beagle boards
Hi all, ever since next-20101008, I am having trouble running beagle board configurations in qemu. Example is multi_v7_defconfig with omap3-beagle devicetree file, or with omap3-beagle-xm. The system just doesn't boot anymore (no kernel log messages). I have tried to bisect twice, but I don't get conclusive results. The latest bisect log (from next-20151022) is below. I tried to bisect into the merge commits; bisect specifically claims that the merge itself is causing the problem, not any of the merged commits. Couple of questions: Has anyone tried next-20151008 or later with above configuration on a real system ? If so, does it work ? If it doesn't work on a real system, any idea what might be wrong in the code ? If it works on a real system, any idea what might cause qemu to hang ? Thanks, Guenter --- # bad: [6dcf94ff0c9e28e5790799e53641dd256745f425] Add linux-next specific files for 20151022 # good: [7379047d5585187d1288486d4627873170d0005a] Linux 4.3-rc6 git bisect start 'HEAD' 'v4.3-rc6' # good: [c3d1cd2b1e542e5ba6a844fd40fa5e62a896cfc2] Merge remote-tracking branch 'block/for-next' git bisect good c3d1cd2b1e542e5ba6a844fd40fa5e62a896cfc2 # good: [c3af8a28f43315fc46753465a4e77e5619dd9f30] staging: IB/hfi1: use TASK_COMM_LEN in hfi1_ctxtdata git bisect good c3af8a28f43315fc46753465a4e77e5619dd9f30 # good: [41783383487fc80d2acdd78fb9133d441371510b] Merge remote-tracking branch 'driver-core/driver-core-next' git bisect good 41783383487fc80d2acdd78fb9133d441371510b # good: [1709035022efcdcf316010592537de205e4e] Merge remote-tracking branch 'target-merge/for-next-merge' git bisect good 1709035022efcdcf316010592537de205e4e # good: [641e7642617127da14e683da8ec690d8404ea83f] rbtree-clarify-documentation-of-rbtree_postorder_for_each_entry_safe-fix git bisect good 641e7642617127da14e683da8ec690d8404ea83f # bad: [a1a15239a59287d6d56cf43e84d3cc878bca828f] Merge remote-tracking branch 'clk/clk-next' git bisect bad a1a15239a59287d6d56cf43e84d3cc878bca828f # good: [87fd47bb754496a1ba005fca022eee1b30b3cee9] Merge remote-tracking branch 'pwm/for-next' git bisect good 87fd47bb754496a1ba005fca022eee1b30b3cee9 # good: [caac0ef8414bfbe296e6617511908ba249f0ab92] Merge tag 'clk-samsung-4.4' of git://linuxtv.org/snawrocki/samsung into clk-next git bisect good caac0ef8414bfbe296e6617511908ba249f0ab92 # good: [67d7188afe23e4b1b82ee6fed35c14387f169f74] Merge branch 'clk-bcm2835' into clk-next git bisect good 67d7188afe23e4b1b82ee6fed35c14387f169f74 # good: [b1a0eeb4f6bbfb63c356578eaf76003faa58f56b] clk: xgene: Remove unused setup.h include git bisect good b1a0eeb4f6bbfb63c356578eaf76003faa58f56b # good: [eae14465de250be75021659789f138a70a553ac5] Merge tag 'tegra-for-4.4-clk' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into clk-next git bisect good eae14465de250be75021659789f138a70a553ac5 # good: [254f9463c5d41a7ac9d35ca24e6c3196814cb890] Merge branch 'clk-shmobile-for-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into clk-next git bisect good 254f9463c5d41a7ac9d35ca24e6c3196814cb890 # good: [1256f10fb26e5824fde12314b5f4690797478678] clk: berlin: bg2: remove CLK_IGNORE_UNUSED flag for sdio clk git bisect good 1256f10fb26e5824fde12314b5f4690797478678 # good: [63243a4da7d0dfa19dcacd0a529782eeb2f86f92] clk: iproc: Fix PLL output frequency calculation git bisect good 63243a4da7d0dfa19dcacd0a529782eeb2f86f92 # first bad commit: [a1a15239a59287d6d56cf43e84d3cc878bca828f] Merge remote-tracking branch 'clk/clk-next' --- Bisect into the merge: # bad: [a1a15239a59287d6d56cf43e84d3cc878bca828f] Merge remote-tracking branch 'clk/clk-next' # good: [87fd47bb754496a1ba005fca022eee1b30b3cee9] Merge remote-tracking branch 'pwm/for-next' git bisect start 'a1a15239a59287d6d56cf43e84d3cc878bca828f' 'a1a15239a59287d6d56cf43e84d3cc878bca828f~1' # good: [caac0ef8414bfbe296e6617511908ba249f0ab92] Merge tag 'clk-samsung-4.4' of git://linuxtv.org/snawrocki/samsung into clk-next git bisect good caac0ef8414bfbe296e6617511908ba249f0ab92 # good: [67d7188afe23e4b1b82ee6fed35c14387f169f74] Merge branch 'clk-bcm2835' into clk-next git bisect good 67d7188afe23e4b1b82ee6fed35c14387f169f74 # good: [b1a0eeb4f6bbfb63c356578eaf76003faa58f56b] clk: xgene: Remove unused setup.h include git bisect good b1a0eeb4f6bbfb63c356578eaf76003faa58f56b # good: [eae14465de250be75021659789f138a70a553ac5] Merge tag 'tegra-for-4.4-clk' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into clk-next git bisect good eae14465de250be75021659789f138a70a553ac5 # good: [254f9463c5d41a7ac9d35ca24e6c3196814cb890] Merge branch 'clk-shmobile-for-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into clk-next git bisect good 254f9463c5d41a7ac9d35ca24e6c3196814cb890 # good: [1256f10fb26e5824fde12314b5f4690797478678] clk: berlin: bg2: remove CLK_IGNORE_UNUSED flag for sdio clk git bisect good 1256f10fb26e5824fde12314b5f4690797478678 # good:
Re: [PATCH v2 01/10] hwmon: (fam15h_power) Refactor attributes for dynamically added
On Sun, Oct 25, 2015 at 07:14:27PM -0700, Guenter Roeck wrote:
> On Mon, Oct 26, 2015 at 09:58:45AM +0800, Huang Rui wrote:
> > On Fri, Oct 23, 2015 at 06:42:20AM -0700, Guenter Roeck wrote:
> > > On 10/19/2015 07:28 PM, Huang Rui wrote:
> > > >Attributes depend on the CPU model the driver gets loaded on.
> > > >Therefore, add those attributes dynamically at init time. This is more
> > > >flexible to control the different attributes on different platforms.
> > > >
> > > >Suggestedy-by: Borislav Petkov
> > > >Signed-off-by: Huang Rui
> > > >Cc: Guenter Roeck
> > > >Cc: Peter Zijlstra
> > > >Cc: Ingo Molnar
> > > >---
> > > > drivers/hwmon/fam15h_power.c | 70
> > > >
> > > > 1 file changed, 45 insertions(+), 25 deletions(-)
> > > >
> > > >diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> > > >index e80ee23..41d022e 100644
> > > >--- a/drivers/hwmon/fam15h_power.c
> > > >+++ b/drivers/hwmon/fam15h_power.c
> > > >@@ -41,12 +41,17 @@ MODULE_LICENSE("GPL");
> > > > #define REG_TDP_RUNNING_AVERAGE0xe0
> > > > #define REG_TDP_LIMIT3 0xe8
> > > >
> > > >+#define FAM15H_MIN_NUM_ATTRS2
> > > >+#define FAM15H_NUM_GROUPS 2
> > > >+
> > > > struct fam15h_power_data {
> > > > struct pci_dev *pdev;
> > > > unsigned int tdp_to_watts;
> > > > unsigned int base_tdp;
> > > > unsigned int processor_pwr_watts;
> > > > unsigned int cpu_pwr_sample_ratio;
> > > >+const struct attribute_group
> > > >*fam15h_power_groups[FAM15H_NUM_GROUPS];
> > > >+struct attribute_group fam15h_power_group;
> > > > };
> > > >
> > > > static ssize_t show_power(struct device *dev,
> > > >@@ -105,29 +110,31 @@ static ssize_t show_power_crit(struct device *dev,
> > > > }
> > > > static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
> > > >
> > > >-static umode_t fam15h_power_is_visible(struct kobject *kobj,
> > > >- struct attribute *attr,
> > > >- int index)
> > > >+static int fam15h_power_init_attrs(struct pci_dev *pdev,
> > > >+ struct fam15h_power_data *data)
> > > > {
> > > >-/* power1_input is only reported for Fam15h, Models 00h-0fh */
> > > >-if (attr == _attr_power1_input.attr &&
> > > >- (boot_cpu_data.x86 != 0x15 || boot_cpu_data.x86_model > 0xf))
> > > >-return 0;
> > > >+int n = FAM15H_MIN_NUM_ATTRS;
> > > >+struct attribute **fam15h_power_attrs;
> > > >
> > > >-return attr->mode;
> > > >-}
> > > >+if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> > > >+n += 1;
> > > >
> > > >-static struct attribute *fam15h_power_attrs[] = {
> > > >-_attr_power1_input.attr,
> > > >-_attr_power1_crit.attr,
> > > >-NULL
> > > >-};
> > > >+fam15h_power_attrs = devm_kcalloc(>dev, n,
> > > >+ sizeof(*fam15h_power_attrs),
> > > >+ GFP_KERNEL);
> > > >
> > > >-static const struct attribute_group fam15h_power_group = {
> > > >-.attrs = fam15h_power_attrs,
> > > >-.is_visible = fam15h_power_is_visible,
> > > >-};
> > > >-__ATTRIBUTE_GROUPS(fam15h_power);
> > > >+if (!fam15h_power_attrs)
> > > >+return -ENOMEM;
> > > >+
> > > >+n = 0;
> > > >+fam15h_power_attrs[n++] = _attr_power1_crit.attr;
> > > >+if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> > > >+fam15h_power_attrs[n++] = _attr_power1_input.attr;
> > > >+
> > > >+data->fam15h_power_group.attrs = fam15h_power_attrs;
> > > >+
> > > >+return 0;
> > > >+}
> > > >
> > > > static bool should_load_on_this_node(struct pci_dev *f4)
> > > > {
> > > >@@ -186,11 +193,12 @@ static int fam15h_power_resume(struct pci_dev
> > > >*pdev)
> > > > #define fam15h_power_resume NULL
> > > > #endif
> > > >
> > > >-static void fam15h_power_init_data(struct pci_dev *f4,
> > > >- struct fam15h_power_data
> > > >*data)
> > > >+static int fam15h_power_init_data(struct pci_dev *f4,
> > > >+ struct fam15h_power_data *data)
> > > > {
> > > > u32 val, eax, ebx, ecx, edx;
> > > > u64 tmp;
> > > >+int ret;
> > > >
> > > > pci_read_config_dword(f4, REG_PROCESSOR_TDP, );
> > > > data->base_tdp = val >> 16;
> > > >@@ -211,11 +219,15 @@ static void fam15h_power_init_data(struct pci_dev
> > > >*f4,
> > > > /* convert to microWatt */
> > > > data->processor_pwr_watts = (tmp * 15625) >> 10;
> > > >
> > > >+ret = fam15h_power_init_attrs(f4, data);
> > > >+if (ret)
> > > >+return ret;
> > > >+
> > > > cpuid(0x8007, , , , );
>
Re: [PATCH v2 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi
On Fri, Oct 23, 2015 at 7:46 AM, Vishnu Patekar
wrote:
> Allwinner A83T is new octa-core cortex-a7 SOC.
> This adds the basic dtsi, the clocks differs from
> earlier sun8i SOCs.
>
> Signed-off-by: Vishnu Patekar
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 247
> ++
> 1 file changed, 247 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun8i-a83t.dtsi
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> new file mode 100644
> index 000..e85995f
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -0,0 +1,247 @@
> + cpu@100 {
> + compatible = "arm,cortex-a7";
> + device_type = "cpu";
> + reg = <4>;
> + };
> +
> + cpu@101 {
> + compatible = "arm,cortex-a7";
> + device_type = "cpu";
> + reg = <5>;
> + };
> + cpu@102 {
> + compatible = "arm,cortex-a7";
> + device_type = "cpu";
> + reg = <6>;
> + };
> +
> + cpu@103 {
> + compatible = "arm,cortex-a7";
> + device_type = "cpu";
> + reg = <7>;
> + };
The reg values are still wrong for the second cluster.
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/10] hwmon: (fam15h_power) Enable power1_input on AMD Carrizo
On Fri, Oct 23, 2015 at 06:45:59AM -0700, Guenter Roeck wrote:
> On 10/19/2015 07:28 PM, Huang Rui wrote:
> >This patch enables power1_input attribute for Carrizo platform.
> >
> >Signed-off-by: Huang Rui
> >Cc: Borislav Petkov
> >Cc: Guenter Roeck
> >Cc: Peter Zijlstra
> >Cc: Ingo Molnar
> >---
> > drivers/hwmon/fam15h_power.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> >index 41d022e..a090adf 100644
> >--- a/drivers/hwmon/fam15h_power.c
> >+++ b/drivers/hwmon/fam15h_power.c
> >@@ -115,8 +115,11 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev,
> > {
> > int n = FAM15H_MIN_NUM_ATTRS;
> > struct attribute **fam15h_power_attrs;
> >+struct cpuinfo_x86 *c = _cpu_data;
> >
> >-if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> >+if (c->x86 == 0x15 &&
> >+((c->x86_model <= 0xf) ||
>
> Please no unnecessary ( ).
>
> >+ (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
>
> Those are acceptable to clarify that the && has precedence on purpose,
> but "(c->x86_model <= 0xf)" is really unnecessary (and inconsistent
> with the rest of the code).
>
OK, I will fixed it on V3. :)
Thanks,
Rui
> > n += 1;
> >
> > fam15h_power_attrs = devm_kcalloc(>dev, n,
> >@@ -128,7 +131,9 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev,
> >
> > n = 0;
> > fam15h_power_attrs[n++] = _attr_power1_crit.attr;
> >-if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> >+if (c->x86 == 0x15 &&
> >+((c->x86_model <= 0xf) ||
> >+ (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
>
> Same here.
>
> > fam15h_power_attrs[n++] = _attr_power1_input.attr;
> >
> > data->fam15h_power_group.attrs = fam15h_power_attrs;
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
On Wed, 2015-10-21 at 12:36 -0700, Paul E. McKenney wrote: > On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote: > > On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote: > > > I am not seeing a sync there, but I really have to defer to the > > > maintainers on this one. I could easily have missed one. > > > > So x86 implies a full barrier for everything that changes the CPL; and > > some form of implied ordering seems a must if you change the privilege > > level unless you tag every single load/store with the priv level at that > > time, which seems the more expensive option. > > And it is entirely possible that there is some similar operation > somewhere in the powerpc entry/exit code. I would not trust myself > to recognize it, though. > > So I suspect the typical implementation will flush all load/stores, > > change the effective priv level and continue. > > > > This can of course be implemented at a pure per CPU ordering (RCpc), > > which would be in line with the rest of Power, in which case you do > > indeed need an explicit sync to make it visible to other CPUs. > > > > But yes, if Michael or Ben could clarify this it would be good. > > :-) ;-) ;-) Sorry guys, these threads are so long I tend not to read them very actively :} Looking at the system call path, the straight line path does not include any barriers. I can't see any hidden in macros either. We also have an explicit sync in the switch_to() path, which suggests that we know system call is not a full barrier. Also looking at the architecture, section 1.5 which talks about the synchronisation that occurs on system calls, defines nothing in terms of memory ordering, and includes a programming note which says "Unlike the Synchronize instruction, a context synchronizing operation does not affect the order in which storage accesses are performed.". Whether that's actually how it's implemented I don't know, I'll see if I can find out. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/10] hwmon: (fam15h_power) Refactor attributes for dynamically added
On Mon, Oct 26, 2015 at 09:58:45AM +0800, Huang Rui wrote:
> On Fri, Oct 23, 2015 at 06:42:20AM -0700, Guenter Roeck wrote:
> > On 10/19/2015 07:28 PM, Huang Rui wrote:
> > >Attributes depend on the CPU model the driver gets loaded on.
> > >Therefore, add those attributes dynamically at init time. This is more
> > >flexible to control the different attributes on different platforms.
> > >
> > >Suggestedy-by: Borislav Petkov
> > >Signed-off-by: Huang Rui
> > >Cc: Guenter Roeck
> > >Cc: Peter Zijlstra
> > >Cc: Ingo Molnar
> > >---
> > > drivers/hwmon/fam15h_power.c | 70
> > >
> > > 1 file changed, 45 insertions(+), 25 deletions(-)
> > >
> > >diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> > >index e80ee23..41d022e 100644
> > >--- a/drivers/hwmon/fam15h_power.c
> > >+++ b/drivers/hwmon/fam15h_power.c
> > >@@ -41,12 +41,17 @@ MODULE_LICENSE("GPL");
> > > #define REG_TDP_RUNNING_AVERAGE 0xe0
> > > #define REG_TDP_LIMIT3 0xe8
> > >
> > >+#define FAM15H_MIN_NUM_ATTRS 2
> > >+#define FAM15H_NUM_GROUPS 2
> > >+
> > > struct fam15h_power_data {
> > > struct pci_dev *pdev;
> > > unsigned int tdp_to_watts;
> > > unsigned int base_tdp;
> > > unsigned int processor_pwr_watts;
> > > unsigned int cpu_pwr_sample_ratio;
> > >+ const struct attribute_group *fam15h_power_groups[FAM15H_NUM_GROUPS];
> > >+ struct attribute_group fam15h_power_group;
> > > };
> > >
> > > static ssize_t show_power(struct device *dev,
> > >@@ -105,29 +110,31 @@ static ssize_t show_power_crit(struct device *dev,
> > > }
> > > static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
> > >
> > >-static umode_t fam15h_power_is_visible(struct kobject *kobj,
> > >- struct attribute *attr,
> > >- int index)
> > >+static int fam15h_power_init_attrs(struct pci_dev *pdev,
> > >+ struct fam15h_power_data *data)
> > > {
> > >- /* power1_input is only reported for Fam15h, Models 00h-0fh */
> > >- if (attr == _attr_power1_input.attr &&
> > >- (boot_cpu_data.x86 != 0x15 || boot_cpu_data.x86_model > 0xf))
> > >- return 0;
> > >+ int n = FAM15H_MIN_NUM_ATTRS;
> > >+ struct attribute **fam15h_power_attrs;
> > >
> > >- return attr->mode;
> > >-}
> > >+ if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> > >+ n += 1;
> > >
> > >-static struct attribute *fam15h_power_attrs[] = {
> > >- _attr_power1_input.attr,
> > >- _attr_power1_crit.attr,
> > >- NULL
> > >-};
> > >+ fam15h_power_attrs = devm_kcalloc(>dev, n,
> > >+sizeof(*fam15h_power_attrs),
> > >+GFP_KERNEL);
> > >
> > >-static const struct attribute_group fam15h_power_group = {
> > >- .attrs = fam15h_power_attrs,
> > >- .is_visible = fam15h_power_is_visible,
> > >-};
> > >-__ATTRIBUTE_GROUPS(fam15h_power);
> > >+ if (!fam15h_power_attrs)
> > >+ return -ENOMEM;
> > >+
> > >+ n = 0;
> > >+ fam15h_power_attrs[n++] = _attr_power1_crit.attr;
> > >+ if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> > >+ fam15h_power_attrs[n++] = _attr_power1_input.attr;
> > >+
> > >+ data->fam15h_power_group.attrs = fam15h_power_attrs;
> > >+
> > >+ return 0;
> > >+}
> > >
> > > static bool should_load_on_this_node(struct pci_dev *f4)
> > > {
> > >@@ -186,11 +193,12 @@ static int fam15h_power_resume(struct pci_dev *pdev)
> > > #define fam15h_power_resume NULL
> > > #endif
> > >
> > >-static void fam15h_power_init_data(struct pci_dev *f4,
> > >- struct fam15h_power_data *data)
> > >+static int fam15h_power_init_data(struct pci_dev *f4,
> > >+struct fam15h_power_data *data)
> > > {
> > > u32 val, eax, ebx, ecx, edx;
> > > u64 tmp;
> > >+ int ret;
> > >
> > > pci_read_config_dword(f4, REG_PROCESSOR_TDP, );
> > > data->base_tdp = val >> 16;
> > >@@ -211,11 +219,15 @@ static void fam15h_power_init_data(struct pci_dev
> > >*f4,
> > > /* convert to microWatt */
> > > data->processor_pwr_watts = (tmp * 15625) >> 10;
> > >
> > >+ ret = fam15h_power_init_attrs(f4, data);
> > >+ if (ret)
> > >+ return ret;
> > >+
> > > cpuid(0x8007, , , , );
> > >
> > > /* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
> > > if (!(edx & BIT(12)))
> > >- return;
> > >+ return 0;
> > >
> > > /*
> > >* determine the ratio of the compute unit power accumulator
> > >@@ -223,14 +235,17 @@ static void fam15h_power_init_data(struct pci_dev
> > >*f4,
> > >* Fn8000_0007:ECX
> > >*/
> > > data->cpu_pwr_sample_ratio = ecx;
> > >+
> > >+ return 0;
> > > }
> > >
> > > static int fam15h_power_probe(struct pci_dev *pdev,
> > >- const struct pci_device_id *id)
> > >+
Re: [PATCH v2 01/10] hwmon: (fam15h_power) Refactor attributes for dynamically added
On Fri, Oct 23, 2015 at 06:42:20AM -0700, Guenter Roeck wrote:
> On 10/19/2015 07:28 PM, Huang Rui wrote:
> >Attributes depend on the CPU model the driver gets loaded on.
> >Therefore, add those attributes dynamically at init time. This is more
> >flexible to control the different attributes on different platforms.
> >
> >Suggestedy-by: Borislav Petkov
> >Signed-off-by: Huang Rui
> >Cc: Guenter Roeck
> >Cc: Peter Zijlstra
> >Cc: Ingo Molnar
> >---
> > drivers/hwmon/fam15h_power.c | 70
> >
> > 1 file changed, 45 insertions(+), 25 deletions(-)
> >
> >diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> >index e80ee23..41d022e 100644
> >--- a/drivers/hwmon/fam15h_power.c
> >+++ b/drivers/hwmon/fam15h_power.c
> >@@ -41,12 +41,17 @@ MODULE_LICENSE("GPL");
> > #define REG_TDP_RUNNING_AVERAGE0xe0
> > #define REG_TDP_LIMIT3 0xe8
> >
> >+#define FAM15H_MIN_NUM_ATTRS2
> >+#define FAM15H_NUM_GROUPS 2
> >+
> > struct fam15h_power_data {
> > struct pci_dev *pdev;
> > unsigned int tdp_to_watts;
> > unsigned int base_tdp;
> > unsigned int processor_pwr_watts;
> > unsigned int cpu_pwr_sample_ratio;
> >+const struct attribute_group *fam15h_power_groups[FAM15H_NUM_GROUPS];
> >+struct attribute_group fam15h_power_group;
> > };
> >
> > static ssize_t show_power(struct device *dev,
> >@@ -105,29 +110,31 @@ static ssize_t show_power_crit(struct device *dev,
> > }
> > static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
> >
> >-static umode_t fam15h_power_is_visible(struct kobject *kobj,
> >- struct attribute *attr,
> >- int index)
> >+static int fam15h_power_init_attrs(struct pci_dev *pdev,
> >+ struct fam15h_power_data *data)
> > {
> >-/* power1_input is only reported for Fam15h, Models 00h-0fh */
> >-if (attr == _attr_power1_input.attr &&
> >- (boot_cpu_data.x86 != 0x15 || boot_cpu_data.x86_model > 0xf))
> >-return 0;
> >+int n = FAM15H_MIN_NUM_ATTRS;
> >+struct attribute **fam15h_power_attrs;
> >
> >-return attr->mode;
> >-}
> >+if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> >+n += 1;
> >
> >-static struct attribute *fam15h_power_attrs[] = {
> >-_attr_power1_input.attr,
> >-_attr_power1_crit.attr,
> >-NULL
> >-};
> >+fam15h_power_attrs = devm_kcalloc(>dev, n,
> >+ sizeof(*fam15h_power_attrs),
> >+ GFP_KERNEL);
> >
> >-static const struct attribute_group fam15h_power_group = {
> >-.attrs = fam15h_power_attrs,
> >-.is_visible = fam15h_power_is_visible,
> >-};
> >-__ATTRIBUTE_GROUPS(fam15h_power);
> >+if (!fam15h_power_attrs)
> >+return -ENOMEM;
> >+
> >+n = 0;
> >+fam15h_power_attrs[n++] = _attr_power1_crit.attr;
> >+if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> >+fam15h_power_attrs[n++] = _attr_power1_input.attr;
> >+
> >+data->fam15h_power_group.attrs = fam15h_power_attrs;
> >+
> >+return 0;
> >+}
> >
> > static bool should_load_on_this_node(struct pci_dev *f4)
> > {
> >@@ -186,11 +193,12 @@ static int fam15h_power_resume(struct pci_dev *pdev)
> > #define fam15h_power_resume NULL
> > #endif
> >
> >-static void fam15h_power_init_data(struct pci_dev *f4,
> >- struct fam15h_power_data *data)
> >+static int fam15h_power_init_data(struct pci_dev *f4,
> >+ struct fam15h_power_data *data)
> > {
> > u32 val, eax, ebx, ecx, edx;
> > u64 tmp;
> >+int ret;
> >
> > pci_read_config_dword(f4, REG_PROCESSOR_TDP, );
> > data->base_tdp = val >> 16;
> >@@ -211,11 +219,15 @@ static void fam15h_power_init_data(struct pci_dev *f4,
> > /* convert to microWatt */
> > data->processor_pwr_watts = (tmp * 15625) >> 10;
> >
> >+ret = fam15h_power_init_attrs(f4, data);
> >+if (ret)
> >+return ret;
> >+
> > cpuid(0x8007, , , , );
> >
> > /* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
> > if (!(edx & BIT(12)))
> >-return;
> >+return 0;
> >
> > /*
> > * determine the ratio of the compute unit power accumulator
> >@@ -223,14 +235,17 @@ static void fam15h_power_init_data(struct pci_dev *f4,
> > * Fn8000_0007:ECX
> > */
> > data->cpu_pwr_sample_ratio = ecx;
> >+
> >+return 0;
> > }
> >
> > static int fam15h_power_probe(struct pci_dev *pdev,
> >-const struct pci_device_id *id)
> >+ const struct pci_device_id *id)
> > {
> > struct fam15h_power_data *data;
> > struct device *dev = >dev;
> > struct device *hwmon_dev;
> >+int ret;
> >
> > /*
> > * though we
Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
On Wed, Oct 21, 2015 at 12:36:38PM -0700, Paul E. McKenney wrote: > On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote: > > On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote: > > > I am not seeing a sync there, but I really have to defer to the > > > maintainers on this one. I could easily have missed one. > > > > So x86 implies a full barrier for everything that changes the CPL; and > > some form of implied ordering seems a must if you change the privilege > > level unless you tag every single load/store with the priv level at that > > time, which seems the more expensive option. > > And it is entirely possible that there is some similar operation > somewhere in the powerpc entry/exit code. I would not trust myself > to recognize it, though. > > > So I suspect the typical implementation will flush all load/stores, > > change the effective priv level and continue. > > > > This can of course be implemented at a pure per CPU ordering (RCpc), > > which would be in line with the rest of Power, in which case you do > > indeed need an explicit sync to make it visible to other CPUs. > > > > But yes, if Michael or Ben could clarify this it would be good. > > Michael and Ben, ping for this, thank you ;-) Regards, Boqun > > Back then I talked to Ralf about what MIPS says on this, and MIPS arch > > spec is entirely quiet on this, it allows implementations full freedom > > IIRC. > > :-) ;-) ;-) > > > > > Thanx, Paul > signature.asc Description: PGP signature
Re: [PATCH v3 3/4] soc: qcom: smd: Use __ioread32_copy() instead of open-coding it
On Fri, Oct 23, 2015 at 01:01:51PM -0700, Stephen Boyd wrote: > Now that we have a generic library function for this, replace the > open-coded instance. > > Cc: Bjorn Andersson > Signed-off-by: Stephen Boyd > --- Acked-by: Andy Gross -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting for events
Hi Yu, On Mon, Oct 26, 2015 at 01:33:10AM +, Chen, Yu C wrote: > Hi, Fengguang, > I've forgotten to add --thread-shallow when doing git format-patch, thanks! Never mind, --thread-shallow helps but won't be unnecessary. I'll improve the patchset detection logic. Thanks, Fengguang > > -Original Message- > > From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm- > > ow...@vger.kernel.org] On Behalf Of Fengguang Wu > > Sent: Monday, October 26, 2015 9:22 AM > > To: Chen, Yu C > > Cc: kbuild-...@01.org; r...@rjwysocki.net; l...@kernel.org; Zhang, Rui; > > Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > > p...@vger.kernel.org; sta...@vger.kernel.org; Li, Philip > > Subject: Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting for events > > > > On Sun, Oct 25, 2015 at 10:08:29AM +0800, Chen, Yu C wrote: > > > This should not be a valid warning IMO, because PATCH 2/3 is based on > > > PATCH 1/3, and the warning of implicit declaration is defined in PATCH > > > 1/3. > > > > Yes sorry, the robot treats the patchset as 3 independent patches: > > > > 2754 N L Oct 25 Chen Yu ( 34:0) [PATCH 2/3][v2] ACPI: Using > > correct irq > > when waiting for events > > 2756 N L Oct 25 Chen Yu ( 52:0) [PATCH 3/3][v2] ACPI / PM: Fix > > incorrect > > wakeup irq setting before suspend-to-idle > > 2757 N L Oct 25 Chen Yu ( 75:0) [PATCH 1/3][v2] ACPI: Using > > correct irq > > when uninstalling acpi irq handler > > > > And the root cause is, the 3 patches are likely sent one by one _out of > > order_. > > And there is no in-reply-to field to help reorder them into a logical > > patchset. > > > > Thanks, > > Fengguang > > > > > > -Original Message- > > > > From: lkp > > > > Sent: Sunday, October 25, 2015 1:19 AM > > > > To: Chen, Yu C > > > > Cc: kbuild-...@01.org; r...@rjwysocki.net; l...@kernel.org; Zhang, > > > > Rui; Zheng, Lv; linux-a...@vger.kernel.org; > > > > linux-kernel@vger.kernel.org; linux- p...@vger.kernel.org; Chen, Yu C; > > > > sta...@vger.kernel.org > > > > Subject: Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting > > > > for events > > > > > > > > Hi Chen, > > > > > > > > [auto build test ERROR on pm/linux-next -- if it's inappropriate > > > > base, please suggest rules for selecting the more suitable base] > > > > > > > > url:https://github.com/0day-ci/linux/commits/Chen-Yu/ACPI-Using- > > > > correct-irq-when-waiting-for-events/20151025-010210 > > > > config: x86_64-randconfig-x015-201543 (attached as .config) > > > > reproduce: > > > > # save the attached .config to linux build tree > > > > make ARCH=x86_64 > > > > > > > > All error/warnings (new ones prefixed by >>): > > > > > > > >In file included from include/uapi/linux/stddef.h:1:0, > > > > from include/linux/stddef.h:4, > > > > from include/uapi/linux/posix_types.h:4, > > > > from include/uapi/linux/types.h:13, > > > > from include/linux/types.h:5, > > > > from include/linux/list.h:4, > > > > from include/linux/module.h:9, > > > > from drivers/acpi/osl.c:26: > > > >drivers/acpi/osl.c: In function 'acpi_os_wait_events_complete': > > > > >> drivers/acpi/osl.c:1183:6: error: implicit declaration of > > > > >> function > > > > 'acpi_sci_irq_valid' [-Werror=implicit-function-declaration] > > > > if (acpi_sci_irq_valid()) > > > > ^ > > > >include/linux/compiler.h:147:28: note: in definition of macro > > > > '__trace_if' > > > > if (__builtin_constant_p((cond)) ? !!(cond) : \ > > > >^ > > > > >> drivers/acpi/osl.c:1183:2: note: in expansion of macro 'if' > > > > if (acpi_sci_irq_valid()) > > > > ^ > > > > >> drivers/acpi/osl.c:1184:23: error: 'acpi_sci_irq' undeclared > > > > >> (first use in this > > > > function) > > > > synchronize_hardirq(acpi_sci_irq); > > > > ^ > > > >drivers/acpi/osl.c:1184:23: note: each undec
Re: [PATCH net-next 2/3] bpf: introduce bpf_perf_event_output() helper
On 2015/10/24 1:25, Alexei Starovoitov wrote:
On 10/23/15 9:42 AM, Peter Zijlstra wrote:
On Fri, Oct 23, 2015 at 08:02:00AM -0700, Alexei Starovoitov wrote:
On 10/23/15 7:39 AM, Peter Zijlstra wrote:
On Tue, Oct 20, 2015 at 08:02:34PM -0700, Alexei Starovoitov wrote:
+static const struct bpf_func_proto bpf_perf_event_output_proto = {
+.func= bpf_perf_event_output,
+.gpl_only= false,
Oh ?
no particular reason. key helper bpf_probe_read() is gpl, so all
bpf for tracing progs have to be gpl.
If you feel strongly about it, I can change it.
All the perf symbols are export GPL, so I suppose this should be true.
ok. will send a patch.
Can we (or have we already) setup some rules for licensing? Which part
should be GPL? Who has the response to decide it?
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3][v2] ACPI: Using correct irq when waiting for events
Hi, Fengguang,
I've forgotten to add --thread-shallow when doing git format-patch, thanks!
Best Regards,
Yu
> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Fengguang Wu
> Sent: Monday, October 26, 2015 9:22 AM
> To: Chen, Yu C
> Cc: kbuild-...@01.org; r...@rjwysocki.net; l...@kernel.org; Zhang, Rui;
> Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> p...@vger.kernel.org; sta...@vger.kernel.org; Li, Philip
> Subject: Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting for events
>
> On Sun, Oct 25, 2015 at 10:08:29AM +0800, Chen, Yu C wrote:
> > This should not be a valid warning IMO, because PATCH 2/3 is based on
> > PATCH 1/3, and the warning of implicit declaration is defined in PATCH
> > 1/3.
>
> Yes sorry, the robot treats the patchset as 3 independent patches:
>
> 2754 N L Oct 25 Chen Yu ( 34:0) [PATCH 2/3][v2] ACPI: Using correct
> irq
> when waiting for events
> 2756 N L Oct 25 Chen Yu ( 52:0) [PATCH 3/3][v2] ACPI / PM: Fix
> incorrect
> wakeup irq setting before suspend-to-idle
> 2757 N L Oct 25 Chen Yu ( 75:0) [PATCH 1/3][v2] ACPI: Using correct
> irq
> when uninstalling acpi irq handler
>
> And the root cause is, the 3 patches are likely sent one by one _out of
> order_.
> And there is no in-reply-to field to help reorder them into a logical
> patchset.
>
> Thanks,
> Fengguang
>
> > > -Original Message-
> > > From: lkp
> > > Sent: Sunday, October 25, 2015 1:19 AM
> > > To: Chen, Yu C
> > > Cc: kbuild-...@01.org; r...@rjwysocki.net; l...@kernel.org; Zhang,
> > > Rui; Zheng, Lv; linux-a...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; linux- p...@vger.kernel.org; Chen, Yu C;
> > > sta...@vger.kernel.org
> > > Subject: Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting
> > > for events
> > >
> > > Hi Chen,
> > >
> > > [auto build test ERROR on pm/linux-next -- if it's inappropriate
> > > base, please suggest rules for selecting the more suitable base]
> > >
> > > url:https://github.com/0day-ci/linux/commits/Chen-Yu/ACPI-Using-
> > > correct-irq-when-waiting-for-events/20151025-010210
> > > config: x86_64-randconfig-x015-201543 (attached as .config)
> > > reproduce:
> > > # save the attached .config to linux build tree
> > > make ARCH=x86_64
> > >
> > > All error/warnings (new ones prefixed by >>):
> > >
> > >In file included from include/uapi/linux/stddef.h:1:0,
> > > from include/linux/stddef.h:4,
> > > from include/uapi/linux/posix_types.h:4,
> > > from include/uapi/linux/types.h:13,
> > > from include/linux/types.h:5,
> > > from include/linux/list.h:4,
> > > from include/linux/module.h:9,
> > > from drivers/acpi/osl.c:26:
> > >drivers/acpi/osl.c: In function 'acpi_os_wait_events_complete':
> > > >> drivers/acpi/osl.c:1183:6: error: implicit declaration of
> > > >> function
> > > 'acpi_sci_irq_valid' [-Werror=implicit-function-declaration]
> > > if (acpi_sci_irq_valid())
> > > ^
> > >include/linux/compiler.h:147:28: note: in definition of macro
> > > '__trace_if'
> > > if (__builtin_constant_p((cond)) ? !!(cond) : \
> > >^
> > > >> drivers/acpi/osl.c:1183:2: note: in expansion of macro 'if'
> > > if (acpi_sci_irq_valid())
> > > ^
> > > >> drivers/acpi/osl.c:1184:23: error: 'acpi_sci_irq' undeclared
> > > >> (first use in this
> > > function)
> > > synchronize_hardirq(acpi_sci_irq);
> > > ^
> > >drivers/acpi/osl.c:1184:23: note: each undeclared identifier is
> > > reported only once for each function it appears in
> > >cc1: some warnings being treated as errors
> > >
> > > vim +/acpi_sci_irq_valid +1183 drivers/acpi/osl.c
> > >
> > > 1177void acpi_os_wait_events_complete(void)
> > > 1178{
> > > 1179/*
> > > 1180 * Make sure the GPE handler or the fixed event
> handler is
> > > not used
> > > 1181 * on another CPU after removal.
> > > 1182 */
> > > > 11
[PATCH v2 2/4] x86/signal/64: Fix SS if needed when delivering a 64-bit signal
Signals are always delivered to 64-bit tasks with CS set to a long
mode segment. In long mode, SS doesn't matter, as long as it's a
present writable segment.
If SS starts out invalid (this can happen if the signal was caused
by an IRET fault or was delivered on the way out of set_thread_area
or modify_ldt), then IRET to the signal handler can fail, eventually
killing the task.
The straightforward fix would be to simply reset SS when delivering
a signal. That breaks DOSEMU, though: 64-bit builds of DOSEMU rely
on SS being set to the faulting SS when signals are delivered.
As a compromise, this patch leaves SS alone so long as it's valid.
The net effect should be that the behavior of successfully delivered
signals is unchanged. Some signals that would previously have
failed to be delivered will now be delivered successfully.
This has no effect for x32 or 32-bit tasks: their signal handlers
were already called with SS == __USER_DS.
(On Xen, there's a slight hole: if a task sets SS to a writable
*kernel* data segment, then we will fail to identify it as invalid
and we'll still kill the task. If anyone cares, this could be fixed
with a new paravirt hook.)
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/desc_defs.h | 23 ++
arch/x86/kernel/signal.c | 51 ++--
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/desc_defs.h b/arch/x86/include/asm/desc_defs.h
index 278441f39856..00971705a16d 100644
--- a/arch/x86/include/asm/desc_defs.h
+++ b/arch/x86/include/asm/desc_defs.h
@@ -98,4 +98,27 @@ struct desc_ptr {
#endif /* !__ASSEMBLY__ */
+/* Access rights as returned by LAR */
+#define AR_TYPE_RODATA (0 * (1 << 9))
+#define AR_TYPE_RWDATA (1 * (1 << 9))
+#define AR_TYPE_RODATA_EXPDOWN (2 * (1 << 9))
+#define AR_TYPE_RWDATA_EXPDOWN (3 * (1 << 9))
+#define AR_TYPE_XOCODE (4 * (1 << 9))
+#define AR_TYPE_XRCODE (5 * (1 << 9))
+#define AR_TYPE_XOCODE_CONF(6 * (1 << 9))
+#define AR_TYPE_XRCODE_CONF(7 * (1 << 9))
+#define AR_TYPE_MASK (7 * (1 << 9))
+
+#define AR_DPL0(0 * (1 << 13))
+#define AR_DPL3(3 * (1 << 13))
+#define AR_DPL_MASK(3 * (1 << 13))
+
+#define AR_A (1 << 8)/* A means "accessed" */
+#define AR_S (1 << 12) /* S means "not system" */
+#define AR_P (1 << 15) /* P means "present" */
+#define AR_AVL (1 << 20) /* AVL does nothing */
+#define AR_L (1 << 21) /* L means "long mode" */
+#define AR_DB (1 << 22) /* D or B, depending on type */
+#define AR_G (1 << 23) /* G means "limit in pages" */
+
#endif /* _ASM_X86_DESC_DEFS_H */
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index d87ce92d3404..ca8975096728 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -61,6 +61,35 @@
regs->seg = GET_SEG(seg) | 3; \
} while (0)
+#ifdef CONFIG_X86_64
+/*
+ * If regs->ss will cause an IRET fault, change it. Otherwise leave it
+ * alone. Using this generally makes no sense unless
+ * user_64bit_mode(regs) would return true.
+ */
+static void force_valid_ss(struct pt_regs *regs)
+{
+ u32 ar;
+ asm volatile ("lar %[old_ss], %[ar]\n\t"
+ "jz 1f\n\t" /* If invalid: */
+ "xorl %[ar], %[ar]\n\t" /* set ar = 0 */
+ "1:"
+ : [ar] "=r" (ar)
+ : [old_ss] "rm" ((u16)regs->ss));
+
+ /*
+* For a valid 64-bit user context, we need DPL 3, type
+* read-write data or read-write exp-down data, and S and P
+* set. We can't use VERW because VERW doesn't check the
+* P bit.
+*/
+ ar &= AR_DPL_MASK | AR_S | AR_P | AR_TYPE_MASK;
+ if (ar != (AR_DPL3 | AR_S | AR_P | AR_TYPE_RWDATA) &&
+ ar != (AR_DPL3 | AR_S | AR_P | AR_TYPE_RWDATA_EXPDOWN))
+ regs->ss = __USER_DS;
+}
+#endif
+
int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc)
{
void __user *buf;
@@ -457,10 +486,28 @@ static int __setup_rt_frame(int sig, struct ksignal *ksig,
regs->sp = (unsigned long)frame;
- /* Set up the CS register to run signal handlers in 64-bit mode,
- even if the handler happens to be interrupting 32-bit code. */
+ /*
+* Set up the CS and SS registers to run signal handlers in
+* 64-bit mode, even if the handler happens to be interrupting
+* 32-bit or 16-bit code.
+*
+* SS is subtle. In 64-bit mode, we don't need any particular
+* SS descriptor, but we do need SS to be valid. It's possible
+* that the old SS is entirely bogus -- this can happen if the
+* signal we're trying to
Re: [PATCH 1/2] can: xilinx: use readl/writel instead of ioread/iowrite
On Sunday 25 October 2015, Marc Kleine-Budde wrote: > On 10/22/2015 10:58 AM, Arnd Bergmann wrote: > >>> The two should really do the same thing: iowrite32() is just a static > >>> inline > >>> calling writel() on both ARM32 and ARM64. On which kernel version did you > >>> observe the difference? It's possible that an older version used > >>> CONFIG_GENERIC_IOMAP, which made this slightly more expensive. > >>> > >>> If there are barriers that you want to get rid of for performance reasons, > >>> you should use writel_relaxed(), but be careful to synchronize them > >>> correctly > >>> with regard to DMA. It should be fine in this driver, as it does not > >>> perform any DMA, but be aware that there is no big-endian version of > >>> writel_relaxed() at the moment. > >> > >> We don't have DMA in CAN drivers, but usually a certain write triggers > >> sending. Do we need a barrier before triggering the sending? > > > > No, the relaxed writes are not well-defined across architectures. On > > ARM, the CPU guarantees that stores to an MMIO area are still in order > > with respect to one another, the barrier is only needed for actual DMA, > > so you are fine. I would expect the same to be true everywhere, > > otherwise a lot of other drivers would be broken too. > > And the relaxed functions seem not to be available on all archs. This > driver should work on microblaze. Are __raw_writeX(), __raw_readX() an > alternative here? __raw_writeX() and __raw_readX() are not safe to use in drivers in general. readl_relaxed() should work on all architectures nowadays, and I've checked that it does on microblaze. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context
This is a second attempt to make the improvements from c6f2062935c8
("x86/signal/64: Fix SS handling for signals delivered to 64-bit
programs"), which was reverted by 51adbfbba5c6 ("x86/signal/64: Add
support for SS in the 64-bit signal context").
This adds two new uc_flags flags. UC_SIGCONTEXT_SS will be set for
all 64-bit signals (including x32). It indicates that the saved SS
field is valid and that the kernel supports the new behavior.
The goal is to fix a problems with signal handling in 64-bit tasks:
SS wasn't saved in the 64-bit signal context, making it awkward to
determine what SS was at the time of signal delivery and making it
impossible to return to a non-flat SS (as calling sigreturn clobbers
SS).
This also made it extremely difficult for 64-bit tasks to return to
fully-defined 16-bit contexts, because only the kernel can easily do
espfix64, but sigreturn was unable to load or even restore SS:ESP.
(DOSEMU has a monstrous hack to partially work around this.)
If we could go back in time, the correct fix would be to make 64-bit
signals work just like 32-bit signals with respect to SS: save it
in signal context, reset it when delivering a signal, and restore
it in sigreturn.
Unfortunately, doing that (as I tried originally) breaks DOSEMU:
DOSEMU wouldn't reset the signal context's SS when clearing the LDT
and changing the saved CS to 64-bit mode, since it predates the SS
context field existing in the first place.
This patch is a bit more complicated, and it tries to balance a
bunch of goals. It makes signal delivery due to a bogus SS reliable
without having to set any flags (64-bit signals will always be
delivered to a valid SS), and it makes most cases of changing
ucontext->ss during signal handling work as expected.
I do this by special-casing the interesting case. On sigreturn,
ucontext->ss will be honored by default, unless the ucontext was
created from scratch by an old program and had a 64-bit CS
(unfortunately, CRIU can do this) or was the result of changing a
32-bit signal context to 64-bit without resetting SS (as DOSEMU
does).
For the benefit of new 64-bit software that uses segmentation (new
versions of DOSEMU might), the new behavior can be detected with a
new ucontext flag UC_SIGCONTEXT_SS.
To avoid compilation issues, __pad0 is left as an alias for ss in
ucontext.
The nitty-gritty details are documented in the header file.
Cc: Stas Sergeev
Cc: Linus Torvalds
Cc: Cyrill Gorcunov
Cc: Pavel Emelyanov
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/sigcontext.h | 2 +-
arch/x86/include/asm/sighandling.h | 1 -
arch/x86/include/uapi/asm/sigcontext.h | 5 ++-
arch/x86/include/uapi/asm/ucontext.h | 43 ---
arch/x86/kernel/signal.c | 63 --
tools/testing/selftests/x86/Makefile | 4 +--
6 files changed, 89 insertions(+), 29 deletions(-)
diff --git a/arch/x86/include/asm/sigcontext.h
b/arch/x86/include/asm/sigcontext.h
index 9dfce4e0417d..9789402b99b6 100644
--- a/arch/x86/include/asm/sigcontext.h
+++ b/arch/x86/include/asm/sigcontext.h
@@ -59,7 +59,7 @@ struct sigcontext {
unsigned short cs;
unsigned short gs;
unsigned short fs;
- unsigned short __pad0;
+ unsigned short ss; /* Only restored if UC_RESTORE_SS is set. */
unsigned long err;
unsigned long trapno;
unsigned long oldmask;
diff --git a/arch/x86/include/asm/sighandling.h
b/arch/x86/include/asm/sighandling.h
index 89db46752a8f..452c88b8ad06 100644
--- a/arch/x86/include/asm/sighandling.h
+++ b/arch/x86/include/asm/sighandling.h
@@ -13,7 +13,6 @@
X86_EFLAGS_CF | X86_EFLAGS_RF)
void signal_fault(struct pt_regs *regs, void __user *frame, char *where);
-int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc);
int setup_sigcontext(struct sigcontext __user *sc, void __user *fpstate,
struct pt_regs *regs, unsigned long mask);
diff --git a/arch/x86/include/uapi/asm/sigcontext.h
b/arch/x86/include/uapi/asm/sigcontext.h
index 827c6ed0e26a..ad02ae519179 100644
--- a/arch/x86/include/uapi/asm/sigcontext.h
+++ b/arch/x86/include/uapi/asm/sigcontext.h
@@ -197,7 +197,10 @@ struct sigcontext {
*/
__u16 gs;
__u16 fs;
- __u16 __pad0;
+ union {
+ __u16 ss; /* If UC_SAVED_SS */
+ __u16 __pad0; /* If !UC_SAVED_SS */
+ };
__u64 err;
__u64 trapno;
__u64 oldmask;
diff --git a/arch/x86/include/uapi/asm/ucontext.h
b/arch/x86/include/uapi/asm/ucontext.h
index b7c29c8017f2..a5c1718ce65b 100644
--- a/arch/x86/include/uapi/asm/ucontext.h
+++ b/arch/x86/include/uapi/asm/ucontext.h
@@ -1,11 +1,44 @@
#ifndef _ASM_X86_UCONTEXT_H
#define _ASM_X86_UCONTEXT_H
-#define UC_FP_XSTATE 0x1 /* indicates the presence of extended state
-* information in the memory layout pointed
-
[PATCH v2 1/4] x86/signal/64: Add a comment about sigcontext->fs and gs
These fields have a strange history. This tries to document it.
This borrows from 9a036b93a344 ("x86/signal/64: Remove 'fs' and 'gs'
from sigcontext"), which was reverted by ed596cde9425 ("Revert x86
sigcontext cleanups").
Signed-off-by: Andy Lutomirski
---
arch/x86/include/uapi/asm/sigcontext.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/include/uapi/asm/sigcontext.h
b/arch/x86/include/uapi/asm/sigcontext.h
index 40836a9a7250..827c6ed0e26a 100644
--- a/arch/x86/include/uapi/asm/sigcontext.h
+++ b/arch/x86/include/uapi/asm/sigcontext.h
@@ -177,6 +177,24 @@ struct sigcontext {
__u64 rip;
__u64 eflags; /* RFLAGS */
__u16 cs;
+
+ /*
+* Prior to 2.5.64 ("[PATCH] x86-64 updates for 2.5.64-bk3"),
+* Linux saved and restored fs and gs in these slots. This
+* was counterproductive, as fsbase and gsbase were never
+* saved, so arch_prctl was presumably unreliable.
+*
+* If these slots are ever needed for any other purpose, there
+* is some risk that very old 64-bit binaries could get
+* confused. I doubt that many such binaries still work,
+* though, since the same patch in 2.5.64 also removed the
+* 64-bit set_thread_area syscall, so it appears that there is
+* no TLS API that works in both pre- and post-2.5.64 kernels.
+*
+* There is at least one additional concern if these slots are
+* recycled for another purpose: some DOSEMU versions stash fs
+* and gs in these slots manually.
+*/
__u16 gs;
__u16 fs;
__u16 __pad0;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] x86: sigcontext fixes, again
This is take 2 at fixing x86 64-bit signals wrt SS. After a lot of thought, this is not controlled by any flags -- I would much prefer to avoid opt-in behavior. Instead, it just tries hard to avoid triggering the cases that break DOSEMU. Stas, this now seems to pass the test you sent me. It works with stock dosemu2 (I haven't tested classic dosemu because I can't get it to work regardless). It also works with a patched dosemu2 that bypasses the userspace trampoline: https://github.com/amluto/dosemu2/commit/571b4d08dc885b7a133e444a2ad23e0d21366206 With this applied, all of the x86 selftests pass on x86_64. That wasn't the case before -- ldt_gdt_64 was broken. This is a bit risky, and another option would be to do nothing at all. Then we'd disable the problematic self-tests (sigh), and DOSEMU and similar tools will be stuck using gross hacks even on new kernels. Changes from v1: - Comment fixes - Fix screwed up uaccess that broke things Andy Lutomirski (4): x86/signal/64: Add a comment about sigcontext->fs and gs x86/signal/64: Fix SS if needed when delivering a 64-bit signal x86/signal/64: Re-add support for SS in the 64-bit signal context selftests/x86: Add tests for UC_SIGCONTEXT_SS and UC_STRICT_RESTORE_SS arch/x86/include/asm/desc_defs.h| 23 +++ arch/x86/include/asm/sigcontext.h | 2 +- arch/x86/include/asm/sighandling.h | 1 - arch/x86/include/uapi/asm/sigcontext.h | 23 ++- arch/x86/include/uapi/asm/ucontext.h| 43 +- arch/x86/kernel/signal.c| 114 --- tools/testing/selftests/x86/Makefile| 4 +- tools/testing/selftests/x86/sigreturn.c | 240 8 files changed, 391 insertions(+), 59 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] selftests/x86: Add tests for UC_SIGCONTEXT_SS and UC_STRICT_RESTORE_SS
This tests the two ABI-preserving cases that DOSEMU cares about, and
it also explicitly tests the new UC_SIGCONTEXT_SS and
UC_STRICT_RESTORE_SS flags.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/sigreturn.c | 240
1 file changed, 212 insertions(+), 28 deletions(-)
diff --git a/tools/testing/selftests/x86/sigreturn.c
b/tools/testing/selftests/x86/sigreturn.c
index b5aa1bab7416..43e840470e32 100644
--- a/tools/testing/selftests/x86/sigreturn.c
+++ b/tools/testing/selftests/x86/sigreturn.c
@@ -55,6 +55,47 @@
#include
/*
+ * Copied from asm/ucontext.h, as asm/ucontext.h conflicts badly with the glibc
+ * headers.
+ */
+#ifdef __x86_64__
+/*
+ * UC_SAVED_SS will be set when delivering 64-bit or x32 signals on
+ * kernels that save SS in the sigcontext. Kernels that set UC_SAVED_SS
+ * allow signal handlers to set UC_RESTORE_SS; if UC_RESTORE_SS is set,
+ * then sigreturn will restore SS.
+ *
+ * For compatibility with old programs, the kernel will *not* set
+ * UC_RESTORE_SS when delivering signals.
+ */
+#define UC_SIGCONTEXT_SS 0x2
+#define UC_STRICT_RESTORE_SS 0x4
+#endif
+
+/* Access rights as returned by LAR */
+#define AR_TYPE_RODATA (0 * (1 << 9))
+#define AR_TYPE_RWDATA (1 * (1 << 9))
+#define AR_TYPE_RODATA_EXPDOWN (2 * (1 << 9))
+#define AR_TYPE_RWDATA_EXPDOWN (3 * (1 << 9))
+#define AR_TYPE_XOCODE (4 * (1 << 9))
+#define AR_TYPE_XRCODE (5 * (1 << 9))
+#define AR_TYPE_XOCODE_CONF(6 * (1 << 9))
+#define AR_TYPE_XRCODE_CONF(7 * (1 << 9))
+#define AR_TYPE_MASK (7 * (1 << 9))
+
+#define AR_DPL0(0 * (1 << 13))
+#define AR_DPL3(3 * (1 << 13))
+#define AR_DPL_MASK(3 * (1 << 13))
+
+#define AR_A (1 << 8)/* A means "accessed" */
+#define AR_S (1 << 12) /* S means "not system" */
+#define AR_P (1 << 15) /* P means "present" */
+#define AR_AVL (1 << 20) /* AVL does nothing */
+#define AR_L (1 << 21) /* L means "long mode" */
+#define AR_DB (1 << 22) /* D or B, depending on type */
+#define AR_G (1 << 23) /* G means "limit in pages" */
+
+/*
* In principle, this test can run on Linux emulation layers (e.g.
* Illumos "LX branded zones"). Solaris-based kernels reserve LDT
* entries 0-5 for their own internal purposes, so start our LDT
@@ -267,6 +308,9 @@ static gregset_t initial_regs, requested_regs,
resulting_regs;
/* Instructions for the SIGUSR1 handler. */
static volatile unsigned short sig_cs, sig_ss;
static volatile sig_atomic_t sig_trapped, sig_err, sig_trapno;
+#ifdef __x86_64__
+static volatile sig_atomic_t sig_corrupt_final_ss;
+#endif
/* Abstractions for some 32-bit vs 64-bit differences. */
#ifdef __x86_64__
@@ -305,9 +349,105 @@ static greg_t *csptr(ucontext_t *ctx)
}
#endif
+/*
+ * Checks a given selector for its code bitness or returns -1 if it's not
+ * a usable code segment selector.
+ */
+int cs_bitness(unsigned short cs)
+{
+ uint32_t valid = 0, ar;
+ asm ("lar %[cs], %[ar]\n\t"
+"jnz 1f\n\t"
+"mov $1, %[valid]\n\t"
+"1:"
+: [ar] "=r" (ar), [valid] "+rm" (valid)
+: [cs] "r" (cs));
+
+ if (!valid)
+ return -1;
+
+ bool db = (ar & (1 << 22));
+ bool l = (ar & (1 << 21));
+
+ if (!(ar & (1<<11)))
+ return -1; /* Not code. */
+
+ if (l && !db)
+ return 64;
+ else if (!l && db)
+ return 32;
+ else if (!l && !db)
+ return 16;
+ else
+ return -1; /* Unknown bitness. */
+}
+
+/*
+ * Checks a given selector for its code bitness or returns -1 if it's not
+ * a usable code segment selector.
+ */
+bool is_valid_ss(unsigned short cs)
+{
+ uint32_t valid = 0, ar;
+ asm ("lar %[cs], %[ar]\n\t"
+"jnz 1f\n\t"
+"mov $1, %[valid]\n\t"
+"1:"
+: [ar] "=r" (ar), [valid] "+rm" (valid)
+: [cs] "r" (cs));
+
+ if (!valid)
+ return false;
+
+ if ((ar & AR_TYPE_MASK) != AR_TYPE_RWDATA &&
+ (ar & AR_TYPE_MASK) != AR_TYPE_RWDATA_EXPDOWN)
+ return false;
+
+ return (ar & AR_P);
+}
+
/* Number of errors in the current test case. */
static volatile sig_atomic_t nerrs;
+static void validate_signal_ss(int sig, ucontext_t *ctx)
+{
+#ifdef __x86_64__
+ bool was_64bit = (cs_bitness(*csptr(ctx)) == 64);
+
+ if (!(ctx->uc_flags & UC_SIGCONTEXT_SS)) {
+ printf("[FAIL]\tUC_SIGCONTEXT_SS was not set\n");
+ nerrs++;
+
+ /*
+* This happens on Linux 4.1. The rest will fail, too, so
+* return now to reduce the noise.
+*/
+ return;
+
Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting for events
On Sun, Oct 25, 2015 at 10:08:29AM +0800, Chen, Yu C wrote:
> This should not be a valid warning IMO,
> because PATCH 2/3 is based on PATCH 1/3,
> and the warning of implicit declaration is defined
> in PATCH 1/3.
Yes sorry, the robot treats the patchset as 3 independent patches:
2754 N L Oct 25 Chen Yu ( 34:0) [PATCH 2/3][v2] ACPI: Using correct
irq when waiting for events
2756 N L Oct 25 Chen Yu ( 52:0) [PATCH 3/3][v2] ACPI / PM: Fix
incorrect wakeup irq setting before suspend-to-idle
2757 N L Oct 25 Chen Yu ( 75:0) [PATCH 1/3][v2] ACPI: Using correct
irq when uninstalling acpi irq handler
And the root cause is, the 3 patches are likely sent one by one
_out of order_. And there is no in-reply-to field to help reorder
them into a logical patchset.
Thanks,
Fengguang
> > -Original Message-
> > From: lkp
> > Sent: Sunday, October 25, 2015 1:19 AM
> > To: Chen, Yu C
> > Cc: kbuild-...@01.org; r...@rjwysocki.net; l...@kernel.org; Zhang, Rui;
> > Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> > p...@vger.kernel.org; Chen, Yu C; sta...@vger.kernel.org
> > Subject: Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting for events
> >
> > Hi Chen,
> >
> > [auto build test ERROR on pm/linux-next -- if it's inappropriate base,
> > please
> > suggest rules for selecting the more suitable base]
> >
> > url:https://github.com/0day-ci/linux/commits/Chen-Yu/ACPI-Using-
> > correct-irq-when-waiting-for-events/20151025-010210
> > config: x86_64-randconfig-x015-201543 (attached as .config)
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=x86_64
> >
> > All error/warnings (new ones prefixed by >>):
> >
> >In file included from include/uapi/linux/stddef.h:1:0,
> > from include/linux/stddef.h:4,
> > from include/uapi/linux/posix_types.h:4,
> > from include/uapi/linux/types.h:13,
> > from include/linux/types.h:5,
> > from include/linux/list.h:4,
> > from include/linux/module.h:9,
> > from drivers/acpi/osl.c:26:
> >drivers/acpi/osl.c: In function 'acpi_os_wait_events_complete':
> > >> drivers/acpi/osl.c:1183:6: error: implicit declaration of function
> > 'acpi_sci_irq_valid' [-Werror=implicit-function-declaration]
> > if (acpi_sci_irq_valid())
> > ^
> >include/linux/compiler.h:147:28: note: in definition of macro
> > '__trace_if'
> > if (__builtin_constant_p((cond)) ? !!(cond) : \
> >^
> > >> drivers/acpi/osl.c:1183:2: note: in expansion of macro 'if'
> > if (acpi_sci_irq_valid())
> > ^
> > >> drivers/acpi/osl.c:1184:23: error: 'acpi_sci_irq' undeclared (first use
> > >> in this
> > function)
> > synchronize_hardirq(acpi_sci_irq);
> > ^
> >drivers/acpi/osl.c:1184:23: note: each undeclared identifier is reported
> > only
> > once for each function it appears in
> >cc1: some warnings being treated as errors
> >
> > vim +/acpi_sci_irq_valid +1183 drivers/acpi/osl.c
> >
> > 1177 void acpi_os_wait_events_complete(void)
> > 1178 {
> > 1179 /*
> > 1180 * Make sure the GPE handler or the fixed event handler
> > is
> > not used
> > 1181 * on another CPU after removal.
> > 1182 */
> > > 1183 if (acpi_sci_irq_valid())
> > > 1184 synchronize_hardirq(acpi_sci_irq);
> > 1185 flush_workqueue(kacpid_wq);
> > 1186 flush_workqueue(kacpi_notify_wq);
> > 1187 }
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology
> > Center
> > https://lists.01.org/pipermail/kbuild-all Intel
> > Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] [media] v4l: xilinx-vipp: add missing of_node_put
Hi Julia,
Thank you for the patch.
On Sunday 25 October 2015 14:57:04 Julia Lawall wrote:
> for_each_child_of_node performs an of_node_get on each iteration, so
> a break out of the loop requires an of_node_put.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows (http://coccinelle.lip6.fr):
>
> //
> @@
> expression root,e;
> local idexpression child;
> @@
>
> for_each_child_of_node(root, child) {
>... when != of_node_put(child)
>when != e = child
> (
>return child;
>
> + of_node_put(child);
> ? return ...;
> )
>...
> }
> //
>
> Signed-off-by: Julia Lawall
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/xilinx/xilinx-vipp.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c
> b/drivers/media/platform/xilinx/xilinx-vipp.c index 7b7cb9c..b9bf24f 100644
> --- a/drivers/media/platform/xilinx/xilinx-vipp.c
> +++ b/drivers/media/platform/xilinx/xilinx-vipp.c
> @@ -476,8 +476,10 @@ static int xvip_graph_dma_init(struct
> xvip_composite_device *xdev)
>
> for_each_child_of_node(ports, port) {
> ret = xvip_graph_dma_init_one(xdev, port);
> - if (ret < 0)
> + if (ret < 0) {
> + of_node_put(port);
> return ret;
> + }
> }
>
> return 0;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] [media] v4l: xilinx-tpg: add missing of_node_put
Hi Julia,
Thank you for the patch.
On Sunday 25 October 2015 14:57:05 Julia Lawall wrote:
> for_each_child_of_node performs an of_node_get on each iteration, so
> a break out of the loop requires an of_node_put.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows (http://coccinelle.lip6.fr):
>
> //
> @@
> expression root,e;
> local idexpression child;
> @@
>
> for_each_child_of_node(root, child) {
>... when != of_node_put(child)
>when != e = child
> (
>return child;
>
> + of_node_put(child);
> ? return ...;
> )
>...
> }
> //
>
> Signed-off-by: Julia Lawall
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/xilinx/xilinx-tpg.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c
> b/drivers/media/platform/xilinx/xilinx-tpg.c index b5f7d5e..8bd7e37 100644
> --- a/drivers/media/platform/xilinx/xilinx-tpg.c
> +++ b/drivers/media/platform/xilinx/xilinx-tpg.c
> @@ -731,6 +731,7 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
> format = xvip_of_get_format(port);
> if (IS_ERR(format)) {
> dev_err(dev, "invalid format in DT");
> + of_node_put(port);
> return PTR_ERR(format);
> }
>
> @@ -739,6 +740,7 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
> xtpg->vip_format = format;
> } else if (xtpg->vip_format != format) {
> dev_err(dev, "in/out format mismatch in DT");
> + of_node_put(port);
> return -EINVAL;
> }
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote: > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). Yeah, people seem to have that impression though. :( > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the > noise you're referring to. This links back to the idea of having generic support for pre-probe actions which is also generally useful (the ability to do things like power on regulators for devices on enumerable buses so they can be enumerated as standard). signature.asc Description: PGP signature
[tip:timers/core] timeconst: Update path in comment
Commit-ID: 03f136a2074b2b8890da4a24df7104558ad0da48
Gitweb: http://git.kernel.org/tip/03f136a2074b2b8890da4a24df7104558ad0da48
Author: Jason A. Donenfeld
AuthorDate: Tue, 14 Jul 2015 19:24:45 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 26 Oct 2015 10:06:06 +0900
timeconst: Update path in comment
Signed-off-by: Jason A. Donenfeld
Cc: hof...@osadl.org
Link: http://lkml.kernel.org/r/1436894685-5868-1-git-send-email-ja...@zx2c4.com
Signed-off-by: Thomas Gleixner
---
kernel/time/timeconst.bc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/timeconst.bc b/kernel/time/timeconst.bc
index c7388de..c486889 100644
--- a/kernel/time/timeconst.bc
+++ b/kernel/time/timeconst.bc
@@ -39,7 +39,7 @@ define fmuls(b,n,d) {
}
define timeconst(hz) {
- print "/* Automatically generated by kernel/timeconst.bc */\n"
+ print "/* Automatically generated by kernel/time/timeconst.bc */\n"
print "/* Time conversion constants for HZ == ", hz, " */\n"
print "\n"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process
On Tue, Oct 06, 2015 at 11:06:47AM +0100, Grant Likely wrote: > [Resending because I messed up the first one] > > The elections for five of the ten members of the Linux Foundation > Technical Advisory Board (TAB) are held every year[1]. This year the > election will be at the 2015 Kernel Summit in Seoul, South Korea > (probably on the Monday, 26 October) and will be open to all attendees > of both Kernel Summit and Korea Linux Forum. > > Anyone is eligible to stand for election, simply send your nomination to: > > tech-board-disc...@lists.linux-foundation.org > > We currently have 3 nominees for five places: > Thomas Gleixner > Greg Kroah-Hartman > Stephen Hemminger Rather late, but thanks to the descriptions from Grant and Jon: I would like to nominate myself. I will be present for the election. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] net: thunderx: Support pass-2 revision hardware.
From: David Daney Date: Fri, 23 Oct 2015 17:14:06 -0700 > With the availability of a new revision of the ThunderX NIC hardware a > few changes to the driver are required. With these, the driver works > on all currently available hardware revisions. Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
Hello, On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen wrote: > Add arch timer node to enable arch-timer support. MT8135 firmware > doesn't correctly setup arch-timer frequency and CNTVOFF, add > properties to workaround this. > > This also set cpu enable-method to enable SMP. > > Signed-off-by: Yingjoe Chen kernelci.org started detecting new boot failures for the mt8135-evb in the arm-soc tree[1], and the boot failures were bisected down to this patch, which landed upstream in the form of commit d186a394bb98 (ARM: dts: mt8135: enable basic SMP bringup for mt8135) Maybe this new SMP support requires updating the firmware on the board as well? If so, the changelog should've been a bit more explicit about firmware dependencies. Kevin [1] http://kernelci.org/boot/mt8135-evbp1/job/arm-soc/kernel/v4.3-rc5-795-ga4b616012d2e/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=562b1cf959b5149e07111471 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mmc: dw_mmc: add hw_reset support
在 2015/10/23 20:07, Jaehoon Chung 写道:
Hi, Shawn.
On 10/22/2015 03:19 PM, Shawn Lin wrote:
This patch implement hw_reset function for DesignWare
MMC controller. By adding this feature, mmc blk can
do some basic recovery if emmc device cannot work any
more for unknown reasons.
Are there any other issue before applied this patch?
yes, but don't relate to dw_mmc itself. In some
low and high temperature test, I get reports that some emmcs don't
work properly for a very very small probability. I don't know what
happend to them, but reset them can slove the problem. So I have to
guess that these emmcs are not so robust at least for temperature test.
Signed-off-by: Shawn Lin
---
drivers/mmc/host/dw_mmc.c | 29 +
drivers/mmc/host/dw_mmc.h | 4
2 files changed, 33 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 6e600e8..8a0f2995 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1478,6 +1478,34 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
return present;
}
+static void dw_mci_hw_reset(struct mmc_host *mmc)
+{
+ struct dw_mci_slot *slot = mmc_priv(mmc);
+ struct dw_mci *host = slot->host;
+
+ if (host->use_dma == TRANS_MODE_IDMAC)
+ dw_mci_idmac_reset(host);
+
+ if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET) ||
+ (!dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET)))
Why does it reset twice? Can't reset together with DMA and FIFO?
dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET | SDMMC_CTRL_FIFO_RESET)?
I reset these by the order provided by the instruction of dw databook.
I can setup my experiment to re-test to see if we can merge these two reset.
Need a few days to test it, I will feedback later. :)
+ return;
+
+ /* CARD_RESET
+* According to eMMC spec
+* tRstW >= 1us: RST_n pulse width
+* tRSCA >= 200us: RST_n to Command time
+* tRSTH >= 1us: RST_n high period
+* Note: add some margin to make rst timing not too
+* "spec" for some bad qulity eMMC devices.
some bad quality? Which devices are bad quality devices?
I test the diff reset time for the emmcs I mentioned above to see
the minimal requirment for them. As spec just say we need to make sure
the tRstW>1us, but I find 2us is enough for most of emmcs but still some
need more than 4 us. So I make it 5us at least here.
+*/
+mci_writel(slot->host, RST_N, SDMMC_RST_HWRESET);
+wmb(); /* drain writebuffer */
+usleep_range(5, 10);
+mci_writel(slot->host, RST_N, SDMMC_RST_HWACTIVE);
+wmb(); /* drain writebuffer */
+usleep_range(500, 1000);
Need to drain writebuffer at here?
I don't know why you choose those values..Just some margin?
And if you want to apply this, i recommend to use the shift with card number.
Just some margin.
okay, I will use the card number shift here.
Best Regards,
Jaehoon Chung
+}
+
static void dw_mci_init_card(struct mmc_host *mmc, struct mmc_card *card)
{
struct dw_mci_slot *slot = mmc_priv(mmc);
@@ -1564,6 +1592,7 @@ static const struct mmc_host_ops dw_mci_ops = {
.set_ios= dw_mci_set_ios,
.get_ro = dw_mci_get_ro,
.get_cd = dw_mci_get_cd,
+ .hw_reset = dw_mci_hw_reset,
.enable_sdio_irq= dw_mci_enable_sdio_irq,
.execute_tuning = dw_mci_execute_tuning,
.card_busy = dw_mci_card_busy,
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index f2a88d4..9df18c1 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -46,6 +46,7 @@
#define SDMMC_VERID 0x06c
#define SDMMC_HCON0x070
#define SDMMC_UHS_REG 0x074
+#define SDMMC_RST_N0x078
#define SDMMC_BMOD0x080
#define SDMMC_PLDMND 0x084
#define SDMMC_DBADDR 0x088
@@ -169,6 +170,9 @@
#define SDMMC_IDMAC_ENABLEBIT(7)
#define SDMMC_IDMAC_FBBIT(1)
#define SDMMC_IDMAC_SWRESET BIT(0)
+/* H/W reset*/
+#define SDMMC_RST_HWACTIVE 0x1
+#define SDMMC_RST_HWRESET 0x0
/* Version ID register define */
#define SDMMC_GET_VERID(x)((x) & 0x)
/* Card read threshold */
--
Best Regards
Shawn Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: soc for 4.4 #2
On Mon, Oct 19, 2015 at 11:21:05PM +0200, Alexandre Belloni wrote: > Arnd, Olof, Kevin, > > This is a great fix for PM and suspend/resume for 4.4 > > Thanks, > > The following changes since commit 6f112a08c1ed717a015dae190e289d53085c1bc4: > > ARM: at91: debug: use DEBUG_UART_PHYS (2015-09-21 16:31:15 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git > tags/at91-ab-soc2 > > for you to fetch changes up to 5fcf8d1a0e84792b2bc44922c5d833dab96a9c1e: > > ARM: at91: pm: at91_pm_suspend_in_sram() must be 8-byte aligned (2015-10-19 > 22:58:44 +0200) Merged, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: defconfig for 4.4 #1
On Mon, Oct 19, 2015 at 10:26:08PM +0200, Alexandre Belloni wrote: > Arnd, Olof, Kevin, > > A defconfig update, adding sama5d2 peripherals to sama5_defconfig and > multi_v7_defconfig > > Thanks, > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git > tags/at91-ab-defconfig > > for you to fetch changes up to 4af8540f0082812e2e092f2d31dbb4d114eee968: > > ARM: multi_v7_defconfig: Add Atmel SDHCI device (2015-10-19 21:52:21 +0200) Merged, thanks! -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: Test for CONFIG_USE_OF to handle the USE_OF=n/OF=y case
On Sun, Oct 25, 2015 at 10:25 AM, Geert Uytterhoeven
wrote:
> Until commit 0166dc11be911213 ("of: make CONFIG_OF user selectable"),
> CONFIG_OF=y implied CONFIG_USE_OF=y on ARM, as the former could solely
> be enabled by being selected by the latter.
Arnd sent a similar fix[1] which I prefer.
> However, if the user now manually enables CONFIG_OF=y while
> CONFIG_USE_OF=n:
>
> arch/arm/kernel/devtree.c: In function 'setup_machine_fdt':
> arch/arm/kernel/devtree.c:215:2: error: implicit declaration of function
> 'early_init_dt_verify' [-Werror=implicit-function-declaration]
> if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
> ^
> arch/arm/kernel/devtree.c:218:2: error: implicit declaration of function
> 'of_flat_dt_match_machine' [-Werror=implicit-function-declaration]
> mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
> ^
> arch/arm/kernel/devtree.c:218:8: warning: assignment makes pointer from
> integer without a cast
> mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
> ^
> arch/arm/kernel/devtree.c:228:3: error: implicit declaration of function
> 'of_get_flat_dt_root' [-Werror=implicit-function-declaration]
>dt_root = of_get_flat_dt_root();
>^
> arch/arm/kernel/devtree.c:229:3: error: implicit declaration of function
> 'of_get_flat_dt_prop' [-Werror=implicit-function-declaration]
>prop = of_get_flat_dt_prop(dt_root, "compatible", );
>^
> arch/arm/kernel/devtree.c:229:8: warning: assignment makes pointer from
> integer without a cast
>prop = of_get_flat_dt_prop(dt_root, "compatible", );
> ^
> arch/arm/kernel/devtree.c:244:2: error: implicit declaration of function
> 'early_init_dt_scan_nodes' [-Werror=implicit-function-declaration]
> early_init_dt_scan_nodes();
> ^
>
> and
>
> arch/arm/kernel/built-in.o: In function `setup_arch':
> arch/arm/kernel/setup.c:940: undefined reference to `setup_machine_fdt'
> arch/arm/kernel/setup.c:979: undefined reference to `arm_dt_init_cpu_maps'
>
> Replace tests for CONFIG_OF by tests for CONFIG_USE_OF where appropriate
> to fix this.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/12531538/
>
> I only fixed the particular issue with the randconfig from the build
> above. Are there more tests for CONFIG_OF that should be converted to
> CONFIG_USE_OF?
I'd rather move toward removing USE_OF and having arches select if
they use EARLY_FLATTREE.
Rob
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/376484.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On Sun, Oct 25, 2015 at 03:45:43PM -0500, Andrew F. Davis wrote: > On 10/24/2015 05:14 PM, Mark Brown wrote: > >Tbe binding document is buggy and doesn't reflect the code, there's no > >compatible string in the driver. > Sure there is: > drivers/mfd/mt6397-core.c:48: > .of_compatible = "mediatek,mt6397-regulator", This is in the MFD, this is not used in actual systems. > Then mfd_add_devices uses this to find the regulator node and fill > in .of_node, then in the regulator driver: > drivers/regulator/mt6397-regulator.c:48: > .of_match = of_match_ptr(match), > which uses your helper to match the nodes in the filled in .of_node. This is in a regulator definition, it is using the regulator framework support for parsing DT which must be used by modern drivers. It is not part of how the Linux driver model device is instantiated, that is done using the struct platform_driver which is what we are talking about here. Please stop this, it is getting very tiresome. > >No, that's not the case - remember, users don't have to write a new > >driver every time they instantiate a device on a board. They're going > >to have to list the in-use regulators one way or another but if we have > >the extra compatible for regulators they have to bind both the core > >device (which is going to be required anyway due to the control bus) and > >the subnode saying that it has regulators (which we knew anyway as soon > >as we knew we had the core device). > We don't know what sub-devices the core device has, PMICs are more like > SoCs on a bus than a regular device, the sub-parts change with every spin and > we can represent this in DT like we do with SoCs. Else we would have to have > a new core binding for every spin. We know what devices are on a particular > SoC too, but we still list them and match them in DT so some SoC driver > doesn't have to. PMICs are very much smaller than SoCs, and again if you're not able to usefully represent individual IPs in the DT (as is *clearly* the case here where you are trying to make one node for the entire collection of regulators) we're not getting any value. signature.asc Description: PGP signature
[PATCH -next] sparc: Populate 'device' for platform device devicetree nodes
Since commit 61e82530d80f ("of/platform: Point to struct device from device
node"), the 'device' pointer in devicetree nodes for platform devices must
be set for of_find_device_by_node to succeed. This is not the case unless
the platform device was created using of_platform_device_create(), which
is not always the case. This causes all sparc images to crash with "Unable
to handle NULL pointer reference" in functions such as iommu_init(), which
don't expect of_find_device_by_node() to return NULL.
Cc: Tomeu Vizoso
Signed-off-by: Guenter Roeck
---
This patch depends on the patch causing the problem (which can not be easily
reverted). It should probably go through the same tree as that patch,
or the patches should be merged.
arch/sparc/kernel/of_device_32.c | 1 +
arch/sparc/kernel/of_device_64.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/sparc/kernel/of_device_32.c b/arch/sparc/kernel/of_device_32.c
index 185aa96fa5be..18a3506ead38 100644
--- a/arch/sparc/kernel/of_device_32.c
+++ b/arch/sparc/kernel/of_device_32.c
@@ -350,6 +350,7 @@ static struct platform_device * __init
scan_one_device(struct device_node *dp,
sd->op = op;
op->dev.of_node = dp;
+ dp->device = >dev;
intr = of_get_property(dp, "intr", );
if (intr) {
diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c
index 7bbdc26d9512..e7a7f3c8733e 100644
--- a/arch/sparc/kernel/of_device_64.c
+++ b/arch/sparc/kernel/of_device_64.c
@@ -647,6 +647,7 @@ static struct platform_device * __init
scan_one_device(struct device_node *dp,
sd->op = op;
op->dev.of_node = dp;
+ dp->device = >dev;
irq = of_get_property(dp, "interrupts", );
if (irq) {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:irq/urgent] irqchip/tegra: Propagate IRQ type setting to parent
Commit-ID: 209da39154837ec1b69fb34f438041939911e4b4
Gitweb: http://git.kernel.org/tip/209da39154837ec1b69fb34f438041939911e4b4
Author: Lucas Stach
AuthorDate: Sun, 25 Oct 2015 16:39:12 +0100
Committer: Thomas Gleixner
CommitDate: Mon, 26 Oct 2015 09:20:59 +0900
irqchip/tegra: Propagate IRQ type setting to parent
The LIC doesn't deal with the different types of interrupts itself
but needs to forward calls to set the appropriate type to its parent
IRQ controller.
Without this fix all IRQs routed through the LIC will stay at the
initial EDGE type, while most of them should actually be level triggered.
Fixes: 1eec582158e2 "irqchip: tegra: Add Tegra210 support"
Signed-off-by: Lucas Stach
Cc: Stephen Warren
Cc: Thierry Reding
Cc: Alexandre Courbot
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: # 4.1
Link: http://lkml.kernel.org/r/1445787552-13062-1-git-send-email-...@lynxeye.de
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/irq-tegra.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-tegra.c b/drivers/irqchip/irq-tegra.c
index 2fd89eb..fd88e68 100644
--- a/drivers/irqchip/irq-tegra.c
+++ b/drivers/irqchip/irq-tegra.c
@@ -214,6 +214,7 @@ static struct irq_chip tegra_ictlr_chip = {
.irq_unmask = tegra_unmask,
.irq_retrigger = tegra_retrigger,
.irq_set_wake = tegra_set_wake,
+ .irq_set_type = irq_chip_set_type_parent,
.flags = IRQCHIP_MASK_ON_SUSPEND,
#ifdef CONFIG_SMP
.irq_set_affinity = irq_chip_set_affinity_parent,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node
On October 26, 2015 9:13:01 AM GMT+09:00, Mark Brown wrote: >On Sat, Oct 24, 2015 at 03:09:06PM -0500, Rob Herring wrote: > >> Let's get agreement on the flow and structure and how to address >other >> issues like suspend, then we can worry about whether this needs to be >> abstracted from subsystems. We can discuss more this week at KS. > >Should we try to schedule an ad-hoc session today (Monday) for those of >us who are here to talk this over? That would be great. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1338/1338] Drivers:staging:wlan-ng fixed coding style
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Sun, Oct 25, 2015 at 10:55:55PM +, sasa bogicevic wrote: > Ooops I guess I made a mistake with my first patch, but your name came up when > I called get_maintainer.pl. Yes, that's fine, I should be copied on patches like this, but please go read Documentation/SubmittingPatches for what exactly signed-off-by: means and why you can't do that for anyone else. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node
On Sat, Oct 24, 2015 at 03:09:06PM -0500, Rob Herring wrote: > Let's get agreement on the flow and structure and how to address other > issues like suspend, then we can worry about whether this needs to be > abstracted from subsystems. We can discuss more this week at KS. Should we try to schedule an ad-hoc session today (Monday) for those of us who are here to talk this over? signature.asc Description: PGP signature
Re: [PATCH 2/5] staging: fsl-mc: define a macro to differentiate root dprc
On Sun, Oct 25, 2015 at 05:41:20PM -0500, Lijun Pan wrote:
> Define is_root_dprc(dev) to tell whether a device is
> root dprc or not via platform_bus_type.
>
> Signed-off-by: Lijun Pan
> ---
> drivers/staging/fsl-mc/include/mc.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/staging/fsl-mc/include/mc.h
> b/drivers/staging/fsl-mc/include/mc.h
> index a933291..483763e 100644
> --- a/drivers/staging/fsl-mc/include/mc.h
> +++ b/drivers/staging/fsl-mc/include/mc.h
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include "../include/dprc.h"
>
> #define FSL_MC_VENDOR_FREESCALE 0x1957
> @@ -109,6 +110,15 @@ struct fsl_mc_resource {
> #define FSL_MC_IS_DPRC 0x0001
>
> /**
> + * root dprc's parent is a platform device
> + * that platform device's bus type is platform_bus_type.
> + */
> +#define is_root_dprc(dev) \
> + ((to_fsl_mc_device(dev)->flags & FSL_MC_IS_DPRC) && \
> + ((dev)->bus == _mc_bus_type) && \
> + ((dev)->parent->bus == _bus_type))
> +
It's best to make this type of thing a static inline function, to ensure
you get the correct typechecking.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] irqchip: armada-370-xp: re-enable per-CPU interrupts at resume time
Marcin,
On Sun, 25 Oct 2015 22:22:37 +0100, Marcin Wojtas wrote:
> > @@ -550,16 +572,27 @@ static void armada_370_xp_mpic_resume(void)
> > if (virq == 0)
> > continue;
> >
> > - if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
> > + data = irq_get_irq_data(virq);
> > +
> > + if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ) {
> > + /* Non per-CPU interrupts */
> > writel(irq, per_cpu_int_base +
>
> For "Non per-CPU interrupts" per_cpu_int_base is used - is it
> intentional? In armada_370_xp_irq_mask/unmask the condition looks
> exactly opposite...
Yes, this is normal. Carefully read PATCH 5/5, which adds a big
comment, which explains the logic of the HW and how the
irq-armada-370-xp driver copes with it.
Each interrupt can be masked at two levels. One level is enabled when
the interrupted is mapped, the other upon ->mask()/->unmask(). So
when we're resuming, we need to re-enable the interrupt at the level it
was enabled in ->map(), and have ->mask()/->unmask() continue to
mask/unmask the interrupt at the other level.
For per-CPU interrupts, ->map() and ->resume() enable the interrupt at
the global level, and leave ->mask()/->unmask() enable/disable at the
per-CPU level.
For global interrupts, ->map() and ->resume() enable the interrupt at
the per-CPU level, and leave ->mask()/->unmask() enable/disable at the
global level.
Again, see PATCH 5/5, and let me know if there are still some unclear
aspects.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
We Offer All Kinds Of Loans!!
We offer loan at low interest rate of 3% and with collateral and not Collateral, we offer personal loans, debt consolidation loans, venture capital Capital, business loan, education loan, mortgage or Loans for any reason". E-mail us for more Info with amount needed at: quickloan...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Fixed Trivial Warnings in file: Deleted Spaces prior to tabs, and added lines. modified: kernel/auditfilter.c
On 10/21/2015 09:15 PM, Richard Guy Briggs wrote:
On 15/10/21, Scott Matheina wrote:
On 10/21/2015 10:33 AM, Richard Guy Briggs wrote:
On 15/10/21, Joe Perches wrote:
On Mon, 2015-10-19 at 12:10 -0400, Richard Guy Briggs wrote:
On 15/10/18, Scott Matheina wrote:
On 10/14/2015 04:54 PM, Paul Moore wrote:
On Saturday, October 10, 2015 08:57:55 PM Scott Matheina wrote:
[]
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
[]
@@ -109,6 +109,7 @@ void audit_free_rule_rcu(struct rcu_head *head)
{
struct audit_entry *e = container_of(head, struct audit_entry, rcu);
audit_free_rule(e);
+
}
Why?
I was following the error messages in checkpatch.pl, but the warning
went away after adding this line. No problem with the code.
That sounds like a bug in checkpatch.pl, since that blank line should be
tween the declaration and the function call.
checkpatch message asks for a blank line after the
"struct audit_entry *e = ..." declaration.
Well then maybe it is a bug in his interpretation of the output of
checkpatch.pl? Scott, did you re-run checkpatch.pl after adding those
spaces? Did it pass?
The error did go away.
Joe, I confirm the error went away. Looks like a bug in checkpatch.pl
to me. I tried a number of combinations of things and it didn't
complain about several things it should have. I did try a few other
things to make sure it was still finding problems like brace placement
and leading spaces, but it looks like the blank line checking code isn't
working. This is on 4.0, so maybe it has been fixed since then. Scott,
what kernel version are you using?
I had just cloned Linus' repo, so v4.3rc6.
while (*list != ~0U) {
+
unsigned n = *list++;
if (n >= AUDIT_BITMASK_SIZE * 32 - AUDIT_SYSCALL_CLASSES) {
kfree(p);
Why?
This is the same as above. Just going through the checkpatch.pl
script, and looking for warnings to fix.
Again, another manifestation of that bug? That blank line should be
after the declaration and before the if statement.
[]
Well, I agree, you have to start somewhere... Too bad you hit a bug in
checkpatch.pl!
Here too, not a bug in checkpatch.
checkpatch output asks for a blank line after the
"unsigned n" declaration, not before.
- RGB
- RGB
--
Richard Guy Briggs
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] clocksource: mtk_timer: fix pr_warn() messages in mtk_timer_init
1) Change pr_warn()s to pr_err()s. These messages are actually
errors and not warnings.
2) Add missing \n.
3) Error message for kzalloc() failure is removed per suggestion
by Joe Perches. There is generic stack_dump() for allocation issues.
Signed-off-by: Alexey Klimov
---
Changes in v3:
-- small cleanup
Changes in v2:
-- remove message on allocation failure
drivers/clocksource/mtk_timer.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index ca5ea9e..4f4 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -183,10 +183,8 @@ static void __init mtk_timer_init(struct device_node *node)
struct clk *clk;
evt = kzalloc(sizeof(*evt), GFP_KERNEL);
- if (!evt) {
- pr_warn("Can't allocate mtk clock event driver struct");
+ if (!evt)
return;
- }
evt->dev.name = "mtk_tick";
evt->dev.rating = 300;
@@ -200,24 +198,24 @@ static void __init mtk_timer_init(struct device_node
*node)
evt->gpt_base = of_io_request_and_map(node, 0, "mtk-timer");
if (IS_ERR(evt->gpt_base)) {
- pr_warn("Can't get resource\n");
+ pr_err("Can't get resource\n");
return;
}
evt->dev.irq = irq_of_parse_and_map(node, 0);
if (evt->dev.irq <= 0) {
- pr_warn("Can't parse IRQ");
+ pr_err("Can't parse IRQ\n");
goto err_mem;
}
clk = of_clk_get(node, 0);
if (IS_ERR(clk)) {
- pr_warn("Can't get timer clock");
+ pr_err("Can't get timer clock\n");
goto err_irq;
}
if (clk_prepare_enable(clk)) {
- pr_warn("Can't prepare clock");
+ pr_err("Can't prepare clock\n");
goto err_clk_put;
}
rate = clk_get_rate(clk);
@@ -226,7 +224,7 @@ static void __init mtk_timer_init(struct device_node *node)
if (request_irq(evt->dev.irq, mtk_timer_interrupt,
IRQF_TIMER | IRQF_IRQPOLL, "mtk_timer", evt)) {
- pr_warn("failed to setup irq %d\n", evt->dev.irq);
+ pr_err("failed to setup irq %d\n", evt->dev.irq);
goto err_clk_disable;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
