Re: [PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code
Hi!
> > >> Is similar patch needed for i386?
> > >
> > > Yes, it is, in general, for i386 hibernation to work with ASLR.
> > >
> > > But it doesn't work with it for other reasons ATM, AFAICS.
> > >
> > > Unfortunately, I won't really have the time to take care of this any time
> > > soon.
> > >
> >
> > KASLR memory randomization is only available for x64 right now. I plan
> > on porting to 32bit eventually and will test/adapt hibernation as part
> > of it.
>
> Great to hear that, but you need to be aware that the i386 hibernate code has
> not been touched for a long time and it makes some heavy assumptions that
> are not made on x86-64.
Yes, we did pretty bad job keeping i386 and x86-64 in sync.
This should bring them closer together. (My original motivation was to
enable hibernation and resume using differnet kernel versions. That
worked. Merge with v4.7 changes was not trivial, but it still appears
to work, probably doing some stuff that is not neccessary on 32-bit.)
Signed-off-by: Pavel Machek (but cleanup before
applying :-))
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3a9add5..b5c48f1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2236,7 +2236,7 @@ menu "Power management and ACPI options"
config ARCH_HIBERNATION_HEADER
def_bool y
- depends on X86_64 && HIBERNATION
+ depends on HIBERNATION
source "kernel/power/Kconfig"
diff --git a/arch/x86/include/asm/suspend_32.h
b/arch/x86/include/asm/suspend_32.h
index 8e9dbe7..81c5bfc 100644
--- a/arch/x86/include/asm/suspend_32.h
+++ b/arch/x86/include/asm/suspend_32.h
@@ -25,4 +25,7 @@ struct saved_context {
unsigned long return_address;
} __attribute__((packed));
+extern char core_restore_code;
+extern char restore_registers;
+
#endif /* _ASM_X86_SUSPEND_32_H */
diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
new file mode 100644
index 000..c0b0572
--- /dev/null
+++ b/arch/x86/power/hibernate.c
@@ -0,0 +1,49 @@
+int reallocate_restore_code(void)
+{
+ relocated_restore_code = (void *)get_safe_page(GFP_ATOMIC);
+ if (!relocated_restore_code)
+ return -ENOMEM;
+ memcpy(relocated_restore_code, &core_restore_code,
+ &restore_registers - &core_restore_code);
+ return 0;
+}
+
+struct restore_data_record {
+ unsigned long jump_address;
+ unsigned long jump_address_phys;
+ unsigned long cr3;
+ unsigned long magic;
+};
+
+/**
+ * arch_hibernation_header_save - populate the architecture specific part
+ * of a hibernation image header
+ * @addr: address to save the data at
+ */
+int arch_hibernation_header_save(void *addr, unsigned int max_size)
+{
+ struct restore_data_record *rdr = addr;
+
+ if (max_size < sizeof(struct restore_data_record))
+ return -EOVERFLOW;
+ rdr->jump_address = (unsigned long)&restore_registers;
+ rdr->jump_address_phys = __pa_symbol(&restore_registers);
+ rdr->cr3 = restore_cr3;
+ rdr->magic = RESTORE_MAGIC;
+ return 0;
+}
+
+/**
+ * arch_hibernation_header_restore - read the architecture specific data
+ * from the hibernation image header
+ * @addr: address to read the data from
+ */
+int arch_hibernation_header_restore(void *addr)
+{
+ struct restore_data_record *rdr = addr;
+
+ restore_jump_address = rdr->jump_address;
+ jump_address_phys = rdr->jump_address_phys;
+ restore_cr3 = rdr->cr3;
+ return (rdr->magic == RESTORE_MAGIC) ? 0 : -EINVAL;
+}
diff --git a/arch/x86/power/hibernate_32.c b/arch/x86/power/hibernate_32.c
index 9f14bd3..784e6c7 100644
--- a/arch/x86/power/hibernate_32.c
+++ b/arch/x86/power/hibernate_32.c
@@ -4,6 +4,7 @@
* Distribute under GPLv2
*
* Copyright (c) 2006 Rafael J. Wysocki
+ * Copyright (c) 2015 Pavel Machek
*/
#include
@@ -14,13 +15,30 @@
#include
#include
#include
+#include
+#include
/* Defined in hibernate_asm_32.S */
extern int restore_image(void);
+/*
+ * Address to jump to in the last phase of restore in order to get to the image
+ * kernel's text (this value is passed in the image header).
+ */
+unsigned long restore_jump_address __visible;
+unsigned long jump_address_phys;
+
+/*
+ * Value of the cr3 register from before the hibernation (this value is passed
+ * in the image header).
+ */
+unsigned long restore_cr3 __visible;
+
/* Pointer to the temporary resume page tables */
pgd_t *resume_pg_dir;
+void *relocated_restore_code __visible;
+
/* The following three functions are based on the analogous code in
* arch/x86/mm/init_32.c
*/
@@ -142,6 +160,9 @@ static inline void resume_init_first_level_page_table(pgd_t
*pg_dir)
#endif
}
+#define RESTORE_MAGIC 0x1bea1e0UL
+#include "hibernate.c"
+
int swsusp_arch_resume(void)
{
int error;
@@ -155,6 +176,10 @@ int swsusp_arch_resume(void)
if (error)
return error;
+ error = reallocate_restore_code
Re: [PATCH 0/7] Minor DP aux transaction fixes
Am 06.08.2016 um 02:30 schrieb Lyude: While I was investigating an unrelated bug on the radeon driver, I noticed that it's become rather difficult to actually read through dmesg with drm.debug turned on, on account of the huge number of messages we end up printing from failed DP aux transactions that happen every time we reprobe each connector. Timed out transactions are relatively normal, and as well there's a lot of places in radeon/amdgpu where we're printing redundant debugging information dozens of times each time we attempt a DP aux transactions. Additionally, I've removed some of the retry loops in amdgpu/radeon. These were definitely useful at one point, but since we now retry any failed aux transaction unconditionally in DRM's dp helpers they don't serve much purpose other then to make failing aux transactions take a lot more time then they need to. The whole set is Reviewed-by: Christian König . Regards, Christian. Lyude (7): drm/dp_helper: Print first error received on failure in drm_dp_dpcd_access() drm/radeon: Don't print error on aux transaction timeouts drm/radeon: Don't retry 7 times in radeon_dp_dpcd() drm/amdgpu: Don't print error on aux transaction timeouts drm/amdgpu: Don't retry 7 times in amdgpu_atombios_dp_get_dpcd() drm: Add ratelimited versions of the DRM_DEBUG* macros drm/dp_helper: Rate limit timeout errors from drm_dp_i2c_do_msg() drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 22 ++ drivers/gpu/drm/drm_dp_helper.c | 14 -- drivers/gpu/drm/radeon/atombios_dp.c | 21 ++--- drivers/gpu/drm/radeon/radeon_dp_auxch.c | 1 - include/drm/drmP.h | 30 ++ 5 files changed, 62 insertions(+), 26 deletions(-)
Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy
Hi Stephan, On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote: > Hi Ted, Herbert, > > I sent a question to the ATH9K RNG some time ago to the developers. > See https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg19115.html > > I have not yet received a word and I think this issue should be resolved. > > Thanks > Stephan > > ---8<--- If the above text is placed below the three dashes, "---", below ... > The ATH9K driver implements an RNG which is completely bypassing the > standard Linux HW generator logic. > > The RNG may or may not deliver entropy. Considering the conservative > approach in treating entropy with respect to non-auditable sources, this > patch changes the delivered entropy value to zero. The RNG still feeds > data into the input_pool but it is assumed to have no entropy. > > When the ATH9K RNG changes to use the HW RNG framework, it may re-enable > the entropy estimation considering that a user can change that value at > boot and runtime. > > Signed-off-by: Stephan Mueller > --- here, then the mail can be applied directly without editing. > drivers/net/wireless/ath/ath9k/rng.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/rng.c > b/drivers/net/wireless/ath/ath9k/rng.c > index d38e50f..d63dc48 100644 > --- a/drivers/net/wireless/ath/ath9k/rng.c > +++ b/drivers/net/wireless/ath/ath9k/rng.c > @@ -92,8 +92,7 @@ static int ath9k_rng_kthread(void *data) > fail_stats = 0; > > /* sleep until entropy bits under write_wakeup_threshold */ > - add_hwgenerator_randomness((void *)rng_buf, bytes_read, > -ATH9K_RNG_ENTROPY(bytes_read)); This is the only use of this macro. I'd remove the #define on line 25 as well. > + add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0); > } > > kfree(rng_buf); Other than that, Reviewed-by: Jason Cooper thx, Jason.
Re: [PATCH] Revert "irqdomain: Don't set type when mapping an IRQ"
On Sat, 6 Aug 2016 10:18:03 +0200 Linus Walleij wrote: > This reverts commit 1e2a7d78499ec8859d2b469051b7b80bad3b08aa. > > When using the APQ8060 Dragonboard I have lost all interrupts from > the PMIC after this commit: power button, keypad, RTC alarm and > all GPIOs. Reverting the commit solves the issue. > > The affected irqchip driver is drivers/mfd/pm8921-core.c > > I cannot immediately see what the problem is, so if you have a > better solution than just reverting the patch, please suggest. > > Cc: Jon Hunter > Cc: Marc Zyngier > Cc: Thomas Gleixner > Cc: John Stultz > Cc: Björn Andersson > Cc: Stephen Boyd > Cc: Abhijeet Dharmapurikar > Signed-off-by: Linus Walleij > --- > I am pretty sure that this is the same bug that John Stultz is > seeing on the Nexus 7, John: please confirm. Hi Linus, Before blindly reverting this patch (which itself is going to cause other things to break), I'd like to understand the failure mode. Any chance you could instrument pm8xxx_irq_set_type() and see if we get called (and which which parameters)? A call stack would be ideal. I'm normally expecting __irq_set_trigger() to be called from manage.c::__setup_irq(), but your failure mode would tend to indicate that it is not going that way. Is there any irq line sharing going on by any chance? Also, John has now isolated the failure to a much simpler piece of code, so I'd hope to narrow it down pretty quickly (see the other thread). Thanks, M. -- Jazz is not dead. It just smells funny.
[PATCH v2 07/14] net: ethernet: ti: cpsw: replace pdev on dev
No need to hold pdev link when only dev is needed.
This allows to simplify a bunch of cpsw->pdev->dev now and farther.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 65 ++
1 file changed, 34 insertions(+), 31 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index ac875b3..a813bac 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -364,7 +364,7 @@ static inline void slave_write(struct cpsw_slave *slave,
u32 val, u32 offset)
}
struct cpsw_common {
- struct platform_device *pdev;
+ struct device *dev;
};
struct cpsw_priv {
@@ -1159,7 +1159,7 @@ static void cpsw_slave_open(struct cpsw_slave *slave,
struct cpsw_priv *priv)
phy_start(slave->phy);
/* Configure GMII_SEL register */
- cpsw_phy_sel(&cpsw->pdev->dev, slave->phy->interface, slave->slave_num);
+ cpsw_phy_sel(cpsw->dev, slave->phy->interface, slave->slave_num);
}
static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
@@ -1245,9 +1245,9 @@ static int cpsw_ndo_open(struct net_device *ndev)
int i, ret;
u32 reg;
- ret = pm_runtime_get_sync(&cpsw->pdev->dev);
+ ret = pm_runtime_get_sync(cpsw->dev);
if (ret < 0) {
- pm_runtime_put_noidle(&cpsw->pdev->dev);
+ pm_runtime_put_noidle(cpsw->dev);
return ret;
}
@@ -1324,7 +1324,7 @@ static int cpsw_ndo_open(struct net_device *ndev)
*/
cpsw_info(priv, ifup, "submitted %d rx descriptors\n", i);
- if (cpts_register(&cpsw->pdev->dev, priv->cpts,
+ if (cpts_register(cpsw->dev, priv->cpts,
priv->data.cpts_clock_mult,
priv->data.cpts_clock_shift))
dev_err(priv->dev, "error registering cpts device\n");
@@ -1349,7 +1349,7 @@ static int cpsw_ndo_open(struct net_device *ndev)
err_cleanup:
cpdma_ctlr_stop(priv->dma);
for_each_slave(priv, cpsw_slave_stop, priv);
- pm_runtime_put_sync(&cpsw->pdev->dev);
+ pm_runtime_put_sync(cpsw->dev);
netif_carrier_off(priv->ndev);
return ret;
}
@@ -1374,7 +1374,7 @@ static int cpsw_ndo_stop(struct net_device *ndev)
cpsw_ale_stop(priv->ale);
}
for_each_slave(priv, cpsw_slave_stop, priv);
- pm_runtime_put_sync(&cpsw->pdev->dev);
+ pm_runtime_put_sync(cpsw->dev);
if (priv->data.dual_emac)
priv->slaves[priv->emac_port].open_stat = false;
return 0;
@@ -1614,9 +1614,9 @@ static int cpsw_ndo_set_mac_address(struct net_device
*ndev, void *p)
if (!is_valid_ether_addr(addr->sa_data))
return -EADDRNOTAVAIL;
- ret = pm_runtime_get_sync(&cpsw->pdev->dev);
+ ret = pm_runtime_get_sync(cpsw->dev);
if (ret < 0) {
- pm_runtime_put_noidle(&cpsw->pdev->dev);
+ pm_runtime_put_noidle(cpsw->dev);
return ret;
}
@@ -1634,7 +1634,7 @@ static int cpsw_ndo_set_mac_address(struct net_device
*ndev, void *p)
memcpy(ndev->dev_addr, priv->mac_addr, ETH_ALEN);
for_each_slave(priv, cpsw_set_slave_mac, priv);
- pm_runtime_put(&cpsw->pdev->dev);
+ pm_runtime_put(cpsw->dev);
return 0;
}
@@ -1706,9 +1706,9 @@ static int cpsw_ndo_vlan_rx_add_vid(struct net_device
*ndev,
if (vid == priv->data.default_vlan)
return 0;
- ret = pm_runtime_get_sync(&cpsw->pdev->dev);
+ ret = pm_runtime_get_sync(cpsw->dev);
if (ret < 0) {
- pm_runtime_put_noidle(&cpsw->pdev->dev);
+ pm_runtime_put_noidle(cpsw->dev);
return ret;
}
@@ -1728,7 +1728,7 @@ static int cpsw_ndo_vlan_rx_add_vid(struct net_device
*ndev,
dev_info(priv->dev, "Adding vlanid %d to vlan filter\n", vid);
ret = cpsw_add_vlan_ale_entry(priv, vid);
- pm_runtime_put(&cpsw->pdev->dev);
+ pm_runtime_put(cpsw->dev);
return ret;
}
@@ -1742,9 +1742,9 @@ static int cpsw_ndo_vlan_rx_kill_vid(struct net_device
*ndev,
if (vid == priv->data.default_vlan)
return 0;
- ret = pm_runtime_get_sync(&cpsw->pdev->dev);
+ ret = pm_runtime_get_sync(cpsw->dev);
if (ret < 0) {
- pm_runtime_put_noidle(&cpsw->pdev->dev);
+ pm_runtime_put_noidle(cpsw->dev);
return ret;
}
@@ -1769,7 +1769,7 @@ static int cpsw_ndo_vlan_rx_kill_vid(struct net_device
*ndev,
ret = cpsw_ale_del_mcast(priv->ale, priv->ndev->broadcast,
0, ALE_VLAN, vid);
- pm_runtime_put(&cpsw->pdev->dev);
+ pm_runtime_put(cpsw->dev);
return ret;
}
@@ -1813,10 +1813,11 @@ static void cpsw_get_drvinfo(struct net_device *nd
[GIT PULL for v4.8-rc1] mailcap fixup for two entries
Hi Linus, Please pull from my tree for a small fixup on my entry and Shuah's entry at .mailcap. Basically, those entries were with a syntax that makes get_maintainer.pl to do the wrong thing. Thanks! Mauro PS.: Andrew asked to handle this one via my tree, as he had some issued with some UTF-8 characters on this file, at the context lines. The following changes since commit 292eaf50c7df4ae2ae8aaa9e1ce3f1240a353ee8: [media] cec: fix off-by-one memset (2016-07-28 20:16:35 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.8-6 for you to fetch changes up to 5055610e3d30ed90de77525cf240d0066ac616e4: .mailmap: Correct entries for Mauro Carvalho Chehab and Shuah Khan (2016-08-04 21:35:41 -0300) media updates for v4.8-rc1 Joe Perches (1): .mailmap: Correct entries for Mauro Carvalho Chehab and Shuah Khan .mailmap | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-)
Re: [PATCH v2] perf probe: Support signedness casting
On Fri, 5 Aug 2016 20:53:21 +0900 Naohiro Aota wrote: > Perf-probe detects a variable's type and use the detected type to add new > probe. Then, kprobes prints its variable in hexadecimal format if the > variable is unsigned and prints in decimal if it is signed. > > We sometimes want to see unsigned variable in decimal format (i.e. > sector_t or size_t). In that case, we need to investigate variable's > size manually to specify just signedness. > > This patch add signedness casting support. By specifying "s" or "u" as a > type, perf-probe will investigate variable size as usual and use > the specified signedness. > > E.g. without this: > > $ perf probe -a 'submit_bio bio->bi_iter.bi_sector' > Added new event: > probe:submit_bio (on submit_bio with bi_sector=bio->bi_iter.bi_sector) > You can now use it in all perf tools, such as: > perf record -e probe:submit_bio -aR sleep 1 > $ cat trace_pipe|head > dbench-9692 [003] d..1 971.096633: submit_bio: > (submit_bio+0x0/0x140) bi_sector=0x3a3d00 > dbench-9692 [003] d..1 971.096685: submit_bio: > (submit_bio+0x0/0x140) bi_sector=0x1a3d80 > dbench-9692 [003] d..1 971.096687: submit_bio: > (submit_bio+0x0/0x140) bi_sector=0x3a3d80 > ... > // need to investigate the variable size > $ perf probe -a 'submit_bio bio->bi_iter.bi_sector:s64' > Added new event: > probe:submit_bio (on submit_bio with > bi_sector=bio->bi_iter.bi_sector:s64) > You can now use it in all perf tools, such as: > perf record -e probe:submit_bio -aR sleep 1 > > With this: > > // just use "s" to cast its signedness > $ perf probe -v -a 'submit_bio bio->bi_iter.bi_sector:s' > Added new event: > probe:submit_bio (on submit_bio with bi_sector=bio->bi_iter.bi_sector:s) > You can now use it in all perf tools, such as: > perf record -e probe:submit_bio -aR sleep 1 > $ cat trace_pipe|head > dbench-9689 [001] d..1 1212.391237: submit_bio: > (submit_bio+0x0/0x140) bi_sector=128 > dbench-9689 [001] d..1 1212.391252: submit_bio: > (submit_bio+0x0/0x140) bi_sector=131072 > dbench-9697 [006] d..1 1212.398611: submit_bio: > (submit_bio+0x0/0x140) bi_sector=30208 > > This commit also update perf-probe.txt to describe "types". Most parts > are based on existing documentation: Documentation/trace/kprobetrace.txt > > Signed-off-by: Naohiro Aota > --- > tools/perf/Documentation/perf-probe.txt | 10 +- > tools/perf/util/probe-finder.c | 15 --- > 2 files changed, 21 insertions(+), 4 deletions(-) > > diff --git a/tools/perf/Documentation/perf-probe.txt > b/tools/perf/Documentation/perf-probe.txt > index 736da44..a23b124 100644 > --- a/tools/perf/Documentation/perf-probe.txt > +++ b/tools/perf/Documentation/perf-probe.txt > @@ -176,10 +176,18 @@ Each probe argument follows below syntax. > > 'NAME' specifies the name of this argument (optional). You can use the name > of local variable, local data structure member (e.g. var->field, var.field2), > local array with fixed index (e.g. array[1], var->array[0], var->pointer[2]), > or kprobe-tracer argument format (e.g. $retval, %ax, etc). Note that the name > of this argument will be set as the last member name if you specify a local > data structure member (e.g. field2 for 'var->field1.field2'.) > '$vars' and '$params' special arguments are also available for NAME, '$vars' > is expanded to the local variables (including function parameters) which can > access at given probe point. '$params' is expanded to only the function > parameters. > -'TYPE' casts the type of this argument (optional). If omitted, perf probe > automatically set the type based on debuginfo. You can specify 'string' type > only for the local variable or structure member which is an array of or a > pointer to 'char' or 'unsigned char' type. > +'TYPE' casts the type of this argument (optional). If omitted, perf probe > automatically set the type based on debuginfo. Currently, basic types > (u8/u16/u32/u64/s8/s16/s32/s64), "string" and bitfield are supported. (see > TYPES for detail) Hmm, have you added the 's' and 'u' here too ?? > > On x86 systems %REG is always the short form of the register: for example > %AX. %RAX or %EAX is not valid. > > +TYPES > +- > +Basic types (u8/u16/u32/u64/s8/s16/s32/s64) are integer types. Prefix 's' > and 'u' means those types are signed and unsigned respectively. Traced > arguments are shown in decimal (signed) or hex (unsigned). You can also use > 's' or 'u' to specify only signedness and leave its size auto-detected by > perf probe. So, not only the details, but also the brief information about the TYPE, there should be 's' and 'u'. Other are good to me. Thanks, > +String type is a special type, which fetches a "null-terminated" string from > kernel space. This means it will fail and store NULL if the string container > has been paged out. You can specify 'string' type o
Re: [PATCH v2 1/2] befs: remove unused BEFS_BT_MATCH
On 06/08/16 19:34, Salah Triki wrote:
> On Fri, Aug 05, 2016 at 01:41:20PM +0100, Luis de Bethencourt wrote:
>> befs_btree_find(), the only caller of befs_find_key(), only cares about if
>> the return from that function is BEFS_BT_MATCH or not. It never uses the
>> partial match given with BEFS_BT_MATCH. Removing that return and don't set
>> the value that will go unused.
>>
>> Signed-off-by: Luis de Bethencourt
>> ---
>> v2: fix overflow != not found
>> keep a value for the while(!leafnode()) loop to find a leaf node and exit
>>
>>
>> Hi,
>>
>> This is a correction. Now I understand the difference between returning
>> NOT_FOUND when the key is in a full node and we have to look in the overflow.
>> Compared to NOT_FOUND when the key doesn't exist.
>>
>> For the former, we can set the key value to 0 and that means check the
>> overflow.
>>
>> For the latter, we need to return an existing value, even if not correct, so
>> the while loop [while (!befs_leafnode(this_node))] can find a leaf, exit and
>> then see it is not the correct node in the call of befs_find_next() right
>> after
>> the loop body.
>>
>> This makes the code more readable than a mysterious "partial match" that
>> actually means no match.
>>
>> There is still an issue with the comparison of the strings in the binary
>> search. About to start looking into that but wanted to send this corrected
>> patch first before any of you reviewed the faulty first version.
>>
>> Thanks,
>> Luis
>>
>> fs/befs/befs.h | 1 -
>> fs/befs/btree.c | 38 --
>> 2 files changed, 16 insertions(+), 23 deletions(-)
>>
>> diff --git a/fs/befs/befs.h b/fs/befs/befs.h
>> index c5c6cd1..faf3fac 100644
>> --- a/fs/befs/befs.h
>> +++ b/fs/befs/befs.h
>> @@ -79,7 +79,6 @@ enum befs_err {
>> BEFS_BT_END,
>> BEFS_BT_EMPTY,
>> BEFS_BT_MATCH,
>> -BEFS_BT_PARMATCH,
>> BEFS_BT_NOT_FOUND
>> };
>>
>> diff --git a/fs/befs/btree.c b/fs/befs/btree.c
>> index 3f1a391..bc7efb0 100644
>> --- a/fs/befs/btree.c
>> +++ b/fs/befs/btree.c
>> @@ -281,9 +281,9 @@ befs_btree_find(struct super_block *sb, const
>> befs_data_stream *ds,
>>
>> while (!befs_leafnode(this_node)) {
>> res = befs_find_key(sb, this_node, key, &node_off);
>> -if (res == BEFS_BT_NOT_FOUND)
>> +/* if no key set, try the overflow node */
>> +if (node_off == 0)
>> node_off = this_node->head.overflow;
>> -/* if no match, go to overflow node */
>> if (befs_bt_read_node(sb, ds, this_node, node_off) != BEFS_OK) {
>> befs_error(sb, "befs_btree_find() failed to read "
>> "node at %llu", node_off);
>> @@ -291,8 +291,7 @@ befs_btree_find(struct super_block *sb, const
>> befs_data_stream *ds,
>> }
>> }
>>
>> -/* at the correct leaf node now */
>> -
>> +/* at a leaf node now, check if it is correct */
>> res = befs_find_key(sb, this_node, key, value);
>>
>> brelse(this_node->bh);
>> @@ -321,18 +320,13 @@ befs_btree_find(struct super_block *sb, const
>> befs_data_stream *ds,
>> * @sb: Filesystem superblock
>> * @node: Node to find the key within
>> * @findkey: Keystring to search for
>> - * @value: If key is found, the value stored with the key is put here
>> - *
>> - * finds exact match if one exists, and returns BEFS_BT_MATCH
>> - * If no exact match, finds first key in node that is greater
>> - * (alphabetically) than the search key and returns BEFS_BT_PARMATCH
>> - * (for partial match, I guess). Can you think of something better to
>> - * call it?
>> + * @value: If key is found, the value stored with the key is put here.
>> + * If not, the value is returned as 0.
>> *
>> - * If no key was a match or greater than the search key, return
>> - * BEFS_BT_NOT_FOUND.
>> + * Finds exact match if one exists, and returns BEFS_BT_MATCH.
>> + * If there is no exact match, it returns BEFS_BT_NOT_FOUND.
>> *
>> - * Use binary search instead of a linear.
>> + * Uses binary search instead of a linear.
>> */
>> static int
>> befs_find_key(struct super_block *sb, struct befs_btree_node *node,
>> @@ -355,8 +349,8 @@ befs_find_key(struct super_block *sb, struct
>> befs_btree_node *node,
>>
>> eq = befs_compare_strings(thiskey, keylen, findkey, findkey_len);
>> if (eq < 0) {
>> -befs_error(sb, "<--- %s %s not found", __func__, findkey);
>> -befs_debug(sb, "<--- %s ERROR", __func__);
>> +*value = 0;
>> +befs_debug(sb, "<--- node can't contain %s", findkey);
>> return BEFS_BT_NOT_FOUND;
>> }
>>
>> @@ -385,12 +379,12 @@ befs_find_key(struct super_block *sb, struct
>> befs_btree_node *node,
>> else
>> first = mid + 1;
>> }
>> -if (eq < 0)
>> -*value = fs64_to_cpu(sb, valarray[mid + 1]);
>> -else
>> -*value = fs64_to_cpu
Re: [PATCH 2/2] gpio: add Technologic I2C-FPGA gpio support
On Fri, Aug 5, 2016 at 10:41 AM, Lucile Quirion
wrote:
> This driver is generic and aims to support all Technologic Systems's
> boards embedding FPGA GPIOs with an I2C interface.
>
> This driver supports TS-4900, TS-7970, TS-7990 and TS-4100 series.
>
> Signed-off-by: Lucile Quirion
> ---
> drivers/gpio/Kconfig | 6 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-ts4900.c | 238
> +
> 3 files changed, 245 insertions(+)
> create mode 100644 drivers/gpio/gpio-ts4900.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 98dd47a..459fb71 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -779,6 +779,12 @@ config GPIO_TPIC2810
> To compile this driver as a module, choose M here: the module will
> be called gpio-tpic2810.
>
> +config GPIO_TS4900
> + bool "Technologic Systems FPGA I2C GPIO"
Please don't use module.h and MODULE_ macros in drivers that are bool.
Either delete all the module related stuff and use a builtin registration fcn,
or use a tristate Kconfig if there is a genuine use case for a modular driver.
Thanks,
Paul.
--
> + help
> + Say yes here to enabled the GPIO driver for Technologic's FPGA core.
> + Series supported include TS-4100, TS-4900, TS-7970 and TS-7990.
> +
> endmenu
>
> menu "MFD GPIO expanders"
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 2a035ed..4dcc21f 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -110,6 +110,7 @@ obj-$(CONFIG_GPIO_TPS6586X) += gpio-tps6586x.o
> obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
> obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
> obj-$(CONFIG_GPIO_TS4800) += gpio-ts4800.o
> +obj-$(CONFIG_GPIO_TS4900) += gpio-ts4900.o
> obj-$(CONFIG_GPIO_TS5500) += gpio-ts5500.o
> obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
> obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
> diff --git a/drivers/gpio/gpio-ts4900.c b/drivers/gpio/gpio-ts4900.c
> new file mode 100644
> index 000..104d1e0
> --- /dev/null
> +++ b/drivers/gpio/gpio-ts4900.c
> @@ -0,0 +1,238 @@
> +/*
> + * Digital I/O driver for Technologic Systems I2C FPGA Core
> + *
> + * Copyright (C) 2015 Technologic Systems
> + * Copyright (C) 2016 Savoir-Faire Linux
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether expressed or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License version 2 for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
[...]
> +static const struct i2c_device_id ts4900_gpio_id_table[] = {
> + { "ts4900-gpio", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(i2c, ts4900_gpio_id_table);
> +
> +static struct i2c_driver ts4900_gpio_driver = {
> + .driver = {
> + .name = "ts4900-gpio",
> + .of_match_table = ts4900_gpio_of_match_table,
> + },
> + .probe = ts4900_gpio_probe,
> + .remove = ts4900_gpio_remove,
> + .id_table = ts4900_gpio_id_table,
> +};
> +module_i2c_driver(ts4900_gpio_driver);
> +
> +MODULE_AUTHOR("Technologic Systems");
> +MODULE_DESCRIPTION("GPIO interface for Technologic Systems I2C-FPGA core");
> +MODULE_LICENSE("GPL");
> --
> 2.5.5
>
Re: [PATCH v3] Coccinelle: Script to replace NULL test with IS_ERR test for devm_ioremap_resource
On Sat, 6 Aug 2016, SF Markus Elfring wrote: > > +@err depends on context || org || report@ > > +statement S; > > +expression e; > > +position j0; > > How do you think about to omit the number from this variable name? > > > > +@@ > > + > > + e = devm_ioremap_resource(...); > > +* if (!e@j0) S > > Are there any more functions to consider for such a source code search > pattern? > How do you think about to use a function name list here? How about getting this into the kernel, and then one can worry about adding more functions later. > > > +// > > > > I suggest to omit such comment lines from this SmPL script. These are introduced by spgen. Likewise for the numbers on the j variables. The pattern j + number can even be useful, because it shows a position variable that introduced to manage the different kinds of output, rather than something that is intrinsic to the computation being performed. julia > > Regards, > Markus >
Re: [Documentation] State of CPU controller in cgroup v2
On Fri, 2016-08-05 at 13:07 -0400, Tejun Heo wrote: > 2-2. Impact on CPU Controller > > As indicated earlier, the CPU controller's resource distribution graph > is the simplest. Every schedulable resource consumption can be > attributed to a specific task. In addition, for weight based control, > the per-task priority set through setpriority(2) can be translated to > and from a per-cgroup weight. As such, the CPU controller can treat a > task and a cgroup symmetrically, allowing support for any tree layout > of cgroups and tasks. Both process granularity and the no internal > process constraint restrict how the CPU controller can be used. Not only the cpu controller, but also cpuacct and cpuset. > 2-2-1. Impact of Process Granularity > > Process granularity prevents tasks belonging to the same process to > be assigned to different cgroups. It was pointed out [6] that this > excludes the valid use case of hierarchical CPU distribution within > processes. Does that not obsolete the rather useful/common concept "thread pool"? > 2-2-2. Impact of No Internal Process Constraint > > The no internal process constraint disallows tasks from competing > directly against cgroups. Here is an excerpt from Peter Zijlstra > pointing out the issue [10] - R, L and A are cgroups; t1, t2, t3 and > t4 are tasks: > > > R > / | \ >t1 t2 A >/ \ > t3 t4 > > > Is fundamentally different from: > > >R > / \ >L A > / \ / \ > t1 t2 t3 t4 > > > Because if in the first hierarchy you add a task (t5) to R, all of > its A will run at 1/4th of total bandwidth where before it had > 1/3rd, whereas with the second example, if you add our t5 to L, A > doesn't get any less bandwidth. > > > It is true that the trees are semantically different from each other > and the symmetric handling of tasks and cgroups is aesthetically > pleasing. However, it isn't clear what the practical usefulness of > a layout with direct competition between tasks and cgroups would be, > considering that number and behavior of tasks are controlled by each > application, and cgroups primarily deal with system level resource > distribution; changes in the number of active threads would directly > impact resource distribution. Real world use cases of such layouts > could not be established during the discussions. You apparently intend to ignore any real world usages that don't work with these new constraints. Priority and affinity are not process wide attributes, never have been, but you're insisting that so they must become for the sake of progress. I mentioned a real world case of a thread pool servicing customer accounts by doing something quite sane: hop into an account (cgroup), do work therein, send bean count off to the $$ department, wash, rinse repeat. That's real world users making real world cash registers go ka -ching so real world people can pay their real world bills. I also mentioned breakage to cpusets: given exclusive set A and exclusive subset B therein, there is one and only one spot where affinity A exists... at the to be forbidden junction of A and B. As with the thread pool, process granularity makes it impossible for any threaded application affinity to be managed via cpusets, such as say stuffing realtime critical threads into a shielded cpuset, mundane threads into another. There are any number of affinity usages that will break. Try as I may, I can't see anything progressive about enforcing process granularity of per thread attributes. I do see regression potential for users of these controllers, and no viable means to even report them as being such. It will likely be systemd flipping the V2 on switch, not the kernel, not the user. Regression reports would thus presumably be deflected to... those who want this. Sweet. -Mike
[PATCH v8 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook
Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for stable branches) into it's own function, and
add an appropriate display function hook for it.
Based off of Matt Rope's suggestions
Changes since v1:
- Drop pipe_config->base.active check in intel_update_crtcs() since we
check that before calling the function
Signed-off-by: Lyude
Reviewed-by: Matt Roper
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_display.c | 74 +---
2 files changed, 54 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb449f6..c40d5c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -630,6 +630,8 @@ struct drm_i915_display_funcs {
struct intel_crtc_state *crtc_state);
void (*crtc_enable)(struct drm_crtc *crtc);
void (*crtc_disable)(struct drm_crtc *crtc);
+ void (*update_crtcs)(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask);
void (*audio_codec_enable)(struct drm_connector *connector,
struct intel_encoder *encoder,
const struct drm_display_mode
*adjusted_mode);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 744eeb4..980b6fd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13618,6 +13618,52 @@ static bool needs_vblank_wait(struct intel_crtc_state
*crtc_state)
return false;
}
+static void intel_update_crtc(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ struct drm_crtc_state *old_crtc_state,
+ unsigned int *crtc_vblank_mask)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc->state);
+ bool modeset = needs_modeset(crtc->state);
+
+ if (modeset) {
+ update_scanline_offset(intel_crtc);
+ dev_priv->display.crtc_enable(crtc);
+ } else {
+ intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
+ }
+
+ if (drm_atomic_get_existing_plane_state(state, crtc->primary)) {
+ intel_fbc_enable(
+ intel_crtc, pipe_config,
+ to_intel_plane_state(crtc->primary->state));
+ }
+
+ drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
+
+ if (needs_vblank_wait(pipe_config))
+ *crtc_vblank_mask |= drm_crtc_mask(crtc);
+}
+
+static void intel_update_crtcs(struct drm_atomic_state *state,
+ unsigned int *crtc_vblank_mask)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_crtc_state;
+ int i;
+
+ for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
+ if (!crtc->state->active)
+ continue;
+
+ intel_update_crtc(crtc, state, old_crtc_state,
+ crtc_vblank_mask);
+ }
+}
+
static void intel_atomic_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
@@ -13717,17 +13763,9 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
intel_modeset_verify_disabled(dev);
}
- /* Now enable the clocks, plane, pipe, and connectors that we set up. */
+ /* Complete the events for pipes that have now been disabled */
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
- struct intel_crtc_state *pipe_config =
- to_intel_crtc_state(crtc->state);
-
- if (modeset && crtc->state->active) {
- update_scanline_offset(to_intel_crtc(crtc));
- dev_priv->display.crtc_enable(crtc);
- }
/* Complete events for now disable pipes here. */
if (modeset && !crtc->state->active && crtc->state->event) {
@@ -13737,21 +13775,11 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
crtc->state->event = NULL;
}
-
-
Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy
Am Samstag, 6. August 2016, 19:45:51 CEST schrieb Jason Cooper: Hi Jason, > Hi Stephan, > > On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote: > > Hi Ted, Herbert, > > > > I sent a question to the ATH9K RNG some time ago to the developers. > > See > > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg19115.html > > > > I have not yet received a word and I think this issue should be resolved. > > > > Thanks > > Stephan > > > > ---8<--- > > If the above text is placed below the three dashes, "---", below ... > > > The ATH9K driver implements an RNG which is completely bypassing the > > standard Linux HW generator logic. > > > > The RNG may or may not deliver entropy. Considering the conservative > > approach in treating entropy with respect to non-auditable sources, this > > patch changes the delivered entropy value to zero. The RNG still feeds > > data into the input_pool but it is assumed to have no entropy. > > > > When the ATH9K RNG changes to use the HW RNG framework, it may re-enable > > the entropy estimation considering that a user can change that value at > > boot and runtime. > > > > Signed-off-by: Stephan Mueller > > --- > > here, then the mail can be applied directly without editing. Thank you for the hint. I will resend the patch that can be applied. > > > drivers/net/wireless/ath/ath9k/rng.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/net/wireless/ath/ath9k/rng.c > > b/drivers/net/wireless/ath/ath9k/rng.c index d38e50f..d63dc48 100644 > > --- a/drivers/net/wireless/ath/ath9k/rng.c > > +++ b/drivers/net/wireless/ath/ath9k/rng.c > > @@ -92,8 +92,7 @@ static int ath9k_rng_kthread(void *data) > > > > fail_stats = 0; > > > > /* sleep until entropy bits under write_wakeup_threshold */ > > > > - add_hwgenerator_randomness((void *)rng_buf, bytes_read, > > - ATH9K_RNG_ENTROPY(bytes_read)); > > This is the only use of this macro. I'd remove the #define on line 25 > as well. My idea for leaving it was that folks who would bring the RNG into the hwrandom framework could reuse the ideas from the original authors. What about commenting it out with #if 0 ? > > > + add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0); > > > > } > > > > kfree(rng_buf); > > Other than that, > > Reviewed-by: Jason Cooper Thank you. > > thx, > > Jason. -- Ciao Stephan
Re: [RFC][PATCH 0/4] SRAM based reboot reason driver for HiKey
On Fri, Aug 5, 2016 at 3:37 PM, Rob Herring wrote: > On Fri, Aug 5, 2016 at 7:46 AM, Vladimir Zapolskiy > wrote: >> Hi John, >> >> On 08/04/2016 02:05 AM, John Stultz wrote: >>> >>> Now that Andy's reboot reason core driver has landed, I wanted >>> to resubmit a reworked version of my SRAM based reboot reason >>> driver. >>> >>> This allows the kernel to communicate to the bootloader what mode >>> it should reboot to using some reserved memory. >>> >>> Feedback would be very much appreciated! >> >> >> in my opinion the taken approach is wrong, and I've already explained >> why and how to rework your driver to shrink the change, please see >> https://lkml.org/lkml/2016/1/27/133 >> >> In this case I think that a SRAM device node should just contain >> a plain description of partitions, compatible = "sram-reboot-mode" is >> clearly not a device on "SRAM bus", it is not a device at all, so >> please let's separate policy from mechanism > > Having a 2nd node for the driver is still not a device on a bus. It > adds unneeded complexity to the binding IMO. > > The current approach also follows the model ramoops is using. Right > now it's using reserved-memory, but that could easily be extended to > SRAM region as well. > >> Because my proposed alternative approach separates policy from >> mechanism, it for instanse allows to avoid overlappings on SRAM areas, >> and still other drivers may serve as consumers of partitions on SRAM. > > You could still have multiple consumers and having a compatible string > doesn't necessarily imply a driver. Though multiple consumers without > something arbitrating access sounds like broken design to me. So after running into some issues implementing the feedback that Bjorn suggested, I realized we were going to need to not only extend the sram driver to probe children, but we'd also have to make it a mfd so it wouldn't reserve the entire range and the reboot reason driver could map the memory. That on top of the fact that we're already duplicating much of the syscon-reboot-mode driver to work on sram, I decided to just start over and use the syscon driver, which works fine here. All that is needed is just adding it to the dts. I know that its not exactly correct usage of the syscon driver, but it starts to feel crazy almost completely duplicating the syscon driver just to have it named sram. thanks -john
[PATCH v2 14/14] net: ethernet: ti: cpsw: move ale, cpts and drivers params under cpsw_common
The ale, cpts, version, limit, freq, interrupt pacing parameters
are common per net device that uses the same h/w. So, move them to
common driver structure.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 237 ++---
1 file changed, 106 insertions(+), 131 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index e0a1b80..bd0ea71 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -373,13 +373,19 @@ struct cpsw_common {
struct cpsw_wr_regs __iomem *wr_regs;
u8 __iomem *hw_stats;
struct cpsw_host_regs __iomem *host_port_regs;
+ u32 version;
+ u32 coal_intvl;
+ u32 bus_freq_mhz;
+ int rx_packet_max;
struct cpsw_slave *slaves;
struct cpdma_ctlr *dma;
struct cpdma_chan *txch, *rxch;
+ struct cpsw_ale *ale;
boolquirk_irq;
boolrx_irq_disabled;
booltx_irq_disabled;
u32 irqs_table[IRQ_NUM];
+ struct cpts *cpts;
int intr_dbg_msg;
};
@@ -387,15 +393,9 @@ struct cpsw_priv {
struct net_device *ndev;
struct device *dev;
u32 msg_enable;
- u32 version;
- u32 coal_intvl;
- u32 bus_freq_mhz;
- int rx_packet_max;
u8 mac_addr[ETH_ALEN];
- struct cpsw_ale *ale;
boolrx_pause;
booltx_pause;
- struct cpts *cpts;
u32 emac_port;
struct cpsw_common *cpsw;
};
@@ -505,22 +505,16 @@ static const struct cpsw_stats cpsw_gstrings_stats[] = {
} while (0)
#define cpsw_get_slave_ndev(cpsw, __slave_no__)
\
cpsw->slaves[__slave_no__].ndev
-#define cpsw_get_slave_priv(cpsw, __slave_no__)
\
- (((__slave_no__ < cpsw->data.slaves) && \
- (cpsw->slaves[__slave_no__].ndev)) ?\
- netdev_priv(cpsw->slaves[__slave_no__].ndev) : NULL)\
-#define cpsw_dual_emac_src_port_detect(cpsw, status, priv, ndev, skb) \
+#define cpsw_dual_emac_src_port_detect(cpsw, status, ndev, skb)
\
do {\
if (!cpsw->data.dual_emac) \
break; \
if (CPDMA_RX_SOURCE_PORT(status) == 1) {\
ndev = cpsw_get_slave_ndev(cpsw, 0);\
- priv = netdev_priv(ndev); \
skb->dev = ndev;\
} else if (CPDMA_RX_SOURCE_PORT(status) == 2) { \
ndev = cpsw_get_slave_ndev(cpsw, 1);\
- priv = netdev_priv(ndev); \
skb->dev = ndev;\
} \
} while (0)
@@ -531,11 +525,11 @@ static const struct cpsw_stats cpsw_gstrings_stats[] = {
priv->emac_port;\
int slave_port = cpsw_get_slave_port( \
slave->slave_num); \
- cpsw_ale_add_mcast(priv->ale, addr, \
+ cpsw_ale_add_mcast(cpsw->ale, addr, \
1 << slave_port | ALE_PORT_HOST,\
ALE_VLAN, slave->port_vlan, 0); \
} else {\
- cpsw_ale_add_mcast(priv->ale, addr, \
+ cpsw_ale_add_mcast(cpsw->ale, addr, \
ALE_ALL_PORTS, \
0, 0, 0); \
} \
@@ -548,9 +542,8 @@ static inline int cpsw_get_slave_port(u32 slave_num)
static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
{
- struct cpsw_priv *priv = netdev_priv(ndev);
- struct cpsw_common *cpsw = priv->cpsw
[PATCH v2 08/14] net: ethernet: ti: cpsw: move links on h/w registers to cpsw_common
The pointers on h/w registers are common for every cpsw_private
instance, so no need to hold them for every ndev.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 97 +++---
1 file changed, 53 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index a813bac..6fc22df 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -365,6 +365,10 @@ static inline void slave_write(struct cpsw_slave *slave,
u32 val, u32 offset)
struct cpsw_common {
struct device *dev;
+ struct cpsw_ss_regs __iomem *regs;
+ struct cpsw_wr_regs __iomem *wr_regs;
+ u8 __iomem *hw_stats;
+ struct cpsw_host_regs __iomem *host_port_regs;
};
struct cpsw_priv {
@@ -373,10 +377,6 @@ struct cpsw_priv {
struct napi_struct napi_tx;
struct device *dev;
struct cpsw_platform_data data;
- struct cpsw_ss_regs __iomem *regs;
- struct cpsw_wr_regs __iomem *wr_regs;
- u8 __iomem *hw_stats;
- struct cpsw_host_regs __iomem *host_port_regs;
u32 msg_enable;
u32 version;
u32 coal_intvl;
@@ -658,8 +658,10 @@ static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
static void cpsw_intr_enable(struct cpsw_priv *priv)
{
- __raw_writel(0xFF, &priv->wr_regs->tx_en);
- __raw_writel(0xFF, &priv->wr_regs->rx_en);
+ struct cpsw_common *cpsw = priv->cpsw;
+
+ __raw_writel(0xFF, &cpsw->wr_regs->tx_en);
+ __raw_writel(0xFF, &cpsw->wr_regs->rx_en);
cpdma_ctlr_int_ctrl(priv->dma, true);
return;
@@ -667,8 +669,10 @@ static void cpsw_intr_enable(struct cpsw_priv *priv)
static void cpsw_intr_disable(struct cpsw_priv *priv)
{
- __raw_writel(0, &priv->wr_regs->tx_en);
- __raw_writel(0, &priv->wr_regs->rx_en);
+ struct cpsw_common *cpsw = priv->cpsw;
+
+ __raw_writel(0, &cpsw->wr_regs->tx_en);
+ __raw_writel(0, &cpsw->wr_regs->rx_en);
cpdma_ctlr_int_ctrl(priv->dma, false);
return;
@@ -752,8 +756,9 @@ requeue:
static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
{
struct cpsw_priv *priv = dev_id;
+ struct cpsw_common *cpsw = priv->cpsw;
- writel(0, &priv->wr_regs->tx_en);
+ writel(0, &cpsw->wr_regs->tx_en);
cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
if (priv->quirk_irq) {
@@ -768,9 +773,10 @@ static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
{
struct cpsw_priv *priv = dev_id;
+ struct cpsw_common *cpsw = priv->cpsw;
cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
- writel(0, &priv->wr_regs->rx_en);
+ writel(0, &cpsw->wr_regs->rx_en);
if (priv->quirk_irq) {
disable_irq_nosync(priv->irqs_table[0]);
@@ -785,11 +791,12 @@ static int cpsw_tx_poll(struct napi_struct *napi_tx, int
budget)
{
struct cpsw_priv*priv = napi_to_priv(napi_tx);
int num_tx;
+ struct cpsw_common *cpsw = priv->cpsw;
num_tx = cpdma_chan_process(priv->txch, budget);
if (num_tx < budget) {
napi_complete(napi_tx);
- writel(0xff, &priv->wr_regs->tx_en);
+ writel(0xff, &cpsw->wr_regs->tx_en);
if (priv->quirk_irq && priv->tx_irq_disabled) {
priv->tx_irq_disabled = false;
enable_irq(priv->irqs_table[1]);
@@ -804,11 +811,12 @@ static int cpsw_rx_poll(struct napi_struct *napi_rx, int
budget)
{
struct cpsw_priv*priv = napi_to_priv(napi_rx);
int num_rx;
+ struct cpsw_common *cpsw = priv->cpsw;
num_rx = cpdma_chan_process(priv->rxch, budget);
if (num_rx < budget) {
napi_complete(napi_rx);
- writel(0xff, &priv->wr_regs->rx_en);
+ writel(0xff, &cpsw->wr_regs->rx_en);
if (priv->quirk_irq && priv->rx_irq_disabled) {
priv->rx_irq_disabled = false;
enable_irq(priv->irqs_table[0]);
@@ -929,10 +937,11 @@ static int cpsw_set_coalesce(struct net_device *ndev,
u32 prescale = 0;
u32 addnl_dvdr = 1;
u32 coal_intvl = 0;
+ struct cpsw_common *cpsw = priv->cpsw;
coal_intvl = coal->rx_coalesce_usecs;
- int_ctrl = readl(&priv->wr_regs->int_control);
+ int_ctrl = readl(&cpsw->wr_regs->int_control);
prescale = priv->bus_freq_mhz * 4;
if (!coal->rx_coalesce_usecs) {
@@ -961,15 +970,15 @@ static int cpsw_set_coalesce(struct net_device *ndev,
}
num_interrupts = (1000 * addn
Re: [PATCH v2 2/2] imx53.dtsi : Add DMA configuration for UART
On Thu, Aug 4, 2016 at 7:49 AM, Alexander Shiyan wrote: > Hello. > > UART SDMA has been tested by me for i.MX51. > So, on my opinion, In the first part of the patch, we just need to remove > is_imx6q_uart() > check on and always let the devicetree decide about DMA usage. Yes, agreed.
[PATCH] megaraid_sas: Fix probing cards without io port
Found one megaraid_sas HBA probe fails,
[ 187.235190] scsi host2: Avago SAS based MegaRAID driver
[ 191.112365] megaraid_sas :89:00.0: BAR 0: can't reserve [io
0x-0x00ff]
[ 191.120548] megaraid_sas :89:00.0: IO memory region busy!
and the card has resource like,
[ 125.097714] pci :89:00.0: [1000:005d] type 00 class 0x010400
[ 125.104446] pci :89:00.0: reg 0x10: [io 0x-0x00ff]
[ 125.110686] pci :89:00.0: reg 0x14: [mem 0xce40-0xce40 64bit]
[ 125.118286] pci :89:00.0: reg 0x1c: [mem 0xce30-0xce3f 64bit]
[ 125.125891] pci :89:00.0: reg 0x30: [mem 0xce20-0xce2f pref]
that does not io port resource allocated from BIOS, and kernel can not assign
one as io port shortage.
The driver is only looking for MEM, and should not fail.
It turns out megasas_init_fw() etc are using bar index as mask.
index 1 is used as mask 1, so that pci_request_selected_regions()
is trying to request BAR0 instead of BAR1.
Fix all related reference.
Fixes: b6d5d8808b4c ("megaraid_sas: Use lowest memory bar for SR-IOV VF
support")
Signed-off-by: Yinghai Lu
---
drivers/scsi/megaraid/megaraid_sas_base.c |6 +++---
drivers/scsi/megaraid/megaraid_sas_fusion.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/drivers/scsi/megaraid/megaraid_sas_base.c
===
--- linux-2.6.orig/drivers/scsi/megaraid/megaraid_sas_base.c
+++ linux-2.6/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5037,7 +5037,7 @@ static int megasas_init_fw(struct megasa
/* Find first memory bar */
bar_list = pci_select_bars(instance->pdev, IORESOURCE_MEM);
instance->bar = find_first_bit(&bar_list, sizeof(unsigned long));
- if (pci_request_selected_regions(instance->pdev, instance->bar,
+ if (pci_request_selected_regions(instance->pdev, 1pdev->dev, "IO memory region
busy!\n");
return -EBUSY;
@@ -5339,7 +5339,7 @@ fail_ready_state:
iounmap(instance->reg_set);
fail_ioremap:
- pci_release_selected_regions(instance->pdev, instance->bar);
+ pci_release_selected_regions(instance->pdev, 1reg_set);
- pci_release_selected_regions(instance->pdev, instance->bar);
+ pci_release_selected_regions(instance->pdev, 1reg_set);
- pci_release_selected_regions(instance->pdev, instance->bar);
+ pci_release_selected_regions(instance->pdev, 1
[PATCH v8 0/6] Finally fix watermarks
Latest version of https://patchwork.freedesktop.org/series/10276/ All patches are being resent to keep them in one place. Most of the changes are very minor, with the exception of patch 6. The patches that actually changed: - drm/i915/skl: Add support for the SAGV, fix underrun hangs - drm/i915/skl: Update plane watermarks atomically during plane updates - drm/i915/skl: Update DDB values atomically with wms/plane attrs Lyude (5): drm/i915/skl: Add support for the SAGV, fix underrun hangs drm/i915/skl: Update plane watermarks atomically during plane updates drm/i915/skl: Ensure pipes with changed wms get added to the state drm/i915: Move CRTC updating in atomic_commit into it's own hook drm/i915/skl: Update DDB values atomically with wms/plane attrs Matt Roper (1): drm/i915/gen9: Only copy WM results for changed pipes to skl_hw drivers/gpu/drm/i915/i915_drv.h | 4 + drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_display.c | 197 +++ drivers/gpu/drm/i915/intel_drv.h | 14 ++ drivers/gpu/drm/i915/intel_pm.c | 369 --- drivers/gpu/drm/i915/intel_sprite.c | 6 + 6 files changed, 401 insertions(+), 193 deletions(-) -- 2.7.4
[PATCH v8 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.
With this in mind, up until now we've been updating watermarks on skl
like this:
non-modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- intel_pre_plane_update:
- intel_update_watermarks()
- {vblank happens; new watermarks + old plane values => underrun }
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
}
or
modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- crtc_enable:
- intel_update_watermarks()
- {vblank happens; new watermarks + old plane values => underrun }
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
}
Now we update watermarks atomically like this:
non-modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- intel_pre_plane_update:
- intel_update_watermarks() (wm values aren't written yet)
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
}
modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- crtc_enable:
- intel_update_watermarks() (actual wm values aren't written
yet)
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
}
So this patch moves all of the watermark writes into the right place;
inside of the vblank evasion where we update all of the registers for
each plane. While this patch doesn't fix everything, it does allow us to
update the watermark values in the way the hardware expects us to.
Changes since original patch series:
- Remove mutex_lock/mutex_unlock since they don't do anything and we're
not touching global state
- Move skl_write_cursor_wm/skl_write_plane_wm functions into
intel_pm.c, make externally visible
- Add skl_write_plane_wm calls to skl_update_plane
- Fix conditional for for loop in skl_write_plane_wm (level < max_level
should be level <= max_level)
- Make diagram in commit more accurate to what's actually happening
- Add Fixes:
Changes since v1:
- Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
then just Skylake
- Update description to make it clear this patch doesn't fix everything
- Check if pipes were actually changed before writing watermarks
Changes since v2:
- Write PIPE_WM_LINETIME during vblank evasion
Changes since v3:
- Rebase against new SAGV patch changes
Changes since v4:
- Add a parameter to choose what skl_wm_values struct to use when
writing new plane watermarks
Changes since v5:
- Remove cursor ddb entry write in skl_write_cursor_wm(), defer until
patch 6
- Write WM_LINETIME in intel_begin_crtc_commit()
Changes since v6:
- Remove redundant dirty_pipes check in skl_write_plane_wm (we check
this in all places where we call this function, and it was supposed
to have been removed earlier anyway)
- In i9xx_update_cursor(), use dev_priv->info.gen >= 9 instead of
IS_GEN9(dev_priv). We do this everywhere else and I'd imagine this
needs to be done for gen10 as well
Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
---
drivers/gpu/drm/i915/intel_display.c | 16 +++-
drivers/gpu/drm/i915/intel_drv.h | 5
drivers/gpu/drm/i915/intel_pm.c | 50
drivers/gpu/drm/i915/intel_sprite.c | 6 +
4 files changed, 60 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 814d07d..744eeb4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2980,6 +2980,7 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct skl_wm_values *wm = &dev_priv->wm.skl_results;
int pipe = intel_crtc->pipe;
u32 plane_ctl, stride_div, stride;
u32 tile_height, plane_offset, plane_size;
@@ -3
[PATCH v8 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
other pipes remain 0. Thus a blind copy of the entire skl_wm_values
structure will clobber the values for unchanged pipes...we need to be
more selective and only copy over the values for the changing pipes.
This mistake was hidden until recently due to another bug that caused us
to erroneously re-calculate watermarks for all active pipes rather than
changing pipes. Only when that bug was fixed was the impact of this bug
discovered (e.g., modesets failing with "Requested display configuration
exceeds system watermark limitations" messages and leaving watermarks
non-functional, even ones initiated by intel_fbdev_restore_mode).
Changes since v1:
- Add a function for copying a pipe's wm values
(skl_copy_wm_for_pipe()) so we can reuse this later
Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 'check'
(v2)")
Fixes: 9b6130227495 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
Signed-off-by: Matt Roper
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
---
drivers/gpu/drm/i915/intel_pm.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0c52c50..cb1cab0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4066,6 +4066,24 @@ skl_compute_ddb(struct drm_atomic_state *state)
return 0;
}
+static void
+skl_copy_wm_for_pipe(struct skl_wm_values *dst,
+struct skl_wm_values *src,
+enum pipe pipe)
+{
+ dst->wm_linetime[pipe] = src->wm_linetime[pipe];
+ memcpy(dst->plane[pipe], src->plane[pipe],
+ sizeof(dst->plane[pipe]));
+ memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
+ sizeof(dst->plane_trans[pipe]));
+
+ dst->ddb.pipe[pipe] = src->ddb.pipe[pipe];
+ memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
+ sizeof(dst->ddb.y_plane[pipe]));
+ memcpy(dst->ddb.plane[pipe], src->ddb.plane[pipe],
+ sizeof(dst->ddb.plane[pipe]));
+}
+
static int
skl_compute_wm(struct drm_atomic_state *state)
{
@@ -4138,8 +4156,10 @@ static void skl_update_wm(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct skl_wm_values *results = &dev_priv->wm.skl_results;
+ struct skl_wm_values *hw_vals = &dev_priv->wm.skl_hw;
struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
struct skl_pipe_wm *pipe_wm = &cstate->wm.skl.optimal;
+ int pipe;
if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
return;
@@ -4151,8 +4171,12 @@ static void skl_update_wm(struct drm_crtc *crtc)
skl_write_wm_values(dev_priv, results);
skl_flush_wm_values(dev_priv, results);
- /* store the new configuration */
- dev_priv->wm.skl_hw = *results;
+ /*
+* Store the new configuration (but only for the pipes that have
+* changed; the other values weren't recomputed).
+*/
+ for_each_pipe_masked(dev_priv, pipe, results->dirty_pipes)
+ skl_copy_wm_for_pipe(hw_vals, results, pipe);
mutex_unlock(&dev_priv->wm.wm_mutex);
}
--
2.7.4
[PATCH v8 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:
- Get a laptop with a skylake GPU, and hook up two external monitors to
it
- Move the cursor from the built-in LCD to one of the external displays
as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
just freeze.
After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:
"The display engine access to system memory is blocked during the
adjustment time. SAGV defaults to enabled. Software must use the
GT-driver pcode mailbox to disable SAGV when the display engine is not
able to tolerate the blocking time."
The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.
Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s. Additionally,
the bspec mentions turning off the SAGV with more then one pipe enabled
as a workaround for display underruns. While this patch doesn't entirely
fix that, it looks like it does improve the situation a little bit so
it's likely this is going to be required to make watermarks on Skylake
fully functional.
Changes since v8:
- Add intel_state->modeset guard to the conditional for
skl_enable_sagv()
Changes since v7:
- Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's
all we use it for anyway)
- Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification
- Fix a styling error that snuck past me
Changes since v6:
- Protect skl_enable_sagv() with intel_state->modeset conditional in
intel_atomic_commit_tail()
Changes since v5:
- Don't use is_power_of_2. Makes things confusing
- Don't use the old state to figure out whether or not to
enable/disable the sagv, use the new one
- Split the loop in skl_disable_sagv into it's own function
- Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail()
Changes since v4:
- Use is_power_of_2 against active_crtcs to check whether we have > 1
pipe enabled
- Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
enabled
- Call skl_sagv_enable/disable() from pre/post-plane updates
Changes since v3:
- Use time_before() to compare timeout to jiffies
Changes since v2:
- Really apply minor style nitpicks to patch this time
Changes since v1:
- Added comments about this probably being one of the requirements to
fixing Skylake's watermark issues
- Minor style nitpicks from Matt Roper
- Disable these functions on Broxton, since it doesn't have an SAGV
Reviewed-by: Matt Roper
Reviewed-by: Maarten Lankhorst
Signed-off-by: Lyude
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 4 ++
drivers/gpu/drm/i915/intel_display.c | 11
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pm.c | 112 +++
5 files changed, 131 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index feec00f..eb449f6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1948,6 +1948,8 @@ struct drm_i915_private {
struct i915_suspend_saved_registers regfile;
struct vlv_s0ix_state vlv_s0ix_state;
+ bool skl_sagv_enabled;
+
struct {
/*
* Raw watermark latency values:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f38a5e2..f7e0bc2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7170,6 +7170,10 @@ enum {
#define HSW_PCODE_DE_WRITE_FREQ_REQ 0x17
#define DISPLAY_IPS_CONTROL 0x19
#define HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL 0x1A
+#define GEN9_PCODE_SAGV_CONTROL 0x21
+#define GEN9_SAGV_DISABLE 0x0
+#define GEN9_SAGV_IS_DISABLED 0x1
+#define GEN9_SAGV_DYNAMIC_FREQ 0x3
#define GEN6_PCODE_DATA_MMIO(0x138128)
#define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
#define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9cbf543..814d07d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13698,6 +13698,14 @@
[PATCH v8 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.
The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.
The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:
We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:
| A | B |xxx|
Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.
1. Flush pipes with new allocation contained into old space. None
apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
giving us the following update order: A, B
This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.
As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().
This long overdue patch fixes the rest of the underruns on Skylake.
Changes since v1:
- Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
Changes since v2:
- Use the method for updating CRTCs that Ville suggested
- In skl_update_wm(), only copy the watermarks for the crtc that was
passed to us
Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
Signed-off-by: Lyude
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
Cc: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 100 +++--
drivers/gpu/drm/i915/intel_drv.h | 7 ++
drivers/gpu/drm/i915/intel_pm.c | 207 +--
3 files changed, 144 insertions(+), 170 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 980b6fd..ad5f6e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12903,16 +12903,23 @@ static void verify_wm_state(struct drm_crtc *crtc,
hw_entry->start, hw_entry->end);
}
- /* cursor */
- hw_entry = &hw_ddb.plane[pipe][PLANE_CURSOR];
- sw_entry = &sw_ddb->plane[pipe][PLANE_CURSOR];
-
- if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
- DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe),
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+ /*
+* cursor
+* If the cursor plane isn't active, we may not have updated it's ddb
+* allocation. In that case since the ddb allocation will be updated
+* once the plane becomes visible, we can skip this check
+*/
+ if (intel_crtc->cursor_addr) {
+ hw_entry = &hw_ddb.plane[pipe][PLANE_CURSOR];
+ sw_entry = &sw_ddb->plane[pipe][PLANE_CURSOR];
+
+ if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
+ DRM_ERROR("mismatch in DDB state pipe %c cursor "
+ "(expected (%u,%u), found (%u,%u))\n",
+ pipe_name(pipe),
+ sw_entry->start, sw_entry->end,
+ hw_entry->start, hw_entry->end);
+ }
}
}
@@ -13664,6 +13671,72 @@ static void intel_update_crtcs(struct drm_atomic_state
*state,
}
}
+static void skl_update_crtcs(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask)
+{
+ struct drm_device *dev = state->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_crtc_state;
+ struct skl_ddb_allocation *new_ddb = &intel_state->wm_results.ddb;
+ struct skl_ddb_allocation cur_ddb;
+ bool progress;
+ bool reallocated[I915_MAX_PIPES] = {};
+ enum pipe pipe;
+ int wait_vbl_pipes,
[GIT PULL] arch/sh updates for 4.8
Hi Linus, Please pull these changes for arch/sh. They're based off a commit in your current tree to resolve conflicts with 726328d92a (locking/spinlock, arch: Update and fix spin_unlock_wait() implementations). The J-Core arch support is included here but to be usable it needs drivers that are waiting on approval/inclusion from their subsystem maintainers. Rich -- The following changes since commit 7f155c702677d057d03b192ce652311de5434697: Merge tag 'nfs-for-4.8-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs (2016-07-30 16:33:25 -0700) are available in the git repository at: git://git.libc.org/linux-sh tags/sh-for-4.8 for you to fetch changes up to e61c10e468a42512f5fad74c00b62af5cc19f65f: sh: add device tree source for J2 FPGA on Mimas v2 board (2016-08-05 03:38:26 +) These changes improve device tree support (including builtin DTB), add support for the J-Core J2 processor, an open source synthesizable reimplementation of the SH-2 ISA, resolve a longstanding sigcontext ABI mismatch issue, and fix various bugs including nommu-specific issues and minor regressions introduced in 4.6. Markus Elfring (1): sh: Delete unnecessary checks before the function call "mempool_destroy" Pan Xinhui (1): sh: cmpxchg: fix a bit shift bug in big_endian os Paul Gortmaker (4): sh: make time.c explicitly non-modular sh: make mm/asids-debugfs explicitly non-modular sh: make board-secureedge5410 explicitly non-modular sh: make heartbeat driver explicitly non-modular Rich Felker (16): sh: add support for linking a builtin device tree blob in the kernel sh: make sigcontext definition consistent across fpu/nofpu models sh: disable aliased page logic on NOMMU models sh: fix futex/robust_list on nommu models sh: allow clocksource drivers to register sched_clock backends sh: fix build regression with CONFIG_OF && !CONFIG_OF_FLATTREE sh: add support for J-Core J2 processor sh: add AT_HWCAP flag for J-Core cas.l instruction sh: add J2 atomics using the cas.l instruction sh: add working futex atomic ops on userspace addresses for smp sh: SMP support for SH2 entry.S sh: add SMP support for J2 sh: do not perform IPI-based cache flush except on boards that need it sh: use common clock framework with device tree boards sh: add defconfig for J-Core J2 sh: add device tree source for J2 FPGA on Mimas v2 board Yoshinori Sato (1): sh: system call wire up arch/sh/Kconfig | 34 + arch/sh/Makefile| 3 + arch/sh/boards/Kconfig | 1 + arch/sh/boards/board-secureedge5410.c | 3 +- arch/sh/boards/of-generic.c | 15 ++- arch/sh/boot/dts/Makefile | 3 + arch/sh/boot/dts/j2_mimas_v2.dts| 96 ++ arch/sh/configs/j2_defconfig| 40 ++ arch/sh/drivers/heartbeat.c | 32 + arch/sh/include/asm/atomic.h| 8 ++ arch/sh/include/asm/barrier.h | 5 + arch/sh/include/asm/bitops-cas.h| 93 + arch/sh/include/asm/bitops.h| 2 + arch/sh/include/asm/cmpxchg-cas.h | 24 arch/sh/include/asm/cmpxchg-xchg.h | 2 +- arch/sh/include/asm/cmpxchg.h | 2 + arch/sh/include/asm/futex-cas.h | 34 + arch/sh/include/asm/futex-irq.h | 86 arch/sh/include/asm/futex-llsc.h| 41 ++ arch/sh/include/asm/futex.h | 97 -- arch/sh/include/asm/processor.h | 2 +- arch/sh/include/asm/spinlock-cas.h | 117 + arch/sh/include/asm/spinlock-llsc.h | 224 arch/sh/include/asm/spinlock.h | 222 +-- arch/sh/include/uapi/asm/cpu-features.h | 1 + arch/sh/include/uapi/asm/sigcontext.h | 3 - arch/sh/include/uapi/asm/unistd_32.h| 16 ++- arch/sh/include/uapi/asm/unistd_64.h| 16 ++- arch/sh/kernel/cpu/clock.c | 4 + arch/sh/kernel/cpu/init.c | 6 +- arch/sh/kernel/cpu/proc.c | 1 + arch/sh/kernel/cpu/sh2/Makefile | 4 + arch/sh/kernel/cpu/sh2/entry.S | 55 arch/sh/kernel/cpu/sh2/probe.c | 39 +- arch/sh/kernel/cpu/sh2/smp-j2.c | 139 arch/sh/kernel/dwarf.c | 6 +- arch/sh/kernel/head_32.S| 6 +- arch/sh/kernel/setup.c | 6 +- arch/sh/kernel/syscalls_32.S| 14 ++ arch/sh/kernel/syscalls_64.S| 14 ++ arch/sh/kernel/time.c | 3 +- arch/sh/mm/Makefile | 3 +- arch/sh/mm/asids-debugfs.c | 5 +- arch/sh/mm/cache-j2.c
[PATCH v8 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state
If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: sta...@vger.kernel.org Cc: Ville Syrjälä Cc: Daniel Vetter Cc: Radhakrishna Sripada Cc: Hans de Goede --- drivers/gpu/drm/i915/intel_pm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index e539a41..3f23e5e 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4079,6 +4079,10 @@ skl_compute_ddb(struct drm_atomic_state *state) ret = skl_allocate_pipe_ddb(cstate, ddb); if (ret) return ret; + + ret = drm_atomic_add_affected_planes(state, &intel_crtc->base); + if (ret) + return ret; } return 0; -- 2.7.4
Re: [GIT PULL for v4.8-rc1] mailcap fixup for two entries
On Sat, 2016-08-06 at 07:35 -0300, Mauro Carvalho Chehab wrote: > Hi Linus, > > Please pull from my tree for a small fixup on my entry and Shuah's entry at > .mailcap. > > Basically, those entries were with a syntax that makes get_maintainer.pl to > do the wrong thing. > > Thanks! > Mauro .mailmap The old entries were simply improper. git shortlog wasn't doing the right thing either.
Re: [PATCH 2/4] tools lib traceevent: Use USECS_PER_SEC instead of hardcoded number
Em Fri, Aug 05, 2016 at 03:15:28PM -0400, Steven Rostedt escreveu: > On Fri, 5 Aug 2016 15:36:55 -0300 > Arnaldo Carvalho de Melo wrote: > > > > [acme@jouet linux]$ cat tools/include/linux/time64.h > > #ifndef _TOOLS_LINUX_TIME64_H > > #define _TOOLS_LINUX_TIME64_H > > > > #define MSEC_PER_SEC1000L > > #define USEC_PER_MSEC 1000L > > #define NSEC_PER_USEC 1000L > > #define NSEC_PER_MSEC 100L > > #define USEC_PER_SEC100L > > #define NSEC_PER_SEC10L > > #define FSEC_PER_SEC1000LL > > > > #endif /* _TOOLS_LINUX_TIME64_H */ > > [acme@jouet linux]$ > > > > So the header to include is the same as in the kernel, the constants as > > well. We can go on adding more stuff from include/linux/time64.h as > > tools use it. > > OK, can you modify the scripting-engines/trace-event-*.c to use that > too. I'm going to move the macros locally into event-parse.c, as I work > to make that ready to be a separate library. Ok, and I fix a few more, pushing to perf/core. > Thanks! > > -- Steve
[PATCH v2 11/14] net: ethernet: ti: cpsw: move data platform data and slaves info to cpsw_common
These data are common per net dev. No need to hold it in every priv
instance, so move them under cpsw_common.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 271 +
1 file changed, 140 insertions(+), 131 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 4080487..29ff489 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -140,9 +140,9 @@ do {
\
#define CPSW_CMINTMAX_INTVL(1000 / CPSW_CMINTMIN_CNT)
#define CPSW_CMINTMIN_INTVL((1000 / CPSW_CMINTMAX_CNT) + 1)
-#define cpsw_slave_index(priv) \
- ((priv->data.dual_emac) ? priv->emac_port : \
- priv->data.active_slave)
+#define cpsw_slave_index(cpsw, priv) \
+ ((cpsw->data.dual_emac) ? priv->emac_port : \
+ cpsw->data.active_slave)
#define IRQ_NUM2
static int debug_level;
@@ -366,10 +366,12 @@ static inline void slave_write(struct cpsw_slave *slave,
u32 val, u32 offset)
struct cpsw_common {
struct device *dev;
+ struct cpsw_platform_data data;
struct cpsw_ss_regs __iomem *regs;
struct cpsw_wr_regs __iomem *wr_regs;
u8 __iomem *hw_stats;
struct cpsw_host_regs __iomem *host_port_regs;
+ struct cpsw_slave *slaves;
struct cpdma_ctlr *dma;
struct cpdma_chan *txch, *rxch;
boolquirk_irq;
@@ -383,14 +385,12 @@ struct cpsw_priv {
struct napi_struct napi_rx;
struct napi_struct napi_tx;
struct device *dev;
- struct cpsw_platform_data data;
u32 msg_enable;
u32 version;
u32 coal_intvl;
u32 bus_freq_mhz;
int rx_packet_max;
u8 mac_addr[ETH_ALEN];
- struct cpsw_slave *slaves;
struct cpsw_ale *ale;
boolrx_pause;
booltx_pause;
@@ -492,40 +492,41 @@ static const struct cpsw_stats cpsw_gstrings_stats[] = {
#define for_each_slave(priv, func, arg...) \
do {\
struct cpsw_slave *slave; \
+ struct cpsw_common *cpsw = (priv)->cpsw;\
int n; \
- if (priv->data.dual_emac) \
- (func)((priv)->slaves + priv->emac_port, ##arg);\
+ if (cpsw->data.dual_emac) \
+ (func)((cpsw)->slaves + priv->emac_port, ##arg);\
else\
- for (n = (priv)->data.slaves, \
- slave = (priv)->slaves; \
+ for (n = cpsw->data.slaves, \
+ slave = cpsw->slaves; \
n; n--) \
(func)(slave++, ##arg); \
} while (0)
-#define cpsw_get_slave_ndev(priv, __slave_no__)
\
- priv->slaves[__slave_no__].ndev
-#define cpsw_get_slave_priv(priv, __slave_no__)
\
- (((__slave_no__ < priv->data.slaves) && \
- (priv->slaves[__slave_no__].ndev)) ?\
- netdev_priv(priv->slaves[__slave_no__].ndev) : NULL)\
-
-#define cpsw_dual_emac_src_port_detect(status, priv, ndev, skb)
\
+#define cpsw_get_slave_ndev(cpsw, __slave_no__)
\
+ cpsw->slaves[__slave_no__].ndev
+#define cpsw_get_slave_priv(cpsw, __slave_no__)
\
+ (((__slave_no__ < cpsw->data.slaves) && \
+ (cpsw->slaves[__slave_no__].ndev)) ?\
+ netdev_priv(cpsw->slaves[__slave_no__].ndev) : NULL)\
+
+#define cpsw_dual_emac_src_port_detect(cpsw, status, priv, ndev, skb) \
do {\
- if (!priv->data.dual_emac) \
+ if (!cpsw->data.dual_emac) \
[PATCH v2 05/14] net: ethernet: ti: cpsw: don't check slave num in runtime
No need to check const slave num in runtime for every packet,
and ndev for slaves w/o ndev is anyway NULL. So remove redundant
check.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 70a9570..19aa4bb 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -498,8 +498,7 @@ static const struct cpsw_stats cpsw_gstrings_stats[] = {
(func)(slave++, ##arg); \
} while (0)
#define cpsw_get_slave_ndev(priv, __slave_no__)
\
- ((__slave_no__ < priv->data.slaves) ? \
- priv->slaves[__slave_no__].ndev : NULL)
+ priv->slaves[__slave_no__].ndev
#define cpsw_get_slave_priv(priv, __slave_no__)
\
(((__slave_no__ < priv->data.slaves) && \
(priv->slaves[__slave_no__].ndev)) ?\
--
1.9.1
Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy
Hi Stephan, On Sat, Aug 06, 2016 at 10:03:58PM +0200, Stephan Mueller wrote: > Am Samstag, 6. August 2016, 19:45:51 CEST schrieb Jason Cooper: > > On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote: ... > > > diff --git a/drivers/net/wireless/ath/ath9k/rng.c > > > b/drivers/net/wireless/ath/ath9k/rng.c index d38e50f..d63dc48 100644 > > > --- a/drivers/net/wireless/ath/ath9k/rng.c > > > +++ b/drivers/net/wireless/ath/ath9k/rng.c > > > @@ -92,8 +92,7 @@ static int ath9k_rng_kthread(void *data) > > > > > > fail_stats = 0; > > > > > > /* sleep until entropy bits under write_wakeup_threshold */ > > > > > > - add_hwgenerator_randomness((void *)rng_buf, bytes_read, > > > -ATH9K_RNG_ENTROPY(bytes_read)); > > > > This is the only use of this macro. I'd remove the #define on line 25 > > as well. > > My idea for leaving it was that folks who would bring the RNG into the > hwrandom framework could reuse the ideas from the original authors. > > What about commenting it out with #if 0 ? #if 0 is frowned upon. If that calculation is documented somewhere, then it can be redone from the spec. If it isn't, then I'd be curious to know where it came from. Perhaps one of the ath9k devs can point to a document containing the formula? We could put the reference in a comment. thx, Jason.
Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac
On 08/04/2016 08:43 PM, Michael Ellerman wrote:
> York Sun writes:
>
>> Two symbols are missing if mpc85xx_edac driver is compiled as module.
>>
>> Signed-off-by: York Sun
>>
>> ---
>> Change log
>> v3: Change subject tag
>> v2: no change
>>
>> arch/powerpc/kernel/pci-common.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/powerpc/kernel/pci-common.c
>> b/arch/powerpc/kernel/pci-common.c
>> index 0f7a60f..86bc484 100644
>> --- a/arch/powerpc/kernel/pci-common.c
>> +++ b/arch/powerpc/kernel/pci-common.c
>> @@ -226,6 +226,7 @@ struct pci_controller*
>> pci_find_hose_for_OF_device(struct device_node* node)
>> }
>> return NULL;
>> }
>> +EXPORT_SYMBOL(pci_find_hose_for_OF_device);
>>
>> /*
>> * Reads the interrupt pin to determine if interrupt is use by card.
>> @@ -1585,6 +1586,7 @@ int early_find_capability(struct pci_controller *hose,
>> int bus, int devfn,
>> {
>> return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
>> }
>> +EXPORT_SYMBOL(early_find_capability);
>
> Does the driver really need to use these routines? They're meant for use
> early in boot, before PCI is setup.
>
> AFAICS this is just a regular driver, so when it's probed the PCI
> devices should have already been scanned. In which case pci_get_device()
> could work couldn't it? (I see other edac drivers doing that).
I am trying to fix this but need some help. We are dealing with PCIe
controller here. Does it have a bus number assigned at this point? If
yes, how can I find it? I seem not able to find out where the
platform_data is filled as well. Can someone kindly point it out to me?
York
[PATCH v2 0/3] sched: Avoid that __wait_on_bit_lock() hangs
Hello Ingo, This patch series addresses an issue that my SRP driver test software can trigger reproducibly, namely that __wait_on_bit_lock() hangs. Please review and apply these patches whenever this is convenient for you. The changes compared to the first version of this series are: * Reworked the abort_exclusive_wait() changes. * Added two patches, namely a patch that introduces a local variable and a patch (nr. 3) that eliminates again the spurious wakeups introduced by patch 1. These patches have been tested on top of kernel v4.7 with kernel debugging enabled (detection of list corruption, lockdep, SLUB debugging, kmemleak, ...). See also https://lkml.org/lkml/2016/8/3/289. Thanks, Bart.
[PATCH 1/2] f2fs: clean up bio cache trace
From: Chao Yu
Trace info related to bio cache operation is out of format, clean up it.
Before:
<...>-28308 [002] 4781.052703: f2fs_submit_write_bio: dev =
(251,1), WRITEWRITE_SYNC ^H, DATA, sector = 271424, size = 126976
<...>-28308 [002] 4781.052820: f2fs_submit_page_mbio: dev =
(251,1), ino = 103, page_index = 0x1f, oldaddr = 0x, newaddr = 0x84a7
rw = WRITEWRITE_SYNCi ^H, type = DATA
kworker/u8:2-29988 [001] 5549.293877: f2fs_submit_page_mbio: dev =
(251,1), ino = 91, page_index = 0xd, oldaddr = 0x, newaddr = 0x782f rw
= WRITE0x0i ^H type = DATA
After:
kworker/u8:2-8678 [000] 7945.124459: f2fs_submit_write_bio: dev =
(251,1), rw = WRITE_SYNC, DATA, sector = 74080, size = 53248
kworker/u8:2-8678 [000] 7945.124551: f2fs_submit_page_mbio: dev =
(251,1), ino = 11, page_index = 0xec, oldaddr = 0x, newaddr = 0x243a,
rw = WRITE, type = DATA
Signed-off-by: Chao Yu
---
include/trace/events/f2fs.h | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h
index ff95fd0..903a091 100644
--- a/include/trace/events/f2fs.h
+++ b/include/trace/events/f2fs.h
@@ -58,16 +58,12 @@ TRACE_DEFINE_ENUM(CP_DISCARD);
#define F2FS_BIO_FLAG_MASK(t) (t & (REQ_RAHEAD | WRITE_FLUSH_FUA))
#define F2FS_BIO_EXTRA_MASK(t) (t & (REQ_META | REQ_PRIO))
-#define show_bio_type(op, op_flags) show_bio_op(op), \
- show_bio_op_flags(op_flags), show_bio_extra(op_flags)
-
-#define show_bio_op(op)
\
- __print_symbolic(op,\
- { READ, "READ" }, \
- { WRITE,"WRITE" })
+#define show_bio_type(op_flags)show_bio_op_flags(op_flags),
\
+ show_bio_extra(op_flags)
#define show_bio_op_flags(flags) \
__print_symbolic(F2FS_BIO_FLAG_MASK(flags), \
+ { 0,"WRITE" }, \
{ REQ_RAHEAD, "READAHEAD" }, \
{ READ_SYNC,"READ_SYNC" }, \
{ WRITE_SYNC, "WRITE_SYNC" }, \
@@ -754,12 +750,12 @@ DECLARE_EVENT_CLASS(f2fs__submit_page_bio,
),
TP_printk("dev = (%d,%d), ino = %lu, page_index = 0x%lx, "
- "oldaddr = 0x%llx, newaddr = 0x%llx rw = %s%si%s, type = %s",
+ "oldaddr = 0x%llx, newaddr = 0x%llx, rw = %s%s, type = %s",
show_dev_ino(__entry),
(unsigned long)__entry->index,
(unsigned long long)__entry->old_blkaddr,
(unsigned long long)__entry->new_blkaddr,
- show_bio_type(__entry->op, __entry->op_flags),
+ show_bio_type(__entry->op_flags),
show_block_type(__entry->type))
);
@@ -806,9 +802,9 @@ DECLARE_EVENT_CLASS(f2fs__submit_bio,
__entry->size = bio->bi_iter.bi_size;
),
- TP_printk("dev = (%d,%d), %s%s%s, %s, sector = %lld, size = %u",
+ TP_printk("dev = (%d,%d), rw = %s%s, %s, sector = %lld, size = %u",
show_dev(__entry),
- show_bio_type(__entry->op, __entry->op_flags),
+ show_bio_type(__entry->op_flags),
show_block_type(__entry->type),
(unsigned long long)__entry->sector,
__entry->size)
--
2.7.2
[PATCH 2/2] Revert "f2fs: move i_size_write in f2fs_write_end"
From: Chao Yu This reverts commit a2ee0a300344a6da76186129b078113354fe13d2. When testing with generic/032 of xfstest suit, failure message will be reported as below: generic/032 8s ... [failed, exit status 1] - output mismatch (see results/generic/032.out.bad) --- tests/generic/032.out 2015-01-11 16:52:27.643681072 +0800 +++ results/generic/032.out.bad 2016-08-06 13:44:43.861330500 +0800 @@ -1,5 +1,5 @@ QA output created by 032 -100 iterations -000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd -* -010 +1: [768..775]: unwritten +Unwritten extents found! ... (Run 'diff -u tests/generic/032.out results/generic/032.out.bad' to see the entire diff) Ran: generic/032 Failures: generic/032 Failed 1 of 1 tests In write_end(), we should update i_size of inode before unlock page, otherwise, we will lose newly updated data in following race condition. Thread AThread B - write_end - unlock page - writepages - lock_page - writepage if page is out-of-range of file size, we will skip writting the page. - update i_size Signed-off-by: Chao Yu --- fs/f2fs/data.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index e262427..5bb0bd2 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -1700,11 +1700,11 @@ static int f2fs_write_end(struct file *file, trace_f2fs_write_end(inode, pos, len, copied); set_page_dirty(page); - f2fs_put_page(page, 1); if (pos + copied > i_size_read(inode)) f2fs_i_size_write(inode, pos + copied); + f2fs_put_page(page, 1); f2fs_update_time(F2FS_I_SB(inode), REQ_TIME); return copied; } -- 2.7.2
[PATCH v2 2/3] sched: Introduce a local variable in abort_exclusive_wait()
This patch does not change any functionality.
Signed-off-by: Bart Van Assche
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Johannes Weiner
Cc: Neil Brown
Cc: Michael Shaver
---
kernel/sched/wait.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index fa12939..dcc7693 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -429,18 +429,20 @@ int __sched
__wait_on_bit_lock(wait_queue_head_t *wq, struct wait_bit_queue *q,
wait_bit_action_f *action, unsigned mode)
{
+ struct wait_bit_key *const key = &q->key;
+
do {
int ret;
prepare_to_wait_exclusive(wq, &q->wait, mode);
- if (!test_bit(q->key.bit_nr, q->key.flags))
+ if (!test_bit(key->bit_nr, key->flags))
continue;
- ret = action(&q->key, mode);
+ ret = action(key, mode);
if (!ret)
continue;
- abort_exclusive_wait(wq, &q->wait, mode, &q->key);
+ abort_exclusive_wait(wq, &q->wait, mode, key);
return ret;
- } while (test_and_set_bit(q->key.bit_nr, q->key.flags));
+ } while (test_and_set_bit(key->bit_nr, key->flags));
finish_wait(wq, &q->wait);
return 0;
}
--
2.9.2
[PATCH v2 1/3] sched: Avoid that __wait_on_bit_lock() hangs
If delivery of a signal and __wake_up_common() happen concurrently
it is possible that the signal is delivered after __wake_up_common()
woke up the affected task and before bit_wait_io() checks whether a
signal is pending. Avoid that the next waiter is not woken up if this
happens. This patch fixes the following hang:
INFO: task systemd-udevd:10111 blocked for more than 480 seconds.
Not tainted 4.7.0-dbg+ #1
Call Trace:
[] schedule+0x37/0x90
[] schedule_timeout+0x27f/0x470
[] io_schedule_timeout+0x9f/0x110
[] bit_wait_io+0x16/0x60
[] __wait_on_bit_lock+0x49/0xa0
[] __lock_page+0xb9/0xc0
[] truncate_inode_pages_range+0x3e0/0x760
[] truncate_inode_pages+0x10/0x20
[] kill_bdev+0x30/0x40
[] __blkdev_put+0x71/0x360
[] blkdev_put+0x49/0x170
[] blkdev_close+0x20/0x30
[] __fput+0xe8/0x1f0
[] fput+0x9/0x10
[] task_work_run+0x83/0xb0
[] do_exit+0x3ee/0xc40
[] do_group_exit+0x4b/0xc0
[] get_signal+0x2ca/0x940
[] do_signal+0x23/0x660
[] exit_to_usermode_loop+0x73/0xb0
[] syscall_return_slowpath+0xb0/0xc0
[] entry_SYSCALL_64_fastpath+0xa6/0xa8
Fixes: 777c6c5f1f6e ("wait: prevent exclusive waiter starvation")
References: https://lkml.org/lkml/2012/8/24/185
References: http://www.spinics.net/lists/raid/msg53056.html
Signed-off-by: Bart Van Assche
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Johannes Weiner
Cc: Neil Brown
Cc: Michael Shaver
Cc: # v2.6.29+
---
kernel/sched/wait.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index f15d6b6..fa12939 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -266,12 +266,16 @@ EXPORT_SYMBOL(finish_wait);
* the wait descriptor from the given waitqueue if still
* queued.
*
- * Wakes up the next waiter if the caller is concurrently
- * woken up through the queue.
- *
- * This prevents waiter starvation where an exclusive waiter
- * aborts and is woken up concurrently and no one wakes up
- * the next waiter.
+ * Wakes up the next waiter to prevent waiter starvation
+ * when an exclusive waiter aborts and is woken up
+ * concurrently and no one wakes up the next waiter. Note:
+ * even when a signal is pending it is possible that
+ * __wake_up_common() wakes up the current thread and hence
+ * that @wait has been removed from the wait queue @q. Hence
+ * test whether there are more waiters on the wait queue
+ * even if @wait is not on the wait queue @q. This approach
+ * will cause a spurious wakeup if a signal is delivered and
+ * no other thread calls __wake_up_common() concurrently.
*/
void abort_exclusive_wait(wait_queue_head_t *q, wait_queue_t *wait,
unsigned int mode, void *key)
@@ -282,7 +286,7 @@ void abort_exclusive_wait(wait_queue_head_t *q,
wait_queue_t *wait,
spin_lock_irqsave(&q->lock, flags);
if (!list_empty(&wait->task_list))
list_del_init(&wait->task_list);
- else if (waitqueue_active(q))
+ if (waitqueue_active(q))
__wake_up_locked_key(q, mode, key);
spin_unlock_irqrestore(&q->lock, flags);
}
--
2.9.2
Re: [PATCH v2 03/44] x86/asm/head: rename 'stack_start' -> 'initial_stack'
On Sat, Aug 06, 2016 at 07:25:21AM +0200, Borislav Petkov wrote:
> On Fri, Aug 05, 2016 at 11:01:57AM -0500, Josh Poimboeuf wrote:
> > The 8 should be changed to SIZEOF_PTREGS in a later patch
> > ("x86/asm/head: standardize the end of the stack for idle tasks").
>
> But SIZEOF_PTREGS is 21*8. I don't understand.
I was referring to this patch:
[PATCH v2 41/44] x86/asm/head: standardize the end of the stack for idle tasks
https://lkml.kernel.org/r/98f297ffbc2a23131f08c5c77c4db974e0de2ad3.1470345772.git.jpoim...@redhat.com
It changes the stack end offset from 8 to SIZEOF_PTREGS, so idle tasks
will have the same end of stack address that other tasks do. I was
thinking we should make a similar change here, for consistency:
/*
* Setup stack for verify_cpu(). "-8" because stack_start is defined
* this way, see below. Our best guess is a NULL ptr for stack
* termination heuristics and we don't want to break anything which
* might depend on it (kgdb, ...).
*/
leaq(__end_init_task - 8)(%rip), %rsp
--
Josh
checkpatch.pl: how to run --fix-inplace for just only one warning/error
Hi,
Maybe it's tricky, but could it be possible?
For example for: ERROR: space prohibited after that open parenthesis '('
Any hint?
Thank you.
Re: [PATCH v2 12/14] net: ethernet: ti: cpsw: fix int dbg message
On Sat, 2016-08-06 at 13:48 +0300, Ivan Khoronzhuk wrote:
> While poll handlers there is no possibility to figure out
> which network device is handling packets, as cpdma channels
> are common for both network devices in dual_emac mode. Currently,
> the messages are printed only for one device, in fact, there is two.
> So, better to print integrated num_tx value for both devices if
> any of them is allowed to.
[]
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
[]
> @@ -378,6 +378,7 @@ struct cpsw_common {
> boolrx_irq_disabled;
> booltx_irq_disabled;
> u32 irqs_table[IRQ_NUM];
> + int intr_dbg_msg;
Looks like this should be bool and should
be placed after tx_irq_disabled
[]
> @@ -1848,8 +1853,35 @@ static u32 cpsw_get_msglevel(struct net_device *ndev)
>
> static void cpsw_set_msglevel(struct net_device *ndev, u32 value)
> {
> + int i;
> + struct cpsw_priv *sl_priv;
> struct cpsw_priv *priv = netdev_priv(ndev);
> + struct cpsw_common *cpsw = priv->cpsw;
> +
> priv->msg_enable = value;
> +
> + /* There is no possibility to at napi poll level
> + * to know which netdev is handled, so enable
> + * common dbg msg print if any interface is enabled to
to? too?
> + */
> + cpsw->intr_dbg_msg = 0;
> + if (!cpsw->data.dual_emac) {
> + if (netif_msg_intr(priv))
> + cpsw->intr_dbg_msg = 1;
> + return;
> + }
> +
> + for (i = 0; i < cpsw->data.slaves; i++) {
> + ndev = netdev_priv(cpsw->slaves[i].ndev);
> + if (!ndev)
> + continue;
> +
> + sl_priv = netdev_priv(ndev);
> + if (netif_msg_intr(sl_priv)) {
> + cpsw->intr_dbg_msg = 1;
> + break;
> + }
> + }
> }
>
> static int cpsw_get_ts_info(struct net_device *ndev,
Filesystem slow write performance
Hi, Seeing some terrible write performance with ext3/4 writes. Reads are fine. I have a created loop device and mounted as ext3(tried ext4 also). Here is iostat output. await time is pretty high most of the time. Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util loop0 0.00 0.000.00 133.00 0.00 1064.00 8.00 124.14 835.61 7.52 100.00 dm-0 0.00 0.000.00 132.00 0.00 1056.00 8.00 1.007.52 7.52 99.20 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util loop0 0.00 0.000.00 94.00 0.00 752.00 8.00 124.18 901.02 10.64 100.00 dm-0 0.00 0.000.00 92.00 0.00 736.00 8.00 1.02 11.09 10.87 100.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util loop0 0.00 0.000.00 132.00 0.00 1056.00 8.00 124.56 1329.30 7.58 100.00 dm-0 0.00 0.000.00 141.00 0.00 1128.00 8.00 1.087.72 7.06 99.60 Tags output [root@build-t7 0]# cat tags nr_tags=128, reserved_tags=0, bits_per_word=5 nr_free=128, nr_reserved=0 active_queues=0 Here is the output of "echo w > /proc/sysrq-trigger" when the problem happens. Aug 3 12:18:55 build-t7 kernel: kworker/u512:0 D 009defd4 0 6 2 0x0600 Aug 3 12:18:55 build-t7 kernel: Workqueue: writeback bdi_writeback_workfn (flush-7:0) Aug 3 12:18:55 build-t7 kernel: Call Trace: Aug 3 12:18:55 build-t7 kernel: [009dc9e4] schedule+0x24/0xa0 Aug 3 12:18:55 build-t7 kernel: [009defd4] schedule_timeout+0x134/0x220 Aug 3 12:18:55 build-t7 kernel: [009dc044] io_schedule_timeout+0x84/0x100 Aug 3 12:18:55 build-t7 kernel: [006be64c] bt_get+0x10c/0x1e0 Aug 3 12:18:55 build-t7 kernel: [006be7f4] blk_mq_get_tag+0x74/0xe0 Aug 3 12:18:55 build-t7 kernel: [006ba570] __blk_mq_alloc_request+0x10/0x180 Aug 3 12:18:55 build-t7 kernel: [006bb9f4] blk_mq_map_request+0x1d4/0x260 Aug 3 12:18:55 build-t7 kernel: [006bbd40] blk_sq_make_request+0x60/0x300 Aug 3 12:18:55 build-t7 kernel: [006afa58] generic_make_request+0x78/0xe0 Aug 3 12:18:55 build-t7 kernel: [006afb44] submit_bio+0x84/0x160 Aug 3 12:18:55 build-t7 kernel: [005f7cb4] _submit_bh+0x174/0x200 Aug 3 12:18:55 build-t7 kernel: [005f7d54] submit_bh+0x14/0x40 Aug 3 12:18:55 build-t7 kernel: [005fc248] __block_write_full_page.clone.0+0x2c8/0x500 Aug 3 12:18:55 build-t7 kernel: [005fc620] block_write_full_page+0xa0/0xe0 Aug 3 12:18:55 build-t7 kernel: [100e7d94] ext3_writeback_writepage+0x134/0x200 [ext3] Aug 3 12:18:55 build-t7 kernel: [00562798] __writepage+0x18/0x60 Aug 3 12:18:55 build-t7 kernel: loop0 D 009deff4 0 15632 2 0x01000400 Aug 3 12:18:55 build-t7 kernel: Call Trace: Aug 3 12:18:55 build-t7 kernel: [009dc9e4] schedule+0x24/0xa0 Aug 3 12:18:55 build-t7 kernel: [009deff4] schedule_timeout+0x154/0x220 Aug 3 12:18:55 build-t7 kernel: [009dc044] io_schedule_timeout+0x84/0x100 Aug 3 12:18:55 build-t7 kernel: [009dcdbc] bit_wait_io+0x3c/0x80 Aug 3 12:18:55 build-t7 kernel: [009dd1c4] __wait_on_bit+0x84/0x100 Aug 3 12:18:55 build-t7 kernel: [0055719c] wait_on_page_bit+0x7c/0xa0 Aug 3 12:18:55 build-t7 kernel: [005586a8] filemap_fdatawait_range+0xc8/0x140 Aug 3 12:18:55 build-t7 kernel: [005587fc] filemap_write_and_wait_range+0x3c/0x80 Aug 3 12:18:55 build-t7 kernel: [00558a58] __generic_file_write_iter+0xb8/0x140 Aug 3 12:18:55 build-t7 kernel: [00558bac] generic_file_write_iter+0xcc/0x1e0 Aug 3 12:18:55 build-t7 kernel: [007ca000] lo_rw_aio+0x180/0x240 Aug 3 12:18:55 build-t7 kernel: [007ca260] do_req_filebacked+0x1a0/0x1c0 Aug 3 12:18:55 build-t7 kernel: [007ca2b4] loop_queue_work+0x34/0x80 Aug 3 12:18:55 build-t7 kernel: [00491944] kthread_worker_fn+0x44/0x180 Aug 3 12:18:55 build-t7 kernel: [00491c4c] kthread+0xac/0xe0 Aug 3 12:18:55 build-t7 kernel: [00406184] ret_from_fork+0x1c/0x2c Aug 3 12:18:55 build-t7 kernel: livecd-creator D 009deff4 0 15627 2676 0x308000103000400 Aug 3 12:18:55 build-t7 kernel: Call Trace: Aug 3 12:18:55 build-t7 kernel: [009dc9e4] schedule+0x24/0xa0 Aug 3 12:18:55 build-t7 kernel: [009deff4] schedule_timeout+0x154/0x220 Aug 3 12:18:55 build-t7 kernel: [009dc044] io_schedule_timeout+0x84/0x100 Aug 3 12:18:55 build-t7 kernel: [009dcdbc] bit_wait_io+0x3c/0x80 Aug 3 12:18:55 build-t7 kernel: [009dd1c4] __wait_on_bit+0x84/0x100 Aug 3 12:18:55 build-t7 kernel: [0055719c] wait_on_page_bit+0x7c/0xa0 Aug 3 12:1
[PATCH 2/7] drm/radeon: Don't print error on aux transaction timeouts
Since it's normal for DRM to retry our aux transaction helpers multiple
times in a row, up to 32 times for each attempted transaction, we're
making a lot of noise that is no longer necessary now that DRM will just
print the return code we give it.
Signed-off-by: Lyude
---
drivers/gpu/drm/radeon/radeon_dp_auxch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
index db64e00..2d46564 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
@@ -164,7 +164,6 @@ radeon_dp_aux_transfer_native(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg
}
if (tmp & AUX_SW_RX_TIMEOUT) {
- DRM_DEBUG_KMS("dp_aux_ch timed out\n");
ret = -ETIMEDOUT;
goto done;
}
--
2.7.4
[PATCH 5/7] drm/amdgpu: Don't retry 7 times in amdgpu_atombios_dp_get_dpcd()
When this code was written, we didn't retry DP aux transactions on any
error, which required retrying important transactions like this in
individual drivers. Since that's no longer the case, retrying here is
not necessary. As well, we retry any aux transaction on any error 32
times. 7 * 32 = 224, which means this loop causes us to retry grabbing
the dpcd 224 times. This is definitely far more then we actually need to
do.
Signed-off-by: Lyude
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 166dc7b..f81068b 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -338,22 +338,21 @@ int amdgpu_atombios_dp_get_dpcd(struct amdgpu_connector
*amdgpu_connector)
{
struct amdgpu_connector_atom_dig *dig_connector =
amdgpu_connector->con_priv;
u8 msg[DP_DPCD_SIZE];
- int ret, i;
+ int ret;
- for (i = 0; i < 7; i++) {
- ret = drm_dp_dpcd_read(&amdgpu_connector->ddc_bus->aux,
DP_DPCD_REV, msg,
- DP_DPCD_SIZE);
- if (ret == DP_DPCD_SIZE) {
- memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
+ ret = drm_dp_dpcd_read(&amdgpu_connector->ddc_bus->aux, DP_DPCD_REV,
+ msg, DP_DPCD_SIZE);
+ if (ret == DP_DPCD_SIZE) {
+ memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
- DRM_DEBUG_KMS("DPCD: %*ph\n",
(int)sizeof(dig_connector->dpcd),
- dig_connector->dpcd);
+ DRM_DEBUG_KMS("DPCD: %*ph\n", (int)sizeof(dig_connector->dpcd),
+ dig_connector->dpcd);
- amdgpu_atombios_dp_probe_oui(amdgpu_connector);
+ amdgpu_atombios_dp_probe_oui(amdgpu_connector);
- return 0;
- }
+ return 0;
}
+
dig_connector->dpcd[0] = 0;
return -EINVAL;
}
--
2.7.4
[PATCH 3/7] drm/radeon: Don't retry 7 times in radeon_dp_dpcd()
When this code was written, we didn't retry DP aux transactions on any
error, which required retrying important transactions like this in
individual drivers. Since that's no longer the case, retrying here is
not necessary. As well, we retry any aux transaction on any error 32
times. 7 * 32 = 224, which means this loop causes us to retry grabbing
the dpcd 224 times. This is definitely far more then we actually need to
do.
Signed-off-by: Lyude
---
drivers/gpu/drm/radeon/atombios_dp.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index cead089a..432cb46 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -389,22 +389,21 @@ bool radeon_dp_getdpcd(struct radeon_connector
*radeon_connector)
{
struct radeon_connector_atom_dig *dig_connector =
radeon_connector->con_priv;
u8 msg[DP_DPCD_SIZE];
- int ret, i;
+ int ret;
- for (i = 0; i < 7; i++) {
- ret = drm_dp_dpcd_read(&radeon_connector->ddc_bus->aux,
DP_DPCD_REV, msg,
- DP_DPCD_SIZE);
- if (ret == DP_DPCD_SIZE) {
- memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
+ ret = drm_dp_dpcd_read(&radeon_connector->ddc_bus->aux, DP_DPCD_REV,
msg,
+ DP_DPCD_SIZE);
+ if (ret == DP_DPCD_SIZE) {
+ memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
- DRM_DEBUG_KMS("DPCD: %*ph\n",
(int)sizeof(dig_connector->dpcd),
- dig_connector->dpcd);
+ DRM_DEBUG_KMS("DPCD: %*ph\n", (int)sizeof(dig_connector->dpcd),
+ dig_connector->dpcd);
- radeon_dp_probe_oui(radeon_connector);
+ radeon_dp_probe_oui(radeon_connector);
- return true;
- }
+ return true;
}
+
dig_connector->dpcd[0] = 0;
return false;
}
--
2.7.4
Re: checkpatch.pl: how to run --fix-inplace for just only one warning/error
On Sat, 2016-08-06 at 22:24 +0200, Xose Vazquez Perez wrote:
> Hi,
>
> Maybe it's tricky, but could it be possible?
> For example for: ERROR: space prohibited after that open parenthesis
> '('
> Any hint?
try --types=SPACING
[PATCH 7/7] drm/dp_helper: Rate limit timeout errors from drm_dp_i2c_do_msg()
Timeouts can be errors, but timeouts are also usually normal behavior
and happen a lot. Since the kernel already lets us know when we're
suppressing messages due to rate limiting, rate limit timeout errors so
we don't make too much noise in the kernel log.
Signed-off-by: Lyude
---
drivers/gpu/drm/drm_dp_helper.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 43be189..5ca72d25 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -574,7 +574,17 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
if (ret == -EBUSY)
continue;
- DRM_DEBUG_KMS("transaction failed: %d\n", ret);
+ /*
+* While timeouts can be errors, they're usually normal
+* behavior (for instance, when a driver tries to
+* communicate with a non-existant DisplayPort device).
+* Avoid spamming the kernel log with timeout errors.
+*/
+ if (ret == -ETIMEDOUT)
+ DRM_DEBUG_KMS_RATELIMITED("transaction timed
out\n");
+ else
+ DRM_DEBUG_KMS("transaction failed: %d\n", ret);
+
return ret;
}
--
2.7.4
[PATCH 1/7] drm/dp_helper: Print first error received on failure in drm_dp_dpcd_access()
Since we always retry in drm_dp_dpcd_access() regardless of the error,
we're going to make a lot of noise if the aux->transfer function prints
it's own errors (as is the case with radeon). If we can print the error
code here, this reduces the need for drivers to do this. So instead of
having to print "dp_aux_ch timed out" over 32 times we can just print
once.
Signed-off-by: Lyude
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8f11b87..43be189 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -223,7 +223,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
err = ret;
}
- DRM_DEBUG_KMS("too many retries, giving up\n");
+ DRM_DEBUG_KMS("Too many retries, giving up. First error: %d\n", err);
ret = err;
unlock:
--
2.7.4
Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()
* Andreas Kemnade [160805 08:35]: > I repeat the subject line of the patch: > [PATCH v2] musb: omap2430: do not assume balanced enable()/disable() > It is *not* fix charging. > > So you mean that the phy should magically know at which refcounter > it should power on and off if power on/off is not called in the > balanced way? No, I mean we need to figure out why things can be called in unbalanced way. With your patch I end up with unbalanced calls leaving the phy on after all the modules have been removed :) > Maybe the phy-twl4030 uses the phy layer wrong. > Now the relevant part of power on/off in phy-twl4030 is done via struct > phy_ops.power_off/power_on (*not* via pm_runtime). Maybe that is wrong > and more parts should be moved to the pm_runtime stuff (which is also > present). We should use phy power_off/power_on for the USB related parts. The parts needed by other components, like VBUS detection, should be handled by PM runtime. We should get phy-twl4030-usb and the charger driver working also when no musb modules are loaded. > Then the phy subsystem has its own power refcounter in struct > phy.power_count. It it handled via phy_power_off()/phy_power_on(). > And that is called from musb/omap2430.c > But that is another story. Yes that's what the USB driver is expected to do. But obviously there are issues remaining also in the phy-twl4030-usb.c driver. And it seems that we should have some OTG parts always enabled when VBUS is detected when twl4030-charger is configured? > > If there are MUSB specific PM runtime issues then let's fix > > those separately. > > > And that exactly tries my patch to do. For that task it does not > even use the PM runtime system. Again please read the subject line of > the patch. Maybe it unveils some other pm issues in musb > which should first be fixed in a complete patch series. Certainly that needs to be fixed, but let's do it in a way where things work for other test cases also. Care to describe how to to reproduce the issue you're seeing? It seems that you are seeing devices not being enmerated leading to the charger not working? Is this with built in MUSB and phy modules? Regrds, Tony
[PATCH 4/7] drm/amdgpu: Don't print error on aux transaction timeouts
Since it's normal for DRM to retry our aux transaction helpers multiple
times in a row, up to 32 times for each attempted transaction, we're
making a lot of noise that is no longer necessary now that DRM will just
print the return code we give it.
Signed-off-by: Lyude
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 7f85c2c..166dc7b 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -88,7 +88,6 @@ static int amdgpu_atombios_dp_process_aux_ch(struct
amdgpu_i2c_chan *chan,
/* timeout */
if (args.v2.ucReplyStatus == 1) {
- DRM_DEBUG_KMS("dp_aux_ch timeout\n");
r = -ETIMEDOUT;
goto done;
}
--
2.7.4
[PATCH 0/7] Minor DP aux transaction fixes
While I was investigating an unrelated bug on the radeon driver, I noticed that it's become rather difficult to actually read through dmesg with drm.debug turned on, on account of the huge number of messages we end up printing from failed DP aux transactions that happen every time we reprobe each connector. Timed out transactions are relatively normal, and as well there's a lot of places in radeon/amdgpu where we're printing redundant debugging information dozens of times each time we attempt a DP aux transactions. Additionally, I've removed some of the retry loops in amdgpu/radeon. These were definitely useful at one point, but since we now retry any failed aux transaction unconditionally in DRM's dp helpers they don't serve much purpose other then to make failing aux transactions take a lot more time then they need to. Lyude (7): drm/dp_helper: Print first error received on failure in drm_dp_dpcd_access() drm/radeon: Don't print error on aux transaction timeouts drm/radeon: Don't retry 7 times in radeon_dp_dpcd() drm/amdgpu: Don't print error on aux transaction timeouts drm/amdgpu: Don't retry 7 times in amdgpu_atombios_dp_get_dpcd() drm: Add ratelimited versions of the DRM_DEBUG* macros drm/dp_helper: Rate limit timeout errors from drm_dp_i2c_do_msg() drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 22 ++ drivers/gpu/drm/drm_dp_helper.c | 14 -- drivers/gpu/drm/radeon/atombios_dp.c | 21 ++--- drivers/gpu/drm/radeon/radeon_dp_auxch.c | 1 - include/drm/drmP.h | 30 ++ 5 files changed, 62 insertions(+), 26 deletions(-) -- 2.7.4
[PATCH 1/1] x86/mm: kaslr: fix -Wformat-security warning
debug_putstr() is used to output strings without using printf-like
formatting but debug_putstr(v) is defined as early_printk(v) in
arch/x86/lib/kaslr.c. This makes clang reports the following warning
when building with -Wformat-security:
arch/x86/lib/kaslr.c:57:15: warning: format string is not a string
literal (potentially insecure) [-Wformat-security]
debug_putstr(purpose);
^~~
Fix this by using "%s" in early_printk().
Signed-off-by: Nicolas Iooss
---
arch/x86/lib/kaslr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/lib/kaslr.c b/arch/x86/lib/kaslr.c
index f7dfeda83e5c..121f59c6ee54 100644
--- a/arch/x86/lib/kaslr.c
+++ b/arch/x86/lib/kaslr.c
@@ -19,7 +19,7 @@
#include
#include
-#define debug_putstr(v) early_printk(v)
+#define debug_putstr(v) early_printk("%s", v)
#define has_cpuflag(f) boot_cpu_has(f)
#define get_boot_seed() kaslr_offset()
#endif
--
2.9.2
[PATCH 6/7] drm: Add ratelimited versions of the DRM_DEBUG* macros
There's a couple of places where this would be useful for drivers (such
as reporting DP aux transaction timeouts).
Signed-off-by: Lyude
---
include/drm/drmP.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d377865..1c4d91b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -231,6 +231,36 @@ void drm_err(const char *format, ...);
drm_ut_debug_printk(__func__, fmt, ##args); \
} while (0)
+#define _DRM_DEFINE_DEBUG_RATELIMITED(level, fmt, args...) \
+ do {\
+ if (unlikely(drm_debug & DRM_UT_ ## level)) { \
+ static DEFINE_RATELIMIT_STATE( \
+ _rs,\
+ DEFAULT_RATELIMIT_INTERVAL, \
+ DEFAULT_RATELIMIT_BURST); \
+ \
+ if (__ratelimit(&_rs)) {\
+ drm_ut_debug_printk(__func__, fmt, \
+ ##args);\
+ } \
+ } \
+ } while (0)
+
+/**
+ * Rate limited debug output. Like DRM_DEBUG() but won't flood the log.
+ *
+ * \param fmt printf() like format string.
+ * \param arg arguments
+ */
+#define DRM_DEBUG_RATELIMITED(fmt, args...)\
+ _DRM_DEFINE_DEBUG_RATELIMITED(CORE, fmt, ##args)
+#define DRM_DEBUG_DRIVER_RATELIMITED(fmt, args...) \
+ _DRM_DEFINE_DEBUG_RATELIMITED(DRIVER, fmt, ##args)
+#define DRM_DEBUG_KMS_RATELIMITED(fmt, args...)
\
+ _DRM_DEFINE_DEBUG_RATELIMITED(KMS, fmt, ##args)
+#define DRM_DEBUG_PRIME_RATELIMITED(fmt, args...) \
+ _DRM_DEFINE_DEBUG_RATELIMITED(PRIME, fmt, ##args)
+
/*@}*/
/***/
--
2.7.4
Re: [PATCH v2 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
On 22 April 2016 at 12:09, Yunhui Cui wrote:
> From: Yunhui Cui
>
> With the physical sectors combination, S25FS-S family flash
> requires some special operations for read/write functions.
>
> Signed-off-by: Yunhui Cui
> ---
> drivers/mtd/spi-nor/spi-nor.c | 59
> +++
> 1 file changed, 59 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 157841d..91ee920 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -39,6 +39,10 @@
>
> #define SPI_NOR_MAX_ID_LEN 6
> #define SPI_NOR_MAX_ADDR_WIDTH 4
> +/* Added for S25FS-S family flash */
> +#define SPINOR_CONFIG_REG3_OFFSET 0x84
> +#define CR3V_4KB_ERASE_UNABLE 0x8
> +#define SPINOR_S25FS_FAMILY_ID 0x81
>
> struct flash_info {
> char*name;
> @@ -78,6 +82,7 @@ struct flash_info {
> };
>
> #define JEDEC_MFR(info)((info)->id[0])
> +#define EXT_ID(info) ((info)->id[5])
I don't think 5th only the ext and usually last 3 bytes are called as
ext_jedec if the id length is 6 bytes.
>
> static const struct flash_info *spi_nor_match_id(const char *name);
>
> @@ -881,6 +886,7 @@ static const struct flash_info spi_nor_ids[] = {
> */
> { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024, 512, 0)},
> { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> @@ -1018,6 +1024,53 @@ static const struct flash_info *spi_nor_read_id(struct
> spi_nor *nor)
> return ERR_PTR(-ENODEV);
> }
>
> +/*
> + * The S25FS-S family physical sectors may be configured as a
> + * hybrid combination of eight 4-kB parameter sectors
> + * at the top or bottom of the address space with all
> + * but one of the remaining sectors being uniform size.
> + * The Parameter Sector Erase commands (20h or 21h) must
> + * be used to erase the 4-kB parameter sectors individually.
> + * The Sector (uniform sector) Erase commands (D8h or DCh)
> + * must be used to erase any of the remaining
> + * sectors, including the portion of highest or lowest address
> + * sector that is not overlaid by the parameter sectors.
> + * The uniform sector erase command has no effect on parameter sectors.
> + */
> +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor)
> +{
> + struct fsl_qspi *q;
> + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
> + u8 cr3v = 0x0;
> + int ret = 0x0;
> +
> + q = nor->priv;
Why this q?
--
Jagan.
[PATCH v2 3/3] sched: Avoid that abort_exclusive_wait() triggers spurious wakeups
Patch "sched: Avoid that __wait_on_bit_lock() hangs" made spurious
wakeups possible. Avoid to trigger such spurious wakeups.
Signed-off-by: Bart Van Assche
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Johannes Weiner
Cc: Neil Brown
Cc: Michael Shaver
---
include/linux/wait.h | 5 +++--
kernel/sched/wait.c | 21 -
2 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 27d7a0a..5034fce 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -282,7 +282,7 @@ wait_queue_head_t *bit_waitqueue(void *, int);
__ret = __int; \
if (exclusive) {\
abort_exclusive_wait(&wq, &__wait, \
-state, NULL); \
+ condition, state, NULL);\
goto __out; \
} \
break; \
@@ -976,7 +976,8 @@ void prepare_to_wait(wait_queue_head_t *q, wait_queue_t
*wait, int state);
void prepare_to_wait_exclusive(wait_queue_head_t *q, wait_queue_t *wait, int
state);
long prepare_to_wait_event(wait_queue_head_t *q, wait_queue_t *wait, int
state);
void finish_wait(wait_queue_head_t *q, wait_queue_t *wait);
-void abort_exclusive_wait(wait_queue_head_t *q, wait_queue_t *wait, unsigned
int mode, void *key);
+void abort_exclusive_wait(wait_queue_head_t *q, wait_queue_t *wait,
+ bool wake_up_next, unsigned int mode, void *key);
long wait_woken(wait_queue_t *wait, unsigned mode, long timeout);
int woken_wake_function(wait_queue_t *wait, unsigned mode, int sync, void
*key);
int autoremove_wake_function(wait_queue_t *wait, unsigned mode, int sync, void
*key);
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index dcc7693..c5a913f 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -259,6 +259,7 @@ EXPORT_SYMBOL(finish_wait);
* abort_exclusive_wait - abort exclusive waiting in a queue
* @q: waitqueue waited on
* @wait: wait descriptor
+ * @wake_up_next: Whether or not to wake up another exclusive waiter
* @mode: runstate of the waiter to be woken
* @key: key to identify a wait bit queue or %NULL
*
@@ -266,19 +267,12 @@ EXPORT_SYMBOL(finish_wait);
* the wait descriptor from the given waitqueue if still
* queued.
*
- * Wakes up the next waiter to prevent waiter starvation
- * when an exclusive waiter aborts and is woken up
- * concurrently and no one wakes up the next waiter. Note:
- * even when a signal is pending it is possible that
- * __wake_up_common() wakes up the current thread and hence
- * that @wait has been removed from the wait queue @q. Hence
- * test whether there are more waiters on the wait queue
- * even if @wait is not on the wait queue @q. This approach
- * will cause a spurious wakeup if a signal is delivered and
- * no other thread calls __wake_up_common() concurrently.
+ * Wakes up the next waiter if @wake_up_next is set to prevent
+ * waiter starvation when an exclusive waiter aborts and is
+ * woken up concurrently and no one wakes up the next waiter.
*/
void abort_exclusive_wait(wait_queue_head_t *q, wait_queue_t *wait,
- unsigned int mode, void *key)
+ bool wake_up_next, unsigned int mode, void *key)
{
unsigned long flags;
@@ -286,7 +280,7 @@ void abort_exclusive_wait(wait_queue_head_t *q,
wait_queue_t *wait,
spin_lock_irqsave(&q->lock, flags);
if (!list_empty(&wait->task_list))
list_del_init(&wait->task_list);
- if (waitqueue_active(q))
+ if (wake_up_next && waitqueue_active(q))
__wake_up_locked_key(q, mode, key);
spin_unlock_irqrestore(&q->lock, flags);
}
@@ -440,7 +434,8 @@ __wait_on_bit_lock(wait_queue_head_t *wq, struct
wait_bit_queue *q,
ret = action(key, mode);
if (!ret)
continue;
- abort_exclusive_wait(wq, &q->wait, mode, key);
+ abort_exclusive_wait(wq, &q->wait,
+ test_bit(key->bit_nr, key->flags), mode, key);
return ret;
} while (test_and_set_bit(key->bit_nr, key->flags));
finish_wait(wq, &q->wait);
--
2.9.2
Re: [PATCH 6/7] drm: Add ratelimited versions of the DRM_DEBUG* macros
On Fri, 2016-08-05 at 20:30 -0400, Lyude wrote: > There's a couple of places where this would be useful for drivers (such > as reporting DP aux transaction timeouts). Maybe a single static _rs or one for each type would be better than an individual _rs per callsite.
Re: [PATCH 4/6] fs: befs: remove unnecessary *befs_sb variable
On Mon, Aug 01, 2016 at 03:02:57PM +0100, Luis de Bethencourt wrote: > On 31/07/16 21:34, Salah Triki wrote: > > Remove *befs_sb and just call BEFS_SB(sb) directly, since the returned > > value by this function is only used once. > > > > Signed-off-by: Salah Triki > > --- > > fs/befs/datastream.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/fs/befs/datastream.c b/fs/befs/datastream.c > > index b68b6f9..343123c 100644 > > --- a/fs/befs/datastream.c > > +++ b/fs/befs/datastream.c > > @@ -422,10 +422,9 @@ befs_find_brun_dblindirect(struct super_block *sb, > > struct buffer_head *indir_block; > > befs_block_run indir_run; > > befs_disk_inode_addr *iaddr_array; > > - struct befs_sb_info *befs_sb = BEFS_SB(sb); > > > > befs_blocknr_t indir_start_blk = > > - data->max_indirect_range >> befs_sb->block_shift; > > + data->max_indirect_range >> BEFS_SB(sb)->block_shift; > > > > off_t dbl_indir_off = blockno - indir_start_blk; > > > > > > This looks to be consistent with other uses of BEFS_SB() when the value is > only used once. > > Thanks, > Luis > > Acked-by: Luis de Bethencourt > > Pushed to the befs-next branch: > https://github.com/luisbg/linux-befs/tree/befs-next Thanx :) salah
Re: [PATCH 2/6] fs: befs: remove in vain variable assignment
On Mon, Aug 01, 2016 at 02:24:34PM +0100, Luis de Bethencourt wrote: > On 31/07/16 21:34, Salah Triki wrote: > > There is no need to set *value, it will be overwritten later. > > > > Signed-off-by: Salah Triki > > --- > > fs/befs/btree.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/fs/befs/btree.c b/fs/befs/btree.c > > index a0e8cfa..f33fc6c 100644 > > --- a/fs/befs/btree.c > > +++ b/fs/befs/btree.c > > @@ -348,8 +348,6 @@ befs_find_key(struct super_block *sb, struct > > befs_btree_node *node, > > > > befs_debug(sb, "---> %s %s", __func__, findkey); > > > > - *value = 0; > > - > > findkey_len = strlen(findkey); > > > > /* if node can not contain key, just skeep this node */ > > > > Hi Salah, > > The key here is that befs_btree_find(), the only consumer of befs_find_key(), > doesn't use the value if the return is BEFS_BT_NOT_FOUND. > > Tested the patch anyway to be sure. > > Acked-by: Luis de Bethencourt > > Pushed to the befs-next branch: > https://github.com/luisbg/linux-befs/tree/befs-next > > Thanks! > Luis Thanx :) Salah
Re: [PATCH v2] perf probe: fix module name matching
On Fri, 05 Aug 2016 15:22:36 +0300
Konstantin Khlebnikov wrote:
> If module is "module" then dso->short_name is "[module]".
> Substring comparing is't enough: "raid10" matches to "[raid1]".
> This patch also checks terminating zero in module name.
>
> Signed-off-by: Konstantin Khlebnikov
Looks good to me :)
Acked-by: Masami Hiramatsu
Thanks!
> ---
> tools/perf/util/probe-event.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 953dc1ab2ed7..dd2d60ef05d3 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -170,8 +170,10 @@ static struct map *kernel_get_module_map(const char
> *module)
> module = "kernel";
>
> for (pos = maps__first(maps); pos; pos = map__next(pos)) {
> + /* short_name is "[module]" */
> if (strncmp(pos->dso->short_name + 1, module,
> - pos->dso->short_name_len - 2) == 0) {
> + pos->dso->short_name_len - 2) == 0 &&
> + module[pos->dso->short_name_len - 2] == '\0') {
> return pos;
> }
> }
>
--
Masami Hiramatsu
[PATCH 1/1] ASoc: simple-card-utils: add __printf attribute
asoc_simple_card_set_dailink_name() uses devm_kvasprintf() to format some of its arguments. Adding a __printf attribute to this function makes it possible to detect at compile-time errors related to format strings. Signed-off-by: Nicolas Iooss --- include/sound/simple_card_utils.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/sound/simple_card_utils.h b/include/sound/simple_card_utils.h index 86088aed9002..3207b1a70d38 100644 --- a/include/sound/simple_card_utils.h +++ b/include/sound/simple_card_utils.h @@ -27,6 +27,7 @@ int asoc_simple_card_parse_daifmt(struct device *dev, struct device_node *codec, char *prefix, unsigned int *retfmt); +__printf(3, 4) int asoc_simple_card_set_dailink_name(struct device *dev, struct snd_soc_dai_link *dai_link, const char *fmt, ...); -- 2.9.2
[PATCH v3] Coccinelle: Script to replace NULL test with IS_ERR test for devm_ioremap_resource
This script detects cases which have incorrect error handling for devm_ioremap_resource function, employing a NULL test instead of an IS_ERR() test. Acked-by: Julia Lawall Signed-off-by: Amitoj Kaur Chawla --- Changes in v2: -Changed script to correct error handling instead of just detecting cases of incorrect error handling Changes in v3: -Reverted to original script in v1 to ensure no error in modifying inconsistent paths. .../null/devm_ioremap_resource_test.cocci | 38 ++ 1 file changed, 38 insertions(+) create mode 100644 scripts/coccinelle/null/devm_ioremap_resource_test.cocci diff --git a/scripts/coccinelle/null/devm_ioremap_resource_test.cocci b/scripts/coccinelle/null/devm_ioremap_resource_test.cocci new file mode 100644 index 000..734dbd3 --- /dev/null +++ b/scripts/coccinelle/null/devm_ioremap_resource_test.cocci @@ -0,0 +1,38 @@ +/// Correct error handling for devm_ioremap_resource +/// +// Confidence: High +// Copyright: (C) 2016 Amitoj Kaur Chawla +// Keywords: devm,devm_ioremap_resource + +virtual context +virtual org +virtual report + +// + +@err depends on context || org || report@ +statement S; +expression e; +position j0; +@@ + + e = devm_ioremap_resource(...); +* if (!e@j0) S +// + +@script:python err_org depends on org@ +j0 << err.j0; +@@ + +msg = "Incorrect error handling." +coccilib.org.print_todo(j0[0], msg) + +// + +@script:python err_report depends on report@ +j0 << err.j0; +@@ + +msg = "Incorrect error handling." +coccilib.report.print_report(j0[0], msg) + -- 1.9.1
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures
On Fri, 05 Aug 2016 21:16:00 +0200 Arnd Bergmann wrote: > On Saturday, August 6, 2016 2:16:42 AM CEST Nicholas Piggin wrote: > > > > > > diff --git a/include/asm-generic/vmlinux.lds.h > > > b/include/asm-generic/vmlinux.lds.h > > > index 0ec807d69f18..7a3ad269fa23 100644 > > > --- a/include/asm-generic/vmlinux.lds.h > > > +++ b/include/asm-generic/vmlinux.lds.h > > > @@ -433,7 +433,7 @@ > > > * during second ld run in second ld pass when generating System.map */ > > > #define TEXT_TEXT\ > > > ALIGN_FUNCTION(); \ > > > - *(.text.hot .text .text.fixup .text.unlikely) \ > > > + *(.text.hot .text .text.* .text.fixup .text.unlikely) \ > > > *(.ref.text)\ > > > MEM_KEEP(init.text) \ > > > MEM_KEEP(exit.text) \ > > > > > > > > > It also got much faster again, the link time for an allyesconfig > > > kernel is now 18 minutes instead of 10 hours, but it's still > > > much worse than the 2 minutes I had earlier or the four minutes > > > with the previous patch. > > > > Are you using the patches I just sent? > > Not yet, I was still busy with the older version, and trying to > figure out exactly what went wrong in ld.bfd. FWIW, I first tried > to see if the hash tables were just too small, but as it turned > out that was not the problem. When I tried to change the default > hash table sizes, making them bigger only made things slower. > > I also found the --hash-size=xxx option, which has a significant > impact on runtime speed. Interestingly again, using sizes less > than the default made things faster in practice. If we can > work out the optimum size for the kernel build, that might > shave a few minutes off the total build time. > > > Either way, you also need > > to do the same for data and bss sections as you are using > > -fdata-sections too. > > Right. > > > I've found virtually no build time regression on powerpc or x86 > > when those are taken care of properly (x86 numbers I sent are typo, > > it's not 5m20, it's 5m02). > > Interesting. I wonder if it's got something to do with the > generation of the branch trampolines on ARM, as we have a lot > of them on an allyesconfig. Powerpc generates quite a few branch trampolines as well, so I'm not sure if that would be the issue. Can you get a profile of the link? Are you linking with archives? Do your input archives have a symbol index built? > Is the 5m20 the total build time for the kernel, the time for > rebuilding after a trivial change, or the time to call 'ld.bfd' > once? 5m02 was the total time for x86 defconfig. With the powerpc allyesconfig build, the final link: $ time ld -EL -m elf64lppc -pie --emit-relocs --build-id --gc-sections -X -o vmlinux -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive built-in.o .tmp_kallsyms2.o real0m15.556s user0m13.288s sys 0m2.240s $ ls -lh vmlinux -rwxrwxr-x 1 npiggin npiggin 279M Aug 6 14:02 vmlinux Without -pie --emit-relocs it's 11.8s and 150M but I'm using emit-relocs for a post-link step. > Are you using ld.bfd on x86 or ld.gold? For me ld.gold either > works and is really fast, or it crashes, depending on the > configuration. I also don't think it supports big-endian ARM > (which is what allyesconfig ends up using). ld.bfd on both. Gold crashed on powerpc and I didn't try it on x86. Thanks, Nick
Re: [lkdtm] 9a49a528dc: WARNING: CPU: 0 PID: 404 at kernel/trace/ftrace.c:2005 ftrace_bug
This should be fixed by mpe's notrace patch for this function which should be landing in 4.8 shortly. -Kees On Sat, Aug 6, 2016 at 4:05 AM, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > commit 9a49a528dcf3c2022ff89f700d5d0345b9abf288 > Author: Kees Cook > AuthorDate: Mon Feb 22 14:09:29 2016 -0800 > Commit: Kees Cook > CommitDate: Fri Jun 10 15:57:50 2016 -0700 > > lkdtm: add function for testing .rodata section > > This adds a function that lives in the .rodata section. The section > flags are corrected using objcopy since there is no way with gcc to > declare section flags in an architecture-agnostic way. > > Signed-off-by: Kees Cook > > +---++++ > | | 426f3a53d4 | > 9a49a528dc | 5eb7f58ccb | > +---++++ > | boot_successes| 876| 255 > | 57 | > | boot_failures | 344| 55 > | 33 | > | BUG:kernel_test_crashed | 344| 53 > | 31 | > | WARNING:at_kernel/trace/ftrace.c:#ftrace_bug | 0 | 2 > | 2 | > | RIP:is_ftrace_trampoline | 0 | 2 > | 2 | > | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0 | 2 > | 2 | > | backtrace:perf_ftrace_event_register | 0 | 2 > | 2 | > | backtrace:perf_trace_init | 0 | 2 > | 2 | > | backtrace:perf_tp_event_init | 0 | 2 > | 2 | > | backtrace:perf_try_init_event | 0 | 2 > | 2 | > | backtrace:perf_event_alloc| 0 | 2 > | 2 | > | backtrace:SyS_perf_event_open | 0 | 2 > | 2 | > +---++++ > > [ 11.152520] init: plymouth-splash main process (396) terminated with > status 1 > [ 11.164728] init: networking main process (398) terminated with status 1 > [ 18.827856] [ cut here ] > [ 18.829473] WARNING: CPU: 0 PID: 404 at kernel/trace/ftrace.c:2005 > ftrace_bug+0x145/0x400 > [ 18.833070] CPU: 0 PID: 404 Comm: trinity-main Not tainted > 4.7.0-rc2-00303-g9a49a52 #1 > [ 18.835847] 0009 880009093bf8 81720b3c > 880009093c38 > [ 18.838684] 810df9d2 07d58112d8af 8800102a7e80 > 81fe1db0 > [ 18.841697] 93e8 0001 831b9330 > 880009093c48 > [ 18.844511] Call Trace: > [ 18.845424] [] dump_stack+0x19/0x1d > [ 18.847204] [] __warn+0x112/0x150 > [ 18.848936] [] warn_slowpath_null+0x1d/0x20 > [ 18.851178] [] ftrace_bug+0x145/0x400 > [ 18.853029] [] ftrace_replace_code+0x2c9/0x480 > [ 18.855130] [] ftrace_modify_all_code+0x36/0xc0 > [ 18.857372] [] arch_ftrace_update_code+0xf/0x20 > [ 18.859483] [] ftrace_run_update_code+0x50/0x60 > [ 18.861813] [] ftrace_startup_enable+0x33/0x50 > [ 18.863903] [] ftrace_startup+0x13d/0x180 > [ 18.866205] [] register_ftrace_function+0x4c/0x60 > [ 18.868342] [] perf_ftrace_event_register+0x47/0x100 > [ 18.870749] [] perf_trace_init+0x25b/0x280 > [ 18.872718] [] perf_tp_event_init+0x56/0x90 > [ 18.874690] [] perf_try_init_event+0xa9/0xd0 > [ 18.876806] [] perf_event_alloc+0x70c/0x1080 > [ 18.878818] [] SyS_perf_event_open+0x928/0x17b0 > [ 18.881148] [] entry_SYSCALL_64_fastpath+0x1f/0xb8 > [ 18.883330] ---[ end trace 1cf1f82a14a663e2 ]--- > [ 18.884894] ftrace faulted on writing [] > lkdtm_rodata_do_nothing+0x0/0x10 > > git bisect start 5eb7f58ccb08a2822f20afb2f4341474e1dece30 > 523d939ef98fd712632d93a5a2b588e477a7565e -- > git bisect bad 3b760b613b1536578a4576a73e9ba9ac359d3dfd # 15:06151- > 59 Merge > 'linux-review/Wei-Yongjun/IB-core-Fix-possible-memory-leak-in-cma_resolve_iboe_route/20160805-215000' > into devel-spot-201608061351 > git bisect bad 9e0b994e4fcc43853507dbdf87667f0195196858 # 15:10 0- > 1 Merge > 'linux-review/Dave-Carroll/aacraid-C
Re: [PATCH v2 03/44] x86/asm/head: rename 'stack_start' -> 'initial_stack'
On Fri, Aug 05, 2016 at 11:01:57AM -0500, Josh Poimboeuf wrote:
> The 8 should be changed to SIZEOF_PTREGS in a later patch
> ("x86/asm/head: standardize the end of the stack for idle tasks").
But SIZEOF_PTREGS is 21*8. I don't understand.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
Regression: commit 12549e2 clocksource/drivers/time-armada-370-xp: Convert init function to return error
Dear list, dear Daniel Commit 12549e27c63c61d76bb059bfafce0a4ee05c7e90 breaks booting a Linksys WRT1900ACS for me. I filed bug [1] and John Stultz asked me to get the lists and in particular the author of the commit Daniel Lezcano's attention. More details in the original report [1]. Regards Ralph [1] https://bugzilla.kernel.org/show_bug.cgi?id=150571
Re: [PATCH v2 03/44] x86/asm/head: rename 'stack_start' -> 'initial_stack'
On Sat, Aug 06, 2016 at 09:15:30AM -0400, Brian Gerst wrote:
> On Sat, Aug 6, 2016 at 1:25 AM, Borislav Petkov wrote:
> > On Fri, Aug 05, 2016 at 11:01:57AM -0500, Josh Poimboeuf wrote:
> >> The 8 should be changed to SIZEOF_PTREGS in a later patch
> >> ("x86/asm/head: standardize the end of the stack for idle tasks").
> >
> > But SIZEOF_PTREGS is 21*8. I don't understand.
>
> This patch is only for the boot cpu's idle thread. All other kernel
> threads, including idle threads for the secondary cpus, already have
> the pt_regs area reserved.
Ah, you're right, it does only affect the boot CPU's idle thread.
(To be clear, I think you're talking about patch 41/44, and not the
temporary stack for the verify_cpu() call which I referred to above.)
> My best guess for the current 8 byte
> padding is to make sure thread_info is calculated properly (by masking
> off the low bits from RSP).
>
> Also, this fix should be applied to 32-bit, but make sure to account
> for TOP_OF_KERNEL_STACK_PADDING.
Ok.
--
Josh
[PATCH] Map in physical addresses in efi_map_region_fixed
This is a simple change to add in the physical mappings as well as the
virtual mappings in efi_map_region_fixed. The motivation here is to
get access to EFI runtime code that is only available via the 1:1
mappings on a kexec'd kernel.
The added call is essentially the kexec analog of the first __map_region
that Boris put in efi_map_region in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping").
Signed-off-by: Alex Thorlton
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: Mike Travis
Cc: Matt Fleming
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
arch/x86/platform/efi/efi_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 459bcbb..b206126 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -363,6 +363,7 @@ void __init efi_map_region(efi_memory_desc_t *md)
*/
void __init efi_map_region_fixed(efi_memory_desc_t *md)
{
+ __map_region(md, md->phys_addr);
__map_region(md, md->virt_addr);
}
--
1.8.5.6
Re: [PATCH 3/4] KVM: arm/arm64: Check for broadcast TLBI support
Hi Matthias,
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.7]
[cannot apply to next-20160805]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Matthias-Brugger/arm64-insn-Do-not-disable-irqs-during-patching/20160804-172016
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
for-next/core
config: arm-axm55xx_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/kvm/arm.c: In function 'kvm_arch_init':
>> arch/arm/kvm/arm.c:1378:6: error: implicit declaration of function
>> 'cpus_have_cap' [-Werror=implicit-function-declaration]
if (cpus_have_cap(ARM64_HAS_NO_BCAST_TLBI)) {
^
>> arch/arm/kvm/arm.c:1378:20: error: 'ARM64_HAS_NO_BCAST_TLBI' undeclared
>> (first use in this function)
if (cpus_have_cap(ARM64_HAS_NO_BCAST_TLBI)) {
^
arch/arm/kvm/arm.c:1378:20: note: each undeclared identifier is reported
only once for each function it appears in
cc1: some warnings being treated as errors
vim +/cpus_have_cap +1378 arch/arm/kvm/arm.c
1372 */
1373 int kvm_arch_init(void *opaque)
1374 {
1375 int err;
1376 int ret, cpu;
1377
> 1378 if (cpus_have_cap(ARM64_HAS_NO_BCAST_TLBI)) {
1379 kvm_err("Missing broadcast TLBI support.\n");
1380 return -ENODEV;
1381 }
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v3 2/3] drm: Add API for capturing frame CRCs
Hi Tomeu, On 22 July 2016 at 15:10, Tomeu Vizoso wrote: > +/** > + * DOC: CRC ABI > + * > + * DRM device drivers can provide to userspace CRC information of each frame > as > + * it reached a given hardware component (a "source"). > + * > + * Userspace can control generation of CRCs in a given CRTC by writing to the s/can/must/ Is it worth having 'auto' as a default source perhaps? > + * file dri/0/crtc-N/crc/control in debugfs, with N being the index of the > CRTC. > + * Accepted values are source names (which are driver-specific) and the > "none" > + * and "auto" keywords. "none" will disable CRC generation and "auto" will > let > + * the driver select a default source of frame CRCs for this CRTC. Is it also worth having 'connector-%s' (named as per sysfs, e.g. connector-HDMI-A-0) as a standardised entry, for cloneable CRTCs which have CRC control on the connector rather than the CRTC? Cheers, Daniel
[PATCH v2] clocksource: Defer override invalidation unless clock is unstable
Clocksources don't get the VALID_FOR_HRES flag until they have been
checked by a watchdog. However, when using an override, the
clocksource_select logic will clear the override value if the
clocksource is not marked VALID_FOR_HRES during that inititial check.
When using the boot arguments clocksource=, this selection can
run before the watchdog, and can cause the override to be incorrectly
cleared.
To address this condition, the override_name is only invalidated for
unstable clocksources. Otherwise, the override is left intact until after
the watchdog has validated the clocksource as stable/unstable.
Signed-off-by: Kyle Walker
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Martin Schwidefsky
Cc: linux-kernel@vger.kernel.org
---
Notes:
Changes from v1:
* Altered changelog description, many thanks to John Stultz for the assist!
kernel/time/clocksource.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 56ece14..4c1bb2a 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -600,9 +600,18 @@ static void __clocksource_select(bool skipcur)
*/
if (!(cs->flags & CLOCK_SOURCE_VALID_FOR_HRES) && oneshot) {
/* Override clocksource cannot be used. */
- pr_warn("Override clocksource %s is not HRT compatible
- cannot switch while in HRT/NOHZ mode\n",
- cs->name);
- override_name[0] = 0;
+ if (cs->flags & CLOCK_SOURCE_UNSTABLE) {
+ pr_warn("Override clocksource %s is unstable
and not HRT compatible - cannot switch while in HRT/NOHZ mode\n",
+ cs->name);
+ override_name[0] = 0;
+ } else {
+ /*
+* The override cannot be currently verified.
+* Deferring to let the watchdog check.
+*/
+ pr_info("Override clocksource %s is not
currently HRT compatible - deferring\n",
+ cs->name);
+ }
} else
/* Override clocksource can be used. */
best = cs;
--
2.5.5
Re: [PATCH v3 1/9] usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align
On Fri, Aug 05 2016, Felipe F. Tonello wrote:
> USB spec specifies wMaxPacketSize to be little endian (as other properties),
> so when using this variable in the driver we should convert to the current
> CPU endianness if necessary.
>
> This patch also introduces usb_ep_align() which does always returns the
> aligned buffer size for an endpoint. This is useful to be used by USB requests
> allocator functions.
>
> Signed-off-by: Felipe F. Tonello
Acked-by: Michal Nazarewicz
> ---
> include/linux/usb/gadget.h | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 612dbdfa388e..3cc93237ff98 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -418,8 +418,20 @@ static inline struct usb_gadget
> *dev_to_usb_gadget(struct device *dev)
> list_for_each_entry(tmp, &(gadget)->ep_list, ep_list)
>
> /**
> + * usb_ep_align - returns @len aligned to ep's maxpacketsize.
> + * @ep: the endpoint whose maxpacketsize is used to align @len
> + * @len: buffer size's length to align to @ep's maxpacketsize
> + *
> + * This helper is used to align buffer's size to an ep's maxpacketsize.
> + */
> +static inline size_t usb_ep_align(struct usb_ep *ep, size_t len)
> +{
> + return round_up(len, (size_t)le16_to_cpu(ep->desc->wMaxPacketSize));
> +}
> +
> +/**
> * usb_ep_align_maybe - returns @len aligned to ep's maxpacketsize if gadget
> - * requires quirk_ep_out_aligned_size, otherwise reguens len.
> + * requires quirk_ep_out_aligned_size, otherwise returns len.
> * @g: controller to check for quirk
> * @ep: the endpoint whose maxpacketsize is used to align @len
> * @len: buffer size's length to align to @ep's maxpacketsize
> @@ -430,8 +442,7 @@ static inline struct usb_gadget *dev_to_usb_gadget(struct
> device *dev)
> static inline size_t
> usb_ep_align_maybe(struct usb_gadget *g, struct usb_ep *ep, size_t len)
> {
> - return !g->quirk_ep_out_aligned_size ? len :
> - round_up(len, (size_t)ep->desc->wMaxPacketSize);
> + return g->quirk_ep_out_aligned_size ? usb_ep_align(ep, len) : len;
> }
>
> /**
> --
> 2.9.0
>
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
Re: [PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code
On Friday, August 05, 2016 08:21:31 AM Thomas Garnier wrote: > On Fri, Aug 5, 2016 at 7:44 AM, Rafael J. Wysocki wrote: > > On Friday, August 05, 2016 12:37:13 PM Pavel Machek wrote: > >> On Wed 2016-08-03 01:19:26, Rafael J. Wysocki wrote: > >> > From: Rafael J. Wysocki > >> > > >> > When CONFIG_RANDOMIZE_MEMORY is set on x86-64, __PAGE_OFFSET becomes > >> > a variable and using it as a symbol in the image memory restoration > >> > assembly code under core_restore_code is not correct any more. > >> > >> On a related note... we should really have page_offset variable in > >> such case, and use that -- having __FOO_BAR not being a constant is > >> ugly/confusing/dangerous. > >> > >> > To avoid that problem, modify set_up_temporary_mappings() to compute > >> > the physical address of the temporary page tables and store it in > >> > temp_level4_pgt, so that the value of that variable is ready to be > >> > written into CR3. Then, the assembly code doesn't have to worry > >> > about converting that value into a physical address and things work > >> > regardless of whether or not CONFIG_RANDOMIZE_MEMORY is set. > >> > > >> > Reported-and-tested-by: Thomas Garnier > >> > Signed-off-by: Rafael J. Wysocki > >> > >> Acked-by: Pavel Machek > >> > >> Is similar patch needed for i386? > > > > Yes, it is, in general, for i386 hibernation to work with ASLR. > > > > But it doesn't work with it for other reasons ATM, AFAICS. > > > > Unfortunately, I won't really have the time to take care of this any time > > soon. > > > > KASLR memory randomization is only available for x64 right now. I plan > on porting to 32bit eventually and will test/adapt hibernation as part > of it. Great to hear that, but you need to be aware that the i386 hibernate code has not been touched for a long time and it makes some heavy assumptions that are not made on x86-64. Please keep me and Pavel in the loop, though. Thanks, Rafael
Re: [RFC][PATCH 0/4] SRAM based reboot reason driver for HiKey
On Fri, Aug 5, 2016 at 7:46 AM, Vladimir Zapolskiy wrote: > Hi John, > > On 08/04/2016 02:05 AM, John Stultz wrote: >> >> Now that Andy's reboot reason core driver has landed, I wanted >> to resubmit a reworked version of my SRAM based reboot reason >> driver. >> >> This allows the kernel to communicate to the bootloader what mode >> it should reboot to using some reserved memory. >> >> Feedback would be very much appreciated! > > > in my opinion the taken approach is wrong, and I've already explained > why and how to rework your driver to shrink the change, please see > https://lkml.org/lkml/2016/1/27/133 > > In this case I think that a SRAM device node should just contain > a plain description of partitions, compatible = "sram-reboot-mode" is > clearly not a device on "SRAM bus", it is not a device at all, so > please let's separate policy from mechanism Having a 2nd node for the driver is still not a device on a bus. It adds unneeded complexity to the binding IMO. The current approach also follows the model ramoops is using. Right now it's using reserved-memory, but that could easily be extended to SRAM region as well. > Because my proposed alternative approach separates policy from > mechanism, it for instanse allows to avoid overlappings on SRAM areas, > and still other drivers may serve as consumers of partitions on SRAM. You could still have multiple consumers and having a compatible string doesn't necessarily imply a driver. Though multiple consumers without something arbitrating access sounds like broken design to me. Rob
[GIT PULL] first round of SCSI updates for the 4.7+ merge window
This is seven basic fixes (plus one MAINTAINERS update) which came in close to the merge window. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc The short changelog is: Brian King (1): ipr: Wait to do async scan until scsi host is initialized Hannes Reinecke (1): fcoe: Use default VLAN for FIP VLAN discovery Johannes Thumshirn (1): lpfc: Fix possible NULL pointer dereference Mauricio Faria de Oliveira (1): lpfc: fix oops in lpfc_sli4_scmd_to_wqidx_distr() from lpfc_send_taskmgmt() Uma Krishnan (2): MAINTAINERS: Update cxlflash maintainers cxlflash: Verify problem state area is mapped before notifying shutdown Wei Yongjun (2): ipr: Fix error return code in ipr_probe_ioa() fcoe: add missing destroy_workqueue() on error in fcoe_init() And the diffstat: MAINTAINERS | 1 + drivers/scsi/cxlflash/main.c | 10 - drivers/scsi/fcoe/fcoe.c | 52 +-- drivers/scsi/fcoe/fcoe.h | 1 + drivers/scsi/ipr.c| 10 + drivers/scsi/ipr.h| 1 + drivers/scsi/lpfc/lpfc_scsi.c | 2 +- drivers/scsi/lpfc/lpfc_sli.c | 15 + 8 files changed, 79 insertions(+), 13 deletions(-) James
Re: [PATCH v2 1/2] befs: remove unused BEFS_BT_MATCH
On Fri, Aug 05, 2016 at 01:41:20PM +0100, Luis de Bethencourt wrote:
> befs_btree_find(), the only caller of befs_find_key(), only cares about if
> the return from that function is BEFS_BT_MATCH or not. It never uses the
> partial match given with BEFS_BT_MATCH. Removing that return and don't set
> the value that will go unused.
>
> Signed-off-by: Luis de Bethencourt
> ---
> v2: fix overflow != not found
> keep a value for the while(!leafnode()) loop to find a leaf node and exit
>
>
> Hi,
>
> This is a correction. Now I understand the difference between returning
> NOT_FOUND when the key is in a full node and we have to look in the overflow.
> Compared to NOT_FOUND when the key doesn't exist.
>
> For the former, we can set the key value to 0 and that means check the
> overflow.
>
> For the latter, we need to return an existing value, even if not correct, so
> the while loop [while (!befs_leafnode(this_node))] can find a leaf, exit and
> then see it is not the correct node in the call of befs_find_next() right
> after
> the loop body.
>
> This makes the code more readable than a mysterious "partial match" that
> actually means no match.
>
> There is still an issue with the comparison of the strings in the binary
> search. About to start looking into that but wanted to send this corrected
> patch first before any of you reviewed the faulty first version.
>
> Thanks,
> Luis
>
> fs/befs/befs.h | 1 -
> fs/befs/btree.c | 38 --
> 2 files changed, 16 insertions(+), 23 deletions(-)
>
> diff --git a/fs/befs/befs.h b/fs/befs/befs.h
> index c5c6cd1..faf3fac 100644
> --- a/fs/befs/befs.h
> +++ b/fs/befs/befs.h
> @@ -79,7 +79,6 @@ enum befs_err {
> BEFS_BT_END,
> BEFS_BT_EMPTY,
> BEFS_BT_MATCH,
> - BEFS_BT_PARMATCH,
> BEFS_BT_NOT_FOUND
> };
>
> diff --git a/fs/befs/btree.c b/fs/befs/btree.c
> index 3f1a391..bc7efb0 100644
> --- a/fs/befs/btree.c
> +++ b/fs/befs/btree.c
> @@ -281,9 +281,9 @@ befs_btree_find(struct super_block *sb, const
> befs_data_stream *ds,
>
> while (!befs_leafnode(this_node)) {
> res = befs_find_key(sb, this_node, key, &node_off);
> - if (res == BEFS_BT_NOT_FOUND)
> + /* if no key set, try the overflow node */
> + if (node_off == 0)
> node_off = this_node->head.overflow;
> - /* if no match, go to overflow node */
> if (befs_bt_read_node(sb, ds, this_node, node_off) != BEFS_OK) {
> befs_error(sb, "befs_btree_find() failed to read "
> "node at %llu", node_off);
> @@ -291,8 +291,7 @@ befs_btree_find(struct super_block *sb, const
> befs_data_stream *ds,
> }
> }
>
> - /* at the correct leaf node now */
> -
> + /* at a leaf node now, check if it is correct */
> res = befs_find_key(sb, this_node, key, value);
>
> brelse(this_node->bh);
> @@ -321,18 +320,13 @@ befs_btree_find(struct super_block *sb, const
> befs_data_stream *ds,
> * @sb: Filesystem superblock
> * @node: Node to find the key within
> * @findkey: Keystring to search for
> - * @value: If key is found, the value stored with the key is put here
> - *
> - * finds exact match if one exists, and returns BEFS_BT_MATCH
> - * If no exact match, finds first key in node that is greater
> - * (alphabetically) than the search key and returns BEFS_BT_PARMATCH
> - * (for partial match, I guess). Can you think of something better to
> - * call it?
> + * @value: If key is found, the value stored with the key is put here.
> + * If not, the value is returned as 0.
> *
> - * If no key was a match or greater than the search key, return
> - * BEFS_BT_NOT_FOUND.
> + * Finds exact match if one exists, and returns BEFS_BT_MATCH.
> + * If there is no exact match, it returns BEFS_BT_NOT_FOUND.
> *
> - * Use binary search instead of a linear.
> + * Uses binary search instead of a linear.
> */
> static int
> befs_find_key(struct super_block *sb, struct befs_btree_node *node,
> @@ -355,8 +349,8 @@ befs_find_key(struct super_block *sb, struct
> befs_btree_node *node,
>
> eq = befs_compare_strings(thiskey, keylen, findkey, findkey_len);
> if (eq < 0) {
> - befs_error(sb, "<--- %s %s not found", __func__, findkey);
> - befs_debug(sb, "<--- %s ERROR", __func__);
> + *value = 0;
> + befs_debug(sb, "<--- node can't contain %s", findkey);
> return BEFS_BT_NOT_FOUND;
> }
>
> @@ -385,12 +379,12 @@ befs_find_key(struct super_block *sb, struct
> befs_btree_node *node,
> else
> first = mid + 1;
> }
> - if (eq < 0)
> - *value = fs64_to_cpu(sb, valarray[mid + 1]);
> - else
> - *value = fs64_to_cpu(sb, valarray[mid]);
> - befs_debug(sb, "<--- %s found %s at %d", __func__, thiskey, mid);
> - return BEFS_BT_
core.c:undefined reference to `fpu_save'
Hi Andrew, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0cbbc422d56668528f6efd1234fe908010284082 commit: c60f169202c7643991a8b4bfeea60e06843d5b5a arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h date: 5 months ago config: mn10300-allnoconfig (attached as .config) compiler: am33_2.0-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout c60f169202c7643991a8b4bfeea60e06843d5b5a # save the attached .config to linux build tree make.cross ARCH=mn10300 All errors (new ones prefixed by >>): kernel/built-in.o: In function `.L412': >> core.c:(.sched.text+0x257): undefined reference to `fpu_save' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH v2 08/22] usb: chipidea: Remove locking in ci_udc_start()
On Fri, Aug 05, 2016 at 02:53:56PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-07-08 02:45:28)
> > On Thu, Jul 07, 2016 at 03:20:59PM -0700, Stephen Boyd wrote:
> > > We don't call hw_device_reset() with the ci->lock held, so it
> > > doesn't seem like this lock here is protecting anything. Let's
> > > just remove it. This allows us to call sleeping functions like
> > > phy_init() from within the CI_HDRC_CONTROLLER_RESET_EVENT hook.
> > >
> > > Cc: Peter Chen
> > > Cc: Greg Kroah-Hartman
> > > Signed-off-by: Stephen Boyd
> > > ---
> > > drivers/usb/chipidea/udc.c | 3 ---
> > > 1 file changed, 3 deletions(-)
> > >
> > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > index 065f5d97aa67..f16be4710cdb 100644
> > > --- a/drivers/usb/chipidea/udc.c
> > > +++ b/drivers/usb/chipidea/udc.c
> > > @@ -1719,7 +1719,6 @@ static int ci_udc_start(struct usb_gadget *gadget,
> > >struct usb_gadget_driver *driver)
> > > {
> > > struct ci_hdrc *ci = container_of(gadget, struct ci_hdrc, gadget);
> > > - unsigned long flags;
> > > int retval = -ENOMEM;
> > >
> > > if (driver->disconnect == NULL)
> > > @@ -1746,7 +1745,6 @@ static int ci_udc_start(struct usb_gadget *gadget,
> > >
> > > pm_runtime_get_sync(&ci->gadget.dev);
> > > if (ci->vbus_active) {
> > > - spin_lock_irqsave(&ci->lock, flags);
> > > hw_device_reset(ci);
> > > } else {
> > > usb_udc_vbus_handler(&ci->gadget, false);
> > > @@ -1755,7 +1753,6 @@ static int ci_udc_start(struct usb_gadget *gadget,
> > > }
> > >
> > > retval = hw_device_state(ci, ci->ep0out->qh.dma);
> > > - spin_unlock_irqrestore(&ci->lock, flags);
> > > if (retval)
> > > pm_runtime_put_sync(&ci->gadget.dev);
> > >
> >
> > The main purpose for this is disabling interrupt when reset controller,
> > in case the unexpected interrupts occur.
> >
> > You can move this between hw_device_state.
> >
>
> Ok, but we don't hold the ci->lock in ci_udc_vbus_session(). Is that a
> bug as well?
I agree with your patch. In fact, during the reset controller, the
interrupt has not been enabled, it should no unexpected interrupt.
--
Best Regards,
Peter Chen
Re: [PATCH v2 2/2] befs: fix typo in befs_find_key
On Fri, Aug 05, 2016 at 01:41:21PM +0100, Luis de Bethencourt wrote: > Fixing skeep to skip. > > Signed-off-by: Luis de Bethencourt > --- > fs/befs/btree.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/befs/btree.c b/fs/befs/btree.c > index bc7efb0..784688c 100644 > --- a/fs/befs/btree.c > +++ b/fs/befs/btree.c > @@ -343,7 +343,7 @@ befs_find_key(struct super_block *sb, struct > befs_btree_node *node, > > findkey_len = strlen(findkey); > > - /* if node can not contain key, just skeep this node */ > + /* if node can not contain key, just skip this node */ > last = node->head.all_key_count - 1; > thiskey = befs_bt_get_key(sb, node, last, &keylen); > > -- > 2.5.1 > Ack-by: Salah Triki Thanx Luis :) Salah
Re: [PATCH v2 06/22] usb: chipidea: Add platform flag for wrapper phy management
On Fri, Aug 05, 2016 at 02:46:00PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-07-08 02:25:35)
> > On Thu, Jul 07, 2016 at 03:20:57PM -0700, Stephen Boyd wrote:
> > > The ULPI phy on qcom platforms needs to be initialized and
> > > powered on after a USB reset and before we toggle the run/stop
> > > bit. Otherwise, the phy locks up and doesn't work properly.
> > > Therefore, add a flag to skip any phy power management in the
> > > core layer, leaving it up to the glue driver to manage.
> > >
> > > Cc: Peter Chen
> > > Cc: Greg Kroah-Hartman
> > > Signed-off-by: Stephen Boyd
> > > ---
> > > drivers/usb/chipidea/core.c | 6 ++
> > > include/linux/usb/chipidea.h | 1 +
> > > 2 files changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > > index 01390e02ee53..532085a096d9 100644
> > > --- a/drivers/usb/chipidea/core.c
> > > +++ b/drivers/usb/chipidea/core.c
> > > @@ -361,6 +361,9 @@ static int _ci_usb_phy_init(struct ci_hdrc *ci)
> > > */
> > > static void ci_usb_phy_exit(struct ci_hdrc *ci)
> > > {
> > > + if (ci->platdata->flags & CI_HDRC_OVERRIDE_PHY_CONTROL)
> > > + return;
> > > +
> > > if (ci->phy) {
> > > phy_power_off(ci->phy);
> > > phy_exit(ci->phy);
> > > @@ -379,6 +382,9 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
> > > {
> > > int ret;
> > >
> > > + if (ci->platdata->flags & CI_HDRC_OVERRIDE_PHY_CONTROL)
> > > + return 0;
> > > +
> >
> > How you handle the code for PHY getting at probe?
> >
>
> Which probe? Glue layer probe? In my case I'm not using the phy until
> the RESET/STOPPED event so I just rely on the chipidea core to get the
> phy and then control the phy manually in the glue layer.
I have no idea about it after reading your patch 10/22.
--
Best Regards,
Peter Chen
Re: [PATCH 3/6] fs: befs: remove useless initialization to zero
On Mon, Aug 01, 2016 at 02:44:18PM +0100, Luis de Bethencourt wrote:
> On 31/07/16 21:34, Salah Triki wrote:
> > node_off is unconditionally set to bt_super.root_node_ptr, so no need to
> > init it to zero.
> >
> > Signed-off-by: Salah Triki
> > ---
> > fs/befs/btree.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/befs/btree.c b/fs/befs/btree.c
> > index f33fc6c..3cb97e8 100644
> > --- a/fs/befs/btree.c
> > +++ b/fs/befs/btree.c
> > @@ -420,7 +420,7 @@ befs_btree_read(struct super_block *sb, const
> > befs_data_stream *ds,
> > {
> > struct befs_btree_node *this_node;
> > befs_btree_super bt_super;
> > - befs_off_t node_off = 0;
> > + befs_off_t node_off;
> > int cur_key;
> > fs64 *valarray;
> > char *keystart;
> >
>
> Looks good to me.
>
> Strange that static analysis didn't pick this one up before.
>
> Acked-by: Luis de Bethencourt
>
> Pushed to the befs-next branch:
> https://github.com/luisbg/linux-befs/tree/befs-next
>
> Thanks Salah,
> Luis
Thanx :)
Salah
Re: perf test BPF failing on f24: fix
On Fri, 5 Aug 2016 11:35:32 -0300
Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 05, 2016 at 06:45:50PM +0900, Masami Hiramatsu escreveu:
> > On Thu, 4 Aug 2016 18:47:24 -0300
> > Arnaldo Carvalho de Melo wrote:
> >
> > > Em Thu, Aug 04, 2016 at 04:36:56PM -0300, Arnaldo Carvalho de Melo
> > > escreveu:
> > > > So:
> > > >
> > > > int err = debuginfo__get_text_offset(dbg, &baseaddr);
> > > >
> > > > is returning 0, no relocation, its dwarf_addrdie() that is not finding
> > > > SyS_epoll_wait from its address.
> > > >
> > > > Trying to figure out why dwarf_addrdie(0xbd295b50) fails...
> > >
> > > So, trying to use that vmlinux with objdump to do disassembly I found
> > > that I need to do some offsetting, and after calculating it, this made
> > > things works for me:
> > >
> > > diff --git a/tools/perf/util/probe-finder.c
> > > b/tools/perf/util/probe-finder.c
> > > index f2d9ff064e2d..9b95754f28ed 100644
> > > --- a/tools/perf/util/probe-finder.c
> > > +++ b/tools/perf/util/probe-finder.c
> > > @@ -1486,6 +1486,8 @@ retry:
> > > /* Find cu die */
> > > if (!dwarf_addrdie(dbg->dbg, (Dwarf_Addr)addr, &cudie)) {
> > > if (!reloc && debuginfo__get_text_offset(dbg, &baseaddr) == 0) {
> > > + if (baseaddr == 0)
> > > + baseaddr = -0x3c00;
> >
> > Hmm, strange... what's this magic number ...?
> > Actually debuginfo__get_text_offset() is for kernel modules and it relocate
> > the offset.
I've found "commit f90acac75713cc6f18a4b2f1b9162bc1cd893c20"
Actually, I forgot to count the relocation at find_alternative_probe_point().
Could you try the patch below?
--
perf-probe: Adjust map->reloc offset when finding kernel symbol from map
From: Masami Hiramatsu
Adjust map->reloc offset for the unmapped address when
finding alternative symbol address from map, because
KASLR can relocate the kernel symbol address.
The same adjustment has been done when finding appropriate
kernel symbol address from map which was introduced by
commit f90acac75713 ("perf probe: Find given address from offline dwarf")
Reported-by: Arnaldo Carvalho de Melo
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-event.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 953dc1a..d5ccb65 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -385,7 +385,7 @@ static int find_alternative_probe_point(struct debuginfo
*dinfo,
if (uprobes)
address = sym->start;
else
- address = map->unmap_ip(map, sym->start);
+ address = map->unmap_ip(map, sym->start) - map->reloc;
break;
}
if (!address) {
[PATCH] Added perf functionality to mmdc driver
$ perf stat -e
mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/
dd if=/dev/zero of=/dev/null bs=1M count=5000
Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
898021787 mmdc/busy-cycles/
14819600 mmdc/read-accesses/
471.30 MB mmdc/read-bytes/
2815419216 mmdc/total-cycles/
13367354 mmdc/write-accesses/
427.76 MB mmdc/write-bytes/
5.334757334 seconds time elapsed
Signed-off-by: Zhengyu Shen
---
arch/arm/mach-imx/mmdc.c | 206 ++-
1 file changed, 205 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
index db9621c..48f3a0b 100644
--- a/arch/arm/mach-imx/mmdc.c
+++ b/arch/arm/mach-imx/mmdc.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011,2016 Freescale Semiconductor, Inc.
* Copyright 2011 Linaro Ltd.
*
* The code contained herein is licensed under the GNU General Public
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+#include
#include "common.h"
@@ -27,12 +29,198 @@
#define BM_MMDC_MDMISC_DDR_TYPE0x18
#define BP_MMDC_MDMISC_DDR_TYPE0x3
+#define TOTAL_CYCLES 0x1
+#define BUSY_CYCLES0x2
+#define READ_ACCESSES 0x3
+#define WRITE_ACCESSES 0x4
+#define READ_BYTES 0x5
+#define WRITE_BYTES0x6
+
+#define DBG_EN 0x1
+#define DBG_RST0x2
+#define PRF_FRZ0x4
+#define CYC_OVF0x8
+
+#define MMDC_MADPCR0 0x410
+#define MMDC_MADPSR0 0x418
+#define MMDC_MADPSR1 0x41C
+#define MMDC_MADPSR2 0x420
+#define MMDC_MADPSR3 0x424
+#define MMDC_MADPSR4 0x428
+#define MMDC_MADPSR5 0x42C
+
+#define to_mmdc_pmu(p) (container_of(p, struct mmdc_pmu, pmu))
+
static int ddr_type;
+PMU_EVENT_ATTR_STRING(total-cycles, evattr_total_cycles, "event=0x01")
+PMU_EVENT_ATTR_STRING(busy-cycles, evattr_busy_cycles, "event=0x02")
+PMU_EVENT_ATTR_STRING(read-accesses, evattr_read_accesses, "event=0x03")
+PMU_EVENT_ATTR_STRING(write-accesses, evattr_write_accesses, "config=0x04")
+PMU_EVENT_ATTR_STRING(read-bytes, evattr_read_bytes, "event=0x05")
+PMU_EVENT_ATTR_STRING(read-bytes.unit, evattr_read_bytes_unit, "MB");
+PMU_EVENT_ATTR_STRING(read-bytes.scale, evattr_read_bytes_scale, "0.01");
+PMU_EVENT_ATTR_STRING(write-bytes, evattr_write_bytes, "event=0x06")
+PMU_EVENT_ATTR_STRING(write-bytes.unit, evattr_write_bytes_unit, "MB");
+PMU_EVENT_ATTR_STRING(write-bytes.scale, evattr_write_bytes_scale, "0.01");
+
+struct mmdc_pmu
+{
+ struct pmu pmu;
+ void __iomem *mmdc_base;
+};
+
+static struct attribute *events_attrs[] = {
+ &evattr_total_cycles.attr.attr,
+ &evattr_busy_cycles.attr.attr,
+ &evattr_read_accesses.attr.attr,
+ &evattr_write_accesses.attr.attr,
+ &evattr_read_bytes.attr.attr,
+ &evattr_read_bytes_unit.attr.attr,
+ &evattr_read_bytes_scale.attr.attr,
+ &evattr_write_bytes.attr.attr,
+ &evattr_write_bytes_unit.attr.attr,
+ &evattr_write_bytes_scale.attr.attr,
+ NULL,
+};
+
+PMU_FORMAT_ATTR(event, "config:0-63");
+static struct attribute *format_attrs[] = {
+ &format_attr_event.attr,
+ NULL,
+};
+
+static struct attribute_group format_attr_group = {
+ .name = "format",
+ .attrs = format_attrs,
+};
+
+static struct attribute_group events_attr_group = {
+ .name = "events",
+ .attrs = events_attrs,
+};
+
+static const struct attribute_group * attr_groups[] = {
+ &events_attr_group,
+ &format_attr_group,
+ NULL,
+};
+
+static inline u64 mmdc_read_counter(struct perf_event *event)
+{
+ unsigned int val;
+ u64 ret;
+ int cfg = (int) event->attr.config;
+ struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
+ void __iomem *mmdc_base, *reg;
+
+ mmdc_base = pmu_mmdc->mmdc_base;
+
+ writel_relaxed(PRF_FRZ, mmdc_base + MMDC_MADPCR0);
+
+ switch (cfg)
+ {
+ case TOTAL_CYCLES:
+ reg = mmdc_base + MMDC_MADPSR0;
+ break;
+ case BUSY_CYCLES:
+ reg = mmdc_base + MMDC_MADPSR1;
+ break;
+ case READ_ACCESSES:
+ reg = mmdc_base + MMDC_MADPSR2;
+ break;
+ case WRITE_ACCESSES:
+ reg = mmdc_base + MMDC_MADPSR3;
+ break;
+ case READ_BYTES:
+ reg = mmdc_base + MMDC_MADPSR4;
+ break;
+ case WRITE_BYTES:
+ reg = mmdc_base + MMDC_MADPSR5;
+ break;
+ default:
+ return -1;
+ }
+ val = readl_relaxed(reg)
Re: [PATCH v3 4/9] usb: gadget: f_midi: defaults buflen sizes to 512
On Fri, Aug 05 2016, Felipe F. Tonello wrote: > 512 is the value used by wMaxPacketSize, as specified by the USB Spec. This > makes sure this driver uses, by default, the most optimal value for IN and OUT > endpoint requests. > > Signed-off-by: Felipe F. Tonello Acked-by: Michal Nazarewicz > --- > drivers/usb/gadget/function/f_midi.c | 2 +- > drivers/usb/gadget/legacy/gmidi.c| 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/function/f_midi.c > b/drivers/usb/gadget/function/f_midi.c > index 39018dea7035..a7b50ac947f8 100644 > --- a/drivers/usb/gadget/function/f_midi.c > +++ b/drivers/usb/gadget/function/f_midi.c > @@ -1122,7 +1122,7 @@ static struct usb_function_instance > *f_midi_alloc_inst(void) > opts->func_inst.free_func_inst = f_midi_free_inst; > opts->index = SNDRV_DEFAULT_IDX1; > opts->id = SNDRV_DEFAULT_STR1; > - opts->buflen = 256; > + opts->buflen = 512; > opts->qlen = 32; > opts->in_ports = 1; > opts->out_ports = 1; > diff --git a/drivers/usb/gadget/legacy/gmidi.c > b/drivers/usb/gadget/legacy/gmidi.c > index fc2ac150f5ff..0bf39c3ccdb1 100644 > --- a/drivers/usb/gadget/legacy/gmidi.c > +++ b/drivers/usb/gadget/legacy/gmidi.c > @@ -47,7 +47,7 @@ static char *id = SNDRV_DEFAULT_STR1; > module_param(id, charp, S_IRUGO); > MODULE_PARM_DESC(id, "ID string for the USB MIDI Gadget adapter."); > > -static unsigned int buflen = 256; > +static unsigned int buflen = 512; > module_param(buflen, uint, S_IRUGO); > MODULE_PARM_DESC(buflen, "MIDI buffer length"); > > -- > 2.9.0 > -- Best regards ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ «If at first you don’t succeed, give up skydiving»
[PATCH] Staging: wlan-ng: fixed "block comments" warnings
This patch fix "block comments use *" warning returned by checkpatch.pl script. Signed-off-by: Claudiu Beznea --- drivers/staging/wlan-ng/hfa384x.h | 234 +++-- drivers/staging/wlan-ng/hfa384x_usb.c | 172 drivers/staging/wlan-ng/p80211netdev.c | 45 --- drivers/staging/wlan-ng/p80211req.c| 6 +- drivers/staging/wlan-ng/prism2fw.c | 33 +++-- drivers/staging/wlan-ng/prism2mgmt.c | 30 +++-- drivers/staging/wlan-ng/prism2mgmt.h | 4 +- drivers/staging/wlan-ng/prism2mib.c| 48 +++ 8 files changed, 353 insertions(+), 219 deletions(-) diff --git a/drivers/staging/wlan-ng/hfa384x.h b/drivers/staging/wlan-ng/hfa384x.h index cec6d0b..6a3e1ef 100644 --- a/drivers/staging/wlan-ng/hfa384x.h +++ b/drivers/staging/wlan-ng/hfa384x.h @@ -110,7 +110,8 @@ #defineHFA384x_ADDR_FLAT_CMD_OFF_MASK (0x) /* Mask bits for discarding unwanted pieces in AUX format - 16-bit address parts */ + * 16-bit address parts + */ #defineHFA384x_ADDR_AUX_PAGE_MASK (0x) #defineHFA384x_ADDR_AUX_OFF_MASK (0x007f) @@ -172,21 +173,23 @@ /*--- Result Codes --*/ #defineHFA384x_CMD_ERR ((u16)(0x7F)) -/*--- Programming Modes -- - MODE 0: Disable programming - MODE 1: Enable volatile memory programming - MODE 2: Enable non-volatile memory programming - MODE 3: Program non-volatile memory section ---*/ +/* --- Programming Modes -- + * MODE 0: Disable programming + * MODE 1: Enable volatile memory programming + * MODE 2: Enable non-volatile memory programming + * MODE 3: Program non-volatile memory section + * -- + */ #defineHFA384x_PROGMODE_DISABLE((u16)0x00) #defineHFA384x_PROGMODE_RAM((u16)0x01) #defineHFA384x_PROGMODE_NV ((u16)0x02) #defineHFA384x_PROGMODE_NVWRITE((u16)0x03) /*--- Record ID Constants --*/ -/* -Configuration RIDs: Network Parameters, Static Configuration Entities -*/ +/* + * Configuration RIDs: Network Parameters, Static Configuration Entities + * + */ #defineHFA384x_RID_CNFPORTTYPE ((u16)0xFC00) #defineHFA384x_RID_CNFOWNMACADDR ((u16)0xFC01) #defineHFA384x_RID_CNFDESIREDSSID ((u16)0xFC02) @@ -194,27 +197,30 @@ Configuration RIDs: Network Parameters, Static Configuration Entities #defineHFA384x_RID_CNFOWNSSID ((u16)0xFC04) #defineHFA384x_RID_CNFMAXDATALEN ((u16)0xFC07) -/* -Configuration RID lengths: Network Params, Static Config Entities - This is the length of JUST the DATA part of the RID (does not - include the len or code fields) -*/ +/* + * Configuration RID lengths: Network Params, Static Config Entities + * This is the length of JUST the DATA part of the RID (does not + * include the len or code fields) + * + */ #defineHFA384x_RID_CNFOWNMACADDR_LEN ((u16)6) #defineHFA384x_RID_CNFDESIREDSSID_LEN ((u16)34) #defineHFA384x_RID_CNFOWNSSID_LEN ((u16)34) -/* -Configuration RIDs: Network Parameters, Dynamic Configuration Entities -*/ +/* + * Configuration RIDs: Network Parameters, Dynamic Configuration Entities + * + */ #defineHFA384x_RID_CREATEIBSS ((u16)0xFC81) #defineHFA384x_RID_FRAGTHRESH ((u16)0xFC82) #defineHFA384x_RID_RTSTHRESH ((u16)0xFC83) #defineHFA384x_RID_TXRATECNTL ((u16)0xFC84) #defineHFA384x_RID_PROMISCMODE ((u16)0xFC85) -/*-- -Information RIDs: NIC Information -*/ +/* --
Re: [RFC PATCH] softirq: fix tasklet_kill() usage and users
ping !!
On 8/1/2016 9:13 PM, Santosh Shilimkar wrote:
Semantically the expectation from the tasklet init/kill API
should be as below.
tasklet_init() == Init and Enable scheduling
tasklet_kill() == Disable scheduling and Destroy
tasklet_init() API exibit above behavior but not the
tasklet_kill(). The tasklet handler can still get scheduled
and run even after the tasklet_kill().
There are 2, 3 places where drivers are working around
this issue by calling tasklet_disable() which will add an
usecount and there by avoiding the handlers being called.
One of the example 'commit 1e1257860fd1
("tty/serial: at91: correct the usage of tasklet")'
tasklet_enable/tasklet_disable is a pair API and expected
to be used together. Usage of tasklet_disable() *just* to
workround tasklet scheduling after kill is probably not the
correct and inteded use of the API as done the API.
We also happen to see similar issue where in shutdown path
the tasklet_handler was getting called even after the
tasklet_kill().
We can fix this be making sure tasklet_kill() does right
thing and there by ensuring tasklet handler won't run after
tasklet_kil() with very simple change. Patch fixes the tasklet
code and also few drivers hacks to workaround the issue.
Cc: Greg Kroah-Hartman
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Tadeusz Struk
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Paul Bolle
Cc: Nicolas Ferre
Signed-off-by: Santosh Shilimkar
---
drivers/crypto/qat/qat_common/adf_isr.c| 1 -
drivers/crypto/qat/qat_common/adf_sriov.c | 1 -
drivers/crypto/qat/qat_common/adf_vf_isr.c | 2 --
drivers/isdn/gigaset/interface.c | 1 -
drivers/tty/serial/atmel_serial.c | 1 -
kernel/softirq.c | 7 ---
6 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_isr.c
b/drivers/crypto/qat/qat_common/adf_isr.c
index 06d4901..fd5e900 100644
--- a/drivers/crypto/qat/qat_common/adf_isr.c
+++ b/drivers/crypto/qat/qat_common/adf_isr.c
@@ -296,7 +296,6 @@ static void adf_cleanup_bh(struct adf_accel_dev *accel_dev)
int i;
for (i = 0; i < hw_data->num_banks; i++) {
- tasklet_disable(&priv_data->banks[i].resp_handler);
tasklet_kill(&priv_data->banks[i].resp_handler);
}
}
diff --git a/drivers/crypto/qat/qat_common/adf_sriov.c
b/drivers/crypto/qat/qat_common/adf_sriov.c
index 4a526e2..9e65888 100644
--- a/drivers/crypto/qat/qat_common/adf_sriov.c
+++ b/drivers/crypto/qat/qat_common/adf_sriov.c
@@ -204,7 +204,6 @@ void adf_disable_sriov(struct adf_accel_dev *accel_dev)
}
for (i = 0, vf = accel_dev->pf.vf_info; i < totalvfs; i++, vf++) {
- tasklet_disable(&vf->vf2pf_bh_tasklet);
tasklet_kill(&vf->vf2pf_bh_tasklet);
mutex_destroy(&vf->pf2vf_lock);
}
diff --git a/drivers/crypto/qat/qat_common/adf_vf_isr.c
b/drivers/crypto/qat/qat_common/adf_vf_isr.c
index aa689ca..81e63bf 100644
--- a/drivers/crypto/qat/qat_common/adf_vf_isr.c
+++ b/drivers/crypto/qat/qat_common/adf_vf_isr.c
@@ -191,7 +191,6 @@ static int adf_setup_pf2vf_bh(struct adf_accel_dev
*accel_dev)
static void adf_cleanup_pf2vf_bh(struct adf_accel_dev *accel_dev)
{
- tasklet_disable(&accel_dev->vf.pf2vf_bh_tasklet);
tasklet_kill(&accel_dev->vf.pf2vf_bh_tasklet);
mutex_destroy(&accel_dev->vf.vf2pf_lock);
}
@@ -268,7 +267,6 @@ static void adf_cleanup_bh(struct adf_accel_dev *accel_dev)
{
struct adf_etr_data *priv_data = accel_dev->transport;
- tasklet_disable(&priv_data->banks[0].resp_handler);
tasklet_kill(&priv_data->banks[0].resp_handler);
}
diff --git a/drivers/isdn/gigaset/interface.c b/drivers/isdn/gigaset/interface.c
index 600c79b..2ce63b6 100644
--- a/drivers/isdn/gigaset/interface.c
+++ b/drivers/isdn/gigaset/interface.c
@@ -524,7 +524,6 @@ void gigaset_if_free(struct cardstate *cs)
if (!drv->have_tty)
return;
- tasklet_disable(&cs->if_wake_tasklet);
tasklet_kill(&cs->if_wake_tasklet);
cs->tty_dev = NULL;
tty_unregister_device(drv->tty, cs->minor_index);
diff --git a/drivers/tty/serial/atmel_serial.c
b/drivers/tty/serial/atmel_serial.c
index 954941d..27e638e 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1915,7 +1915,6 @@ static void atmel_shutdown(struct uart_port *port)
* Clear out any scheduled tasklets before
* we destroy the buffers
*/
- tasklet_disable(&atmel_port->tasklet);
tasklet_kill(&atmel_port->tasklet);
/*
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 17caf4b..21397eb 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -498,7 +498,7 @@ static void tasklet_action(struct softirq_action *a)
list = list->next;
if (tasklet_trylock(t)) {
- if (!atomic_read(&t->count)) {
+ if (atomic
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures
On Saturday, August 6, 2016 2:17:16 PM CEST Nicholas Piggin wrote: > On Fri, 05 Aug 2016 21:16:00 +0200 > Arnd Bergmann wrote: > > > On Saturday, August 6, 2016 2:16:42 AM CEST Nicholas Piggin wrote: > > > > > > > > diff --git a/include/asm-generic/vmlinux.lds.h > > > > b/include/asm-generic/vmlinux.lds.h > > > > index 0ec807d69f18..7a3ad269fa23 100644 > > > > --- a/include/asm-generic/vmlinux.lds.h > > > > +++ b/include/asm-generic/vmlinux.lds.h > > > > @@ -433,7 +433,7 @@ > > > > * during second ld run in second ld pass when generating System.map */ > > > > #define TEXT_TEXT\ > > > > ALIGN_FUNCTION(); \ > > > > - *(.text.hot .text .text.fixup .text.unlikely) \ > > > > + *(.text.hot .text .text.* .text.fixup .text.unlikely) \ > > > > *(.ref.text)\ > > > > MEM_KEEP(init.text) \ > > > > MEM_KEEP(exit.text) \ > > > > > > > > > > > > It also got much faster again, the link time for an allyesconfig > > > > kernel is now 18 minutes instead of 10 hours, but it's still > > > > much worse than the 2 minutes I had earlier or the four minutes > > > > with the previous patch. > > > > > > Are you using the patches I just sent? > > > > Not yet, I was still busy with the older version, and trying to > > figure out exactly what went wrong in ld.bfd. FWIW, I first tried > > to see if the hash tables were just too small, but as it turned > > out that was not the problem. When I tried to change the default > > hash table sizes, making them bigger only made things slower. > > > > I also found the --hash-size=xxx option, which has a significant > > impact on runtime speed. Interestingly again, using sizes less > > than the default made things faster in practice. If we can > > work out the optimum size for the kernel build, that might > > shave a few minutes off the total build time. > > > > > Either way, you also need > > > to do the same for data and bss sections as you are using > > > -fdata-sections too. > > > > Right. > > > > > I've found virtually no build time regression on powerpc or x86 > > > when those are taken care of properly (x86 numbers I sent are typo, > > > it's not 5m20, it's 5m02). > > > > Interesting. I wonder if it's got something to do with the > > generation of the branch trampolines on ARM, as we have a lot > > of them on an allyesconfig. > > Powerpc generates quite a few branch trampolines as well, so > I'm not sure if that would be the issue. Can you get a profile > of the link? CPU: AMD64 family15h, speed 2600 MHz (estimated) Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 10 samples %image name symbol name 1212556 63.6990 ld-new bfd_hash_lookup 416050 21.8563 ld-new bfd_hash_hash 64861 3.4073 no-vmlinux /no-vmlinux 59038 3.1014 ld-new bfd_hash_traverse 13873 0.7288 ld-new bfd_get_next_section_by_name 9880 0.5190 ld-new strrevcmp I've manually marked bfd_hash_hash as __attribute__((noinline)) to see it separately from bfd_hash_lookup. The vast majority of these calls seem to come from _bfd_elf_strtab_add and from bfd_get_section_by_name/bfd_get_next_section_by_name. While I first thought the hash tables were too slow, investigating further showed that most of the hash tables are really small (and appropriately sized), we just do a lot of lookups on them. > Are you linking with archives? Do your input archives have a > symbol index built? yes, and don't know. I've moved on to your new patches now, will see how that goes. > > Is the 5m20 the total build time for the kernel, the time for > > rebuilding after a trivial change, or the time to call 'ld.bfd' > > once? > > 5m02 was the total time for x86 defconfig. With the powerpc > allyesconfig build, the final link: > > $ time ld -EL -m elf64lppc -pie --emit-relocs --build-id --gc-sections -X -o > vmlinux -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive built-in.o > .tmp_kallsyms2.o > > real 0m15.556s > user 0m13.288s > sys 0m2.240s > > $ ls -lh vmlinux > -rwxrwxr-x 1 npiggin npiggin 279M Aug 6 14:02 vmlinux > > Without -pie --emit-relocs it's 11.8s and 150M but I'm using > emit-relocs for a post-link step. Interesting, that does sound more like an ARM specific bug in ld then. > > Are you using ld.bfd on x86 or ld.gold? For me ld.gold either > > works and is really fast, or it crashes, depending on the > > configuration. I also don't think it supports big-endian ARM > > (which is what allyesconfig ends up using). > > ld.bfd on both. Gold crashed on powerpc and I didn't try it on x86. Ok. Arnd
Re: [RFC][PATCH 5/7] cpufreq / sched: UUF_IO flag to indicate iowait condition
On Thursday, August 04, 2016 03:09:08 PM Steve Muckle wrote: > On Thu, Aug 04, 2016 at 11:19:00PM +0200, Rafael J. Wysocki wrote: [cut] > > > This is also an issue for the remote wakeup case where I currently have > > > another invocation of the hook in check_preempt_curr(), so I can know if > > > preemption was triggered and skip a remote schedutil update in that case > > > to avoid a duplicate IPI. > > > > > > It seems to me worth evaluating if a higher level set of hook locations > > > could be used. One possibility is higher up in CFS: > > > - enqueue_task_fair, dequeue_task_fair > > > - scheduler_tick > > > - active_load_balance_cpu_stop, load_balance > > > > Agreed, that's worth checking. > > > > > Though this wouldn't solve my issue with check_preempt_curr. That would > > > probably require going further up the stack to try_to_wake_up() etc. Not > > > yet sure what the other hook locations would be at that level. > > > > That's probably too far away from the root cfs_rq utilization changes IMO. > > Is your concern that the rate of hook calls would be decreased? It might be decreased, but also we might end up using utilization values that wouldn't reflect the current situation (eg. if the hook is called before update_load_avg(), the util value used by the governor may not be adequate). Thanks, Rafael
Re: [PATCH] asus-laptop: get rid of parse_arg()
On Fri, Aug 05, 2016 at 04:15:07PM -0700, Darren Hart wrote:
> On Fri, Aug 05, 2016 at 11:57:10PM +0300, Giedrius Statkevičius wrote:
> > parse_arg() duplicates the funcionality of kstrtoint() so use the latter
> > function instead. There is no funcionality change except that in the
> > case of input being too big -ERANGE will be returned instead of -EINVAL
> > which is not bad because -ERANGE makes more sense here. The check for
> > !count is already done by the sysfs core so no need to duplicate it
> > again. Also, add some minor corrections to error handling to accommodate
> > the change in return values (parse_arg returned count if everything
> > succeeded whereas kstrtoint returns 0 in the same situation)
> >
> > As a result of this patch asus-laptop.ko size is reduced by almost 1%:
> > add/remove: 0/1 grow/shrink: 1/6 up/down: 1/-149 (-148)
> > function old new delta
> > __UNIQUE_ID_vermagic0 69 70 +1
> > ls_switch_store 133 117 -16
> > ledd_store 175 159 -16
> > display_store157 141 -16
> > ls_level_store 193 176 -17
> > gps_store200 178 -22
> > sysfs_acpi_set.isra 148 125 -23
> > parse_arg.part39 - -39
> > Total: Before=19160, After=19012, chg -0.77%
> >
> > Signed-off-by: Giedrius Statkevičius
> > ---
> > drivers/platform/x86/asus-laptop.c | 77
> > ++
> > 1 file changed, 36 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/platform/x86/asus-laptop.c
> > b/drivers/platform/x86/asus-laptop.c
> > index 15f1311..28551f5 100644
> > --- a/drivers/platform/x86/asus-laptop.c
> > +++ b/drivers/platform/x86/asus-laptop.c
> > @@ -932,30 +932,19 @@ static ssize_t infos_show(struct device *dev, struct
> > device_attribute *attr,
> > }
> > static DEVICE_ATTR_RO(infos);
> >
> > -static int parse_arg(const char *buf, unsigned long count, int *val)
> > -{
> > - if (!count)
> > - return 0;
> > - if (count > 31)
> > - return -EINVAL;
> > - if (sscanf(buf, "%i", val) != 1)
> > - return -EINVAL;
> > - return count;
> > -}
> > -
> > static ssize_t sysfs_acpi_set(struct asus_laptop *asus,
> > const char *buf, size_t count,
> > const char *method)
> > {
> > int rv, value;
> >
> > - rv = parse_arg(buf, count, &value);
> > - if (rv <= 0)
> > + rv = kstrtoint(buf, 0, &value);
> > + if (rv < 0)
> > return rv;
> >
> > if (write_acpi_int(asus->handle, method, value))
> > return -ENODEV;
> > - return rv;
> > + return count;
>
> This makes explicit what was hidden before - count is merely a range check, it
> isn't used in parsing the string... I'm not sure if this is a problem, but it
> caught my interest. If count is passed as 12, but buf only contains 3
> character,
> it may succeed and return 12. I suppose this is a failure in the caller, and
> doesn't impact this function - unless the caller isn't expected to properly
> terminate the string... but if that were the case, it would have failed
> previously as we didn't check for that in parse_arg either this is fine as
> is I suppose - can be addressed separately if need be.
>
According to Documentation/filesystems/sysfs.txt:
"On write(2), ... A terminating null is added after the data on stores. This
makes functions like sysfs_streq() safe to use."
So it should be guaranteed that the buffer is a proper C string. Also, we could
say kstrtoint() or sscanf() uses all of the buffer so it is safe to return count
(as it says in the documentation) as it was before this patch (parse_int
returned count if everything succeeded).
> > }
> >
> > /*
> > @@ -975,15 +964,17 @@ static ssize_t ledd_store(struct device *dev, struct
> > device_attribute *attr,
> > struct asus_laptop *asus = dev_get_drvdata(dev);
> > int rv, value;
> >
> > - rv = parse_arg(buf, count, &value);
> > - if (rv > 0) {
> > - if (write_acpi_int(asus->handle, METHOD_LEDD, value)) {
> > - pr_warn("LED display write failed\n");
> > - return -ENODEV;
> > - }
> > - asus->ledd_status = (u32) value;
> > + rv = kstrtoint(buf, 0, &value);
> > + if (rv < 0)
> > + return rv;
> >
>
> This inverts the check to check for failure (this is preferred), but it does
> change the successful path to include the value of 0, which was skipped over
> in
> the original above.
>
> > + if (write_acpi_int(asus->handle, METHOD_LEDD, value)) {
>
> What is value if rv is 0? Perhaps safer/more explicit to test for (rv <= 0)
> above. Please consider, and apply decision to all similar instances below.
>
[PATCH v2 01/14] net: ethernet: ti: cpsw: simplify submit routine
As second net dev is created only in case of dual_emac mode, port
number can be figured out in simpler way. Also no need to pass
redundant ndev struct.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c51f346..8972bf6 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1065,19 +1065,11 @@ static int cpsw_common_res_usage_state(struct cpsw_priv
*priv)
return usage_count;
}
-static inline int cpsw_tx_packet_submit(struct net_device *ndev,
- struct cpsw_priv *priv, struct sk_buff *skb)
+static inline int cpsw_tx_packet_submit(struct cpsw_priv *priv,
+ struct sk_buff *skb)
{
- if (!priv->data.dual_emac)
- return cpdma_chan_submit(priv->txch, skb, skb->data,
- skb->len, 0);
-
- if (ndev == cpsw_get_slave_ndev(priv, 0))
- return cpdma_chan_submit(priv->txch, skb, skb->data,
- skb->len, 1);
- else
- return cpdma_chan_submit(priv->txch, skb, skb->data,
- skb->len, 2);
+ return cpdma_chan_submit(priv->txch, skb, skb->data, skb->len,
+priv->emac_port + priv->data.dual_emac);
}
static inline void cpsw_add_dual_emac_def_ale_entries(
@@ -1406,7 +1398,7 @@ static netdev_tx_t cpsw_ndo_start_xmit(struct sk_buff
*skb,
skb_tx_timestamp(skb);
- ret = cpsw_tx_packet_submit(ndev, priv, skb);
+ ret = cpsw_tx_packet_submit(priv, skb);
if (unlikely(ret != 0)) {
cpsw_err(priv, tx_err, "desc submit failed\n");
goto fail;
--
1.9.1
Re: [PATCH v4 0/6] power: add power sequence library
El 2016-08-02 05:30, Peter Chen escribió: Hi all, This is a follow-up for my last power sequence framework patch set [1]. According to Rob Herring and Ulf Hansson's comments[2], I use a generic power sequence library for parsing the power sequence elements on DT, and implement generic power sequence on library. The host driver can allocate power sequence instance, and calls pwrseq APIs accordingly. In future, if there are special power sequence requirements, the special power sequence library can be created. This patch set is tested on i.mx6 sabresx evk using a dts change, I use two hot-plug devices to simulate this use case, the related binding change is updated at patch [1/6], The udoo board changes were tested using my last power sequence patch set.[3] Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also need to power on itself before it can be found by ULPI bus. [1] http://www.spinics.net/lists/linux-usb/msg142755.html [2] http://www.spinics.net/lists/linux-usb/msg143106.html [3] http://www.spinics.net/lists/linux-usb/msg142815.html Changes for v4: - Create the patch on next-20160722 - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6] - Using more friendly wait method for reset gpio [Patch 2/6] - Support multiple input clocks [Patch 2/6] - Add Rob Herring's ack for DT changes - Add Joshua Clayton's Tested-by Changes for v3: - Delete "power-sequence" property at binding-doc, and change related code at both library and user code. - Change binding-doc example node name with Rob's comments - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags, add additional code request gpio with proper gpio flags - Add Philipp Zabel's Ack and MAINTAINER's entry Changes for v2: - Delete "pwrseq" prefix and clock-names for properties at dt binding - Should use structure not but its pointer for kzalloc - Since chipidea core has no of_node, let core's of_node equals glue layer's at core's probe Peter Chen (6): binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library power: add power sequence library binding-doc: usb: usb-device: add optional properties for power sequence usb: core: add power sequence handling for USB devices usb: chipidea: let chipidea core device of_node equal's glue layer device of_node ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property Hi Peter, I tried the last version on my udoo board but I got these compile errors: [21330s] ERROR: "pwrseq_get" [drivers/usb/core/usbcore.ko] undefined! [21330s] ERROR: "pwrseq_free" [drivers/usb/core/usbcore.ko] undefined! [21330s] ERROR: "pwrseq_put" [drivers/usb/core/usbcore.ko] undefined! [21330s] ERROR: "pwrseq_off" [drivers/usb/core/usbcore.ko] undefined! [21330s] ERROR: "pwrseq_on" [drivers/usb/core/usbcore.ko] undefined! Will you do another version? Thanks! -- Oscar
[PATCH v2 06/14] net: ethernet: ti: cpsw: create common struct to hold shared driver data
This patch simply create holder for common data and as a start moves
pdev var to it.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 62 ++
1 file changed, 39 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 19aa4bb..ac875b3 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -363,8 +363,11 @@ static inline void slave_write(struct cpsw_slave *slave,
u32 val, u32 offset)
__raw_writel(val, slave->regs + offset);
}
-struct cpsw_priv {
+struct cpsw_common {
struct platform_device *pdev;
+};
+
+struct cpsw_priv {
struct net_device *ndev;
struct napi_struct napi_rx;
struct napi_struct napi_tx;
@@ -394,6 +397,7 @@ struct cpsw_priv {
u32 num_irqs;
struct cpts *cpts;
u32 emac_port;
+ struct cpsw_common *cpsw;
};
struct cpsw_stats {
@@ -484,6 +488,7 @@ static const struct cpsw_stats cpsw_gstrings_stats[] = {
#define CPSW_STATS_LEN ARRAY_SIZE(cpsw_gstrings_stats)
+#define ndev_to_cpsw(ndev) (((struct cpsw_priv *)netdev_priv(ndev))->cpsw)
#define napi_to_priv(napi) container_of(napi, struct cpsw_priv, napi)
#define for_each_slave(priv, func, arg...) \
do {\
@@ -1095,6 +1100,7 @@ static void soft_reset_slave(struct cpsw_slave *slave)
static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
{
u32 slave_port;
+ struct cpsw_common *cpsw = priv->cpsw;
soft_reset_slave(slave);
@@ -1153,7 +1159,7 @@ static void cpsw_slave_open(struct cpsw_slave *slave,
struct cpsw_priv *priv)
phy_start(slave->phy);
/* Configure GMII_SEL register */
- cpsw_phy_sel(&priv->pdev->dev, slave->phy->interface, slave->slave_num);
+ cpsw_phy_sel(&cpsw->pdev->dev, slave->phy->interface, slave->slave_num);
}
static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
@@ -1235,12 +1241,13 @@ static void cpsw_slave_stop(struct cpsw_slave *slave,
struct cpsw_priv *priv)
static int cpsw_ndo_open(struct net_device *ndev)
{
struct cpsw_priv *priv = netdev_priv(ndev);
+ struct cpsw_common *cpsw = priv->cpsw;
int i, ret;
u32 reg;
- ret = pm_runtime_get_sync(&priv->pdev->dev);
+ ret = pm_runtime_get_sync(&cpsw->pdev->dev);
if (ret < 0) {
- pm_runtime_put_noidle(&priv->pdev->dev);
+ pm_runtime_put_noidle(&cpsw->pdev->dev);
return ret;
}
@@ -1317,7 +1324,7 @@ static int cpsw_ndo_open(struct net_device *ndev)
*/
cpsw_info(priv, ifup, "submitted %d rx descriptors\n", i);
- if (cpts_register(&priv->pdev->dev, priv->cpts,
+ if (cpts_register(&cpsw->pdev->dev, priv->cpts,
priv->data.cpts_clock_mult,
priv->data.cpts_clock_shift))
dev_err(priv->dev, "error registering cpts device\n");
@@ -1342,7 +1349,7 @@ static int cpsw_ndo_open(struct net_device *ndev)
err_cleanup:
cpdma_ctlr_stop(priv->dma);
for_each_slave(priv, cpsw_slave_stop, priv);
- pm_runtime_put_sync(&priv->pdev->dev);
+ pm_runtime_put_sync(&cpsw->pdev->dev);
netif_carrier_off(priv->ndev);
return ret;
}
@@ -1350,6 +1357,7 @@ err_cleanup:
static int cpsw_ndo_stop(struct net_device *ndev)
{
struct cpsw_priv *priv = netdev_priv(ndev);
+ struct cpsw_common *cpsw = priv->cpsw;
cpsw_info(priv, ifdown, "shutting down cpsw device\n");
netif_stop_queue(priv->ndev);
@@ -1366,7 +1374,7 @@ static int cpsw_ndo_stop(struct net_device *ndev)
cpsw_ale_stop(priv->ale);
}
for_each_slave(priv, cpsw_slave_stop, priv);
- pm_runtime_put_sync(&priv->pdev->dev);
+ pm_runtime_put_sync(&cpsw->pdev->dev);
if (priv->data.dual_emac)
priv->slaves[priv->emac_port].open_stat = false;
return 0;
@@ -1598,6 +1606,7 @@ static int cpsw_ndo_set_mac_address(struct net_device
*ndev, void *p)
{
struct cpsw_priv *priv = netdev_priv(ndev);
struct sockaddr *addr = (struct sockaddr *)p;
+ struct cpsw_common *cpsw = priv->cpsw;
int flags = 0;
u16 vid = 0;
int ret;
@@ -1605,9 +1614,9 @@ static int cpsw_ndo_set_mac_address(struct net_device
*ndev, void *p)
if (!is_valid_ether_addr(addr->sa_data))
return -EADDRNOTAVAIL;
- ret = pm_runtime_get_sync(&priv->pdev->dev);
+ ret = pm_runtime_get_sync(&cpsw->pdev->dev);
if (ret < 0) {
- pm_runtime_put_noidle(&priv->pdev->dev);
+ pm_runtime_put_noidle(&cpsw->pdev->dev);
return ret;
}
Re: [GIT PULL] platform-drivers-x86 for 4.8-2
On Fri, Aug 5, 2016 at 6:51 PM, Darren Hart wrote: > > Minor platform specific event handling updates and a Kconfig cleanup. No. You already sent a *different* copy of all of these except for the dell-wmi one in a previous pull requests. This pull request gets me four new commits, but three of them I already had. From you. See for example your new commit 2dd73625dedc platform/x86: Drop duplicate dependencies on X86 vs 25789f95a883 platform/x86: Drop duplicate dependencies on X86 which are identical patches, just different dates. Why should I pull a branch that is this confused? It's not like I got those patches from somebody else, and there was just a mis-communication about who should apply them. They were both from *you*. That old commit came in in 4.7-rc4, so it's not even all that recent. Linus
Re: [PATCH v3] Coccinelle: Script to replace NULL test with IS_ERR test for devm_ioremap_resource
> +@err depends on context || org || report@ > +statement S; > +expression e; > +position j0; How do you think about to omit the number from this variable name? > +@@ > + > + e = devm_ioremap_resource(...); > +* if (!e@j0) S Are there any more functions to consider for such a source code search pattern? How do you think about to use a function name list here? > +// > I suggest to omit such comment lines from this SmPL script. Regards, Markus
[PATCH v2 13/14] net: ethernet: ti: cpsw: move napi struct to cpsw_common
The napi structs are common for both net devices in dual_emac
mode, In order to not hold duplicate links to them, move to
cpsw_common.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 50 +++---
1 file changed, 22 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 395531d..e0a1b80 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -367,6 +367,8 @@ static inline void slave_write(struct cpsw_slave *slave,
u32 val, u32 offset)
struct cpsw_common {
struct device *dev;
struct cpsw_platform_data data;
+ struct napi_struct napi_rx;
+ struct napi_struct napi_tx;
struct cpsw_ss_regs __iomem *regs;
struct cpsw_wr_regs __iomem *wr_regs;
u8 __iomem *hw_stats;
@@ -383,8 +385,6 @@ struct cpsw_common {
struct cpsw_priv {
struct net_device *ndev;
- struct napi_struct napi_rx;
- struct napi_struct napi_tx;
struct device *dev;
u32 msg_enable;
u32 version;
@@ -489,7 +489,7 @@ static const struct cpsw_stats cpsw_gstrings_stats[] = {
#define CPSW_STATS_LEN ARRAY_SIZE(cpsw_gstrings_stats)
#define ndev_to_cpsw(ndev) (((struct cpsw_priv *)netdev_priv(ndev))->cpsw)
-#define napi_to_priv(napi) container_of(napi, struct cpsw_priv, napi)
+#define napi_to_cpsw(napi) container_of(napi, struct cpsw_common, napi)
#define for_each_slave(priv, func, arg...) \
do {\
struct cpsw_slave *slave; \
@@ -755,8 +755,7 @@ requeue:
static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
{
- struct cpsw_priv *priv = dev_id;
- struct cpsw_common *cpsw = priv->cpsw;
+ struct cpsw_common *cpsw = dev_id;
writel(0, &cpsw->wr_regs->tx_en);
cpdma_ctlr_eoi(cpsw->dma, CPDMA_EOI_TX);
@@ -766,14 +765,13 @@ static irqreturn_t cpsw_tx_interrupt(int irq, void
*dev_id)
cpsw->tx_irq_disabled = true;
}
- napi_schedule(&priv->napi_tx);
+ napi_schedule(&cpsw->napi_tx);
return IRQ_HANDLED;
}
static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
{
- struct cpsw_priv *priv = dev_id;
- struct cpsw_common *cpsw = priv->cpsw;
+ struct cpsw_common *cpsw = dev_id;
cpdma_ctlr_eoi(cpsw->dma, CPDMA_EOI_RX);
writel(0, &cpsw->wr_regs->rx_en);
@@ -783,15 +781,14 @@ static irqreturn_t cpsw_rx_interrupt(int irq, void
*dev_id)
cpsw->rx_irq_disabled = true;
}
- napi_schedule(&priv->napi_rx);
+ napi_schedule(&cpsw->napi_rx);
return IRQ_HANDLED;
}
static int cpsw_tx_poll(struct napi_struct *napi_tx, int budget)
{
- struct cpsw_priv*priv = napi_to_priv(napi_tx);
+ struct cpsw_common *cpsw = napi_to_cpsw(napi_tx);
int num_tx;
- struct cpsw_common *cpsw = priv->cpsw;
num_tx = cpdma_chan_process(cpsw->txch, budget);
if (num_tx < budget) {
@@ -811,9 +808,8 @@ static int cpsw_tx_poll(struct napi_struct *napi_tx, int
budget)
static int cpsw_rx_poll(struct napi_struct *napi_rx, int budget)
{
- struct cpsw_priv*priv = napi_to_priv(napi_rx);
+ struct cpsw_common *cpsw = napi_to_cpsw(napi_rx);
int num_rx;
- struct cpsw_common *cpsw = priv->cpsw;
num_rx = cpdma_chan_process(cpsw->rxch, budget);
if (num_rx < budget) {
@@ -1292,7 +1288,6 @@ static int cpsw_ndo_open(struct net_device *ndev)
ALE_ALL_PORTS, ALE_ALL_PORTS, 0, 0);
if (!cpsw_common_res_usage_state(cpsw)) {
- struct cpsw_priv *priv_sl0 = cpsw_get_slave_priv(cpsw, 0);
int buf_num;
/* setup tx dma to fixed prio and zero offset */
@@ -1308,8 +1303,8 @@ static int cpsw_ndo_open(struct net_device *ndev)
/* Enable internal fifo flow control */
writel(0x7, &cpsw->regs->flow_control);
- napi_enable(&priv_sl0->napi_rx);
- napi_enable(&priv_sl0->napi_tx);
+ napi_enable(&cpsw->napi_rx);
+ napi_enable(&cpsw->napi_tx);
if (cpsw->tx_irq_disabled) {
cpsw->tx_irq_disabled = false;
@@ -1384,8 +1379,8 @@ static int cpsw_ndo_stop(struct net_device *ndev)
if (cpsw_common_res_usage_state(cpsw) <= 1) {
struct cpsw_priv *priv_sl0 = cpsw_get_slave_priv(cpsw, 0);
- napi_disable(&priv_sl0->napi_rx);
- napi_disable(&priv_sl0->napi_tx);
+ n
[PATCH v2 12/14] net: ethernet: ti: cpsw: fix int dbg message
While poll handlers there is no possibility to figure out
which network device is handling packets, as cpdma channels
are common for both network devices in dual_emac mode. Currently,
the messages are printed only for one device, in fact, there is two.
So, better to print integrated num_tx value for both devices if
any of them is allowed to.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 29ff489..395531d 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -378,6 +378,7 @@ struct cpsw_common {
boolrx_irq_disabled;
booltx_irq_disabled;
u32 irqs_table[IRQ_NUM];
+ int intr_dbg_msg;
};
struct cpsw_priv {
@@ -802,7 +803,9 @@ static int cpsw_tx_poll(struct napi_struct *napi_tx, int
budget)
}
}
- cpsw_dbg(priv, intr, "poll %d tx pkts\n", num_tx);
+ if (cpsw->intr_dbg_msg && net_ratelimit())
+ dev_dbg(cpsw->dev, "poll %d tx pkts\n", num_tx);
+
return num_tx;
}
@@ -822,7 +825,9 @@ static int cpsw_rx_poll(struct napi_struct *napi_rx, int
budget)
}
}
- cpsw_dbg(priv, intr, "poll %d rx pkts\n", num_rx);
+ if (cpsw->intr_dbg_msg && net_ratelimit())
+ dev_dbg(cpsw->dev, "poll %d tx pkts\n", num_rx);
+
return num_rx;
}
@@ -1848,8 +1853,35 @@ static u32 cpsw_get_msglevel(struct net_device *ndev)
static void cpsw_set_msglevel(struct net_device *ndev, u32 value)
{
+ int i;
+ struct cpsw_priv *sl_priv;
struct cpsw_priv *priv = netdev_priv(ndev);
+ struct cpsw_common *cpsw = priv->cpsw;
+
priv->msg_enable = value;
+
+ /* There is no possibility to at napi poll level
+* to know which netdev is handled, so enable
+* common dbg msg print if any interface is enabled to
+*/
+ cpsw->intr_dbg_msg = 0;
+ if (!cpsw->data.dual_emac) {
+ if (netif_msg_intr(priv))
+ cpsw->intr_dbg_msg = 1;
+ return;
+ }
+
+ for (i = 0; i < cpsw->data.slaves; i++) {
+ ndev = netdev_priv(cpsw->slaves[i].ndev);
+ if (!ndev)
+ continue;
+
+ sl_priv = netdev_priv(ndev);
+ if (netif_msg_intr(sl_priv)) {
+ cpsw->intr_dbg_msg = 1;
+ break;
+ }
+ }
}
static int cpsw_get_ts_info(struct net_device *ndev,
--
1.9.1
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons
On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter wrote:
> Hi John,
>
> On 30/07/16 05:39, John Stultz wrote:
>> Hey Jon,
>> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
>> noticed the power/volume buttons stopped working.
>>
>> I did a manual rebased bisection and chased it down to your commit
>> 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
>>
>> Reverting that patch makes things work again, so I wanted to see if
>> there was any debugging info I could provide to try to help narrow
>> down the problem here. (Sorry, I'd tinker myself with it some and try
>> to debug the issue, but after burning my friday night on this, I'm
>> eager to get away from the keyboard for the weekend).
>
> Before this commit bad IRQ type settings in device-tree were not getting
> reported and so failures to set the IRQ type were going unnoticed. It's
> most likely a bad IRQ type settings somewhere.
>
> As Thomas mentioned hopefully dmesg will shed a bit more light.
>
> Otherwise it can be worth looking at the ->irq_set_type() function for
> the irqchips in the path of the interrupt requested to see if any are
> failing. Looking at the nexus7 (assuming qcom variant), it looks like
> there are 3 irqchips in the path (pm8921 --> apq8064-pinctrl --> gic).
> The pm8xxx_irq_set_type() could return a failure when setting up the IRQ
> type and could be worth checking. It does not look like the set_type for
> the apq8064-pinctrl should ever fail (apart from calling BUG() which
> would be obvious). The gic can also return a failure for setting the
> type, but I did not see anything at first glance that looks incorrect in
> the dts.
>
> If we can narrow down irqchip, then hopefully it will be clearer.
The pm_8xxx_irq_set_type doesn't seem to be failing as far as I can see..
Looking at the patch that seems to cause the trouble, I narrowed it
down to just the following chunk:
@@ -614,7 +615,11 @@ unsigned int irq_create_fwspec_mapping(struct
irq_fwspec *fwspec)
* it now and return the interrupt number.
*/
if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
- irq_set_irq_type(virq, type);
+ irq_data = irq_get_irq_data(virq);
+ if (!irq_data)
+ return 0;
+
+ irqd_set_trigger_type(irq_data, type);
return virq;
}
If I revert just that, it works again.
I was worried we were hitting an early failure from !irq_data, but it
seems there's some subtle difference between irqd_set_trigger_type and
irq_set_type that makes the former break for me.
Still digging though.
thanks
-john
Re: [RFC][PATCH 7/7] cpufreq: intel_pstate: Change P-state selection algorithm for Core
On Wednesday, August 03, 2016 11:53:23 PM Doug Smythies wrote:
> On 2016.08.03 21:19 Doug Smythies wrote:
>
> Re-sending without the previously attached graph.
>
> Hi Rafael,
>
> Hope this feedback and test results help.
>
> On 2016.07.31 16:49 Rafael J. Wysocki wrote:
>
> > The PID-base P-state selection algorithm used by intel_pstate for
> > Core processors is based on very weak foundations.
>
> Agree, very very much.
>
> ...[cut]...
>
> > Consequently, the only viable way to fix that is to replace the
> > erroneous algorithm entirely with a better one.
>
> Agree, very very much.
>
> > To that end, notice that setting the P-state proportional to the
> > actual CPU utilization (measured with the help of MPERF and TSC)
> > generally leads to reasonable behavior, but it does not reflect
> > the "performance boosting" nature of the current P-state
> > selection algorithm. It may be made more similar to that
> > algorithm, though, by adding iowait boosting to it.
>
> Which is good and does help a lot for the IO case, but issues
> remain for the compute case.
>
> ...[cut]...
>
> > +static inline int32_t get_target_pstate_default(struct cpudata *cpu)
> > +{
> > + struct sample *sample = &cpu->sample;
> > + int32_t busy_frac;
> > + int pstate;
> > +
> > + busy_frac = div_fp(sample->mperf, sample->tsc);
> > + sample->busy_scaled = busy_frac * 100;
> > +
> > + if (busy_frac < cpu->iowait_boost)
> > + busy_frac = cpu->iowait_boost;
> > +
> > + cpu->iowait_boost >>= 1;
> > +
> > + pstate = cpu->pstate.turbo_pstate;
> > + return fp_toint((pstate + (pstate >> 2)) * busy_frac);
> > +}
> > +
>
> The response curve is not normalized on the lower end to the minimum
> pstate for the processor, meaning the overall response will vary
> between processors as a function of minimum pstate.
But that's OK IMO.
Mapping busy_frac = 0 to the minimum P-state would over-provision workloads
with small values of busy_frac.
> The clamping at maximum pstate at about 80% load seems at little high
> to me. Work I have done in various attempts to bring back the use of actual
> load
> has always ended up achieving maximum pstate before 80% load for best results.
> Even the get_target_pstate_cpu_load people reach the max pstate faster, and
> they
> are more about energy than performance.
> What was the criteria for the decision here? Are test results available for
> review
> and/or duplication by others?
This follows the coefficient used by the schedutil governor, but then the
metric is different, so quite possibly a different value may work better here.
We'll test other values before applying this for sure. :-)
>
> Several tests were done with this patch set.
> The patch set would not apply to kernel 4.7, but did apply fine to a 4.7+
> kernel
> (I did as of 7a66ecf) from a few days ago.
>
> Test 1: Phoronix ffmpeg test (less time is better):
> Reason: Because it suffers from rotating amongst CPUs in an odd way,
> challenging for CPU frequency scaling drivers.
> This test tends to be an indicator of potential troubles with some games.
> Criteria: (Dirk Brandewie): Must match or better acpi_cpufreq - ondemand.
> With patch set: 15.8 Seconds average and 24.51 package watts.
> Without patch set: 11.61 Seconds average and 27.59 watts.
> Conclusion: Significant reduction in performance with proposed patch set.
>
> Tests 2, 3, 4: Phoronix apache, kernel compile, and postmark tests.
> Conclusion: All were similar with and without the patch set, with perhaps a
> slight
> improvement in power consumption for the postmark test with the patch set.
>
> Test 5: Random reads within a largish (50 gigabytes) file.
> Reason: Because it was a test I used to use with other include or not include
> IOWAIT work.
> Conclusion: no difference with and without the patch set, likely due to
> domination by
> long seek times (the file is on a normal disk, not an SSD).
>
> Test 6: Sequential read of a largish (50 gigabytes) file.
> Reason: Because it was a test I used to use with other include or not include
> IOWAIT work.
> With patch set: 288.38 Seconds; 177.544 MB/Sec; 6.83 Watts.
> Without patch set: 292.38 Seconds; 174.99 MB/Sec; 7.08 Watts.
> Conclusion: Better performance and better power with the patch set.
>
> Test 7: Compile the kernel 9 times.
> Reason: Just because it was a very revealing test during the
> "intel_pstate: Increase hold-off time before busyness is scaled"
> discussion / thread(s).
> Conclusion: no difference with and without the patch set.
>
> Test 8: pipe-test between cores.
> Reason: Just because it was so useful during the
> "cross core scheduling frequency drop bisected to 0c313cb20732"
> discussion / thread(s).
> With patch set: 73.166 Sec; 3.6576 usec/loop; 2278.53 Joules.
> Without Patch set: 74.444 Sec; 3.7205 usec/loop; 2338.79 Joules.
> Conclusion: Slightly better performance and better energy with the patch set.
>
> Test 9: Dougs_specpower simulator (20% load):
> Time i
Re: [PATCH 3/3] locking/rwsem: Scan the wait_list for readers only once
* Davidlohr Bueso wrote: > When wanting to wakeup readers, __rwsem_mark_wakeup() currently > iterates the wait_list twice while looking to wakeup the first N > queued reader-tasks. While this can be quite inefficient, it was > there such that a awoken reader would be first and foremost > acknowledged by the lock counter. > > Keeping the same logic, we can further benefit from the use of > wake_qs and avoid entirely the first wait_list iteration that sets > the counter as wake_up_process() isn't going to occur right away, > and therefore we maintain the counter->list order of going about > things. > > Other than saving cycles with O(n) "scanning", this change also > nicely cleans up a good chunk of __rwsem_mark_wakeup(); both > visually and less tedious to read. > > For example, the following improvements where seen on some will > it scale microbenchmarks, on a 48-core Haswell: > > v4.7 v4.7-rwsem-v1 > Hmeansignal1-processes-85792691.42 ( 0.00%) 5771971.04 ( -0.36%) > Hmeansignal1-processes-12 6081199.96 ( 0.00%) 6072174.38 ( -0.15%) > Hmeansignal1-processes-21 3071137.71 ( 0.00%) 3041336.72 ( -0.97%) > Hmeansignal1-processes-48 3712039.98 ( 0.00%) 3708113.59 ( -0.11%) > Hmeansignal1-processes-79 4464573.45 ( 0.00%) 4682798.66 ( 4.89%) > Hmeansignal1-processes-110 4486842.01 ( 0.00%) 4633781.71 ( 3.27%) > Hmeansignal1-processes-141 4611816.83 ( 0.00%) 4692725.38 ( 1.75%) > Hmeansignal1-processes-172 4638157.05 ( 0.00%) 4714387.86 ( 1.64%) > Hmeansignal1-processes-203 4465077.80 ( 0.00%) 4690348.07 ( 5.05%) > Hmeansignal1-processes-224 4410433.74 ( 0.00%) 4687534.43 ( 6.28%) Please always make it clear in changelogs what the numbers mean, that higher numbers are better, etc. - so that people don't have to re-read it 2-3 times to figure out what it means. Also, what are 'will it scale microbenchmarks'? Thanks, Ingo
[PATCH v2 10/14] net; ethernet: ti: cpsw: move irq stuff under cpsw_common
The irq data are common per net device. So no need to hold these
data per net dev, move it under cpsw_common. Also delete irq_num
var, as after optimization it's not needed. Correct number of
irqs to 2, as anyway, driver is using only 2, at least for now.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 65 +++---
1 file changed, 29 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index d3af373..4080487 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -143,6 +143,7 @@ do {
\
#define cpsw_slave_index(priv) \
((priv->data.dual_emac) ? priv->emac_port : \
priv->data.active_slave)
+#define IRQ_NUM2
static int debug_level;
module_param(debug_level, int, 0);
@@ -371,6 +372,10 @@ struct cpsw_common {
struct cpsw_host_regs __iomem *host_port_regs;
struct cpdma_ctlr *dma;
struct cpdma_chan *txch, *rxch;
+ boolquirk_irq;
+ boolrx_irq_disabled;
+ booltx_irq_disabled;
+ u32 irqs_table[IRQ_NUM];
};
struct cpsw_priv {
@@ -389,12 +394,6 @@ struct cpsw_priv {
struct cpsw_ale *ale;
boolrx_pause;
booltx_pause;
- boolquirk_irq;
- boolrx_irq_disabled;
- booltx_irq_disabled;
- /* snapshot of IRQ numbers */
- u32 irqs_table[4];
- u32 num_irqs;
struct cpts *cpts;
u32 emac_port;
struct cpsw_common *cpsw;
@@ -758,9 +757,9 @@ static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
writel(0, &cpsw->wr_regs->tx_en);
cpdma_ctlr_eoi(cpsw->dma, CPDMA_EOI_TX);
- if (priv->quirk_irq) {
- disable_irq_nosync(priv->irqs_table[1]);
- priv->tx_irq_disabled = true;
+ if (cpsw->quirk_irq) {
+ disable_irq_nosync(cpsw->irqs_table[1]);
+ cpsw->tx_irq_disabled = true;
}
napi_schedule(&priv->napi_tx);
@@ -775,9 +774,9 @@ static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
cpdma_ctlr_eoi(cpsw->dma, CPDMA_EOI_RX);
writel(0, &cpsw->wr_regs->rx_en);
- if (priv->quirk_irq) {
- disable_irq_nosync(priv->irqs_table[0]);
- priv->rx_irq_disabled = true;
+ if (cpsw->quirk_irq) {
+ disable_irq_nosync(cpsw->irqs_table[0]);
+ cpsw->rx_irq_disabled = true;
}
napi_schedule(&priv->napi_rx);
@@ -794,9 +793,9 @@ static int cpsw_tx_poll(struct napi_struct *napi_tx, int
budget)
if (num_tx < budget) {
napi_complete(napi_tx);
writel(0xff, &cpsw->wr_regs->tx_en);
- if (priv->quirk_irq && priv->tx_irq_disabled) {
- priv->tx_irq_disabled = false;
- enable_irq(priv->irqs_table[1]);
+ if (cpsw->quirk_irq && cpsw->tx_irq_disabled) {
+ cpsw->tx_irq_disabled = false;
+ enable_irq(cpsw->irqs_table[1]);
}
}
@@ -814,9 +813,9 @@ static int cpsw_rx_poll(struct napi_struct *napi_rx, int
budget)
if (num_rx < budget) {
napi_complete(napi_rx);
writel(0xff, &cpsw->wr_regs->rx_en);
- if (priv->quirk_irq && priv->rx_irq_disabled) {
- priv->rx_irq_disabled = false;
- enable_irq(priv->irqs_table[0]);
+ if (cpsw->quirk_irq && cpsw->rx_irq_disabled) {
+ cpsw->rx_irq_disabled = false;
+ enable_irq(cpsw->irqs_table[0]);
}
}
@@ -1303,14 +1302,14 @@ static int cpsw_ndo_open(struct net_device *ndev)
napi_enable(&priv_sl0->napi_rx);
napi_enable(&priv_sl0->napi_tx);
- if (priv_sl0->tx_irq_disabled) {
- priv_sl0->tx_irq_disabled = false;
- enable_irq(priv->irqs_table[1]);
+ if (cpsw->tx_irq_disabled) {
+ cpsw->tx_irq_disabled = false;
+ enable_irq(cpsw->irqs_table[1]);
}
- if (priv_sl0->rx_irq_disabled) {
- priv_sl0->rx_irq_disabled = false;
- enable_irq(priv->irqs_table[0]);
+ if (cpsw->rx_irq_disabled) {
+ cpsw->rx_irq_disabled = false;
+ enable_irq(cpsw->irqs_table[0]);
}
buf_num = cpdma_chan_get_rx_buf_num(cpsw->dma
[PATCH v2 04/14] net: ethernet: ti: cpsw: remove clk var from priv
There is no need to hold link to clk, it's used only once
while probe.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 30e1ddb..70a9570 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -379,7 +379,6 @@ struct cpsw_priv {
u32 coal_intvl;
u32 bus_freq_mhz;
int rx_packet_max;
- struct clk *clk;
u8 mac_addr[ETH_ALEN];
struct cpsw_slave *slaves;
struct cpdma_ctlr *dma;
@@ -2179,8 +2178,6 @@ static int cpsw_probe_dual_emac(struct platform_device
*pdev,
memcpy(ndev->dev_addr, priv_sl2->mac_addr, ETH_ALEN);
priv_sl2->slaves = priv->slaves;
- priv_sl2->clk = priv->clk;
-
priv_sl2->coal_intvl = 0;
priv_sl2->bus_freq_mhz = priv->bus_freq_mhz;
@@ -2258,6 +2255,7 @@ MODULE_DEVICE_TABLE(of, cpsw_of_mtable);
static int cpsw_probe(struct platform_device *pdev)
{
+ struct clk *clk;
struct cpsw_platform_data *data;
struct net_device *ndev;
struct cpsw_priv*priv;
@@ -2336,14 +2334,14 @@ static int cpsw_probe(struct platform_device *pdev)
priv->slaves[0].ndev = ndev;
priv->emac_port = 0;
- priv->clk = devm_clk_get(&pdev->dev, "fck");
- if (IS_ERR(priv->clk)) {
+ clk = devm_clk_get(&pdev->dev, "fck");
+ if (IS_ERR(clk)) {
dev_err(priv->dev, "fck is not found\n");
ret = -ENODEV;
goto clean_runtime_disable_ret;
}
priv->coal_intvl = 0;
- priv->bus_freq_mhz = clk_get_rate(priv->clk) / 100;
+ priv->bus_freq_mhz = clk_get_rate(clk) / 100;
ss_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ss_regs = devm_ioremap_resource(&pdev->dev, ss_res);
--
1.9.1
[PATCH] proc: faster /proc/*/status
top(1) opens the following files for every PID:
/proc/*/stat
/proc/*/statm
/proc/*/status
This patch switches /proc/*/status away from seq_printf().
The result is 13.5% speedup.
Benchmark is open("/proc/self/status")+read+close 1.000.000 million times.
BEFORE
$ perf stat -r 10 taskset -c 3 ./proc-self-status
Performance counter stats for 'taskset -c 3 ./proc-self-status' (10 runs):
10748.474301 task-clock (msec) #0.954 CPUs utilized
( +- 0.91% )
12 context-switches #0.001 K/sec
( +- 1.09% )
1 cpu-migrations#0.000 K/sec
104 page-faults #0.010 K/sec
( +- 0.45% )
37,424,127,876 cycles#3.482 GHz
( +- 0.04% )
8,453,010,029 stalled-cycles-frontend # 22.59% frontend cycles
idle ( +- 0.12% )
3,747,609,427 stalled-cycles-backend# 10.01% backend cycles idle
( +- 0.68% )
65,632,764,147 instructions #1.75 insn per cycle
#0.13 stalled cycles per
insn ( +- 0.00% )
13,981,324,775 branches # 1300.773 M/sec
( +- 0.00% )
138,967,110 branch-misses #0.99% of all branches
( +- 0.18% )
11.263885428 seconds time elapsed
( +- 0.04% )
AFTER
$ perf stat -r 10 taskset -c 3 ./proc-self-status
Performance counter stats for 'taskset -c 3 ./proc-self-status' (10 runs):
9010.521776 task-clock (msec) #0.925 CPUs utilized
( +- 1.54% )
11 context-switches #0.001 K/sec
( +- 1.54% )
1 cpu-migrations#0.000 K/sec
( +- 11.11% )
103 page-faults #0.011 K/sec
( +- 0.60% )
32,352,310,603 cycles#3.591 GHz
( +- 0.07% )
7,849,199,578 stalled-cycles-frontend # 24.26% frontend cycles
idle ( +- 0.27% )
3,269,738,842 stalled-cycles-backend# 10.11% backend cycles idle
( +- 0.73% )
56,012,163,567 instructions #1.73 insn per cycle
#0.14 stalled cycles per
insn ( +- 0.00% )
11,735,778,795 branches # 1302.453 M/sec
( +- 0.00% )
98,084,459 branch-misses #0.84% of all branches
( +- 0.28% )
9.741247736 seconds time elapsed
( +- 0.07% )
^^^
Signed-off-by: Alexey Dobriyan
---
fs/proc/array.c | 87 ++--
1 file changed, 47 insertions(+), 40 deletions(-)
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -186,51 +186,52 @@ static inline void task_state(struct seq_file *m, struct
pid_namespace *ns,
task_unlock(p);
rcu_read_unlock();
- seq_printf(m,
- "State:\t%s\n"
- "Tgid:\t%d\n"
- "Ngid:\t%d\n"
- "Pid:\t%d\n"
- "PPid:\t%d\n"
- "TracerPid:\t%d\n"
- "Uid:\t%d\t%d\t%d\t%d\n"
- "Gid:\t%d\t%d\t%d\t%d\n"
- "FDSize:\t%d\nGroups:\t",
- get_task_state(p),
- tgid, ngid, pid_nr_ns(pid, ns), ppid, tpid,
- from_kuid_munged(user_ns, cred->uid),
- from_kuid_munged(user_ns, cred->euid),
- from_kuid_munged(user_ns, cred->suid),
- from_kuid_munged(user_ns, cred->fsuid),
- from_kgid_munged(user_ns, cred->gid),
- from_kgid_munged(user_ns, cred->egid),
- from_kgid_munged(user_ns, cred->sgid),
- from_kgid_munged(user_ns, cred->fsgid),
- max_fds);
-
+ seq_printf(m, "State:\t%s", get_task_state(p));
+
+ seq_puts(m, "\nTgid:\t");
+ seq_put_decimal_ull(m, 0, tgid);
+ seq_puts(m, "\nNgid:\t");
+ seq_put_decimal_ull(m, 0, ngid);
+ seq_puts(m, "\nPid:\t");
+ seq_put_decimal_ull(m, 0, pid_nr_ns(pid, ns));
+ seq_puts(m, "\nPPid:\t");
+ seq_put_decimal_ull(m, 0, ppid);
+ seq_puts(m, "\nTracerPid:\t");
+ seq_put_decimal_ull(m, 0, tpid);
+ seq_puts(m, "\nUid:");
+ seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->uid));
+ seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->euid));
+ seq_put_decimal_ull(m, '\t', from_kuid_munged(user_ns, cred->suid));
+ seq_put_decimal_ull(m, '\t', from
[PATCH v2 03/14] net: ethernet: ti: cpsw: remove priv from cpsw_get_slave_port() parameters list
There is no need in priv here.
Signed-off-by: Ivan Khoronzhuk
---
drivers/net/ethernet/ti/cpsw.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 85ee9f5..30e1ddb 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -525,7 +525,7 @@ static const struct cpsw_stats cpsw_gstrings_stats[] = {
if (priv->data.dual_emac) { \
struct cpsw_slave *slave = priv->slaves + \
priv->emac_port;\
- int slave_port = cpsw_get_slave_port(priv, \
+ int slave_port = cpsw_get_slave_port( \
slave->slave_num); \
cpsw_ale_add_mcast(priv->ale, addr, \
1 << slave_port | ALE_PORT_HOST,\
@@ -537,7 +537,7 @@ static const struct cpsw_stats cpsw_gstrings_stats[] = {
} \
} while (0)
-static inline int cpsw_get_slave_port(struct cpsw_priv *priv, u32 slave_num)
+static inline int cpsw_get_slave_port(u32 slave_num)
{
return slave_num + 1;
}
@@ -849,7 +849,7 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
if (!phy)
return;
- slave_port = cpsw_get_slave_port(priv, slave->slave_num);
+ slave_port = cpsw_get_slave_port(slave->slave_num);
if (phy->link) {
mac_control = priv->data.mac_control;
@@ -1120,7 +1120,7 @@ static void cpsw_slave_open(struct cpsw_slave *slave,
struct cpsw_priv *priv)
slave->mac_control = 0; /* no link yet */
- slave_port = cpsw_get_slave_port(priv, slave->slave_num);
+ slave_port = cpsw_get_slave_port(slave->slave_num);
if (priv->data.dual_emac)
cpsw_add_dual_emac_def_ale_entries(priv, slave, slave_port);
@@ -1222,7 +1222,7 @@ static void cpsw_slave_stop(struct cpsw_slave *slave,
struct cpsw_priv *priv)
{
u32 slave_port;
- slave_port = cpsw_get_slave_port(priv, slave->slave_num);
+ slave_port = cpsw_get_slave_port(slave->slave_num);
if (!slave->phy)
return;
--
1.9.1
