Re: [PATCH] ACPI/IORT: Fix iort_node_get_id() mapping entries indexing
On 2017/1/6 2:29, Lorenzo Pieralisi wrote:
Commit 618f535a6062 ("ACPI/IORT: Add single mapping function")
introduced a function (iort_node_get_id()) to retrieve ids for IORT
named components.
iort_node_get_id() takes an index as input to refer to a specific
mapping entry in the mapping array to retrieve the id at a specific
index provided the index is below the total mapping count; currently the
index is used to retrieve the mapping value from the correct entry but
not to dereference the correct entry while retrieving the mapping
output_reference (ie IORT parent pointer), which consequently always
resolves to the output_reference of the first entry in the mapping
array.
Update the map array entry pointer computation in iort_node_get_id() to
take into account the index value, fixing the issue.
Fixes: 618f535a6062 ("ACPI/IORT: Add single mapping function")
Reported-by: Hanjun Guo
Signed-off-by: Lorenzo Pieralisi
Cc: Hanjun Guo
Cc: Sinan Kaya
Cc: Tomasz Nowicki
Cc: Nate Watterson
Cc: "Rafael J. Wysocki"
---
drivers/acpi/arm64/iort.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index e0d2e6e..ba156c5 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -333,7 +333,7 @@ struct acpi_iort_node *iort_node_get_id(struct
acpi_iort_node *node,
return NULL;
map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
- node->mapping_offset);
+ node->mapping_offset + index * sizeof(*map));
/* Firmware bug! */
if (!map->output_reference) {
@@ -348,10 +348,10 @@ struct acpi_iort_node *iort_node_get_id(struct
acpi_iort_node *node,
if (!(IORT_TYPE_MASK(parent->type) & type_mask))
return NULL;
- if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
+ if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
- *id_out = map[index].output_base;
+ *id_out = map->output_base;
return parent;
}
}
Reviewed-by: Hanjun Guo
Re: [PATCH net-next] bridge: multicast to unicast
On Sat, 2017-01-07 at 16:15 +0100, Linus Lüssing wrote: > Actually, I do not quite understand that remark in the mac80211 > multicast-to-unicast patch. IP should not care about the ethernet > header? But it does, for example RFC 1122 states: When a host sends a datagram to a link-layer broadcast address, the IP destination address MUST be a legal IP broadcast or IP multicast address. A host SHOULD silently discard a datagram that is received via a link-layer broadcast (see Section 2.4) but does not specify an IP multicast or broadcast destination address. You can probably find other examples too. johannes
[PATCH v1] irqchip: irq-mips-gic:- Handle return NULL error from ioremap_nocache
Here, If ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.
This error check will avoid NULL pointer dereference.
Signed-off-by: Arvind Yadav
---
drivers/irqchip/irq-mips-gic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index c01c09e..eeea2e8 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -979,6 +979,8 @@ static void __init __gic_init(unsigned long gic_base_addr,
__gic_base_addr = gic_base_addr;
gic_base = ioremap_nocache(gic_base_addr, gic_addrspace_size);
+ if (!gic_base)
+ panic("Failed to map GIC memory");
gicconfig = gic_read(GIC_REG(SHARED, GIC_SH_CONFIG));
gic_shared_intrs = (gicconfig & GIC_SH_CONFIG_NUMINTRS_MSK) >>
--
1.9.1
Re: [PATCH net-next] bridge: multicast to unicast
On Sat, 2017-01-07 at 15:55 +0100, Linus Lüssing wrote:
> On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote:
> > Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> > >
> > > > The bridge layer can use IGMP snooping to ensure that the
> > > > multicast
> > > > stream is only transmitted to clients that are actually a
> > > > member of
> > > > the group. Can the mac80211 feature do the same?
> > >
> > > No, it'll convert the packet for all clients that are behind that
> > > netdev. But that's an argument for dropping the mac80211 feature,
> > > which
> > > hasn't been merged upstream yet, no?
> >
> > But there is multicast/broadcast traffic like e.g. ARP and some IP
> > multicast groups that are not covered by IGMP snooping. The
> > mac80211
> > patch converts this to unicast as well, which the bridge cannot do.
> >
> > That way, these features both complement and overlap each other.
>
> Right, I'd agree with that.
Ok.
> I didn't write it explicitly in the commit message, but yes, the
> like anything concerning bridge multicast snooping, bridge
> multicast-to-unicast can only affect packets as noted in
> RFC4541 ("Considerations for Internet Group Management Protocol (IGMP)
> and Multicast Listener Discovery (MLD) Snooping Switches"), too.
>
> So it is only working for IPv4 multicast, excluding link-local
> (224.0.0.0/24), and IPv6 multicast, excluding all-host-multicast
> (ff02::1).
>
> And does not concern ARP in any way.
>
>
> The nice complementary effect is, that the bridge can first sieve
> out those IP packets thanks to IGMP/MLD snooping knowledge and for
> anything else, like ARP, 224.0.0.x or ff02::1, the mac80211
> multicast-to-unicast could do its job.
>
>
> For APs with a small number of STAs (like your private home AP),
> you might want to enable both bridge multicast-to-unicast and
> mac80211 multicast-to-unicast for this complementary effect. While
> on public APs with 30 to 50 STAs with varying distances and bitrates,
> you might only one to enable the bridge one, because sending an ARP
> packet 50x might actually reduce performance and airtime
> significantly.
Does it make sense to implement the two in separate layers though?
Clearly, this part needs to be implemented in the bridge layer due to
the snooping knowledge, but the code is very similar to what mac80211
has now.
It would probably not make sense to combine the two options into one,
but it seems relatively simple for bridge to also implement the one
mac80211 tentatively has now, with multiple benefits:
* single place for configuration, leading to less possible confusion
* single implementation for all wireless devices, including ones with
Full-MAC firmware that don't use mac80211
* code sharing for the duplication, although admittedly not so much
Thoughts?
johannes
Re: [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface
Hi Lorenzo,
On 2017-01-03 18:34, Lorenzo Pieralisi wrote:
With the introduction of the new iommu_{register/get}_instance()
interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT
agnostic") (based on struct fwnode_handle as look-up token, so firmware
agnostic) to register IOMMU instances with the core IOMMU layer there is
no reason to keep the old OF based interface around any longer.
Convert all the IOMMU drivers (and OF IOMMU core code) that rely on the
of_iommu_{set/get}_ops() to the new kernel interface to register/retrieve
IOMMU instances and remove the of_iommu_{set/get}_ops() remaining glue
code in order to complete the interface rework.
Signed-off-by: Lorenzo Pieralisi
Cc: Matthias Brugger
Cc: Will Deacon
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: Marek Szyprowski
---
Exynos, msm and mtk code compile tested only owing to lack of
test platforms, I would appreciate some help in testing this
patch on those platforms before merging it even if it is just
a simple interface conversion.
Tested-by: Marek Szyprowski
Thanks,
Lorenzo
drivers/iommu/exynos-iommu.c | 2 +-
drivers/iommu/msm_iommu.c| 2 +-
drivers/iommu/mtk_iommu.c| 2 +-
drivers/iommu/of_iommu.c | 4 ++--
include/linux/of_iommu.h | 11 ---
5 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 57ba0d3..b79e4c4 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -628,7 +628,7 @@ static int __init exynos_sysmmu_probe(struct
platform_device *pdev)
pm_runtime_enable(dev);
- of_iommu_set_ops(dev->of_node, &exynos_iommu_ops);
+ iommu_register_instance(dev->fwnode, &exynos_iommu_ops);
return 0;
}
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index b09692b..9cd3cee 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -737,7 +737,7 @@ static int msm_iommu_probe(struct platform_device *pdev)
}
list_add(&iommu->dev_node, &qcom_iommu_devices);
- of_iommu_set_ops(pdev->dev.of_node, &msm_iommu_ops);
+ iommu_register_instance(pdev->dev.fwnode, &msm_iommu_ops);
pr_info("device mapped at %p, irq %d with %d ctx banks\n",
iommu->base, iommu->irq, iommu->ncb);
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 1479c76..0596ab2 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -655,7 +655,7 @@ static int mtk_iommu_init_fn(struct device_node *np)
return ret;
}
- of_iommu_set_ops(np, &mtk_iommu_ops);
+ iommu_register_instance(&np->fwnode, &mtk_iommu_ops);
return 0;
}
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 0f57ddc..d7f480a 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -127,7 +127,7 @@ static const struct iommu_ops
"iommu-map-mask", &iommu_spec.np, iommu_spec.args))
return NULL;
- ops = of_iommu_get_ops(iommu_spec.np);
+ ops = iommu_get_instance(&iommu_spec.np->fwnode);
if (!ops || !ops->of_xlate ||
iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
ops->of_xlate(&pdev->dev, &iommu_spec))
@@ -157,7 +157,7 @@ const struct iommu_ops *of_iommu_configure(struct device
*dev,
"#iommu-cells", idx,
&iommu_spec)) {
np = iommu_spec.np;
- ops = of_iommu_get_ops(np);
+ ops = iommu_get_instance(&np->fwnode);
if (!ops || !ops->of_xlate ||
iommu_fwspec_init(dev, &np->fwnode, ops) ||
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 6a7fc50..13394ac 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -31,17 +31,6 @@ static inline const struct iommu_ops
*of_iommu_configure(struct device *dev,
#endif /* CONFIG_OF_IOMMU */
-static inline void of_iommu_set_ops(struct device_node *np,
- const struct iommu_ops *ops)
-{
- iommu_register_instance(&np->fwnode, ops);
-}
-
-static inline const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
-{
- return iommu_get_instance(&np->fwnode);
-}
-
extern struct of_device_id __iommu_of_table;
typedef int (*of_iommu_init_fn)(struct device_node *);
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v2 1/5] usb: dwc2: gadget: use ep->fifo_index in context of FIFO registers
Hi, John On Thu, Feb 4, 2016 at 8:25 PM, Vahram Aharonyan wrote: > On 2/3/2016 3:40 PM, Robert Baldyga wrote: > > Hi Robert, > > DTXFSTS register is linked with endpoint, not FIFO - it contains information > about how much space is used in the FIFO assigned to the endpoint. Changing > ep->index to ep->fifo_index will work, if FIFO number assigned to that > endpoint coincides with ep->index. For example, TX FIFO #1 has been assigned > to EP 1 In. If TX FIFO #2 was assigned to EP #1, then with this change > DTXFSTS[2] will be used instead of DTXFSTS[1] for EP #1. > > Thanks, > Vahram. As mentioned by Vahram, DTXFSTS registers are indexed by endpoint number, instead of FIFO number. It should be reverted.
Re: [PATCH 00/10] vtime: Delay cputime accounting to tick / context switch
On Thu, 5 Jan 2017 18:11:40 +0100
Frederic Weisbecker wrote:
> This version is a rebase on top of latest Linus tree which includes
> the fix 8f2b468aadc ("s390/vtime: correct system time accounting").
>
> Also a small change: I have moved account_system_index_scaled() to s390
> in patch "s390/cputime: delayed accounting of system time" because it is
> the only user of the function.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> vtime/acc-v2
That looks good, I get sensible numbers for s390. Thanks for doing this!
For the s390 parts:
Acked-by: Martin Schwidefsky
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
Re: [PATCH v2] staging: wilc1000: Connect to highest RSSI value for required SSID
Thanks for the changes. regards, dan carpenter
[patch] misc: mic: double free on ioctl error path
This function only has one caller. Freeing "vdev" here leads to a use
after free bug. There are several other error paths in this function
but this is the only one which frees "vdev". It looks like the kfree()
can be safely removed.
Fixes: 61e9c905df78 ("misc: mic: Enable VOP host side functionality")
Signed-off-by: Dan Carpenter
diff --git a/drivers/misc/mic/vop/vop_vringh.c
b/drivers/misc/mic/vop/vop_vringh.c
index 88e45234d527..fed992e2c258 100644
--- a/drivers/misc/mic/vop/vop_vringh.c
+++ b/drivers/misc/mic/vop/vop_vringh.c
@@ -292,7 +292,6 @@ static int vop_virtio_add_device(struct vop_vdev *vdev,
if (ret) {
dev_err(vop_dev(vdev), "%s %d err %d\n",
__func__, __LINE__, ret);
- kfree(vdev);
return ret;
}
Re: [PATCH v3 00/11] power: supply: bq275xx: implement individual chip revision support
On Monday 09 January 2017 11:47:34 Chris Lapa wrote: > From: Chris Lapa > > This patch series separates out support for each revision chip in > the bq27500, bq27510 and bq27520 family. Each revision has enough > register address changes to justify individual register mappings. > > The series also cleans up the large overtemp if statement to > improve readability and adds devicetree documentation for all > the support bq27xxx series chips. > > I had a chance to test the deprecated bq27500/10/20 support which still > behaves the same. I also tested the new specific bq27510g3 support > on a custom board I have here and it worked correctly. > > Chris Lapa (11): > power: supplies: bq275xx: move overtemp tests to a switch statement. > power: supplies: bq275xx: rename BQ27500 allow for deprecation in > future. > power: supplies: bq275xx: adds specific support for bq27500/1 > revision. > power: supplies: bq275xx: adds specific support for bq27510-g1 > revision. > power: supplies: bq275xx: adds specific support for bq27510-g2 > revision. > power: supplies: bq275xx: adds specific support for bq27510-g3 > revision. > power: supplies: bq275xx: adds specific support for bq27520-g1 > revision. > power: supplies: bq275xx: adds specific support for bq27520-g2 > revision. > power: supplies: bq275xx: adds specific support for bq27520-g3 > revision. > power: supplies: bq275xx: adds specific support for bq27520-g4 > revision. > power: supplies: bq27xxx: adds device tree binding documentation. > > .../devicetree/bindings/power/supply/bq27xxx.txt | 36 +++ > drivers/power/supply/bq27xxx_battery.c | 348 > - > drivers/power/supply/bq27xxx_battery_i2c.c | 22 +- > include/linux/power/bq27xxx_battery.h | 10 +- > 4 files changed, 407 insertions(+), 9 deletions(-) > create mode 100644 Documentation/devicetree/bindings/power/supply/bq27xxx.txt Much better now! You can add my Acked-by. -- Pali Rohár pali.ro...@gmail.com
rcu_sched detected stalls on CPUs and server freeze for few minutes.
Hello, from few months I have a problem with my kernel or server. I read a lots of posts in internet but unable to find solution or information what trigger this error. Im using Slackware linux x86-64, kernel version: Linux database 4.4.38 #2 SMP Sun Dec 11 16:11:02 CST 2016 x86_64 Intel(R) Xeon(R) CPU E7- 4830 @ 2.13GHz GenuineIntel GNU/Linux Load of my server isnt big less then 0.50 and when server freeze nothing is working for 3-5 minute. No lan, no video, no keyboard, mouse. Nothing is working. After these few minutes everything continue normal. I read kernel documentation but did not find how to resolve the problem. I change a few kernels in last few months but no effect. Usual error is : [Tue Jan 3 14:34:48 2017] INFO: rcu_sched detected stalls on CPUs/tasks: [Tue Jan 3 14:34:48 2017] 0-...: (1 GPs behind) idle=0c3/1/0 softirq=99925959/99925960 fqs=18719 [Tue Jan 3 14:34:48 2017] (detected by 12, t=60002 jiffies, g=59107674, c=59107673, q=4826) [Tue Jan 3 14:34:48 2017] Task dump for CPU 0: [Tue Jan 3 14:34:48 2017] swapper/0 R running task0 0 0 0x0008 [Tue Jan 3 14:34:48 2017] 82403e98 0018 81b342ad 82403ee8 [Tue Jan 3 14:34:48 2017] 00062f9abbe9e97d 82558700 82404000 e8400800 [Tue Jan 3 14:34:48 2017] 824b2f40 8240 82403ee0 81b34487 [Tue Jan 3 14:34:48 2017] Call Trace: [Tue Jan 3 14:34:48 2017] [] ? cpuidle_enter_state+0x10d/0x2b0 [Tue Jan 3 14:34:48 2017] [] ? cpuidle_enter+0x17/0x20 [Tue Jan 3 14:34:48 2017] [] ? call_cpuidle+0x32/0x60 [Tue Jan 3 14:34:48 2017] [] ? cpuidle_select+0x13/0x20 [Tue Jan 3 14:34:48 2017] [] ? cpu_startup_entry+0x26f/0x310 [Tue Jan 3 14:34:48 2017] [] ? rest_init+0x77/0x80 [Tue Jan 3 14:34:48 2017] [] ? start_kernel+0x44b/0x458 [Tue Jan 3 14:34:48 2017] [] ? x86_64_start_reservations+0x2a/0x2c [Tue Jan 3 14:34:48 2017] [] ? x86_64_start_kernel+0x168/0x176 Here was a big "crash" [Wed Jan 4 10:19:12 2017] INFO: rcu_sched detected stalls on CPUs/tasks: [Wed Jan 4 10:19:12 2017] 0-...: (1 GPs behind) idle=1e1/1/0 softirq=104171004/104171004 fqs=0 [Wed Jan 4 10:19:12 2017] 5-...: (0 ticks this GP) idle=e10/0/0 softirq=27256743/27256743 fqs=0 [Wed Jan 4 10:19:12 2017] 16-...: (17661 GPs behind) idle=922/0/0 softirq=371974/371974 fqs=0 [Wed Jan 4 10:19:12 2017] 17-...: (15806 GPs behind) idle=c1c/0/0 softirq=650751/650751 fqs=0 [Wed Jan 4 10:19:12 2017] 19-...: (0 ticks this GP) idle=7a8/0/0 softirq=589498/589498 fqs=0 [Wed Jan 4 10:19:12 2017] 20-...: (15801 GPs behind) idle=bfc/0/0 softirq=598502/598502 fqs=0 [Wed Jan 4 10:19:12 2017] 21-...: (24358 GPs behind) idle=c2c/0/0 softirq=502650/502650 fqs=0 [Wed Jan 4 10:19:12 2017] 22-...: (12806 GPs behind) idle=528/0/0 softirq=452491/452491 fqs=0 [Wed Jan 4 10:19:12 2017] 23-...: (3988 GPs behind) idle=01e/0/0 softirq=516819/516819 fqs=0 [Wed Jan 4 10:19:12 2017] 24-...: (0 ticks this GP) idle=f8a/0/0 softirq=1013969/1013969 fqs=0 [Wed Jan 4 10:19:12 2017] 25-...: (0 ticks this GP) idle=a2c/0/0 softirq=965710/965710 fqs=0 [Wed Jan 4 10:19:12 2017] 26-...: (0 ticks this GP) idle=fe2/0/0 softirq=1140759/1140759 fqs=0 [Wed Jan 4 10:19:12 2017] 27-...: (0 ticks this GP) idle=950/0/0 softirq=864214/864214 fqs=0 [Wed Jan 4 10:19:12 2017] 30-...: (0 ticks this GP) idle=e8e/0/0 softirq=923356/923356 fqs=0 [Wed Jan 4 10:19:12 2017] 31-...: (0 ticks this GP) idle=82c/0/0 softirq=977601/977601 fqs=0 [Wed Jan 4 10:19:12 2017] (detected by 6, t=60002 jiffies, g=61967937, c=61967936, q=4682) [Wed Jan 4 10:19:12 2017] Task dump for CPU 0: [Wed Jan 4 10:19:12 2017] swapper/0 R running task0 0 0 0x0008 [Wed Jan 4 10:19:12 2017] 82403e98 0018 81b342ad 82403ee8 [Wed Jan 4 10:19:12 2017] 0006703c8fc4629f 82558700 82404000 e8400800 [Wed Jan 4 10:19:12 2017] 824b2f40 8240 82403ee0 81b34487 [Wed Jan 4 10:19:12 2017] Call Trace: [Wed Jan 4 10:19:12 2017] [] ? cpuidle_enter_state+0x10d/0x2b0 [Wed Jan 4 10:19:12 2017] [] ? cpuidle_enter+0x17/0x20 [Wed Jan 4 10:19:12 2017] [] ? call_cpuidle+0x32/0x60 [Wed Jan 4 10:19:12 2017] [] ? cpuidle_select+0x13/0x20 [Wed Jan 4 10:19:12 2017] [] ? cpu_startup_entry+0x26f/0x310 [Wed Jan 4 10:19:12 2017] [] ? rest_init+0x77/0x80 [Wed Jan 4 10:19:12 2017] [] ? start_kernel+0x44b/0x458 [Wed Jan 4 10:19:12 2017] [] ? x86_64_start_reservations+0x2a/0x2c [Wed Jan 4 10:19:12 2017] [] ? x86_64_start_kernel+0x168/0x176 [Wed Jan 4 10:19:12 2017] Task dump for CPU 5: [Wed Jan 4 10:19:12 2017] swapper/5 R running task0 0 1 0x0028 [Wed Jan 4 10:19:12 2017] 0006703c8fb28759 881fb261beb0 81b34290 b261b
Re: [PATCH v3 2/2] backlight arcxcnn devicetree bindings for ArcticSand
On Fri, 06 Jan 2017, Olimpiu Dejeu wrote:
> backlight: Add devicetree bindings for the Arctic Sand backlight driver
> This patch provides devicetree bindings for the Arctic Sand
> driver submitted in the previous patch
> Acked-by: Rob Herring
> Signed-off-by: Olimpiu Dejeu
> ---
>
> v2 => v3:
> - Version updated to match other patch in set. No other changes.
> v1 => v2:
> - Version updated to match other patch in set. No other changes.
>
> .../bindings/leds/backlight/arcxcnn_bl.txt | 31
> ++
> 1 file changed, 31 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> new file mode 100644
> index 000..a7b6ff2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> @@ -0,0 +1,33 @@
> +Binding for ArcticSand arc2c0608 LED driver
> +
> +Required properties:
> +- compatible: should be "arc,arc2c0608"
> +- reg: slave address
> +
> +Optional properties:
> +- default-brightness: brightness value on boot, value from: 0-4095
> +- label: The name of the backlight device
> + See Documentation/devicetree/bindings/leds/common.txt
> +- led-sources: List of enabled channels from 0 to 5.
> + See Documentation/devicetree/bindings/leds/common.txt
> +
> +- arc,led-config-0: setting for register ILED_CONFIG_0
> +- arc,led-config-1: setting for register ILED_CONFIG_1
> +- arc,dim-freq: PWM mode frequence setting (bits [3:0] used)
> +- arc,comp-config: setting for register CONFIG_COMP
> +- arc,filter-config: setting for register FILTER_CONFIG
> +- arc,trim-config: setting for register IMAXTUNE
Nit: Don't you think this is easier to read?
Required properties:
- compatible: should be "arc,arc2c0608"
- reg: slave address
Optional properties:
- default-brightness: brightness value on boot, value from: 0-4095
- label:The name of the backlight device
See Documentation/devicetree/bindings/leds/common.txt
- led-sources: List of enabled channels from 0 to 5.
See Documentation/devicetree/bindings/leds/common.txt
- arc,led-config-0: setting for register ILED_CONFIG_0
- arc,led-config-1: setting for register ILED_CONFIG_1
- arc,dim-freq: PWM mode frequence setting (bits [3:0] used)
- arc,comp-config: setting for register CONFIG_COMP
- arc,filter-config:setting for register FILTER_CONFIG
- arc,trim-config: setting for register IMAXTUNE
> +
> +Note: Optional properties not specified will default to values in IC EPROM
> +
> +Example:
> +
> +arc2c0608@30 {
> + compatible = "arc,arc2c0608";
> + reg = <0x30>;
> + default-brightness = <500>;
> + label = "lcd-backlight";
> + linux,default-trigger = "backlight";
> + led-sources = <0 1 2 5>;
> +};
> +
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64
On Fri, Jan 06, 2017 at 02:47:04PM +, Catalin Marinas wrote: > On Sun, Dec 18, 2016 at 12:38:23PM +0530, Yury Norov wrote: > > On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote: > > > This series enables aarch64 with ilp32 mode, and as supporting work, > > > introduces ARCH_32BIT_OFF_T configuration option that is enabled for > > > existing 32-bit architectures but disabled for new arches (so 64-bit > > > off_t is is used by new userspace). > > > > > > This version is based on kernel v4.9-rc1. It works with glibc-2.24, > > > and tested with LTP. > > > > Hi Arnd, Catalin > > > > For last few days I'm trying to rebase this series on current master, > > and I see significant conflicts and regressions. In fact, every time > > I rebase on next rc1, I feel like I play a roulette. > > > > This is not a significant problem now because it's almost for sure > > that this series will not get into 4.10, for reasons not related to > > kernel code. And I have time to deal with regressions. But in general, > > I'd like to try my patches on top of other candidates for next merge > > window. I cannot read all emails in LKML, but I can easily detect > > problems and join to the discussion at early stage if I see any problem. > > > > This is probably a noob question, and there are well-known branches, > > like Andrew Morton's one. But at this stage it's very important to > > have this series prepared for merge, and I'd prefer to ask about it. > > I'm not entirely sure what the question is. For development, you could > base your series on a final release, e.g. 4.9. For reviews and > especially if you are targeting a certain merging window, it's useful to > rebase your patches on a fairly recent -rc, e.g. 4.10-rc3. I would > entirely skip any non-tagged kernel states (like middle of the merging > window) or out of tree branches. There may be a case to rebase on some > other developer's branch but only if there is a dependency that can't be > avoided and usually with prior agreement from both the respective > developer (as not to rebase the branch) and the involved maintainers. Hi Catalin, 4.10-rcX is good enough but I also need to be sure that when merge window will be opened I will not find my series broken due to conflicts, because merge window is only 2 weeks, and there's no much time to investigate and fix all bugs properly. Anyway, linux-next is what I need, as Chris mentioned. Yury
Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: > On 28/12/2016 18:09, Roman Kagan wrote: > > Am I correct assuming that QEMU is currently the only user of > > arch/x86/include/uapi/asm/hyperv.h? > > > > Then I think we're fine withdrawing it from uapi as a whole and letting > > QEMU pull it in through its header-harvesting scripts (as does now > > anyway). This would lift all licensing and longterm API stability > > expectations. > > Actually, QEMU's header-harvesting scripts use uapi/ headers > exclusively, since they are built on "make headers_install". > > The extra cleanups that QEMU does on top are to allow compilation of the > headers on non-Linux machines. They don't really do much more than > changing Linux (linux/types.h) integer types to the C99 (stdint.h) > equivalents. Ouch, I stand corrected. So what should we do with it then? I'm sorta lost... We certainly can give it up and live with a private copy of the definitions in the QEMU tree but that doesn't sound optimal in any sense. Thanks, Roman.
Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree
On Fri, 06 Jan 2017, Bjorn Andersson wrote:
> On Fri 06 Jan 01:53 PST 2017, Lee Jones wrote:
>
> > On Thu, 05 Jan 2017, Bjorn Andersson wrote:
> >
> > > On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:
> > >
> > > > On Wed, 04 Jan 2017, Bjorn Andersson wrote:
> > > >
> > > > > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> > > > >
> > > > > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > > > > >
> > > > > > > From: Bjorn Andersson
> > > > > > >
> > > > > > > Implement support for initialization of the lm3533 driver core and
> > > > > > > probing child devices from Device Tree.
> > > > > > >
> > > > >
> > > > > [..]
> > > > >
> > > > > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533
> > > > > > > *lm3533)
> > > > > > > lm3533_device_bl_init(lm3533);
> > > > > > > lm3533_device_led_init(lm3533);
> > > > > > >
> > > > > > > + if (lm3533->dev->of_node) {
> > > > > > > + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > > > > + lm3533->dev);
> > > > > > > + }
> > > > > >
> > > > > > I think it's save to call of_platform_populate(), even if !of_node.
> > > > > > It will just fail and return an error code, which you are ignoring
> > > > > > anyway.
> > > > > >
> > > > >
> > > > > I thought so too, but that's apparently how you trigger probing
> > > > > children
> > > > > of the root node. So we're stuck with a conditional.
> > > >
> > > > Ah, so this is to protect against the case where DT is present, but a
> > > > node for this device is not (or is disabled), so is left unprobed.
> > > > Then the bind is initiated via I2C? Or something else?
> > > >
> > >
> > > In the event that a new lm3533 is spawned from sysfs we would not have
> > > platform_data when entering lm3533_device_init() and just bail early.
> > >
> > > Therefor, this issue would be limited to the odd case of lm3533 being
> > > initiated from code (e.g. a board file) on a DT enabled system. In which
> > > case it will create and probe new devices from the root of the DT.
> >
> > Eewww, do we really want to support that?
> >
>
> As long as we support non-DT probing of the driver this is a possible
> scenario. And with modern ARM being DT-centric I think that if anyone
> uses this driver with a modern version of the Linux kernel it's likely
> that they would have this kind of hybrid solution.
>
> So, although ugly, I think we should keep this conditional and hope that
> anyone using the driver will transition to use the DT binding.
Very well, but can you add a comment describing the reason for its
existence with a view to removing it further down the line?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[ANNOUNCE] Jailhouse 0.6 released
Busily fixing and enhancing the partitioning hypervisor Jailhouse over the last year, we basically forgot to release new versions. Here is one, and it's another major step forward towards the production-grade of this hypervisor. Key changes since the last release: - Rework and maturing of ARMv7 support - Integration of ARMv8 support with a many new boards - AMD Seattle / SoftIron Overdrive 3000 - LeMaker HiKey - NVIDIA Jetson TX1 - Xilinx ZCU102 (ZynqMP evaluation board) - Support for booting multiple Linux instances, UP or SMP, on all supported architectures - Enhanced inter-cell communication, including support for using a virtual network protocol driver on top, also on all architectures - Many improvements on x86 - AMD IOMMU support (interrupt remapping will come soon) - Intel Cache Allocation Technology (L3, support for L2 will follow) - Support for recent Intel CPUs, including Apollo Lake SOCs - Support for sub-page MMIO regions (who still designs hardware with unaligned resources?) The statistics over v0.5..v0.6 also look fairly nice: - 744 commits (330 files changed, 20700 insertions, 9266 deletions) - 26 contributors - at least 12 different contributing organizations (companies, universities) Special thanks go to Huawei, who did a great job in enabling Jailhouse on ARMv8, and to the OTH Regensburg, who is currently sending us the most active non-Siemens contributor, Ralf Ramsauer, and also makes sure that Jailhouse will literally fly (more at ELC and the Embedded World conference). You can download the new release from https://github.com/siemens/jailhouse/archive/v0.6.tar.gz then follow the README.md for first steps on recommended evaluation platforms and check the tutorial session from last ELC-E [1][2]. Drop us a note on the mailing list if you run into trouble. Jailhouse continues to improve on usability, but dealing with real hardware bears the risk that something requires fine-tuning and deeper understanding. What comes next? Of course, that also depends on further contributions. But we do have a number of hot topics on the to-do list: - Further rework of the inter-cell communication device, either towards some "ivshmem 2.0" that will be used by others as well (specifically QEMU) or defined as a Jailhouse-proprietary solution. Discussions to be started soon. - Improve code documentation, not only to support the ongoing safety certification efforts, but it plays an important role there. - On-device test automation: with about 10 targets now and likely more in the future, it became fairly unhandy to test manually... Last but not least, we should do better with regular releasing. The plan is now to establish a 3-months cadence. So the next release will be in early April. Feel free to remind us if we should forget that again. Jan [1] https://events.linuxfoundation.org/sites/events/files/slides/ELCE2016-Jailhouse-Tutorial.pdf [2] https://youtu.be/7fiJbwmhnRw?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
On January 9, 2017 12:32:23 AM PST, Roman Kagan wrote: >On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: >> On 28/12/2016 18:09, Roman Kagan wrote: >> > Am I correct assuming that QEMU is currently the only user of >> > arch/x86/include/uapi/asm/hyperv.h? >> > >> > Then I think we're fine withdrawing it from uapi as a whole and >letting >> > QEMU pull it in through its header-harvesting scripts (as does now >> > anyway). This would lift all licensing and longterm API stability >> > expectations. >> >> Actually, QEMU's header-harvesting scripts use uapi/ headers >> exclusively, since they are built on "make headers_install". >> >> The extra cleanups that QEMU does on top are to allow compilation of >the >> headers on non-Linux machines. They don't really do much more than >> changing Linux (linux/types.h) integer types to the C99 (stdint.h) >> equivalents. > >Ouch, I stand corrected. > >So what should we do with it then? I'm sorta lost... > >We certainly can give it up and live with a private copy of the >definitions in the QEMU tree but that doesn't sound optimal in any >sense. > >Thanks, >Roman. Why do that through header mangling rather than typedef? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [f2fs-dev] [PATCH 3/5] f2fs: check in-memory block bitmap
Hi Jaegeuk,
On 2017/1/8 13:02, Jaegeuk Kim wrote:
>> @@ -2786,6 +2811,7 @@ static void destroy_sit_info(struct f2fs_sb_info *sbi)
>> if (sit_i->sentries) {
>> for (start = 0; start < MAIN_SEGS(sbi); start++) {
>> kfree(sit_i->sentries[start].cur_valid_map);
>
> I added:
>
> #ifdef CONFIG_F2FS_CHECK_FS
Oops, thanks for fixing it. :)
Thanks,
>
>> +kfree(sit_i->sentries[start].cur_valid_map_mir);
>
> #endif
>
> Thanks,
>
> .
>
Re: [PATCH v1 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family
On Mon, Jan 09, 2017 at 11:00:38AM +0800, Jun Nie wrote:
> >+static int zx2967_thermal_resume(struct device *dev)
> >+{
> >+struct platform_device *pdev = to_platform_device(dev);
> >+struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
> >+int error;
> >+
> >+error = clk_prepare_enable(priv->clk_gate);
> >+if (error)
> Use IS_ERR(ret) to check error.
No. IS_ERR() checks on pointer, while clk_prepare_enable() returns
integer.
Shawn
> >+return error;
> >+
> >+error = clk_prepare_enable(priv->pclk);
> >+if (error)
> Ditto.
> >+return error;
> >+
> >+dev_info(dev, "resumed\n");
> >+
> >+return 0;
> >+}
[PATCH v4 2/2] ARM: sama5_defconfig: add support for the Axentia TSE-850 board
Signed-off-by: Peter Rosin --- arch/arm/configs/sama5_defconfig | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig index aca8625b6fc9..bf5b3a73e38c 100644 --- a/arch/arm/configs/sama5_defconfig +++ b/arch/arm/configs/sama5_defconfig @@ -131,7 +131,7 @@ CONFIG_GPIO_SYSFS=y CONFIG_POWER_SUPPLY=y CONFIG_BATTERY_ACT8945A=y CONFIG_POWER_RESET=y -# CONFIG_HWMON is not set +CONFIG_SENSORS_JC42=y CONFIG_WATCHDOG=y CONFIG_AT91SAM9X_WATCHDOG=y CONFIG_SAMA5D4_WATCHDOG=y @@ -142,6 +142,7 @@ CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_ACT8865=y CONFIG_REGULATOR_ACT8945A=y +CONFIG_REGULATOR_PWM=y CONFIG_MEDIA_SUPPORT=y CONFIG_MEDIA_CAMERA_SUPPORT=y CONFIG_V4L_PLATFORM_DRIVERS=y @@ -164,6 +165,7 @@ CONFIG_SND_ATMEL_SOC=y CONFIG_SND_ATMEL_SOC_WM8904=y # CONFIG_HID_GENERIC is not set CONFIG_SND_ATMEL_SOC_PDMIC=y +CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_EHCI_HCD=y @@ -199,6 +201,9 @@ CONFIG_AT_XDMAC=y CONFIG_IIO=y CONFIG_AT91_ADC=y CONFIG_AT91_SAMA5D2_ADC=y +CONFIG_ENVELOPE_DETECTOR=y +CONFIG_DPOT_DAC=y +CONFIG_MCP4531=y CONFIG_PWM=y CONFIG_PWM_ATMEL=y CONFIG_PWM_ATMEL_HLCDC_PWM=y -- 2.1.4
[PATCH v4 0/2] Support for Axentia TSE-850
Hi! changes v3 -> v4 - rename files arch/arm/boot/dts/axentia-* to .../at91-* - remove bootargs from at91-tse850-3.dts - depend on the atmel ssc to register as a sound dai by itself - bump copyright years changes v2 -> v3 - document the new compatible strings prefixed with "axentia,". changes v1 -> v2 - squash the fixup into the correct patch, sorry for the noise. After finally having all essintial drivers upstreamed I would like to have the dts and the defconfig also upstreamed. The atmel-ssc/sound-dai change depends on a change that has been sitting in the ASoC tree since mid-december, and I have been waiting for it to hit linux-next before sending this, but it seems to take longer than I anticipated. So, since I do not want this to in turn miss the next merge window because of that wait I therefore request that this is taken now even though it doesn't really work w/o the ASoC "topic/atmel" branch as of 2016-12-15 [1]. It of course builds cleanly even w/o those ASoC changes. That effectively means that noone besides me should notice the inconsistency (I currently have all affected devices under my control). Cheers, peda [1] http://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/atmel Peter Rosin (2): ARM: dts: at91: add devicetree for the Axentia TSE-850 ARM: sama5_defconfig: add support for the Axentia TSE-850 board Documentation/devicetree/bindings/arm/axentia.txt | 19 ++ MAINTAINERS | 8 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/at91-linea.dtsi | 53 + arch/arm/boot/dts/at91-tse850-3.dts | 274 ++ arch/arm/configs/sama5_defconfig | 7 +- 6 files changed, 361 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt create mode 100644 arch/arm/boot/dts/at91-linea.dtsi create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts -- 2.1.4
[PATCH v4 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/at91-linea.dtsi | 53 +
arch/arm/boot/dts/at91-tse850-3.dts | 274 ++
5 files changed, 355 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
diff --git a/Documentation/devicetree/bindings/arm/axentia.txt
b/Documentation/devicetree/bindings/arm/axentia.txt
new file mode 100644
index ..ea3fb96ae465
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axentia.txt
@@ -0,0 +1,19 @@
+Device tree bindings for Axentia ARM devices
+
+
+Linea CPU module
+
+
+Required root node properties:
+compatible = "axentia,linea",
+"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from atmel-at91.txt for a sama5d31 SoC.
+
+
+TSE-850 v3 board
+
+
+Required root node properties:
+compatible = "axentia,tse850v3", "axentia,linea",
+"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from above for the axentia,linea CPU module.
diff --git a/MAINTAINERS b/MAINTAINERS
index 97b78cc5aa51..5c2ea6e9cd7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2346,6 +2346,14 @@ S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXENTIA ARM DEVICES
+M: Peter Rosin
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/arm/axentia.txt
+F: arch/arm/boot/dts/at91-linea.dtsi
+F: arch/arm/boot/dts/at91-tse850-3.dts
+
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab
M: Mauro Carvalho Chehab
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9a7375c388a8..7632849866de 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ at91-tse850-3.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
sama5d34ek.dtb \
diff --git a/arch/arm/boot/dts/at91-linea.dtsi
b/arch/arm/boot/dts/at91-linea.dtsi
new file mode 100644
index ..20d982153a45
--- /dev/null
+++ b/arch/arm/boot/dts/at91-linea.dtsi
@@ -0,0 +1,53 @@
+/*
+ * at91-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ compatible = "axentia,linea",
+"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ memory {
+ reg = <0x2000 0x2000>;
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <1200>;
+};
+
+&main {
+ clock-frequency = <1200>;
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom@51 {
+ compatible = "st,24c64";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+};
+
+&nand0 {
+ status = "okay";
+
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+};
diff --git a/arch/arm/boot/dts/at91-tse850-3.dts
b/arch/arm/boot/dts/at91-tse850-3.dts
new file mode 100644
index ..669a2c6bdefc
--- /dev/null
+++ b/arch/arm/boot/dts/at91-tse850-3.dts
@@ -0,0 +1,274 @@
+/*
+ * at91-tse850-3.dts - Device Tree file for the Axentia TSE-850 3.0 board
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include
+#include "at91-linea.dtsi"
+
+/ {
+ model = "Axentia TSE-850 3.0";
+ compatible = "axentia,tse850v3", "axentia,linea",
+"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ pinctrl@f200 {
+ tse850 {
+ pinctrl_usba_vbus: usba-vbus {
+ atmel,pins =
+ ;
+ };
+ };
+ };
+
+ watchdog@fe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ sck: oscillator {
+ compatible = "fixed-clock";
+
+ #clock-cells = <0>;
+
Re: [PATCH] mm: support __GFP_REPEAT in kvmalloc_node
On Fri 06-01-17 13:09:36, Vlastimil Babka wrote:
> On 01/04/2017 07:12 PM, Michal Hocko wrote:
> > While checking opencoded users I've encountered that vhost code would
> > really like to use kvmalloc with __GFP_REPEAT [1] so the following patch
> > adds support for __GFP_REPEAT and converts both vhost users.
> >
> > So currently I am sitting on 3 patches. I will wait for more feedback -
> > especially about potential split ups or cleanups few more days and then
> > repost the whole series.
> >
> > [1] http://lkml.kernel.org/r/20170104150800.go25...@dhcp22.suse.cz
> > ---
> > From 0b92e4d2e040524b878d4e7b9ee88fbad5284b33 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko
> > Date: Wed, 4 Jan 2017 18:01:39 +0100
> > Subject: [PATCH] mm: support __GFP_REPEAT in kvmalloc_node
> >
> > vhost code uses __GFP_REPEAT when allocating vhost_virtqueue resp.
> > vhost_vsock because it would really like to prefer kmalloc to the
> > vmalloc fallback - see 23cc5a991c7a ("vhost-net: extend device
> > allocation to vmalloc") for more context. Michael Tsirkin has also
> > noted:
> > "
> > __GFP_REPEAT overhead is during allocation time. Using vmalloc means all
> > accesses are slowed down. Allocation is not on data path, accesses are.
> > "
> >
> > Let's teach kvmalloc_node to handle __GFP_REPEAT properly. There are two
> > things to be careful about. First we should prevent from the OOM killer
> > and so have to involve __GFP_NORETRY by default and secondly override
> > __GFP_REPEAT for !costly order requests as the __GFP_REPEAT is ignored
> > for !costly orders.
> >
> > This patch shouldn't introduce any functional change.
>
> Which is because the converted usages are always used for costly order,
> right.
I have overlooked this remark previously. You are right. And I've
updated the documentation and also the inline comment to be more
explicit about this. We do not have a good way to support __GFP_REPEAT
for !costly orders currently unfortunatelly. Maybe I should revive my
__GFP_RETRY_MAYFAIL patch, this would be another user (outside of xfs
which already wants something like that for KM_MAYFAIL.
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/4] ARM: dts: move hdmi pinctrl out of board file.
On 01/04/2017 07:04 PM, Srinivas Kandagatla wrote:
This patch moves hdmi pinctrl defination from board file to soc level
pinctrl file. If not this pinctrl setup will be duplicated across all
the apq8064 based board files.
Reviewed-by: Archit Taneja
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 22 --
arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 19 +++
arch/arm/boot/dts/qcom-apq8064.dtsi| 2 ++
3 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 3d37cab..881ce70 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -75,25 +75,6 @@
bias-disable;
};
};
-
- hdmi_pinctrl: hdmi-pinctrl {
- mux {
- pins = "gpio70", "gpio71", "gpio72";
- function = "hdmi";
- };
-
- pinconf_ddc {
- pins = "gpio70", "gpio71";
- bias-pull-up;
- drive-strength = <2>;
- };
-
- pinconf_hpd {
- pins = "gpio72";
- bias-pull-down;
- drive-strength = <16>;
- };
- };
};
rpm@108000 {
@@ -368,9 +349,6 @@
hpd-gpios = <&tlmm_pinmux 72 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&hdmi_pinctrl>;
-
ports {
port@0 {
endpoint {
diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
index 6b801e7..cba4450 100644
--- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -284,4 +284,23 @@
bias-disable = <0>;
};
};
+
+ hdmi_pinctrl: hdmi-pinctrl {
+ mux {
+ pins = "gpio70", "gpio71", "gpio72";
+ function = "hdmi";
+ };
+
+ pinconf_ddc {
+ pins = "gpio70", "gpio71";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+
+ pinconf_hpd {
+ pins = "gpio72";
+ bias-pull-down;
+ drive-strength = <16>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 407a461..e68a8a1 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -1327,6 +1327,8 @@
hdmi: hdmi-tx@4a0 {
compatible = "qcom,hdmi-tx-8960";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pinctrl>;
reg = <0x04a0 0x2f0>;
reg-names = "core_physical";
interrupts = ;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 2/4] ARM: dts: sd-600eval: add hdmi support
On 01/04/2017 07:04 PM, Srinivas Kandagatla wrote:
Signed-off-by: Srinivas Kandagatla
Reviewed-by: Archit Taneja
---
.../arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts | 44 ++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
index 39ae2bc..4e908af 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-sd-600eval.dts
@@ -39,6 +39,17 @@
};
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+ };
+
soc {
rpm@108000 {
regulators {
@@ -347,5 +358,38 @@
cd-gpios= <&tlmm_pinmux 26
GPIO_ACTIVE_HIGH>;
};
};
+
+ hdmi-tx@4a0 {
+ status = "okay";
+ core-vdda-supply = <&pm8921_hdmi_switch>;
+ hdmi-mux-supply = <&vcc3v3>;
+
+ hpd-gpio = <&tlmm_pinmux 72 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+
+ hdmi-phy@4a00400 {
+ status = "okay";
+ core-vdda-supply = <&pm8921_hdmi_switch>;
+ };
+
+ mdp@510 {
+ status = "okay";
+
+ ports {
+ port@3 {
+ endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
+ };
};
};
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 2/6] arm64: dts: apq8016-sbc: add support to hdmi audio via adv7533
On 01/04/2017 07:04 PM, Srinivas Kandagatla wrote:
This patch adds support to hdmi audio via adv7533.
Tested-by: Archit Taneja
Signed-off-by: Srinivas Kandagatla
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 08bd5eb..5ab277f 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -85,6 +85,7 @@
pinctrl-names = "default","sleep";
pinctrl-0 = <&adv7533_int_active
&adv7533_switch_active>;
pinctrl-1 = <&adv7533_int_suspend
&adv7533_switch_suspend>;
+ #sound-dai-cells = <1>;
ports {
#address-cells = <1>;
@@ -285,6 +286,15 @@
qcom,audio-routing =
"AMIC2", "MIC BIAS Internal2",
"AMIC3", "MIC BIAS External1";
+ external-dai-link@0 {
+ link-name = "ADV7533";
+ cpu { /* QUAT */
+ sound-dai = <&lpass MI2S_QUATERNARY>;
+ };
+ codec {
+ sound-dai = <&adv_bridge 0>;
+ };
+ };
internal-codec-playback-dai-link@0 {/* I2S
- Internal codec */
link-name = "WCD";
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: Uninitialized variable in bfad_im_bsg_els_ct_request
On Sun, Dec 18, 2016 at 09:44:27PM +0100, Nicolas Iooss wrote:
> Hello,
>
> Currently on Linus master tree and in linux-next [1],
> bfad_im_bsg_els_ct_request() code starts with the following code:
>
> int
> bfad_im_bsg_els_ct_request(struct bsg_job *job)
> {
> /*...*/
> struct fc_bsg_request *bsg_request = bsg_request;
> struct fc_bsg_reply *bsg_reply = job->reply;
> uint32_t command_type = bsg_request->msgcode;
>
> The local variable "bsg_request" is initialized to itself (which would
> usually mean it is uninitialized) but it is dereferenced in order to get
> its "msgcode" field. As I am quite new to the kernel code and
> dereferencing self-initialized local variables looks black magic to me,
> could you please describe why this code is valid?
>
> It has recently been introduced by commit 01e0e15c8b3b ("scsi: don't use
> fc_bsg_job::request and fc_bsg_job::reply directly").
>
> Thanks,
> Nicolas Iooss
>
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/scsi/bfa/bfad_bsg.c?id=06548160dfecd1983ffd9d6795242a5cda095da5#n3356
Yes this is wrong. bsg_request should point to job->request:
diff --git a/drivers/scsi/bfa/bfad_bsg.c b/drivers/scsi/bfa/bfad_bsg.c
index a9a0016..b2e8c0d 100644
--- a/drivers/scsi/bfa/bfad_bsg.c
+++ b/drivers/scsi/bfa/bfad_bsg.c
@@ -3363,7 +3363,7 @@ struct bfad_buf_info *
struct bfad_fcxp*drv_fcxp;
struct bfa_fcs_lport_s *fcs_port;
struct bfa_fcs_rport_s *fcs_rport;
- struct fc_bsg_request *bsg_request = bsg_request;
+ struct fc_bsg_request *bsg_request = job->request;
struct fc_bsg_reply *bsg_reply = job->reply;
uint32_t command_type = bsg_request->msgcode;
unsigned long flags;
I'll send out an official patch soon, thanks for the report.
Johannes
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
On Mon, Jan 09, 2017 at 12:40:48AM -0800, h...@zytor.com wrote: > On January 9, 2017 12:32:23 AM PST, Roman Kagan wrote: > >On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: > >> On 28/12/2016 18:09, Roman Kagan wrote: > >> > Am I correct assuming that QEMU is currently the only user of > >> > arch/x86/include/uapi/asm/hyperv.h? > >> > > >> > Then I think we're fine withdrawing it from uapi as a whole and > >letting > >> > QEMU pull it in through its header-harvesting scripts (as does now > >> > anyway). This would lift all licensing and longterm API stability > >> > expectations. > >> > >> Actually, QEMU's header-harvesting scripts use uapi/ headers > >> exclusively, since they are built on "make headers_install". > >> > >> The extra cleanups that QEMU does on top are to allow compilation of > >the > >> headers on non-Linux machines. They don't really do much more than > >> changing Linux (linux/types.h) integer types to the C99 (stdint.h) > >> equivalents. > > > >Ouch, I stand corrected. > > > >So what should we do with it then? I'm sorta lost... > > > >We certainly can give it up and live with a private copy of the > >definitions in the QEMU tree but that doesn't sound optimal in any > >sense. > > > >Thanks, > >Roman. > > Why do that through header mangling rather than typedef? Sorry for not being clear, I actually asked what to do with the Hyper-V and VMBus protocol definitions. The typedef vs mangling is a different matter; I guess mangling was chosen to avoid conflicts with system-provided definitions on non-Linux systems, but I think Paolo can tell more. Roman.
Re: [PATCH v1] irqchip: irq-mips-gic:- Handle return NULL error from ioremap_nocache
On 09/01/17 08:08, Arvind Yadav wrote:
> Here, If ioremap_nocache will fail. It will return NULL.
> Kernel can run into a NULL-pointer dereference.
> This error check will avoid NULL pointer dereference.
>
> Signed-off-by: Arvind Yadav
> ---
> drivers/irqchip/irq-mips-gic.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
> index c01c09e..eeea2e8 100644
> --- a/drivers/irqchip/irq-mips-gic.c
> +++ b/drivers/irqchip/irq-mips-gic.c
> @@ -979,6 +979,8 @@ static void __init __gic_init(unsigned long gic_base_addr,
> __gic_base_addr = gic_base_addr;
>
> gic_base = ioremap_nocache(gic_base_addr, gic_addrspace_size);
> + if (!gic_base)
> + panic("Failed to map GIC memory");
So you're replacing a panic due to dereferencing a NULL pointer with
another panic -- not much progress here. I appreciate that the message
is a bit more explicit, but is there something slightly less drastic we
could do? Like returning an error code and see if the kernel otherwise
recovers (possibly with reduced functionality)?
>
> gicconfig = gic_read(GIC_REG(SHARED, GIC_SH_CONFIG));
> gic_shared_intrs = (gicconfig & GIC_SH_CONFIG_NUMINTRS_MSK) >>
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
On 09/01/2017 09:40, h...@zytor.com wrote: > On January 9, 2017 12:32:23 AM PST, Roman Kagan wrote: >> On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: >>> On 28/12/2016 18:09, Roman Kagan wrote: Am I correct assuming that QEMU is currently the only user of arch/x86/include/uapi/asm/hyperv.h? Then I think we're fine withdrawing it from uapi as a whole and >> letting QEMU pull it in through its header-harvesting scripts (as does now anyway). This would lift all licensing and longterm API stability expectations. >>> >>> Actually, QEMU's header-harvesting scripts use uapi/ headers >>> exclusively, since they are built on "make headers_install". >>> >>> The extra cleanups that QEMU does on top are to allow compilation of >> the >>> headers on non-Linux machines. They don't really do much more than >>> changing Linux (linux/types.h) integer types to the C99 (stdint.h) >>> equivalents. >> >> Ouch, I stand corrected. >> >> So what should we do with it then? I'm sorta lost... >> >> We certainly can give it up and live with a private copy of the >> definitions in the QEMU tree but that doesn't sound optimal in any >> sense. > > Why do that through header mangling rather than typedef? Because you are not suppose to typedef identifiers that start with "__", and because it does do a few other ad-hoc changes: -e 's/]*\)>/"standard-headers\/linux\/\1"/' \ -e 's/__bitwise__//' \ -e 's/__attribute__((packed))/QEMU_PACKED/' \ -e 's/__inline__/inline/' \ -e '/sys\/ioctl.h/d' \ -e 's/SW_MAX/SW_MAX_/' \ Paolo
Re: [PATCH v11 0/5] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing
On Tue, 3 Jan 2017, Pavel Machek wrote: > On Tue 2016-12-20 14:48:41, Grzegorz Andrejczuk wrote: > > Following patches enable the use of the feature that allows > > the Intel Xeon Phi x200 devices to use MONITOR/MWAIT instructions > > outside ring 0. It allows userspace applications to use > > more efficient synchronization operations, which improves performance > > and energy efficiency. > > What kind of security holes does it bring us? > > rdseed can be used for two processes to communicate when they should > not (serious problem for android). Can this be used for something similar? No. The monitor address must be in the virtual address space of the caller, so it's like any other 'read' operation. Thanks, tglx
Re: [PATCH v3 1/5] drm/dp: add connector backpointer to drm_dp_aux
On 6 January 2017 at 16:56, Sean Paul wrote:
> On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso
> wrote:
>> This backpointer allows DP helpers to access the connector it's being
>> used for.
>>
>> Signed-off-by: Tomeu Vizoso
>> ---
>>
>> include/drm/drm_dp_helper.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index 55bbeb0ff594..4fa77b434594 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -721,6 +721,7 @@ struct drm_dp_aux_msg {
>> * @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
>> * @ddc: I2C adapter that can be used for I2C-over-AUX communication
>> * @dev: pointer to struct device that is the parent for this AUX channel
>> + * @connector: backpointer to connector that uses this AUX channel
>> * @hw_mutex: internal mutex used for locking transfers
>> * @transfer: transfers a message representing a single AUX transaction
>> *
>> @@ -757,6 +758,7 @@ struct drm_dp_aux {
>> const char *name;
>> struct i2c_adapter ddc;
>> struct device *dev;
>> + struct drm_connector *connector;
>
> Perhaps I'm misreading the series, but it seems like you could instead
> add int crc_pipe along with the other crc fields. Then when you start
> the crc, set the pipe number. If you have the pipe in the crc worker,
> you can wait vblank on that pipe (no pointers needed).
>
> Reasonable?
I think that would work fine, but is it any better? I like that the
connector isn't going to change during the lifetime of the drm_dp_aux,
but crc_pipe could be changing between sampling sessions and any bugs
in keeping that field updated would be quite disconcerting and
cumbersome to debug.
crc_pipe's advantage is that we wouldn't need to update all callers of
drm_dp_aux_register, but I think it's better to have a connector field
that is mistakenly NULL, than a crc_pipe field with the wrong value.
Regards,
Tomeu
> Sean
>
>> struct mutex hw_mutex;
>> ssize_t (*transfer)(struct drm_dp_aux *aux,
>> struct drm_dp_aux_msg *msg);
>> --
>> 2.9.3
>>
>
>
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
[PATCH v2 0/3] STM32F4 Clock binding fix & update
From: Gabriel Fernandez v2: - Only rename commit subject of first patch to avoid the error: Remote Server returned '
[PATCH v2 2/3] dt-bindings: mfd: stm32f4: Add missing binding definition
From: Gabriel Fernandez This patch adds missing binding definition (backupram, ethernet, otg, qspi, adc & dsi) Signed-off-by: Gabriel Fernandez --- include/dt-bindings/mfd/stm32f4-rcc.h | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h index f662b19..082a81c 100644 --- a/include/dt-bindings/mfd/stm32f4-rcc.h +++ b/include/dt-bindings/mfd/stm32f4-rcc.h @@ -18,11 +18,17 @@ #define STM32F4_RCC_AHB1_GPIOJ 9 #define STM32F4_RCC_AHB1_GPIOK 10 #define STM32F4_RCC_AHB1_CRC 12 +#define STM32F4_RCC_AHB1_BKPSRAM 18 +#define STM32F4_RCC_AHB1_CCMDATARAM20 #define STM32F4_RCC_AHB1_DMA1 21 #define STM32F4_RCC_AHB1_DMA2 22 #define STM32F4_RCC_AHB1_DMA2D 23 #define STM32F4_RCC_AHB1_ETHMAC25 -#define STM32F4_RCC_AHB1_OTGHS 29 +#define STM32F4_RCC_AHB1_ETHMACTX 26 +#define STM32F4_RCC_AHB1_ETHMACRX 27 +#define STM32F4_RCC_AHB1_ETHMACPTP 28 +#define STM32F4_RCC_AHB1_OTGHS 29 +#define STM32F4_RCC_AHB1_OTGHSULPI 30 #define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8)) #define STM32F4_AHB1_CLOCK(bit) (STM32F4_RCC_AHB1_##bit) @@ -40,6 +46,7 @@ /* AHB3 */ #define STM32F4_RCC_AHB3_FMC 0 +#define STM32F4_RCC_AHB3_QSPI 1 #define STM32F4_AHB3_RESET(bit)(STM32F4_RCC_AHB3_##bit + (0x18 * 8)) #define STM32F4_AHB3_CLOCK(bit)(STM32F4_RCC_AHB3_##bit + 0x40) @@ -79,7 +86,9 @@ #define STM32F4_RCC_APB2_TIM8 1 #define STM32F4_RCC_APB2_USART14 #define STM32F4_RCC_APB2_USART65 -#define STM32F4_RCC_APB2_ADC 8 +#define STM32F4_RCC_APB2_ADC1 8 +#define STM32F4_RCC_APB2_ADC2 9 +#define STM32F4_RCC_APB2_ADC3 10 #define STM32F4_RCC_APB2_SDIO 11 #define STM32F4_RCC_APB2_SPI1 12 #define STM32F4_RCC_APB2_SPI4 13 @@ -91,6 +100,7 @@ #define STM32F4_RCC_APB2_SPI6 21 #define STM32F4_RCC_APB2_SAI1 22 #define STM32F4_RCC_APB2_LTDC 26 +#define STM32F4_RCC_APB2_DSI 27 #define STM32F4_APB2_RESET(bit)(STM32F4_RCC_APB2_##bit + (0x24 * 8)) #define STM32F4_APB2_CLOCK(bit)(STM32F4_RCC_APB2_##bit + 0xA0) -- 1.9.1
[PATCH v2 3/3] ARM: dts: stm32: Use clock DT binding definition on stm32f429 family
From: Gabriel Fernandez
This patch uses clock DT binding definition instead numerical values
for stm32f429 board.
Signed-off-by: Gabriel Fernandez
---
arch/arm/boot/dts/stm32429i-eval.dts | 2 +-
arch/arm/boot/dts/stm32f429.dtsi | 66 +++-
2 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 76f7206..4e31881 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -107,7 +107,7 @@
usbotg_hs_phy: usbphy {
#phy-cells = <0>;
compatible = "usb-nop-xceiv";
- clocks = <&rcc 0 30>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(OTGHSULPI)>;
clock-names = "main_clk";
};
};
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 041e3fc..1bacdfb 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -49,6 +49,7 @@
#include "armv7-m.dtsi"
#include
#include
+#include
/ {
clocks {
@@ -82,7 +83,7 @@
compatible = "st,stm32-timer";
reg = <0x4000 0x400>;
interrupts = <28>;
- clocks = <&rcc 0 128>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM2)>;
status = "disabled";
};
@@ -90,7 +91,7 @@
compatible = "st,stm32-timer";
reg = <0x4400 0x400>;
interrupts = <29>;
- clocks = <&rcc 0 129>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM3)>;
status = "disabled";
};
@@ -98,7 +99,7 @@
compatible = "st,stm32-timer";
reg = <0x4800 0x400>;
interrupts = <30>;
- clocks = <&rcc 0 130>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM4)>;
status = "disabled";
};
@@ -106,14 +107,14 @@
compatible = "st,stm32-timer";
reg = <0x4c00 0x400>;
interrupts = <50>;
- clocks = <&rcc 0 131>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM5)>;
};
timer6: timer@40001000 {
compatible = "st,stm32-timer";
reg = <0x40001000 0x400>;
interrupts = <54>;
- clocks = <&rcc 0 132>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM6)>;
status = "disabled";
};
@@ -121,7 +122,7 @@
compatible = "st,stm32-timer";
reg = <0x40001400 0x400>;
interrupts = <55>;
- clocks = <&rcc 0 133>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM7)>;
status = "disabled";
};
@@ -129,7 +130,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004400 0x400>;
interrupts = <38>;
- clocks = <&rcc 0 145>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART2)>;
status = "disabled";
};
@@ -137,7 +138,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004800 0x400>;
interrupts = <39>;
- clocks = <&rcc 0 146>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART3)>;
status = "disabled";
dmas = <&dma1 1 4 0x400 0x0>,
<&dma1 3 4 0x400 0x0>;
@@ -148,7 +149,7 @@
compatible = "st,stm32-uart";
reg = <0x40004c00 0x400>;
interrupts = <52>;
- clocks = <&rcc 0 147>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART4)>;
status = "disabled";
};
@@ -156,7 +157,7 @@
compatible = "st,stm32-uart";
reg = <0x40005000 0x400>;
interrupts = <53>;
- clocks = <&rcc 0 148>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART5)>;
status = "disabled";
};
@@ -164,7 +165,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40007800 0x400>;
interrupts = <82>;
- clocks = <&rcc 0 158>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(
[PATCH v2 1/3] dt-bindings: mfd: stm32f4: Fix STM32F4_X_CLOCK() macro
From: Gabriel Fernandez Macro to select a clock was not correct. Offset of enable register starts at 0x30, then calculation to select a bit is: (@enable_reg - 0x30) / 4 * 32 + bit_to_select Signed-off-by: Gabriel Fernandez Tested-by: M'boumba Cedric Madianga --- include/dt-bindings/mfd/stm32f4-rcc.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h index e98942d..f662b19 100644 --- a/include/dt-bindings/mfd/stm32f4-rcc.h +++ b/include/dt-bindings/mfd/stm32f4-rcc.h @@ -25,7 +25,7 @@ #define STM32F4_RCC_AHB1_OTGHS 29 #define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8)) -#define STM32F4_AHB1_CLOCK(bit) (STM32F4_RCC_AHB1_##bit + (0x30 * 8)) +#define STM32F4_AHB1_CLOCK(bit) (STM32F4_RCC_AHB1_##bit) /* AHB2 */ @@ -36,13 +36,13 @@ #define STM32F4_RCC_AHB2_OTGFS 7 #define STM32F4_AHB2_RESET(bit)(STM32F4_RCC_AHB2_##bit + (0x14 * 8)) -#define STM32F4_AHB2_CLOCK(bit)(STM32F4_RCC_AHB2_##bit + (0x34 * 8)) +#define STM32F4_AHB2_CLOCK(bit)(STM32F4_RCC_AHB2_##bit + 0x20) /* AHB3 */ #define STM32F4_RCC_AHB3_FMC 0 #define STM32F4_AHB3_RESET(bit)(STM32F4_RCC_AHB3_##bit + (0x18 * 8)) -#define STM32F4_AHB3_CLOCK(bit)(STM32F4_RCC_AHB3_##bit + (0x38 * 8)) +#define STM32F4_AHB3_CLOCK(bit)(STM32F4_RCC_AHB3_##bit + 0x40) /* APB1 */ #define STM32F4_RCC_APB1_TIM2 0 @@ -72,7 +72,7 @@ #define STM32F4_RCC_APB1_UART8 31 #define STM32F4_APB1_RESET(bit)(STM32F4_RCC_APB1_##bit + (0x20 * 8)) -#define STM32F4_APB1_CLOCK(bit)(STM32F4_RCC_APB1_##bit + (0x40 * 8)) +#define STM32F4_APB1_CLOCK(bit)(STM32F4_RCC_APB1_##bit + 0x80) /* APB2 */ #define STM32F4_RCC_APB2_TIM1 0 @@ -93,6 +93,6 @@ #define STM32F4_RCC_APB2_LTDC 26 #define STM32F4_APB2_RESET(bit)(STM32F4_RCC_APB2_##bit + (0x24 * 8)) -#define STM32F4_APB2_CLOCK(bit)(STM32F4_RCC_APB2_##bit + (0x44 * 8)) +#define STM32F4_APB2_CLOCK(bit)(STM32F4_RCC_APB2_##bit + 0xA0) #endif /* _DT_BINDINGS_MFD_STM32F4_RCC_H */ -- 1.9.1
Re: [PATCH v11 0/5] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing
On Mon 2017-01-09 09:59:42, Thomas Gleixner wrote: > On Tue, 3 Jan 2017, Pavel Machek wrote: > > > On Tue 2016-12-20 14:48:41, Grzegorz Andrejczuk wrote: > > > Following patches enable the use of the feature that allows > > > the Intel Xeon Phi x200 devices to use MONITOR/MWAIT instructions > > > outside ring 0. It allows userspace applications to use > > > more efficient synchronization operations, which improves performance > > > and energy efficiency. > > > > What kind of security holes does it bring us? > > > > rdseed can be used for two processes to communicate when they should > > not (serious problem for android). Can this be used for something similar? > > No. The monitor address must be in the virtual address space of the > caller, so it's like any other 'read' operation. Hmm. Unlike any other 'read' operation, it allows userland to modulate CPU frequency with great precision; probably allowing userland to transmit at radio bands, and allowing sound production without syscalls (singing capacitors). But userland can probably do that already, with help of high-resolution timers, so nothing new theree... that I can think off. Lets wait for the presentation at 39c3 :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
RE: [PATCH net-next] bridge: multicast to unicast
> -Message d'origine- > De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] De la part de Stephen Hemminger > Envoyé : samedi 7 janvier 2017 04:14 > À : Linus Lüssing > Cc : net...@vger.kernel.org; David S . Miller; bridge@lists.linux- > foundation.org; linux-kernel@vger.kernel.org; linux- > wirel...@vger.kernel.org; Felix Fietkau > Objet : Re: [PATCH net-next] bridge: multicast to unicast > > On Mon, 2 Jan 2017 20:32:14 +0100 > Linus Lüssing wrote: > > > This feature is intended for interface types which have a more > > reliable and/or efficient way to deliver unicast packets than > > broadcast ones (e.g. wifi). > > > Why is this not done in MAC80211 rather than bridge? OTOH mac80211 has more information to decide whether it is more economic to send one multicast or several unicast. It depends on the bitrate of each station, number of stations and the (not necessarily slower) bitrate of multicasts.
Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
2017년 01월 09일 16:37에 Andrzej Hajda 이(가) 쓴 글:
> On 06.01.2017 09:36, Inki Dae wrote:
>>
>> 2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
>>> Hi Inki,
>>>
>>> Thanks for the reply, but...
>>>
>> +static const struct drm_display_mode default_mode = {
>> +.clock = 222372,
>> +.hdisplay = 1440,
>> +.hsync_start = 1440 + 1,
>> +.hsync_end = 1440 + 1 + 1,
>> +.htotal = 1440 + 1 + 1 + 1,
>> +.vdisplay = 2560,
>> +.vsync_start = 2560 + 1,
>> +.vsync_end = 2560 + 1 + 1,
>> +.vtotal = 2560 + 1 + 1 + 15,
>> +.vrefresh = 60,
>> +.flags = 0,
>> +};
> how is this working with tm2e? Are these values valid for both
> the boards?
We don't need to consider tm2e board with two reasones,
1. there is no tm2e board support in mainline
2. the panel on tm2 would be a little bit different from one on tm2e
>>> ... this display in the Tizen Kernel is supported by both:
>>> tm2 [1] and tm2e [2]. The only differences are:
>> Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :(
>>
>>> TM2:
>>>clock-frequency = <1487>;
>>>hactive = <1440>;
>>>
>>> TM2E:
>>>clock-frequency = <16523724>;
>>>hactive = <1600>;
>>>
>>> I don't know much about the differences you mention in point 2,
>>> but it's a pity to drop support only because we don't want to put
>>> in the dts the 'hactive', and 'clock-frequency' properties.
>> Anyway, tm2e board is already in mainline so Panel driver may need to
>> identify what kinds of panel is probed to decide porch values. I think there
>> are relevant registers in MCU of the Panel device to check version or
>> similar thing.
>
> I think we can safely use different compatible string for tm2e - it uses
> different display IC controller - s6e3hf2, driver will provide timings
> based on it.
Using compatable string wouldn't be a good idea because Panel is a device not
specific to board.
> As far as I examined available specs/docs there is no reliable register
> which can be used to safely distinguish it on runtime, but the docs I
> have are far from completeness.
The data sheet I am seeing says a RDDIDS register describes manufacturer and
module version information. With this we could identify the Panel device.
Of course, we may need to check the register has really different values
according to board.
Below is the version information Hoegeun checked,
TM2
[4.908666] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-10-31 06:41
[5.035768] panel_s6e3ha2 1390.dsi.0: Id: 50 20 09
TM2e
[4.929265] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-09-03 06:30
[5.056287] panel_s6e3ha2 1390.dsi.0: Id: 40 40 14
Thanks.
>
> Regards
> Andrzej
>
>>
>> Thanks.
>>
>>> Andi
>>>
>>> [1]
>>> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
>>> [2]
>>> https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe devicetree" 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 devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Re: [HMM v15 01/16] mm/free_hot_cold_page: catch ZONE_DEVICE pages
On Fri, Jan 06, 2017 at 11:46:28AM -0500, Jérôme Glisse wrote:
> Catch page from ZONE_DEVICE in free_hot_cold_page(). This should never
> happen as ZONE_DEVICE page must always have an elevated refcount.
>
> This is safety-net to catch any refcounting issues in a sane way for any
> ZONE_DEVICE pages.
>
> Signed-off-by: Jérôme Glisse
> Cc: Dan Williams
> Cc: Ross Zwisler
> ---
> mm/page_alloc.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 1c24112..355beb4 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2445,6 +2445,16 @@ void free_hot_cold_page(struct page *page, bool cold)
> unsigned long pfn = page_to_pfn(page);
> int migratetype;
>
> + /*
> + * This should never happen ! Page from ZONE_DEVICE always must have an
> + * active refcount. Complain about it and try to restore the refcount.
> + */
> + if (is_zone_device_page(page)) {
> + VM_BUG_ON_PAGE(is_zone_device_page(page), page);
This can be VM_BUG_ON_PAGE(1, page), hopefully the compiler does the right thing
here. I suspect this should be a BUG_ON, independent of CONFIG_DEBUG_VM
> + page_ref_inc(page);
> + return;
> + }
> +
Balbir Singh.
Re: 4.10-rc1: thinkpad x60: who ate my cpu?
Hi! > I used to have two cpus, and Thinkpad X60 should have two cores, but I > only see one on 4.10-rc1. This machine went through many > suspend/resume cycles. When backups finish, I'll try -rc2. Whoever did it, he seems to have returned the cpu in -rc3. All seems to be good now. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v5] PCI: add a new directory for designware core
Hi, On Friday 06 January 2017 07:10 PM, Joao Pinto wrote: > Hello, > > Às 1:12 PM de 1/6/2017, Kishon Vijay Abraham I escreveu: >> Hi Arnd, >> >> On Friday 06 January 2017 06:31 PM, Arnd Bergmann wrote: >>> On Friday, January 6, 2017 6:22:48 PM CET Kishon Vijay Abraham I wrote: Group all the PCI drivers that use designware core in dwc directory. dwc IP is capable of operating in both host mode and device mode and keeping it inside the *host* directory is misleading. >>> >>> I have no objections to the patch, it makes a lot of sense, but I think >>> the reasoning above is a bit questionable, as a lot of the other >>> host drivers (at least tegra, mvebu and xgene, probably more) equally >>> support >>> endpoint mode and remain in the same directory. >>> >>> Any suggestion to what we should do with them? >> >> I'm not sure of the exact IP's used by these SoCs. Now that we decided to >> group >> the drivers by IPs used, the best would be identify the IPs used in these >> SoCs >> and create a separate directory for each of the IPs. If the vendors own IP is >> used, then create a directory with the name of the vendor?. I'm sure such a >> change would increase the number of directories but I'm not sure what else to >> do here. > > In case of designware based drivers you already did the clean up nicely. Next > would be, like Arnd is sugesting, to do the same to the others. If they are > all > self-contained I suggest we leave them as they are and in the future if a > endpoint variant driver comes up for any of them, we can suggest to add a > folder > with the vendor or SoC name in order to follow the rule. What do you think? That's my idea as well. Arnd, do you think it's okay not to disturb other drivers/directories until endpoint support is added to those drivers? Thanks Kishon
Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
+ Paul for comment.
Leaving in the rest for him.
On Mon, Jan 09, 2017 at 02:36:33AM +, Zheng, Lv wrote:
> Hi,
>
> > From: linux-acpi-ow...@vger.kernel.org
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng,
> > Lv
> > Subject: RE: 174cc7187e6f ACPICA: Tables: Back port
> > acpi_get_table_with_size() and
> > early_acpi_os_unmap_memory() from Linux kernel
> >
> > Hi,
> >
> > > From: linux-acpi-ow...@vger.kernel.org
> > > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of
> > Borislav
> > > Petkov
> > > Subject: Re: 174cc7187e6f ACPICA: Tables: Back port
> > > acpi_get_table_with_size() and
> > > early_acpi_os_unmap_memory() from Linux kernel
> > >
> > > On Sun, Jan 08, 2017 at 03:20:20AM +0100, Rafael J. Wysocki wrote:
> > > > drivers/iommu/amd_iommu_init.c |2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > Index: linux-pm/drivers/iommu/amd_iommu_init.c
> > > > ===
> > > > --- linux-pm.orig/drivers/iommu/amd_iommu_init.c
> > > > +++ linux-pm/drivers/iommu/amd_iommu_init.c
> > > > @@ -2230,7 +2230,7 @@ static int __init early_amd_iommu_init(v
> > > > */
> > > > ret = check_ivrs_checksum(ivrs_base);
> > > > if (ret)
> > > > - return ret;
> > > > + goto out;
> > > >
> > > > amd_iommu_target_ivhd_type =
> > > > get_highest_supported_ivhd_type(ivrs_base);
> > > > DUMP_printk("Using IVHD type %#x\n",
> > > > amd_iommu_target_ivhd_type);
> > >
> > > Good catch, this one needs to be applied regardless.
> > >
> > > However, it doesn't fix my issue though.
> > >
> > > But I think I have it - I went and applied the well-proven debugging
> > > technique of sprinkling printks around. Here's what I'm seeing:
> > >
> > > early_amd_iommu_init()
> > > |-> acpi_put_table(ivrs_base);
> > > |-> acpi_tb_put_table(table_desc);
> > > |-> acpi_tb_invalidate_table(table_desc);
> > > |-> acpi_tb_release_table(...)
> > > |-> acpi_os_unmap_memory
> > > |-> acpi_os_unmap_iomem
> > > |-> acpi_os_map_cleanup
> > > |-> synchronize_rcu_expedited <-- the kernel/rcu/tree_exp.h version
> > > with CONFIG_PREEMPT_RCU=y
> > >
> > > Now that function goes and sends IPIs, i.e., schedule_work()
> > > but this is too early - we haven't even done workqueue_init().
> > > Actually, from looking at the callstack, we do
> > > kernel_init_freeable->native_smp_prepare_cpus() and workqueue_init()
> > > comes next.
> > >
> > > And this makes sense because the splat rIP points to __queue_work() but
> > > we haven't done that yet.
> > >
> > > So that acpi_put_table() is happening too early. Looks like AMD IOMMU
> > > should not put the table but WTH do I know?!
> > >
> > > In any case, commenting out:
> > >
> > > acpi_put_table(ivrs_base);
> > > ivrs_base = NULL;
> > >
> > > and the end of early_amd_iommu_init() makes the box boot again.
> >
> > So please help to comment out these 2 lines (with descriptions and do not
> > delete them).
> > Until acpi_os_unmap_memory() is able to handle such an early case.
>
> IMO, synchronize_rcu_expedited() should be improved:
> If rcu_init() isn't called or there is nothing to synchronize,
> schedule_work() shouldn't be invoked.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] VMCI: Use kmalloc_array() in qp_alloc_ppn_set()
On Sun 08-01-17 17:37:08, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 8 Jan 2017 14:04:10 +0100
>
> Multiplications for the size determination of memory allocations
> indicated that array data structures should be processed.
> Thus use the corresponding function "kmalloc_array".
>
> This issue was detected by using the Coccinelle software.
I am surprised that Coccinelle found a single instance of this pattern.
If there are more then I would suggest changing all of them at once
along with the coccinelle program which has been used.
> Signed-off-by: Markus Elfring
> ---
> drivers/misc/vmw_vmci/vmci_queue_pair.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
> b/drivers/misc/vmw_vmci/vmci_queue_pair.c
> index 498c0854305f..7b5c8a89cc54 100644
> --- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
> +++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
> @@ -486,13 +486,15 @@ static int qp_alloc_ppn_set(void *prod_q,
> if (ppn_set->initialized)
> return VMCI_ERROR_ALREADY_EXISTS;
>
> - produce_ppns =
> - kmalloc(num_produce_pages * sizeof(*produce_ppns), GFP_KERNEL);
> + produce_ppns = kmalloc_array(num_produce_pages,
> + sizeof(*produce_ppns),
> + GFP_KERNEL);
> if (!produce_ppns)
> return VMCI_ERROR_NO_MEM;
>
> - consume_ppns =
> - kmalloc(num_consume_pages * sizeof(*consume_ppns), GFP_KERNEL);
> + consume_ppns = kmalloc_array(num_consume_pages,
> + sizeof(*consume_ppns),
> + GFP_KERNEL);
> if (!consume_ppns) {
> kfree(produce_ppns);
> return VMCI_ERROR_NO_MEM;
> --
> 2.11.0
>
--
Michal Hocko
SUSE Labs
Re: [PATCH V2 1/2] clk: qcom: gdsc: Add support for gdscs with HW control
Hi Sricharan,
On 11/18/2016 02:28 PM, Sricharan R wrote:
> From: Rajendra Nayak
>
> Some GDSCs might support a HW control mode, where in the power
> domain (gdsc) is brought in and out of low power state (while
> unsued) without any SW assistance, saving power.
> Such GDSCs can be configured in a HW control mode when powered on
> until they are explicitly requested to be powered off by software.
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Sricharan R
> ---
> [V2] Fixed to take care of the return value of gdsc_hwctrl
>
> drivers/clk/qcom/gdsc.c | 19 +++
> drivers/clk/qcom/gdsc.h | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> index f12d7b2..57c7c1b 100644
> --- a/drivers/clk/qcom/gdsc.c
> +++ b/drivers/clk/qcom/gdsc.c
> @@ -55,6 +55,13 @@ static int gdsc_is_enabled(struct gdsc *sc, unsigned int
> reg)
> return !!(val & PWR_ON_MASK);
> }
>
> +static int gdsc_hwctrl(struct gdsc *sc, bool en)
> +{
> + u32 val = en ? HW_CONTROL_MASK : 0;
> +
> + return regmap_update_bits(sc->regmap, sc->gdscr, HW_CONTROL_MASK, val);
> +}
> +
> static int gdsc_toggle_logic(struct gdsc *sc, bool en)
> {
> int ret;
> @@ -164,16 +171,28 @@ static int gdsc_enable(struct generic_pm_domain *domain)
>*/
> udelay(1);
>
> + /* Turn on HW trigger mode if supported */
> + if (sc->flags & HW_CTRL)
> + return gdsc_hwctrl(sc, true);
> +
> return 0;
> }
>
> static int gdsc_disable(struct generic_pm_domain *domain)
> {
> struct gdsc *sc = domain_to_gdsc(domain);
> + int ret;
>
> if (sc->pwrsts == PWRSTS_ON)
> return gdsc_assert_reset(sc);
>
> + /* Turn off HW trigger mode if supported */
> + if (sc->flags & HW_CTRL) {
> + ret = gdsc_hwctrl(sc, false);
Looking in the downstream implementation the disabling of the hw control
bit shouldn't be enough.
After disabling hw control bit we must have a 1us delay and polling for
enabled PWR_ON bit with timeout of 100us, only then we should continue
with disabling the GDSC in software controlled mode.
--
regards,
Stan
Re: [PATCH 3/4] mm, page_allocator: Only use per-cpu allocator for irq-safe requests
On Mon, Jan 09, 2017 at 11:14:29AM +0800, Hillf Danton wrote: > > Sent: Friday, January 06, 2017 6:16 PM Mel Gorman wrote: > > > > On Fri, Jan 06, 2017 at 11:26:46AM +0800, Hillf Danton wrote: > > > > > > On Wednesday, January 04, 2017 7:11 PM Mel Gorman wrote: > > > > @@ -2647,9 +2644,8 @@ static struct page *rmqueue_pcplist(struct zone > > > > *preferred_zone, > > > > struct list_head *list; > > > > bool cold = ((gfp_flags & __GFP_COLD) != 0); > > > > struct page *page; > > > > - unsigned long flags; > > > > > > > > - local_irq_save(flags); > > > > + preempt_disable(); > > > > pcp = &this_cpu_ptr(zone->pageset)->pcp; > > > > list = &pcp->lists[migratetype]; > > > > page = __rmqueue_pcplist(zone, order, gfp_flags, migratetype, > > > > @@ -2658,7 +2654,7 @@ static struct page *rmqueue_pcplist(struct zone > > > > *preferred_zone, > > > > __count_zid_vm_events(PGALLOC, page_zonenum(page), 1 << > > > > order); > > > > zone_statistics(preferred_zone, zone, gfp_flags); > > > > } > > > > - local_irq_restore(flags); > > > > + preempt_enable(); > > > > return page; > > > > } > > > > > > > With PREEMPT configured, preempt_enable() adds entry point to schedule(). > > > Is that needed when we try to allocate a page? > > > > > > > Not necessarily but what are you proposing as an alternative? > > preempt_enable_no_resched() looks at first glance a choice for us to > avoid flipping interrupts. > Ok, I wasn't sure if you were proposing something more drastic. I can make it this although I have no reason to believe it will really matter. The path should be short enough that it's unlikely a scheduler event would ever occur at that point. Still, no harm in doing what you suggest. Thanks. -- Mel Gorman SUSE Labs
RE: Problem on SCTP
From: Sun Paul > Sent: 09 January 2017 02:08 > >> I am setting up a lab where the SCTP traffics from client is passing > >> through a linux router before reaching to the SCTP server running > >> LKSCTP. > >> > >> The linux router did not change the source address of the client, so > >> when it arrived to the SCTP server, the source address is the oriingal > >> one. > > the INIT chunk arrive on the SERVER, but then no response. the > application that using in SERVER is the same as the other test. > > I noticed one thing in Ethernet frame of the incoming packet on the > SERVER compared to the one captured from the client is the LG bit on > the source address. > > The LG bit is set to 0 on the request packet received in the > SERVER,but it is 0 from the one originated on the client. willl it be > the root cause? Which addresses are you talking about, and what do you mean by the LG bit? Is your linux 'router' just routing (ie IP forwarding) or is it doing NAT? If it is changing the IP addresses then the addresses inside some SCTP chunks also need changing. David
[PATCH 1/6] perf tools: Add unit_number__scnprint function
Adding unit_number__scnprint function to display
size units and use it in -m option info message.
Before:
$ perf record -m 10M ls
rounding mmap pages size to 16777216 bytes (4096 pages)
...
After:
$ perf record -m 10M ls
rounding mmap pages size to 16M (4096 pages)
...
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-0gafw11lesghnbfoiw90k...@git.kernel.org
---
tools/perf/tests/Build | 1 +
tools/perf/tests/builtin-test.c | 4
tools/perf/tests/tests.h | 1 +
tools/perf/tests/unit_number__scnprint.c | 37
tools/perf/util/evlist.c | 8 +--
tools/perf/util/util.c | 13 +++
tools/perf/util/util.h | 1 +
7 files changed, 63 insertions(+), 2 deletions(-)
create mode 100644 tools/perf/tests/unit_number__scnprint.c
diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index 6676c2dd6dcb..4f653d257225 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -44,6 +44,7 @@ perf-y += is_printable_array.o
perf-y += bitmap.o
perf-y += perf-hooks.o
perf-y += clang.o
+perf-y += unit_number__scnprint.o
$(OUTPUT)tests/llvm-src-base.c: tests/bpf-script-example.c tests/Build
$(call rule_mkdir)
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index a77dcc0d24e3..5d93c41803d3 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -247,6 +247,10 @@ static struct test generic_tests[] = {
}
},
{
+ .desc = "unit_number__scnprint",
+ .func = test__unit_number__scnprint,
+ },
+ {
.func = NULL,
},
};
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index a512f0c8ff5b..1fa9b9d83aa5 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -96,6 +96,7 @@ int test__perf_hooks(int subtest);
int test__clang(int subtest);
const char *test__clang_subtest_get_desc(int subtest);
int test__clang_subtest_get_nr(void);
+int test__unit_number__scnprint(int subtest);
#if defined(__arm__) || defined(__aarch64__)
#ifdef HAVE_DWARF_UNWIND_SUPPORT
diff --git a/tools/perf/tests/unit_number__scnprint.c
b/tools/perf/tests/unit_number__scnprint.c
new file mode 100644
index ..b336024b6c6a
--- /dev/null
+++ b/tools/perf/tests/unit_number__scnprint.c
@@ -0,0 +1,37 @@
+#include
+#include
+#include "tests.h"
+#include "util.h"
+#include "debug.h"
+
+int test__unit_number__scnprint(int subtest __maybe_unused)
+{
+ struct {
+ u64 n;
+ const char *str;
+ } test[] = {
+ { 1,"1B"},
+ { 10*1024, "10K" },
+ { 20*1024*1024, "20M" },
+ { 30*1024*1024*1024ULL, "30G" },
+ { 0,"0B"},
+ { 0,NULL},
+ };
+ unsigned i = 0;
+
+ while (test[i].str) {
+ char buf[100];
+
+ unit_number__scnprint(buf, sizeof(buf), test[i].n);
+
+ pr_debug("n %" PRIu64 ", str '%s', buf '%s'\n",
+test[i].n, test[i].str, buf);
+
+ if (strcmp(test[i].str, buf))
+ return TEST_FAIL;
+
+ i++;
+ }
+
+ return TEST_OK;
+}
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index d92e02006fb8..435ff1c94a66 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1224,12 +1224,16 @@ static long parse_pages_arg(const char *str, unsigned
long min,
if (pages == 0 && min == 0) {
/* leave number of pages at 0 */
} else if (!is_power_of_2(pages)) {
+ char buf[100];
+
/* round pages up to next power of 2 */
pages = roundup_pow_of_two(pages);
if (!pages)
return -EINVAL;
- pr_info("rounding mmap pages size to %lu bytes (%lu pages)\n",
- pages * page_size, pages);
+
+ unit_number__scnprint(buf, sizeof(buf), pages * page_size);
+ pr_info("rounding mmap pages size to %s (%lu pages)\n",
+ buf, pages);
}
if (pages > max)
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 9ddd98827d12..c2b941dd8826 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -789,3 +789,16 @@ int is_printable_array(char *p, unsigned int len)
}
return 1;
}
+
+int unit_number__scnprint(char *buf, size_t size, u64 n)
+{
+ char unit[4] = "BKMG";
+ int i = 0;
+
+ while (((n / 1024) > 1) && (i < 3)) {
+ n /= 1024;
+ i++;
+ }
+
+ return scnprint
[PATCH 3/6] perf record: Change switch-output option to take optional argument
Next patches will add --switch-output option arguments,
changing the option to allow that and adding its default
value to 'signal'.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-d3qy0tnc4m2dyt8yd6x5p...@git.kernel.org
---
tools/perf/builtin-record.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f7e805b30527..2bf811acaf8d 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -48,6 +48,8 @@
struct switch_output {
bool signal;
+ const char *str;
+ bool set;
};
struct record {
@@ -1356,6 +1358,22 @@ static int record__parse_mmap_pages(const struct option
*opt,
return ret;
}
+static int switch_output_setup(struct record *rec)
+{
+ struct switch_output *s = &rec->switch_output;
+
+ if (!s->set)
+ return 0;
+
+ if (!strcmp(s->str, "signal")) {
+ s->signal = true;
+ pr_debug("switch-output with SIGUSR2 signal\n");
+ return 0;
+ }
+
+ return -1;
+}
+
static const char * const __record_usage[] = {
"perf record [] []",
"perf record [] -- []",
@@ -1523,8 +1541,9 @@ static struct option __record_options[] = {
"Record build-id of all DSOs regardless of hits"),
OPT_BOOLEAN(0, "timestamp-filename", &record.timestamp_filename,
"append timestamp to output filename"),
- OPT_BOOLEAN(0, "switch-output", &record.switch_output.signal,
- "Switch output when receive SIGUSR2"),
+ OPT_STRING_OPTARG_SET(0, "switch-output", &record.switch_output.str,
+ &record.switch_output.set, "signal",
+ "Switch output when receive SIGUSR2", "signal"),
OPT_BOOLEAN(0, "dry-run", &dry_run,
"Parse options then exit"),
OPT_END()
@@ -1582,6 +1601,11 @@ int cmd_record(int argc, const char **argv, const char
*prefix __maybe_unused)
return -EINVAL;
}
+ if (switch_output_setup(rec)) {
+ parse_options_usage(record_usage, record_options,
"switch-output", 0);
+ return -EINVAL;
+ }
+
if (rec->switch_output.signal)
rec->timestamp_filename = true;
--
2.7.4
[PATCH 5/6] perf record: Add switch-output size warning
Adding switch-output size warning if the requested
size of lower than the wakeup ring buffer size.
$ perf record --switch-output=1K ls
WARNING: switch-output data size lower than wakeup kernel buffer size (258K)
expect bigger perf.data sizes
...
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-0gafw11lesghnbfoiw90k...@git.kernel.org
---
tools/perf/builtin-record.c | 21 +
tools/perf/util/evlist.c| 2 +-
tools/perf/util/evlist.h| 2 ++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 3fa64492ee62..4a70e964cd96 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1377,6 +1377,23 @@ static int record__parse_mmap_pages(const struct option
*opt,
return ret;
}
+static void switch_output_size_warn(struct record *rec)
+{
+ u64 wakeup_size = perf_evlist__mmap_size(rec->opts.mmap_pages);
+ struct switch_output *s = &rec->switch_output;
+
+ wakeup_size /= 2;
+
+ if (s->size < wakeup_size) {
+ char buf[100];
+
+ unit_number__scnprint(buf, sizeof(buf), wakeup_size);
+ pr_warning("WARNING: switch-output data size lower than "
+ "wakeup kernel buffer size (%s) "
+ "expect bigger perf.data sizes\n", buf);
+ }
+}
+
static int switch_output_setup(struct record *rec)
{
struct switch_output *s = &rec->switch_output;
@@ -1410,6 +1427,10 @@ static int switch_output_setup(struct record *rec)
enabled:
rec->timestamp_filename = true;
s->enabled = true;
+
+ if (s->size && !rec->opts.no_buffering)
+ switch_output_size_warn(rec);
+
return 0;
}
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 435ff1c94a66..9900ce5177bc 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1184,7 +1184,7 @@ unsigned long perf_event_mlock_kb_in_pages(void)
return pages;
}
-static size_t perf_evlist__mmap_size(unsigned long pages)
+size_t perf_evlist__mmap_size(unsigned long pages)
{
if (pages == UINT_MAX)
pages = perf_event_mlock_kb_in_pages();
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 4fd034f22d2f..389b9ccdf8c7 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -218,6 +218,8 @@ int perf_evlist__mmap(struct perf_evlist *evlist, unsigned
int pages,
bool overwrite);
void perf_evlist__munmap(struct perf_evlist *evlist);
+size_t perf_evlist__mmap_size(unsigned long pages);
+
void perf_evlist__disable(struct perf_evlist *evlist);
void perf_evlist__enable(struct perf_evlist *evlist);
void perf_evlist__toggle_enable(struct perf_evlist *evlist);
--
2.7.4
[PATCHv2 0/7] perf tools: Add switch-output size and time threshold options
hi, adding a way to configure switch data output for size and time, like: $ sudo perf record -e 'sched:*' --switch-output=10M -avg callchain: type FP switch-output with 10M size threshold mmap size 528384B [ perf record: dump data: Woken up 37 times ] [ perf record: Dump perf.data.2017010309135512 ] [ perf record: dump data: Woken up 39 times ] [ perf record: Dump perf.data.2017010309135771 ] [ perf record: dump data: Woken up 38 times ] [ perf record: Dump perf.data.2017010309140005 ] ^C[ perf record: Woken up 16 times to write data ] [ perf record: Dump perf.data.2017010309140111 ] [ perf record: Captured and wrote 4.748 MB perf.data. ] ... the default for switch-output option stays and does the SIGUSR2 output switch v2 changes: - some patches already accepted - add warning for switched size lower than ring buffer wakeup size - got Wang Nan's Tested-by, but did not include it due to changes I made in v2 Also available in: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git perf/fixes thanks, jirka Cc: Wang Nan --- Jiri Olsa (6): perf tools: Add unit_number__scnprint function perf record: Add struct switch_output perf record: Change switch-output option to take optional argument perf record: Add switch-output size option argument perf record: Add switch-output size warning perf record: Add switch-output time option argument tools/perf/Documentation/perf-record.txt | 14 +++-- tools/perf/builtin-record.c | 154 ++ tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 +++ tools/perf/tests/tests.h | 1 + tools/perf/tests/unit_number__scnprint.c | 37 ++ tools/perf/util/evlist.c | 10 -- tools/perf/util/evlist.h | 2 ++ tools/perf/util/util.c | 13 tools/perf/util/util.h | 1 + 10 files changed, 219 insertions(+), 18 deletions(-) create mode 100644 tools/perf/tests/unit_number__scnprint.c
[PATCH 4/6] perf record: Add switch-output size option argument
It's now possible to specify the threshold size for
perf.data like:
$ perf record --switch-output=2G ...
Once it's reached, the current data are dumped in to the
perf.data. file and session does on.
$ perf record --switch-output=2G ...
[ perf record: dump data: Woken up 7244 times ]
[ perf record: Dump perf.data.2017010214093746 ]
...
The size is expected to be a number with appended unit
character - B/K/M/G.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-xw4x8qj6aojox378q9ley...@git.kernel.org
---
tools/perf/Documentation/perf-record.txt | 12 +-
tools/perf/builtin-record.c | 67 +---
2 files changed, 63 insertions(+), 16 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 5054d9147f0f..3d55d2fd48b3 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -421,9 +421,17 @@ Configure all used events to run in user space.
--timestamp-filename
Append timestamp to output file name.
---switch-output::
+--switch-output[=mode]::
Generate multiple perf.data files, timestamp prefixed, switching to a new one
-when receiving a SIGUSR2.
+based on 'mode' value:
+ "signal" - when receiving a SIGUSR2 (default value) or
+ - when reaching the size threshold, size is expected to
+ be a number with appended unit character - B/K/M/G
+
+ Note: the precision of the size threshold hugely depends
+ on your configuration - the number and size of your ring
+ buffers (-m). It is generally more precise for higher sizes
+ (like >5M), for lower values expect different sizes.
A possible use case is to, given an external event, slice the perf.data file
that gets then processed, possibly via a perf script, to decide if that
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 2bf811acaf8d..3fa64492ee62 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -47,7 +47,9 @@
#include
struct switch_output {
+ bool enabled;
bool signal;
+ unsigned longsize;
const char *str;
bool set;
};
@@ -72,6 +74,23 @@ struct record {
unsigned long long samples;
};
+static volatile int auxtrace_record__snapshot_started;
+static DEFINE_TRIGGER(auxtrace_snapshot_trigger);
+static DEFINE_TRIGGER(switch_output_trigger);
+
+static bool switch_output_signal(struct record *rec)
+{
+ return rec->switch_output.signal &&
+ trigger_is_ready(&switch_output_trigger);
+}
+
+static bool switch_output_size(struct record *rec)
+{
+ return rec->switch_output.size &&
+ trigger_is_ready(&switch_output_trigger) &&
+ (rec->bytes_written >= rec->switch_output.size);
+}
+
static int record__write(struct record *rec, void *bf, size_t size)
{
if (perf_data_file__write(rec->session->file, bf, size) < 0) {
@@ -80,6 +99,10 @@ static int record__write(struct record *rec, void *bf,
size_t size)
}
rec->bytes_written += size;
+
+ if (switch_output_size(rec))
+ trigger_hit(&switch_output_trigger);
+
return 0;
}
@@ -199,10 +222,6 @@ static volatile int done;
static volatile int signr = -1;
static volatile int child_finished;
-static volatile int auxtrace_record__snapshot_started;
-static DEFINE_TRIGGER(auxtrace_snapshot_trigger);
-static DEFINE_TRIGGER(switch_output_trigger);
-
static void sig_handler(int sig)
{
if (sig == SIGCHLD)
@@ -848,11 +867,11 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
signal(SIGTERM, sig_handler);
signal(SIGSEGV, sigsegv_handler);
- if (rec->opts.auxtrace_snapshot_mode || rec->switch_output.signal) {
+ if (rec->opts.auxtrace_snapshot_mode || rec->switch_output.enabled) {
signal(SIGUSR2, snapshot_sig_handler);
if (rec->opts.auxtrace_snapshot_mode)
trigger_on(&auxtrace_snapshot_trigger);
- if (rec->switch_output.signal)
+ if (rec->switch_output.enabled)
trigger_on(&switch_output_trigger);
} else {
signal(SIGUSR2, SIG_IGN);
@@ -1361,6 +1380,14 @@ static int record__parse_mmap_pages(const struct option
*opt,
static int switch_output_setup(struct record *rec)
{
struct switch_output *s = &rec->switch_output;
+ static struct parse_tag tags_size[] = {
+ { .tag = 'B', .mult = 1 },
+ { .tag = 'K', .mult = 1 << 10 },
+ { .tag = 'M', .mult = 1 << 20 },
+ { .tag = 'G', .mult = 1 << 30 },
+ { .tag = 0 },
+ };
+ unsigned long val;
if (!s->set)
return 0;
@@
[PATCH 2/6] perf record: Add struct switch_output
Next patches will add more --switch-output option arguments,
so preparing the data holder.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-tibmeq1qw3kgrfzrswt5x...@git.kernel.org
---
tools/perf/builtin-record.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 4ec10e9427d9..f7e805b30527 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -46,6 +46,10 @@
#include
#include
+struct switch_output {
+ bool signal;
+};
+
struct record {
struct perf_tooltool;
struct record_opts opts;
@@ -62,7 +66,7 @@ struct record {
boolno_buildid_cache_set;
boolbuildid_all;
booltimestamp_filename;
- boolswitch_output;
+ struct switch_outputswitch_output;
unsigned long long samples;
};
@@ -842,11 +846,11 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
signal(SIGTERM, sig_handler);
signal(SIGSEGV, sigsegv_handler);
- if (rec->opts.auxtrace_snapshot_mode || rec->switch_output) {
+ if (rec->opts.auxtrace_snapshot_mode || rec->switch_output.signal) {
signal(SIGUSR2, snapshot_sig_handler);
if (rec->opts.auxtrace_snapshot_mode)
trigger_on(&auxtrace_snapshot_trigger);
- if (rec->switch_output)
+ if (rec->switch_output.signal)
trigger_on(&switch_output_trigger);
} else {
signal(SIGUSR2, SIG_IGN);
@@ -1519,7 +1523,7 @@ static struct option __record_options[] = {
"Record build-id of all DSOs regardless of hits"),
OPT_BOOLEAN(0, "timestamp-filename", &record.timestamp_filename,
"append timestamp to output filename"),
- OPT_BOOLEAN(0, "switch-output", &record.switch_output,
+ OPT_BOOLEAN(0, "switch-output", &record.switch_output.signal,
"Switch output when receive SIGUSR2"),
OPT_BOOLEAN(0, "dry-run", &dry_run,
"Parse options then exit"),
@@ -1578,7 +1582,7 @@ int cmd_record(int argc, const char **argv, const char
*prefix __maybe_unused)
return -EINVAL;
}
- if (rec->switch_output)
+ if (rec->switch_output.signal)
rec->timestamp_filename = true;
if (!rec->itr) {
@@ -1629,7 +1633,7 @@ int cmd_record(int argc, const char **argv, const char
*prefix __maybe_unused)
if (rec->no_buildid_cache || rec->no_buildid) {
disable_buildid_cache();
- } else if (rec->switch_output) {
+ } else if (rec->switch_output.signal) {
/*
* In 'perf record --switch-output', disable buildid
* generation by default to reduce data file switching
--
2.7.4
[PATCH 6/6] perf record: Add switch-output time option argument
It's now possible to specify the threshold time for
perf.data like:
$ perf record --switch-output=30s ...
Once it's reached, the current data are dumped in to the
perf.data. file and session does on.
$ perf record --switch-output=30s ...
[ perf record: dump data: Woken up 44 times ]
[ perf record: Dump perf.data.2017010213043746 ]
...
The time is expected to be a number with appended unit
character - s/m/h/d.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-2u6y3h89c0guejpn1nwv3...@git.kernel.org
---
tools/perf/Documentation/perf-record.txt | 2 ++
tools/perf/builtin-record.c | 44 ++--
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 3d55d2fd48b3..27256bc68eda 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -427,6 +427,8 @@ based on 'mode' value:
"signal" - when receiving a SIGUSR2 (default value) or
- when reaching the size threshold, size is expected to
be a number with appended unit character - B/K/M/G
+ - when reaching the time threshold, size is expected to
+ be a number with appended unit character - s/m/h/d
Note: the precision of the size threshold hugely depends
on your configuration - the number and size of your ring
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 4a70e964cd96..4e437dba60dd 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -50,6 +50,7 @@ struct switch_output {
bool enabled;
bool signal;
unsigned longsize;
+ unsigned longtime;
const char *str;
bool set;
};
@@ -91,6 +92,12 @@ static bool switch_output_size(struct record *rec)
(rec->bytes_written >= rec->switch_output.size);
}
+static bool switch_output_time(struct record *rec)
+{
+ return rec->switch_output.time &&
+ trigger_is_ready(&switch_output_trigger);
+}
+
static int record__write(struct record *rec, void *bf, size_t size)
{
if (perf_data_file__write(rec->session->file, bf, size) < 0) {
@@ -737,6 +744,7 @@ static void workload_exec_failed_signal(int signo
__maybe_unused,
}
static void snapshot_sig_handler(int sig);
+static void alarm_sig_handler(int sig);
int __weak
perf_event__synth_time_conv(const struct perf_event_mmap_page *pc
__maybe_unused,
@@ -1068,6 +1076,10 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
err = fd;
goto out_child;
}
+
+ /* re-arm the alarm */
+ if (rec->switch_output.time)
+ alarm(rec->switch_output.time);
}
if (hits == rec->samples) {
@@ -1404,6 +1416,13 @@ static int switch_output_setup(struct record *rec)
{ .tag = 'G', .mult = 1 << 30 },
{ .tag = 0 },
};
+ static struct parse_tag tags_time[] = {
+ { .tag = 's', .mult = 1},
+ { .tag = 'm', .mult = 60 },
+ { .tag = 'h', .mult = 60*60},
+ { .tag = 'd', .mult = 60*60*24 },
+ { .tag = 0 },
+ };
unsigned long val;
if (!s->set)
@@ -1422,6 +1441,14 @@ static int switch_output_setup(struct record *rec)
goto enabled;
}
+ val = parse_tag_value(s->str, tags_time);
+ if (val != (unsigned long) -1) {
+ s->time = val;
+ pr_debug("switch-output with %s time threshold (%lu seconds)\n",
+s->str, s->time);
+ goto enabled;
+ }
+
return -1;
enabled:
@@ -1602,8 +1629,8 @@ static struct option __record_options[] = {
OPT_BOOLEAN(0, "timestamp-filename", &record.timestamp_filename,
"append timestamp to output filename"),
OPT_STRING_OPTARG_SET(0, "switch-output", &record.switch_output.str,
- &record.switch_output.set, "signal,size",
- "Switch output when receive SIGUSR2 or cross size
threshold",
+ &record.switch_output.set, "signal,size,time",
+ "Switch output when receive SIGUSR2 or cross
size,time threshold",
"signal"),
OPT_BOOLEAN(0, "dry-run", &dry_run,
"Parse options then exit"),
@@ -1667,6 +1694,11 @@ int cmd_record(int argc, const char **argv, const char
*prefix __maybe_unused)
return -EINVAL;
}
+ if (rec->switch_output.time) {
+ signal(SIGALRM, alarm_sig_hand
Re: [PATCH 1/2] serial: sh-sci: Fix early deassertion of dedicated RTS
Hi Laurent,
On Fri, Jan 6, 2017 at 1:30 PM, Laurent Pinchart
wrote:
> On Friday 02 Dec 2016 13:35:10 Geert Uytterhoeven wrote:
>> If a UART has dedicated RTS/CTS pins, there are some issues:
>> 1. When changing hardware control flow, the new AUTORTS state is not
>>immediately reflected in the hardware, but only when RTS is raised.
>>However, the serial core doesn't call .set_mctrl() after
>>.set_termios(), hence AUTORTS may only become effective when the port
>>is closed, and reopened later.
>>Note that this problem does not happen when manually using stty to
>>change CRTSCTS, as AUTORTS will work fine on next open.
>>
>> 2. When hardware control flow is disabled (or AUTORTS is not yet
>>effective), changing any serial port configuration deasserts RTS, as
>>.set_termios() calls sci_init_pins().
>
> Isn't this still a problem with this patch applied ? Calling sci_set_mctrl()
> should reconfigure the pins properly, but won't there be a short window during
> which the configuration will be wrong ?
You mean in between the calls to sci_init_pins() and sci_set_mctrl()?
I don't think _de_asserting RTS for a few microseconds matters much, would it?
Asserting RTS wrongly would be worse.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On 09.01.2017 10:19, Inki Dae wrote:
>
> 2017년 01월 09일 16:37에 Andrzej Hajda 이(가) 쓴 글:
>> On 06.01.2017 09:36, Inki Dae wrote:
>>> 2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
Hi Inki,
Thanks for the reply, but...
>>> +static const struct drm_display_mode default_mode = {
>>> + .clock = 222372,
>>> + .hdisplay = 1440,
>>> + .hsync_start = 1440 + 1,
>>> + .hsync_end = 1440 + 1 + 1,
>>> + .htotal = 1440 + 1 + 1 + 1,
>>> + .vdisplay = 2560,
>>> + .vsync_start = 2560 + 1,
>>> + .vsync_end = 2560 + 1 + 1,
>>> + .vtotal = 2560 + 1 + 1 + 15,
>>> + .vrefresh = 60,
>>> + .flags = 0,
>>> +};
>> how is this working with tm2e? Are these values valid for both
>> the boards?
> We don't need to consider tm2e board with two reasones,
> 1. there is no tm2e board support in mainline
> 2. the panel on tm2 would be a little bit different from one on tm2e
... this display in the Tizen Kernel is supported by both:
tm2 [1] and tm2e [2]. The only differences are:
>>> Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :(
>>>
TM2:
clock-frequency = <1487>;
hactive = <1440>;
TM2E:
clock-frequency = <16523724>;
hactive = <1600>;
I don't know much about the differences you mention in point 2,
but it's a pity to drop support only because we don't want to put
in the dts the 'hactive', and 'clock-frequency' properties.
>>> Anyway, tm2e board is already in mainline so Panel driver may need to
>>> identify what kinds of panel is probed to decide porch values. I think
>>> there are relevant registers in MCU of the Panel device to check version or
>>> similar thing.
>> I think we can safely use different compatible string for tm2e - it uses
>> different display IC controller - s6e3hf2, driver will provide timings
>> based on it.
> Using compatable string wouldn't be a good idea because Panel is a device not
> specific to board.
But both panels are different devices:
TM2 has: AMS567DJ01 panel on S6E3HA2 interface (called LDI/IC)
TM2E has AMB559DE01 panel on S6E3HF2 interface (called LDI/IC)
Why assigning different compatibles to different devices is not a good idea?
>
>> As far as I examined available specs/docs there is no reliable register
>> which can be used to safely distinguish it on runtime, but the docs I
>> have are far from completeness.
> The data sheet I am seeing says a RDDIDS register describes manufacturer and
> module version information. With this we could identify the Panel device.
> Of course, we may need to check the register has really different values
> according to board.
>
> Below is the version information Hoegeun checked,
>
> TM2
> [4.908666] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-10-31
> 06:41
> [5.035768] panel_s6e3ha2 1390.dsi.0: Id: 50 20 09
>
> TM2e
> [4.929265] panel_s6e3ha2 1390.dsi.0: Manufacture date: 2014-09-03
> 06:30
> [5.056287] panel_s6e3ha2 1390.dsi.0: Id: 40 40 14
There is description of ID1, ID2, ID3 registers in specs of both panels,
I see no reliable bits to distinguish panels.
And relying on read values of random devices does not seems to me proper
solution.
Regards
Andrzej
>
>
> Thanks.
>
>> Regards
>> Andrzej
>>
>>> Thanks.
>>>
Andi
[1]
https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
[2]
https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
Re: [PATCH 4.4 54/58] powerpc: Convert cmp to cmpd in idle enter sequence
* Greg Kroah-Hartman [2017-01-06 22:44:39]:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Segher Boessenkool
>
> commit 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 upstream.
>
> PowerPC's "cmp" instruction has four operands. Normally people write
> "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently
> people forget, and write "cmp" with just three operands.
>
> With older binutils this is silently accepted as if this was "cmpw",
> while often "cmpd" is wanted. With newer binutils GAS will complain
> about this for 64-bit code. For 32-bit code it still silently assumes
> "cmpw" is what is meant.
>
> In this instance the code comes directly from ISA v2.07, including the
> cmp, but cmpd is correct. Backport to stable so that new toolchains can
> build old kernels.
>
> Fixes: 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode")
> Reviewed-by: Vaidyanathan Srinivasan
> Signed-off-by: Segher Boessenkool
> Signed-off-by: Michael Ellerman
> Signed-off-by: Joel Stanley
> Signed-off-by: Greg Kroah-Hartman
Acked-by: Vaidyanathan Srinivasan
The change from cmp to cmpd is correct. This code will execute
in 64-bit mode only and fix applies to stable as described above.
>
>
> ---
> arch/powerpc/kernel/idle_power7.S |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/arch/powerpc/kernel/idle_power7.S
> +++ b/arch/powerpc/kernel/idle_power7.S
> @@ -44,7 +44,7 @@
> std r0,0(r1); \
> ptesync;\
> ld r0,0(r1); \
> -1: cmp cr0,r0,r0; \
> +1: cmpdcr0,r0,r0; \
> bne 1b; \
> IDLE_INST; \
> b .
>
>
Re: [PATCH 3/4] mm, page_allocator: Only use per-cpu allocator for irq-safe requests
On Monday, January 09, 2017 5:48 PM Mel Gorman wrote: > On Mon, Jan 09, 2017 at 11:14:29AM +0800, Hillf Danton wrote: > > > On Friday, January 06, 2017 6:16 PM Mel Gorman wrote: > > > > > > On Fri, Jan 06, 2017 at 11:26:46AM +0800, Hillf Danton wrote: > > > > > > > > On Wednesday, January 04, 2017 7:11 PM Mel Gorman wrote: > > > > > @@ -2647,9 +2644,8 @@ static struct page *rmqueue_pcplist(struct zone > > > > > *preferred_zone, > > > > > struct list_head *list; > > > > > bool cold = ((gfp_flags & __GFP_COLD) != 0); > > > > > struct page *page; > > > > > - unsigned long flags; > > > > > > > > > > - local_irq_save(flags); > > > > > + preempt_disable(); > > > > > pcp = &this_cpu_ptr(zone->pageset)->pcp; > > > > > list = &pcp->lists[migratetype]; > > > > > page = __rmqueue_pcplist(zone, order, gfp_flags, migratetype, > > > > > @@ -2658,7 +2654,7 @@ static struct page *rmqueue_pcplist(struct zone > > > > > *preferred_zone, > > > > > __count_zid_vm_events(PGALLOC, page_zonenum(page), 1 << > > > > > order); > > > > > zone_statistics(preferred_zone, zone, gfp_flags); > > > > > } > > > > > - local_irq_restore(flags); > > > > > + preempt_enable(); > > > > > return page; > > > > > } > > > > > > > > > With PREEMPT configured, preempt_enable() adds entry point to > > > > schedule(). > > > > Is that needed when we try to allocate a page? > > > > > > > > > > Not necessarily but what are you proposing as an alternative? > > > > preempt_enable_no_resched() looks at first glance a choice for us to > > avoid flipping interrupts. > > > > Ok, I wasn't sure if you were proposing something more drastic. I can > make it this although I have no reason to believe it will really matter. > The path should be short enough that it's unlikely a scheduler event > would ever occur at that point. Still, no harm in doing what you > suggest. > If spin, feel free to add Acked-by: Hillf Danton to the patchset.
[PATCH] ACPI / OSL: Fix rcu synchronization logic
The rcu synchronization logic is originally provided to protect
apei_read()/apei_write() as in the APEI drivers, there is NMI event source
requiring non spinlock based synchronization mechanism.
After that, ACPI developers think FADT registers may also require same
facility, so they moved the RCU stuffs to generic ACPI layer.
So now non-task-context ACPI map lookup is only protected by RCU.
This triggers problem as acpi_os_map_memory()/acpi_os_unmap_memory() can be
used to map/unmap tables as long as to map/unmap ACPI registers. When it is
used for the ACPI tables, the caller could invoke this very early. When it
is invoked earlier than workqueue_init() and later than
check_early_ioremp_leak(), invoking synchronize_rcu_expedited() can cause a
kernel hang.
Actually this facility is only used to protect non-task-context ACPI map
lookup, and such mappings are only introduced by
acpi_os_map_generic_address(). So before it is invoked, there is no need to
invoke synchronize_rcu_expedited().
Suggested-by: Huang Ying
Signed-off-by: Lv Zheng
Cc: Huang Ying
Cc: Borislav Petkov
---
drivers/acpi/osl.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index a404ff4..3d93633 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -77,6 +77,7 @@ static int (*__acpi_os_prepare_extended_sleep)(u8
sleep_state, u32 val_a,
static bool acpi_os_initialized;
unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
bool acpi_permanent_mmap = false;
+bool acpi_synchronize_rcu = false;
/*
* This list of permanent mappings is for memory that may be accessed from
@@ -378,7 +379,8 @@ static void acpi_os_drop_map_ref(struct acpi_ioremap *map)
static void acpi_os_map_cleanup(struct acpi_ioremap *map)
{
if (!map->refcount) {
- synchronize_rcu_expedited();
+ if (acpi_synchronize_rcu)
+ synchronize_rcu_expedited();
acpi_unmap(map->phys, map->virt);
kfree(map);
}
@@ -444,6 +446,7 @@ int acpi_os_map_generic_address(struct acpi_generic_address
*gas)
if (!virt)
return -EIO;
+ acpi_synchronize_rcu = true;
return 0;
}
EXPORT_SYMBOL(acpi_os_map_generic_address);
--
1.7.10
Re: weird allocation pattern in alloc_ila_locks
On Sat 07-01-17 10:37:41, Eric Dumazet wrote: > On Sat, Jan 7, 2017 at 1:27 AM, Michal Hocko wrote: > > On Fri 06-01-17 14:14:49, Eric Dumazet wrote: > > >> I believe the intent was to get NUMA spreading, a bit like what we have > >> in alloc_large_system_hash() when hashdist == HASHDIST_DEFAULT > > > > Hmm, I am not sure this works as expected then. Because it is more > > likely that all pages backing the vmallocked area will come from the > > local node than spread around more nodes. Or did I miss your point? > > Well, you missed that vmalloc() is aware of NUMA policies. You are right. I have missed that alloc_page ends up using alloc_pages_current for CONFIG_NUMA rather than alloc_pages_node. > If current process has requested interleave on 2 nodes (as it is done > at boot time on a dual node system), > then vmalloc() of 8 pages will allocate 4 pages on each node. On the other hand alloc_ila_locks does go over a single page when lockdep is enabled and I am wondering whether doing this NUMA subtle magic is any win... Also this seems to be an init code so I assume a modprobe would have to set a non-default policy to make use of it. Does anybody do that out there? alloc_bucket_locks is a bit more complicated because it is not only called from the init context. But considering that rhashtable_shrink is called from the worker context - so no mem policy can be assumed then I am wondering whether the code really works as expected. To me it sounds like it is trying to be clever while the outcome doesn't really do what it is intended. Would you mind if I just convert it to kvmalloc and make it easier to understand? -- Michal Hocko SUSE Labs
Re: [PATCH] clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled
On 07/01/17 00:44, Michał Zegan wrote:
> seems the patch works as intended.
>
So, can we take this as
Tested-by: Michał Zegan ?
> W dniu 06.01.2017 o 13:34, Sudeep Holla pisze:
>> Currently we add the virtual cpufreq device unconditionally even when
>> the SCPI DVFS clock provider node is disabled. This will cause cpufreq
>> driver to throw errors when it gets initailised on boot/modprobe and
>> also when the CPUs are hot-plugged back in.
>>
>> This patch fixes the issue by adding the virtual cpufreq device only if
>> the SCPI DVFS clock provider is available and registered.
>>
>> Fixes: 9490f01e2471 ("clk: scpi: add support for cpufreq virtual device")
>> Reported-by: Michał Zegan
>> Cc: Neil Armstrong
>> Cc: Michael Turquette
>> Cc: Stephen Boyd
>> Signed-off-by: Sudeep Holla
--
Regards,
Sudeep
Re: [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3
On Sat, Jan 07, 2017 at 04:49:18PM +0100, Ondřej Jirman wrote: > Maxime, > > Dne 25.11.2016 v 01:28 meg...@megous.com napsal(a): > > From: Ondrej Jirman > > > > When adjusting PLL_CPUX on H3, the PLL is temporarily driven > > too high, and the system becomes unstable (oopses or hangs). > > > > Add a notifier to avoid this situation by temporarily switching > > to a known stable 24 MHz oscillator. > > I have done more thorough testing on H3 and this approach with switching > to 24MHz oscillator does not work. Motivation being that my Orange Pi > One still gets lockups even with this patch under certain circumstances. > > So I have created a small test program for CPUS (additional OpenRISC CPU > on the SoC) which randomly changes PLL_CPUX settings while main CPU is > running a loop that sends messages to CPUS via msgbox. > > Assumption being that while CPUS is successfully receiving messages via > msgbox, the main CPU didn't lock up, yet. > > With this I am able to quickly and thoroughly test various PLL_CPUX > change and factor selection algorithms. > > Results are that bypassing CPUX clock by switching to 24 MHz oscillator > does not work at all. Main CPU locks up in about 1 second into the test. > Don't ask me why. You mean that you are changing the frequency behind Linux' back? That won't work. There's more to cpufreq than just changing the frequency, but also adusting the number of loops per jiffy for the new frequency for example. I don't really expect that setup to work even on a perfectly stable system. CPUFreq *has* to be involved, otherwise, that alone might introduce bugs, and you cannot draw any conclusions anymore. > What works is selecting NKMP factors so that M is always 1 and P is > anything other than /1 only for frequencies under 288MHz. As mandated by > the H3 datasheet. Mainline ccu_nkmp_find_best doesn't respect these > conditions. With that I can change CPUX frequencies randomly 20x a > second so far indefinitely without the main CPU ever locking up. > > Please drop or revert this patch. It is not a correct approach to the > problem. I'd suggest dropping the entire clock notifier mechanism, too, > unless it can be proven to work reliably. It has been proven to work reliably on a number of other SoCs. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: Problem on SCTP
Hi the linux router just change the destination, so it can arrive on the the SERVER. On Mon, Jan 9, 2017 at 5:51 PM, David Laight wrote: > From: Sun Paul >> Sent: 09 January 2017 02:08 > >> >> I am setting up a lab where the SCTP traffics from client is passing >> >> through a linux router before reaching to the SCTP server running >> >> LKSCTP. >> >> >> >> The linux router did not change the source address of the client, so >> >> when it arrived to the SCTP server, the source address is the oriingal >> >> one. >> >> the INIT chunk arrive on the SERVER, but then no response. the >> application that using in SERVER is the same as the other test. >> >> I noticed one thing in Ethernet frame of the incoming packet on the >> SERVER compared to the one captured from the client is the LG bit on >> the source address. >> >> The LG bit is set to 0 on the request packet received in the >> SERVER,but it is 0 from the one originated on the client. willl it be >> the root cause? > > Which addresses are you talking about, and what do you mean by the LG bit? > > Is your linux 'router' just routing (ie IP forwarding) or is it doing NAT? > If it is changing the IP addresses then the addresses inside some SCTP > chunks also need changing. > > David >
Re: [PATCH v2 7/7] uapi: export all headers under uapi directories
On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all headers under uapi directories should be exported, thus it's > useless to have an exhaustive list. > > After this patch, the following files, which were not exported, are now > exported (with make headers_install_all): > asm-unicore32/shmparam.h > asm-unicore32/ucontext.h > asm-hexagon/shmparam.h > asm-mips/ucontext.h > asm-mips/hwcap.h > asm-mips/reg.h > drm/vgem_drm.h > drm/armada_drm.h > drm/omap_drm.h > drm/etnaviv_drm.h > asm-tile/shmparam.h > asm-blackfin/shmparam.h > asm-blackfin/ucontext.h > asm-powerpc/perf_regs.h > rdma/qedr-abi.h > asm-parisc/kvm_para.h > asm-openrisc/shmparam.h > asm-nios2/kvm_para.h > asm-nios2/ucontext.h > asm-sh/kvm_para.h > asm-sh/ucontext.h > asm-xtensa/kvm_para.h > asm-avr32/kvm_para.h > asm-m32r/kvm_para.h > asm-h8300/shmparam.h > asm-h8300/ucontext.h > asm-metag/kvm_para.h > asm-metag/shmparam.h > asm-metag/ucontext.h > asm-m68k/kvm_para.h > asm-m68k/shmparam.h > linux/bcache.h > linux/kvm.h > linux/kvm_para.h > linux/kfd_ioctl.h > linux/cryptouser.h > linux/kcm.h > linux/kcov.h > linux/seg6_iptunnel.h > linux/stm.h > linux/genwqe > linux/genwqe/.install > linux/genwqe/genwqe_card.h > linux/genwqe/..install.cmd > linux/seg6.h > linux/cifs > linux/cifs/.install > linux/cifs/cifs_mount.h > linux/cifs/..install.cmd > linux/auto_dev-ioctl.h > > Thanks to Julien Floret for the tip to get all > subdirs with a pure makefile command. > > Signed-off-by: Nicolas Dichtel Makes lots of sense. Acked-by: Daniel Vetter > --- > Documentation/kbuild/makefiles.txt | 41 ++- > arch/alpha/include/uapi/asm/Kbuild | 41 --- > arch/arc/include/uapi/asm/Kbuild| 3 - > arch/arm/include/uapi/asm/Kbuild| 17 - > arch/arm64/include/uapi/asm/Kbuild | 18 -- > arch/avr32/include/uapi/asm/Kbuild | 20 -- > arch/blackfin/include/uapi/asm/Kbuild | 17 - > arch/c6x/include/uapi/asm/Kbuild| 8 - > arch/cris/include/uapi/arch-v10/arch/Kbuild | 5 - > arch/cris/include/uapi/arch-v32/arch/Kbuild | 3 - > arch/cris/include/uapi/asm/Kbuild | 43 +-- > arch/frv/include/uapi/asm/Kbuild| 33 -- > arch/h8300/include/uapi/asm/Kbuild | 28 -- > arch/hexagon/include/asm/Kbuild | 3 - > arch/hexagon/include/uapi/asm/Kbuild| 13 - > arch/ia64/include/uapi/asm/Kbuild | 45 --- > arch/m32r/include/uapi/asm/Kbuild | 31 -- > arch/m68k/include/uapi/asm/Kbuild | 24 -- > arch/metag/include/uapi/asm/Kbuild | 8 - > arch/microblaze/include/uapi/asm/Kbuild | 32 -- > arch/mips/include/uapi/asm/Kbuild | 37 --- > arch/mn10300/include/uapi/asm/Kbuild| 32 -- > arch/nios2/include/uapi/asm/Kbuild | 4 +- > arch/openrisc/include/asm/Kbuild| 3 - > arch/openrisc/include/uapi/asm/Kbuild | 8 - > arch/parisc/include/uapi/asm/Kbuild | 28 -- > arch/powerpc/include/uapi/asm/Kbuild| 45 --- > arch/s390/include/uapi/asm/Kbuild | 52 --- > arch/score/include/asm/Kbuild | 4 - > arch/score/include/uapi/asm/Kbuild | 32 -- > arch/sh/include/uapi/asm/Kbuild | 23 -- > arch/sparc/include/uapi/asm/Kbuild | 48 --- > arch/tile/include/asm/Kbuild| 3 - > arch/tile/include/uapi/arch/Kbuild | 17 - > arch/tile/include/uapi/asm/Kbuild | 19 +- > arch/unicore32/include/uapi/asm/Kbuild | 6 - > arch/x86/include/uapi/asm/Kbuild| 59 > arch/xtensa/include/uapi/asm/Kbuild | 23 -- > include/Kbuild | 2 - > include/asm-generic/Kbuild.asm | 1 - > include/scsi/fc/Kbuild | 0 > include/uapi/Kbuild | 15 - > include/uapi/asm-generic/Kbuild | 36 --- > include/uapi/asm-generic/Kbuild.asm | 62 ++-- > include/uapi/drm/Kbuild | 22 -- > include/uapi/linux/Kbuild | 482 > > include/uapi/linux/android/Kbuild | 2 - > include/uapi/linux/byteorder/Kbuild | 3 - > include/uapi/linux/caif/Kbuild | 3 - > include/uapi/linux/can/Kbuild | 6 - > include/uapi/linux/dvb/Kbuild | 9 - > include/uapi/linux/hdlc/Kbuild | 2 - > include/uapi/linux/hsi/Kbuild | 2 - > include/uapi/linux/iio/Kbuild | 3 - > include/uapi/linux/isdn/Kbuild | 2 - > include/uapi/linux/mmc/Kbuild | 2 - > include/uapi/linux/netfilter/Kbuild | 89 - > include/uapi/linux/netfilter/ipset/Kbuild
Re: [patch] mm, thp: add new background defrag option
On 01/06/2017 11:20 PM, David Rientjes wrote: > On Fri, 6 Jan 2017, Vlastimil Babka wrote: > >> Deciding between "defer" and "background" is however confusing, and also >> doesn't indicate that the difference is related to madvise. >> > > Any suggestions for a better name for "background" are more than welcome. Why not just "madvise+defer"? >> I don't like bikesheding, but as this is about user-space API, more care >> should be taken than for implementation details that can change. Even >> though realistically there will be in 99% of cases only two groups of >> users setting this >> - experts like you who know what they are doing, and confusing names >> won't prevent them from making the right choice >> - people who will blindly copy/paste from the future cargo-cult websites >> (if they ever get updated from the enabled="never" recommendations), who >> likely won't stop and think about the other options. >> > > I think the far majority will go with a third option: simply use the > kernel default and be unaware of other settings or consider it to be the > most likely choice solely because it is the kernel default. Sure, my prediction was only about "users setting this" :) Agreed that those will be a small minority of all users. [...] > So whether it's better to do echo background or echo "madvise defer" is > not important to me, I simply imagine that the combination will be more > difficult to describe to users. It would break our userspace to currently > tests for "[madvise]" and reports that state as strictly madvise to our > mission control, but I can work around that; not sure if others would > encounter the same issue (would "[defer madvise]" or "[defer] [madvise]" > break fewer userspaces?). OK, well I'm reluctant to break existing userspace knowingly over such silliness. Also apparently sysfs files in general should accept only one value, so I'm not going to push my approach. > I'd leave it to Andrew to decide whether sysfs files should accept > multiple modes or not. If you are to propose a patch to do so, I'd > encourage you to do the same cleanup of triple_flag_store() that I did and > make the gfp mask construction more straight-forward. If you'd like to > suggest a different name for "background", I'd be happy to change that if > it's more descriptive. Suggestion is above. I however think your cleanup isn't really needed, we can simply keep the existing 3 internal flags, and "madvise+defer" would enable two of them, like in my patch. Nothing says that internally each option should correspond to exactly one flag. Vlastimil
[PATCH v6 08/17] mtd: nand: Add manufacturer specific initialization/detection steps
A lot of NANDs are implementing generic features in a non-generic way,
or are providing advanced auto-detection logic where the NAND ID bytes
meaning changes with the NAND generation.
Providing this vendor specific initialization step will allow us to get
rid of the full ids in the nand_ids table or all the vendor specific
cases added over the time in the generic NAND ID decoding logic.
Signed-off-by: Boris Brezillon
---
drivers/mtd/nand/nand_base.c | 75 ++--
include/linux/mtd/nand.h | 35 +
2 files changed, 100 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index e21fd3f3e08f..07f075afce49 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3779,7 +3779,7 @@ static int nand_get_bits_per_cell(u8 cellinfo)
* chip. The rest of the parameters must be decoded according to generic or
* manufacturer-specific "extended ID" decoding patterns.
*/
-static void nand_decode_ext_id(struct nand_chip *chip)
+void nand_decode_ext_id(struct nand_chip *chip)
{
struct mtd_info *mtd = nand_to_mtd(chip);
int extid, id_len = chip->id.len;
@@ -3904,6 +3904,7 @@ static void nand_decode_ext_id(struct nand_chip *chip)
}
}
+EXPORT_SYMBOL_GPL(nand_decode_ext_id);
/*
* Old devices have chip data hardcoded in the device ID table. nand_decode_id
@@ -4008,6 +4009,53 @@ static bool find_full_id_nand(struct nand_chip *chip,
}
/*
+ * Manufacturer detection. Only used when the NAND is not ONFI or JEDEC
+ * compliant and does not have a full-id or legacy-id entry in the nand_ids
+ * table.
+ */
+static void nand_manufacturer_detect(struct nand_chip *chip)
+{
+ /*
+* Try manufacturer detection if available and use
+* nand_decode_ext_id() otherwise.
+*/
+ if (chip->manufacturer.desc && chip->manufacturer.desc->ops &&
+ chip->manufacturer.desc->ops->detect)
+ chip->manufacturer.desc->ops->detect(chip);
+ else
+ nand_decode_ext_id(chip);
+}
+
+/*
+ * Manufacturer initialization. This function is called for all NANDs including
+ * ONFI and JEDEC compliant ones.
+ * Manufacturer drivers should put all their specific initialization code in
+ * their ->init() hook.
+ */
+static int nand_manufacturer_init(struct nand_chip *chip)
+{
+ if (!chip->manufacturer.desc || !chip->manufacturer.desc->ops ||
+ !chip->manufacturer.desc->ops->init)
+ return 0;
+
+ return chip->manufacturer.desc->ops->init(chip);
+}
+
+/*
+ * Manufacturer cleanup. This function is called for all NANDs including
+ * ONFI and JEDEC compliant ones.
+ * Manufacturer drivers should put all their specific cleanup code in their
+ * ->cleanup() hook.
+ */
+static void nand_manufacturer_cleanup(struct nand_chip *chip)
+{
+ /* Release manufacturer private data */
+ if (chip->manufacturer.desc && chip->manufacturer.desc->ops &&
+ chip->manufacturer.desc->ops->cleanup)
+ chip->manufacturer.desc->ops->cleanup(chip);
+}
+
+/*
* Get the flash and manufacturer id and lookup if the type is supported.
*/
static int nand_detect(struct nand_chip *chip, struct nand_flash_dev *type)
@@ -4015,7 +4063,7 @@ static int nand_detect(struct nand_chip *chip, struct
nand_flash_dev *type)
const struct nand_manufacturer *manufacturer;
struct mtd_info *mtd = nand_to_mtd(chip);
int busw;
- int i;
+ int i, ret;
u8 *id_data = chip->id.data;
u8 maf_id, dev_id;
@@ -4056,6 +4104,10 @@ static int nand_detect(struct nand_chip *chip, struct
nand_flash_dev *type)
chip->id.len = nand_id_len(id_data, 8);
+ /* Try to identify manufacturer */
+ manufacturer = nand_get_manufacturer(maf_id);
+ chip->manufacturer.desc = manufacturer;
+
if (!type)
type = nand_flash_ids;
@@ -4102,12 +4154,11 @@ static int nand_detect(struct nand_chip *chip, struct
nand_flash_dev *type)
chip->chipsize = (uint64_t)type->chipsize << 20;
- if (!type->pagesize) {
- /* Decode parameters from extended ID */
- nand_decode_ext_id(chip);
- } else {
+ if (!type->pagesize)
+ nand_manufacturer_detect(chip);
+ else
nand_decode_id(chip, type);
- }
+
/* Get chip options */
chip->options |= type->options;
@@ -4119,9 +4170,6 @@ static int nand_detect(struct nand_chip *chip, struct
nand_flash_dev *type)
chip->options &= ~NAND_SAMSUNG_LP_OPTIONS;
ident_done:
- /* Try to identify manufacturer */
- manufacturer = nand_get_manufacturer(maf_id);
-
if (chip->options & NAND_BUSWIDTH_AUTO) {
WARN_ON(busw & NAND_BUSWIDTH_16);
nand_set_defaults(chip);
@@ -4162,6 +4210,10 @@ static int nand_detect(struct nand_chip *chip, struct
nand
Re: [PATCH] ACPI / OSL: Fix rcu synchronization logic
On Mon, Jan 09, 2017 at 05:56:09PM +0800, Lv Zheng wrote:
> The rcu synchronization logic is originally provided to protect
> apei_read()/apei_write() as in the APEI drivers, there is NMI event source
> requiring non spinlock based synchronization mechanism.
>
> After that, ACPI developers think FADT registers may also require same
> facility, so they moved the RCU stuffs to generic ACPI layer.
>
> So now non-task-context ACPI map lookup is only protected by RCU.
>
> This triggers problem as acpi_os_map_memory()/acpi_os_unmap_memory() can be
> used to map/unmap tables as long as to map/unmap ACPI registers. When it is
> used for the ACPI tables, the caller could invoke this very early. When it
> is invoked earlier than workqueue_init() and later than
> check_early_ioremp_leak(), invoking synchronize_rcu_expedited() can cause a
> kernel hang.
>
> Actually this facility is only used to protect non-task-context ACPI map
> lookup, and such mappings are only introduced by
> acpi_os_map_generic_address(). So before it is invoked, there is no need to
> invoke synchronize_rcu_expedited().
>
> Suggested-by: Huang Ying
> Signed-off-by: Lv Zheng
> Cc: Huang Ying
> Cc: Borislav Petkov
Whatever we end up applying, I'd like to have this thing tagged properly
- I didn't bisect for 2 days for nothing:
Reported-and-tested-by: Borislav Petkov
Also, below's the other patch, I think you should copy the detailed
explanation about what happens from its commit message so that we have
it somewhere.
Also, to your patch add:
Fixes: 174cc7187e6f ("ACPICA: Tables: Back port acpi_get_table_with_size() and
early_acpi_os_unmap_memory() from Linux kernel")
Link: https://lkml.kernel.org/r/4034dde8-ffc1-18e2-f40c-00cf37471...@intel.com
(I've added the link to the second mail in the thread because my first
one didn't end up on lkml due to attachment size, most likely).
> ---
> drivers/acpi/osl.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index a404ff4..3d93633 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -77,6 +77,7 @@ static int (*__acpi_os_prepare_extended_sleep)(u8
> sleep_state, u32 val_a,
> static bool acpi_os_initialized;
> unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
> bool acpi_permanent_mmap = false;
> +bool acpi_synchronize_rcu = false;
ERROR: do not initialise globals to false
#54: FILE: drivers/acpi/osl.c:80:
+bool acpi_synchronize_rcu = false;
> /*
> * This list of permanent mappings is for memory that may be accessed from
> @@ -378,7 +379,8 @@ static void acpi_os_drop_map_ref(struct acpi_ioremap *map)
> static void acpi_os_map_cleanup(struct acpi_ioremap *map)
> {
> if (!map->refcount) {
> - synchronize_rcu_expedited();
> + if (acpi_synchronize_rcu)
> + synchronize_rcu_expedited();
> acpi_unmap(map->phys, map->virt);
> kfree(map);
> }
> @@ -444,6 +446,7 @@ int acpi_os_map_generic_address(struct
> acpi_generic_address *gas)
> if (!virt)
> return -EIO;
>
> + acpi_synchronize_rcu = true;
> return 0;
> }
> EXPORT_SYMBOL(acpi_os_map_generic_address);
> --
---
From: Borislav Petkov
Date: Mon, 9 Jan 2017 10:54:21 +0100
Subject: [PATCH] iommu/amd: Comment out acpi_put_table() for now
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We're calling this too early and we land in RCU which is uninitialized
yet:
early_amd_iommu_init()
|-> acpi_put_table(ivrs_base);
|-> acpi_tb_put_table(table_desc);
|-> acpi_tb_invalidate_table(table_desc);
|-> acpi_tb_release_table(...)
|-> acpi_os_unmap_memory
|-> acpi_os_unmap_iomem
|-> acpi_os_map_cleanup
|-> synchronize_rcu_expedited <-- the kernel/rcu/tree_exp.h version with
CONFIG_PREEMPT_RCU=y
Now that function goes and sends IPIs, i.e., schedule_work() but this is
too early - we haven't even done workqueue_init().
Actually, from looking at the callstack, we do
kernel_init_freeable()->native_smp_prepare_cpus() and workqueue_init()
comes next.
So let's choose the lesser of two evils - leak a little ACPI memory -
instead of freezing early at boot. Took me a while to bisect this :-\
Signed-off-by: Borislav Petkov
Fixes: 6b11d1d67713 ("ACPI / osl: Remove
acpi_get_table_with_size()/early_acpi_os_unmap_memory() users")
Cc: Bob Moore
Cc: Jörg Rödel
Cc: Linux ACPI
Cc: Lv Zheng
Cc: "Paul E. McKenney"
Cc: "Rafael J. Wysocki"
Cc: "Rafael J. Wysocki"
---
drivers/iommu/amd_iommu_init.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 6799cf9713f7..b7c228002ec7 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2337,8 +2337,14 @@ static int __init early_amd_iommu_init(void)
out:
/* Don't leak any ACPI memory */
+
+ /*
+* Temporarily avoid doing that be
Re: usb:xhci: support disable usb2 LPM Remote Wakeup
On Mon, Dec 12, 2016 at 8:00 PM, Mathias Nyman wrote: > On 12.12.2016 06:00, Thang Q. Nguyen wrote: >> >> On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring wrote: >>> >>> On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote: From: Thang Nguyen As per USB 2.0 link power management addendum ECN, table 1-2, page 4, device or host initiated via resume signaling; device-initiated resumes can be optionally enabled/disabled by software. This patch adds support to control enabling the USB2 RWE feature via DT/ACPI attribute. Signed-off-by: Vu Nguyen Signed-off-by: Thang Nguyen --- Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + drivers/usb/host/xhci-plat.c | 3 +++ drivers/usb/host/xhci.c| 5 - drivers/usb/host/xhci.h| 1 + 4 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 966885c..9b4cd14 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -25,6 +25,7 @@ Required properties: Optional properties: - clocks: reference to a clock + - usb2-rwe-disable: disable USB2 LPM Remote Wakeup capable >>> >>> >>> Remote wakeup has been around since USB 1.0 days. Does this need to be >>> USB2 or XHCI specific? >> >> This is XHCI specific. Per XHCI specification 1.1, remote wakeup is >> optional for XHCI 1.0 and required for XHCI 1.1. This patch provides >> ability for software to disable RWE for USB2 in XHCI1.0 controller. > > > I think I understand what's going on. > > USB: > The good old USB2 suspend is called L2. Device enters it after 3ms if > there is no link activity. > If a device can remote wakeup (RWE) it's stated in the descriptor. RWE can > be turned on > of off using standard SET/CLEAR Fature requests > > The LPM L1 USB2 state again is entered with a LPM extended transaction to > avoid the > 3ms wait before powersaving. L1 state is exit can be done with a simialr RWE > as L2 resume. > The RWE from L1 can turned on/off using a bit in the LPM extended > transaction. > > XHCI: > > Specs say that if the device supports RWE we should enable it for LPM L1 > exit as well. > This is done by setting the RWE (LPM L1) bit in PORTPMSC register. This bit > only affect LPM L1 remote > wake. see 4.23.5.1.1.1 > > The issue might be that xhci driver never check if the device actually > supports RWE, we always > set the PORTPMSC RWE (for LPM L1) bit. Yes, we should check if device support Remote Wakeup to enable or disable RWE as noted in cases 1 (page 265) and 2 (page 266) from 4.23.5.1.1.1. > > How about checking something like udev->do_remote_wakeup and setting and > setting the bit > based on that. > > The function that you are changing, xhci_set_usb2_hardware_lpm() should > only be used if > host has Hardware LPM Cabaility bit (HLC) set for that USB2 port in the > USB 2.0 xHCI Supported Protocol Capability. > Host that don't supprt LPM won't have that set. See xhci 7.2.2.1.3.2 When hosts support Hardware LPM (HLC), any problem if we add a DT/ACPI attribute to support disable it (HLE=0)? > -Mathias > > > > > > >
Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code
On Thu, Jan 05, 2017 at 11:03:44AM -0800, Dave Hansen wrote: > My Thinkpad x260 doesn't like to be unplugged from its dock. I don't > think this is a new bug. It's happening on my distro's 4.4 kernel > as well. > > The actual oops is in device_del(). It appears to have been passed a > null 'struct device *'. > > There appears to have been a race _around_ here fixed in 1f7717552e. > I've looked for and tried to find the locking that prevents > drm_connector_unregister() from being called twice concurrently. I'm > unable to find anything. > > drm_dp_destroy_connector_work() has some locking that looks useful: > > mutex_lock(&mgr->destroy_connector_lock) > > but it's released before the offending call: > > mgr->cbs->destroy_connector(mgr, port->connector); > > which actually calls intel_dp_destroy_mst_connector(). I have no idea > if it's correct (and haven't even run it with lockdep), but the attached > patch does seem to fix my oopses. > > Any ideas? > > > Jan 5 10:22:32 ray kernel: [ 537.087042] BUG: unable to handle kernel > > NULL pointer dereference at 009e > > Jan 5 10:22:32 ray kernel: [ 537.087954] IP: device_del+0x19/0x330 > > Jan 5 10:22:32 ray kernel: [ 537.088860] PGD 0 > > Jan 5 10:22:32 ray kernel: [ 537.088860] > > Jan 5 10:22:32 ray kernel: [ 537.090578] Oops: [#1] SMP > > Jan 5 10:22:32 ray kernel: [ 537.091406] Modules linked in: ctr ccm > > ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat > > nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT > > nf_reject_ipv4 xt_CHECKSUM iptable_mangle xt_tcpudp bridge stp llc > > iptable_filter ip_tables ebtable_nat ebtables x_tables cmac rfcomm bnep > > dm_crypt arc4 iwlmvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek > > snd_hda_codec_generic iwlwifi intel_rapl snd_hda_intel iosf_mbi > > hid_logitech_hidpp snd_seq_midi cfg80211 x86_pkg_temp_thermal snd_hda_codec > > snd_seq_midi_event snd_hwdep btusb snd_rawmidi snd_hda_core btrtl coretemp > > snd_seq snd_pcm btbcm btintel joydev bluetooth ghash_clmulni_intel > > snd_timer shpchp thinkpad_acpi snd_seq_device nvram wmi snd soundcore > > mac_hid aesni_intel aes_x86_64 crypto_simd cryptd glue_helper kvm_intel > > Jan 5 10:22:32 ray kernel: [ 537.095222] kvm irqbypass hid_generic > > hid_logitech_dj usbhid hid > > Jan 5 10:22:32 ray kernel: [ 537.096272] CPU: 2 PID: 23 Comm: kworker/2:0 > > Tainted: GW 4.10.0-rc2 #47 > > Jan 5 10:22:32 ray kernel: [ 537.097263] Hardware name: LENOVO > > 20F5S7V800/20F5S7V800, BIOS R02ET50W (1.23 ) 09/20/2016 > > Jan 5 10:22:32 ray kernel: [ 537.098291] Workqueue: events > > drm_dp_destroy_connector_work > > Jan 5 10:22:32 ray kernel: [ 537.099328] task: 88040f2f1e00 > > task.stack: c9000198c000 > > Jan 5 10:22:32 ray kernel: [ 537.100335] RIP: 0010:device_del+0x19/0x330 > > Jan 5 10:22:32 ray kernel: [ 537.101340] RSP: 0018:c9000198fd58 > > EFLAGS: 00010282 > > Jan 5 10:22:32 ray kernel: [ 537.102361] RAX: RBX: > > fffe RCX: 88040c5191b0 > > Jan 5 10:22:32 ray kernel: [ 537.103418] RDX: 81cb6246 RSI: > > 0001 RDI: fffe > > Jan 5 10:22:32 ray kernel: [ 537.104473] RBP: c9000198fd90 R08: > > R09: 880421517780 > > Jan 5 10:22:32 ray kernel: [ 537.105574] R10: 007d0ce17c93 R11: > > 0001 R12: fffe > > Jan 5 10:22:32 ray kernel: [ 537.106636] R13: 88040ed36bd8 R14: > > 88040ed36788 R15: 88040c728810 > > Jan 5 10:22:32 ray kernel: [ 537.107728] FS: () > > GS:88042150() knlGS: > > Jan 5 10:22:32 ray kernel: [ 537.108812] CS: 0010 DS: ES: CR0: > > 80050033 > > Jan 5 10:22:32 ray kernel: [ 537.109937] CR2: 009e CR3: > > 000384894000 CR4: 003406e0 > > Jan 5 10:22:32 ray kernel: [ 537.111038] DR0: DR1: > > DR2: > > Jan 5 10:22:32 ray kernel: [ 537.112142] DR3: DR6: > > fffe0ff0 DR7: 0400 > > Jan 5 10:22:32 ray kernel: [ 537.113223] Call Trace: > > Jan 5 10:22:32 ray kernel: [ 537.114293] device_unregister+0x12/0x30 > > Jan 5 10:22:32 ray kernel: [ 537.115354] > > drm_sysfs_connector_remove+0x3b/0x50 > > Jan 5 10:22:32 ray kernel: [ 537.116391] > > drm_connector_unregister.part.8+0x27/0x40 > > Jan 5 10:22:32 ray kernel: [ 537.117433] > > drm_connector_unregister+0x14/0x20 > > Jan 5 10:22:32 ray kernel: [ 537.118478] > > intel_dp_destroy_mst_connector+0x1a/0x80 > > Jan 5 10:22:32 ray kernel: [ 537.119513] > > drm_dp_destroy_connector_work+0xa9/0x150 > > Jan 5 10:22:32 ray kernel: [ 537.120539] process_one_work+0x14b/0x430 > > Jan 5 10:22:32 ray kernel: [ 537.121568] worker_thread+0x12b/0x4a0 > > Jan 5 10:22:32 ray kernel: [ 537.122581] kthread+0x10c/0x140 > > Jan
Re: [PATCH] clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled
Of course.
W dniu 09.01.2017 o 10:58, Sudeep Holla pisze:
>
>
> On 07/01/17 00:44, Michał Zegan wrote:
>> seems the patch works as intended.
>>
>
> So, can we take this as
> Tested-by: Michał Zegan ?
>
>> W dniu 06.01.2017 o 13:34, Sudeep Holla pisze:
>>> Currently we add the virtual cpufreq device unconditionally even when
>>> the SCPI DVFS clock provider node is disabled. This will cause cpufreq
>>> driver to throw errors when it gets initailised on boot/modprobe and
>>> also when the CPUs are hot-plugged back in.
>>>
>>> This patch fixes the issue by adding the virtual cpufreq device only if
>>> the SCPI DVFS clock provider is available and registered.
>>>
>>> Fixes: 9490f01e2471 ("clk: scpi: add support for cpufreq virtual device")
>>> Reported-by: Michał Zegan
>>> Cc: Neil Armstrong
>>> Cc: Michael Turquette
>>> Cc: Stephen Boyd
>>> Signed-off-by: Sudeep Holla
>
signature.asc
Description: OpenPGP digital signature
Re: [GIT PULL] efi: Pass secure boot mode to kernel
On Thu, 05 Jan, at 02:41:09PM, David Howells wrote: > Matt Fleming wrote: > > > > Is it too late to request this for the upcoming merge window? > > > > For something as non-trivial as this, yes, it's too late. We generally > > close the EFI tree window for new features around -rc5 time. > > Can I request that it be pulled now? Are you going to update efi/core? Sorry for the delay David. I've just returned from annual leave and I'll take a look at this series this week.
Re: __GFP_REPEAT usage in fq_alloc_node
On Fri 06-01-17 17:19:44, Michal Hocko wrote:
[...]
> From 8eadf8774daecdd6c4de37339216282a16920458 Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Fri, 6 Jan 2017 17:03:31 +0100
> Subject: [PATCH] net: use kvmalloc rather than open coded variant
>
> fq_alloc_node, alloc_netdev_mqs and netif_alloc* open code kmalloc
> with vmalloc fallback. Use the kvmalloc variant instead. Keep the
> __GFP_REPEAT flag based on explanation from
> Eric:
> "
> At the time, tests on the hardware I had in my labs showed that
> vmalloc() could deliver pages spread all over the memory and that was a
> small penalty (once memory is fragmented enough, not at boot time)
> "
the changelog doesn't mention it but this, unlike other kvmalloc
conversions is not without functional changes. The kmalloc part
will be weaker than it is with the original code for !costly (<64kB)
requests, because we are enforcing __GFP_NORETRY to break out from the
page allocator which doesn't really fail such a small requests.
Now the question is what those code paths really prefer. Do they really
want to potentially loop in the page allocator and invoke the OOM killer
when the memory is short/fragmeted? I mean we can get into a situation
when no order-3 pages can be compacted and shooting the system down just
for that reason sounds quite dangerous to me.
So the main question is how hard should we try before falling back to
vmalloc here?
> Cc: Eric Dumazet
> Signed-off-by: Michal Hocko
> ---
> net/core/dev.c | 24 +---
> net/sched/sch_fq.c | 12 +---
> 2 files changed, 10 insertions(+), 26 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 56818f7eab2b..5cf2762387aa 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7111,12 +7111,10 @@ static int netif_alloc_rx_queues(struct net_device
> *dev)
>
> BUG_ON(count < 1);
>
> - rx = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
> - if (!rx) {
> - rx = vzalloc(sz);
> - if (!rx)
> - return -ENOMEM;
> - }
> + rx = kvzalloc(sz, GFP_KERNEL | __GFP_REPEAT);
> + if (!rx)
> + return -ENOMEM;
> +
> dev->_rx = rx;
>
> for (i = 0; i < count; i++)
> @@ -7153,12 +7151,10 @@ static int netif_alloc_netdev_queues(struct
> net_device *dev)
> if (count < 1 || count > 0x)
> return -EINVAL;
>
> - tx = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
> - if (!tx) {
> - tx = vzalloc(sz);
> - if (!tx)
> - return -ENOMEM;
> - }
> + tx = kvzalloc(sz, GFP_KERNEL | __GFP_REPEAT);
> + if (!tx)
> + return -ENOMEM;
> +
> dev->_tx = tx;
>
> netdev_for_each_tx_queue(dev, netdev_init_one_queue, NULL);
> @@ -7691,9 +7687,7 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv,
> const char *name,
> /* ensure 32-byte alignment of whole construct */
> alloc_size += NETDEV_ALIGN - 1;
>
> - p = kzalloc(alloc_size, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
> - if (!p)
> - p = vzalloc(alloc_size);
> + p = kvzalloc(alloc_size, GFP_KERNEL | __GFP_REPEAT);
> if (!p)
> return NULL;
>
> diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
> index a4f738ac7728..594f77d89f6c 100644
> --- a/net/sched/sch_fq.c
> +++ b/net/sched/sch_fq.c
> @@ -624,16 +624,6 @@ static void fq_rehash(struct fq_sched_data *q,
> q->stat_gc_flows += fcnt;
> }
>
> -static void *fq_alloc_node(size_t sz, int node)
> -{
> - void *ptr;
> -
> - ptr = kmalloc_node(sz, GFP_KERNEL | __GFP_REPEAT | __GFP_NOWARN, node);
> - if (!ptr)
> - ptr = vmalloc_node(sz, node);
> - return ptr;
> -}
> -
> static void fq_free(void *addr)
> {
> kvfree(addr);
> @@ -650,7 +640,7 @@ static int fq_resize(struct Qdisc *sch, u32 log)
> return 0;
>
> /* If XPS was setup, we can allocate memory on right NUMA node */
> - array = fq_alloc_node(sizeof(struct rb_root) << log,
> + array = kvmalloc_node(sizeof(struct rb_root) << log, GFP_KERNEL |
> __GFP_REPEAT,
> netdev_queue_numa_node_read(sch->dev_queue));
> if (!array)
> return -ENOMEM;
> --
> 2.11.0
>
> --
> Michal Hocko
> SUSE Labs
--
Michal Hocko
SUSE Labs
[PATCH v6 09/17] mtd: nand: Move Samsung specific init/detection logic in nand_samsung.c
Move Samsung specific initialization and detection logic into
nand_samsung.c. This is part of the "separate vendor specific code from
core" cleanup process.
Signed-off-by: Boris Brezillon
Acked-by: Richard Weinberger
---
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/nand_base.c| 52 ++-
drivers/mtd/nand/nand_ids.c | 4 +-
drivers/mtd/nand/nand_samsung.c | 92 +
include/linux/mtd/nand.h| 2 +
5 files changed, 101 insertions(+), 50 deletions(-)
create mode 100644 drivers/mtd/nand/nand_samsung.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index bfd5d12b9ade..d4b90b0f879e 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -61,3 +61,4 @@ obj-$(CONFIG_MTD_NAND_QCOM) += qcom_nandc.o
obj-$(CONFIG_MTD_NAND_MTK) += mtk_nand.o mtk_ecc.o
nand-objs := nand_base.o nand_bbt.o nand_timings.o nand_ids.o
+nand-objs += nand_samsung.o
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 07f075afce49..1c2253a0868c 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3792,48 +3792,13 @@ void nand_decode_ext_id(struct nand_chip *chip)
/*
* Field definitions are in the following datasheets:
* Old style (4,5 byte ID): Samsung K9GAG08U0M (p.32)
-* New Samsung (6 byte ID): Samsung K9GAG08U0F (p.44)
* Hynix MLC (6 byte ID): Hynix H27UBG8T2B (p.22)
*
* Check for ID length, non-zero 6th byte, cell type, and Hynix/Samsung
* ID to decide what to do.
*/
- if (id_len == 6 && id_data[0] == NAND_MFR_SAMSUNG &&
- !nand_is_slc(chip) && id_data[5] != 0x00) {
- /* Calc pagesize */
- mtd->writesize = 2048 << (extid & 0x03);
- extid >>= 2;
- /* Calc oobsize */
- switch (((extid >> 2) & 0x04) | (extid & 0x03)) {
- case 1:
- mtd->oobsize = 128;
- break;
- case 2:
- mtd->oobsize = 218;
- break;
- case 3:
- mtd->oobsize = 400;
- break;
- case 4:
- mtd->oobsize = 436;
- break;
- case 5:
- mtd->oobsize = 512;
- break;
- case 6:
- mtd->oobsize = 640;
- break;
- case 7:
- default: /* Other cases are "reserved" (unknown) */
- mtd->oobsize = 1024;
- break;
- }
- extid >>= 2;
- /* Calc blocksize */
- mtd->erasesize = (128 * 1024) <<
- (((extid >> 1) & 0x04) | (extid & 0x03));
- } else if (id_len == 6 && id_data[0] == NAND_MFR_HYNIX &&
- !nand_is_slc(chip)) {
+ if (id_len == 6 && id_data[0] == NAND_MFR_HYNIX &&
+ !nand_is_slc(chip)) {
unsigned int tmp;
/* Calc pagesize */
@@ -3961,13 +3926,10 @@ static void nand_decode_bbm_options(struct nand_chip
*chip)
* Micron devices with 2KiB pages and on SLC Samsung, Hynix, Toshiba,
* AMD/Spansion, and Macronix. All others scan only the first page.
*/
- if (!nand_is_slc(chip) &&
- (maf_id == NAND_MFR_SAMSUNG ||
-maf_id == NAND_MFR_HYNIX))
+ if (!nand_is_slc(chip) && maf_id == NAND_MFR_HYNIX)
chip->bbt_options |= NAND_BBT_SCANLASTPAGE;
else if ((nand_is_slc(chip) &&
- (maf_id == NAND_MFR_SAMSUNG ||
-maf_id == NAND_MFR_HYNIX ||
+ (maf_id == NAND_MFR_HYNIX ||
maf_id == NAND_MFR_TOSHIBA ||
maf_id == NAND_MFR_AMD ||
maf_id == NAND_MFR_MACRONIX)) ||
@@ -4162,12 +4124,6 @@ static int nand_detect(struct nand_chip *chip, struct
nand_flash_dev *type)
/* Get chip options */
chip->options |= type->options;
- /*
-* Check if chip is not a Samsung device. Do not clear the
-* options for chips which do not have an extended id.
-*/
- if (maf_id != NAND_MFR_SAMSUNG && !type->pagesize)
- chip->options &= ~NAND_SAMSUNG_LP_OPTIONS;
ident_done:
if (chip->options & NAND_BUSWIDTH_AUTO) {
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 0c5589bb4624..9209054310cf 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -10,7 +10,7 @@
#include
#include
-#define LP_OPTIONS NAND_SAMSUNG_LP_OPTIONS
+#define LP_OPTIONS 0
#define LP_OPTIONS16 (LP_OPTIONS | NAND_BU
[PATCH] drm/i915: Flush untouched framebuffers before display on !llc
On a non-llc system, the objects are created with .cache_level =
CACHE_NONE and so the transition to uncached for scanout is a no-op.
However, if the object was never written to, it will still be in the CPU
domain (having been zeroed out by shmemfs). Those cachelines need to be
flushed prior to display.
Reported-by: Vito Caputo
Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning
the scanout")
Signed-off-by: Chris Wilson
Cc: # v4.10-rc1+
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 76689b59fc90..e64d0ea6113d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2327,6 +2327,7 @@ static void i915_sg_trim(struct sg_table *orig_st)
if (sg_alloc_table(&new_st, orig_st->nents, GFP_KERNEL | __GFP_NOWARN))
return;
+ new_st->orig_nents = orig_st->orig_nents; /* XXX lies for
new_sg = new_st.sgl;
for_each_sg(orig_st->sgl, sg, orig_st->nents, i) {
sg_set_page(new_sg, sg_page(sg), sg->length, 0);
@@ -3514,7 +3515,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
/* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
- if (obj->cache_dirty) {
+ if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) {
i915_gem_clflush_object(obj, true);
intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
}
--
2.11.0
Re: [PATCH 4/8] [media] videobuf-dma-sg: Adjust 24 checks for null values
On Mon, Dec 26, 2016 at 09:48:19PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 26 Dec 2016 20:30:19 +0100 > > Convert comparisons with the preprocessor symbol "NULL" or the value "0" > to condition checks without it. Generally lengths are numbers and not booleans so "len == 0" is ok. Checkpatch doesn't complain about that. regards, dan carpenter
Re: [PATCH v7 1/3] gpio: exar: add gpio for exar cards
On Sun, Jan 8, 2017 at 12:57 AM, Sudip Mukherjee
wrote:
> Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which
> can be controlled using gpio interface.
>
> Add the gpio specific code.
>
> Signed-off-by: Sudip Mukherjee
Will I be able to merge this independently to the GPIO trees
once we are done with review? (Looks like so...)
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
Is this really useful?
> +#include
> +#include
No use:
#include
ONLY
> +static LIST_HEAD(exar_list);
> +static DEFINE_MUTEX(exar_list_mtx);
> +DEFINE_IDA(ida_index);
What is this? A local list? I can understand the IDA index but in
general, follow the state container pattern instead:
Documentation/driver-model/design-patterns.txt
> +#define to_exar_chip(n) container_of(n, struct exar_gpio_chip, gpio_chip)
Don't do this, use
gpiochip_get_data()
> +static inline unsigned int read_exar_reg(struct exar_gpio_chip *chip,
> +int offset)
> +{
> + dev_dbg(chip->gpio_chip.parent, "regs=%p offset=%x\n",
> + chip->regs, offset);
> +
> + return readb(chip->regs + offset);
> +}
> +
> +static inline void write_exar_reg(struct exar_gpio_chip *chip, int offset,
> + int value)
> +{
> + dev_dbg(chip->gpio_chip.parent,
> + "regs=%p value=%x offset=%x\n", chip->regs, value,
> + offset);
> + writeb(value, chip->regs + offset);
> +}
I don't see why these need their own accessor functions, just inline
the readb()/writeb() calls.
> +static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
> + unsigned int offset)
> +{
> + struct exar_gpio_chip *exar_gpio = to_exar_chip(chip);
So just:
struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
> + int temp;
> +
> + mutex_lock(&exar_gpio->lock);
> + temp = read_exar_reg(exar_gpio, reg);
> + temp &= ~(1 << offset);
> + temp |= val << offset;
Use:
#include
temp &= BIT(offset);
if (val)
temp |= BIT(offset);
> +static int exar_get(struct gpio_chip *chip, unsigned int reg)
> +{
> + struct exar_gpio_chip *exar_gpio = to_exar_chip(chip);
> + int value;
> +
> + mutex_lock(&exar_gpio->lock);
> + value = read_exar_reg(exar_gpio, reg);
> + mutex_unlock(&exar_gpio->lock);
> +
> + return value;
Please use:
return !!value;
To clamp to bool.
> +static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
> +{
> + int val;
> +
> + if (offset < 8)
> + val = exar_get(chip, EXAR_OFFSET_MPIOSEL_LO) >> offset;
> + else
> + val = exar_get(chip, EXAR_OFFSET_MPIOSEL_HI) >>
> + (offset - 8);
> +
> + return val & 0x01;
Just
return !!val;
or something.
> +static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
> +{
> + int val;
> +
> + if (offset < 8)
> + val = exar_get(chip, EXAR_OFFSET_MPIOLVL_LO) >> offset;
> + else
> + val = exar_get(chip, EXAR_OFFSET_MPIOLVL_HI) >>
> + (offset - 8);
> + return val & 0x01;
> +}
Dito.
> +static int gpio_exar_probe(struct platform_device *pdev)
> +{
> + struct pci_dev *dev = platform_get_drvdata(pdev);
> + struct exar_gpio_chip *exar_gpio;
> + void __iomem *p;
> + int index = 1;
> + int ret;
> +
> + if (dev->vendor != PCI_VENDOR_ID_EXAR)
> + return -ENODEV;
> +
> + p = pci_ioremap_bar(dev, 0);
> + if (!p)
> + return -ENOMEM;
> +
> + exar_gpio = devm_kzalloc(&dev->dev, sizeof(*exar_gpio), GFP_KERNEL);
> + if (!exar_gpio)
> + return -ENOMEM;
> +
> + mutex_init(&exar_gpio->lock);
> + INIT_LIST_HEAD(&exar_gpio->list);
> +
> + index = ida_simple_get(&ida_index, 0, 0, GFP_KERNEL);
> + mutex_lock(&exar_list_mtx);
This looks overkill.
> + sprintf(exar_gpio->name, "exar_gpio%d", index);
> + exar_gpio->gpio_chip.label = exar_gpio->name;
> + exar_gpio->gpio_chip.parent = &dev->dev;
> + exar_gpio->gpio_chip.direction_output = exar_direction_output;
> + exar_gpio->gpio_chip.direction_input = exar_direction_input;
> + exar_gpio->gpio_chip.get_direction = exar_get_direction;
> + exar_gpio->gpio_chip.get = exar_get_value;
> + exar_gpio->gpio_chip.set = exar_set_value;
> + exar_gpio->gpio_chip.base = -1;
> + exar_gpio->gpio_chip.ngpio = 16;
> + exar_gpio->regs = p;
> + exar_gpio->index = index;
> + exar_gpio->pcidev = dev;
> +
> + ret = gpiochip_add(&exar_gpio->gpio_chip);
Use devm_gpiochip_add_data(dev, &exar_gpio->gpio_chip, exar_gpio)
So you can later use gpiochip_get_data()
> +static int gpio_exar_remove(struct platform_device *pdev)
> +{
> + struct exar_gpio_chip *exar_gpio, *exar_temp;
> + struct pci_dev
[PATCH v6 12/17] mtd: nand: Move Micron specific init logic in nand_micron.c
Move Micron specific initialization logic into nand_micron.c. This is
part of the "separate vendor specific code from core" cleanup process.
Signed-off-by: Boris Brezillon
Acked-by: Richard Weinberger
---
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/nand_base.c | 32 +---
drivers/mtd/nand/nand_ids.c| 2 +-
drivers/mtd/nand/nand_micron.c | 86 ++
include/linux/mtd/nand.h | 21 +--
5 files changed, 91 insertions(+), 51 deletions(-)
create mode 100644 drivers/mtd/nand/nand_micron.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 7c059822f479..11d743155810 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -62,5 +62,6 @@ obj-$(CONFIG_MTD_NAND_MTK)+= mtk_nand.o mtk_ecc.o
nand-objs := nand_base.o nand_bbt.o nand_timings.o nand_ids.o
nand-objs += nand_hynix.o
+nand-objs += nand_micron.o
nand-objs += nand_samsung.o
nand-objs += nand_toshiba.o
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 02bffe47c311..fe05191c952a 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3500,30 +3500,6 @@ static int nand_flash_detect_ext_param_page(struct
nand_chip *chip,
return ret;
}
-static int nand_setup_read_retry_micron(struct mtd_info *mtd, int retry_mode)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- uint8_t feature[ONFI_SUBFEATURE_PARAM_LEN] = {retry_mode};
-
- return chip->onfi_set_features(mtd, chip, ONFI_FEATURE_ADDR_READ_RETRY,
- feature);
-}
-
-/*
- * Configure chip properties from Micron vendor-specific ONFI table
- */
-static void nand_onfi_detect_micron(struct nand_chip *chip,
- struct nand_onfi_params *p)
-{
- struct nand_onfi_vendor_micron *micron = (void *)p->vendor;
-
- if (le16_to_cpu(p->vendor_revision) < 1)
- return;
-
- chip->read_retries = micron->read_retry_options;
- chip->setup_read_retry = nand_setup_read_retry_micron;
-}
-
/*
* Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise.
*/
@@ -3620,9 +3596,6 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
pr_warn("Could not retrieve ONFI ECC requirements\n");
}
- if (p->jedec_id == NAND_MFR_MICRON)
- nand_onfi_detect_micron(chip, p);
-
return 1;
}
@@ -3859,9 +3832,8 @@ static void nand_decode_bbm_options(struct nand_chip
*chip)
* Micron devices with 2KiB pages and on SLC Samsung, Hynix, Toshiba,
* AMD/Spansion, and Macronix. All others scan only the first page.
*/
- if ((nand_is_slc(chip) &&
-(maf_id == NAND_MFR_AMD || maf_id == NAND_MFR_MACRONIX)) ||
- (mtd->writesize == 2048 && maf_id == NAND_MFR_MICRON))
+ if (nand_is_slc(chip) &&
+ (maf_id == NAND_MFR_AMD || maf_id == NAND_MFR_MACRONIX))
chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
}
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 7adab884038e..7dd339c15d3e 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -178,7 +178,7 @@ static const struct nand_manufacturer nand_manufacturers[]
= {
{NAND_MFR_RENESAS, "Renesas"},
{NAND_MFR_STMICRO, "ST Micro"},
{NAND_MFR_HYNIX, "Hynix", &hynix_nand_manuf_ops},
- {NAND_MFR_MICRON, "Micron"},
+ {NAND_MFR_MICRON, "Micron", µn_nand_manuf_ops},
{NAND_MFR_AMD, "AMD/Spansion"},
{NAND_MFR_MACRONIX, "Macronix"},
{NAND_MFR_EON, "Eon"},
diff --git a/drivers/mtd/nand/nand_micron.c b/drivers/mtd/nand/nand_micron.c
new file mode 100644
index ..877011069251
--- /dev/null
+++ b/drivers/mtd/nand/nand_micron.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2017 Free Electrons
+ * Copyright (C) 2017 NextThing Co
+ *
+ * Author: Boris Brezillon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+
+struct nand_onfi_vendor_micron {
+ u8 two_plane_read;
+ u8 read_cache;
+ u8 read_unique_id;
+ u8 dq_imped;
+ u8 dq_imped_num_settings;
+ u8 dq_imped_feat_addr;
+ u8 rb_pulldown_strength;
+ u8 rb_pulldown_strength_feat_addr;
+ u8 rb_pulldown_strength_num_settings;
+ u8 otp_mode;
+ u8 otp_page_start;
+ u8 otp_data_prot_addr;
+ u8 otp_num_pages;
+ u8 otp_feat_addr;
+ u8 read_retry_options;
+ u8 reserved[72];
+
Re: [PATCH v4] rfkill: Add rfkill-any LED trigger
> > Looks better, but > > > > > +static struct work_struct rfkill_any_work; > > > > At least on module exit you need to cancel this work. > > It is cancelled in rfkill_any_led_trigger_unregister(). It seemed > fitting to do it this way as rfkill_any_work is initialized in > rfkill_any_led_trigger_register(). And if CONFIG_RFKILL_LEDS=n, > rfkill_any_work is neither initialized nor scheduled, so we should be > good as well. Am I missing something? No, I just missed that, sorry. Applied the patch now. johannes
Build regressions/improvements in v4.10-rc3
Below is the list of build error/warning regressions/improvements in
v4.10-rc3[1] compared to v4.9[2].
Summarized:
- build errors: +1/-8
- build warnings: +1292/-954
JFYI, when comparing v4.10-rc3[1] to v4.10-rc2[3], the summaries are:
- build errors: +1/-3
- build warnings: +426/-677
Happy fixing! ;-)
Thanks to the linux-next team for providing the build service.
[1]
http://kisskb.ellerman.id.au/kisskb/head/a121103c922847ba5010819a3f250f1f7fc84ab8/
(all 267 configs)
[2]
http://kisskb.ellerman.id.au/kisskb/head/69973b830859bc6529a7a0468ba0d80ee5117826/
(all 267 configs)
[3]
http://kisskb.ellerman.id.au/kisskb/head/0c744ea4f77d72b3dcebb7a8f2684633ec79be88/
(all 267 configs)
*** ERRORS ***
1 error regressions:
+ error: rtnetlink.c: relocation truncated to fit: R_AVR32_11H_PCREL against
`.text'+217b4: => (.text+0x21bc4)
8 error improvements:
- /home/kisskb/slave/src/drivers/usb/serial/cp210x.c: error: passing argument
2 of 'cp210x_get_termios_port' from incompatible pointer type
[-Werror=incompatible-pointer-types]: 719:4 =>
- /home/kisskb/slave/tmp/ccZFNWVe.s: Error: pcrel too far BFD_RELOC_BFIN_10:
912 =>
- error: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!: N/A =>
- error: /home/kisskb/slave/src/drivers/block/loop.c: undefined reference to
`__ucmpdi2': .text+0x2ef6c), .text+0x2ef78), .text+0x3) =>
- error: /home/kisskb/slave/src/drivers/scsi/sd.c: undefined reference to
`__ucmpdi2': .text+0x38804), .text+0x36dc0) =>
- error: page_ext.c: undefined reference to `__end_data_ro_after_init':
.text+0x19860) =>
- error: page_ext.c: undefined reference to `__start_data_ro_after_init':
.text+0x1985c) =>
- error: trace.c: relocation truncated to fit: R_PPC64_REL24 against symbol
`.trace_event_buffer_reserve' defined in .text section in kernel/built-in.o:
(.text+0x1ff8050), (.text+0x1ff8b7c), (.text+0x1ff834c), (.text+0x1ff8150),
(.text+0x1ff892c), (.text+0x1ff86e0), (.text+0x1ff85d0), (.text+0x1ff84d0),
(.text+0x1ff7ee4), (.text+0x1ff8240) =>
*** WARNINGS ***
1292 warning regressions:
[Deleted 1054 lines about "warning: -ffunction-sections disabled; it makes
profiling impossible [enabled by default]" on parisc-allmodconfig]
+ /home/kisskb/slave/src/arch/x86/kernel/vm86_32.c: warning: unused variable
'vma' [-Wunused-variable]: => 180:26
+ /home/kisskb/slave/src/crypto/cbc.c: warning: 'crypto_cbc_decrypt' uses
dynamic stack allocation [enabled by default]: => 78:1
+ /home/kisskb/slave/src/crypto/cryptd.c: warning: 'cryptd_skcipher_decrypt'
uses dynamic stack allocation [enabled by default]: => 532:1
+ /home/kisskb/slave/src/crypto/cryptd.c: warning: 'cryptd_skcipher_encrypt'
uses dynamic stack allocation [enabled by default]: => 504:1
+ /home/kisskb/slave/src/drivers/ata/libata-scsi.c: warning:
'ncq_prio_enable' may be used uninitialized in this function: => 281
+ /home/kisskb/slave/src/drivers/char/tpm/tpm.h: warning: 'blob_handle' may
be used uninitialized in this function [-Wuninitialized]: => 480:18
+ /home/kisskb/slave/src/drivers/char/tpm/tpm2-cmd.c: warning: 'blob_handle'
may be used uninitialized in this function [-Wuninitialized]: => 655:20
+ /home/kisskb/slave/src/drivers/crypto/chelsio/chcr_algo.c: warning:
'chcr_ahash_setkey' uses dynamic stack allocation [enabled by default]: =>
1216:1
+ /home/kisskb/slave/src/drivers/crypto/chelsio/chcr_algo.c: warning:
'chcr_authenc_setkey' uses dynamic stack allocation [enabled by default]: =>
2354:1
+ /home/kisskb/slave/src/drivers/crypto/chelsio/chcr_algo.c: warning:
'chcr_copy_assoc.isra.19' uses dynamic stack allocation [enabled by default]:
=> 1334:1
+ /home/kisskb/slave/src/drivers/gpu/drm/drm_dp_dual_mode_helper.c: warning:
format '%zd' expects argument of type 'signed size_t', but argument 5 has type
'ssize_t {aka int}' [-Wformat=]: => 220:16
+ /home/kisskb/slave/src/drivers/gpu/drm/drm_dp_dual_mode_helper.c: warning:
format '%zd' expects argument of type 'signed size_t', but argument 6 has type
'ssize_t {aka int}' [-Wformat=]: => 201:16
+ /home/kisskb/slave/src/drivers/gpu/drm/drm_dp_helper.c: warning: format
'%zu' expects argument of type 'size_t', but argument 4 has type 'unsigned int'
[-Wformat=]: => 861:18
+ /home/kisskb/slave/src/drivers/gpu/drm/drm_dp_helper.c: warning: format
'%zu' expects argument of type 'size_t', but argument 5 has type 'unsigned int'
[-Wformat=]: => 809:18, 776:18
+ /home/kisskb/slave/src/drivers/gpu/drm/drm_gem_cma_helper.c: warning:
format '%zu' expects argument of type 'size_t', but argument 3 has type
'unsigned int' [-Wformat=]: => 115:60
+ /home/kisskb/slave/src/drivers/gpu/drm/drm_gem_cma_helper.c: warning:
format '%zu' expects argument of type 'size_t', but argument 5 has type
'unsigned int' [-Wformat=]: => 457:18
+ /home/kisskb/slave/src/drivers/gpu/drm/drm_info.c: warning: format '%zd'
expects argument of type 'signed size_t', but argument 4 has type 'size_t {aka
unsigned i
Re: [GIT PULL] efi: Pass secure boot mode to kernel
Matt Fleming wrote: > > Can I request that it be pulled now? Are you going to update efi/core? > > Sorry for the delay David. I've just returned from annual leave and > I'll take a look at this series this week. That's okay, thanks! David
Re: [PATCH v8 1/3] gpio: exar: add gpio for exar cards
On Sun, Jan 8, 2017 at 11:32 PM, Sudip Mukherjee wrote: > From: Sudip Mukherjee > > Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which > can be controlled using gpio interface. > > Add the gpio specific code. > > Signed-off-by: Sudip Mukherjee My comments on the previous version seem to apply to this version too. Yours, Linus Walleij
Re: [PATCH v3 4/9] arm64: cpufeature: Document the rules of safe value for features
On 06/01/17 12:30, Catalin Marinas wrote: On Wed, Jan 04, 2017 at 05:49:02PM +, Suzuki K. Poulose wrote: --- a/arch/arm64/include/asm/cpufeature.h +++ b/arch/arm64/include/asm/cpufeature.h @@ -29,7 +29,21 @@ #include #include -/* CPU feature register tracking */ +/* + * CPU feature register tracking + * + * The safe value of a CPUID feature field is dependent on the implications + * of the values assigned to it by the architecture. Based on the relationship + * between the values, the features are classified into 3 types. + * + * a) LOWER_SAFE - The value 'n+1' indicates, value 'n' and some + *additional features. (where n >= 0). The smaller value (n) is + *considered safer in this case. + * b) HIGHER_SAFE - The value 'n+1' is safer than 'n' (for n>= 0). + * c) EXACT - If the values of the feature don't have any relationship, + *a predefined safe value is used. + */ I don't think this text fully describes what is actually compared. You could say something that the lowest value of all the CPUs is chosen for LOWER_SAFE, highest for HIGHER_SAFE and it is expected that all CPUs have the same value for a field when EXACT is specified. Ok. I have changed it as below : /* * CPU feature register tracking * * The safe value of a CPUID feature field is dependent on the implications * of the values assigned to it by the architecture. Based on the relationship * between the values, the features are classified into 3 types - LOWER_SAFE, * HIGHER_SAFE and EXACT. * * The lowest value of all the CPUs is chosen for LOWER_SAFE and highest * for HIGHER_SAFE. It is expected that all CPUs have the same value for * a field when EXACT is specified, failing which, the safe value specified * in the table is chosen. */ Suzuki
Re: [PATCH v2 2/2] reset: make optional functions really optional
Hi Ramiro,
Am Dienstag, den 27.12.2016, 12:37 + schrieb Ramiro Oliveira:
> The optional functions weren't really optional so this patch makes them
> really optional.
Please add a bit of detail to the description. Since this changes the
API, you should mention that the reset_control_get_optional variants now
return NULL instead of an error if there is no matching reset phandle in
the device tree and that the reset_control_* functions accept NULL rstc
pointers.
> Signed-off-by: Ramiro Oliveira
> ---
> drivers/reset/core.c | 35 +--
> include/linux/reset.h | 45 ++---
> 2 files changed, 55 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> index 70023997d031..f933e9dfebc5 100644
> --- a/drivers/reset/core.c
> +++ b/drivers/reset/core.c
> @@ -135,9 +135,15 @@ EXPORT_SYMBOL_GPL(devm_reset_controller_register);
> * @rstc: reset controller
> *
> * Calling this on a shared reset controller is an error.
> + *
> + * If rstc is NULL it is an optional reset and the function will just
> + * return 0.
> */
> int reset_control_reset(struct reset_control *rstc)
> {
> + if (!rstc)
> + return 0;
> +
> if (WARN_ON(rstc->shared))
> return -EINVAL;
>
> @@ -158,9 +164,15 @@ EXPORT_SYMBOL_GPL(reset_control_reset);
> *
> * For shared reset controls a driver cannot expect the hw's registers and
> * internal state to be reset, but must be prepared for this to happen.
> + *
> + * If rstc is NULL it is an optional reset and the function will just
> + * return 0.
> */
> int reset_control_assert(struct reset_control *rstc)
> {
> + if (!rstc)
> + return 0;
> +
> if (!rstc->rcdev->ops->assert)
> return -ENOTSUPP;
>
> @@ -181,9 +193,15 @@ EXPORT_SYMBOL_GPL(reset_control_assert);
> * @rstc: reset controller
> *
> * After calling this function, the reset is guaranteed to be deasserted.
> + *
> + * If rstc is NULL it is an optional reset and the function will just
> + * return 0.
> */
> int reset_control_deassert(struct reset_control *rstc)
> {
> + if (!rstc)
> + return 0;
> +
> if (!rstc->rcdev->ops->deassert)
> return -ENOTSUPP;
>
> @@ -199,11 +217,14 @@ EXPORT_SYMBOL_GPL(reset_control_deassert);
> /**
> * reset_control_status - returns a negative errno if not supported, a
> * positive value if the reset line is asserted, or zero if the reset
> - * line is not asserted.
> + * line is not asserted or if the desc is NULL (optional reset).
> * @rstc: reset controller
> */
> int reset_control_status(struct reset_control *rstc)
> {
> + if (!rstc)
> + return 0;
> +
> if (rstc->rcdev->ops->status)
> return rstc->rcdev->ops->status(rstc->rcdev, rstc->id);
>
> @@ -258,7 +279,8 @@ static void __reset_control_put(struct reset_control
> *rstc)
> }
>
> struct reset_control *__of_reset_control_get(struct device_node *node,
> - const char *id, int index, bool shared)
> + const char *id, int index, bool shared,
> + bool optional)
> {
> struct reset_control *rstc;
> struct reset_controller_dev *r, *rcdev;
> @@ -273,13 +295,13 @@ struct reset_control *__of_reset_control_get(struct
> device_node *node,
> index = of_property_match_string(node,
>"reset-names", id);
> if (index < 0)
> - return ERR_PTR(-ENOENT);
> + return optional ? NULL : ERR_PTR(-ENOENT);
of_property_match_string can return -EINVAL, -ENODATA, or -EILSEQ.
I think -EILSEQ should still be returned.
> }
>
> ret = of_parse_phandle_with_args(node, "resets", "#reset-cells",
>index, &args);
> if (ret)
> - return ERR_PTR(ret);
> + return optional ? NULL : ERR_PTR(ret);
of_parse_phandle_with_args can return -ENOENT or -EINVAL.
I think -EINVAL should still be returned.
>
> mutex_lock(&reset_list_mutex);
> rcdev = NULL;
> @@ -338,7 +360,8 @@ static void devm_reset_control_release(struct device
> *dev, void *res)
> }
>
> struct reset_control *__devm_reset_control_get(struct device *dev,
> - const char *id, int index, bool shared)
> + const char *id, int index, bool shared,
> + bool optional)
> {
> struct reset_control **ptr, *rstc;
>
> @@ -348,7 +371,7 @@ struct reset_control *__devm_reset_control_get(struct
> device *dev,
> return ERR_PTR(-ENOMEM);
>
> rstc = __of_reset_control_get(dev ? dev->of_node : NULL,
> - id, index, shared);
> + id, index, shared, optiona
[PATCH] stable-fixup: hotplug: fix unused function warning
The backport of upstream commit 777c6e0daebb ("hotplug: Make
register and unregister notifier API symmetric") to linux-4.4.y
introduced a harmless warning in 'allnoconfig' builds as spotted by
kernelci.org:
kernel/cpu.c:226:13: warning: 'cpu_notify_nofail' defined but not used
[-Wunused-function]
So far, this is the only stable tree that is affected, as linux-4.6 and
higher contain commit 984581728eb4 ("cpu/hotplug: Split out cpu down functions")
that makes the function used in all configurations, while older longterm
releases so far don't seem to have a backport of 777c6e0daebb.
The fix for the warning is trivial: move the unused function back
into the #ifdef section where it was before.
Link: https://kernelci.org/build/id/586fcacb59b514049ef6c3aa/logs/
Fixes: 1c0f4e0ebb79 ("hotplug: Make register and unregister notifier API
symmetric") in v4.4.y
Signed-off-by: Arnd Bergmann
---
kernel/cpu.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index cd6d1258554e..40d20bf5de28 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -223,10 +223,6 @@ static int cpu_notify(unsigned long val, void *v)
return __cpu_notify(val, v, -1, NULL);
}
-static void cpu_notify_nofail(unsigned long val, void *v)
-{
- BUG_ON(cpu_notify(val, v));
-}
EXPORT_SYMBOL(register_cpu_notifier);
EXPORT_SYMBOL(__register_cpu_notifier);
@@ -245,6 +241,11 @@ void __unregister_cpu_notifier(struct notifier_block *nb)
EXPORT_SYMBOL(__unregister_cpu_notifier);
#ifdef CONFIG_HOTPLUG_CPU
+static void cpu_notify_nofail(unsigned long val, void *v)
+{
+ BUG_ON(cpu_notify(val, v));
+}
+
/**
* clear_tasks_mm_cpumask - Safely clear tasks' mm_cpumask for a CPU
* @cpu: a CPU id
--
2.9.0
Re: [PATCH V6 2/7] perf/amd/iommu: Modify functions to query max banks and counters
On 1/4/17 21:48, Joerg Roedel wrote: On Fri, Dec 23, 2016 at 08:38:45PM +0700, Suravee Suthikulpanit wrote: --- a/arch/x86/events/amd/iommu.h +++ b/arch/x86/events/amd/iommu.h @@ -24,15 +24,12 @@ #define PC_MAX_SPEC_BNKS 64 #define PC_MAX_SPEC_CNTRS 16 -/* iommu pc reg masks*/ -#define IOMMU_BASE_DEVID 0x - /* amd_iommu_init.c external support functions */ extern bool amd_iommu_pc_supported(void); -extern u8 amd_iommu_pc_get_max_banks(u16 devid); +extern u8 amd_iommu_pc_get_max_banks(uint devid); -extern u8 amd_iommu_pc_get_max_counters(u16 devid); +extern u8 amd_iommu_pc_get_max_counters(uint devid); The parameters are now iommu-indexes and not device-ids anymore. You should reflect that in the prototypes here too. Ahh.. thanks for pointing out. I missed this part. diff --git a/drivers/iommu/amd_iommu_proto.h b/drivers/iommu/amd_iommu_proto.h index 7eb60c1..1f10b3f 100644 --- a/drivers/iommu/amd_iommu_proto.h +++ b/drivers/iommu/amd_iommu_proto.h @@ -58,8 +58,8 @@ extern int amd_iommu_domain_set_gcr3(struct iommu_domain *dom, int pasid, /* IOMMU Performance Counter functions */ extern bool amd_iommu_pc_supported(void); -extern u8 amd_iommu_pc_get_max_banks(u16 devid); -extern u8 amd_iommu_pc_get_max_counters(u16 devid); +extern u8 amd_iommu_pc_get_max_banks(uint devid); +extern u8 amd_iommu_pc_get_max_counters(uint devid); Same here, and why do you need to declare the prototypes in two different header files? Hm.. actually good point. I will remove the unnecessary function declarations in the amd_iommu_proto.h. Thanks, Suravee
Re: [PATCH] iio: misc: add a generic regulator driver
On Thu, Jan 5, 2017 at 1:00 PM, Mark Brown wrote: > The system itself is controlling > a power line, it knows nothing about what's connected. It seems like > this is coming up often enough that someone should probably just write > an external system control binding, also tying in things like references > to the console and so on. That sounds pretty helpful for these usecases. Yours, Linus Walleij
[PATCH v6 10/17] mtd: nand: Move Hynix specific init/detection logic in nand_hynix.c
Move Hynix specific initialization and detection logic into
nand_hynix.c. This is part of the "separate vendor specific code from
core" cleanup process.
Signed-off-by: Boris Brezillon
Acked-by: Richard Weinberger
---
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/nand_base.c | 114 +++---
drivers/mtd/nand/nand_hynix.c | 84 +++
drivers/mtd/nand/nand_ids.c | 2 +-
include/linux/mtd/nand.h | 1 +
5 files changed, 115 insertions(+), 87 deletions(-)
create mode 100644 drivers/mtd/nand/nand_hynix.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index d4b90b0f879e..ddb2670d9767 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -61,4 +61,5 @@ obj-$(CONFIG_MTD_NAND_QCOM) += qcom_nandc.o
obj-$(CONFIG_MTD_NAND_MTK) += mtk_nand.o mtk_ecc.o
nand-objs := nand_base.o nand_bbt.o nand_timings.o nand_ids.o
+nand-objs += nand_hynix.o
nand-objs += nand_samsung.o
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1c2253a0868c..3b15a1cd39bc 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3789,85 +3789,32 @@ void nand_decode_ext_id(struct nand_chip *chip)
/* The 4th id byte is the important one */
extid = id_data[3];
+ /* Calc pagesize */
+ mtd->writesize = 1024 << (extid & 0x03);
+ extid >>= 2;
+ /* Calc oobsize */
+ mtd->oobsize = (8 << (extid & 0x01)) * (mtd->writesize >> 9);
+ extid >>= 2;
+ /* Calc blocksize. Blocksize is multiples of 64KiB */
+ mtd->erasesize = (64 * 1024) << (extid & 0x03);
+ extid >>= 2;
+ /* Get buswidth information */
+ if (extid & 0x1)
+ chip->options |= NAND_BUSWIDTH_16;
+
/*
-* Field definitions are in the following datasheets:
-* Old style (4,5 byte ID): Samsung K9GAG08U0M (p.32)
-* Hynix MLC (6 byte ID): Hynix H27UBG8T2B (p.22)
-*
-* Check for ID length, non-zero 6th byte, cell type, and Hynix/Samsung
-* ID to decide what to do.
+* Toshiba 24nm raw SLC (i.e., not BENAND) have 32B OOB per
+* 512B page. For Toshiba SLC, we decode the 5th/6th byte as
+* follows:
+* - ID byte 6, bits[2:0]: 100b -> 43nm, 101b -> 32nm,
+* 110b -> 24nm
+* - ID byte 5, bit[7]:1 -> BENAND, 0 -> raw SLC
*/
- if (id_len == 6 && id_data[0] == NAND_MFR_HYNIX &&
- !nand_is_slc(chip)) {
- unsigned int tmp;
-
- /* Calc pagesize */
- mtd->writesize = 2048 << (extid & 0x03);
- extid >>= 2;
- /* Calc oobsize */
- switch (((extid >> 2) & 0x04) | (extid & 0x03)) {
- case 0:
- mtd->oobsize = 128;
- break;
- case 1:
- mtd->oobsize = 224;
- break;
- case 2:
- mtd->oobsize = 448;
- break;
- case 3:
- mtd->oobsize = 64;
- break;
- case 4:
- mtd->oobsize = 32;
- break;
- case 5:
- mtd->oobsize = 16;
- break;
- default:
- mtd->oobsize = 640;
- break;
- }
- extid >>= 2;
- /* Calc blocksize */
- tmp = ((extid >> 1) & 0x04) | (extid & 0x03);
- if (tmp < 0x03)
- mtd->erasesize = (128 * 1024) << tmp;
- else if (tmp == 0x03)
- mtd->erasesize = 768 * 1024;
- else
- mtd->erasesize = (64 * 1024) << tmp;
- } else {
- /* Calc pagesize */
- mtd->writesize = 1024 << (extid & 0x03);
- extid >>= 2;
- /* Calc oobsize */
- mtd->oobsize = (8 << (extid & 0x01)) *
- (mtd->writesize >> 9);
- extid >>= 2;
- /* Calc blocksize. Blocksize is multiples of 64KiB */
- mtd->erasesize = (64 * 1024) << (extid & 0x03);
- extid >>= 2;
- /* Get buswidth information */
- if (extid & 0x1)
- chip->options |= NAND_BUSWIDTH_16;
-
- /*
-* Toshiba 24nm raw SLC (i.e., not BENAND) have 32B OOB per
-* 512B page. For Toshiba SLC, we decode the 5th/6th byte as
-* follows:
-* - ID byte 6, bits[2:0]: 100b -> 43nm, 101b -> 32nm,
-* 110b -> 24nm
-* - ID byte 5, bit[7]:1 -> BENAND, 0 -> raw SLC
-*/
- if (id_len >
Re: [PATCH] drm/i915: Flush untouched framebuffers before display on !llc
On Mon, Jan 09, 2017 at 10:24:01AM +, Chris Wilson wrote:
> On a non-llc system, the objects are created with .cache_level =
> CACHE_NONE and so the transition to uncached for scanout is a no-op.
> However, if the object was never written to, it will still be in the CPU
> domain (having been zeroed out by shmemfs). Those cachelines need to be
> flushed prior to display.
>
> Reported-by: Vito Caputo
> Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning
> the scanout")
> Signed-off-by: Chris Wilson
> Cc: # v4.10-rc1+
> ---
> drivers/gpu/drm/i915/i915_gem.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 76689b59fc90..e64d0ea6113d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2327,6 +2327,7 @@ static void i915_sg_trim(struct sg_table *orig_st)
> if (sg_alloc_table(&new_st, orig_st->nents, GFP_KERNEL | __GFP_NOWARN))
> return;
>
> + new_st->orig_nents = orig_st->orig_nents; /* XXX lies for
Oops. Ignore this chunk!
> new_sg = new_st.sgl;
> for_each_sg(orig_st->sgl, sg, orig_st->nents, i) {
> sg_set_page(new_sg, sg_page(sg), sg->length, 0);
> @@ -3514,7 +3515,7 @@ i915_gem_object_pin_to_display_plane(struct
> drm_i915_gem_object *obj,
> vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
>
> /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
> - if (obj->cache_dirty) {
> + if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) {
> i915_gem_clflush_object(obj, true);
> intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
> }
> --
> 2.11.0
>
--
Chris Wilson, Intel Open Source Technology Centre
Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
Hi Rafael,
On Sun, Jan 08, 2017 at 03:20:20AM +0100, Rafael J. Wysocki wrote:
> ---
> drivers/iommu/amd_iommu_init.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-pm/drivers/iommu/amd_iommu_init.c
> ===
> --- linux-pm.orig/drivers/iommu/amd_iommu_init.c
> +++ linux-pm/drivers/iommu/amd_iommu_init.c
> @@ -2230,7 +2230,7 @@ static int __init early_amd_iommu_init(v
>*/
> ret = check_ivrs_checksum(ivrs_base);
> if (ret)
> - return ret;
> + goto out;
>
> amd_iommu_target_ivhd_type = get_highest_supported_ivhd_type(ivrs_base);
> DUMP_printk("Using IVHD type %#x\n", amd_iommu_target_ivhd_type);
Yeah, good catch. Can you send me a patch for this and I am going to
send the fix upstream asap.
Thanks,
Joerg
[tip:x86/apic] x86/apic: Implement set_state_oneshot_stopped() callback
Commit-ID: 914122c389d091a02f7b5476209af715e77ccb73
Gitweb: http://git.kernel.org/tip/914122c389d091a02f7b5476209af715e77ccb73
Author: Frederic Weisbecker
AuthorDate: Thu, 29 Dec 2016 17:45:49 +0100
Committer: Thomas Gleixner
CommitDate: Mon, 9 Jan 2017 11:48:42 +0100
x86/apic: Implement set_state_oneshot_stopped() callback
When clock_event_device::set_state_oneshot_stopped() is not implemented,
hrtimer_cancel() can't stop the clock when there is no more timer in
the queue. So the ghost of the freshly cancelled hrtimer haunts us back
later with an extra interrupt:
-0 [002] d..2 2248.557659: hrtimer_cancel:
hrtimer=88021fa92d80
-0 [002] d.h1 2249.303659: local_timer_entry: vector=239
So let's implement this missing callback for the lapic clock. This
consist in calling its set_state_shutdown() callback. There don't seem
to be a lighter way to stop the clock. Simply writing 0 to APIC_TMICT
won't be enough to stop the clock and avoid the extra interrupt, as
opposed to what is specified in the specs. We must also mask the
timer interrupt in the device.
Signed-off-by: Frederic Weisbecker
Cc: Borislav Petkov
Reviewed-by: Wanpeng Li
Reviewed-by: Viresh Kumar
Link:
http://lkml.kernel.org/r/1483029949-6925-1-git-send-email-fweis...@gmail.com
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/apic.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 5c4fdcf..fdb9c46 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -529,18 +529,19 @@ static void lapic_timer_broadcast(const struct cpumask
*mask)
* The local apic timer can be used for any function which is CPU local.
*/
static struct clock_event_device lapic_clockevent = {
- .name = "lapic",
- .features = CLOCK_EVT_FEAT_PERIODIC |
- CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP
- | CLOCK_EVT_FEAT_DUMMY,
- .shift = 32,
- .set_state_shutdown = lapic_timer_shutdown,
- .set_state_periodic = lapic_timer_set_periodic,
- .set_state_oneshot = lapic_timer_set_oneshot,
- .set_next_event = lapic_next_event,
- .broadcast = lapic_timer_broadcast,
- .rating = 100,
- .irq= -1,
+ .name = "lapic",
+ .features = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT |
CLOCK_EVT_FEAT_C3STOP
+ | CLOCK_EVT_FEAT_DUMMY,
+ .shift = 32,
+ .set_state_shutdown = lapic_timer_shutdown,
+ .set_state_periodic = lapic_timer_set_periodic,
+ .set_state_oneshot = lapic_timer_set_oneshot,
+ .set_state_oneshot_stopped = lapic_timer_shutdown,
+ .set_next_event = lapic_next_event,
+ .broadcast = lapic_timer_broadcast,
+ .rating = 100,
+ .irq= -1,
};
static DEFINE_PER_CPU(struct clock_event_device, lapic_events);
Re: Dell XPS13: MCE (Hardware Error) reported
On 01/06/17 17:54, Borislav Petkov wrote: On Fri, Jan 06, 2017 at 07:58:31AM -0800, Raj, Ashok wrote: Looks like we don't need a return value from therm_throt_process(), we can fix that as void as well. Right you are, here's v2: --- From a8151fa6f18c2605eb7972061234f05e79b372c4 Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Fri, 6 Jan 2017 12:07:08 +0100 Subject: [PATCH] x86/MCE/therm_throt: Do not log a fake MCE for a thermal event We log a fake bank 128 MCE to note that we're handling a CPU thermal event. However, this confuses people into thinking that their hardware generates MCEs. Hijacking MCA for logging thermal events is a gross misuse anyway and it should've been done in the first place. And besides Do you mean *shouldn’t have been done*? we have other means for dealing with thermal events which are much more suitable. So let's kill the MCE logging part. Signed-off-by: Borislav Petkov Should the discussion be referenced? Also, is that just for MacBookPro11,3? The MCE for the Dell XPS13 looks different from what I see, doesn’t it? […] Kind regards, Paul
[tip:x86/urgent] x86/boot: Add missing declaration of string functions
Commit-ID: fac69d0efad08fc15e4dbfc116830782acc0dc9a
Gitweb: http://git.kernel.org/tip/fac69d0efad08fc15e4dbfc116830782acc0dc9a
Author: Nicholas Mc Guire
AuthorDate: Sat, 7 Jan 2017 10:38:31 +0100
Committer: Thomas Gleixner
CommitDate: Mon, 9 Jan 2017 11:53:05 +0100
x86/boot: Add missing declaration of string functions
Add the missing declarations of basic string functions to string.h to allow
a clean build.
Fixes: 5be865661516 ("String-handling functions for the new x86 setup code.")
Signed-off-by: Nicholas Mc Guire
Link:
http://lkml.kernel.org/r/1483781911-21399-1-git-send-email-hof...@osadl.org
Signed-off-by: Thomas Gleixner
---
arch/x86/boot/string.c | 1 +
arch/x86/boot/string.h | 9 +
2 files changed, 10 insertions(+)
diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index cc3bd58..9e240fc 100644
--- a/arch/x86/boot/string.c
+++ b/arch/x86/boot/string.c
@@ -14,6 +14,7 @@
#include
#include "ctype.h"
+#include "string.h"
int memcmp(const void *s1, const void *s2, size_t len)
{
diff --git a/arch/x86/boot/string.h b/arch/x86/boot/string.h
index 725e820..113588d 100644
--- a/arch/x86/boot/string.h
+++ b/arch/x86/boot/string.h
@@ -18,4 +18,13 @@ int memcmp(const void *s1, const void *s2, size_t len);
#define memset(d,c,l) __builtin_memset(d,c,l)
#define memcmp __builtin_memcmp
+extern int strcmp(const char *str1, const char *str2);
+extern int strncmp(const char *cs, const char *ct, size_t count);
+extern size_t strlen(const char *s);
+extern char *strstr(const char *s1, const char *s2);
+extern size_t strnlen(const char *s, size_t maxlen);
+extern unsigned int atou(const char *s);
+extern unsigned long long simple_strtoull(const char *cp, char **endp,
+ unsigned int base);
+
#endif /* BOOT_STRING_H */
Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m
On Thu, 05 Jan 2017, Randy Dunlap wrote: > That particular circular/recursive dependency is ugly. I spent about > one hour trying/testing various fixes and don't have one. I didn't really look at this one all that much, but when I face problems with kconfig, it's almost invariably because of overuse of select. Documentation/kbuild/kconfig-language.txt says, "In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies." People violate this all the time because it's convenient. If they depended, they'd have to enable all deps to even see their config. I wish kconfig would warn about incorrect use of select... though I guess that would produce a wall of warnings. Additionally, it really should be easier to find and enable unmet dependencies in menuconfig. Someone(tm) has a lot of work to do... BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
Re: [PATCH v3 9/9] arm64: Documentation - Expose CPU feature registers
On 06/01/17 12:16, Catalin Marinas wrote: On Wed, Jan 04, 2017 at 05:49:07PM +, Suzuki K. Poulose wrote: +The following rules are applied to the value returned by the +infrastructure: + + a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0. + b) The value of a reserved field is populated with the reserved +value as defined by the architecture. + c) The value of a field marked as not 'visible', is set to indicate +the feature is missing (as defined by the architecture). + d) The value of a 'visible' field holds the system wide safe value +for the particular feature(except for MIDR_EL1, see section 4). +See Appendix I for more information on safe value. + +There are only a few registers visible to the userspace. See Section 4, +for the list of 'visible' registers. + +All others are emulated as having 'invisible' features. BTW, we don't have any statement about whether a visible field may become invisible but I guess this wouldn't be a problem as long as the feature is reported as missing. I'm thinking about currently RES0 fields that are listed as visible but they may report something in the future that we don't want exposed to user. At that point, we'll change the field to "invisible" while reporting RES0 to user. I don't see an issue with this, just I thought worth flagging. Thanks for raising that. In fact, we treat all the RES0 fields as invisible and strict for the moment. So, I think it is worth reflecting that in the documentation. As you mentioned, we could switch them as required based on the feature without any issues. I will fix this. Anyway: Reviewed-by: Catalin Marinas Thanks for reviewing the entire series. I will resend the series with the tags and updates to this documentation and a couple of other patches. Suzuki
Re: [linux-sunxi] Re: [PATCH 3/6] clk: sunxi-ng: Add H5 clocks
On Fri, Jan 06, 2017 at 06:48:31AM +0800, Icenowy Zheng wrote: > > 2017年1月6日 06:04于 Maxime Ripard 写道： > > > > On Tue, Dec 27, 2016 at 12:25:15AM +0800, Icenowy Zheng wrote: > > > Add the H5 CCU clocks set based on the H3 one. > > > > > > Signed-off-by: Icenowy Zheng > > > > Is there any difference with H3's? > > One more Transport Stream controller, so one more bus gate and bus > reset for it. There's no need to duplicate more than 1000 lines of code just for that then. Just add a new compatible and reuse the clocks already defined. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: Dell XPS13: MCE (Hardware Error) reported
On Mon, Jan 09, 2017 at 11:55:41AM +0100, Paul Menzel wrote: > Do you mean *shouldn’t have been done*? Yes. > Should the discussion be referenced? Yap, it will be. > Also, is that just for MacBookPro11,3? The MCE for the Dell XPS13 looks > different from what I see, doesn’t it? Yes, yours is different. I'm still waiting for you to reply to Ashok's questions here: https://lkml.kernel.org/r/20170105011236.GA80100@otc-brkl-03 Thanks. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: Dell XPS13: MCE (Hardware Error) reported
Dear Boris, On 01/09/17 12:05, Borislav Petkov wrote: On Mon, Jan 09, 2017 at 11:55:41AM +0100, Paul Menzel wrote: […] Also, is that just for MacBookPro11,3? The MCE for the Dell XPS13 looks different from what I see, doesn’t it? Yes, yours is different. I'm still waiting for you to reply to Ashok's questions here: https://lkml.kernel.org/r/20170105011236.GA80100@otc-brkl-03 I see. I thought Daniel’s answered them. I’ll reply now. Kind regards, Paul
Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB
Hi Shashank,
Thanks for the review.
On 09-01-2017 05:22, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 12/30/2016 10:23 PM, Jose Abreu wrote:
>> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
>> According to the spec the EDID may contain two blocks that
>> signal this sampling mode:
>> - YCbCr 4:2:0 Video Data Block
>> - YCbCr 4:2:0 Video Capability Map Data Block
>>
>> The video data block contains the list of vic's were
>> only YCbCr 4:2:0 sampling mode shall be used while the
>> video capability map data block contains a mask were
>> YCbCr 4:2:0 sampling mode may be used.
>>
>> This RFC patch adds support for parsing these two new blocks
>> and introduces new flags to signal the drivers if the
>> mode is 4:2:0'only or 4:2:0'able.
>>
>> The reason this is still a RFC is because there is no
>> reference in kernel for this new sampling mode (specially in
>> AVI infoframe part), so, I was hoping to hear some feedback
>> first.
>>
>> Tested in a HDMI 2.0 compliance scenario.
>>
>> Signed-off-by: Jose Abreu
>> Cc: Carlos Palminha
>> Cc: Daniel Vetter
>> Cc: Jani Nikula
>> Cc: Sean Paul
>> Cc: David Airlie
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>> drivers/gpu/drm/drm_edid.c | 139
>> +++-
>> drivers/gpu/drm/drm_modes.c | 10 +++-
>> include/uapi/drm/drm_mode.h | 6 ++
>> 3 files changed, 151 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c
>> b/drivers/gpu/drm/drm_edid.c
>> index 67d6a73..6ce1a38 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct
>> drm_connector *connector,
>> #define VENDOR_BLOCK0x03
>> #define SPEAKER_BLOCK0x04
>> #define VIDEO_CAPABILITY_BLOCK0x07
>> +#define VIDEO_DATA_BLOCK_4200x0E
>> +#define VIDEO_CAP_BLOCK_4200x0F
>> #define EDID_BASIC_AUDIO(1 << 6)
>> #define EDID_CEA_YCRCB444(1 << 5)
>> #define EDID_CEA_YCRCB422(1 << 4)
>> @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct
>> drm_connector *connector, u16 structure,
>> return modes;
>> }
>> +static int add_420_mode(struct drm_connector *connector, u8
>> vic)
>> +{
>> +struct drm_device *dev = connector->dev;
>> +struct drm_display_mode *newmode;
>> +
>> +if (!drm_valid_cea_vic(vic))
>> +return 0;
>> +
>> +newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
> Sorry to start the review late, I missed this mail chain. It
> would be great if you can please keep me in CC for this chain.
Sure. Will do that next time.
>
> Practically, YUV420 modes are being used for 4k and UHD video
> modes. Now here, when we want to
> add these modes from edid_cea_db, using the VIC index, we
> should have full list of cea_modes from 1 - 107
> Particularly 93-107 ( which is for new 38x21 and 40x21 modes,
> added in CEA-861-F). right now, edid_cea_modes
> cant index 4k modes, so practically this this patch series will
> do nothing (even though its doing everything right)
This is correct but not entirely true. I realize 4:2:0 is mostly
used in 4k modes but it can also be used in any other video mode,
as long as it is declared in the VCB.
>
> To handle this scenario, I had added a patch series
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_119627_&d=DgICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI&s=DPBQ2MpLgngWGJEOg2v9CQhg2CSf_4LOIAC30B6AAyg&e=
> (complete the cea modedb (VIC=65 onwards)) Now, this patch
> series had dependency on new aspect ratios
> being added in CEA-861-F which I tried to add in series
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_116095_&d=DgICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI&s=PX2M1hM2cF_aWiDe5oZeLWjsOgL-hvUR54Ion9kYMxM&e=
> )
> Which was added and later reverted by Ville
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_119808_&d=DgICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=6JwJ_PEZj3MSeRaLTHuLtPZCb0uPPjUqR5raxY_qILI&s=FAa6aHQ_HjlaVRzDm282p9bSY_tBiN1PngZBhsTqYdI&e=
> ).
Yes, I remember that. If it was breaking userspace then there was
nothing left to do, revert was needed. I thing we should take
your patch and rework/extend it so that userspace does not break
as this is a most welcome feature. The new HDMI spec is almost
ready, and yet, 2.0 features are still missing from the kernel.
We should take advantage from our capability of accessing these
specs, test equipment, compliance equipment ... and submit
patches for these new features :)
>
> In short, the method/sequence for effective development would be:
> - Add aspect ratio support in DRM
> - Add HDMI 2.0 (CEA-861-F) aspect ratios
> (
Re: drivers/net/wireless/intel/iwlwifi/pcie/trans.c: 2 * suspicious code ?
On Fri, 2017-01-06 at 17:47 +, David Binderman wrote: > Hello there, Hi David, > 1. > > drivers/net/wireless/intel/iwlwifi/pcie/trans.c:2039:14: warning: decrement > of a boolean expression [-Wbool-operation] > > Source code is > >txq->block--; > > Maybe someone got a bool and a int mixed up ? > > 2. > > drivers/net/wireless/intel/iwlwifi/pcie/trans.c:2045:14: warning: increment > of a boolean expression [-Wbool-operation] > > Duplicate a few lines further down. Emmanuel has fixed this in our internal tree and I'll be sending it out together with our normal upstreaming process. Thanks for reporting! -- Cheers, Luca.
Re: [PATCH 0/4] Staging: comedi: comedi_fops: Header cleanup
On 07/01/17 11:13, Cheah Kok Cheong wrote: This series does trivial header cleanup for comedi_fops.c Cheah Kok Cheong (4): Staging: comedi: comedi_fops: Remove unused kmod.h header Staging: comedi: comedi_fops: Remove redundant init.h header Staging: comedi: comedi_fops: Remove unused vmalloc.h header Staging: comedi: comedi_fops: Remove unused stat.h header drivers/staging/comedi/comedi_fops.c | 4 1 file changed, 4 deletions(-) I wasn't sure about the removal of the #include , but it seems to make sense. Thanks. Reviewed-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Web: http://www.mev.co.uk/ )=-
