Re: linux-next: Tree for Aug 27
On 8/27/2014 5:48 PM, Stephen Rothwell wrote:
Hi all,
On Wed, 27 Aug 2014 16:58:09 -0700 Guenter Roeck wrote:
I see a large number of build failures with this kernel.
drivers/base/dma-mapping.c: In function 'dma_common_contiguous_remap':
drivers/base/dma-mapping.c:294:2: error: implicit declaration of function
'dma_common_pages_remap' [-Werror=implicit-function-declaration]
drivers/base/dma-mapping.c:294:6: warning: assignment makes pointer from integer
without a cast [enabled by default]
drivers/base/dma-mapping.c: At top level:
drivers/base/dma-mapping.c:305:7: error: conflicting types for
'dma_common_pages_remap'
drivers/base/dma-mapping.c:294:8: note: previous implicit declaration of
'dma_common_pages_remap' was here
cc1: some warnings being treated as errors
make[2]: *** [drivers/base/dma-mapping.o] Error 1
Caused by commit fa44abcad042 ("common: dma-mapping: introduce common
remapping functions") from the akpm-current tree. I will attempt to
revert that commit today, but I may need to also revert the following 2
commits as well:
arm: use genalloc for the atomic pool
arm64: add atomic pool for non-coherent and CMA allocations
though I am not sure. Hopefully someone will let me know in the next
few hours ...
I sent fixes for this to Andrew yesterday, did those not get picked up
or fix the problem?
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Aug 27
Hi all,
On Wed, 27 Aug 2014 16:58:09 -0700 Guenter Roeck wrote:
>
> I see a large number of build failures with this kernel.
>
> drivers/base/dma-mapping.c: In function 'dma_common_contiguous_remap':
> drivers/base/dma-mapping.c:294:2: error: implicit declaration of function
> 'dma_common_pages_remap' [-Werror=implicit-function-declaration]
> drivers/base/dma-mapping.c:294:6: warning: assignment makes pointer from
> integer
> without a cast [enabled by default]
> drivers/base/dma-mapping.c: At top level:
> drivers/base/dma-mapping.c:305:7: error: conflicting types for
> 'dma_common_pages_remap'
> drivers/base/dma-mapping.c:294:8: note: previous implicit declaration of
> 'dma_common_pages_remap' was here
> cc1: some warnings being treated as errors
> make[2]: *** [drivers/base/dma-mapping.o] Error 1
Caused by commit fa44abcad042 ("common: dma-mapping: introduce common
remapping functions") from the akpm-current tree. I will attempt to
revert that commit today, but I may need to also revert the following 2
commits as well:
arm: use genalloc for the atomic pool
arm64: add atomic pool for non-coherent and CMA allocations
though I am not sure. Hopefully someone will let me know in the next
few hours ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [linuxtv-media:devel 497/499] drivers/media/platform/s5p-mfc/s5p_mfc.c:454:2-5: WARNING: Use BUG_ON
Hi Mauro, On Wed, Aug 27, 2014 at 02:31:37PM -0300, Mauro Carvalho Chehab wrote: > Hi Fengguang, > > Not sure why, but I didn't receive this e-mail (or other emails in this > thread). It's a manual check process rather than an email problem. The TO/CC you see lie in the email body. The original email is sent to the kbuild list for manual checking. We do such check for all low confident static check warnings. Julia and Dan are actively looking at these reports and will forward the ones that worth more attention to the relevant people. Thanks, Fengguang > Em Wed, 27 Aug 2014 19:07:45 +0200 (CEST) > Julia Lawall escreveu: > > > The bug_on one doesn't look like a good idea, but the returnvar one would > > make the code a little simpler. > > > > julia > > > > On Thu, 28 Aug 2014, kbuild test robot wrote: > > > > > TO: Mauro Carvalho Chehab > > > CC: linux-me...@vger.kernel.org > > > > > > Hi Mauro, > > > > > > First bad commit (maybe != root cause): > > > > > > tree: git://linuxtv.org/media_tree.git devel > > > head: 38a0731165250a0a77eff7b90ea3156d44cc7d66 > > > commit: 7155043c2d027c9c848c3d09badb5af2894ed652 [497/499] [media] enable > > > COMPILE_TEST for media drivers > > > :: branch date: 19 hours ago > > > :: commit date: 19 hours ago > > > > > > >> drivers/media/platform/s5p-mfc/s5p_mfc.c:454:2-5: WARNING: Use BUG_ON > > > >> drivers/media/platform/s5p-mfc/s5p_mfc.c:333:3-6: WARNING: Use BUG_ON > > > >> drivers/media/platform/s5p-mfc/s5p_mfc.c:406:2-5: WARNING: Use BUG_ON > > > >> drivers/media/platform/s5p-mfc/s5p_mfc.c:548:3-6: WARNING: Use BUG_ON > > > >> drivers/media/platform/s5p-mfc/s5p_mfc.c:556:3-6: WARNING: Use BUG_ON > > > >> drivers/media/platform/s5p-mfc/s5p_mfc.c:509:2-5: WARNING: Use BUG_ON > > > >> drivers/media/platform/s5p-mfc/s5p_mfc.c:634:4-7: WARNING: Use BUG_ON > > > -- > > > >> drivers/media/platform/davinci/vpfe_capture.c:946:5-8: Unneeded > > > >> variable: "ret". Return "0" on line 951 > > > > > > Please consider folding the attached diff :-) > > > > > > --- > > > 0-DAY kernel build testing backend Open Source Technology > > > Center > > > http://lists.01.org/mailman/listinfo/kbuild 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: [RFC PATCH v3] tpm_tis: verify interrupt during init
On Wed, 27 Aug 2014, Jason Gunthorpe wrote:
> On Wed, Aug 27, 2014 at 09:32:10PM +, Scot Doyle wrote:
-if (tpm_do_selftest(chip)) {
-dev_err(dev, "TPM self test failed\n");
-rc = -ENODEV;
-goto out_err;
-}
>>>
>>> Move gettimeout too
>>
>> Can it be moved? It sends startup(clear) if the TPM isn't yet operational.
>
> To move it means we have to understand why you are getting timeouts:
>
> [ 33.247720] tpm_tis 00:08: tpm_transmit: tpm_send: error -62
> [ 33.247731] tpm_tis 00:08: [Hardware Error]: TPM command timed out during
> continue self test
>
> I had thought based on your other patch that these should not happen
> since the raw register is polled after the timer expires?
It is polled after the timer expires in tpm_tis_send_data, but not in
tpm_tis_send, and the return value is used in tpm_tis_send...
> What is going on here? Do you still have that other patch applied?
...so with the other patch applied too, the output is:
[1.464217] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
[3.570836] tpm_tis 00:08: tpm_transmit: tpm_send: error -62
[3.660885] tpm_tis 00:08: [Firmware Bug]: TPM interrupt not working,
polling instead
Much better! Any thoughts before I proceed?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2% Loan Offer
-- Our Company gives out Personal and Business Loans,interested persons should contact us now. Harry Roberts -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hello
My Dear, I want to establish a charity foundation in your country with this sum which I inherited from my late fathers (Mr kumar Zakaria) it is my desire to see that this money is invested to any business /organization of your choice in your country, motherless baby’s home, mosques, churches,School,Destitute aged men and women or whatever you may have in mind that will be to the benefit of the less fortunate Miss.Maryam Zakaria (miss.maryam_zaka...@yahoo.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 1/2] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 16:54:18 -0700 Mike Travis wrote: > > If we're still at 1+ hours then little bodges like this are nowhere > > near sufficient and sterner stuff will be needed. > > > > Do we actually need the test? My googling turns up zero instances of > > anyone reporting the "ioremap on RAM pfn" warning. > > We get them more than we like, mostly from 3rd party vendors, and > esp. those that merely port their windows drivers to linux. Dang. So wrapping the check in CONFIG_DEBUG_VM would be problematic? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/15] drm/exynos/ipp: free partially allocated resources on error
Hi,
On 08/27/2014 07:27 PM, Andrzej Hajda wrote:
> On 08/26/2014 07:00 AM, Joonyoung Shim wrote:
>> Hi Andrzej,
>>
>> On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
>>> In case of allocation errors some already allocated buffers
>>> were not freed. The patch fixes it.
>>>
>>> Signed-off-by: Andrzej Hajda
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 68
>>> -
>>> 1 file changed, 33 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>>> index 060a198..728f3b9 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>>> @@ -599,6 +599,37 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv
>>> *ippdrv,
>>> return ret;
>>> }
>>>
>>> +static int ipp_put_mem_node(struct drm_device *drm_dev,
>>> + struct drm_exynos_ipp_cmd_node *c_node,
>>> + struct drm_exynos_ipp_mem_node *m_node)
>>> +{
>>> + int i;
>>> +
>>> + DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
>>> +
>>> + if (!m_node) {
>>> + DRM_ERROR("invalid dequeue node.\n");
>>> + return -EFAULT;
>>> + }
>>> +
>>> + DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
>>> +
>>> + /* put gem buffer */
>>> + for_each_ipp_planar(i) {
>>> + unsigned long handle = m_node->buf_info.handles[i];
>>> + if (handle)
>>> + exynos_drm_gem_put_dma_addr(drm_dev, handle,
>>> + c_node->filp);
>>> + }
>>> +
>>> + /* conditionally remove from queue */
>>> + if (m_node->list.next)
>> How about do INIT_LIST_HEAD for list in ipp_get_mem_node()?
>
> I am not sure if it is better. For sure it adds unnecessary
> initialization sequence.
In other words, this NULL checking is unnecessary if you initialize the
list_head by INIT_LIST_HEAD.
> Maybe adding list_is_initialized inline function to list.h would be the
> best solution.
There is just list_empty and we can't know whether list is initialized
or not. I recommend to use initialized list_head.
Thanks.
>
> Regards
> Andrzej
>
>>
>>> + list_del(_node->list);
>>> + kfree(m_node);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static struct drm_exynos_ipp_mem_node
>>> *ipp_get_mem_node(struct drm_device *drm_dev,
>>> struct drm_file *file,
>>> @@ -634,7 +665,8 @@ static struct drm_exynos_ipp_mem_node
>>> qbuf->handle[i], file);
>>> if (IS_ERR(addr)) {
>>> DRM_ERROR("failed to get addr.\n");
>>> - goto err_clear;
>>> + ipp_put_mem_node(drm_dev, c_node, m_node);
>>> + return ERR_PTR(-EFAULT);
>>> }
>>>
>>> buf_info->handles[i] = qbuf->handle[i];
>>> @@ -649,40 +681,6 @@ static struct drm_exynos_ipp_mem_node
>>> mutex_unlock(_node->mem_lock);
>>>
>>> return m_node;
>>> -
>>> -err_clear:
>>> - kfree(m_node);
>>> - return ERR_PTR(-EFAULT);
>>> -}
>>> -
>>> -static int ipp_put_mem_node(struct drm_device *drm_dev,
>>> - struct drm_exynos_ipp_cmd_node *c_node,
>>> - struct drm_exynos_ipp_mem_node *m_node)
>>> -{
>>> - int i;
>>> -
>>> - DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
>>> -
>>> - if (!m_node) {
>>> - DRM_ERROR("invalid dequeue node.\n");
>>> - return -EFAULT;
>>> - }
>>> -
>>> - DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
>>> -
>>> - /* put gem buffer */
>>> - for_each_ipp_planar(i) {
>>> - unsigned long handle = m_node->buf_info.handles[i];
>>> - if (handle)
>>> - exynos_drm_gem_put_dma_addr(drm_dev, handle,
>>> - c_node->filp);
>>> - }
>>> -
>>> - /* delete list in queue */
>>> - list_del(_node->list);
>>> - kfree(m_node);
>>> -
>>> - return 0;
>>> }
>>>
>>> static void ipp_free_event(struct drm_pending_event *event)
>>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Aug 27
On Wed, Aug 27, 2014 at 04:10:21PM +1000, Stephen Rothwell wrote: > Hi all, > > Changes since 20140826: > > The net tree lost its build failure. > > The usb.current tree gained a build failure for which I reverted a commit. > > The mfd tree lost its build failure. > > The percpu tree gained a build failure so I used the version from > next-20140826. > > The staging tree still had its build failure for which I applied a > fix patch. > > The akpm-current tree lost its build failure. > > The akpm tree lost its build failure and a patch that turned up elsewhere. > > Non-merge commits (relative to Linus' tree): 2028 > 2105 files changed, 56310 insertions(+), 35111 deletions(-) > I see a large number of build failures with this kernel. drivers/base/dma-mapping.c: In function 'dma_common_contiguous_remap': drivers/base/dma-mapping.c:294:2: error: implicit declaration of function 'dma_common_pages_remap' [-Werror=implicit-function-declaration] drivers/base/dma-mapping.c:294:6: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/base/dma-mapping.c: At top level: drivers/base/dma-mapping.c:305:7: error: conflicting types for 'dma_common_pages_remap' drivers/base/dma-mapping.c:294:8: note: previous implicit declaration of 'dma_common_pages_remap' was here cc1: some warnings being treated as errors make[2]: *** [drivers/base/dma-mapping.o] Error 1 Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] memory-hotplug: rename zones_online_to to valid_zones
(2014/08/27 20:18), Zhang Zhen wrote:
Rename the interface to valid_zones according to most pepole's
suggestion.
Sample output of the sysfs files:
memory0/valid_zones: none
memory1/valid_zones: DMA32
memory2/valid_zones: DMA32
memory3/valid_zones: DMA32
memory4/valid_zones: Normal
memory5/valid_zones: Normal
memory6/valid_zones: Normal Movable
memory7/valid_zones: Movable Normal
memory8/valid_zones: Movable
Signed-off-by: Zhang Zhen
Reviewed-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
---
Documentation/ABI/testing/sysfs-devices-memory | 8
Documentation/memory-hotplug.txt | 13 ++---
drivers/base/memory.c | 6 +++---
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-devices-memory
b/Documentation/ABI/testing/sysfs-devices-memory
index 2b2a1d7..deef3b5 100644
--- a/Documentation/ABI/testing/sysfs-devices-memory
+++ b/Documentation/ABI/testing/sysfs-devices-memory
@@ -61,13 +61,13 @@ Users: hotplug memory remove tools
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
-What: /sys/devices/system/memory/memoryX/zones_online_to
+What: /sys/devices/system/memory/memoryX/valid_zones
Date: July 2014
Contact: Zhang Zhen
Description:
- The file /sys/devices/system/memory/memoryX/zones_online_to
- is read-only and is designed to show which zone this memory
block can
- be onlined to.
+ The file /sys/devices/system/memory/memoryX/valid_zones is
+ read-only and is designed to show which zone this memory
+ block can be onlined to.
What: /sys/devices/system/memoryX/nodeY
Date: October 2009
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 5b34e33..93a25ef 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -155,7 +155,7 @@ Under each memory block, you can see 4 files:
/sys/devices/system/memory/memoryXXX/phys_device
/sys/devices/system/memory/memoryXXX/state
/sys/devices/system/memory/memoryXXX/removable
-/sys/devices/system/memory/memoryXXX/zones_online_to
+/sys/devices/system/memory/memoryXXX/valid_zones
'phys_index' : read-only and contains memory block id, same as XXX.
'state' : read-write
@@ -171,8 +171,15 @@ Under each memory block, you can see 4 files:
block is removable and a value of 0 indicates that
it is not removable. A memory block is removable only if
every section in the block is removable.
-'zones_online_to' : read-only: designed to show which zone this memory block
- can be onlined to.
+'valid_zones' : read-only: designed to show which zones this memory block
+ can be onlined to.
+ The first column shows it's default zone.
+ "memory6/valid_zones: Normal Movable" shows this memoryblock
+ can be onlined to ZONE_NORMAL by default and to ZONE_MOVABLE
+ by online_movable.
+ "memory7/valid_zones: Movable Normal" shows this memoryblock
+ can be onlined to ZONE_MOVABLE by default and to ZONE_NORMAL
+ by online_kernel.
NOTE:
These directories/files appear after physical memory hotplug phase.
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 0fc1d25..efd456c 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -374,7 +374,7 @@ static ssize_t show_phys_device(struct device *dev,
}
#ifdef CONFIG_MEMORY_HOTREMOVE
-static ssize_t show_zones_online_to(struct device *dev,
+static ssize_t show_valid_zones(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct memory_block *mem = to_memory_block(dev);
@@ -409,7 +409,7 @@ static ssize_t show_zones_online_to(struct device *dev,
return sprintf(buf, "%s\n", zone->name);
}
-static DEVICE_ATTR(zones_online_to, 0444, show_zones_online_to, NULL);
+static DEVICE_ATTR(valid_zones, 0444, show_valid_zones, NULL);
#endif
static DEVICE_ATTR(phys_index, 0444, show_mem_start_phys_index, NULL);
@@ -563,7 +563,7 @@ static struct attribute *memory_memblk_attrs[] = {
_attr_phys_device.attr,
_attr_removable.attr,
#ifdef CONFIG_MEMORY_HOTREMOVE
- _attr_zones_online_to.attr,
+ _attr_valid_zones.attr,
#endif
NULL
};
-- 1.8.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 1/2] memory-hotplug: fix not enough check of valid zones
(2014/08/27 20:16), Zhang Zhen wrote:
As Yasuaki Ishimatsu described the check here is not enough
if memory has hole as follows:
PFN 0x00 0xd0 0xe0 0xf0
+-+-+-+
zone type | Normal| hole| Normal|
+-+-+-+
In this case, the check can't guarantee that this is "the last
block of memory".
The check of ZONE_MOVABLE has the same problem.
Signed-off-by: Zhang Zhen
Reviewed-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
---
drivers/base/memory.c | 36 ++--
1 file changed, 6 insertions(+), 30 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index ccaf37c..0fc1d25 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -374,20 +374,6 @@ static ssize_t show_phys_device(struct device *dev,
}
#ifdef CONFIG_MEMORY_HOTREMOVE
-static int __zones_online_to(unsigned long end_pfn,
- struct page *first_page, unsigned long nr_pages)
-{
- struct zone *zone_next;
-
- /* The mem block is the last block of memory. */
- if (!pfn_valid(end_pfn + 1))
- return 1;
- zone_next = page_zone(first_page + nr_pages);
- if (zone_idx(zone_next) == ZONE_MOVABLE)
- return 1;
- return 0;
-}
-
static ssize_t show_zones_online_to(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -407,28 +393,18 @@ static ssize_t show_zones_online_to(struct device *dev,
zone = page_zone(first_page);
-#ifdef CONFIG_HIGHMEM
- if (zone_idx(zone) == ZONE_HIGHMEM) {
- if (__zones_online_to(end_pfn, first_page, nr_pages))
+ if (zone_idx(zone) == ZONE_MOVABLE - 1) {
+ /*The mem block is the last memoryblock of this zone.*/
+ if (end_pfn == zone_end_pfn(zone))
return sprintf(buf, "%s %s\n",
zone->name, (zone + 1)->name);
}
-#else
- if (zone_idx(zone) == ZONE_NORMAL) {
- if (__zones_online_to(end_pfn, first_page, nr_pages))
- return sprintf(buf, "%s %s\n",
- zone->name, (zone + 1)->name);
- }
-#endif
if (zone_idx(zone) == ZONE_MOVABLE) {
- if (!pfn_valid(start_pfn - nr_pages))
- return sprintf(buf, "%s %s\n",
- zone->name, (zone - 1)->name);
- zone_prev = page_zone(first_page - nr_pages);
- if (zone_idx(zone_prev) != ZONE_MOVABLE)
+ /*The mem block is the first memoryblock of ZONE_MOVABLE.*/
+ if (start_pfn == zone->zone_start_pfn)
return sprintf(buf, "%s %s\n",
- zone->name, (zone - 1)->name);
+ zone->name, (zone - 1)->name);
}
return sprintf(buf, "%s\n", zone->name);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the usb.current tree
On Wed, Aug 27, 2014 at 11:03:22AM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the usb.current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/usb/core/hub.c: In function 'hub_probe':
> drivers/usb/core/hub.c:1735:21: error: 'struct dev_pm_info' has no member
> named 'autosuspend_delay'
> if (hdev->dev.power.autosuspend_delay >= 0)
> ^
>
> Caused by commit bdd405d2a528 ("usb: hub: Prevent hub autosuspend if
> usbcore.autosuspend is -1"). CONFIG_PM_RUNTIME is not set in this
> build.
>
> I have reverted that commit for today.
Thanks, I'll work on fixing this later on today...
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On 8/27/2014 4:37 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis wrote:
>
>>>
>>>
>>>
>>> Doing strcmp("System RAM") is rather a hack. Is there nothing in
>>> resource.flags which can be used? Or added otherwise?
>>
>> I agree except this mimics the page_is_ram function:
>>
>> while ((res.start < res.end) &&
>> (find_next_iomem_res(, "System RAM", true) >= 0)) {
>
> Yeah. Sigh.
>
>> So it passes the same literal string which then find_next does the
>> same strcmp on it:
>>
>> if (p->flags != res->flags)
>> continue;
>> if (name && strcmp(p->name, name))
>> continue;
>>
>> I should add back in the check to insure name is not NULL.
>
> If we're still at 1+ hours then little bodges like this are nowhere
> near sufficient and sterner stuff will be needed.
>
> Do we actually need the test? My googling turns up zero instances of
> anyone reporting the "ioremap on RAM pfn" warning.
We get them more than we like, mostly from 3rd party vendors, and
esp. those that merely port their windows drivers to linux.
>
> Where's the rest of the time being spent?
This device has a huge internal memory and many processing devices.
So it loads up an operating system and starts a bunch of pseudo network
connections through the PCI-e/driver interface. It was hard to
determine what percentage the ioremap played in the overall starting
time (based on what info we were able to collect). But the ioremap
was definitely the largest part of the 'modprobe' operation. I think
realistically that's all we have control over.
(But as I mentioned, we are encouraging the vendor to look into starting
the devices in parallel. The overlap will cut down the overall time by
quite a bit, being there are 31 devices.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: gadget: net2280: Remove pci_class from PCI_TABLE
On Wed, Aug 27, 2014 at 11:09:08PM +0200, Bjørn Mork wrote: > Greg Kroah-Hartman writes: > > On Wed, Aug 27, 2014 at 09:39:43PM +0200, Ricardo Ribalda Delgado wrote: > >> > >> return sprintf(buf, "pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02x\n", > > That final 'x' does look like a typo, doesn't it? We are otherwise > consistently using upper-case hex digits for field values and lower case > letter for field names. But it looks like it has been like that since > the beginning, so it might be difficult to fix... Yes, it should be fixed, sorry, my later email said that, no one has hit it in 9+ years, pretty impressive. > > No, the root cause of the problem is a userspace tool looking at a hex > > value as a string and not a number. It doesn't matter if we print it in > > upper or lower case, it's a digit, not a string. Do the numeric > > compare, not a string compare. > > Now I don't really know much about the history here, but the format of > module aliases, using wildcards, seem to suggest a string match to me. > Do you really mean that these strings should be parsed into field names > + values before matching? If that was the intention then surely we > would have exported the fields one-by-one as separate sysfs attributes? > Ref the "one value per file" policy. No, this is a bit field, so you can't do a string compare. kmod should know how do handle this, it does so for other types of "class" fields in module device ids. And no, we didn't export these as a set of files, it's one unique value that you can use to match up a device to a driver. > >> Not many drivers define the pci interface and there is no other driver > >> that has the same vendor and product id. Therefore I see no hurt in > >> adding both patches, one to make the driver broader, and another to > >> fix pci-sysfs. > >> > >> Also, the change on pci-sysfs might affect more stuff and therefore > >> take longer to be applied. > > > > As we have been printing the value to userspace in this way for well > > over a decade now, and nothing has changed, I say it's a userspace bug > > that you should fix instead. Don't work around broken user programs in > > the kernel by changing something that has been stable for 10+ years. > > > > Ok, sorry, not 10+ years, the commit was written May of 2005, so 9 > > years. > > well, just looking at a few common PCI devices on my PCs I wonder if the > reason this hasn't been a problem is because there are _very_ few PCI > programming interfaces using anything by 0-9 digits. One? Looking at the > modules built by Debian I can only find one udc module matching on any > hex value: > > bjorn@nemi:~$ grep pci: /lib/modules/3.16-trunk-amd64/modules.alias|egrep > "i[A-F]" > alias pci:v10DBd8808sv*sd*bc0Csc03iFE* pch_udc > alias pci:v10DBd801Dsv*sd*bc0Csc03iFE* pch_udc > alias pci:v8086d8808sv*sd*bc0Csc03iFE* pch_udc > > This makes me wonder if this is exclusively a problem for PCI UDCs, > which tend to be pretty rare devices? Yes, this is a rare thing, as the age of this line proves :) 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 v7] usb:serial:pl2303: add GPIOs interface on PL2303
On Mon, Aug 18, 2014 at 12:07:20PM +0200, Johan Hovold wrote: > On Sun, Aug 17, 2014 at 10:05:36AM +0800, Wang YanQing wrote: > > Hi Johan Hovold. > > > > Another two questions. > > > > On Tue, Aug 12, 2014 at 04:46:25PM +0200, Johan Hovold wrote: > > > > > > > + int (*gpio_startup)(struct usb_serial *serial); > > > > + void (*gpio_release)(struct usb_serial *serial); > > > > > > This isn't the right place for this abstraction. Most of the setup code > > > would be common for any device type with GPIOs. > > > > I assume you mean any pl2303 variant, not any device type, because > > no device in drivers/gpio has common setup code except many of them > > use struct gpio_chip. > > Yes, pl2303 type/variant. Specifically, much of the setup code will be > identical even if say the number of gpio differ (2 or 4) depending on > type. Yes, indeed unless I know how to make kernel could distinguish those two types, this patch willn't be fit for mergence. And I don't have free time recent, I need more time to prepare this patch, or could you figure out how to distinguish them? 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/
[security-next] Pull request (merge window)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef: Linux 3.17-rc2 (2014-08-25 15:36:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-security sec-v3.17-rc2 for you to fetch changes up to 8fe7a268b18ebc89203c766b020b9e32f1cfeebf: tomoyo: Fix pathname calculation breakage. (2014-08-26 21:52:09 -0500) - Tetsuo Handa (1): tomoyo: Fix pathname calculation breakage. security/tomoyo/realpath.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT/mw0AAoJELF1z6mPGSryE80H/32KcZ50yKf8BdQ8TzcvNQQf pOFkdJsekS6YUQDRN22Qcf2tBHGI2YjaALN0xiPfhHNbXFNzDzpklGXEz6NU58DT t1i9jXB4Ks8+ydl5MU3zPpsuEdcOBuIPv40E5fWi7jS3X27RjerKgiD0h+nGtbpT mbF2KskQx6oAF5MpKkb/2fYzopkcwwZtn8GNjU6mhz74ndenluuN6Z8t39RRjzkd 1lb+3yOefpMjQZ3KCjEddmcwHw8EFOL0UvUfV18FXV7FaUoNaeNGqWW6xIvm2PH1 clj9KifHg0D2RrKaxO1mKQRvfDkzwnFw/yTBtC+w3SXxtmXgQa+0iY/WVh02jXA= =VO9O -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pci/pci-sysfs: Set pci interface in uppercase
On Wed, Aug 27, 2014 at 11:10:42PM +0200, Ricardo Ribalda Delgado wrote: > Hello Greg > > On Wed, Aug 27, 2014 at 11:04 PM, Greg KH wrote: > > On Wed, Aug 27, 2014 at 10:56:57PM +0200, Ricardo Ribalda Delgado wrote: > >> No worries, > >> > >> I have to mark for stable it or Bjorn? It it is me, how :) ? > > > > Bjorn can when he applies it, for details on the process, see the kernel > > file Documentation/stable_kernel_rules.txt > > > >> ps: For other people reading this thread, the kmod/modprobe is in > >> http://anonscm.debian.org/cgit/users/md/kmod.git/tree/libkmod/libkmod-index.c > >> and handles all the modalias as strings without differing the type. > > > > That sounds wrong, and odds are, will cause more problems over time. > > These are hex values, not strings :( > > I totally see your point, but I disagree on the method. > > I think is our resposibility (modalias/file2alias) to provide a > matcheable string, otherwise modprobe should be aware of all the types > (pci, usb, spi, vmbus.) > > As we keep adding types, and they don't follow any standard, we would > be adding a dependecy between kmod and the kernel, and duplicating > code. That is bad systemwise > > Maybe the code on kmod should not be case sensitive, that is all :) But this is a class field, which is a bit field, so it can't be compared with a string compare, as it's a numerical value, not a string... So maybe kmod needs to be fixed up? 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: Resend Re: [PATCH v6] usb:serial:pl2303: add GPIOs interface on PL2303
On Tue, Aug 12, 2014 at 04:02:59PM +0200, Johan Hovold wrote: > On Sat, Aug 09, 2014 at 02:46:56AM +0800, Wang YanQing wrote: > > On Fri, Aug 08, 2014 at 09:54:42AM +0200, Johan Hovold wrote: > > > On Fri, Aug 08, 2014 at 03:10:34AM +0800, Wang YanQing wrote: > > > > On Tue, Aug 05, 2014 at 03:54:08PM +0200, Johan Hovold wrote: > > > > > > > I noticed that setting direction to output and setting the gpio > > > > > > > high has > > > > > > > no effect on the read-back value (i.e. I still read back 0) for my > > > > > > > pl2303hx (note that my device has no easily accessible gpios so I > > > > > > > haven't verified the actual state of the output pin). > > > > > > > > > > > > > > What happens on your system? Is the read-back value still 0, even > > > > > > > when > > > > > > > the GPIO output is actually high? Should we return the cached > > > > > > > value in > > > > > > > this case? > > > > > > > > > > > > If i set direction to output, then I could control gpio high and low > > > > > > by set 1 or 0, and the read-back value is 1 or 0 according to high > > > > > > and > > > > > > low(I test high and low by oscillscope) > > > > > > > > > > > > I test it with my pl2303hx with only two gpios. > > > > > > > > > > > > Could you use usbmon to see whether the traffic is right according > > > > > > to comment in struct pl2303_gpio? > > > > > > > > > > The traffic appears correct judging from the debug output (which I > > > > > trust). Output-enable is reflected in register 0x81, but the value > > > > > isn't. > > > > > > > > > > What is the lsusb -v output for your device? > > > > > > > > Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 > > > > Serial Port. > > > > > > You forgot the verbose flag (-v). > > Sorry, below is output with -v: > > Bus 002 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial > > Port > > Device Descriptor: > > bLength18 > > bDescriptorType 1 > > bcdUSB 1.10 > > bDeviceClass0 (Defined at Interface level) > > bDeviceSubClass 0 > > bDeviceProtocol 0 > > bMaxPacketSize064 > > idVendor 0x067b Prolific Technology, Inc. > > idProduct 0x2303 PL2303 Serial Port > > bcdDevice3.00 > > You seem to have an HX device, whereas mine is an HXD (rev D) with > bcdDevice 4.00. That could account for the different behaviour of the > GPIO state/value register. > > How did you figure out which registers to use? Were you sniffing the > traffic of some driver for some other OS? And does your device only have > two GPIOs and not four like the HX rev D? After I found I need to use GPIOs in pl2303, I found below patch in Internet firstly: http://comments.gmane.org/gmane.linux.usb.general/65066 Then I verified the protocol by sniffing the traffic of some driver for some other OS running in virtualbox, and host OS is linux:) Prolific has pl2303 gpio test program (.exe) for windows, maybe you could find it from Internet. It support HXA and HXD, I use it to test two gpios in my pl2303HXA, and analyze output of usbmon. Yes, my device only have two GPIOs. > > > > > > It is strange your device doesn't work, I verify the control method by > > > > analyze usbmon output from linux host which has VirtualBox running > > > > gpio test program, but I don't have right to distribute the gpio test > > > > program I think, so I can't help you to figure out why it doesn't work > > > > for your device. > > > > > > What do you use the gpio test program for? I thought you verified the > > > gpios with a scope? > > > > Yes, I verified gpios with a scope. > > > > " > > You must allocate the buffer dynamically as some platforms cannot do > > DMA to the stack. > > " > > Thanks very much for point out it, could you clarify it? > > I want to know the reason. > > The memory where the stack resides might not be available for DMA, and > even if it is, there could still be problems with cache coherency. It is still vague: stack memory maybe resident higher place than normal memory, but I don't think kmalloc could be immune from this problem, unless we use GFP_DMA? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis wrote:
> >
> >
> >
> > Doing strcmp("System RAM") is rather a hack. Is there nothing in
> > resource.flags which can be used? Or added otherwise?
>
> I agree except this mimics the page_is_ram function:
>
> while ((res.start < res.end) &&
> (find_next_iomem_res(, "System RAM", true) >= 0)) {
Yeah. Sigh.
> So it passes the same literal string which then find_next does the
> same strcmp on it:
>
> if (p->flags != res->flags)
> continue;
> if (name && strcmp(p->name, name))
> continue;
>
> I should add back in the check to insure name is not NULL.
If we're still at 1+ hours then little bodges like this are nowhere
near sufficient and sterner stuff will be needed.
Do we actually need the test? My googling turns up zero instances of
anyone reporting the "ioremap on RAM pfn" warning.
Where's the rest of the time being spent?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mm/slab: use percpu allocator for cpu cache
One minor nit. Otherwise
Acked-by: Christoph Lameter
On Thu, 21 Aug 2014, Joonsoo Kim wrote:
> @@ -2041,56 +1982,63 @@ static size_t calculate_slab_order(struct kmem_cache
> *cachep,
> return left_over;
> }
>
> +static int alloc_kmem_cache_cpus(struct kmem_cache *cachep, int entries,
> + int batchcount)
> +{
> + cachep->cpu_cache = __alloc_kmem_cache_cpus(cachep, entries,
> + batchcount);
> + if (!cachep->cpu_cache)
> + return 1;
> +
> + return 0;
> +}
Do we really need this trivial function? It doesnt do anything useful as
far as I can tell.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support
On Tue, 2014-08-26 at 21:19 -0500, Lu Jingchang-B35083 wrote: > >-Original Message- > >From: Wood Scott-B07421 > >Sent: Wednesday, August 27, 2014 6:51 AM > >To: Lu Jingchang-B35083 > >Cc: mturque...@linaro.org; linuxppc-...@lists.ozlabs.org; linux- > >ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms > >CLK_OF_DECLARE support > > > >On Fri, 2014-08-22 at 17:34 +0800, Jingchang Lu wrote: > >> +CLK_OF_DECLARE(ppc_core_pll_v1, "fsl,qoriq-core-pll-1.0", > >core_pll_init); > >> +CLK_OF_DECLARE(ppc_core_pll_v2, "fsl,qoriq-core-pll-2.0", > >core_pll_init); > >> +CLK_OF_DECLARE(ppc_core_mux_v1, "fsl,qoriq-core-mux-1.0", > >core_mux_init); > >> +CLK_OF_DECLARE(ppc_core_mux_v2, "fsl,qoriq-core-mux-2.0", > >core_mux_init); > > > >What does this do that the existing platform driver and match table > >don't? Why is it needed for ARM when PPC didn't need it? > > > >-Scott > > > Common clk init on ARM platform is initialized earlier via of_clk_init() > instead of > driver probe method, the of_clk_init will walk a __clk_of_table to init each > clk provider > in the table, the CLK_OF_DECLARE() macro puts a supported clk in the > __clk_of_table for > it initializing on starup, and the clk system has added some common clk such > as "fixed-clk" > to this table already. > So here I add our specific clk init declaration to consist this framework, > and the driver > probe function will not be needed on ARM. OK... Is there any reason why the new method won't work on PPC? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: stmmac: fix warning from Sparse for socfpga
From: Ley Foon Tan Date: Tue, 26 Aug 2014 15:11:16 +0800 > @@ -119,7 +119,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac > *dwmac, struct device * > return -EINVAL; > } > > - dwmac->splitter_base = (void *)devm_ioremap_resource(dev, > + dwmac->splitter_base = > + (void __iomem *)devm_ioremap_resource(dev, > _splitter); Please either put this entire call on one line (it'll only be slightly over 80 columns, which is fine), or indent it properly. And by properly I meant that the second and subsequent lines of a function call must be indented precisely to the first column after the openning parenthesis of the function call on the first line. You must use the appropriate number of TAB and SPACE characters necessary to do so. If it is indented using only TAB characters, it is very likely that you are doing it wrong. 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 v2] sched: Reduce contention in update_cfs_rq_blocked_load
On Wed, 2014-08-27 at 10:34 -0700, Jason Low wrote:
> On Tue, 2014-08-26 at 16:24 -0700, Paul Turner wrote:
> > On Tue, Aug 26, 2014 at 4:11 PM, Jason Low wrote:
> > > Based on perf profiles, the update_cfs_rq_blocked_load function constantly
> > > shows up as taking up a noticeable % of system run time. This is
> > > especially
> > > apparent on larger numa systems.
> > >
> > > Much of the contention is in __update_cfs_rq_tg_load_contrib when we're
> > > updating the tg load contribution stats. However, it was noticed that the
> > > values often don't get modified by much. In fact, much of the time, they
> > > don't get modified at all. However, the update can always get attempted
> > > due
> > > to force_update.
> > >
> > > In this patch, we remove the force_update in only the
> > > __update_cfs_rq_tg_load_contrib. Thus the tg load contrib stats now get
> > > modified only if the delta is large enough (in the current code, they get
> > > updated when the delta is larger than 12.5%). This is a way to rate-limit
> > > the updates while largely keeping the values accurate.
> > >
> > > When testing this change with AIM7 workloads, we found that it was able to
> > > reduce the overhead of the function by up to a factor of 20x.
> >
> > Looks reasonable.
> >
> > >
> > > Cc: Yuyang Du
> > > Cc: Waiman Long
> > > Cc: Mel Gorman
> > > Cc: Mike Galbraith
> > > Cc: Rik van Riel
> > > Cc: Aswin Chandramouleeswaran
> > > Cc: Chegu Vinod
> > > Cc: Scott J Norton
> > > Signed-off-by: Jason Low
> > > ---
> > > kernel/sched/fair.c | 10 --
> > > 1 files changed, 4 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index fea7d33..7a6e18b 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -2352,8 +2352,7 @@ static inline u64 __synchronize_entity_decay(struct
> > > sched_entity *se)
> > > }
> > >
> > > #ifdef CONFIG_FAIR_GROUP_SCHED
> > > -static inline void __update_cfs_rq_tg_load_contrib(struct cfs_rq *cfs_rq,
> > > -int force_update)
> > > +static inline void __update_cfs_rq_tg_load_contrib(struct cfs_rq *cfs_rq)
> > > {
> > > struct task_group *tg = cfs_rq->tg;
> > > long tg_contrib;
> > > @@ -2361,7 +2360,7 @@ static inline void
> > > __update_cfs_rq_tg_load_contrib(struct cfs_rq *cfs_rq,
> > > tg_contrib = cfs_rq->runnable_load_avg + cfs_rq->blocked_load_avg;
> > > tg_contrib -= cfs_rq->tg_load_contrib;
> > >
> > > - if (force_update || abs(tg_contrib) > cfs_rq->tg_load_contrib /
> > > 8) {
> >
> > Another option with slightly higher accuracy would be to increase the
> > sensitivity here when force_update == 1.
> >
> > E.g.:
> > abs(tg_contrib) > cfs_rq->tg_load_contrib / (8 * (1 + force_update))) {
> > ...
> >
> > Alternatively we could bound total inaccuracy:
> >int divisor = force_update ? NR_CPUS : 8;
> >if (abs(tg_contrib) > cfs_rq->tg_load_contrib / divisor) { ...
> >
> >
> > [ And probably rename force_update to want_update ]
>
> Out of the 2 additional options, I think the first one is better. The
> other option of using NR_CPUS looks like we're increasing the update
> rate as the system gets larger, and its the larger systems that are
> typically more affected by the contention.
Probably num_present_cpus() will be better than NR_CPUS, which can
be much larger than the actual cpus present.
>
> Do you prefer either of the 2 other options over this v2 patch? If so, I
> can test and send out a new patch, otherwise, I'll keep this current v2
> patch.
If there are multiple non-forced updates, option 1's error seems to
accumulate and non-bounded as we do not actually update?
Is this a concern?
Thanks.
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] x86: Speed up ioremap operations
On 8/27/2014 4:20 PM, Andrew Morton wrote: > On Wed, 27 Aug 2014 16:15:28 -0700 Mike Travis wrote: > >> >>> There are two causes for requiring a restart/reload of the drivers. First is periodic preventive maintenance (PM) and the second is if any of the devices experience a fatal error. Both of these trigger this excessively long delay in bringing the system back up to full capability. The problem was tracked down to a very slow IOREMAP operation and the excessively long ioresource lookup to insure that the user is not attempting to ioremap RAM. These patches provide a speed up to that function. >>> >>> With what result? >>> >> >> Early measurements on our in house lab system (with far fewer cpus >> and memory) shows about a 60-75% increase. They have a 31 devices, >> 3000+ cpus, 10+Tb of memory. We have 20 devices, 480 cpus, ~2Tb of >> memory. I expect their ioresource list to be about 5-10 times longer. >> [But their system is in production so we have to wait for the next >> scheduled PM interval before a live test can be done.] > > So you expect 1+ hours? That's still nuts. > Actually I expect a lot better improvement. We are removing cycles through the I/O resource list and the longer the list, the longer it takes to pass completely through it. As mentioned for a 128M I/O BAR region, that is 32 passes, so we are removing 31 of them. 31 times a list 5-10 times longer should be a much better overall improvement in the ioremap time. The startup time of the device will still be there, though we are encouraging the vendor to look at starting them up in parallel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] usb: phy: twl4030-usb: Simplify phy init to use runtime PM
We can now let the interrupt and delayed work do all that's
needed with runtime PM.
Signed-off-by: Tony Lindgren
---
drivers/phy/phy-twl4030-usb.c | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index bc28ecc..a292db0 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -471,16 +471,8 @@ static int twl4030_phy_power_on(struct phy *phy)
twl4030_usb_set_mode(twl, twl->usb_mode);
if (twl->usb_mode == T2_USB_MODE_ULPI)
twl4030_i2c_access(twl, 0);
+ schedule_delayed_work(>id_workaround_work, 0);
- /*
-* XXX When VBUS gets driven after musb goes to A mode,
-* ID_PRES related interrupts no longer arrive, why?
-* Register itself is updated fine though, so we must poll.
-*/
- if (twl->linkstat == OMAP_MUSB_ID_GROUND) {
- cancel_delayed_work(>id_workaround_work);
- schedule_delayed_work(>id_workaround_work, HZ);
- }
return 0;
}
@@ -612,16 +604,9 @@ static void twl4030_id_workaround_work(struct work_struct
*work)
static int twl4030_phy_init(struct phy *phy)
{
struct twl4030_usb *twl = phy_get_drvdata(phy);
- enum omap_musb_vbus_id_status status;
pm_runtime_get_sync(twl->dev);
- status = twl4030_usb_linkstat(twl);
- twl->linkstat = status;
-
- if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
- omap_musb_mailbox(twl->linkstat);
-
- sysfs_notify(>dev->kobj, NULL, "vbus");
+ schedule_delayed_work(>id_workaround_work, 0);
pm_runtime_mark_last_busy(twl->dev);
pm_runtime_put_autosuspend(twl->dev);
@@ -698,6 +683,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl->dev= >dev;
twl->irq= platform_get_irq(pdev, 0);
twl->vbus_supplied = false;
+ twl->linkstat = -EINVAL;
twl->asleep = 1;
twl->linkstat = OMAP_MUSB_UNKNOWN;
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] Clean-up for twl4030-usb
Hi, Here are few more patches for v3.18 to clean up twl4030-usb. These are based on the two regression fixes I sent earlier: [PATCH] usb: phy: twl4030-usb: Fix regressions to runtime PM on omaps [PATCH] usb: phy: twl4030-usb: Fix lost interrupts after ID pin goes down For testing with v3.17-rc2, you probably also want to revert commit a9232076374334ca2bc2a448dfde96d38a54349a until that hits the mainline tree. And you may also want to apply the following patch if testing with PM: [PATCH] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators I've also pushed these patches with the optional patches into a temporary testing branch at [1]. Regards, Tony [1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git omap-for-v3.17/testing-pending-usb Tony Lindgren (5): usb: phy: twl4030-usb: Remove unused irq_enabled usb: phy: twl4030-usb: Simplify phy init to use runtime PM usb: phy: twl4030-usb: Move code from twl4030_phy_power to the runtime PM calls usb: phy: twl4030-usb: Remove asleep and rely on runtime PM usb: phy: twl4030-usb: Use mutex instead of spinlock for protecting the data drivers/phy/phy-twl4030-usb.c | 124 ++ drivers/usb/phy/phy-twl6030-usb.c | 2 - 2 files changed, 46 insertions(+), 80 deletions(-) -- 1.8.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: intel_pstate: Add CPU ID for Braswell processor
On Wednesday, August 27, 2014 09:47:45 AM Dirk Brandewie wrote:
> On 08/22/2014 03:19 AM, Viresh Kumar wrote:
> > On 22 August 2014 15:35, Mika Westerberg
> > wrote:
> >> This is pretty much the same as Intel Baytrail, only the CPU ID is
> >> different. Add the new ID to the supported CPU list.
> >>
> >> Signed-off-by: Mika Westerberg
> >> Cc: Dirk Brandewie
> >
> > Dirk might be away on holidays..
>
> Yes Sorry
>
> Acked-by: Dirk Brandewie
Queued up for 3.17-rc3, thanks!
>
> >
> >> ---
> >> drivers/cpufreq/intel_pstate.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/cpufreq/intel_pstate.c
> >> b/drivers/cpufreq/intel_pstate.c
> >> index c5eac949760d..a3cf8994160b 100644
> >> --- a/drivers/cpufreq/intel_pstate.c
> >> +++ b/drivers/cpufreq/intel_pstate.c
> >> @@ -660,6 +660,7 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[]
> >> = {
> >> ICPU(0x3f, core_params),
> >> ICPU(0x45, core_params),
> >> ICPU(0x46, core_params),
> >> + ICPU(0x4c, byt_params),
> >> ICPU(0x4f, core_params),
> >> ICPU(0x56, core_params),
> >> {}
> >
> > Acked-by: Viresh Kumar
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pm" 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-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
I speak only for myself.
Rafael J. Wysocki, 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/
[PATCH 1/5] usb: phy: twl4030-usb: Remove unused irq_enabled
It's not being used any longer.
Signed-off-by: Tony Lindgren
---
drivers/phy/phy-twl4030-usb.c | 2 --
drivers/usb/phy/phy-twl6030-usb.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 9cd33a4..bc28ecc 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -164,7 +164,6 @@ struct twl4030_usb {
enum omap_musb_vbus_id_status linkstat;
boolvbus_supplied;
u8 asleep;
- boolirq_enabled;
struct delayed_work id_workaround_work;
};
@@ -755,7 +754,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
* set_host() and/or set_peripheral() ... OTG_capable boards
* need both handles, otherwise just one suffices.
*/
- twl->irq_enabled = true;
status = devm_request_threaded_irq(twl->dev, twl->irq, NULL,
twl4030_usb_irq, IRQF_TRIGGER_FALLING |
IRQF_TRIGGER_RISING | IRQF_ONESHOT, "twl4030_usb", twl);
diff --git a/drivers/usb/phy/phy-twl6030-usb.c
b/drivers/usb/phy/phy-twl6030-usb.c
index 04778cf..44ea082 100644
--- a/drivers/usb/phy/phy-twl6030-usb.c
+++ b/drivers/usb/phy/phy-twl6030-usb.c
@@ -104,7 +104,6 @@ struct twl6030_usb {
int irq2;
enum omap_musb_vbus_id_status linkstat;
u8 asleep;
- boolirq_enabled;
boolvbus_enable;
const char *regulator;
};
@@ -373,7 +372,6 @@ static int twl6030_usb_probe(struct platform_device *pdev)
INIT_WORK(>set_vbus_work, otg_set_vbus_work);
- twl->irq_enabled = true;
status = request_threaded_irq(twl->irq1, NULL, twl6030_usbotg_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
IRQF_ONESHOT,
"twl6030_usb", twl);
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] usb: phy: twl4030-usb: Remove asleep and rely on runtime PM
There's no longer need for tracking the phy state in the driver
with asleep, we can now rely on runtime PM.
Signed-off-by: Tony Lindgren
---
drivers/phy/phy-twl4030-usb.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 519cc90..24ff3c6 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -163,7 +163,6 @@ struct twl4030_usb {
int irq;
enum omap_musb_vbus_id_status linkstat;
boolvbus_supplied;
- u8 asleep;
struct delayed_work id_workaround_work;
};
@@ -388,14 +387,13 @@ static int twl4030_usb_runtime_suspend(struct device *dev)
struct twl4030_usb *twl = dev_get_drvdata(dev);
dev_dbg(twl->dev, "%s\n", __func__);
- if (twl->asleep)
+ if (pm_runtime_suspended(dev))
return 0;
__twl4030_phy_power(twl, 0);
regulator_disable(twl->usb1v5);
regulator_disable(twl->usb1v8);
regulator_disable(twl->usb3v1);
- twl->asleep = 1;
return 0;
}
@@ -406,7 +404,7 @@ static int twl4030_usb_runtime_resume(struct device *dev)
int res;
dev_dbg(twl->dev, "%s\n", __func__);
- if (!twl->asleep)
+ if (pm_runtime_active(dev))
return 0;
res = regulator_enable(twl->usb3v1);
@@ -435,7 +433,6 @@ static int twl4030_usb_runtime_resume(struct device *dev)
twl4030_usb_read(twl, PHY_CLK_CTRL) |
(PHY_CLK_CTRL_CLOCKGATING_EN |
PHY_CLK_CTRL_CLK32K_EN));
- twl->asleep = 0;
return 0;
}
@@ -560,10 +557,10 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
*/
if ((status == OMAP_MUSB_VBUS_VALID) ||
(status == OMAP_MUSB_ID_GROUND)) {
- if (twl->asleep)
+ if (pm_runtime_suspended(twl->dev))
pm_runtime_get_sync(twl->dev);
} else {
- if (!twl->asleep) {
+ if (pm_runtime_active(twl->dev)) {
pm_runtime_mark_last_busy(twl->dev);
pm_runtime_put_autosuspend(twl->dev);
}
@@ -572,7 +569,7 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
}
/* don't schedule during sleep - irq works right then */
- if (status == OMAP_MUSB_ID_GROUND && !twl->asleep) {
+ if (status == OMAP_MUSB_ID_GROUND && pm_runtime_active(twl->dev)) {
cancel_delayed_work(>id_workaround_work);
schedule_delayed_work(>id_workaround_work, HZ);
}
@@ -674,7 +671,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl->irq= platform_get_irq(pdev, 0);
twl->vbus_supplied = false;
twl->linkstat = -EINVAL;
- twl->asleep = 1;
twl->linkstat = OMAP_MUSB_UNKNOWN;
twl->phy.dev= twl->dev;
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] usb: phy: twl4030-usb: Move code from twl4030_phy_power to the runtime PM calls
We don't need twl4030_phy_power() any longer now that we have
the runtime PM calls. Let's get rid of it as it's confusing.
No functional changes, just move the code and use res instead
of ret as we are not returning that value.
Signed-off-by: Tony Lindgren
---
drivers/phy/phy-twl4030-usb.c | 72 +++
1 file changed, 31 insertions(+), 41 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index a292db0..519cc90 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -383,45 +383,6 @@ static void __twl4030_phy_power(struct twl4030_usb *twl,
int on)
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) < 0);
}
-static void twl4030_phy_power(struct twl4030_usb *twl, int on)
-{
- int ret;
-
- if (on) {
- ret = regulator_enable(twl->usb3v1);
- if (ret)
- dev_err(twl->dev, "Failed to enable usb3v1\n");
-
- ret = regulator_enable(twl->usb1v8);
- if (ret)
- dev_err(twl->dev, "Failed to enable usb1v8\n");
-
- /*
-* Disabling usb3v1 regulator (= writing 0 to VUSB3V1_DEV_GRP
-* in twl4030) resets the VUSB_DEDICATED2 register. This reset
-* enables VUSB3V1_SLEEP bit that remaps usb3v1 ACTIVE state to
-* SLEEP. We work around this by clearing the bit after usv3v1
-* is re-activated. This ensures that VUSB3V1 is really active.
-*/
- twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB_DEDICATED2);
-
- ret = regulator_enable(twl->usb1v5);
- if (ret)
- dev_err(twl->dev, "Failed to enable usb1v5\n");
-
- __twl4030_phy_power(twl, 1);
- twl4030_usb_write(twl, PHY_CLK_CTRL,
- twl4030_usb_read(twl, PHY_CLK_CTRL) |
- (PHY_CLK_CTRL_CLOCKGATING_EN |
- PHY_CLK_CTRL_CLK32K_EN));
- } else {
- __twl4030_phy_power(twl, 0);
- regulator_disable(twl->usb1v5);
- regulator_disable(twl->usb1v8);
- regulator_disable(twl->usb3v1);
- }
-}
-
static int twl4030_usb_runtime_suspend(struct device *dev)
{
struct twl4030_usb *twl = dev_get_drvdata(dev);
@@ -430,7 +391,10 @@ static int twl4030_usb_runtime_suspend(struct device *dev)
if (twl->asleep)
return 0;
- twl4030_phy_power(twl, 0);
+ __twl4030_phy_power(twl, 0);
+ regulator_disable(twl->usb1v5);
+ regulator_disable(twl->usb1v8);
+ regulator_disable(twl->usb3v1);
twl->asleep = 1;
return 0;
@@ -439,12 +403,38 @@ static int twl4030_usb_runtime_suspend(struct device *dev)
static int twl4030_usb_runtime_resume(struct device *dev)
{
struct twl4030_usb *twl = dev_get_drvdata(dev);
+ int res;
dev_dbg(twl->dev, "%s\n", __func__);
if (!twl->asleep)
return 0;
- twl4030_phy_power(twl, 1);
+ res = regulator_enable(twl->usb3v1);
+ if (res)
+ dev_err(twl->dev, "Failed to enable usb3v1\n");
+
+ res = regulator_enable(twl->usb1v8);
+ if (res)
+ dev_err(twl->dev, "Failed to enable usb1v8\n");
+
+ /*
+* Disabling usb3v1 regulator (= writing 0 to VUSB3V1_DEV_GRP
+* in twl4030) resets the VUSB_DEDICATED2 register. This reset
+* enables VUSB3V1_SLEEP bit that remaps usb3v1 ACTIVE state to
+* SLEEP. We work around this by clearing the bit after usv3v1
+* is re-activated. This ensures that VUSB3V1 is really active.
+*/
+ twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB_DEDICATED2);
+
+ res = regulator_enable(twl->usb1v5);
+ if (res)
+ dev_err(twl->dev, "Failed to enable usb1v5\n");
+
+ __twl4030_phy_power(twl, 1);
+ twl4030_usb_write(twl, PHY_CLK_CTRL,
+ twl4030_usb_read(twl, PHY_CLK_CTRL) |
+ (PHY_CLK_CTRL_CLOCKGATING_EN |
+ PHY_CLK_CTRL_CLK32K_EN));
twl->asleep = 0;
return 0;
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] usb: phy: twl4030-usb: Use mutex instead of spinlock for protecting the data
We're using threaded irq on a I2C bus and we're sleeping in
twl4030_usb_irq() as it calls twl4030_usb_linkstat() which
calls the i2c functions. If we ever need to lock for longer
I2C transaction sequences a mutex will allow us to do that
easily.
Signed-off-by: Tony Lindgren
---
drivers/phy/phy-twl4030-usb.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 24ff3c6..1e0e2d1 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -28,7 +28,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -155,7 +154,7 @@ struct twl4030_usb {
struct regulator*usb3v1;
/* for vbus reporting with irqs disabled */
- spinlock_t lock;
+ struct mutexlock;
/* pin configuration */
enum twl4030_usb_mode usb_mode;
@@ -516,13 +515,12 @@ static ssize_t twl4030_usb_vbus_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct twl4030_usb *twl = dev_get_drvdata(dev);
- unsigned long flags;
int ret = -EINVAL;
- spin_lock_irqsave(>lock, flags);
+ mutex_lock(>lock);
ret = sprintf(buf, "%s\n",
twl->vbus_supplied ? "on" : "off");
- spin_unlock_irqrestore(>lock, flags);
+ mutex_unlock(>lock);
return ret;
}
@@ -536,12 +534,12 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
status = twl4030_usb_linkstat(twl);
- spin_lock_irq(>lock);
+ mutex_lock(>lock);
if (status >= 0 && status != twl->linkstat) {
twl->linkstat = status;
status_changed = true;
}
- spin_unlock_irq(>lock);
+ mutex_unlock(>lock);
if (status_changed) {
/* FIXME add a set_power() method so that B-devices can
@@ -695,8 +693,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
if (IS_ERR(phy_provider))
return PTR_ERR(phy_provider);
- /* init spinlock for workqueue */
- spin_lock_init(>lock);
+ /* init mutex for workqueue */
+ mutex_init(>lock);
INIT_DELAYED_WORK(>id_workaround_work, twl4030_id_workaround_work);
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On 8/27/2014 4:18 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 16:09:09 -0700 Mike Travis wrote:
>
>>
...
--- linux.orig/kernel/resource.c
+++ linux/kernel/resource.c
@@ -494,6 +494,43 @@ int __weak page_is_ram(unsigned long pfn
}
EXPORT_SYMBOL_GPL(page_is_ram);
+/*
+ * Search for a resouce entry that fully contains the specified region.
+ * If found, return 1 if it is RAM, 0 if not.
+ * If not found, or region is not fully contained, return -1
+ *
+ * Used by the ioremap functions to insure user not remapping RAM and is
as
+ * vast speed up over walking through the resource table page by page.
+ */
+int __weak region_is_ram(resource_size_t start, unsigned long size)
+{
+ struct resource *p;
+ resource_size_t end = start + size - 1;
+ int flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+ const char *name = "System RAM";
+ int ret = -1;
+
+ read_lock(_lock);
+ for (p = iomem_resource.child; p ; p = p->sibling) {
+ if (end < p->start)
+ continue;
+
+ if (p->start <= start && end <= p->end) {
+ /* resource fully contains region */
+ if ((p->flags != flags) || strcmp(p->name, name))
+ ret = 0;
+ else
+ ret = 1;
+ break;
+ }
+ if (p->end < start)
+ break; /* not found */
+ }
+ read_unlock(_lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(region_is_ram);
>>>
>>> Exporting a __weak symbol is strange. I guess it works, but neither
>>> the __weak nor the export are actually needed?
>>>
>>
>> I mainly used 'weak' and export because that was what the page_is_ram
>> function was using. Most likely this won't be used anywhere else but
>> I wasn't sure. I can certainly remove the weak and export, at least
>> until it's actually needed?
>
> Several architectures implement custom page_is_ram(), so they need the
> __weak. region_is_ram() needs neither so yes, they should be removed.
Okay.
>
>
>
> Doing strcmp("System RAM") is rather a hack. Is there nothing in
> resource.flags which can be used? Or added otherwise?
I agree except this mimics the page_is_ram function:
while ((res.start < res.end) &&
(find_next_iomem_res(, "System RAM", true) >= 0)) {
So it passes the same literal string which then find_next does the
same strcmp on it:
if (p->flags != res->flags)
continue;
if (name && strcmp(p->name, name))
continue;
I should add back in the check to insure name is not NULL.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rcu: Make nocb leader kthreads process pending callbacks after spawning
On Wed, Aug 27, 2014 at 07:08:37PM -0400, Pranith Kumar wrote: > On Wed, Aug 27, 2014 at 5:47 PM, Paul E. McKenney > wrote: > > > > Thank you, Pranith, queued. I have also backported to v3.17-rc2, > > and am testing both. A sneak preview of the backport is shown below, > > please let me know if you see any problems with it. (The reason for > > the backport is to submit to 3.17 as a fix for a regression.) > > Looks good to me! And both versions pass short rcutorture tests. Amit, could you please try running your test with the backported version of the patch? One more time? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] intel_pstate: Turn per cpu printk into pr_debug
On Wednesday, August 27, 2014 10:27:58 AM Dirk Brandewie wrote:
> On 08/27/2014 10:17 AM, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > On larger systems intel_pstate currently spams the boot up
> > log with its "Intel pstate controlling ..." message for each CPU.
> > It's the only subsystem that prints a message for each
> > CPU.
> >
> > Turn the message into a pr_debug.
> >
> > Signed-off-by: Andi Kleen
>
> Acked-by: Dirk Brandewie
Queued up for 3.17-rc3, thanks!
> > ---
> > drivers/cpufreq/intel_pstate.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > index c5eac94..17be734 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -688,7 +688,7 @@ static int intel_pstate_init_cpu(unsigned int cpunum)
> >
> > add_timer_on(>timer, cpunum);
> >
> > - pr_info("Intel pstate controlling: cpu %d\n", cpunum);
> > + pr_debug("Intel pstate controlling: cpu %d\n", cpunum);
> >
> > return 0;
> > }
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
I speak only for myself.
Rafael J. Wysocki, 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 percpu/for-3.18-consistent-ops] Revert "powerpc: Replace __get_cpu_var uses"
On Thu, 28 Aug 2014, Stephen Rothwell wrote: > > Ok. Once I figure out what went wrong. This went through Feng's build > > system and I though he did a powerpc build. So it must be a difference > > configuration on powerpc. > > Were the patches tested on top of v3.17-rc1? My build was a powerpc > ppc64_defconfig. It is possible that some other change interacted with > this, but there are not many other arch/powerpc changes after v3.17-rc1 > and none seem obvious. Yes the latest build test by Feng was on rc1. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] x86: Speed up ioremap operations
On Wed, 27 Aug 2014 16:15:28 -0700 Mike Travis wrote: > > > > >> There are two causes for requiring a restart/reload of the drivers. > >> First is periodic preventive maintenance (PM) and the second is if > >> any of the devices experience a fatal error. Both of these trigger > >> this excessively long delay in bringing the system back up to full > >> capability. > >> > >> The problem was tracked down to a very slow IOREMAP operation and > >> the excessively long ioresource lookup to insure that the user is > >> not attempting to ioremap RAM. These patches provide a speed up > >> to that function. > > > > With what result? > > > > Early measurements on our in house lab system (with far fewer cpus > and memory) shows about a 60-75% increase. They have a 31 devices, > 3000+ cpus, 10+Tb of memory. We have 20 devices, 480 cpus, ~2Tb of > memory. I expect their ioresource list to be about 5-10 times longer. > [But their system is in production so we have to wait for the next > scheduled PM interval before a live test can be done.] So you expect 1+ hours? That's still nuts. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 16:09:09 -0700 Mike Travis wrote:
>
> >>
> >> ...
> >>
> >> --- linux.orig/kernel/resource.c
> >> +++ linux/kernel/resource.c
> >> @@ -494,6 +494,43 @@ int __weak page_is_ram(unsigned long pfn
> >> }
> >> EXPORT_SYMBOL_GPL(page_is_ram);
> >>
> >> +/*
> >> + * Search for a resouce entry that fully contains the specified region.
> >> + * If found, return 1 if it is RAM, 0 if not.
> >> + * If not found, or region is not fully contained, return -1
> >> + *
> >> + * Used by the ioremap functions to insure user not remapping RAM and is
> >> as
> >> + * vast speed up over walking through the resource table page by page.
> >> + */
> >> +int __weak region_is_ram(resource_size_t start, unsigned long size)
> >> +{
> >> + struct resource *p;
> >> + resource_size_t end = start + size - 1;
> >> + int flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> >> + const char *name = "System RAM";
> >> + int ret = -1;
> >> +
> >> + read_lock(_lock);
> >> + for (p = iomem_resource.child; p ; p = p->sibling) {
> >> + if (end < p->start)
> >> + continue;
> >> +
> >> + if (p->start <= start && end <= p->end) {
> >> + /* resource fully contains region */
> >> + if ((p->flags != flags) || strcmp(p->name, name))
> >> + ret = 0;
> >> + else
> >> + ret = 1;
> >> + break;
> >> + }
> >> + if (p->end < start)
> >> + break; /* not found */
> >> + }
> >> + read_unlock(_lock);
> >> + return ret;
> >> +}
> >> +EXPORT_SYMBOL_GPL(region_is_ram);
> >
> > Exporting a __weak symbol is strange. I guess it works, but neither
> > the __weak nor the export are actually needed?
> >
>
> I mainly used 'weak' and export because that was what the page_is_ram
> function was using. Most likely this won't be used anywhere else but
> I wasn't sure. I can certainly remove the weak and export, at least
> until it's actually needed?
Several architectures implement custom page_is_ram(), so they need the
__weak. region_is_ram() needs neither so yes, they should be removed.
Doing strcmp("System RAM") is rather a hack. Is there nothing in
resource.flags which can be used? Or added otherwise?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-next] r8152: replace strncpy with strlcpy
From: Hayes Wang Date: Tue, 26 Aug 2014 10:08:23 +0800 > Replace the strncpy with strlcpy, and use sizeof to determine the > length. > > Signed-off-by: Hayes Wang 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 V3] ACPI / OSL: Make acpi_os_map_cleanup() use call_rcu() to avoid deadlocks
On Wednesday, August 27, 2014 03:11:29 PM Lan Tianyu wrote:
> Deadlock is possible when CPU hotplug and evaluating ACPI method happen
> at the same time.
>
> During CPU hotplug, acpi_cpu_soft_notify() is called under the CPU hotplug
> lock. Then, acpi_cpu_soft_notify() calls acpi_bus_get_device() to obtain
> the struct acpi_device attached to the given ACPI handle. The ACPICA's
> namespace lock will be acquired by acpi_bus_get_device() in the process.
> Thus it is possible to hold the ACPICA's namespace lock under the CPU
> hotplug lock.
>
> Evaluating an ACPI method may involve accessing an operation region in
> system memory and the associated address space will be unmapped under
> the ACPICA's namespace lock after completing the access. Currently, osl.c
> uses RCU to protect memory ranges used by AML. When unmapping them it
> calls synchronize_rcu() in acpi_os_map_cleanup(), but that blocks
> CPU hotplug by acquiring the CPU hotplug lock. Thus it is possible to
> hold the CPU hotplug lock under the ACPICA's namespace lock.
>
> This leads to deadlocks like the following one if AML accessing operation
> regions in memory is executed in parallel with CPU hotplug.
[cut]
> To avoid such deadlocks, modify acpi_os_map_cleanup() to use call_rcu()
> to schedule acpi_os_async_umap() asynchronously to umap memory regions
> that aren't used any more. The umap operation can't be done in the
> call_rcu()'s callback directly because the callback will be called in the
> soft irq context and acpi_unmap() holds mutex lock inside.
>
> Signed-off-by: Lan Tianyu
> [rjw: Subject and changelog.]
> Cc: All applicable
> Signed-off-by: Rafael J. Wysocki
>
> Signed-off-by: Lan Tianyu
> ---
> drivers/acpi/osl.c | 24 +++-
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 3abe9b2..9baef71 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -94,6 +95,7 @@ struct acpi_ioremap {
> acpi_physical_address phys;
> acpi_size size;
> unsigned long refcount;
> + struct rcu_head rcu;
> };
>
> static LIST_HEAD(acpi_ioremaps);
> @@ -423,13 +425,25 @@ static void acpi_os_drop_map_ref(struct acpi_ioremap
> *map)
> list_del_rcu(>list);
> }
>
> +static void acpi_os_async_umap(void *data, async_cookie_t cookie)
> +{
> + struct acpi_ioremap *map = data;
> +
> + acpi_unmap(map->phys, map->virt);
> + kfree(map);
> +}
> +
> +static void acpi_os_map_reclaim(struct rcu_head *rcu)
> +{
> + struct acpi_ioremap *map = container_of(rcu, struct acpi_ioremap, rcu);
> +
> + async_schedule(acpi_os_async_umap, map);
> +}
> +
> static void acpi_os_map_cleanup(struct acpi_ioremap *map)
> {
> - if (!map->refcount) {
> - synchronize_rcu();
> - acpi_unmap(map->phys, map->virt);
> - kfree(map);
> - }
> + if (!map->refcount)
> + call_rcu(>rcu, acpi_os_map_reclaim);
> }
>
> void __ref acpi_os_unmap_iomem(void __iomem *virt, acpi_size size)
>
This goes a bit too far. First, if you need to start an async thread,
you can simply do synchronize_rcu() from there. Second, though, perhaps
we can address the whole deadlock in a different way.
For example, if we do something like the patch below (which I haven't
tested, but it should work if I'm not missing something horribly), we
won't be taking the ACPI namespace lock under the CPU hotplug lock
in acpi_cpu_soft_notify() any more.
Rafael
---
drivers/acpi/processor_driver.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-pm/drivers/acpi/processor_driver.c
===
--- linux-pm.orig/drivers/acpi/processor_driver.c
+++ linux-pm/drivers/acpi/processor_driver.c
@@ -129,7 +129,11 @@ static int acpi_cpu_soft_notify(struct n
if (action == CPU_STARTING || action == CPU_DYING)
return NOTIFY_DONE;
- if (!pr || acpi_bus_get_device(pr->handle, ))
+ if (!pr || !pr->dev)
+ return NOTIFY_DONE;
+
+ device = ACPI_COMPANION(pr->dev);
+ if (!device)
return NOTIFY_DONE;
if (action == CPU_ONLINE) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: softdirty: enable write notifications on VMAs after VM_SOFTDIRTY cleared
On Tue, 26 Aug 2014, Cyrill Gorcunov wrote: > On Tue, Aug 26, 2014 at 06:43:55PM +0300, Kirill A. Shutemov wrote: > > On Tue, Aug 26, 2014 at 07:18:13PM +0400, Cyrill Gorcunov wrote: > > > > Basically, it's safe if only soft-dirty is allowed to modify vm_flags > > > > without down_write(). But why is soft-dirty so special? > > > > > > because how we use this bit, i mean in normal workload this bit won't > > > be used intensively i think so it's not widespread in kernel code > > > > Weak argument to me. Yes. However rarely it's modified, we don't want any chance of it corrupting another flag. VM_SOFTDIRTY is special in the sense that it's maintained in a very different way from the other VM_flags. If we had a little alignment padding space somewhere in struct vm_area_struct, I think I'd jump at Kirill's suggestion to move it out of vm_flags and into a new field: that would remove some other special casing, like the vma merge issue. But I don't think we have such padding space, and we'd prefer not to bloat struct vm_area_struct for it; so maybe it should stay for now. Besides, with Peter's patch, we're also talking about the locking on modifications to vm_page_prot, aren't we? > > > > What about walk through vmas twice: first with down_write() to modify > > vm_flags and vm_page_prot, then downgrade_write() and do > > walk_page_range() on every vma? > > I still it's undeeded, Yes, so long as nothing else is doing the same. No bug yet, that we can see, but a bug in waiting. > but for sure using write-lock/downgrade won't hurt, > so no argues from my side. Yes, Kirill's two-stage suggestion seems the best: down_write quickly scan vmas clearing VM_SOFT_DIRTY and updating vm_page_prot downgrade_write (or up_write, down_read?) slowly walk page tables write protecting and clearing soft-dirty on ptes up_read But please don't mistake me for someone who has a good grasp of soft-dirty: I don't. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] x86: Speed up ioremap operations
On 8/27/2014 4:06 PM, Andrew Morton wrote: > On Wed, 27 Aug 2014 17:59:27 -0500 Mike Travis wrote: > >> >> We have a large university system in the UK that is experiencing >> very long delays modprobing the driver for a specific I/O device. >> The delay is from 8-10 minutes per device and there are 31 devices >> in the system. This 4 to 5 hour delay in starting up those I/O >> devices is very much a burden on the customer. > > That's nuts. Exactly! The customer was (as expected) not terribly pleased... :) > >> There are two causes for requiring a restart/reload of the drivers. >> First is periodic preventive maintenance (PM) and the second is if >> any of the devices experience a fatal error. Both of these trigger >> this excessively long delay in bringing the system back up to full >> capability. >> >> The problem was tracked down to a very slow IOREMAP operation and >> the excessively long ioresource lookup to insure that the user is >> not attempting to ioremap RAM. These patches provide a speed up >> to that function. > > With what result? > Early measurements on our in house lab system (with far fewer cpus and memory) shows about a 60-75% increase. They have a 31 devices, 3000+ cpus, 10+Tb of memory. We have 20 devices, 480 cpus, ~2Tb of memory. I expect their ioresource list to be about 5-10 times longer. [But their system is in production so we have to wait for the next scheduled PM interval before a live test can be done.] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PANIC, hyperv] BUG: unable to handle kernel paging request at ffff880077800004 (hv_ringbuffer_write)
> -Original Message- > From: Sitsofe Wheeler [mailto:sits...@gmail.com] > Sent: Wednesday, August 27, 2014 3:58 PM > To: KY Srinivasan > Cc: Dexuan Cui; Greg Kroah-Hartman; Haiyang Zhang; > de...@linuxdriverproject.org; linux-kernel@vger.kernel.org > Subject: Re: [PANIC, hyperv] BUG: unable to handle kernel paging request at > 88007784 (hv_ringbuffer_write) > > On Wed, Aug 27, 2014 at 06:45:55PM +, KY Srinivasan wrote: > > > > > -Original Message- > > > From: Sitsofe Wheeler [mailto:sits...@gmail.com] > > > Sent: Wednesday, August 27, 2014 9:19 AM > > > > > > > BTW, with the patch below, hyperv_fb can work now, BUT, > > > > *occasionally*, > > > > storvsc_probe() -> ... -> vmbus_open() -> can fail due to > > > > HV_STATUS_INVALID_ALIGNMENT... > > > > > > I applied your new patch on top of KY's pieces (it applied cleanly) > > > and while it doesn't blow up, one warning is printed out and the UP > > > boot seemed to stall after input: TPPS/2 message (but pressing > > > ctrl-alt-delete allows the system to reboot cleanly). > > > > First let me thank you guys for looking into this issue. Looking at > > your dmesg, it looked like storvsc probe failed as Dexuan had seen. > > Since the failure appears to be alignment related, perhaps we could > > test with allocating a page all the time (and getting rid of the > > kmalloc). Sitsofe, here is a patch based on Dexuan's patch. If this > > works, I will probably minimize failure cases by pre-allocating > > per-cpu pages for this.: > > After some modifications to apply on top of your previous patches applying > this latest patch has cured the issues surrounding hyperv_fb issues on boot. > The only issue seen on boot now is similar to > https://lkml.org/lkml/2014/8/19/227 ... That is good to hear. I was under the impression that this issue would be resolved with all the cleanup we have done. The last patch-set I posted earlier today has the fix for vmbus_open bug that Dexuan had identified. If you could try with the BUG_ON elimination patch-set I sent out earlier today with the fix in hv.c that I had sent that would be great. > > How come previous alignment efforts weren't working out? I have chosen to always allocate a page and so alignment won't be an issue. I want to eliminate failure in this path and so, I will most likely do a per-cpu pre-allocation of this buffer. Thank you very much for taking the time to help us debug these issues. Regards, K. Y > > -- > Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] x86: Speed up ioremap operations
We have a large university system in the UK that is experiencing very long delays modprobing the driver for a specific I/O device. The delay is from 8-10 minutes per device and there are 31 devices in the system. This 4 to 5 hour delay in starting up those I/O devices is very much a burden on the customer. There are two causes for requiring a restart/reload of the drivers. First is periodic preventive maintenance (PM) and the second is if any of the devices experience a fatal error. Both of these trigger this excessively long delay in bringing the system back up to full capability. The problem was tracked down to a very slow IOREMAP operation and the excessively long ioresource lookup to insure that the user is not attempting to ioremap RAM. These patches provide a speed up to that function. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: Optimize resource lookups for ioremap
On 8/27/2014 4:05 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 17:59:28 -0500 Mike Travis wrote:
>
>> Since the ioremap operation is verifying that the specified address range
>> is NOT RAM, it will search the entire ioresource list if the condition
>> is true. To make matters worse, it does this one 4k page at a time.
>> For a 128M BAR region this is 32 passes to determine the entire region
>> does not contain any RAM addresses.
>>
>> This patch provides another resource lookup function, region_is_ram,
>> that searches for the entire region specified, verifying that it is
>> completely contained within the resource region. If it is found, then
>> it is checked to be RAM or not, within a single pass.
>>
>> The return result reflects if it was found or not (-1), and whether it is
>> RAM (1) or not (0). This allows the caller to fallback to the previous
>> page by page search if it was not found.
>>
>> ...
>>
>> --- linux.orig/kernel/resource.c
>> +++ linux/kernel/resource.c
>> @@ -494,6 +494,43 @@ int __weak page_is_ram(unsigned long pfn
>> }
>> EXPORT_SYMBOL_GPL(page_is_ram);
>>
>> +/*
>> + * Search for a resouce entry that fully contains the specified region.
>> + * If found, return 1 if it is RAM, 0 if not.
>> + * If not found, or region is not fully contained, return -1
>> + *
>> + * Used by the ioremap functions to insure user not remapping RAM and is as
>> + * vast speed up over walking through the resource table page by page.
>> + */
>> +int __weak region_is_ram(resource_size_t start, unsigned long size)
>> +{
>> +struct resource *p;
>> +resource_size_t end = start + size - 1;
>> +int flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>> +const char *name = "System RAM";
>> +int ret = -1;
>> +
>> +read_lock(_lock);
>> +for (p = iomem_resource.child; p ; p = p->sibling) {
>> +if (end < p->start)
>> +continue;
>> +
>> +if (p->start <= start && end <= p->end) {
>> +/* resource fully contains region */
>> +if ((p->flags != flags) || strcmp(p->name, name))
>> +ret = 0;
>> +else
>> +ret = 1;
>> +break;
>> +}
>> +if (p->end < start)
>> +break; /* not found */
>> +}
>> +read_unlock(_lock);
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(region_is_ram);
>
> Exporting a __weak symbol is strange. I guess it works, but neither
> the __weak nor the export are actually needed?
>
I mainly used 'weak' and export because that was what the page_is_ram
function was using. Most likely this won't be used anywhere else but
I wasn't sure. I can certainly remove the weak and export, at least
until it's actually needed?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rcu: Make nocb leader kthreads process pending callbacks after spawning
On Wed, Aug 27, 2014 at 5:47 PM, Paul E. McKenney wrote: > > Thank you, Pranith, queued. I have also backported to v3.17-rc2, > and am testing both. A sneak preview of the backport is shown below, > please let me know if you see any problems with it. (The reason for > the backport is to submit to 3.17 as a fix for a regression.) > Looks good to me! -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] acpi: fan.c: printk replacement
On Wednesday, August 27, 2014 10:27:47 AM Sudip Mukherjee wrote:
> On Tue, Aug 26, 2014 at 11:22:12PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, August 26, 2014 01:59:02 PM Joe Perches wrote:
> > > On Tue, 2014-08-26 at 23:02 +0200, Rafael J. Wysocki wrote:
> > > > On Tuesday, August 26, 2014 09:00:39 PM Sudip Mukherjee wrote:
> > > > > On Tue, Aug 26, 2014 at 12:45:20AM +0200, Rafael J. Wysocki wrote:
> > > > > > On Friday, August 22, 2014 05:33:21 PM Sudip Mukherjee wrote:
> > > > > > > printk replaced with corresponding dev_err and dev_info
> > > > > > > fixed one broken user-visible string
> > > > > > > multiine comment edited for correct commenting style
> > > > > > > asm/uaccess.h replaced with linux/uaccess.h
> > > > > > >
> > > > > > > Signed-off-by: Sudip Mukherjee
> > > > > > > ---
> > > > > > > drivers/acpi/fan.c | 18 +-
> > > > > > > 1 file changed, 9 insertions(+), 9 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
> > > > > > > index 8acf53e..7900d55 100644
> > > > > > > --- a/drivers/acpi/fan.c
> > > > > > > +++ b/drivers/acpi/fan.c
> > > > > > > @@ -27,7 +27,7 @@
> > > > > > > #include
> > > > > > > #include
> > > > > > > #include
> > > > > > > -#include
> > > > > > > +#include
> > > > > > > #include
> > > > > > > #include
> > > > > > >
> > > > > > > @@ -127,8 +127,9 @@ static const struct
> > > > > > > thermal_cooling_device_ops fan_cooling_ops = {
> > > > > > > };
> > > > > > >
> > > > > > > /*
> > > > > > > --
> > > > > > > - Driver Interface
> > > > > > > -
> > > > > > > --
> > > > > > > */
> > > > > > > + * Driver Interface
> > > > > > > + *
> > > > > > > --
> > > > > > > +*/
> > > > > > >
> > > > > > > static int acpi_fan_add(struct acpi_device *device)
> > > > > > > {
> > > > > > > @@ -143,7 +144,7 @@ static int acpi_fan_add(struct acpi_device
> > > > > > > *device)
> > > > > > >
> > > > > > > result = acpi_bus_update_power(device->handle, NULL);
> > > > > > > if (result) {
> > > > > > > - printk(KERN_ERR PREFIX "Setting initial power state\n");
> > > > > > > + dev_err(>dev, PREFIX "Setting initial power
> > > > > > > state\n");
> > > > > >
> > > > > > While at it, please define a proper pr_fmt() for this file and get
> > > > > > rid of PREFIX
> > > > > > too.
> > > > > >
> > > > > > Otherwise I don't see a compelling reason to apply this.
> > > > > >
> > > > >
> > > > > Hi,
> > > > > Since in the patch I am not using any pr_* , so I am unable to
> > > > > understand why
> > > > > you are asking for a proper pr_fmt().
> > > >
> > > > Never mind, I was confused somehow, not exactly sure why. Sorry about
> > > > that.
> > > >
> > > > > I can get rid of the PREFIX . Then should I use pr_* in the patch
> > > > > instead of dev_* ?
> > > > > My understanding was dev_* is more preffered than pr_*.
> > > > > waiting for your suggestion on this.
> > > >
> > > > Well, that really depends on the particular case. It really is better
> > > > to use
> > > > dev_err() here, but then PREFIX with it is not really useful, so please
> > > > just
> > > > drop PREFIX from the new messages.
> > >
> > > PREFIX is "ACPI: " so I think the idea is
> > > to be able to grep for that.
> >
> > I'm not sure how useful that is in this particular case. You can grep for
> > "power
> > state" istead just fine ...
> >
> > Rafael
> >
>
> Then there is one more printk which prints fan state is on or off :
>
> >dev_info(>dev, PREFIX "%s [%s] (%s)\n",
> > acpi_device_name(device), acpi_device_bid(device),
> > !device->power.state ? "on" : "off");
>
> So if we drop the PREFIX and if some one wants to grep for this fan on/off ,
> then how to do that ..
> after removing PREFIX , in dmesg I am getting it as :
> [2.056204] fan PNP0C0B:00: Fan [FAN0] (off)
> [2.056225] fan PNP0C0B:01: Fan [FAN1] (off)
> [2.056245] fan PNP0C0B:02: Fan [FAN2] (off)
> [2.056263] fan PNP0C0B:03: Fan [FAN3] (off)
> [2.056283] fan PNP0C0B:04: Fan [FAN4] (off)
$ dmesg | grep fan
?
You can simply say "ACPI fan [%s] (%s)\n", acpi_device_bid(device) " in that
dev_info too.
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/
[PATCH 1/2] x86: Optimize resource lookups for ioremap
Since the ioremap operation is verifying that the specified address range
is NOT RAM, it will search the entire ioresource list if the condition
is true. To make matters worse, it does this one 4k page at a time.
For a 128M BAR region this is 32 passes to determine the entire region
does not contain any RAM addresses.
This patch provides another resource lookup function, region_is_ram,
that searches for the entire region specified, verifying that it is
completely contained within the resource region. If it is found, then
it is checked to be RAM or not, within a single pass.
The return result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
Signed-off-by: Mike Travis
Acked-by: Alex Thorlton
Reviewed-by: Cliff Wickman
---
include/linux/mm.h |1 +
kernel/resource.c | 37 +
2 files changed, 38 insertions(+)
--- linux.orig/include/linux/mm.h
+++ linux/include/linux/mm.h
@@ -346,6 +346,7 @@ static inline int put_page_unless_one(st
}
extern int page_is_ram(unsigned long pfn);
+extern int region_is_ram(resource_size_t phys_addr, unsigned long size);
/* Support for virtually mapped pages */
struct page *vmalloc_to_page(const void *addr);
--- linux.orig/kernel/resource.c
+++ linux/kernel/resource.c
@@ -494,6 +494,43 @@ int __weak page_is_ram(unsigned long pfn
}
EXPORT_SYMBOL_GPL(page_is_ram);
+/*
+ * Search for a resouce entry that fully contains the specified region.
+ * If found, return 1 if it is RAM, 0 if not.
+ * If not found, or region is not fully contained, return -1
+ *
+ * Used by the ioremap functions to insure user not remapping RAM and is as
+ * vast speed up over walking through the resource table page by page.
+ */
+int __weak region_is_ram(resource_size_t start, unsigned long size)
+{
+ struct resource *p;
+ resource_size_t end = start + size - 1;
+ int flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+ const char *name = "System RAM";
+ int ret = -1;
+
+ read_lock(_lock);
+ for (p = iomem_resource.child; p ; p = p->sibling) {
+ if (end < p->start)
+ continue;
+
+ if (p->start <= start && end <= p->end) {
+ /* resource fully contains region */
+ if ((p->flags != flags) || strcmp(p->name, name))
+ ret = 0;
+ else
+ ret = 1;
+ break;
+ }
+ if (p->end < start)
+ break; /* not found */
+ }
+ read_unlock(_lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(region_is_ram);
+
void __weak arch_remove_reservations(struct resource *avail)
{
}
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] x86: Speed up ioremap operations
On Wed, 27 Aug 2014 17:59:27 -0500 Mike Travis wrote: > > We have a large university system in the UK that is experiencing > very long delays modprobing the driver for a specific I/O device. > The delay is from 8-10 minutes per device and there are 31 devices > in the system. This 4 to 5 hour delay in starting up those I/O > devices is very much a burden on the customer. That's nuts. > There are two causes for requiring a restart/reload of the drivers. > First is periodic preventive maintenance (PM) and the second is if > any of the devices experience a fatal error. Both of these trigger > this excessively long delay in bringing the system back up to full > capability. > > The problem was tracked down to a very slow IOREMAP operation and > the excessively long ioresource lookup to insure that the user is > not attempting to ioremap RAM. These patches provide a speed up > to that function. With what result? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 00/21] Support ext4 on NV-DIMMs
On Wed, 27 Aug 2014 14:30:55 -0700 Andrew Morton wrote: > On Wed, 27 Aug 2014 16:22:20 -0500 (CDT) Christoph Lameter > wrote: > > > > Some explanation of why one would use ext4 instead of, say, > > > suitably-modified ramfs/tmpfs/rd/etc? > > > > The NVDIMM contents survive reboot and therefore ramfs and friends wont > > work with it. > > See "suitably modified". Presumably this type of memory would need to > come from a particular page allocator zone. ramfs would be unweildy > due to its use to dentry/inode caches, but rd/etc should be feasible. If you took one of the existing ramfs types you would then need to - make it persistent in its storage, and put all the objects in the store - add journalling for failures mid transaction. Your dimm may retain its bits but if your CPU reset mid fs operation its got to be recovered - write an fsck tool for it - validate it at which point it's probably turned into ext4 8) It's persistent but that doesn't solve the 'my box crashed' problem. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 17:59:28 -0500 Mike Travis wrote:
> Since the ioremap operation is verifying that the specified address range
> is NOT RAM, it will search the entire ioresource list if the condition
> is true. To make matters worse, it does this one 4k page at a time.
> For a 128M BAR region this is 32 passes to determine the entire region
> does not contain any RAM addresses.
>
> This patch provides another resource lookup function, region_is_ram,
> that searches for the entire region specified, verifying that it is
> completely contained within the resource region. If it is found, then
> it is checked to be RAM or not, within a single pass.
>
> The return result reflects if it was found or not (-1), and whether it is
> RAM (1) or not (0). This allows the caller to fallback to the previous
> page by page search if it was not found.
>
> ...
>
> --- linux.orig/kernel/resource.c
> +++ linux/kernel/resource.c
> @@ -494,6 +494,43 @@ int __weak page_is_ram(unsigned long pfn
> }
> EXPORT_SYMBOL_GPL(page_is_ram);
>
> +/*
> + * Search for a resouce entry that fully contains the specified region.
> + * If found, return 1 if it is RAM, 0 if not.
> + * If not found, or region is not fully contained, return -1
> + *
> + * Used by the ioremap functions to insure user not remapping RAM and is as
> + * vast speed up over walking through the resource table page by page.
> + */
> +int __weak region_is_ram(resource_size_t start, unsigned long size)
> +{
> + struct resource *p;
> + resource_size_t end = start + size - 1;
> + int flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> + const char *name = "System RAM";
> + int ret = -1;
> +
> + read_lock(_lock);
> + for (p = iomem_resource.child; p ; p = p->sibling) {
> + if (end < p->start)
> + continue;
> +
> + if (p->start <= start && end <= p->end) {
> + /* resource fully contains region */
> + if ((p->flags != flags) || strcmp(p->name, name))
> + ret = 0;
> + else
> + ret = 1;
> + break;
> + }
> + if (p->end < start)
> + break; /* not found */
> + }
> + read_unlock(_lock);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(region_is_ram);
Exporting a __weak symbol is strange. I guess it works, but neither
the __weak nor the export are actually needed?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function
This patch uses the optimized ioresource lookup, "region_is_ram", for
the ioremap function. If the region is not found, it falls back to the
"page_is_ram" function. If it is found and it is RAM, then the usual
warning message is issued, and the ioremap operation is aborted.
Otherwise, the ioremap operation continues.
Signed-off-by: Mike Travis
Acked-by: Alex Thorlton
Reviewed-by: Cliff Wickman
---
arch/x86/mm/ioremap.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
--- linux.orig/arch/x86/mm/ioremap.c
+++ linux/arch/x86/mm/ioremap.c
@@ -86,6 +86,7 @@ static void __iomem *__ioremap_caller(re
pgprot_t prot;
int retval;
void __iomem *ret_addr;
+ int ram_region;
/* Don't allow wraparound or zero size */
last_addr = phys_addr + size - 1;
@@ -108,12 +109,23 @@ static void __iomem *__ioremap_caller(re
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
- pfn = phys_addr >> PAGE_SHIFT;
- last_pfn = last_addr >> PAGE_SHIFT;
- if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
- __ioremap_check_ram) == 1)
- return NULL;
+ /* First check if whole region can be identified as RAM or not */
+ ram_region = region_is_ram(phys_addr, size);
+ /* If is RAM(1) or could not be identified(-1), check page by page */
+ if (ram_region) {
+ pfn = phys_addr >> PAGE_SHIFT;
+ last_pfn = last_addr >> PAGE_SHIFT;
+ if (ram_region > 0) {
+ WARN_ONCE(1, "ioremap on RAM at 0x%lx - 0x%lx\n",
+ (long unsigned int)phys_addr,
+ (long unsigned int)last_addr);
+ return NULL;
+ }
+ if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
+ __ioremap_check_ram) == 1)
+ return NULL;
+ }
/*
* Mappings have to be page-aligned
*/
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PANIC, hyperv] BUG: unable to handle kernel paging request at ffff880077800004 (hv_ringbuffer_write)
On Wed, Aug 27, 2014 at 06:45:55PM +, KY Srinivasan wrote: > > > -Original Message- > > From: Sitsofe Wheeler [mailto:sits...@gmail.com] > > Sent: Wednesday, August 27, 2014 9:19 AM > > > > > BTW, with the patch below, hyperv_fb can work now, BUT, > > > *occasionally*, > > > storvsc_probe() -> ... -> vmbus_open() -> can fail due to > > > HV_STATUS_INVALID_ALIGNMENT... > > > > I applied your new patch on top of KY's pieces (it applied cleanly) > > and while it doesn't blow up, one warning is printed out and the UP > > boot seemed to stall after input: TPPS/2 message (but pressing > > ctrl-alt-delete allows the system to reboot cleanly). > > First let me thank you guys for looking into this issue. Looking at > your dmesg, it looked like storvsc probe failed as Dexuan had seen. > Since the failure appears to be alignment related, perhaps we could > test with allocating a page all the time (and getting rid of the > kmalloc). Sitsofe, here is a patch based on Dexuan's patch. If this > works, I will probably minimize failure cases by pre-allocating > per-cpu pages for this.: After some modifications to apply on top of your previous patches applying this latest patch has cured the issues surrounding hyperv_fb issues on boot. The only issue seen on boot now is similar to https://lkml.org/lkml/2014/8/19/227 ... How come previous alignment efforts weren't working out? -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1] regulator: max77802: set opmode to normal if off is read from hw
Hello Tomasz and Mark,
Sorry for not answering before but I'm on vacations until Sep, 5 and I
have limited access to my email.
On Wed, Aug 27, 2014 at 11:03 PM, Tomasz Figa wrote:
From what I know based on my experience with Samsung boards we used, the
opmodes of regulators are preconfigured by board bootloader to certain
values based on power design of the board (i.e. there is no need to keep
a regulator in full power mode, if on given board only a little fraction
of it is needed).
>>>
This is the case for Chromebooks as well but the solution implemented
in the downstream Chrome OS 3.8 kernel is what Tomasz suggested
before, the max77802/686 PMIC regulator driver has a DT binding that
allows to define the initial opmode for each regulator:
Required properties for each regulator:
- regulator-op-mode : Regulator operating mode, the meaning is regulator-
dependent. Valid values are 0-3.
>>> Well, presumably the bootloader is going to run again even for a warm
>>> reboot?
>>
>> This is strange, but apparently it's not the case for the hardware which
>> this patch is supposed to fix or at least this is how I understood it.
>>
>
> OK, I just realized that Javier's problem might be caused by the fact
> that the bootloader he use doesn't change the regulators from defaults
> at all. In this case this patch is just fine.
>
Yes, AFAIK the bootloader (none of them because Chromebooks use two
chained U-boots) change the regulators default opmode so once is set
to OFF on .disable, that value is preserved on warm reboot. This made
sense with the Chrome OS kernel since the kernel always set the opmode
defined in the "regulator-op-mode" DT property and did not relied on
the bootloader to set the most efficient default opmode.
As Tomasz said this issue also affects other PMICs, for example a
similar DT binding was proposed [0] for the max77686 PMIC which is
very similar to the max77802. Doug even suggested in that thread a
more generic DT binding that could be part of the regulator core.
At the end that DT binding was not merged and the max77686 driver just
sets the default operating mode for all regulators to NORMAL and does
not even read the value reported by the hardware registers. So in that
regard the max77802 driver (even after this patch) does better since
at least respects the default opmode read from the hardware register
if is not OFF.
Also, other drivers have customs operating mode DT properties, please
take a look at
Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt:
The above regulator entries are defined in regulator bindings documentation
except these properties:
- op_mode: describes the different operating modes of the LDO's with
power mode change in SOC. The different possible values are,
0 - always off mode
1 - on in normal mode
2 - low power mode
3 - suspend mode
This is not a great binding IMHO since not only uses a quite generic
"op_mode" for property that is driver specific ("s5m8767,op-mode" or
something would had been better) but also this seems to be a general
issue for many platforms so if we don't try to solve this with a
generic approach, each driver author will try to solve it in its own
way.
> Best regards,
> Tomasz
> --
Best regards,
Javier
[0]: https://patchwork.kernel.org/patch/1855331/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ATTENTION: CONTACT MONEY GRAM REMMITTING OFFICE
WE THE MONEY GRAM URGENT REMMITTING OFFICE HAVE SENT YOUR FULL COMPENSATION PAYMENT OF $1.5million USD TO YOU THROUGH MONEY GRAM,YOU WILL BE RECEIVING $4,500.00USD PER DAY.NOW WE HAVE SEND THE FIRST PAYMENT TO YOU.SO CONTACT OUR DIRECTOR Mr.Mahugnon E. Metonwaho AND ASK HIM TO GIVE YOU THE MONEY GRAM PAYMENT INFORMATION SO THAT YOU CAN BE ABLE TO PICK UP YOUR FUNDS THROUGH MONEY GRAM WITHOUT ANY PROBLEM. HERE IS THE CONTACT INFORMATION OF MONEY GRAM DIRECTOR GENERAL. Mr.Mahugnon E. Metonwaho EMAIL ADRESS (money_02g...@foxmail.com) TELL (+229) 68550986 THEN CONTACT HIM WITH YOUR FULL INFORMATION. OFFCE TEL( 229) 68620380 Your Name: Country:== Phone No: Address/City:== Age/Sex:== CALL OR EMAIL HIM NOW SO THAT HE CAN PROVIDE THE MONEY GRAM INFORMATION TO YOU AS URGENT AS YOU CAN. THANKS AND GOD BLESSING YOU Sincerely. Mrs Ibrahim Aishat. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[V1 PATCH 1/2] PVH: set EFER.NX and EFER.SCE for boot vcpu
This patch addresses three things for a pvh boot vcpu:
- NX bug on intel: It was recenlty discovered that NX is not being
honored in PVH on intel since EFER.NX is not being set. The pte.NX
bits are ignored if EFER.NX is not set on intel.
- PVH boot hang on newer xen: Following c/s on xen
c/s 7645640: x86/PVH: don't set EFER_SCE for pvh guest
removes setting of EFER.SCE for PVH guests. As such, existing intel pvh
guest will no longer boot on xen after that c/s.
- Both above changes will be applicable to AMD also when xen support of
AMD pvh is added.
Signed-off-by: Mukesh Rathor
---
arch/x86/xen/enlighten.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c0cb11f..4af512d 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1499,6 +1499,17 @@ void __ref xen_pvh_secondary_vcpu_init(int cpu)
xen_pvh_set_cr_flags(cpu);
}
+/* This is done in secondary_startup_64 for hvm guests. */
+static void __init xen_configure_efer(void)
+{
+ u64 efer;
+
+ rdmsrl(MSR_EFER, efer);
+ efer |= EFER_SCE;
+ efer |= (cpuid_edx(0x8001) & (1 << 20)) ? EFER_NX : 0;
+ wrmsrl(MSR_EFER, efer);
+}
+
static void __init xen_pvh_early_guest_init(void)
{
if (!xen_feature(XENFEAT_auto_translated_physmap))
@@ -1508,6 +1519,7 @@ static void __init xen_pvh_early_guest_init(void)
return;
xen_have_vector_callback = 1;
+ xen_configure_efer();
xen_pvh_set_cr_flags(0);
#ifdef CONFIG_X86_32
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[V1 PATCH 0/2] Linux PVH: set EFER bits..
Resending with comments fixed up. Please note, these are no longer AMD only, but address existing broken boot and broken NX on intel. thanks mukesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[V1 PATCH 2/2] PVH: set EFER.NX and EFER.SCE for secondary vcpus
This patch addresses three things for a pvh secondary vcpu:
- NX bug on intel: It was recenlty discovered that NX is not being
honored in PVH on intel since EFER.NX is not being set. The pte.NX
bits are ignored if EFER.NX is not set on intel.
- PVH boot hang on newer xen: Following c/s on xen
c/s 7645640: x86/PVH: don't set EFER_SCE for pvh guest
removes setting of EFER.SCE for PVH guests. As such, existing intel pvh
guest will no longer boot on xen after that c/s.
- Both above changes will be applicable to AMD also when xen support of
AMD pvh is added.
Please note: We create a new glue assembly entry point because the
secondary vcpus come up on kernel page tables that have pte.NX
bits set. While on Intel these are ignored if EFER.NX is not set, on
AMD a RSVD bit fault is generated.
Signed-off-by: Mukesh Rathor
---
arch/x86/xen/smp.c | 28
arch/x86/xen/smp.h | 1 +
arch/x86/xen/xen-head.S | 21 +
3 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 7005974..66058b9 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -37,6 +37,7 @@
#include
#include "xen-ops.h"
#include "mmu.h"
+#include "smp.h"
cpumask_var_t xen_cpu_initialized_map;
@@ -99,8 +100,12 @@ static void cpu_bringup(void)
wmb(); /* make sure everything is out */
}
-/* Note: cpu parameter is only relevant for PVH */
-static void cpu_bringup_and_idle(int cpu)
+/*
+ * Note: cpu parameter is only relevant for PVH. The reason for passing it
+ * is we can't do smp_processor_id until the percpu segments are loaded, for
+ * which we need the cpu number! So we pass it in rdi as first parameter.
+ */
+asmlinkage __visible void cpu_bringup_and_idle(int cpu)
{
#ifdef CONFIG_X86_64
if (xen_feature(XENFEAT_auto_translated_physmap) &&
@@ -374,11 +379,10 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle)
ctxt->user_regs.fs = __KERNEL_PERCPU;
ctxt->user_regs.gs = __KERNEL_STACK_CANARY;
#endif
- ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-
memset(>fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+ ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
ctxt->flags = VGCF_IN_KERNEL;
ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
ctxt->user_regs.ds = __USER_DS;
@@ -416,12 +420,20 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle)
#ifdef CONFIG_X86_32
}
#else
- } else
- /* N.B. The user_regs.eip (cpu_bringup_and_idle) is called with
-* %rdi having the cpu number - which means are passing in
-* as the first parameter the cpu. Subtle!
+ } else {
+ /*
+* The vcpu comes on kernel page tables which have the NX pte
+* bit set on AMD. This means before DS/SS is touched, NX in
+* EFER must be set. Hence the following assembly glue code.
+*/
+ ctxt->user_regs.eip = (unsigned long)pvh_cpu_bringup;
+
+ /* N.B. The bringup function cpu_bringup_and_idle is called with
+* %rdi having the cpu number - which means we are passing it in
+* as the first parameter. Subtle!
*/
ctxt->user_regs.rdi = cpu;
+ }
#endif
ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index c7c2d89..b20ba68 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -7,5 +7,6 @@ extern void xen_send_IPI_mask_allbutself(const struct cpumask
*mask,
extern void xen_send_IPI_allbutself(int vector);
extern void xen_send_IPI_all(int vector);
extern void xen_send_IPI_self(int vector);
+extern void pvh_cpu_bringup(int cpu);
#endif
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 485b695..db8dca5 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -47,6 +47,27 @@ ENTRY(startup_xen)
__FINIT
+#ifdef CONFIG_XEN_PVH
+#ifdef CONFIG_X86_64
+/* Note that rdi contains the cpu number and must be preserved */
+ENTRY(pvh_cpu_bringup)
+ /* Gather features to see if NX implemented. (no EFER.NX on intel) */
+ movl$0x8001, %eax
+ cpuid
+ movl%edx,%esi
+
+ movl$MSR_EFER, %ecx
+ rdmsr
+ btsl$_EFER_SCE, %eax
+
+ btl $20,%esi
+ jnc 1f /* No NX, skip it */
+ btsl$_EFER_NX, %eax
+1: wrmsr
+ jmp cpu_bringup_and_idle
+#endif /* CONFIG_X86_64 */
+#endif /* CONFIG_XEN_PVH */
+
.pushsection .text
.balign PAGE_SIZE
ENTRY(hypercall_page)
--
1.8.3.1
--
To unsubscribe
Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested
On Wed, Aug 27, 2014 at 3:26 PM, Stephen Boyd wrote:
> +Mark (author of change in question)
>
> On 08/27/14 14:27, Sonny Rao wrote:
>> On Wed, Aug 27, 2014 at 2:19 PM, Olof Johansson wrote:
>>> On Wed, Aug 27, 2014 at 2:03 PM, Sonny Rao wrote:
This is a bug fix for using physical arch timers when
the arch_timer_use_virtual boolean is false. It restores the
arch_counter_get_cntpct() function after removal in
0d651e4e "clocksource: arch_timer: use virtual counters"
and completes the implementation of memory mapped access for physical
timers, so if a system is trying to use physical timers, it will
function properly.
Signed-off-by: Sonny Rao
>>> Acked-by: Olof Johansson
>>>
>>> This should have a:
>>>
>>> Fixes: 0d651e4e65e9 ("clocksource: arch_timer: use virtual counters")
>>>
>>> tag too, and possibly cc stable?
>> Ok, as far as stable goes, this patch wouldn't apply cleanly going all
>> the way back to 0d651e4e65e9
>> As-is, it would need to go after 220069945b29 "clocksource:
>> arch_timer: Add support for memory mapped timers" and there would need
>> to be another, simpler, version that went between those two commits.
>>
>> So, I'm not sure what to do in this situation regarding stable?
Greg tends to make a best-effort, you'll find out when he looks at
backporting and can reply with a "punt" or "here's the right patch"
then.
> Is there any reason why the virtual counter can't be read? Maybe we're
> the hyp and we need to make sure we don't use the virtual timer so that
> the guest can use it, but that doesn't have any effect on the usage of
> the virtual counter for the clocksource.
There are several cases where virtual is unusable -- in particular it
might not have been configured properly (i.e. the phys/virt offset is
at a bad value).
-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 2/5 v3] irq / PM: Make wakeup interrupts work with suspend-to-idle
On Wednesday, August 27, 2014 10:32:23 PM Thomas Gleixner wrote:
> On Wed, 27 Aug 2014, Rafael J. Wysocki wrote:
> > The line of reasoning leading to that is as follows.
> >
> > The way suspend_device_irqs() works and the existing code in
> > check_wakeup_irqs(), called by syscore_suspend(), imply that:
> >
> > (1) Interrupt handlers are not invoked for wakeup interrupts
> > after suspend_device_irqs().
> >
> > (2) All interrups from system wakeup IRQs received after\
> > suspend_device_irqs() cause full system suspends to be aborted.
> >
> > In addition to the above, there is the requirement that
> >
> > (3) System wakeup interrupts should wake up the system from
> > suspend-to-idle.
> >
> > It immediately follows from (1) and (2) that no effort is made to
> > distinguish "genuine" wakeup interrupts from "spurious" ones. They
> > all are treated in the same way. Since (3) means that "genuine"
> > wakeup interrupts are supposed to wake up the system from
> > suspend-to-idle too, consistency with (1) and (2) requires that
> > "spurious" wakeup interrupts should do the same thing. Thus there is
> > no reason to invoke interrupt handlers for wakeup interrups after
> > suspend_device_irqs() in the suspend-to-idle case. Moreover, doing
> > so would go against rule (1).
>
> I agree with that, but I disagree with the implementation.
>
> We now have two separate mechanisms to abort suspend:
>
> 1) The existing suspend_device_irqs() / check_wakeup_irqs()
>
> 2) The new suspend_device_irqs() /
>reenable_stuff_and_fiddle_with_irq_action()
>
> So why do we need those two mechanisms in the first place?
>
> AFAICT there is no reason why we cant use the abort_suspend mechanics
> to replace the suspend_device_irqs() / check_wakeup_irqs() pair.
>
> All it needs is to do the handler substitution in
> suspend_device_irqs() right away and replace the loop in
> check_wakeup_irqs() with a check for abort_suspend == true. The roll
> back of the handler substitution can happen in resume_device_irqs()
> for both scenarios.
We can do that of course.
> Aside of that the whole irqaction based substitution is silly. What's
> wrong with doing it at the real interrupt handler level?
Nothing I suppose. :-)
> static void handle_wakeup_irq(unsigned int irq, struct irq_desc *desc)
> {
> raw_spin_lock(>lock);
>
> desc->istate |= IRQS_SUSPENDED | IRQS_PENDING;
> desc->depth++;
> irq_disable(desc);
> pm_system_wakeup();
>
> raw_spin_unlock(>lock);
> }
>
> void suspend_device_irqs(void)
> {
> for_each_irq_desc(irq, desc) {
> /* Disable the interrupt unconditionally */
> disable_irq(irq);
We still need to skip the IRQF_NO_SUSPEND stuff (eg. timers), so I guess
everything left disabled here needs to be IRQS_SUSPENDED, so we know which
ones to re-enable in resume_device_irqs().
>
> /* Is the irq a wakeup source? */
> if (!irqd_is_wakeup_set(>irq_data))
> continue;
>
> /* Replace the handler */
> raw_spin_lock_irqsave(>lock, flags);
> desc->saved_handler = desc->handler;
> desc->handler = handle_wakeup_irq;
Hmm. There's no handler field in struct irq_desc (/me is puzzled).
Did you mean handle_irq (I think you did)?
> raw_spin_unlock_irqrestore(>lock, flags);
>
> /* Reenable the wakeup irq */
> enable_irq(irq);
> }
> }
>
> /* Move that into the pm core code */
> bool check_wakeup_irqs(void)
> {
> return abort_suspend;
> }
>
> void resume_device_irqs(void)
> {
> for_each_irq_desc(irq, desc) {
>
> /* Prevent the wakeup handler from running */
> disable_irq();
>
> raw_spin_lock_irqsave(>lock, flags);
>
> /* Do we need to restore the handler? */
> if (desc->handler == handle_wakeup_irq)
> desc->handler = desc->saved_handler;
>
> /* Is the irq a wakeup source? */
> if (!irqd_is_wakeup_set(>irq_data))
> __enable_irq(irq, desc);
>
> /* Did it get disabled in the wakeup handler? */
> else if (desc->istate & IRQS_SUSPENDED)
> __enable_irq(irq, desc);
>
> raw_spin_unlock_irqrestore(>lock, flags);
>
> enable_irq();
> }
> }
>
> Hmm?
OK
There is quite some ugliness related to resume_irqs(), the want_early thing
and IRQF_EARLY_RESUME / IRQF_FORCE_RESUME. I guess that needs to be preserved?
> One thing we might think about is having flow specific
> handle_wakeup_irq variants as some hardware might require an ack or
> eoi, but that's a simple to solve problem and way simpler than
> fiddling with the irqaction chain and avoids the whole mess of
> sprinkling irq_pm_saved_id() and irq_pm_restore_handler() calls all
> over the
Re: [PATCH v2 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
On 08/27/2014 03:56 PM, Andrew Bresticker wrote:
On Wed, Aug 27, 2014 at 11:19 AM, Stephen Warren wrote:
On 08/27/2014 12:13 PM, Andrew Bresticker wrote:
On Wed, Aug 27, 2014 at 10:50 AM, Stephen Warren
wrote:
On 08/27/2014 11:38 AM, Andrew Bresticker wrote:
On Mon, Aug 25, 2014 at 12:01 PM, Stephen Warren
wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
+static int tegra_xusb_mbox_probe(struct platform_device *pdev)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
Should devm_request_mem_region() be called here to claim the region?
No, the xHCI host driver also needs to map these registers, so they
cannot be mapped exclusively here.
That's unfortunate. Having multiple drivers with overlapping register
regions is not a good idea. Can we instead have a top-level driver map
all
the IO regions, then instantiate the various different sub-components
internally, and divide up the address space. Probably via MFD or similar.
That would prevent multiple drivers from touching the same register
region.
Perhaps I'm misunderstanding, but I don't see how MFD would prevent us
from having to map this register space in two different locations -
the XUSB FPCI address space cannot be divided cleanly between host and
mailbox registers. Or are you saying that there should be a separate
device driver that exposes an API for accessing this register space,
like the Tegra fuse or PMC drivers?
With MFD, there's typically a top-level driver for the HW module (or
register space) that gets instantiated by the DT node. This driver then
instantiates all the different sub-drivers that use that register space, and
provides APIs for the sub-drivers to access the registers (either custom
APIs or more recently by passing a regmap object down to the sub-drivers).
This top-level driver is the only driver that maps the space, and can manage
sharing the space between the various sub-drivers.
So if I'm understanding correctly, we end up with something like this:
usb@7009 {
compatible = "nvidia,tegra124-xusb";
reg = <0x0 0x7009 0x0 0x8000>, // xHCI host registers
<0x0 0x70098000 0x0 0x1000>, // FPCI registers
<0x0 0x70099000 0x0 0x1000>; // IPFS registers
interrupts = , // host interrupt
Something like that, yes.
Given that the "xusb" driver knows that its HW module contains both an
XHCI and XUSB mailbox chunk, those might not need to appear inside the
main XUSB module, but could be hard-coded into the driver. They might
serve as convenient containers for sub-device-specific properties though.
Other alternatives might be:
a) If the registers that are shared between drivers are distinct, then
divide the reg values into non-overlapping lists. We have taken this
approach for the MC/SMMU drivers on Tegra, although it's a horrible mess
and Thierry is actively thinking about reverting that and doing it
through MFD or something MFD-like.
b) Allow the same IO region to be claimed by multiple devices, perhaps
with a new API so that it doesn't accidentally happen when not desired.
c) Ignore the issue and deal with the fact that not all driver usage
shows up in /proc/iomem. This is what we have for the Tegra USB2 and
USB2 PHY drivers, and this is (I think) what your current patch does.
To be honest, none of the options are that good; some end up with the
correct result but are a pain to implement, but others are nice and
simple yet /proc/iomem isn't complete. Given that, I'm personally not
going to try and mandate one option or the other, so the current patch
is fine. Food for thought though:-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clocksource: arch_timer: Fix code to use physical timers when requested
+Mark (author of change in question)
On 08/27/14 14:27, Sonny Rao wrote:
> On Wed, Aug 27, 2014 at 2:19 PM, Olof Johansson wrote:
>> On Wed, Aug 27, 2014 at 2:03 PM, Sonny Rao wrote:
>>> This is a bug fix for using physical arch timers when
>>> the arch_timer_use_virtual boolean is false. It restores the
>>> arch_counter_get_cntpct() function after removal in
>>>
>>> 0d651e4e "clocksource: arch_timer: use virtual counters"
>>>
>>> and completes the implementation of memory mapped access for physical
>>> timers, so if a system is trying to use physical timers, it will
>>> function properly.
>>>
>>> Signed-off-by: Sonny Rao
>> Acked-by: Olof Johansson
>>
>> This should have a:
>>
>> Fixes: 0d651e4e65e9 ("clocksource: arch_timer: use virtual counters")
>>
>> tag too, and possibly cc stable?
> Ok, as far as stable goes, this patch wouldn't apply cleanly going all
> the way back to 0d651e4e65e9
> As-is, it would need to go after 220069945b29 "clocksource:
> arch_timer: Add support for memory mapped timers" and there would need
> to be another, simpler, version that went between those two commits.
>
> So, I'm not sure what to do in this situation regarding stable?
Is there any reason why the virtual counter can't be read? Maybe we're
the hyp and we need to make sure we don't use the virtual timer so that
the guest can use it, but that doesn't have any effect on the usage of
the virtual counter for the clocksource.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] Drivers: hv: vmbus: Cleanup vmbus_establish_gpadl()
Eliminate the call to BUG_ON() by waiting for the host to respond. We are trying to reclaim the ownership of memory that was given to the host and so we will have to wait until the host responds. Signed-off-by: K. Y. Srinivasan Cc: --- drivers/hv/channel.c |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index eb3158e..9a6a2c3 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -363,7 +363,6 @@ int vmbus_establish_gpadl(struct vmbus_channel *channel, void *kbuffer, u32 next_gpadl_handle; unsigned long flags; int ret = 0; - int t; next_gpadl_handle = atomic_read(_connection.next_gpadl_handle); atomic_inc(_connection.next_gpadl_handle); @@ -410,9 +409,7 @@ int vmbus_establish_gpadl(struct vmbus_channel *channel, void *kbuffer, } } - t = wait_for_completion_timeout(>waitevent, 5*HZ); - BUG_ON(t == 0); - + wait_for_completion(>waitevent); /* At this point, we received the gpadl created msg */ *gpadl_handle = gpadlmsg->gpadl; -- 1.7.4.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 V2 1/5] Drivers: hv: vmbus: Cleanup vmbus_post_msg()
Posting messages to the host can fail because of transient resource
related failures. Correctly deal with these failures and increase the
number of attempts to post the message before giving up.
In this version of the patch, I have normalized the error code to
Linux error code.
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/hv/connection.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index ae22e3c..e206619 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -427,10 +427,21 @@ int vmbus_post_msg(void *buffer, size_t buflen)
* insufficient resources. Retry the operation a couple of
* times before giving up.
*/
- while (retries < 3) {
- ret = hv_post_message(conn_id, 1, buffer, buflen);
- if (ret != HV_STATUS_INSUFFICIENT_BUFFERS)
+ while (retries < 10) {
+ ret = hv_post_message(conn_id, 1, buffer, buflen);
+
+ switch (ret) {
+ case HV_STATUS_INSUFFICIENT_BUFFERS:
+ ret = -ENOMEM;
+ case -ENOMEM:
+ break;
+ case HV_STATUS_SUCCESS:
return ret;
+ default:
+ pr_err("hv_post_msg() failed; error code:%d\n", ret);
+ return -EINVAL;
+ }
+
retries++;
msleep(100);
}
--
1.7.4.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 V2 5/5] Drivers: hv: vmbus: Fix a bug in vmbus_open()
Fix a bug in vmbus_open() and properly propagate the error. I would
like to thank Dexuan Cui for identifying the
issue.
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/hv/channel.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 9a6a2c3..19bad59 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -165,8 +165,10 @@ int vmbus_open(struct vmbus_channel *newchannel, u32
send_ringbuffer_size,
ret = vmbus_post_msg(open_msg,
sizeof(struct vmbus_channel_open_channel));
- if (ret != 0)
+ if (ret != 0) {
+ err = ret;
goto error1;
+ }
t = wait_for_completion_timeout(_info->waitevent, 5*HZ);
if (t == 0) {
--
1.7.4.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 V2 2/5] Drivers: hv: vmbus: Cleanup vmbus_teardown_gpadl()
Eliminate calls to BUG_ON() by properly handling errors. In cases where rollback is possible, we will return the appropriate error to have the calling code decide how to rollback state. In the case where we are transferring ownership of the guest physical pages to the host, we will wait for the host to respond. Signed-off-by: K. Y. Srinivasan Cc: --- drivers/hv/channel.c | 11 ++- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index 531a593..0206314 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -435,7 +435,7 @@ int vmbus_teardown_gpadl(struct vmbus_channel *channel, u32 gpadl_handle) struct vmbus_channel_gpadl_teardown *msg; struct vmbus_channel_msginfo *info; unsigned long flags; - int ret, t; + int ret; info = kmalloc(sizeof(*info) + sizeof(struct vmbus_channel_gpadl_teardown), GFP_KERNEL); @@ -457,11 +457,12 @@ int vmbus_teardown_gpadl(struct vmbus_channel *channel, u32 gpadl_handle) ret = vmbus_post_msg(msg, sizeof(struct vmbus_channel_gpadl_teardown)); - BUG_ON(ret != 0); - t = wait_for_completion_timeout(>waitevent, 5*HZ); - BUG_ON(t == 0); + if (ret) + goto post_msg_err; + + wait_for_completion(>waitevent); - /* Received a torndown response */ +post_msg_err: spin_lock_irqsave(_connection.channelmsg_lock, flags); list_del(>msglistentry); spin_unlock_irqrestore(_connection.channelmsg_lock, flags); -- 1.7.4.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 V2 0/5] Drivers: hv: vmbus: Eliminate calls to BUG_ON()
Cleanup the channel management code and eliminate calls to BUG_ON(). Also fix an error propagation bug in vmbus_open(). In this version of the patch-set, I have addressed comments from Dan Carpenter. K. Y. Srinivasan (5): Drivers: hv: vmbus: Cleanup vmbus_post_msg() Drivers: hv: vmbus: Cleanup vmbus_teardown_gpadl() Drivers: hv: vmbus: Cleanup vmbus_close_internal() Drivers: hv: vmbus: Cleanup vmbus_establish_gpadl() Drivers: hv: vmbus: Fix a bug in vmbus_open() drivers/hv/channel.c| 49 +++--- drivers/hv/connection.c | 17 --- 2 files changed, 46 insertions(+), 20 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 3/5] Drivers: hv: vmbus: Cleanup vmbus_close_internal()
Eliminate calls to BUG_ON() in vmbus_close_internal().
We have chosen to potentially leak memory, than crash the guest
in case of failures.
In this version of the patch I have addressed comments from
Dan Carpenter (dan.carpen...@oracle.com).
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/hv/channel.c | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 0206314..eb3158e 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -479,7 +479,7 @@ static void reset_channel_cb(void *arg)
channel->onchannel_callback = NULL;
}
-static void vmbus_close_internal(struct vmbus_channel *channel)
+static int vmbus_close_internal(struct vmbus_channel *channel)
{
struct vmbus_channel_close_channel *msg;
int ret;
@@ -502,11 +502,28 @@ static void vmbus_close_internal(struct vmbus_channel
*channel)
ret = vmbus_post_msg(msg, sizeof(struct vmbus_channel_close_channel));
- BUG_ON(ret != 0);
+ if (ret) {
+ pr_err("Close failed: close post msg return is %d\n", ret);
+ /*
+* If we failed to post the close msg,
+* it is perhaps better to leak memory.
+*/
+ return ret;
+ }
+
/* Tear down the gpadl for the channel's ring buffer */
- if (channel->ringbuffer_gpadlhandle)
- vmbus_teardown_gpadl(channel,
- channel->ringbuffer_gpadlhandle);
+ if (channel->ringbuffer_gpadlhandle) {
+ ret = vmbus_teardown_gpadl(channel,
+ channel->ringbuffer_gpadlhandle);
+ if (ret) {
+ pr_err("Close failed: teardown gpadl return %d\n", ret);
+ /*
+* If we failed to teardown gpadl,
+* it is perhaps better to leak memory.
+*/
+ return ret;
+ }
+ }
/* Cleanup the ring buffers for this channel */
hv_ringbuffer_cleanup(>outbound);
@@ -515,7 +532,7 @@ static void vmbus_close_internal(struct vmbus_channel
*channel)
free_pages((unsigned long)channel->ringbuffer_pages,
get_order(channel->ringbuffer_pagecount * PAGE_SIZE));
-
+ return ret;
}
/*
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86: iosf: Add debugfs support
On 08/27/2014 02:40 PM, David E. Box wrote: > Allows access to the iosf sideband through debugfs. This would break if compiled without CONFIG_DEBUGFS support, which is often a requirement for security reasons. Please conditionalize this code, and if practical move it to a separate .c file. Most drivers also have separate config options to enable their specific debugfs options. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: HT1000 SATA broken by "x86, irq, ACPI: Use common irqdomain map interface to program IOAPIC pins"
On Wed, 27 Aug 2014, Thomas Gleixner wrote: > On Wed, 27 Aug 2014, Mikulas Patocka wrote: > > > Hi > > > > The patch d7b830013f59cf586c1cec3caa1ce7156da59a13, committed to 3.17-rc1, > > breaks the SATA controller (sata_svw driver) on HT1000 ServerWorks > > chipset. The other drivers work correctly. > > > > With the patch d7b830013f59cf586c1cec3caa1ce7156da59a13, the SATA > > controller times out after every command with lost interrupt. > > > > With the patch 16ee7b3dcc56be14b9a813612cff2cc2339cdced, the SATA driver > > can't be loaded at all, it fails with: > > sata_svw :01:0e.0: version 2.3 > > Failed to set pin attr for GSI11 > > sata_svw :01:0e.0: PCI INT A: failed to register GSI > > sata_svw: probe of :01:0e.0 failed with error -1 > > Can you please pull > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent > > into your tree and check whether this solves the issues? > > Thanks, > > tglx Yes, that fixes it. Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] watchdog: add driver for Ricoh RN5T618 watchdog
On Wed, Aug 27, 2014 at 12:01:35PM -0700, Guenter Roeck wrote:
[...]
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define DRIVER_NAME "rn5t618-wdt"
> > +
> > +static bool nowayout = WATCHDOG_NOWAYOUT;
> > +static unsigned int heartbeat = -1;
>
> I'd be surprised if this doesn't cause a compiler warning.
> Why not just initialize the variable with 0 ?
The idea was to initialize the variable with an invalid value that has
no effect when watchdog_init_timeout() is called during probe, thus
leaving the watchdog timeout to the maximum value.
You are right, the same effect can be achieved in a cleaner way
leaving the variable to zero (by the way, the above assignment doesn't
seem to generate warnings).
>
> > +
> > +module_param(heartbeat, int, 0);
> > +MODULE_PARM_DESC(heartbeat, "Initial watchdog heartbeat in seconds");
> > +
> > +module_param(nowayout, bool, 0);
> > +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> > (default="
> > +__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> > +
> > +struct rn5t618_wdt {
> > + struct watchdog_device wdt_dev;
> > + struct rn5t618 *rn5t618;
> > +};
[..]
> > +static int rn5t618_wdt_set_timeout(struct watchdog_device *wdt_dev,
> > + unsigned int timeout)
> > +{
> > + struct rn5t618_wdt *wdt = watchdog_get_drvdata(wdt_dev);
> > + int ret, i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(rn5t618_wdt_map); i++) {
> > + if (rn5t618_wdt_map[i].time + 1 >= timeout)
> > + break;
> > + }
> > +
> > + if (i == ARRAY_SIZE(rn5t618_wdt_map))
> > + ret = -EINVAL;
>
> Can you simplify this a bit ? If you use
>
> if (i == ARRAY_SIZE(rn5t618_wdt_map))
> return -EINVAL;
>
> > + else
>
> You can drop this else statement.
Will do, thanks.
Beniamino
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] radeon: Test for PCI root bus before assuming bus->self
On Wed, Aug 27, 2014 at 3:01 PM, Alex Williamson
wrote:
> If we assign a Radeon device to a virtual machine, we can no longer
> assume a fixed hardware topology, like the GPU having a parent device.
> This patch simply adds a few pci_is_root_bus() tests to avoid passing
> a NULL pointer to PCI access functions, allowing the radeon driver to
> work in a QEMU 440FX machine with an assigned HD8570 on the emulated
> PCI root bus.
>
> Signed-off-by: Alex Williamson
Added to my -fixes queue. thanks!
Alex
> ---
>
> drivers/gpu/drm/radeon/cik.c |6 +-
> drivers/gpu/drm/radeon/si.c |6 +-
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 79a5a55..cc34308 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -9555,6 +9555,9 @@ static void cik_pcie_gen3_enable(struct radeon_device
> *rdev)
> int ret, i;
> u16 tmp16;
>
> + if (pci_is_root_bus(rdev->pdev->bus))
> + return;
> +
> if (radeon_pcie_gen2 == 0)
> return;
>
> @@ -9781,7 +9784,8 @@ static void cik_program_aspm(struct radeon_device *rdev)
> if (orig != data)
> WREG32_PCIE_PORT(PCIE_LC_LINK_WIDTH_CNTL,
> data);
>
> - if (!disable_clkreq) {
> + if (!disable_clkreq &&
> + !pci_is_root_bus(rdev->pdev->bus)) {
> struct pci_dev *root = rdev->pdev->bus->self;
> u32 lnkcap;
>
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index a1274a3..ffb1d4e 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -7177,6 +7177,9 @@ static void si_pcie_gen3_enable(struct radeon_device
> *rdev)
> int ret, i;
> u16 tmp16;
>
> + if (pci_is_root_bus(rdev->pdev->bus))
> + return;
> +
> if (radeon_pcie_gen2 == 0)
> return;
>
> @@ -7454,7 +7457,8 @@ static void si_program_aspm(struct radeon_device *rdev)
> if (orig != data)
> WREG32_PIF_PHY1(PB1_PIF_CNTL, data);
>
> - if (!disable_clkreq) {
> + if (!disable_clkreq &&
> + !pci_is_root_bus(rdev->pdev->bus)) {
> struct pci_dev *root = rdev->pdev->bus->self;
> u32 lnkcap;
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] dt: Document Qualcomm APQ8084 pinctrl binding
On Tue, Aug 26, 2014 at 03:45:55PM +0300, Georgi Djakov wrote: > Define a new binding for the Qualcomm TLMM (Top-Level Mode Mux) based pin > controller inside the APQ8084. > > Signed-off-by: Georgi Djakov Looks fine. Reviewed-by: Andy Gross -- sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/2] USB: OTG: Hold wakeupsource when VBUS present
On Fri, Aug 22, 2014 at 10:12 AM, Felipe Balbi wrote: ... > you never explain why this is needed and you have also added some > information to commit log which shouldn't be here. Android uses this to prevent suspend from interfering with USB peripheral traffic, notably adb. The wakeup source is held only when USB is connected and enumerated for a host session (I might be using wrong terminology here). It may not be necessary on a platform that implements wakeup on incoming USB traffic, although it is likely adb and other protocols would need to hold wakeup sources at certain times. ... >> +static struct otgws_lock vbus_lock; > > should be per-PHY One of the reasons this was done as a separate driver and via notifiers was to keep the (original Android wakelock) logic out of the USB code. If the general idea is something that finds favor with the USB and PM folks then perhaps adding a wakeup source per PHY in the PHY driver would be better. Todd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: softdirty: enable write notifications on VMAs after VM_SOFTDIRTY cleared
On Tue, 26 Aug 2014, Cyrill Gorcunov wrote: > On Mon, Aug 25, 2014 at 09:45:34PM -0700, Hugh Dickins wrote: > > > > Hmm. For a long time I thought you were fixing another important bug > > with down_write, since we "always" use down_write to modify vm_flags. > > > > But now I'm realizing that if this is the _only_ place which modifies > > vm_flags with down_read, then it's "probably" safe. I've a vague > > feeling that this was discussed before - is that so, Cyrill? > > Well, as far as I remember we were not talking before about vm_flags > and read-lock in this function, maybe it was on some unrelated lkml thread > without me CC'ed? Until I miss something obvious using read-lock here > for vm_flags modification should be safe, since the only thing which is > important (in context of vma-softdirty) is the vma's presence. Hugh, > mind to refresh my memory, how long ago the discussion took place? Sorry for making you think you were losing your mind, Cyrill. I myself have no recollection of any such conversation with you; but afraid that I might have lost _my_ memory of it - I didn't want to get too strident about how fragile (though probably not yet buggy) this down_read-for-updating-VM_SOFTDIRTY-onlyi is, if there had already been such a discussion, coming to the conclusion that it is okay for now. I am fairly sure that I have had some such discussion before; but probably with someone else, probably still about mmap_sem and vm_flags, but probably some other VM_flag: the surprising realization that it may be safe but fragile to use just down_read for updating one particular flag. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
On Wed, Aug 27, 2014 at 11:19 AM, Stephen Warren wrote:
> On 08/27/2014 12:13 PM, Andrew Bresticker wrote:
>>
>> On Wed, Aug 27, 2014 at 10:50 AM, Stephen Warren
>> wrote:
>>>
>>> On 08/27/2014 11:38 AM, Andrew Bresticker wrote:
On Mon, Aug 25, 2014 at 12:01 PM, Stephen Warren
wrote:
>
>
> On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
>>
>>
>> +static int tegra_xusb_mbox_probe(struct platform_device *pdev)
>
>
>
>
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>
>> + if (!res)
>> + return -ENODEV;
>
>
>
>
> Should devm_request_mem_region() be called here to claim the region?
No, the xHCI host driver also needs to map these registers, so they
cannot be mapped exclusively here.
>>>
>>>
>>>
>>> That's unfortunate. Having multiple drivers with overlapping register
>>> regions is not a good idea. Can we instead have a top-level driver map
>>> all
>>> the IO regions, then instantiate the various different sub-components
>>> internally, and divide up the address space. Probably via MFD or similar.
>>> That would prevent multiple drivers from touching the same register
>>> region.
>>
>>
>> Perhaps I'm misunderstanding, but I don't see how MFD would prevent us
>> from having to map this register space in two different locations -
>> the XUSB FPCI address space cannot be divided cleanly between host and
>> mailbox registers. Or are you saying that there should be a separate
>> device driver that exposes an API for accessing this register space,
>> like the Tegra fuse or PMC drivers?
>
>
> With MFD, there's typically a top-level driver for the HW module (or
> register space) that gets instantiated by the DT node. This driver then
> instantiates all the different sub-drivers that use that register space, and
> provides APIs for the sub-drivers to access the registers (either custom
> APIs or more recently by passing a regmap object down to the sub-drivers).
>
> This top-level driver is the only driver that maps the space, and can manage
> sharing the space between the various sub-drivers.
So if I'm understanding correctly, we end up with something like this:
usb@7009 {
compatible = "nvidia,tegra124-xusb";
reg = <0x0 0x7009 0x0 0x8000>, // xHCI host registers
<0x0 0x70098000 0x0 0x1000>, // FPCI registers
<0x0 0x70099000 0x0 0x1000>; // IPFS registers
interrupts = , // host interrupt
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: use IORESOURCE_REG resource type for non-translatable addresses in DT
On 08/27/14 11:24, Bjorn Andersson wrote: > On Tue, Jul 29, 2014 at 11:06 PM, Stephen Boyd wrote: >> On 07/29, Rob Herring wrote: > [..] >>> You might as well do of_property_read_u32 in the below example. >>> >> Fair enough. The example is probably too simple. Things are >> sometimes slightly more complicated and a simple >> of_property_read_u32() isn't going to work in the case of >> multiple reg values or when reg-names is in play. >> > But do we have such cases in the Qualcomm PMICs? At the least we have reg-names users. > > The only case I've hit so far is for gpios and mpps, where it feels > like reg should be base, size and not simply base reg of first gpio - > but that's a different thing. > > Also, so far it seems like most drivers just code the base address in > the driver, as we have very specific compatibles. It would be nice if the drivers didn't have to do this. It annoys me that platform drivers need to know that they're using DT to figure out things that are standard platform features: registers, irqs, etc. > > > How about we stop trying so hard to make this "perfect" and just merge > something close to Josh's original proposal and ignore this problem? > Currently all we're doing is delaying any possibility of getting > drivers for the individual blocks merged. > If we have the dt bindings require the reg to be there, we can discuss > and change this all we want later! What's Josh's original proposal? We've already punted on this for SSBI PMICs and just required them to put registers in DT for use some day and I don't see anyone blocking individual SPMI pmic drivers from merging over this. So I guess I agree with you that we can move forward with the other drivers. I'd still like to see us make this better though, so it seems worthwhile to have the discussion and get to some conclusion. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 percpu/for-3.18-consistent-ops] Revert "powerpc: Replace __get_cpu_var uses"
On Wed, 27 Aug 2014, Tejun Heo wrote:
> Weird, the build-bot reported success on all powerpc configs on the
> percpu branches w/o the revert. I wonder what's going on.
I think this will fix it but I have no way of verifying it.
Subject: Define __ARCH_SET_SOFTIRQ_PENDING to avoid duplicate defs
Signed-off-by: Christoph Lameter
Index: linux/arch/powerpc/include/asm/hardirq.h
===
--- linux.orig/arch/powerpc/include/asm/hardirq.h
+++ linux/arch/powerpc/include/asm/hardirq.h
@@ -20,6 +20,7 @@ typedef struct {
DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
#define __ARCH_IRQ_STAT
+#define __ARCH_SET_SOFTIRQ_PENDING
#define local_softirq_pending()
__this_cpu_read(irq_stat.__softirq_pending)
#define set_softirq_pending(x) __this_cpu_write(irq_stat._softirq_pending, (x))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] pinctrl: qcom: Add APQ8084 pinctrl support
On Tue, Aug 26, 2014 at 03:45:54PM +0300, Georgi Djakov wrote: > This patchset adds pinctrl support for the Qualcomm APQ8084 platform. > > Signed-off-by: Georgi Djakov Looks good. I'll try to test this tomorrow, but for now Reviewed-by: Andy Gross -- sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 percpu/for-3.18-consistent-ops] Revert "powerpc: Replace __get_cpu_var uses"
Hi Christoph, On Wed, 27 Aug 2014 10:56:27 -0500 (CDT) Christoph Lameter wrote: > > On Wed, 27 Aug 2014, Tejun Heo wrote: > > > Chrisoph, let's route the updated patch through powerpc tree. > > Ok. Once I figure out what went wrong. This went through Feng's build > system and I though he did a powerpc build. So it must be a difference > configuration on powerpc. Were the patches tested on top of v3.17-rc1? My build was a powerpc ppc64_defconfig. It is possible that some other change interacted with this, but there are not many other arch/powerpc changes after v3.17-rc1 and none seem obvious. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH percpu/for-3.18-consistent-ops] Revert "powerpc: Replace __get_cpu_var uses"
On Thu, Aug 28, 2014 at 07:43:49AM +1000, Stephen Rothwell wrote: > Hi Tejun, > > On Wed, 27 Aug 2014 11:26:09 -0400 Tejun Heo wrote: > > > > From 23f66e2d661b4d3226d16e25910a9e9472ce2410 Mon Sep 17 00:00:00 2001 > > From: Tejun Heo > > Date: Wed, 27 Aug 2014 11:18:29 -0400 > > > > This reverts commit 5828f666c069af74e00db21559f1535103c9f79a due to > > build failure after merging with pending powerpc changes. > > I can't see any pending powerpc changes that would obviously affect > this ... Weird, the build-bot reported success on all powerpc configs on the percpu branches w/o the revert. I wonder what's going on. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3] tpm_tis: verify interrupt during init
On Wed, Aug 27, 2014 at 09:32:10PM +, Scot Doyle wrote:
> If suspend/resume occur before falling back to polling mode (within 30
> seconds after module load), then the machine freezes on resume because
> the module is waiting on the interrupts.
Okay, this is just a specific case of the broader TPM bug: the tpm
driver is registered with the system before it is actually ready to
drive the TPM.
> >> -if (tpm_do_selftest(chip)) {
> >> -dev_err(dev, "TPM self test failed\n");
> >> -rc = -ENODEV;
> >> -goto out_err;
> >> -}
> >
> > Move gettimeout too
>
> Can it be moved? It sends startup(clear) if the TPM isn't yet operational.
To move it means we have to understand why you are getting timeouts:
[ 33.247720] tpm_tis 00:08: tpm_transmit: tpm_send: error -62
[ 33.247731] tpm_tis 00:08: [Hardware Error]: TPM command timed out during
continue self test
I had thought based on your other patch that these should not happen
since the raw register is polled after the timer expires?
What is going on here? Do you still have that other patch applied?
>
> >> -if (chip->vendor.irq) {
> >> +if (interrupts && chip->vendor.irq) {
> >
> > Unrelated? Looks unnecessary:
> >
> >if (!interrupts) {
> >irq = 0;
> >
> >chip->vendor.irq = irq;
> >
> >if (chip->vendor.irq) {
>
> Setting chip->vendor.irq would erase any we just found in probing?
Sorry, I ment the code I clipped is already present in the driver, in
that order, so the change is a NOP.
> Right, the TPM commands don't fail, but tpm_get_timeouts does. I've
> simplified the section in this version.
I'm not quite sure what that means, but..
The reason you want to use tpm_get_timeouts to test the IRQ is because
it has a very short timeout. self test has one of the longest
timeouts, so it is not the best choice.
What I was hoping to see, is that get_timeouts would hit the timer, do
the final read of the completion register, complete normally, then the
tis driver would see successful completion with no IRQ and turn them
off.
Is that doable?
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index e4d0888..6747a47 100644
> +++ b/drivers/char/tpm/tpm.h
> @@ -69,6 +69,7 @@ struct tpm_vendor_specific {
>
> int irq;
> int probed_irq;
> + bool int_received;
Ugh, yes, right, tis doesn't have its own driver private structure
yet.
Please add a comment 'FIXME: belongs in tpm_tis driver private data'
Or, better, add a driver private structure to hold this data.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rcu: Make nocb leader kthreads process pending callbacks after spawning
On Wed, Aug 27, 2014 at 04:43:40PM -0400, Pranith Kumar wrote:
> The nocb callbacks generated before the nocb kthreads are spawned are
> enqueued in the nocb queue for later processing. Commit fbce7497ee5af ("rcu:
> Parallelize and economize NOCB kthread wakeups") introduced nocb leader
> kthreads
> which checked the nocb_leader_wake flag to see if there were any such pending
> callbacks. A case was reported in which newly spawned leader kthreads were not
> processing the pending callbacks as this flag was not set, which led to a boot
> hang.
>
> The following commit ensures that the newly spawned nocb kthreads process the
> pending callbacks by allowing the kthreads to run immediately after spawning
> instead of waiting. This is done by inverting the logic of nocb_leader_wake
> tests to nocb_leader_sleep which allows us to use the default initialization
> of
> this flag to 0 to let the kthreads run.
>
> Reported-by: Amit Shah
> Signed-off-by: Pranith Kumar
> Link: http://www.spinics.net/lists/kernel/msg1802899.html
Thank you, Pranith, queued. I have also backported to v3.17-rc2,
and am testing both. A sneak preview of the backport is shown below,
please let me know if you see any problems with it. (The reason for
the backport is to submit to 3.17 as a fix for a regression.)
Thanx, Paul
rcu: Make nocb leader kthreads process pending callbacks after spawning
The nocb callbacks generated before the nocb kthreads are spawned are
enqueued in the nocb queue for later processing. Commit fbce7497ee5af ("rcu:
Parallelize and economize NOCB kthread wakeups") introduced nocb leader kthreads
which checked the nocb_leader_wake flag to see if there were any such pending
callbacks. A case was reported in which newly spawned leader kthreads were not
processing the pending callbacks as this flag was not set, which led to a boot
hang.
The following commit ensures that the newly spawned nocb kthreads process the
pending callbacks by allowing the kthreads to run immediately after spawning
instead of waiting. This is done by inverting the logic of nocb_leader_wake
tests to nocb_leader_sleep which allows us to use the default initialization of
this flag to 0 to let the kthreads run.
Reported-by: Amit Shah
Signed-off-by: Pranith Kumar
Link: http://www.spinics.net/lists/kernel/msg1802899.html
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 71e64c718f75..6a86eb7bac45 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -358,7 +358,7 @@ struct rcu_data {
struct rcu_head **nocb_gp_tail;
long nocb_gp_count;
long nocb_gp_count_lazy;
- bool nocb_leader_wake; /* Is the nocb leader thread awake? */
+ bool nocb_leader_sleep; /* Is the nocb leader thread asleep? */
struct rcu_data *nocb_next_follower;
/* Next follower in wakeup chain. */
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 00dc411e9676..a7997e272564 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2074,9 +2074,9 @@ static void wake_nocb_leader(struct rcu_data *rdp, bool
force)
if (!ACCESS_ONCE(rdp_leader->nocb_kthread))
return;
- if (!ACCESS_ONCE(rdp_leader->nocb_leader_wake) || force) {
+ if (ACCESS_ONCE(rdp_leader->nocb_leader_sleep) || force) {
/* Prior xchg orders against prior callback enqueue. */
- ACCESS_ONCE(rdp_leader->nocb_leader_wake) = true;
+ ACCESS_ONCE(rdp_leader->nocb_leader_sleep) = false;
wake_up(_leader->nocb_wq);
}
}
@@ -2253,7 +2253,7 @@ wait_again:
if (!rcu_nocb_poll) {
trace_rcu_nocb_wake(my_rdp->rsp->name, my_rdp->cpu, "Sleep");
wait_event_interruptible(my_rdp->nocb_wq,
-ACCESS_ONCE(my_rdp->nocb_leader_wake));
+ !ACCESS_ONCE(my_rdp->nocb_leader_sleep));
/* Memory barrier handled by smp_mb() calls below and repoll. */
} else if (firsttime) {
firsttime = false; /* Don't drown trace log with "Poll"! */
@@ -2292,12 +2292,12 @@ wait_again:
schedule_timeout_interruptible(1);
/* Rescan in case we were a victim of memory ordering. */
- my_rdp->nocb_leader_wake = false;
- smp_mb(); /* Ensure _wake false before scan. */
+ my_rdp->nocb_leader_sleep = true;
+ smp_mb(); /* Ensure _sleep true before scan. */
for (rdp = my_rdp; rdp; rdp = rdp->nocb_next_follower)
if (ACCESS_ONCE(rdp->nocb_head)) {
/* Found CB, so short-circuit next wait. */
- my_rdp->nocb_leader_wake = true;
+
Re: [PATCH v10 00/21] Support ext4 on NV-DIMMs
On Wed, 27 Aug 2014 17:12:50 -0400 Matthew Wilcox wrote: > On Wed, Aug 27, 2014 at 01:06:13PM -0700, Andrew Morton wrote: > > On Tue, 26 Aug 2014 23:45:20 -0400 Matthew Wilcox > > wrote: > > > > > One of the primary uses for NV-DIMMs is to expose them as a block device > > > and use a filesystem to store files on the NV-DIMM. While that works, > > > it currently wastes memory and CPU time buffering the files in the page > > > cache. We have support in ext2 for bypassing the page cache, but it > > > has some races which are unfixable in the current design. This series > > > of patches rewrite the underlying support, and add support for direct > > > access to ext4. > > > > Sat down to read all this but I'm finding it rather unwieldy - it's > > just a great blob of code. Is there some overall > > what-it-does-and-how-it-does-it roadmap? > > The overall goal is to map persistent memory / NV-DIMMs directly to > userspace. We have that functionality in the XIP code, but the way > it's structured is unsuitable for filesystems like ext4 & XFS, and > it has some pretty ugly races. When thinking about looking at the patchset I wonder things like how does mmap work, in what situations does a page get COWed, how do we handle partial pages at EOF, etc. I guess that's all part of the filemap_xip legacy, the details of which I've totally forgotten. > Patches 1 & 3 are simply bug-fixes. They should go in regardless of > the merits of anything else in this series. > > Patch 2 changes the API for the direct_access block_device_operation so > it can report more than a single page at a time. As the series evolved, > this work also included moving support for partitioning into the VFS > where it belongs, handling various error cases in the VFS and so on. > > Patch 4 is an optimisation. It's poor form to make userspace take two > faults for the same dereference. > > Patch 5 gives us a VFS flag for the DAX property, which lets us get rid of > the get_xip_mem() method later on. > > Patch 6 is also prep work; Al Viro liked it enough that it's now in > his tree. > > The new DAX code is then dribbled in over patches 7-11, split up by > functional area. At each stage, the ext2-xip code is converted over to > the new DAX code. > > Patches 12-18 delete the remnants of the old XIP code, and fix the things > in ext2 that Jan didn't like when he reviewed them for ext4 :-) > > Patches 19 & 20 are the work to make ext4 use DAX. > > Patch 21 is some final cleanup of references to the old XIP code, renaming > it all to DAX. hrm. > > Some explanation of why one would use ext4 instead of, say, > > suitably-modified ramfs/tmpfs/rd/etc? > > ramfs and tmpfs really rely on the page cache. They're not exactly > built for permanence either. brd also relies on the page cache, and > there's a clear desire to use a filesystem instead of a block device > for all the usual reasons of access permissions, grow/shrink, etc. > > Some people might want to use XFS instead of ext4. We're starting with > ext4, but we've been keeping an eye on what other filesystems might want > to use. btrfs isn't going to use the DAX code, but some of the other > pieces will probably come in handy. > > There are also at least three people working on their own filesystems > specially designed for persistent memory. I wish them all the best > ... but I'd like to get this infrastructure into place. This is the sort of thing which first-timers (this one at least) like to see in [0/n]. > > Performance testing results? > > I haven't been running any performance tests. What sort of performance > tests would be interesting for you to see? fs benchmarks? `dd' would be a good start ;) I assume (because I wasn't told!) that there are two objectives here: 1) reduce memory consumption by not maintaining pagecache and 2) reduce CPU cost by avoiding the double-copies. These things are pretty easily quantified. And really they must be quantified as part of the developer testing, because if you find they've worsened then holy cow, what went wrong. > > Carsten Otte wrote filemap_xip.c and may be a useful reviewer of this > > work. > > I cc'd him on some earlier versions and didn't hear anything back. It felt > rude to keep plying him with 20+ patches every month. OK. > > All the patch subjects violate Documentation/SubmittingPatches > > section 15 ;) > > errr ... which bit? I used git format-patch to create them. None of the patch titles identify the subsystem(s) which they're hitting. eg, "Introduce IS_DAX(inode)" is an ext2 patch, but nobody would know that from browsing the titles. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 percpu/for-3.18-consistent-ops] Revert "powerpc: Replace __get_cpu_var uses"
Hi Tejun, On Wed, 27 Aug 2014 11:26:09 -0400 Tejun Heo wrote: > > From 23f66e2d661b4d3226d16e25910a9e9472ce2410 Mon Sep 17 00:00:00 2001 > From: Tejun Heo > Date: Wed, 27 Aug 2014 11:18:29 -0400 > > This reverts commit 5828f666c069af74e00db21559f1535103c9f79a due to > build failure after merging with pending powerpc changes. I can't see any pending powerpc changes that would obviously affect this ... -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
[PATCH 2/2] x86: iosf: Add debugfs support
Allows access to the iosf sideband through debugfs.
Signed-off-by: David E. Box
---
arch/x86/kernel/iosf_mbi.c | 74 ++
1 file changed, 74 insertions(+)
diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
index d30acdc..bf848ca 100644
--- a/arch/x86/kernel/iosf_mbi.c
+++ b/arch/x86/kernel/iosf_mbi.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -187,6 +189,75 @@ bool iosf_mbi_available(void)
}
EXPORT_SYMBOL(iosf_mbi_available);
+/** debugfs begin /
+static u32 dbg_mdr;
+static u32 dbg_mcr;
+static u32 dbg_mcrx;
+
+static int mcr_get(void *data, u64 *val)
+{
+ *val = *(u32 *)data;
+ return 0;
+}
+
+static int mcr_set(void *data, u64 val)
+{
+ u8 command = ((u32)val & 0xFF00) >> 24,
+ port= ((u32)val & 0x00FF) >> 16,
+ offset = ((u32)val & 0xFF00) >> 8;
+ int err;
+
+ *(u32 *)data = val;
+
+ if (!capable(CAP_SYS_RAWIO))
+ return -EACCES;
+
+ if (command & 1u)
+ err = iosf_mbi_write(port,
+ command,
+ dbg_mcrx | offset,
+ dbg_mdr);
+ else
+ err = iosf_mbi_read(port,
+ command,
+ dbg_mcrx | offset,
+ _mdr);
+
+ return err;
+}
+DEFINE_SIMPLE_ATTRIBUTE(iosf_mcr_fops, mcr_get, mcr_set , "%llx\n");
+
+static struct dentry *iosf_dbg;
+static void iosf_sideband_debug_init(void)
+{
+ struct dentry *d;
+
+ iosf_dbg = debugfs_create_dir("iosf_sb", NULL);
+ if (IS_ERR_OR_NULL(iosf_dbg))
+ return;
+
+ /* mdr */
+ d = debugfs_create_x32("mdr", 0660, iosf_dbg, _mdr);
+ if (IS_ERR_OR_NULL(d))
+ goto cleanup;
+
+ /* mcrx */
+ debugfs_create_x32("mcrx", 0660, iosf_dbg, _mcrx);
+ if (IS_ERR_OR_NULL(d))
+ goto cleanup;
+
+ /* mcr - initiates mailbox tranaction */
+ debugfs_create_file("mcr", 0660, iosf_dbg, _mcr, _mcr_fops);
+ if (IS_ERR_OR_NULL(d))
+ goto cleanup;
+
+ return;
+
+cleanup:
+ debugfs_remove_recursive(d);
+}
+/** debugfs end /
+
static int iosf_mbi_probe(struct pci_dev *pdev,
const struct pci_device_id *unused)
{
@@ -217,11 +288,14 @@ static struct pci_driver iosf_mbi_pci_driver = {
static int __init iosf_mbi_init(void)
{
+ iosf_sideband_debug_init();
return pci_register_driver(_mbi_pci_driver);
}
static void __exit iosf_mbi_exit(void)
{
+ debugfs_remove_recursive(iosf_dbg);
+
pci_unregister_driver(_mbi_pci_driver);
if (mbi_pdev) {
pci_dev_put(mbi_pdev);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] x86: iosf: Add Kconfig prompt for IOSF_MBI selection
Fixes an error in having the iosf build as 'default m'. On X86 SoC's the iosf sideband is the only way to access information for some registers, as opposed to through MSR's on other Intel architectures. While selecting IOSF_MBI is preferred, it does mean carrying extra code on non-SoC architectures. This exports the selection to the user, allowing those driver writers to compile out iosf code if it's not being built. Signed-off-by: David E. Box --- arch/x86/Kconfig | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d24887b..e07e2a5 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2400,9 +2400,19 @@ config X86_DMA_REMAP depends on STA2X11 config IOSF_MBI - tristate - default m + tristate "Intel System On Chip IOSF Sideband support" depends on PCI + ---help--- + Enables sideband access to mailbox registers on SoC's. The sideband is + available on the following platforms. This list is not meant to be + exclusive. + - BayTrail + - Cherryview + - Braswell + - Quark + + You should say Y if you are running a kernel on one of these + platforms. source "net/Kconfig" -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] x86: iosf: change Kconfig selection and add debugfs
Fixes a flaw with the iosf driver buidling as 'default m' on all x86 systems. Adds debugfs support. David E. Box (2): x86: iosf: Add Kconfig prompt for IOSF_MBI selection x86: iosf: Add debugfs support arch/x86/Kconfig | 14 +++-- arch/x86/kernel/iosf_mbi.c | 74 ++ 2 files changed, 86 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 3/3] powerpc, ptrace: Enable support for miscellaneous registers
Anshuman Khandual [khand...@linux.vnet.ibm.com] wrote:
| This patch enables get and set of miscellaneous registers through ptrace
| PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing new powerpc
| specific register set REGSET_MISC support corresponding to the new ELF
| core note NT_PPC_MISC added previously in this regard.
|
| Signed-off-by: Anshuman Khandual
| ---
| arch/powerpc/kernel/ptrace.c | 81
| 1 file changed, 81 insertions(+)
|
| diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
| index 17642ef..63b883a 100644
| --- a/arch/powerpc/kernel/ptrace.c
| +++ b/arch/powerpc/kernel/ptrace.c
| @@ -1149,6 +1149,76 @@ static int tm_cvmx_set(struct task_struct *target,
const struct user_regset *reg
| #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
|
| /*
| + * Miscellaneous Registers
| + *
| + * struct {
| + * unsigned long dscr;
| + * unsigned long ppr;
| + * unsigned long tar;
| + * };
| + */
| +static int misc_get(struct task_struct *target, const struct user_regset
*regset,
| +unsigned int pos, unsigned int count,
| +void *kbuf, void __user *ubuf)
| +{
| + int ret;
| +
| + /* DSCR register */
| + ret = user_regset_copyout(, , , ,
| + >thread.dscr, 0,
| + sizeof(unsigned long));
| +
| + BUILD_BUG_ON(offsetof(struct thread_struct, dscr) + sizeof(unsigned
long) +
| + sizeof(unsigned long) != offsetof(struct
thread_struct, ppr));
I see these in arch/powerpc/include/asm/processor.h
#ifdef CONFIG_PPC64
unsigned long dscr;
int dscr_inherit;
unsigned long ppr;/* used to save/restore SMT priority */
#endif
where there is an 'int' between ppr and dscr. So, should one of
the above sizeof(unsigned long) be changed to sizeof(int) ?
Also, since we use offsetof(struct thread_struct, field) heavily, a
macro local to the file, may simplify the code.
#define TSO(f) (offsetof(struct thread_struct, f))
| +
| + /* PPR register */
| + if (!ret)
| + ret = user_regset_copyout(, , , ,
| + >thread.ppr, sizeof(unsigned
long),
| + 2 * sizeof(unsigned long));
| +
| + BUILD_BUG_ON(offsetof(struct thread_struct, ppr) + sizeof(unsigned long)
| + != offsetof(struct
thread_struct, tar));
| + /* TAR register */
| + if (!ret)
| + ret = user_regset_copyout(, , , ,
| + >thread.tar, 2 *
sizeof(unsigned long),
| + 3 * sizeof(unsigned long));
| + return ret;
| +}
| +
| +static int misc_set(struct task_struct *target, const struct user_regset
*regset,
| +unsigned int pos, unsigned int count,
| +const void *kbuf, const void __user *ubuf)
| +{
| + int ret;
| +
| + /* DSCR register */
| + ret = user_regset_copyin(, , , ,
| + >thread.dscr, 0,
| + sizeof(unsigned long));
| +
| + BUILD_BUG_ON(offsetof(struct thread_struct, dscr) + sizeof(unsigned
long) +
| + sizeof(unsigned long) != offsetof(struct thread_struct,
ppr));
| +
| + /* PPR register */
| + if (!ret)
| + ret = user_regset_copyin(, , , ,
| + >thread.ppr,
sizeof(unsigned long),
| + 2 * sizeof(unsigned long));
| +
| + BUILD_BUG_ON(offsetof(struct thread_struct, ppr) + sizeof(unsigned long)
| + != offsetof(struct
thread_struct, tar));
| +
| + /* TAR register */
| + if (!ret)
| + ret = user_regset_copyin(, , , ,
| + >thread.tar, 2 *
sizeof(unsigned long),
| + 3 * sizeof(unsigned long));
| + return ret;
| +}
| +
| +/*
| * These are our native regset flavors.
| */
| enum powerpc_regset {
| @@ -1169,6 +1239,7 @@ enum powerpc_regset {
| REGSET_TM_CFPR, /* TM checkpointed FPR */
| REGSET_TM_CVMX, /* TM checkpointed VMX */
| #endif
| + REGSET_MISC /* Miscellaneous */
| };
|
| static const struct user_regset native_regsets[] = {
| @@ -1225,6 +1296,11 @@ static const struct user_regset native_regsets[] = {
| .active = tm_cvmx_active, .get = tm_cvmx_get, .set = tm_cvmx_set
| },
| #endif
| + [REGSET_MISC] = {
| + .core_note_type = NT_PPC_MISC, .n = 3,
| + .size = sizeof(u64), .align = sizeof(u64),
| + .get = misc_get, .set = misc_set
| + },
| };
|
| static const struct user_regset_view user_ppc_native_view = {
| @@ -1566,6 +1642,11 @@ static
Re: [PATCH V3 2/3] powerpc, ptrace: Enable support for transactional memory register sets
Anshuman Khandual [khand...@linux.vnet.ibm.com] wrote:
| This patch enables get and set of transactional memory related register
| sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
| four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
| REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
| ELF core note types added previously in this regard.
|
| (1) NT_PPC_TM_SPR
| (2) NT_PPC_TM_CGPR
| (3) NT_PPC_TM_CFPR
| (4) NT_PPC_TM_CVMX
|
| Signed-off-by: Anshuman Khandual
| ---
| arch/powerpc/include/asm/switch_to.h | 8 +
| arch/powerpc/kernel/process.c| 24 ++
| arch/powerpc/kernel/ptrace.c | 792
+--
| 3 files changed, 795 insertions(+), 29 deletions(-)
|
| diff --git a/arch/powerpc/include/asm/switch_to.h
b/arch/powerpc/include/asm/switch_to.h
| index 0e83e7d..2737f46 100644
| --- a/arch/powerpc/include/asm/switch_to.h
| +++ b/arch/powerpc/include/asm/switch_to.h
| @@ -80,6 +80,14 @@ static inline void flush_spe_to_thread(struct task_struct
*t)
| }
| #endif
|
| +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
| +extern void flush_tmregs_to_thread(struct task_struct *);
| +#else
| +static inline void flush_tmregs_to_thread(struct task_struct *t)
| +{
| +}
| +#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
| +
| static inline void clear_task_ebb(struct task_struct *t)
| {
| #ifdef CONFIG_PPC_BOOK3S_64
| diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
| index 31d0215..e247898 100644
| --- a/arch/powerpc/kernel/process.c
| +++ b/arch/powerpc/kernel/process.c
| @@ -695,6 +695,30 @@ static inline void __switch_to_tm(struct task_struct
*prev)
| }
| }
|
| +void flush_tmregs_to_thread(struct task_struct *tsk)
| +{
| + /*
| + * If task is not current, it should have been flushed
| + * already to it's thread_struct during __switch_to().
| + */
| + if (tsk != current)
| + return;
| +
| + preempt_disable();
| + if (tsk->thread.regs) {
| + /*
| + * If we are still current, the TM state need to
| + * be flushed to thread_struct as it will be still
| + * present in the current cpu.
| + */
| + if (MSR_TM_ACTIVE(tsk->thread.regs->msr)) {
| + __switch_to_tm(tsk);
| + tm_recheckpoint_new_task(tsk);
| + }
| + }
| + preempt_enable();
| +}
| +
| /*
| * This is called if we are on the way out to userspace and the
| * TIF_RESTORE_TM flag is set. It checks if we need to reload
| diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
| index 2e3d2bf..17642ef 100644
| --- a/arch/powerpc/kernel/ptrace.c
| +++ b/arch/powerpc/kernel/ptrace.c
| @@ -357,6 +357,17 @@ static int gpr_set(struct task_struct *target, const
struct user_regset *regset,
| return ret;
| }
|
| +/*
| + * When any transaction is active, "thread_struct->transact_fp" holds
| + * the current running value of all FPR registers and "thread_struct->
| + * fp_state" holds the last checkpointed FPR registers state for the
| + * current transaction.
| + *
| + * struct data {
| + * u64 fpr[32];
| + * u64 fpscr;
| + * };
| + */
Maybe a reference to 'struct thread_fp_state' in the comments will help ?
| static int fpr_get(struct task_struct *target, const struct user_regset
*regset,
| unsigned int pos, unsigned int count,
| void *kbuf, void __user *ubuf)
| @@ -365,21 +376,41 @@ static int fpr_get(struct task_struct *target, const
struct user_regset *regset,
| u64 buf[33];
| int i;
| #endif
| - flush_fp_to_thread(target);
| + if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
| + flush_fp_to_thread(target);
| + flush_altivec_to_thread(target);
| + flush_tmregs_to_thread(target);
| + } else {
| + flush_fp_to_thread(target);
| + }
flush_fp_to_thread(target) is uncondtional - so could be outside
the if and else blocks ?
|
| #ifdef CONFIG_VSX
| /* copy to local buffer then write that out */
| - for (i = 0; i < 32 ; i++)
| - buf[i] = target->thread.TS_FPR(i);
| - buf[32] = target->thread.fp_state.fpscr;
| + if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
| + for (i = 0; i < 32 ; i++)
| + buf[i] = target->thread.TS_TRANS_FPR(i);
| + buf[32] = target->thread.transact_fp.fpscr;
| + } else {
| + for (i = 0; i < 32 ; i++)
| + buf[i] = target->thread.TS_FPR(i);
| + buf[32] = target->thread.fp_state.fpscr;
| + }
| return user_regset_copyout(, , , , buf, 0, -1);
|
| #else
| - BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
| - offsetof(struct thread_fp_state, fpr[32][0]));
| + if (MSR_TM_ACTIVE(tsk->thread.regs->msr)) {
| +
[RFC PATCH v3] tpm_tis: verify interrupt during init
On Wed, 27 Aug 2014, Jason Gunthorpe wrote:
> On Wed, Aug 27, 2014 at 04:31:56AM +, Scot Doyle wrote:
>> It doesn't enable stock SeaBIOS machines to suspend/resume before the 30
>> second interrupt timeout, unless using interrupts=0 or force=1.
>
> ? Can you explain that a bit more? interrupts should be detected off
> by suspend/resume time, surely?
Yes, here's dmesg:
[1.491629] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
[ 33.247720] tpm_tis 00:08: tpm_transmit: tpm_send: error -62
[ 33.247731] tpm_tis 00:08: [Hardware Error]: TPM command timed out during
continue self test
[ 33.349888] tpm_tis 00:08: tpm_transmit: tpm_send: error -5
[ 33.459911] tpm_tis 00:08: [Firmware Bug]: TPM interrupt not working,
polling instead
At module load, the misconfigured DSDT is causing the interrupt to be used
during selftest. The interrupt wait times out after 30 seconds, and the
irq is freed, with the module falling back to polling mode.
If suspend/resume occur before falling back to polling mode (within 30
seconds after module load), then the machine freezes on resume because
the module is waiting on the interrupts.
So, this should only affect machines with incorrect ACPI, that are not
using a module parameter, and that are suspended within 30 seconds after
module load. Considering that we are enabling such machines to
automatically work otherwise, I think this is fair.
>> -if (tpm_do_selftest(chip)) {
>> -dev_err(dev, "TPM self test failed\n");
>> -rc = -ENODEV;
>> -goto out_err;
>> -}
>
> Move gettimeout too
Can it be moved? It sends startup(clear) if the TPM isn't yet operational.
>> -if (chip->vendor.irq) {
>> +if (interrupts && chip->vendor.irq) {
>
> Unrelated? Looks unnecessary:
>
>if (!interrupts) {
>irq = 0;
>
>chip->vendor.irq = irq;
>
>if (chip->vendor.irq) {
Setting chip->vendor.irq would erase any we just found in probing?
>> +/* Test interrupt and/or prepare for later save state */
>> +interrupted = false;
>> +if (tpm_do_selftest(chip)) {
>
> As you pointed out before, the commands don't actually fail if
> interrupts are not enabled, they just take a longer time to complete.
Right, the TPM commands don't fail, but tpm_get_timeouts does. I've
simplified the section in this version.
And I've incorporated the other suggestions, thanks!
---
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index e4d0888..6747a47 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -69,6 +69,7 @@ struct tpm_vendor_specific {
int irq;
int probed_irq;
+ bool int_received;
int region_size;
int have_region;
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 2c46734..ad63027 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -505,6 +505,7 @@ static irqreturn_t tis_int_handler(int dummy, void *dev_id)
if (interrupt == 0)
return IRQ_NONE;
+ chip->vendor.int_received = true;
if (interrupt & TPM_INTF_DATA_AVAIL_INT)
wake_up_interruptible(>vendor.read_queue);
if (interrupt & TPM_INTF_LOCALITY_CHANGE_INT)
@@ -612,12 +613,6 @@ static int tpm_tis_init(struct device *dev,
resource_size_t start,
goto out_err;
}
- if (tpm_do_selftest(chip)) {
- dev_err(dev, "TPM self test failed\n");
- rc = -ENODEV;
- goto out_err;
- }
-
/* INTERRUPT Setup */
init_waitqueue_head(>vendor.read_queue);
init_waitqueue_head(>vendor.int_queue);
@@ -693,7 +688,7 @@ static int tpm_tis_init(struct device *dev, resource_size_t
start,
free_irq(i, chip);
}
}
- if (chip->vendor.irq) {
+ if (interrupts && chip->vendor.irq) {
iowrite8(chip->vendor.irq,
chip->vendor.iobase +
TPM_INT_VECTOR(chip->vendor.locality));
@@ -719,6 +714,29 @@ static int tpm_tis_init(struct device *dev,
resource_size_t start,
}
}
+ /* Test interrupt and/or prepare for later save state */
+ chip->vendor.int_received = false;
+ if (tpm_do_selftest(chip)) {
+ if (interrupts && !chip->vendor.int_received) {
+ /* Turn off interrupt */
+ iowrite32(intmask,
+ chip->vendor.iobase +
+ TPM_INT_ENABLE(chip->vendor.locality));
+ free_irq(chip->vendor.irq, chip);
+
+ /* Retry in polling mode */
+ chip->vendor.irq = 0;
+ if (!tpm_do_selftest(chip)) {
+ dev_err(dev, FW_BUG "TPM interrupt not working,
polling instead\n");
+ goto cont;
+ }
+
[PATCH 3/3] lpc_ich: Add Device IDs for Intel 9 Series PCH
This patch adds the LPC Device IDs for the Intel 9 Series PCH.
Signed-off-by: James Ralston
---
drivers/mfd/lpc_ich.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
index 7d8482f..cb41f4f 100644
--- a/drivers/mfd/lpc_ich.c
+++ b/drivers/mfd/lpc_ich.c
@@ -54,6 +54,7 @@
* document number TBD : Avoton SoC
* document number TBD : Coleto Creek
* document number TBD : Wildcat Point-LP
+ * document number TBD : 9 Series
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -216,6 +217,7 @@ enum lpc_chipsets {
LPC_BAYTRAIL, /* Bay Trail SoC */
LPC_COLETO, /* Coleto Creek */
LPC_WPT_LP, /* Wildcat Point-LP */
+ LPC_9S, /* 9 Series */
};
static struct lpc_ich_info lpc_chipset_info[] = {
@@ -519,6 +521,10 @@ static struct lpc_ich_info lpc_chipset_info[] = {
.name = "Wildcat Point_LP",
.iTCO_version = 2,
},
+ [LPC_9S] = {
+ .name = "9 Series",
+ .iTCO_version = 2,
+ },
};
/*
@@ -745,6 +751,11 @@ static const struct pci_device_id lpc_ich_ids[] = {
{ PCI_VDEVICE(INTEL, 0x9cc6), LPC_WPT_LP},
{ PCI_VDEVICE(INTEL, 0x9cc7), LPC_WPT_LP},
{ PCI_VDEVICE(INTEL, 0x9cc9), LPC_WPT_LP},
+ { PCI_VDEVICE(INTEL, 0x8cc1), LPC_9S},
+ { PCI_VDEVICE(INTEL, 0x8cc2), LPC_9S},
+ { PCI_VDEVICE(INTEL, 0x8cc3), LPC_9S},
+ { PCI_VDEVICE(INTEL, 0x8cc4), LPC_9S},
+ { PCI_VDEVICE(INTEL, 0x8cc6), LPC_9S},
{ 0, }, /* End of list */
};
MODULE_DEVICE_TABLE(pci, lpc_ich_ids);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/3] ARM: dts: Enable PWM backlight on rk3288-evb
Am Montag, 25. August 2014, 15:59:27 schrieb Doug Anderson:
> PWM0 is the PWM associated with the LCD backlight. Enable it.
>
> Signed-off-by: Doug Anderson
Applied to my v3.18-next/dts branch.
> ---
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Fix space to tab in 2 places in DTS.
> - Make sure PWM is upper case in prose.
>
> arch/arm/boot/dts/rk3288-evb.dtsi | 53
> +++ 1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
> b/arch/arm/boot/dts/rk3288-evb.dtsi index 2964370..98b69d0 100644
> --- a/arch/arm/boot/dts/rk3288-evb.dtsi
> +++ b/arch/arm/boot/dts/rk3288-evb.dtsi
> @@ -10,6 +10,7 @@
> * GNU General Public License for more details.
> */
>
> +#include
> #include "rk3288.dtsi"
>
> / {
> @@ -17,6 +18,48 @@
> reg = <0x0 0x8000>;
> };
>
> + backlight {
> + compatible = "pwm-backlight";
> + brightness-levels = <
> + 0 1 2 3 4 5 6 7
> + 8 9 10 11 12 13 14 15
> + 16 17 18 19 20 21 22 23
> + 24 25 26 27 28 29 30 31
> + 32 33 34 35 36 37 38 39
> + 40 41 42 43 44 45 46 47
> + 48 49 50 51 52 53 54 55
> + 56 57 58 59 60 61 62 63
> + 64 65 66 67 68 69 70 71
> + 72 73 74 75 76 77 78 79
> + 80 81 82 83 84 85 86 87
> + 88 89 90 91 92 93 94 95
> + 96 97 98 99 100 101 102 103
> + 104 105 106 107 108 109 110 111
> + 112 113 114 115 116 117 118 119
> + 120 121 122 123 124 125 126 127
> + 128 129 130 131 132 133 134 135
> + 136 137 138 139 140 141 142 143
> + 144 145 146 147 148 149 150 151
> + 152 153 154 155 156 157 158 159
> + 160 161 162 163 164 165 166 167
> + 168 169 170 171 172 173 174 175
> + 176 177 178 179 180 181 182 183
> + 184 185 186 187 188 189 190 191
> + 192 193 194 195 196 197 198 199
> + 200 201 202 203 204 205 206 207
> + 208 209 210 211 212 213 214 215
> + 216 217 218 219 220 221 222 223
> + 224 225 226 227 228 229 230 231
> + 232 233 234 235 236 237 238 239
> + 240 241 242 243 244 245 246 247
> + 248 249 250 251 252 253 254 255>;
> + default-brightness-level = <128>;
> + enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_en>;
> + pwms = < 0 100 PWM_POLARITY_INVERTED>;
> + };
> +
> gpio-keys {
> compatible = "gpio-keys";
> #address-cells = <1>;
> @@ -81,6 +124,10 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
> @@ -102,6 +149,12 @@
> };
>
> {
> + backlight {
> + bl_en: bl-en {
> + rockchip,pins = <7 2 RK_FUNC_GPIO _pull_none>;
> + };
> + };
> +
> buttons {
> pwrbtn: pwrbtn {
> rockchip,pins = <0 5 RK_FUNC_GPIO _pull_up>;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ata_piix: Add Device IDs for Intel 9 Series PCH
This patch adds the IDE mode SATA Device IDs for the Intel 9 Series PCH.
Signed-off-by: James Ralston
---
drivers/ata/ata_piix.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 893e30e..ffbe625 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -340,6 +340,14 @@ static const struct pci_device_id piix_pci_tbl[] = {
{ 0x8086, 0x0F21, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_byt },
/* SATA Controller IDE (Coleto Creek) */
{ 0x8086, 0x23a6, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ /* SATA Controller IDE (9 Series) */
+ { 0x8086, 0x8c88, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
+ /* SATA Controller IDE (9 Series) */
+ { 0x8086, 0x8c89, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
+ /* SATA Controller IDE (9 Series) */
+ { 0x8086, 0x8c80, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (9 Series) */
+ { 0x8086, 0x8c81, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
{ } /* terminate list */
};
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] HID: picolcd: sanity check report size in raw_event() callback
On Wed, 27 Aug 2014, Jiri Kosina wrote:
> > Is it worth adding report->id to this hid_warn()?
> >
> > A valid device is not expected to ever send >64 bytes reports but in
> > case a firmware update would do so it would help to know for which
> > report it was.
>
> It definitely wouldn't hurt. Pull request with the original patch is now
> on its way to Linus though, so let's do this as a followup patch on top
> once this is merged.
I've just queued the below for 3.18.
From: Jiri Kosina
Subject: [PATCH] HID: picolcd: be more verbose when reporting report size error
picolcd device is not expected to send any report with size larger than 64
bytes.
If this impossible event happens (sic!), print also a report ID to allow
for easier debugging.
Suggested-by: Bruno Prémont
Signed-off-by: Jiri Kosina
---
drivers/hid/hid-picolcd_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
index 020df3c..c1b29a9 100644
--- a/drivers/hid/hid-picolcd_core.c
+++ b/drivers/hid/hid-picolcd_core.c
@@ -351,8 +351,8 @@ static int picolcd_raw_event(struct hid_device *hdev,
return 1;
if (size > 64) {
- hid_warn(hdev, "invalid size value (%d) for picolcd raw
event\n",
- size);
+ hid_warn(hdev, "invalid size value (%d) for picolcd raw event
(%d)\n",
+ size, report->id);
return 0;
}
--
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 v5 2/3] ARM: dts: Add main PWM info to rk3288
Am Montag, 25. August 2014, 15:59:26 schrieb Doug Anderson:
> This adds the PWM info (other than the VOP PWM) to the main rk3288
> dtsi file.
>
> Signed-off-by: Caesar Wang
> Signed-off-by: Doug Anderson
> ---
Applied to my v3.18-next/dts branch.
I've changed the RK_FUNC_3 to its numerical equivalent for now, as the pinctrl
binding change is probably going through the pinctrl tree at some point.
> Changes in v5:
> - Back to version 3 (no rockchip,grf).
>
> Changes in v4:
> - Add rockchip,grf to pwm nodes.
>
> Changes in v3: None
>
> arch/arm/boot/dts/rk3288.dtsi | 68
> +++ 1 file changed, 68
> insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index 36be7bb..9c9d9c5 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -261,6 +261,50 @@
> status = "disabled";
> };
>
> + pwm0: pwm@ff68 {
> + compatible = "rockchip,rk3288-pwm";
> + reg = <0xff68 0x10>;
> + #pwm-cells = <3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin>;
> + clocks = < PCLK_PWM>;
> + clock-names = "pwm";
> + status = "disabled";
> + };
> +
> + pwm1: pwm@ff680010 {
> + compatible = "rockchip,rk3288-pwm";
> + reg = <0xff680010 0x10>;
> + #pwm-cells = <3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin>;
> + clocks = < PCLK_PWM>;
> + clock-names = "pwm";
> + status = "disabled";
> + };
> +
> + pwm2: pwm@ff680020 {
> + compatible = "rockchip,rk3288-pwm";
> + reg = <0xff680020 0x10>;
> + #pwm-cells = <3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin>;
> + clocks = < PCLK_PWM>;
> + clock-names = "pwm";
> + status = "disabled";
> + };
> +
> + pwm3: pwm@ff680030 {
> + compatible = "rockchip,rk3288-pwm";
> + reg = <0xff680030 0x10>;
> + #pwm-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin>;
> + clocks = < PCLK_PWM>;
> + clock-names = "pwm";
> + status = "disabled";
> + };
> +
> pmu: power-management@ff73 {
> compatible = "rockchip,rk3288-pmu", "syscon";
> reg = <0xff73 0x100>;
> @@ -611,5 +655,29 @@
> rockchip,pins = <5 15 3 _pull_none>;
> };
> };
> +
> + pwm0 {
> + pwm0_pin: pwm0-pin {
> + rockchip,pins = <7 0 RK_FUNC_1 _pull_none>;
> + };
> + };
> +
> + pwm1 {
> + pwm1_pin: pwm1-pin {
> + rockchip,pins = <7 1 RK_FUNC_1 _pull_none>;
> + };
> + };
> +
> + pwm2 {
> + pwm2_pin: pwm2-pin {
> + rockchip,pins = <7 22 RK_FUNC_3
> _pull_none>;
> + };
> + };
> +
> + pwm3 {
> + pwm3_pin: pwm3-pin {
> + rockchip,pins = <7 23 RK_FUNC_3
> _pull_none>;
> + };
> + };
> };
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator: fix kernel-doc warnings in header files
From: Randy Dunlap
Fix kernel-doc warnings in regulator header files:
Warning(..//include/linux/regulator/machine.h:140): No description found for
parameter 'ramp_disable'
Warning(..//include/linux/regulator/driver.h:279): No description found for
parameter 'linear_ranges'
Warning(..//include/linux/regulator/driver.h:279): No description found for
parameter 'n_linear_ranges'
Signed-off-by: Randy Dunlap
---
include/linux/regulator/driver.h |2 ++
include/linux/regulator/machine.h |1 +
2 files changed, 3 insertions(+)
Please feel free to change these descriptions.
Index: lnx-317-rc2/include/linux/regulator/machine.h
===
--- lnx-317-rc2.orig/include/linux/regulator/machine.h
+++ lnx-317-rc2/include/linux/regulator/machine.h
@@ -85,6 +85,7 @@ struct regulator_state {
* bootloader then it will be enabled when the constraints are
* applied.
* @apply_uV: Apply the voltage constraint when initialising.
+ * @ramp_disable: Disable ramp delay when initialising or when setting voltage.
*
* @input_uV: Input voltage for regulator when supplied by another regulator.
*
Index: lnx-317-rc2/include/linux/regulator/driver.h
===
--- lnx-317-rc2.orig/include/linux/regulator/driver.h
+++ lnx-317-rc2/include/linux/regulator/driver.h
@@ -218,6 +218,8 @@ enum regulator_type {
* @linear_min_sel: Minimal selector for starting linear mapping
* @fixed_uV: Fixed voltage of rails.
* @ramp_delay: Time to settle down after voltage change (unit: uV/us)
+ * @linear_ranges: A constant table of possible voltage ranges.
+ * @n_linear_ranges: Number of entries in the @linear_ranges table.
* @volt_table: Voltage mapping table (if table based mapping)
*
* @vsel_reg: Register for selector when using regulator_regmap_X_voltage_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 00/21] Support ext4 on NV-DIMMs
On Wed, 27 Aug 2014 16:22:20 -0500 (CDT) Christoph Lameter wrote: > > Some explanation of why one would use ext4 instead of, say, > > suitably-modified ramfs/tmpfs/rd/etc? > > The NVDIMM contents survive reboot and therefore ramfs and friends wont > work with it. See "suitably modified". Presumably this type of memory would need to come from a particular page allocator zone. ramfs would be unweildy due to its use to dentry/inode caches, but rd/etc should be feasible. I dunno, I'm not proposing implementations - I'm asking obvious questions. Stuff which should have been addressed in the changelogs before one even starts to read the code... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ahci: Add Device IDs for Intel 9 Series PCH
This patch adds the AHCI mode SATA Device IDs for the Intel 9 Series PCH.
Signed-off-by: James Ralston
---
drivers/ata/ahci.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index a29f801..bca3d64 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -305,6 +305,14 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x9c85), board_ahci }, /* Wildcat Point-LP RAID */
{ PCI_VDEVICE(INTEL, 0x9c87), board_ahci }, /* Wildcat Point-LP RAID */
{ PCI_VDEVICE(INTEL, 0x9c8f), board_ahci }, /* Wildcat Point-LP RAID */
+ { PCI_VDEVICE(INTEL, 0x8c82), board_ahci }, /* 9 Series AHCI */
+ { PCI_VDEVICE(INTEL, 0x8c83), board_ahci }, /* 9 Series AHCI */
+ { PCI_VDEVICE(INTEL, 0x8c84), board_ahci }, /* 9 Series RAID */
+ { PCI_VDEVICE(INTEL, 0x8c85), board_ahci }, /* 9 Series RAID */
+ { PCI_VDEVICE(INTEL, 0x8c86), board_ahci }, /* 9 Series RAID */
+ { PCI_VDEVICE(INTEL, 0x8c87), board_ahci }, /* 9 Series RAID */
+ { PCI_VDEVICE(INTEL, 0x8c8e), board_ahci }, /* 9 Series RAID */
+ { PCI_VDEVICE(INTEL, 0x8c8f), board_ahci }, /* 9 Series RAID */
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested
On Wed, Aug 27, 2014 at 2:19 PM, Olof Johansson wrote:
> On Wed, Aug 27, 2014 at 2:03 PM, Sonny Rao wrote:
>> This is a bug fix for using physical arch timers when
>> the arch_timer_use_virtual boolean is false. It restores the
>> arch_counter_get_cntpct() function after removal in
>>
>> 0d651e4e "clocksource: arch_timer: use virtual counters"
>>
>> and completes the implementation of memory mapped access for physical
>> timers, so if a system is trying to use physical timers, it will
>> function properly.
>>
>> Signed-off-by: Sonny Rao
>
> Acked-by: Olof Johansson
>
> This should have a:
>
> Fixes: 0d651e4e65e9 ("clocksource: arch_timer: use virtual counters")
>
> tag too, and possibly cc stable?
Ok, as far as stable goes, this patch wouldn't apply cleanly going all
the way back to 0d651e4e65e9
As-is, it would need to go after 220069945b29 "clocksource:
arch_timer: Add support for memory mapped timers" and there would need
to be another, simpler, version that went between those two commits.
So, I'm not sure what to do in this situation regarding stable?
>
>
> -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] pinctrl: qcom: Release pin ranges when gpiochip_irqchip_add fails
On Wed, Aug 27, 2014 at 3:57 AM, Pramod Gurav
wrote:
> This patches adds a call to gpiochip_remove_pin_ranges when
> gpiochip_irqchip_add fails to release memory allocated for pin_ranges.
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -845,6 +845,7 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
>IRQ_TYPE_NONE);
> if (ret) {
> dev_err(pctrl->dev, "Failed to add irqchip to gpiochip\n");
> + gpiochip_remove_pin_ranges(chip);
> return -ENOSYS;
> }
Good catch, I guess this was lost in the introduction of gpiochip_irqchip...
Rather than just releasing the pin_ranges of the gpio_chip you should
probably add a gpiochip_remove() both here and in the case of
gpiochip_add_pin_range() failing.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
