Re: [PATCH v15 5/6] x86/boot: Parse SRAT address from RSDP and store immovable memory
On Wed, Jan 16, 2019 at 03:28:52PM +0800, Kairui Song wrote:
>On Mon, Jan 7, 2019 at 11:24 AM Chao Fan wrote:
>>
>> +
>> +/* Determine RSDP, based on acpi_os_get_root_pointer(). */
>> +static acpi_physical_address get_rsdp_addr(void)
>> +{
>> + acpi_physical_address pa;
>> +
>> + pa = get_acpi_rsdp();
>> +
>> + if (!pa)
>> + pa = efi_get_rsdp_addr();
>> +
>> + if (!pa)
>> + pa = bios_get_rsdp_addr();
>> +
>> + return pa;
>> +}
>
>acpi_rsdp might be provided by boot_params.acpi_rsdp_addr too,
>it's introduced in ae7e1238e68f2a for Xen PVH guest and later move to
>boot_params in e6e094e053af,
>kexec could use it to pass RSDP to second kernel as well. Please check
>it as well make sure it always works.
>
Hi Kairui,
I saw the parsing code has been added to kernel, but I didn't see
where to fill in the 'acpi_rsdp_addr'. If only you(KEXEC) use it,
I can add "#ifdef CONFIG_KEXEC", but you said Xen will use it also,
so I didn't add ifdef to control it. I was trying to do as below:
static inline acpi_physical_address get_boot_params_rsdp(void)
{
return boot_params->acpi_rsdp_addr;
}
static acpi_physical_address get_rsdp_addr(void)
{
bool boot_params_rsdp_exist;
acpi_physical_address pa;
pa = get_acpi_rsdp();
if (!pa)
pa = get_boot_params_rsdp();
if (!pa) {
pa = efi_get_rsdp_addr();
boot_params_rsdp_exist = false;
}
else
boot_params_rsdp_exist = true;
if (!pa)
pa = bios_get_rsdp_addr();
if (pa && !boot_params_rsdp_exist)
boot_params.acpi_rsdp_addr = pa;
return pa;
}
At the same time, I notice kernel only parses it when
"#ifdef CONFIG_ACPI", we should keep sync with kernel, but I think
we are parsing SRAT, CONFIG_ACPI is needed sure, so I am going to
update the define of EARLY_SRAT_PARSE:
config EARLY_SRAT_PARSE
bool "EARLY SRAT parsing"
def_bool y
depends on RANDOMIZE_BASE && MEMORY_HOTREMOVE && ACPI
Boris, how do you think the update for the new acpi_rsdp_addr?
If I misunderstand something, please let me know.
Thanks,
Chao Fan
>> +
>> +/* Compute SRAT address from RSDP. */
>> +static struct acpi_table_header *get_acpi_srat_table(void)
>> +{
>> + acpi_physical_address acpi_table;
>> + acpi_physical_address root_table;
>> + struct acpi_table_header *header;
>> + struct acpi_table_rsdp *rsdp;
>> + u32 num_entries;
>> + char arg[10];
>> + u8 *entry;
>> + u32 size;
>> + u32 len;
>> +
>> + rsdp = (struct acpi_table_rsdp *)(long)get_rsdp_addr();
>> + if (!rsdp)
>> + return NULL;
>> +
>> + /* Get RSDT or XSDT from RSDP. */
>> + if (!(cmdline_find_option("acpi", arg, sizeof(arg)) == 4 &&
>> + !strncmp(arg, "rsdt", 4)) &&
>> + rsdp->xsdt_physical_address &&
>> + rsdp->revision > 1) {
>> + root_table = rsdp->xsdt_physical_address;
>> + size = ACPI_XSDT_ENTRY_SIZE;
>> + } else {
>> + root_table = rsdp->rsdt_physical_address;
>> + size = ACPI_RSDT_ENTRY_SIZE;
>> + }
>> +
>> + /* Get ACPI root table from RSDT or XSDT.*/
>> + if (!root_table)
>> + return NULL;
>> + header = (struct acpi_table_header *)(long)root_table;
>> +
>> + len = header->length;
>> + if (len < sizeof(struct acpi_table_header) + size)
>> + return NULL;
>> +
>> + num_entries = (u32)((len - sizeof(struct acpi_table_header)) / size);
>> + entry = ACPI_ADD_PTR(u8, header, sizeof(struct acpi_table_header));
>> +
>> + while (num_entries--) {
>> + u64 address64;
>> +
>> + if (size == ACPI_RSDT_ENTRY_SIZE)
>> + acpi_table = *ACPI_CAST_PTR(u32, entry);
>> + else {
>> + address64 = *(u64 *)entry;
>> + acpi_table = address64;
>> + }
>> +
>> + if (acpi_table) {
>> + header = (struct acpi_table_header
>> *)(long)acpi_table;
>> +
>> + if (ACPI_COMPARE_NAME(header->signature,
>> ACPI_SIG_SRAT))
>> + return header;
>> + }
>> + entry += size;
>> + }
>> + return NULL;
>> +}
>> +
>> +/*
>> + * According to ACPI table, filter the immovable memory regions
>> + * and store them in immovable_mem[].
>> + */
>> +void get_immovable_mem(void)
>> +{
>> + struct acpi_table_header *table_header;
>> + struct acpi_subtable_header *table;
>> + struct acpi_srat_mem_affinity *ma;
>> + char arg[MAX_ACPI_ARG_LENGTH];
>> + unsigned long table_end;
>> + int i = 0;
>> +
>> + if (cmdline_find_option("acpi", arg, sizeof(arg)) == 3 &&
>> + !strncmp(arg, "off", 3))
Re: [PATCH v7 5/5] tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend()
On 12/20/2018 4:21 PM, Jarkko Sakkinen wrote:
On Thu, Dec 13, 2018 at 11:29:45AM +0100, Roberto Sassu wrote:
Currently, tpm_pcr_extend() accepts as an input only a SHA1 digest.
This patch modifies the definition of tpm_pcr_extend() to allow other
kernel subsystems to pass a digest for each algorithm supported by the TPM.
All digests are processed by the TPM in one operation.
If a tpm_pcr_extend() caller provides a subset of the supported algorithms,
the TPM driver extends the remaining PCR banks with the first digest
passed as an argument to the function.
The new tpm_extend digest structure has been preferred to the tpm_digest
structure, to let the caller specify the size of the digest (which may be
unknown to the TPM driver).
Due to the API change, ima_pcr_extend() and pcrlock() have been modified.
Signed-off-by: Roberto Sassu
---
drivers/char/tpm/tpm-interface.c | 24 +---
drivers/char/tpm/tpm.h | 5 +++--
drivers/char/tpm/tpm1-cmd.c| 13 ---
drivers/char/tpm/tpm2-cmd.c| 35 +-
include/linux/tpm.h| 13 ---
security/integrity/ima/ima_queue.c | 5 -
security/keys/trusted.c| 5 -
7 files changed, 62 insertions(+), 38 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index eb7c79ca8a94..911fea19e408 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -478,42 +478,30 @@ EXPORT_SYMBOL_GPL(tpm_pcr_read);
* tpm_pcr_extend - extend a PCR value in SHA1 bank.
* @chip: a tpm_chip instance, %NULL for the default chip
* @pcr_idx: the PCR to be retrieved
- * @hash: the hash value used to extend the PCR value
+ * @count: number of tpm_extend_digest structures
+ * @digests: array of tpm_extend_digest structures used to extend PCRs
*
* Note: with TPM 2.0 extends also those banks for which no digest was
* specified in order to prevent malicious use of those PCR banks.
*
* Return: same as with tpm_transmit_cmd()
*/
-int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8 *hash)
+int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, u32 count,
+ const struct tpm_extend_digest *digests)
Remove const. Document how @digests is used like the special meaning
of the first index. I faintly remember asking this last time.
{
int rc;
- struct tpm_digest *digest_list;
- int i;
chip = tpm_find_get_ops(chip);
if (!chip)
return -ENODEV;
if (chip->flags & TPM_CHIP_FLAG_TPM2) {
- digest_list = kcalloc(chip->nr_allocated_banks,
- sizeof(*digest_list), GFP_KERNEL);
- if (!digest_list)
- return -ENOMEM;
-
- for (i = 0; i < chip->nr_allocated_banks; i++) {
- digest_list[i].alg_id = chip->allocated_banks[i].alg_id;
- memcpy(digest_list[i].digest, hash, TPM_DIGEST_SIZE);
- }
-
- rc = tpm2_pcr_extend(chip, pcr_idx, chip->nr_allocated_banks,
-digest_list);
- kfree(digest_list);
+ rc = tpm2_pcr_extend(chip, pcr_idx, count, digests);
tpm_put_ops(chip);
return rc;
}
- rc = tpm1_pcr_extend(chip, pcr_idx, hash,
+ rc = tpm1_pcr_extend(chip, pcr_idx, count, digests,
"attempting extend a PCR value");
The validation is missing that the provided array has only one element
and the algorithm is SHA1. Could be done also inside tpm1_pcr_extend()
but what you are doing to that function does not make any sense so
better to do it here.
tpm_put_ops(chip);
return rc;
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 64d93d26087f..6b446504d2fe 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -504,7 +504,8 @@ int tpm1_auto_startup(struct tpm_chip *chip);
int tpm1_do_selftest(struct tpm_chip *chip);
int tpm1_get_timeouts(struct tpm_chip *chip);
unsigned long tpm1_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
-int tpm1_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8 *hash,
+int tpm1_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, u32 count,
+ const struct tpm_extend_digest *digests,
const char *log_msg);
int tpm1_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf);
ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
@@ -551,7 +552,7 @@ int tpm2_get_timeouts(struct tpm_chip *chip);
int tpm2_pcr_read(struct tpm_chip *chip, u32 pcr_idx,
struct tpm_digest *digest, u16 *digest_size_ptr);
int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, u32 count,
- struct tpm_digest *digests);
+ const struct
Re: [Intel-wired-lan] [PATCH] e1000e: fix cyclic resets at link up with active tx
On 1/14/2019 15:29, Konstantin Khlebnikov wrote:
I'm seeing series of e1000e resets (sometimes endless) at system boot
if something generates tx traffic at this time. In my case this is
netconsole who sends message "e1000e :02:00.0: Some CPU C-states
have been disabled in order to enable jumbo frames" from e1000e itself.
As result e1000_watchdog_task sees used tx buffer while carrier is off
and start this reset cycle again.
[ 17.794359] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control:
None
[ 17.794714] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 22.936455] e1000e :02:00.0 eth1: changing MTU from 1500 to 9000
[ 23.06] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 26.102364] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control:
None
[ 27.174495] 8021q: 802.1Q VLAN Support v1.8
[ 27.174513] 8021q: adding VLAN 0 to HW filter on device eth1
[ 30.671724] cgroup: cgroup: disabling cgroup2 socket matching due to
net_prio or net_cls activation
[ 30.898564] netpoll: netconsole: local port
[ 30.898566] netpoll: netconsole: local IPv6 address
2a02:6b8:0:80b:beae:c5ff:fe28:23f8
[ 30.898567] netpoll: netconsole: interface 'eth1'
[ 30.898568] netpoll: netconsole: remote port
[ 30.898568] netpoll: netconsole: remote IPv6 address
2a02:6b8:b000:605c:e61d:2dff:fe03:3790
[ 30.898569] netpoll: netconsole: remote ethernet address b0:a8:6e:f4:ff:c0
[ 30.917747] console [netcon0] enabled
[ 30.917749] netconsole: network logging started
[ 31.453353] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 34.185730] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 34.321840] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 34.465822] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 34.597423] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 34.745417] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 34.877356] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 35.005441] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 35.157376] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 35.289362] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 35.417441] e1000e :02:00.0: Some CPU C-states have been disabled in
order to enable jumbo frames
[ 37.790342] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control:
None
This patch flushes tx buffers only once when carrier is off
rather than at each watchdog iteration.
Signed-off-by: Konstantin Khlebnikov
---
drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 189f231075c2..d10083beec83 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5309,8 +5309,13 @@ static void e1000_watchdog_task(struct work_struct *work)
/* 8000ES2LAN requires a Rx packet buffer work-around
* on link down event; reset the controller to flush
* the Rx packet buffer.
+*
+* If the link is lost the controller stops DMA, but
+* if there is queued Tx work it cannot be done. So
+* reset the controller to flush the Tx packet buffers.
*/
- if (adapter->flags & FLAG_RX_NEEDS_RESTART)
+ if ((adapter->flags & FLAG_RX_NEEDS_RESTART) ||
+ e1000_desc_unused(tx_ring) + 1 < tx_ring->count)
adapter->flags |= FLAG_RESTART_NOW;
else
pm_schedule_suspend(netdev->dev.parent,
@@ -5333,14 +5338,6 @@ static void e1000_watchdog_task(struct work_struct *work)
adapter->gotc_old = adapter->stats.gotc;
spin_unlock(>stats64_lock);
- /* If the link is lost the controller stops DMA, but
-* if there is queued Tx work it cannot be done. So
-* reset the controller to flush the Tx packet buffers.
-*/
- if (!netif_carrier_ok(netdev) &&
- (e1000_desc_unused(tx_ring) + 1 < tx_ring->count))
- adapter->flags |= FLAG_RESTART_NOW;
-
/* If reset is necessary, do it outside of interrupt context. */
if (adapter->flags & FLAG_RESTART_NOW) {
schedule_work(>reset_task);
Re: [PATCH v2] tracing/uprobes: Fix output for multiple string arguments
On Thu, 17 Jan 2019 08:40:05 +0100
Andreas Ziegler wrote:
> On 17.01.19 07:01, Masami Hiramatsu wrote:
> > On Wed, 16 Jan 2019 15:16:29 +0100
> > Andreas Ziegler wrote:
> >
> >> When printing multiple uprobe arguments as strings the output for the
> >> earlier arguments would also include all later string arguments.
> >>
> >> This is best explained in an example:
> >>
> >> Consider adding a uprobe to a function receiving two strings as
> >> parameters which is at offset 0xa0 in strlib.so and we want to print
> >> both parameters when the uprobe is hit (on x86_64):
> >>
> >> $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
> >> /sys/kernel/debug/tracing/uprobe_events
> >>
> >> When the function is called as func("foo", "bar") and we hit the probe,
> >> the trace file shows a line like the following:
> >>
> >> [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
> >>
> >> Note the extra "bar" printed as part of arg1. This behaviour stacks up
> >> for additional string arguments.
> >>
> >> The strings are stored in a dynamically growing part of the uprobe
> >> buffer by fetch_store_string() after copying them from userspace via
> >> strncpy_from_user(). The return value of strncpy_from_user() is then
> >> directly used as the required size for the string. However, this does
> >> not take the terminating null byte into account as the documentation
> >> for strncpy_from_user() cleary states that it "[...] returns the
> >> length of the string (not including the trailing NUL)" even though the
> >> null byte will be copied to the destination.
> >>
> >> Therefore, subsequent calls to fetch_store_string() will overwrite
> >> the terminating null byte of the most recently fetched string with
> >> the first character of the current string, leading to the
> >> "accumulation" of strings in earlier arguments in the output.
> >>
> >> Fix this by incrementing the return value of strncpy_from_user() by
> >> one if we did not hit the maximum buffer size.
> >>
> >
> > Yeah, I had eventually same conclusion. However, you also have to increse
> > the return value of fetch_store_strlen() too. (And I found another issue)
> >
>
> I don't think we need to increase that since the documentation for
> strnlen_user() says that it "[r]eturns the size of the string
> INCLUDING the terminating NUL." so its return value will already be
> one more than that of strncpy_from_user().
Ah, I got it.
Hmm, in that case, I have to update my patch in the previous mail.
Anyway,
Acked-by: Masami Hiramatsu
Thank you!!
>
> Thanks,
>
> Andreas
>
> > Could you fix fetch_store_strlen in the same patch?
> >
> > Thank you,
> >
> >> Signed-off-by: Andreas Ziegler
> >> ---
> >> v2: removed a wrong check for (ret > 0)
> >>
> >> kernel/trace/trace_uprobe.c | 7 +++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> >> index e335576b9411..3a1d5ab6b4ba 100644
> >> --- a/kernel/trace/trace_uprobe.c
> >> +++ b/kernel/trace/trace_uprobe.c
> >> @@ -160,6 +160,13 @@ fetch_store_string(unsigned long addr, void *dest,
> >> void *base)
> >>if (ret >= 0) {
> >>if (ret == maxlen)
> >>dst[ret - 1] = '\0';
> >> + else
> >> + /*
> >> + * Include the terminating null byte. In this case it
> >> + * was copied by strncpy_from_user but not accounted
> >> + * for in ret.
> >> + */
> >> + ret++;
> >>*(u32 *)dest = make_data_loc(ret, (void *)dst - base);
> >>}
> >>
> >> --
> >> 2.17.1
> >>
> >
> >
>
--
Masami Hiramatsu
Re: [PATCH 17/17] module: Prevent module removal racing with text_poke()
On Wed, 16 Jan 2019 16:32:59 -0800 Rick Edgecombe wrote: > From: Nadav Amit > > It seems dangerous to allow code modifications to take place > concurrently with module unloading. So take the text_mutex while the > memory of the module is freed. At that point, since the module itself is removed from module list, it seems no actual harm. Or would you have any concern? Thank you, > > Signed-off-by: Nadav Amit > Signed-off-by: Rick Edgecombe > --- > kernel/module.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/kernel/module.c b/kernel/module.c > index 1af5c8e19086..90cfc4988d98 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -64,6 +64,7 @@ > #include > #include > #include > +#include > #include > #include "module-internal.h" > > @@ -2157,6 +2158,9 @@ static void free_module(struct module *mod) > synchronize_rcu(); > mutex_unlock(_mutex); > > + /* Protect against patching of the module while it is being removed */ > + mutex_lock(_mutex); > + > /* This may be empty, but that's OK */ > module_arch_freeing_init(mod); > module_memfree(mod->init_layout.base); > @@ -2168,6 +2172,7 @@ static void free_module(struct module *mod) > > /* Finally, free the core (containing the module structure) */ > module_memfree(mod->core_layout.base); > + mutex_unlock(_mutex); > } > > void *__symbol_get(const char *symbol) > -- > 2.17.1 > -- Masami Hiramatsu
RE: [PATCH] scsi: ufs: revamp string descriptor reading
> > Hello Tomas, > > > > > > > > Define new a type: uc_string_id for easier string handling and less > > > casting. Reduce number or string copies in price of a dynamic > > > allocation. > > > > > > Signed-off-by: Tomas Winkler > > Tested-by: Avri Altman > > > > Just one nit - doesn't really matters. > > > > Cheers, > > Avri > > > > > --- > > > drivers/scsi/ufs/ufs-sysfs.c | 20 ++--- > > > drivers/scsi/ufs/ufs.h | 2 +- > > > drivers/scsi/ufs/ufshcd.c| 164 +-- > > > drivers/scsi/ufs/ufshcd.h| 9 +- > > > 4 files changed, 115 insertions(+), 80 deletions(-) > > > > > > > > > > ufs_fixup_device_setup(hba, ); > > > + ufs_put_device_desc(); > > ufs_get_device_desc() and ufs_put_device_desc() actually serves the > > quirks setup. > > Make sense to call it from within so the logic is clear and in one place. > > Might also save ufs_put_device_desc(). > > You are right from the current perspective , just I'd need it also for the > RPMB > patches that should follow, then it will have bit larger span than the quirks. > Is this okay, can we merge? Thanks Tomas
Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
On Thu, Jan 17, 2019 at 03:41:13PM +0800, Kairui Song wrote:
>On Wed, Jan 16, 2019 at 5:46 PM Borislav Petkov wrote:
>>
>> On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
>> > I didn't see a way to reuse things in that patch series, situation is
>> > different, in that patch it needs to get RSDP in very early boot stage
>> > so it did everything from scratch, in this patch kexec_file_load need
>> > to get RSDP too, but everything is well setup so things are a lot
>> > easier, just read from current boot_prams, efi and fallback to
>> > acpi_find_root_pointer should be good.
>>
>> No no. Early code should find out that venerable RSDP thing once and
>> will save it somewhere for further use. No gazillion parsings of it.
>> Just once and share it with the rest of the code that needs it.
>>
>
>How about we refill the boot_params.acpi_rsdp_addr if it is not valid
>in early code, so it could be used as a reliable RSDP address source?
>That should make things easier.
I think it's OK.
Try to read it, if get RSDP, use it.
If not, search in EFI/BIOS/... and refill the RSDP to
boot_params.acpi_rsdp_addr.
By the way, I search kernel code, I didn't find other code fill and
use it, only you(KEXEC) are trying to fill it.
If I miss something, please let me know.
Thanks,
Chao Fan
>
>But if early code should parse it and store it should be done in
>Chao's patch, or I can post another patch to do it if Chao's patch is
>merged.
>
>For now I think good to have something like this in this patch series
>to always keep storing acpi_rsdp in late code,
>acpi_os_get_root_pointer_late (maybe comeup with a better name later)
>could be used anytime to get RSDP and no extra parsing:
>
>--- a/drivers/acpi/osl.c
>+++ b/drivers/acpi/osl.c
>@@ -180,8 +180,8 @@ void acpi_os_vprintf(const char *fmt, va_list args)
> #endif
> }
>
>-#ifdef CONFIG_KEXEC
> static unsigned long acpi_rsdp;
>+#ifdef CONFIG_KEXEC
> static int __init setup_acpi_rsdp(char *arg)
> {
>return kstrtoul(arg, 16, _rsdp);
>@@ -189,28 +189,38 @@ static int __init setup_acpi_rsdp(char *arg)
> early_param("acpi_rsdp", setup_acpi_rsdp);
> #endif
>
>+acpi_physical_address acpi_os_get_root_pointer_late(void) {
>+ return acpi_rsdp;
>+}
>+
> acpi_physical_address __init acpi_os_get_root_pointer(void)
> {
>acpi_physical_address pa;
>
>-#ifdef CONFIG_KEXEC
>if (acpi_rsdp)
>return acpi_rsdp;
>-#endif
>+
>pa = acpi_arch_get_root_pointer();
>- if (pa)
>+ if (pa) {
>+ acpi_rsdp = pa;
>return pa;
>+ }
>
>if (efi_enabled(EFI_CONFIG_TABLES)) {
>- if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>+ if (efi.acpi20 != EFI_INVALID_TABLE_ADDR) {
>+ acpi_rsdp = efi.acpi20;
>return efi.acpi20;
>- if (efi.acpi != EFI_INVALID_TABLE_ADDR)
>+ }
>+ if (efi.acpi != EFI_INVALID_TABLE_ADDR) {
>+ acpi_rsdp = efi.acpi;
>return efi.acpi;
>+ }
>pr_err(PREFIX "System description tables not found\n");
>} else if (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
>acpi_find_root_pointer();
>}
>
> + acpi_rsdp = pa;
>return pa;
> }
>
>> --
>> Regards/Gruss,
>> Boris.
>>
>> Good mailing practices for 400: avoid top-posting and trim the reply.
>--
>Best Regards,
>Kairui Song
>
>
Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
On Wed, Jan 16, 2019 at 5:46 PM Borislav Petkov wrote:
>
> On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
> > I didn't see a way to reuse things in that patch series, situation is
> > different, in that patch it needs to get RSDP in very early boot stage
> > so it did everything from scratch, in this patch kexec_file_load need
> > to get RSDP too, but everything is well setup so things are a lot
> > easier, just read from current boot_prams, efi and fallback to
> > acpi_find_root_pointer should be good.
>
> No no. Early code should find out that venerable RSDP thing once and
> will save it somewhere for further use. No gazillion parsings of it.
> Just once and share it with the rest of the code that needs it.
>
How about we refill the boot_params.acpi_rsdp_addr if it is not valid
in early code, so it could be used as a reliable RSDP address source?
That should make things easier.
But if early code should parse it and store it should be done in
Chao's patch, or I can post another patch to do it if Chao's patch is
merged.
For now I think good to have something like this in this patch series
to always keep storing acpi_rsdp in late code,
acpi_os_get_root_pointer_late (maybe comeup with a better name later)
could be used anytime to get RSDP and no extra parsing:
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -180,8 +180,8 @@ void acpi_os_vprintf(const char *fmt, va_list args)
#endif
}
-#ifdef CONFIG_KEXEC
static unsigned long acpi_rsdp;
+#ifdef CONFIG_KEXEC
static int __init setup_acpi_rsdp(char *arg)
{
return kstrtoul(arg, 16, _rsdp);
@@ -189,28 +189,38 @@ static int __init setup_acpi_rsdp(char *arg)
early_param("acpi_rsdp", setup_acpi_rsdp);
#endif
+acpi_physical_address acpi_os_get_root_pointer_late(void) {
+ return acpi_rsdp;
+}
+
acpi_physical_address __init acpi_os_get_root_pointer(void)
{
acpi_physical_address pa;
-#ifdef CONFIG_KEXEC
if (acpi_rsdp)
return acpi_rsdp;
-#endif
+
pa = acpi_arch_get_root_pointer();
- if (pa)
+ if (pa) {
+ acpi_rsdp = pa;
return pa;
+ }
if (efi_enabled(EFI_CONFIG_TABLES)) {
- if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
+ if (efi.acpi20 != EFI_INVALID_TABLE_ADDR) {
+ acpi_rsdp = efi.acpi20;
return efi.acpi20;
- if (efi.acpi != EFI_INVALID_TABLE_ADDR)
+ }
+ if (efi.acpi != EFI_INVALID_TABLE_ADDR) {
+ acpi_rsdp = efi.acpi;
return efi.acpi;
+ }
pr_err(PREFIX "System description tables not found\n");
} else if (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
acpi_find_root_pointer();
}
+ acpi_rsdp = pa;
return pa;
}
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
--
Best Regards,
Kairui Song
Re: [PATCH v2] tracing/uprobes: Fix output for multiple string arguments
On 17.01.19 07:01, Masami Hiramatsu wrote:
> On Wed, 16 Jan 2019 15:16:29 +0100
> Andreas Ziegler wrote:
>
>> When printing multiple uprobe arguments as strings the output for the
>> earlier arguments would also include all later string arguments.
>>
>> This is best explained in an example:
>>
>> Consider adding a uprobe to a function receiving two strings as
>> parameters which is at offset 0xa0 in strlib.so and we want to print
>> both parameters when the uprobe is hit (on x86_64):
>>
>> $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
>> /sys/kernel/debug/tracing/uprobe_events
>>
>> When the function is called as func("foo", "bar") and we hit the probe,
>> the trace file shows a line like the following:
>>
>> [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
>>
>> Note the extra "bar" printed as part of arg1. This behaviour stacks up
>> for additional string arguments.
>>
>> The strings are stored in a dynamically growing part of the uprobe
>> buffer by fetch_store_string() after copying them from userspace via
>> strncpy_from_user(). The return value of strncpy_from_user() is then
>> directly used as the required size for the string. However, this does
>> not take the terminating null byte into account as the documentation
>> for strncpy_from_user() cleary states that it "[...] returns the
>> length of the string (not including the trailing NUL)" even though the
>> null byte will be copied to the destination.
>>
>> Therefore, subsequent calls to fetch_store_string() will overwrite
>> the terminating null byte of the most recently fetched string with
>> the first character of the current string, leading to the
>> "accumulation" of strings in earlier arguments in the output.
>>
>> Fix this by incrementing the return value of strncpy_from_user() by
>> one if we did not hit the maximum buffer size.
>>
>
> Yeah, I had eventually same conclusion. However, you also have to increse
> the return value of fetch_store_strlen() too. (And I found another issue)
>
I don't think we need to increase that since the documentation for
strnlen_user() says that it "[r]eturns the size of the string
INCLUDING the terminating NUL." so its return value will already be
one more than that of strncpy_from_user().
Thanks,
Andreas
> Could you fix fetch_store_strlen in the same patch?
>
> Thank you,
>
>> Signed-off-by: Andreas Ziegler
>> ---
>> v2: removed a wrong check for (ret > 0)
>>
>> kernel/trace/trace_uprobe.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
>> index e335576b9411..3a1d5ab6b4ba 100644
>> --- a/kernel/trace/trace_uprobe.c
>> +++ b/kernel/trace/trace_uprobe.c
>> @@ -160,6 +160,13 @@ fetch_store_string(unsigned long addr, void *dest, void
>> *base)
>> if (ret >= 0) {
>> if (ret == maxlen)
>> dst[ret - 1] = '\0';
>> +else
>> +/*
>> + * Include the terminating null byte. In this case it
>> + * was copied by strncpy_from_user but not accounted
>> + * for in ret.
>> + */
>> +ret++;
>> *(u32 *)dest = make_data_loc(ret, (void *)dst - base);
>> }
>>
>> --
>> 2.17.1
>>
>
>
RE: [net] b8154ef682: WARNING:at_drivers/net/phy/phy_device.c:#phy_driver_register
> -Original Message-
> From: Andrew Lunn
> Sent: Wednesday, January 16, 2019 15:41
> To: kernel test robot
> Cc: Camelia Alexandra Groza ;
> f.faine...@gmail.com; hkallwe...@gmail.com; da...@davemloft.net;
> o...@buserror.net; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> l...@01.org
> Subject: Re: [net] b8154ef682:
> WARNING:at_drivers/net/phy/phy_device.c:#phy_driver_register
>
> On Wed, Jan 16, 2019 at 04:58:58PM +0800, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-7):
> >
> > commit: b8154ef682a9a745880ecbb2ee26b16297c9bfd0 ("[PATCH net] net:
> phy: phy driver features are mandatory")
> > url:
> > https://github.com/0day-ci/linux/commits/Camelia-Groza/net-phy-phy-driver-features-are-mandatory/20190116-004308
> >
> >
> > in testcase: trinity
> > with following parameters:
> >
> > runtime: 300s
> >
> > test-description: Trinity is a linux system call fuzz tester.
> > test-url: http://codemonkey.org.uk/projects/trinity/
> >
> >
> > on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2
> -m 512M
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
> >
> >
> > +--++
> +
> > | | 2f960bd056
> > | b8154ef682 |
> > +--++
> +
> > | boot_successes | 45
> > | 0 |
> > | boot_failures| 1
> > | 4 |
> > | BUG:kernel_timeout_in_torture_test_stage | 1
> > ||
> > | WARNING:at_drivers/net/phy/phy_device.c:#phy_driver_register | 0
> | 4 |
> > | EIP:phy_driver_register | 0
> > | 4 |
> > +--++
> +
> >
> >
> >
> > [ 458.251512] WARNING: CPU: 0 PID: 1 at
> drivers/net/phy/phy_device.c:2246 phy_driver_register+0x90/0xe0
> > [ 458.260864] CPU: 0 PID: 1 Comm: swapper Tainted: GT
> > 4.20.0-
> 11080-gb8154ef6 #158
> > [ 458.260864] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.10.2-1 04/01/2014
> > [ 458.260864] EIP: phy_driver_register+0x90/0xe0
> > [ 458.260864] Code: 5d 89 7b 08 89 03 89 d8 c7 43 14 02 00 00 00 e8 06 d3
> > e1
> ff 85 c0 89 c6 75 39 83 c4 0c 89 f0 5b 5e 5f 5d c3 8d b6 00 00 00 00 <0f> 0b
> b8 38
> 5b 2e 5e c7 04 24 00 00 00 00 31 c9 ba 01 00 00 00 be
> > [ 458.260864] EAX: 5e2e5b50 EBX: 5e1a8fe0 ECX: EDX: 0001
> > [ 458.260864] ESI: EDI: EBP: 4010defc ESP: 4010dee4
> > [ 458.260864] DS: 007b ES: 007b FS: GS: SS: 0068 EFLAGS:
> 00210246
> > [ 458.260864] CR0: 80050033 CR2: CR3: 1e43a000 CR4: 06b0
> > [ 458.260864] Call Trace:
> > [ 458.260864] ? phy_drivers_register+0x37/0x90
> > [ 458.260864] ? phy_module_init+0x1b/0x1b
> > [ 458.260864] ? phy_module_init+0x19/0x1b
> > [ 458.260864] ? do_one_initcall+0xd9/0x24b
>
> Hi Camelia
>
> I think we need to extend your patch and print the name of the PHY
> which is missing the features pointer. I don't see anything here which
> allows me to determine which PHY caused the warning.
Hi
Sure, I'll send a v2.
Camelia
Re: perf segfault in in ordered_events__free()
On Wed, Jan 16, 2019 at 1:53 PM Song Liu wrote:
>
> Thanks Jiri!
>
> On Wed, Jan 16, 2019 at 1:34 PM Jiri Olsa wrote:
> >
> > On Wed, Jan 16, 2019 at 10:57:49AM -0800, Song Liu wrote:
> > > Hi,
> > >
> > > We are debugging a segfault of perf in ordered_events__free().
> >
> > hi,
> > any backtrace or info on how to reproduce it?
>
> Here is the backtrace:
>
> #0 0x00500055 in ordered_events(float, long double,...)(...) ()
> #1 0x00500196 in ordered_events.reinit ()
> #2 0x004fe413 in perf_session.process_events ()
> #3 0x00440431 in cmd_record ()
> #4 0x004a439f in run_builtin ()
> #5 0x0042b3e5 in main ()"
>
> >
> > > Disassemble shows the segfault was caused by oe->buff == NULL
> > > in the following line:
> > >
> > > /*
> > > * Current buffer might not have all the events allocated
> > > * yet, we need to free only allocated ones ...
> > > */
> > > list_del(>buffer->list);
> > >
> > > After poking around the code, I suspect it is caused by the following
> > > condition in alloc_event():
> > >
> > > } else if (oe->buffer) {
> > > new = >buffer->event[oe->buffer_idx];
> > > if (++oe->buffer_idx == MAX_SAMPLE_BUFFER)
> > > oe->buffer = NULL;
> >
> >
> > argh.. yea, we need to check oe->buffer in ordered_events__free
> >
> > would attached change fix it for you?
>
> Let me try roll a fixed version to confirm.
Yes, the patch fixes this segfault. Please CC me on the official patch to
back port the official version.
Thanks,
Song
Re: [PATCH] mtd: spi-nor: Add support for Macronix mx25u3235f
Hi, Ding, Similar patch was already submitted by Hauke at http://patchwork.ozlabs.org/patch/1010030/. Can you please test his next patch version and add your Tested-by tag? Thanks, ta
[PATCH -next] cachefiles: remove duplicated include from namei.c
Remove duplicated include. Signed-off-by: YueHaibing --- fs/cachefiles/namei.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c index 1645fcf..d27720c 100644 --- a/fs/cachefiles/namei.c +++ b/fs/cachefiles/namei.c @@ -20,7 +20,6 @@ #include #include #include -#include #include "internal.h" #define CACHEFILES_KEYBUF_SIZE 512 -- 2.7.0
[PATCH -next] ptr_ring: remove duplicated include from ptr_ring.h
Remove duplicated include. Signed-off-by: YueHaibing --- include/linux/ptr_ring.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h index 186cd8e..8da46ac 100644 --- a/include/linux/ptr_ring.h +++ b/include/linux/ptr_ring.h @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #endif -- 2.7.0
Re: [PATCH 2/2] pwm: sifive: Add a driver for SiFive SoC PWM
Hello,
On Thu, Jan 17, 2019 at 12:15:38PM +0530, Yash Shah wrote:
> On Wed, Jan 16, 2019 at 10:16 PM Uwe Kleine-König
> wrote:
> >
> > Hello,
> >
> > On Wed, Jan 16, 2019 at 04:40:42PM +0530, Yash Shah wrote:
> > > On Wed, Jan 16, 2019 at 3:30 AM Uwe Kleine-König
> > > wrote:
> > > > On Fri, Jan 11, 2019 at 01:52:44PM +0530, Yash Shah wrote:
> > > > > Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed
> > > > > SoC.
> > > > >
> > > > > Signed-off-by: Wesley W. Terpstra
> > > > > [Atish: Various fixes and code cleanup]
> > > > > Signed-off-by: Atish Patra
> > > > > Signed-off-by: Yash Shah
> > > > > ---
> > > > > drivers/pwm/Kconfig | 10 ++
> > > > > drivers/pwm/Makefile | 1 +
> > > > > drivers/pwm/pwm-sifive.c | 246
> > > > > +++
> > > > > 3 files changed, 257 insertions(+)
> > > > > create mode 100644 drivers/pwm/pwm-sifive.c
> > > > >
> > > > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> > > > > index a8f47df..3bcaf6a 100644
> > > > > --- a/drivers/pwm/Kconfig
> > > > > +++ b/drivers/pwm/Kconfig
> > > > > @@ -380,6 +380,16 @@ config PWM_SAMSUNG
> > > > > To compile this driver as a module, choose M here: the module
> > > > > will be called pwm-samsung.
> > > > >
> > > > > +config PWM_SIFIVE
> > > > > + tristate "SiFive PWM support"
> > > > > + depends on OF
> > > > > + depends on COMMON_CLK
> > > >
> > > > I'd say add:
> > > >
> > > > depends on MACH_SIFIVE || COMPILE_TEST
> > > >
> > > > (I guess "MACH_SIFIVE" is wrong, but I assume you get what I mean.)
> > >
> > > As of now, MACH_SIFIVE/ARCH_SIFIVE isn't available.
> > > @Paul, Do you have any comments on this?
> >
> > If this is not going to be available at least protect it by
> >
> > depends RISCV || COMPILE_TEST
> >
> > > > I wonder if such an instance should be only a single PWM instead of
> > > > four. Then you were more flexible with the period lengths (using
> > > > pwmcfg.pwmzerocmp) and could do stuff like inverted and uninverted mode.
> > > >
> > > > I didn't understand how the deglitch logic works yet. Currently it is
> > > > not used which might result in four edges in a single period (which is
> > > > bad).
> > >
> > > I can enable deglitch logic by just setting a bit (BIT_PWM_DEGLITCH) in
> > > REG_PWMCFG. Will do that.
> >
> > This only works for the first pwm output though.
I mixed this up with pwmzerocmp; deglitch should work on all four
outputs.
> > > > > +struct sifive_pwm_device {
> > > > > + struct pwm_chip chip;
> > > > > + struct notifier_block notifier;
> > > > > + struct clk *clk;
> > > > > + void __iomem *regs;
> > > > > + unsigned int approx_period;
> >
> > When thinking about this a bit more, I think the better approach would
> > be to let the consumer change the period iff there is only one consumer.
> > Then you can drop that approx-period stuff and the result is more
> > flexible. (Having said that I still prefer making the driver provide
> > only a single PWM with the ability to have periods other than powers of
> > two.)
> >
>
> I am not confident about the implementation of the way you are suggesting.
> As of now, I am going to stick with the current implementation.
The idea is to count the users using the .request and .free callbacks.
Iff there is exactly one, allow changes to period.
But please consider moving to an abstraction that only provides a single
pwm instead.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v3] cpufreq: qcom: Read voltage LUT and populate OPP
On 17-01-19, 12:38, Taniya Das wrote:
> @@ -159,10 +170,18 @@ static int qcom_cpufreq_hw_cpu_init(struct
> cpufreq_policy *policy)
> struct device *dev = _pdev->dev;
> struct of_phandle_args args;
> struct device_node *cpu_np;
> + struct device *cpu_dev;
> struct resource *res;
> void __iomem *base;
> int ret, index;
>
> + cpu_dev = get_cpu_device(policy->cpu);
> + if (!cpu_dev) {
> + pr_err("%s: failed to get cpu%d device\n", __func__,
> +policy->cpu);
> + return -ENODEV;
> + }
> +
> cpu_np = of_cpu_device_node_get(policy->cpu);
> if (!cpu_np)
> return -EINVAL;
> @@ -199,12 +218,18 @@ static int qcom_cpufreq_hw_cpu_init(struct
> cpufreq_policy *policy)
>
> policy->driver_data = base + REG_PERF_STATE;
>
> - ret = qcom_cpufreq_hw_read_lut(dev, policy, base);
> + ret = qcom_cpufreq_hw_read_lut(policy, base);
I asked you to pass cpu_dev here instead of dev and you said okay in
the previous version of the patch. Didn't like it ?
--
viresh
[PATCH -next] perf: remove duplicated include from perf_event.h
Remove duplicated include.
Signed-off-by: YueHaibing
---
include/linux/perf_event.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 1d5c551..19baf4a 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -53,7 +53,6 @@ struct perf_guest_info_callbacks {
#include
#include
#include
-#include
#include
#include
--
2.7.0
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote: > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a): > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote: > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a): > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote: > > > > > Currently MP clocks don't consider adjusting parent rate even if they > > > > > are allowed to do so. Such behaviour considerably lowers amount of > > > > > possible rates, which is very inconvenient when such clock is used for > > > > > pixel clock, for example. > > > > > > > > > > In order to improve the situation, adjusting parent rate is considered > > > > > when allowed. > > > > > > > > > > This code is inspired by clk_divider_bestdiv() function, which does > > > > > basically the same thing for different clock type. > > > > > > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC > > > > boards: > > > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem > > > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command > > > > sunxi-mmc 1c11000.mmc: send stop command failed > > > > > > I'm not familiar with A20. What is interesting is that emmc clocks don't > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any difference. > > > > > > Can you post content of clk_summary with and without this patch? > > > > In both cases I booted from FEL with rootfs on sdcard and tried to mount > > partition from eMMC to /mnt. With your patch, last step it fails. > > > > pre-patch working: > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is off?) > > > > post-patch not working: > > pll-periph[600MHz] -> mmc2[500Mhz], (ahb-mmc2 is enabled) > > > > Also, attached the logs. > > Thanks. Just one more request. Can you enable debug messages in mmc driver? > I'm interested in output of this line: > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n", > clock, rate); 1c11000 is eMMC: [snip] [1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [2.203340] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [2.211412] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [4.967865] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [8.755345] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [9.082510] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 Here I tried to mount partition from eMMC... [ 72.167311] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [ 72.269629] sunxi-mmc 1c11000.mmc: data error, sending stop command [ 73.268999] sunxi-mmc 1c11000.mmc: send stop command failed [/snip] And clock tree: [snip] pll-periph-base330 12 0 0 5 pll-periph 660 6 0 0 5 mmc2 3305000 0 0 5 mmc2_sample 1105000 0 120 5 mmc2_output 1105000 060 5 ahb 18 180 3 0 0 5 ahb-mmc2 110 3 0 0 5 [/snip] And without patch: [snip] [2.003341] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.019479] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.039144] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.047129] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.054324] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.064481] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.091624] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.168067] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.188239] sunxi-mmc 1c11000.mmc: XXX: setting clk to 5200, rounded 5120 [
[PATCH net-next] qed: remove duplicated include from qed_if.h
Remove duplicated include. Signed-off-by: YueHaibing --- include/linux/qed/qed_if.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h index 91c536a..5f818fd 100644 --- a/include/linux/qed/qed_if.h +++ b/include/linux/qed/qed_if.h @@ -38,7 +38,6 @@ #include #include #include -#include #include #include #include -- 2.7.0
[PATCH -next] security: remove duplicated include from security.h
Remove duplicated include. Signed-off-by: YueHaibing --- include/linux/security.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/security.h b/include/linux/security.h index b10866b..7ed03c6 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -30,7 +30,6 @@ #include #include #include -#include struct linux_binprm; struct cred; -- 2.7.0
[PATCH v3 3/4] usb: musb: Delete the const attribute of addr parameter in readb/w/l hooks
From: Min Guo
These changes are for implementing clearing W1C registers.
Signed-off-by: Min Guo
---
drivers/usb/musb/musb_core.c | 10 +-
drivers/usb/musb/musb_core.h | 4 ++--
drivers/usb/musb/musb_io.h | 6 +++---
drivers/usb/musb/sunxi.c | 4 ++--
drivers/usb/musb/tusb6010.c | 2 +-
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b7d5627..d7a417b 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -246,7 +246,7 @@ static u32 musb_default_busctl_offset(u8 epnum, u16 offset)
return 0x80 + (0x08 * epnum) + offset;
}
-static u8 musb_default_readb(const void __iomem *addr, unsigned offset)
+static u8 musb_default_readb(void __iomem *addr, unsigned offset)
{
u8 data = __raw_readb(addr + offset);
@@ -260,7 +260,7 @@ static void musb_default_writeb(void __iomem *addr,
unsigned offset, u8 data)
__raw_writeb(data, addr + offset);
}
-static u16 musb_default_readw(const void __iomem *addr, unsigned offset)
+static u16 musb_default_readw(void __iomem *addr, unsigned offset)
{
u16 data = __raw_readw(addr + offset);
@@ -364,19 +364,19 @@ static void musb_default_read_fifo(struct musb_hw_ep
*hw_ep, u16 len, u8 *dst)
/*
* Old style IO functions
*/
-u8 (*musb_readb)(const void __iomem *addr, unsigned offset);
+u8 (*musb_readb)(void __iomem *addr, unsigned offset);
EXPORT_SYMBOL_GPL(musb_readb);
void (*musb_writeb)(void __iomem *addr, unsigned offset, u8 data);
EXPORT_SYMBOL_GPL(musb_writeb);
-u16 (*musb_readw)(const void __iomem *addr, unsigned offset);
+u16 (*musb_readw)(void __iomem *addr, unsigned offset);
EXPORT_SYMBOL_GPL(musb_readw);
void (*musb_writew)(void __iomem *addr, unsigned offset, u16 data);
EXPORT_SYMBOL_GPL(musb_writew);
-u32 musb_readl(const void __iomem *addr, unsigned offset)
+u32 musb_readl(void __iomem *addr, unsigned offset)
{
u32 data = __raw_readl(addr + offset);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 04203b7..daf5422 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -161,9 +161,9 @@ struct musb_platform_ops {
u16 fifo_mode;
u32 (*fifo_offset)(u8 epnum);
u32 (*busctl_offset)(u8 epnum, u16 offset);
- u8 (*readb)(const void __iomem *addr, unsigned offset);
+ u8 (*readb)(void __iomem *addr, unsigned offset);
void(*writeb)(void __iomem *addr, unsigned offset, u8 data);
- u16 (*readw)(const void __iomem *addr, unsigned offset);
+ u16 (*readw)(void __iomem *addr, unsigned offset);
void(*writew)(void __iomem *addr, unsigned offset, u16 data);
void(*read_fifo)(struct musb_hw_ep *hw_ep, u16 len, u8 *buf);
void(*write_fifo)(struct musb_hw_ep *hw_ep, u16 len, const u8 *buf);
diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
index 8058a58..34ea2a4 100644
--- a/drivers/usb/musb/musb_io.h
+++ b/drivers/usb/musb/musb_io.h
@@ -33,11 +33,11 @@ struct musb_io {
};
/* Do not add new entries here, add them the struct musb_io instead */
-extern u8 (*musb_readb)(const void __iomem *addr, unsigned offset);
+extern u8 (*musb_readb)(void __iomem *addr, unsigned offset);
extern void (*musb_writeb)(void __iomem *addr, unsigned offset, u8 data);
-extern u16 (*musb_readw)(const void __iomem *addr, unsigned offset);
+extern u16 (*musb_readw)(void __iomem *addr, unsigned offset);
extern void (*musb_writew)(void __iomem *addr, unsigned offset, u16 data);
-extern u32 musb_readl(const void __iomem *addr, unsigned offset);
+extern u32 musb_readl(void __iomem *addr, unsigned offset);
extern void musb_writel(void __iomem *addr, unsigned offset, u32 data);
#endif
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 832a41f..2c1bbaa 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -407,7 +407,7 @@ static u32 sunxi_musb_busctl_offset(u8 epnum, u16 offset)
return SUNXI_MUSB_TXFUNCADDR + offset;
}
-static u8 sunxi_musb_readb(const void __iomem *addr, unsigned offset)
+static u8 sunxi_musb_readb(void __iomem *addr, unsigned offset)
{
struct sunxi_glue *glue;
@@ -520,7 +520,7 @@ static void sunxi_musb_writeb(void __iomem *addr, unsigned
offset, u8 data)
(int)(addr - sunxi_musb->mregs));
}
-static u16 sunxi_musb_readw(const void __iomem *addr, unsigned offset)
+static u16 sunxi_musb_readw(void __iomem *addr, unsigned offset)
{
if (addr == sunxi_musb->mregs) {
/* generic control or fifo control reg access */
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 3945328..cfb94f9 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -142,7 +142,7 @@ static void tusb_ep_select(void __iomem *mbase, u8 epnum)
/*
* TUSB6010 doesn't allow 8-bit access; 16-bit
[PATCH v3 2/4] arm: dts: mt2701: Add usb2 device nodes
From: Min Guo
Add musb nodes and usb2 phy nodes for MT2701
Signed-off-by: Min Guo
---
arch/arm/boot/dts/mt2701-evb.dts | 21 +
arch/arm/boot/dts/mt2701.dtsi| 33 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index be0edb3..2635911 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -6,6 +6,7 @@
*/
/dts-v1/;
+#include
#include "mt2701.dtsi"
/ {
@@ -60,6 +61,20 @@
>;
default-brightness-level = <9>;
};
+
+ extcon_usb: extcon_iddig {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = < 44 GPIO_ACTIVE_HIGH>;
+ };
+
+ usb_vbus: regulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 45 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
{
@@ -229,3 +244,9 @@
{
status = "okay";
};
+
+ {
+ vbus-supply = <_vbus>;
+ extcon = <_usb>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 180377e..a6b1434 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -670,6 +670,39 @@
};
};
+ usb2: usb@1120 {
+ compatible = "mediatek,mt2701-musb",
+"mediatek,mtk-musb";
+ reg = <0 0x1120 0 0x1000>;
+ interrupts = ;
+ interrupt-names = "mc";
+ phys = < PHY_TYPE_USB2>;
+ dr_mode = "otg";
+ clocks = < CLK_PERI_USB0>,
+< CLK_PERI_USB0_MCU>,
+< CLK_PERI_USB_SLV>;
+ clock-names = "main","mcu","univpll";
+ power-domains = < MT2701_POWER_DOMAIN_IFR_MSC>;
+ status = "disabled";
+ };
+
+ u2phy0: usb-phy@1121 {
+ compatible = "mediatek,generic-tphy-v1";
+ reg = <0 0x1121 0 0x0800>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "okay";
+
+ u2port2: usb-phy@1a1c4800 {
+ reg = <0 0x11210800 0 0x0100>;
+ clocks = < CLK_TOP_USB_PHY48M>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
ethsys: syscon@1b00 {
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b00 0 0x1000>;
--
1.9.1
[PATCH v3 0/4] Add MediaTek MUSB Controller Driver
From: Min Guo These patches introduce the MediaTek MUSB controller driver. The driver can be configured as Dual-Role Device (DRD), Peripheral Only and Host Only modes. This has beed tested on MT2701 with a variety of devices in host mode and with the f_mass gadget driver in peripheral mode, plugging otg cables in/out a lot of times in all possible imaginable plug orders. changes in v3: changes of driver suggested by Bin: 1. Add a new patch for musb_readb/w/l() to remove const attribute 2. Use is_out as function parameter in set_toggle/get_toggle() hooks 3. Remove 'u8/u16 data' parameter in clearb/w() hooks 4. Remove musb_default_clearb/w() 5. Replace musb_readb/w() with musb_clearb/w() to clear pending interrupts 6. Add comments to clearb/w() hooks 7. Replace musb_save_toggle() with musb->io.get_toggle() 8. Replace musb_set_toggle() with musb->io.set_toggle() changes in v2: changes of dt-bindings suggested by Rob: 1. Modify DRC to DRD 2. Drop the "-musb" in compatible 3. Remove phy-names 4. Add space after comma in clock-names dtsi: 1. Remove phy-names changes of driver suggested by Bin: 1. Add a new patch for musb_set_toggle 2. Add summarize of MediaTek musb controller differences in the commit log 3. Abondon patch "usb: musb: Move musbhsdma macro definition to musb_dma.h" 4. Add "|| COMPILE_TEST" in Kconfig 5. Add musb_clearb() and musb_clearw() hooks 6. Add get_toggle() and set_toggle() hooks 7. Replace musb_readl() with musb_readw() to read 16bit toggle register 8. Move MediaTek's private toggle registers from musb_regs.h to mediatek.c 9. Create musbhs_dma_controller_create_noirq() Min Guo (4): dt-bindings: usb: musb: Add support for MediaTek musb controller arm: dts: mt2701: Add usb2 device nodes usb: musb: Delete the const attribute of addr parameter in readb/w/l hooks usb: musb: Add support for MediaTek musb controller .../devicetree/bindings/usb/mediatek,musb.txt | 43 ++ arch/arm/boot/dts/mt2701-evb.dts | 21 + arch/arm/boot/dts/mt2701.dtsi | 33 ++ drivers/usb/musb/Kconfig | 8 +- drivers/usb/musb/Makefile | 1 + drivers/usb/musb/mediatek.c| 624 + drivers/usb/musb/musb_core.c | 74 ++- drivers/usb/musb/musb_core.h | 13 +- drivers/usb/musb/musb_dma.h| 9 + drivers/usb/musb/musb_host.c | 46 +- drivers/usb/musb/musb_io.h | 12 +- drivers/usb/musb/musbhsdma.c | 57 +- drivers/usb/musb/sunxi.c | 4 +- drivers/usb/musb/tusb6010.c| 2 +- 14 files changed, 876 insertions(+), 71 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt create mode 100644 drivers/usb/musb/mediatek.c -- 1.9.1
[PATCH v3 4/4] usb: musb: Add support for MediaTek musb controller
From: Min Guo
This adds support for MediaTek musb controller in
host, peripheral and otg mode.
There are some quirk of MediaTek musb controller, such as:
-W1C interrupt status registers
-Private data toggle registers
-No dedicated DMA interrupt line
Signed-off-by: Min Guo
Signed-off-by: Yonglong Wu
---
drivers/usb/musb/Kconfig | 8 +-
drivers/usb/musb/Makefile| 1 +
drivers/usb/musb/mediatek.c | 624 +++
drivers/usb/musb/musb_core.c | 64 -
drivers/usb/musb/musb_core.h | 9 +
drivers/usb/musb/musb_dma.h | 9 +
drivers/usb/musb/musb_host.c | 46 +---
drivers/usb/musb/musb_io.h | 6 +
drivers/usb/musb/musbhsdma.c | 57 ++--
9 files changed, 766 insertions(+), 58 deletions(-)
create mode 100644 drivers/usb/musb/mediatek.c
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index ad08895..b72b7c1 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -115,6 +115,12 @@ config USB_MUSB_JZ4740
depends on USB_MUSB_GADGET
depends on USB_OTG_BLACKLIST_HUB
+config USB_MUSB_MEDIATEK
+ tristate "MediaTek platforms"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on NOP_USB_XCEIV
+ depends on GENERIC_PHY
+
config USB_MUSB_AM335X_CHILD
tristate
@@ -141,7 +147,7 @@ config USB_UX500_DMA
config USB_INVENTRA_DMA
bool 'Inventra'
- depends on USB_MUSB_OMAP2PLUS
+ depends on USB_MUSB_OMAP2PLUS || USB_MUSB_MEDIATEK
help
Enable DMA transfers using Mentor's engine.
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index 3a88c79..63d82d0 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o
obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
obj-$(CONFIG_USB_MUSB_JZ4740) += jz4740.o
obj-$(CONFIG_USB_MUSB_SUNXI) += sunxi.o
+obj-$(CONFIG_USB_MUSB_MEDIATEK)+= mediatek.o
obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
diff --git a/drivers/usb/musb/mediatek.c b/drivers/usb/musb/mediatek.c
new file mode 100644
index 000..65cafa6
--- /dev/null
+++ b/drivers/usb/musb/mediatek.c
@@ -0,0 +1,624 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ *
+ * Author:
+ * Min Guo
+ * Yonglong Wu
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "musb_core.h"
+#include "musb_dma.h"
+
+#define USB_L1INTS 0x00a0
+#define USB_L1INTM 0x00a4
+#define MTK_MUSB_TXFUNCADDR0x0480
+
+/* MediaTek controller toggle enable and status reg */
+#define MUSB_RXTOG 0x80
+#define MUSB_RXTOGEN 0x82
+#define MUSB_TXTOG 0x84
+#define MUSB_TXTOGEN 0x86
+
+#define TX_INT_STATUS BIT(0)
+#define RX_INT_STATUS BIT(1)
+#define USBCOM_INT_STATUS BIT(2)
+#define DMA_INT_STATUS BIT(3)
+
+#define DMA_INTR_STATUS_MSKGENMASK(7, 0)
+#define DMA_INTR_UNMASK_SET_MSKGENMASK(31, 24)
+
+enum mtk_vbus_id_state {
+ MTK_ID_FLOAT = 1,
+ MTK_ID_GROUND,
+ MTK_VBUS_OFF,
+ MTK_VBUS_VALID,
+};
+
+struct mtk_glue {
+ struct device *dev;
+ struct musb *musb;
+ struct platform_device *musb_pdev;
+ struct platform_device *usb_phy;
+ struct phy *phy;
+ struct usb_phy *xceiv;
+ enum phy_mode phy_mode;
+ struct clk *main;
+ struct clk *mcu;
+ struct clk *univpll;
+ struct regulator *vbus;
+ struct extcon_dev *edev;
+ struct notifier_block vbus_nb;
+ struct notifier_block id_nb;
+};
+
+static int mtk_musb_clks_get(struct mtk_glue *glue)
+{
+ struct device *dev = glue->dev;
+
+ glue->main = devm_clk_get(dev, "main");
+ if (IS_ERR(glue->main)) {
+ dev_err(dev, "fail to get main clock\n");
+ return PTR_ERR(glue->main);
+ }
+
+ glue->mcu = devm_clk_get(dev, "mcu");
+ if (IS_ERR(glue->mcu)) {
+ dev_err(dev, "fail to get mcu clock\n");
+ return PTR_ERR(glue->mcu);
+ }
+
+ glue->univpll = devm_clk_get(dev, "univpll");
+ if (IS_ERR(glue->univpll)) {
+ dev_err(dev, "fail to get univpll clock\n");
+ return PTR_ERR(glue->univpll);
+ }
+
+ return 0;
+}
+
+static int mtk_musb_clks_enable(struct mtk_glue *glue)
+{
+ int ret;
+
+ ret = clk_prepare_enable(glue->main);
+ if (ret) {
+ dev_err(glue->dev, "failed to enable main clock\n");
+ goto err_main_clk;
+ }
+
+ ret = clk_prepare_enable(glue->mcu);
+ if (ret) {
+ dev_err(glue->dev, "failed to enable mcu clock\n");
+ goto err_mcu_clk;
+ }
+
+ ret = clk_prepare_enable(glue->univpll);
+ if (ret) {
+ dev_err(glue->dev, "failed to
[PATCH v3 1/4] dt-bindings: usb: musb: Add support for MediaTek musb controller
From: Min Guo
This adds support for MediaTek musb controller in
host, peripheral and otg mode.
Signed-off-by: Min Guo
---
.../devicetree/bindings/usb/mediatek,musb.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt
diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt
b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
new file mode 100644
index 000..3e3f671
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
@@ -0,0 +1,43 @@
+MediaTek musb DRD/OTG controller
+---
+
+Required properties:
+ - compatible : should be "mediatek,mtk-musb"
+ - reg : specifies physical base address and size of
+ the registers
+ - interrupts : interrupt used by musb controller
+ - interrupt-names : must be "mc"
+ - phys: PHY specifier for the OTG phy
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+ refer to usb/generic.txt
+ - clocks : a list of phandle + clock-specifier pairs, one for
+ each entry in clock-names
+ - clock-names : must contain "main", "mcu", "univpll"
+ for clocks of controller
+
+Optional properties:
+ - extcon : external connector for VBUS and IDPIN changes detection,
+ needed when supports dual-role mode.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+ dual-role mode.
+ - power-domains : a phandle to USB power domain node to control USB's
+ MTCMOS
+
+Example:
+
+usb2: usb@1120 {
+ compatible = "mediatek,mt2701-musb",
+"mediatek,mtk-musb";
+ reg = <0 0x1120 0 0x1000>;
+ interrupts = ;
+ interrupt-names = "mc";
+ phys = < PHY_TYPE_USB2>;
+ vbus-supply = <_vbus>;
+ extcon = <_usb>;
+ dr_mode = "otg";
+ clocks = < CLK_PERI_USB0>,
+< CLK_PERI_USB0_MCU>,
+< CLK_PERI_USB_SLV>;
+ clock-names = "main","mcu","univpll";
+ power-domains = < MT2701_POWER_DOMAIN_IFR_MSC>;
+};
--
1.9.1
Re: [PATCH v7 3/5] mtd: m25p80: add support of octal mode I/O transfer
On 01/15/2019 12:05 PM, Yogesh Narayan Gaur wrote:
> Add support for octal mode I/O data transfer based on the controller (spi)
> mode.
> Assign hw-capability mask bits for octal transfer.
>
> Signed-off-by: Yogesh Narayan Gaur
Reviewed-by: Tudor Ambarus
> ---
> drivers/mtd/devices/m25p80.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index c4a1d04b8c80..651bab6d4e31 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -195,7 +195,14 @@ static int m25p_probe(struct spi_mem *spimem)
> spi_mem_set_drvdata(spimem, flash);
> flash->spimem = spimem;
>
> - if (spi->mode & SPI_RX_QUAD) {
> + if (spi->mode & SPI_RX_OCTAL) {
> + hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8;
> +
> + if (spi->mode & SPI_TX_OCTAL)
> + hwcaps.mask |= (SNOR_HWCAPS_READ_1_8_8 |
> + SNOR_HWCAPS_PP_1_1_8 |
> + SNOR_HWCAPS_PP_1_8_8);
> + } else if (spi->mode & SPI_RX_QUAD) {
> hwcaps.mask |= SNOR_HWCAPS_READ_1_1_4;
>
> if (spi->mode & SPI_TX_QUAD)
>
[PATCH -next] block: remove duplicated include from block_dev.c
Remove duplicated include. Signed-off-by: YueHaibing --- fs/block_dev.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index c546cdc..b225edb 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -29,7 +29,6 @@ #include #include #include -#include #include #include #include -- 2.7.0
[PATCH -next] power: supply: core: remove duplicated include from power_supply_core.c
Remove duplicated include.
Signed-off-by: YueHaibing
---
drivers/power/supply/power_supply_core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/power/supply/power_supply_core.c
b/drivers/power/supply/power_supply_core.c
index 569790e..07a85e1 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -156,8 +156,6 @@ static void power_supply_deferred_register_work(struct
work_struct *work)
}
#ifdef CONFIG_OF
-#include
-
static int __power_supply_populate_supplied_from(struct device *dev,
void *data)
{
--
2.7.0
Re: [PATCH] Input: olpc_apsp - assign priv->dev earlier
On Wed, Jan 16, 2019 at 10:44:38AM +0100, Lubomir Rintel wrote:
> The dev field needs to be set when serio_register_port() is called,
> because the open callback may use it (in the error handling path).
>
> Cc: sta...@vger.kernel.org # v4.18+
> Fixes: commit af518342effd ("Input: olpc_apsp - check FIFO status on open(),
> not probe()")
> Signed-off-by: Lubomir Rintel
Applied, thank you.
> ---
> drivers/input/serio/olpc_apsp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
> index 0aece9777087..554f4b8228d2 100644
> --- a/drivers/input/serio/olpc_apsp.c
> +++ b/drivers/input/serio/olpc_apsp.c
> @@ -198,6 +198,8 @@ static int olpc_apsp_probe(struct platform_device *pdev)
> if (!priv)
> return -ENOMEM;
>
> + priv->dev = >dev;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> priv->base = devm_ioremap_resource(>dev, res);
> if (IS_ERR(priv->base)) {
> @@ -261,7 +263,6 @@ static int olpc_apsp_probe(struct platform_device *pdev)
> goto err_irq;
> }
>
> - priv->dev = >dev;
> device_init_wakeup(priv->dev, 1);
> platform_set_drvdata(pdev, priv);
>
> --
> 2.20.1
>
--
Dmitry
Re: [PATCH][V2] cifs: fix memory leak of an allocated cifs_ntsd structure
Thanks, Colin! Reviewed-by: Dan Carpener regards, dan carpenter
[PATCH] csky: Optimize remove unnecessary loop irq handle
From: Guo Ren
Here is the previous interrupt processing flow:
while (pending) {
^^^ It's unnecessary!
get irq
handle_level/fasteoi_irq {
mask irq
driver irq handler
unmask irq
}
irq_exit {
preempt_count_sub(HARDIRQ_OFFSET);
if (!in_interrupt() && local_softirq_pending())
invoke_softirq();
Because: linux enable irq Here!
}
}
Because linux enable the irq in irq_exit() before ret, we needn't loop
read pending register again for next irq which is done during irq_exit().
Signed-off-by: Guo Ren
Cc: Thomas Gleixner
Cc: Marc Zyngier
---
drivers/irqchip/irq-csky-apb-intc.c | 36 ++--
drivers/irqchip/irq-csky-mpintc.c | 8 ++--
2 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/drivers/irqchip/irq-csky-apb-intc.c
b/drivers/irqchip/irq-csky-apb-intc.c
index fcc5444..ae4c59b 100644
--- a/drivers/irqchip/irq-csky-apb-intc.c
+++ b/drivers/irqchip/irq-csky-apb-intc.c
@@ -150,7 +150,7 @@ ck_intc_init_comm(struct device_node *node, struct
device_node *parent)
return 0;
}
-static inline bool handle_irq_perbit(struct pt_regs *regs, u32 hwirq,
+static inline bool handle_irq_onebit(struct pt_regs *regs, u32 hwirq,
u32 irq_base)
{
if (hwirq == 0)
@@ -166,16 +166,15 @@ static void gx_irq_handler(struct pt_regs *regs)
{
bool ret;
-retry:
- ret = handle_irq_perbit(regs,
+ ret = handle_irq_onebit(regs,
readl(reg_base + GX_INTC_PEN63_32), 32);
if (ret)
- goto retry;
+ return;
- ret = handle_irq_perbit(regs,
+ ret = handle_irq_onebit(regs,
readl(reg_base + GX_INTC_PEN31_00), 0);
- if (ret)
- goto retry;
+ if (!ret)
+ pr_err("%s: none irq pending!\n", __func__);
}
static int __init
@@ -277,29 +276,30 @@ static void ck_irq_handler(struct pt_regs *regs)
void __iomem *reg_pen_lo = reg_base + CK_INTC_PEN31_00;
void __iomem *reg_pen_hi = reg_base + CK_INTC_PEN63_32;
-retry:
/* handle 0 - 63 irqs */
- ret = handle_irq_perbit(regs, readl(reg_pen_hi), 32);
+ ret = handle_irq_onebit(regs, readl(reg_pen_hi), 32);
if (ret)
- goto retry;
+ return;
- ret = handle_irq_perbit(regs, readl(reg_pen_lo), 0);
+ ret = handle_irq_onebit(regs, readl(reg_pen_lo), 0);
if (ret)
- goto retry;
+ return;
- if (nr_irq == INTC_IRQS)
+ if (nr_irq == INTC_IRQS) {
+ pr_err("%s: none irq pending!\n", __func__);
return;
+ }
/* handle 64 - 127 irqs */
- ret = handle_irq_perbit(regs,
+ ret = handle_irq_onebit(regs,
readl(reg_pen_hi + CK_INTC_DUAL_BASE), 96);
if (ret)
- goto retry;
+ return;
- ret = handle_irq_perbit(regs,
+ ret = handle_irq_onebit(regs,
readl(reg_pen_lo + CK_INTC_DUAL_BASE), 64);
- if (ret)
- goto retry;
+ if (!ret)
+ pr_err("%s: none irq pending!\n", __func__);
}
static int __init
diff --git a/drivers/irqchip/irq-csky-mpintc.c
b/drivers/irqchip/irq-csky-mpintc.c
index 9edc6d3..37ff62b 100644
--- a/drivers/irqchip/irq-csky-mpintc.c
+++ b/drivers/irqchip/irq-csky-mpintc.c
@@ -36,7 +36,6 @@ static void __iomem *INTCL_base;
#define INTCL_CFGR 0x14
#define INTCL_PRTR 0x20
#define INTCL_SIGR 0x60
-#define INTCL_HPPIR0x68
#define INTCL_RDYIR0x6c
#define INTCL_SENR 0xa0
#define INTCL_CENR 0xa4
@@ -48,11 +47,8 @@ static void csky_mpintc_handler(struct pt_regs *regs)
{
void __iomem *reg_base = this_cpu_read(intcl_reg);
- do {
- handle_domain_irq(root_domain,
- readl_relaxed(reg_base + INTCL_RDYIR),
- regs);
- } while (readl_relaxed(reg_base + INTCL_HPPIR) & BIT(31));
+ handle_domain_irq(root_domain,
+ readl_relaxed(reg_base + INTCL_RDYIR), regs);
}
static void csky_mpintc_enable(struct irq_data *d)
--
2.7.4
[PATCH v3] cpufreq: qcom: Read voltage LUT and populate OPP
Add support to read the voltage look up table and populate OPP for all
corresponding CPUS for consumers like the energy model could use the
frequency and voltage from the OPP tables. Also update the logic to not add
duplicate OPPs.
Tested-by: Matthias Kaehlcke
Signed-off-by: Matthias Kaehlcke
Signed-off-by: Taniya Das
---
drivers/cpufreq/qcom-cpufreq-hw.c | 43 +++
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
index d83939a..8da5576 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -10,18 +10,21 @@
#include
#include
#include
+#include
#include
#define LUT_MAX_ENTRIES40U
#define LUT_SRCGENMASK(31, 30)
#define LUT_L_VAL GENMASK(7, 0)
#define LUT_CORE_COUNT GENMASK(18, 16)
+#define LUT_VOLT GENMASK(11, 0)
#define LUT_ROW_SIZE 32
#define CLK_HW_DIV 2
/* Register offsets */
#define REG_ENABLE 0x0
-#define REG_LUT_TABLE 0x110
+#define REG_FREQ_LUT 0x110
+#define REG_VOLT_LUT 0x114
#define REG_PERF_STATE 0x920
static unsigned long cpu_hw_rate, xo_rate;
@@ -70,35 +73,41 @@ static unsigned int qcom_cpufreq_hw_fast_switch(struct
cpufreq_policy *policy,
return policy->freq_table[index].frequency;
}
-static int qcom_cpufreq_hw_read_lut(struct device *dev,
- struct cpufreq_policy *policy,
+static int qcom_cpufreq_hw_read_lut(struct cpufreq_policy *policy,
void __iomem *base)
{
u32 data, src, lval, i, core_count, prev_cc = 0, prev_freq = 0, freq;
+ u32 volt;
unsigned int max_cores = cpumask_weight(policy->cpus);
struct cpufreq_frequency_table *table;
+ struct device *cpu_dev = get_cpu_device(policy->cpu);
table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
if (!table)
return -ENOMEM;
for (i = 0; i < LUT_MAX_ENTRIES; i++) {
- data = readl_relaxed(base + REG_LUT_TABLE + i * LUT_ROW_SIZE);
+ data = readl_relaxed(base + REG_FREQ_LUT +
+ i * LUT_ROW_SIZE);
src = FIELD_GET(LUT_SRC, data);
lval = FIELD_GET(LUT_L_VAL, data);
core_count = FIELD_GET(LUT_CORE_COUNT, data);
+ data = readl_relaxed(base + REG_VOLT_LUT +
+ i * LUT_ROW_SIZE);
+ volt = FIELD_GET(LUT_VOLT, data) * 1000;
+
if (src)
freq = xo_rate * lval / 1000;
else
freq = cpu_hw_rate / 1000;
- /* Ignore boosts in the middle of the table */
- if (core_count != max_cores) {
+ if (freq != prev_freq && core_count == max_cores) {
table[i].frequency = CPUFREQ_ENTRY_INVALID;
} else {
table[i].frequency = freq;
- dev_dbg(dev, "index=%d freq=%d, core_count %d\n", i,
+ dev_pm_opp_add(cpu_dev, freq * 1000, volt);
+ dev_dbg(cpu_dev, "index=%d freq=%d, core_count %d\n", i,
freq, core_count);
}
@@ -116,6 +125,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
if (prev_cc != max_cores) {
prev->frequency = prev_freq;
prev->flags = CPUFREQ_BOOST_FREQ;
+ dev_pm_opp_add(cpu_dev, prev_freq * 1000, volt);
}
break;
@@ -127,6 +137,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
table[i].frequency = CPUFREQ_TABLE_END;
policy->freq_table = table;
+ dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
return 0;
}
@@ -159,10 +170,18 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy
*policy)
struct device *dev = _pdev->dev;
struct of_phandle_args args;
struct device_node *cpu_np;
+ struct device *cpu_dev;
struct resource *res;
void __iomem *base;
int ret, index;
+ cpu_dev = get_cpu_device(policy->cpu);
+ if (!cpu_dev) {
+ pr_err("%s: failed to get cpu%d device\n", __func__,
+ policy->cpu);
+ return -ENODEV;
+ }
+
cpu_np = of_cpu_device_node_get(policy->cpu);
if (!cpu_np)
return -EINVAL;
@@ -199,12 +218,18 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy
*policy)
policy->driver_data = base + REG_PERF_STATE;
- ret =
Re: [PATCH] input: misc: pwm-vibra: Prevent unbalanced regulator
Hi Paweł,
On Wed, Jan 16, 2019 at 10:11:31PM +0100, Paweł Chmiel wrote:
> From: Jonathan Bakker
>
> pwm_vibrator_stop disables the regulator, but it can be called from
> multiple places, even when the regulator is already disabled. Fix this
> by using regulator_is_enabled check when starting and stopping device.
>
> Signed-off-by: Jonathan Bakker
> Signed-off-by: Paweł Chmiel
> ---
> drivers/input/misc/pwm-vibra.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
> index 55da191ae550..66677ee770ca 100644
> --- a/drivers/input/misc/pwm-vibra.c
> +++ b/drivers/input/misc/pwm-vibra.c
> @@ -42,10 +42,12 @@ static int pwm_vibrator_start(struct pwm_vibrator
> *vibrator)
> struct pwm_state state;
> int err;
>
> - err = regulator_enable(vibrator->vcc);
> - if (err) {
> - dev_err(pdev, "failed to enable regulator: %d", err);
> - return err;
> + if (!regulator_is_enabled(vibrator->vcc)) {
I do not think this is correct in case of shared supply, as this checks
global state of regulator. That means that if there is another user, we
may forego enabling regulator here, and that anther user may power it
down and vibrator will stop working.
I think you need a local flag here.
> + err = regulator_enable(vibrator->vcc);
> + if (err) {
> + dev_err(pdev, "failed to enable regulator: %d", err);
> + return err;
> + }
> }
>
> pwm_get_state(vibrator->pwm, );
> @@ -76,7 +78,8 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
>
> static void pwm_vibrator_stop(struct pwm_vibrator *vibrator)
> {
> - regulator_disable(vibrator->vcc);
> + if (regulator_is_enabled(vibrator->vcc))
> + regulator_disable(vibrator->vcc);
Looking at this, I wonder if we should not disable PWMs first and the
disable regulator.
>
> if (vibrator->pwm_dir)
> pwm_disable(vibrator->pwm_dir);
> --
> 2.17.1
>
Thanks.
--
Dmitry
Re: [PATCH v2] cpufreq: qcom: Read voltage LUT and populate OPP
Hello Viresh,
On 1/9/2019 2:24 PM, Viresh Kumar wrote:
On 09-01-19, 13:37, Taniya Das wrote:
@@ -98,6 +107,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
You are only using this "dev" parameter for dev_dbg(), instead of that
pass cpu_dev pointer.
Sure, will clean it up to use cpu_dev.
table[i].frequency = CPUFREQ_ENTRY_INVALID;
} else {
table[i].frequency = freq;
+ dev_pm_opp_add(get_cpu_device(policy->cpu),
+ freq * 1000, volt);
dev_dbg(dev, "index=%d freq=%d, core_count %d\n", i,
freq, core_count);
}
@@ -116,6 +127,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
if (prev_cc != max_cores) {
prev->frequency = prev_freq;
prev->flags = CPUFREQ_BOOST_FREQ;
+ dev_pm_opp_add(get_cpu_device(policy->cpu),
+ prev_freq * 1000, volt);
}
break;
@@ -127,6 +140,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
table[i].frequency = CPUFREQ_TABLE_END;
policy->freq_table = table;
+ dev_pm_opp_set_sharing_cpus(get_cpu_device(policy->cpu), policy->cpus);
and then all the above sites can be simplified a bit.
return 0;
}
@@ -159,10 +173,18 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy
*policy)
struct device *dev = _pdev->dev;
struct of_phandle_args args;
struct device_node *cpu_np;
+ struct device *cpu_dev;
struct resource *res;
void __iomem *base;
int ret, index;
+ cpu_dev = get_cpu_device(policy->cpu);
+ if (!cpu_dev) {
+ pr_err("%s: failed to get cpu%d device\n", __func__,
+ policy->cpu);
+ return -ENODEV;
+ }
+
cpu_np = of_cpu_device_node_get(policy->cpu);
if (!cpu_np)
return -EINVAL;
@@ -205,6 +227,12 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy
*policy)
goto error;
}
+ ret = dev_pm_opp_get_opp_count(cpu_dev);
+ if (ret <= 0) {
+ dev_err(cpu_dev, "OPP table is not ready\n");
Rather say "Failed to add OPPs\n".
Sure will update it.
+ goto error;
+ }
+
policy->fast_switch_possible = true;
return 0;
@@ -217,6 +245,7 @@ static int qcom_cpufreq_hw_cpu_exit(struct cpufreq_policy
*policy)
{
void __iomem *base = policy->driver_data - REG_PERF_STATE;
+ dev_pm_opp_remove_all_dynamic(_pdev->dev);
This is platform device's device structure, while you added the OPPs
using cpu_dev. You sure this will work ?
Hmm, yeah, would update it in the next patch.
kfree(policy->freq_table);
devm_iounmap(_pdev->dev, base);
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
Re: [PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()
On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote:
> arch/csky/mm/highmem.c| 5 +
...
> diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
> index 53b1bfa..3317b774 100644
> --- a/arch/csky/mm/highmem.c
> +++ b/arch/csky/mm/highmem.c
> @@ -141,6 +141,11 @@ static void __init fixrange_init(unsigned long start,
> unsigned long end,
> for (; (k < PTRS_PER_PMD) && (vaddr != end); pmd++,
> k++) {
> if (pmd_none(*pmd)) {
> pte = (pte_t *)
> memblock_alloc_low(PAGE_SIZE, PAGE_SIZE);
> + if (!pte)
> + panic("%s: Failed to allocate
> %lu bytes align=%lx\n",
> + __func__, PAGE_SIZE,
> + PAGE_SIZE);
> +
> set_pmd(pmd, __pmd(__pa(pte)));
> BUG_ON(pte != pte_offset_kernel(pmd,
> 0));
> }
Looks good for me and panic is ok.
Reviewed-by: Guo Ren
[PATCH -next] remoteproc: qcom: remove duplicated include from qcom_sysmon.c
Remove duplicated include. Signed-off-by: YueHaibing --- drivers/remoteproc/qcom_sysmon.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c index e976a60..603b813 100644 --- a/drivers/remoteproc/qcom_sysmon.c +++ b/drivers/remoteproc/qcom_sysmon.c @@ -7,7 +7,6 @@ #include #include #include -#include #include #include #include -- 2.7.0
Re: [PATCH v2] cpufreq: qcom: Read voltage LUT and populate OPP
Thanks for the patch, would incorporate in the next patch series.
On 1/15/2019 5:59 AM, Matthias Kaehlcke wrote:
Hi Taniya,
On Wed, Jan 09, 2019 at 01:37:28PM +0530, Taniya Das wrote:
Add support to read the voltage look up table and populate OPP for all
corresponding CPUS for consumers like the energy model could use the
frequency and voltage from the OPP tables.
Tested-by: Matthias Kaehlcke
Signed-off-by: Taniya Das
---
drivers/cpufreq/qcom-cpufreq-hw.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
index d83939a..18f90bb 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -10,18 +10,21 @@
#include
#include
#include
+#include
#include
#define LUT_MAX_ENTRIES 40U
#define LUT_SRC GENMASK(31, 30)
#define LUT_L_VAL GENMASK(7, 0)
#define LUT_CORE_COUNTGENMASK(18, 16)
+#define LUT_VOLT GENMASK(11, 0)
#define LUT_ROW_SIZE 32
#define CLK_HW_DIV2
/* Register offsets */
#define REG_ENABLE0x0
-#define REG_LUT_TABLE 0x110
+#define REG_FREQ_LUT 0x110
+#define REG_VOLT_LUT 0x114
#define REG_PERF_STATE0x920
static unsigned long cpu_hw_rate, xo_rate;
@@ -75,6 +78,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
void __iomem *base)
{
u32 data, src, lval, i, core_count, prev_cc = 0, prev_freq = 0, freq;
+ u32 volt;
unsigned int max_cores = cpumask_weight(policy->cpus);
struct cpufreq_frequency_table *table;
@@ -83,11 +87,16 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
return -ENOMEM;
for (i = 0; i < LUT_MAX_ENTRIES; i++) {
- data = readl_relaxed(base + REG_LUT_TABLE + i * LUT_ROW_SIZE);
+ data = readl_relaxed(base + REG_FREQ_LUT +
+ i * LUT_ROW_SIZE);
src = FIELD_GET(LUT_SRC, data);
lval = FIELD_GET(LUT_L_VAL, data);
core_count = FIELD_GET(LUT_CORE_COUNT, data);
+ data = readl_relaxed(base + REG_VOLT_LUT +
+ i * LUT_ROW_SIZE);
+ volt = FIELD_GET(LUT_VOLT, data) * 1000;
+
if (src)
freq = xo_rate * lval / 1000;
else
@@ -98,6 +107,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
table[i].frequency = CPUFREQ_ENTRY_INVALID;
} else {
table[i].frequency = freq;
+ dev_pm_opp_add(get_cpu_device(policy->cpu),
+ freq * 1000, volt);
dev_dbg(dev, "index=%d freq=%d, core_count %d\n", i,
freq, core_count);
}
@@ -116,6 +127,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
if (prev_cc != max_cores) {
prev->frequency = prev_freq;
prev->flags = CPUFREQ_BOOST_FREQ;
+ dev_pm_opp_add(get_cpu_device(policy->cpu),
+ prev_freq * 1000, volt);
}
break;
@@ -127,6 +140,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
table[i].frequency = CPUFREQ_TABLE_END;
policy->freq_table = table;
+ dev_pm_opp_set_sharing_cpus(get_cpu_device(policy->cpu), policy->cpus);
return 0;
}
@@ -159,10 +173,18 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy
*policy)
struct device *dev = _pdev->dev;
struct of_phandle_args args;
struct device_node *cpu_np;
+ struct device *cpu_dev;
struct resource *res;
void __iomem *base;
int ret, index;
+ cpu_dev = get_cpu_device(policy->cpu);
+ if (!cpu_dev) {
+ pr_err("%s: failed to get cpu%d device\n", __func__,
+ policy->cpu);
+ return -ENODEV;
+ }
+
cpu_np = of_cpu_device_node_get(policy->cpu);
if (!cpu_np)
return -EINVAL;
@@ -205,6 +227,12 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy
*policy)
goto error;
}
+ ret = dev_pm_opp_get_opp_count(cpu_dev);
+ if (ret <= 0) {
+ dev_err(cpu_dev, "OPP table is not ready\n");
+ goto error;
+ }
+
policy->fast_switch_possible = true;
return 0;
@@ -217,6 +245,7 @@ static int qcom_cpufreq_hw_cpu_exit(struct cpufreq_policy
*policy)
{
void __iomem
[RFC PATCH 0/5] Add Xilinx's ZynqMP AES driver support
This patch set adds support for - dt-binding docs for Xilinx ZynqMP AES driver - Adds device tree node for ZynqMP SHA3 driver - Adds communication layer support for aes in zynqmp.c - Adds user space interface for ALG_SET_KEY_TYPE - Adds Xilinx ZynqMP driver for AES Algorithm Kalyani Akula (5): dt-bindings: crypto: Add bindings for ZynqMP AES driver ARM64: zynqmp: Add Xilinix AES node. firmware: xilinx: Add ZynqMP aes API for AES functionality crypto: Adds user space interface for ALG_SET_KEY_TYPE crypto: Add Xilinx AES driver .../devicetree/bindings/crypto/xlnx,zynqmp-aes.txt | 12 + arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 + crypto/af_alg.c| 7 + crypto/algif_skcipher.c| 7 + crypto/blkcipher.c | 9 + crypto/skcipher.c | 18 ++ drivers/crypto/Kconfig | 11 + drivers/crypto/Makefile| 1 + drivers/crypto/zynqmp-aes.c| 331 + drivers/firmware/xilinx/zynqmp.c | 24 ++ include/crypto/if_alg.h| 2 + include/crypto/skcipher.h | 10 + include/linux/crypto.h | 12 + include/linux/firmware/xlnx-zynqmp.h | 2 + include/uapi/linux/if_alg.h| 1 + 15 files changed, 451 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.txt create mode 100644 drivers/crypto/zynqmp-aes.c -- 1.9.5
[RFC PATCH 4/5] crypto: Adds user space interface for ALG_SET_KEY_TYPE
ALG_SET_KEY_TYPE requires caller to pass the key_type to be used
for AES encryption/decryption.
Sometimes the cipher key will be stored in the
device's hardware. So, there is a need to specify
the information about the key to use for AES operations.
In Xilinx ZynqMP SoC, below key types are available
1. Device key, which is flashed in the HW.
2. PUF KEK, which can be regenerated using the
helper data programmed in the HW.
3. User supplied key.
So to choose the AES key to be used, this patch adds key-type attribute.
Signed-off-by: Kalyani Akula
---
crypto/af_alg.c | 7 +++
crypto/algif_skcipher.c | 7 +++
crypto/blkcipher.c | 9 +
crypto/skcipher.c | 18 ++
include/crypto/if_alg.h | 2 ++
include/crypto/skcipher.h | 10 ++
include/linux/crypto.h | 12
include/uapi/linux/if_alg.h | 1 +
8 files changed, 66 insertions(+)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 17eb09d..c3c0660 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -261,6 +261,13 @@ static int alg_setsockopt(struct socket *sock, int level,
int optname,
if (!type->setauthsize)
goto unlock;
err = type->setauthsize(ask->private, optlen);
+ break;
+ case ALG_SET_KEY_TYPE:
+ if (sock->state == SS_CONNECTED)
+ goto unlock;
+ if (!type->setkeytype)
+ goto unlock;
+ err = type->setkeytype(ask->private, optval, optlen);
}
unlock:
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index cfdaab2..9911a56 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -320,6 +320,12 @@ static int skcipher_setkey(void *private, const u8 *key,
unsigned int keylen)
return crypto_skcipher_setkey(private, key, keylen);
}
+static int skcipher_setkeytype(void *private, const u8 *key,
+ unsigned int keylen)
+{
+ return crypto_skcipher_setkeytype(private, key, keylen);
+}
+
static void skcipher_sock_destruct(struct sock *sk)
{
struct alg_sock *ask = alg_sk(sk);
@@ -384,6 +390,7 @@ static int skcipher_accept_parent(void *private, struct
sock *sk)
.bind = skcipher_bind,
.release= skcipher_release,
.setkey = skcipher_setkey,
+ .setkeytype = skcipher_setkeytype,
.accept = skcipher_accept_parent,
.accept_nokey = skcipher_accept_parent_nokey,
.ops= _skcipher_ops,
diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index c5398bd..8922f58 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -408,6 +408,14 @@ static int setkey(struct crypto_tfm *tfm, const u8 *key,
unsigned int keylen)
return cipher->setkey(tfm, key, keylen);
}
+static int setkeytype(struct crypto_tfm *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct blkcipher_alg *cipher = >__crt_alg->cra_blkcipher;
+
+ return cipher->setkeytype(tfm, key, keylen);
+}
+
static int async_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
unsigned int keylen)
{
@@ -478,6 +486,7 @@ static int crypto_init_blkcipher_ops_sync(struct crypto_tfm
*tfm)
unsigned long addr;
crt->setkey = setkey;
+ crt->setkeytype = setkeytype;
crt->encrypt = alg->encrypt;
crt->decrypt = alg->decrypt;
diff --git a/crypto/skcipher.c b/crypto/skcipher.c
index 2a96929..6a2a0dd 100644
--- a/crypto/skcipher.c
+++ b/crypto/skcipher.c
@@ -605,6 +605,23 @@ static int skcipher_setkey_blkcipher(struct
crypto_skcipher *tfm,
return 0;
}
+static int skcipher_setkeytype_blkcipher(struct crypto_skcipher *tfm,
+const u8 *key, unsigned int keylen)
+{
+ struct crypto_blkcipher **ctx = crypto_skcipher_ctx(tfm);
+ struct crypto_blkcipher *blkcipher = *ctx;
+ int err;
+
+ crypto_blkcipher_clear_flags(blkcipher, ~0);
+ crypto_blkcipher_set_flags(blkcipher, crypto_skcipher_get_flags(tfm) &
+ CRYPTO_TFM_REQ_MASK);
+ err = crypto_blkcipher_setkeytype(blkcipher, key, keylen);
+ crypto_skcipher_set_flags(tfm, crypto_blkcipher_get_flags(blkcipher) &
+ CRYPTO_TFM_RES_MASK);
+
+ return err;
+}
+
static int skcipher_crypt_blkcipher(struct skcipher_request *req,
int (*crypt)(struct blkcipher_desc *,
struct scatterlist *,
@@ -671,6 +688,7 @@ static int crypto_init_skcipher_ops_blkcipher(struct
crypto_tfm *tfm)
tfm->exit = crypto_exit_skcipher_ops_blkcipher;
skcipher->setkey = skcipher_setkey_blkcipher;
+ skcipher->setkeytype = skcipher_setkeytype_blkcipher;
skcipher->encrypt =
[RFC PATCH 3/5] firmware: xilinx: Add ZynqMP aes API for AES functionality
Add ZynqMP firmware AES API to perform encryption/decryption
of given data.
Signed-off-by: Kalyani Akula
---
drivers/firmware/xilinx/zynqmp.c | 24
include/linux/firmware/xlnx-zynqmp.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 9a1c72a..332f98c1 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -469,6 +469,29 @@ static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32
arg1, u32 arg2,
arg1, arg2, out);
}
+/**
+ * zynqmp_pm_aes - Access AES hardware to encrypt/decrypt the data using
+ * AES-GCM core.
+ * @address: Address of the AesParams structure.
+ * @out: Returned output value
+ *
+ * Return: Returns status, either success or error code.
+ */
+static int zynqmp_pm_aes_engine(const u64 address, u32 *out)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!out)
+ return -EINVAL;
+
+ ret = zynqmp_pm_invoke_fn(PM_SECURE_AES, upper_32_bits(address),
+ lower_32_bits(address),
+ 0, 0, ret_payload);
+ *out = ret_payload[1];
+ return ret;
+}
+
static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -482,6 +505,7 @@ static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32
arg1, u32 arg2,
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
.ioctl = zynqmp_pm_ioctl,
+ .aes = zynqmp_pm_aes_engine,
};
/**
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 3c3c28e..815fa30 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -45,6 +45,7 @@ enum pm_api_id {
PM_CLOCK_GETRATE,
PM_CLOCK_SETPARENT,
PM_CLOCK_GETPARENT,
+ PM_SECURE_AES = 47,
};
/* PMU-FW return status codes */
@@ -102,6 +103,7 @@ struct zynqmp_eemi_ops {
int (*clock_setparent)(u32 clock_id, u32 parent_id);
int (*clock_getparent)(u32 clock_id, u32 *parent_id);
int (*ioctl)(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2, u32 *out);
+ int (*aes)(const u64 address, u32 *out);
};
#if IS_REACHABLE(CONFIG_ARCH_ZYNQMP)
--
1.9.5
[RFC PATCH 2/5] ARM64: zynqmp: Add Xilinix AES node.
This patch adds a AES DT node for Xilinx ZynqMP SoC.
Signed-off-by: Kalyani Akula
---
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index fa4fd77..a3e8332 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -124,6 +124,10 @@
<1 10 0xf08>;
};
+ xlnx_aes: zynqmp_aes {
+ compatible = "xlnx,zynqmp-aes";
+ };
+
amba_apu: amba-apu@0 {
compatible = "simple-bus";
#address-cells = <2>;
--
1.9.5
[RFC PATCH 5/5] crypto: Add Xilinx AES driver
This patch adds AES driver support for the Xilinx
ZynqMP SoC.
Signed-off-by: Kalyani Akula
---
drivers/crypto/Kconfig | 11 ++
drivers/crypto/Makefile | 1 +
drivers/crypto/zynqmp-aes.c | 331
3 files changed, 343 insertions(+)
create mode 100644 drivers/crypto/zynqmp-aes.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 5a90075..66d9faa 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -667,6 +667,17 @@ config CRYPTO_DEV_ROCKCHIP
This driver interfaces with the hardware crypto accelerator.
Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
+config CRYPTO_DEV_ZYNQMP_AES
+ tristate "Support for Xilinx ZynqMP AES hw accelerator"
+ depends on ARCH_ZYNQMP || COMPILE_TEST
+ select CRYPTO_AES
+ select CRYPTO_BLKCIPHER
+ help
+ Xilinx ZynqMP has AES-GCM engine used for symmetric key
+ encryption and decryption. This driver interfaces with AES hw
+ accelerator. Select this if you want to use the ZynqMP module
+ for AES algorithms.
+
config CRYPTO_DEV_MEDIATEK
tristate "MediaTek's EIP97 Cryptographic Engine driver"
depends on (ARM && ARCH_MEDIATEK) || COMPILE_TEST
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 8e7e225..991b343 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -47,3 +47,4 @@ obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) += bcm/
obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += inside-secure/
obj-$(CONFIG_CRYPTO_DEV_ARTPEC6) += axis/
obj-y += hisilicon/
+obj-$(CONFIG_CRYPTO_DEV_ZYNQMP_AES) += zynqmp-aes.o
diff --git a/drivers/crypto/zynqmp-aes.c b/drivers/crypto/zynqmp-aes.c
new file mode 100644
index 000..3a38d2d
--- /dev/null
+++ b/drivers/crypto/zynqmp-aes.c
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx ZynqMP AES Driver.
+ * Copyright (c) 2018 Xilinx Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ZYNQMP_AES_QUEUE_LENGTH1
+#define ZYNQMP_AES_IV_SIZE 12
+#define ZYNQMP_AES_GCM_SIZE16
+#define ZYNQMP_AES_KEY_SIZE32
+
+#define ZYNQMP_AES_DECRYPT 0
+#define ZYNQMP_AES_ENCRYPT 1
+
+#define ZYNQMP_AES_KUP_KEY 0
+
+#define ZYNQMP_AES_GCM_TAG_MISMATCH_ERR0x01
+#define ZYNQMP_AES_SIZE_ERR0x06
+#define ZYNQMP_AES_WRONG_KEY_SRC_ERR 0x13
+#define ZYNQMP_AES_PUF_NOT_PROGRAMMED 0xE300
+
+#define ZYNQMP_AES_BLOCKSIZE 0x04
+
+struct zynqmp_aes_dev {
+ struct list_head list;
+ struct device *dev;
+ /* the lock protects queue and dev list */
+ spinlock_t lock;
+ struct crypto_queue queue;
+};
+
+struct zynqmp_aes_op {
+ struct zynqmp_aes_dev *dd;
+ void *src;
+ void *dst;
+ int len;
+ u8 key[ZYNQMP_AES_KEY_SIZE];
+ u8 *iv;
+ u32 keylen;
+ u32 keytype;
+};
+
+struct zynqmp_aes_data {
+ u64 src;
+ u64 iv;
+ u64 key;
+ u64 dst;
+ u64 size;
+ u64 optype;
+ u64 keysrc;
+};
+
+struct zynqmp_aes_drv {
+ struct list_head dev_list;
+ /* the lock protects dev list */
+ spinlock_t lock;
+};
+
+static struct zynqmp_aes_drv zynqmp_aes = {
+ .dev_list = LIST_HEAD_INIT(zynqmp_aes.dev_list),
+ .lock = __SPIN_LOCK_UNLOCKED(zynqmp_aes.lock),
+};
+
+static struct zynqmp_aes_dev *zynqmp_aes_find_dev(struct zynqmp_aes_op *ctx)
+{
+ struct zynqmp_aes_dev *aes_dd = NULL;
+ struct zynqmp_aes_dev *tmp;
+
+ spin_lock_bh(_aes.lock);
+ if (!ctx->dd) {
+ list_for_each_entry(tmp, _aes.dev_list, list) {
+ aes_dd = tmp;
+ break;
+ }
+ ctx->dd = aes_dd;
+ } else {
+ aes_dd = ctx->dd;
+ }
+ spin_unlock_bh(_aes.lock);
+
+ return aes_dd;
+}
+
+static int zynqmp_setkey_blk(struct crypto_tfm *tfm, const u8 *key,
+unsigned int len)
+{
+ struct zynqmp_aes_op *op = crypto_tfm_ctx(tfm);
+
+ op->keylen = len;
+ memcpy(op->key, key, len);
+
+ return 0;
+}
+
+static int zynqmp_setkeytype(struct crypto_tfm *tfm, const u8 *keytype,
+unsigned int len)
+{
+ struct zynqmp_aes_op *op = crypto_tfm_ctx(tfm);
+
+ op->keytype = (u32)(*keytype);
+
+ return 0;
+}
+
+static int zynqmp_aes_xcrypt(struct blkcipher_desc *desc,
+struct scatterlist *dst,
+struct scatterlist *src,
+unsigned int nbytes,
+unsigned int flags)
+{
+ struct zynqmp_aes_op *op = crypto_blkcipher_ctx(desc->tfm);
+ struct zynqmp_aes_dev *dd =
[RFC PATCH 1/5] dt-bindings: crypto: Add bindings for ZynqMP AES driver
Add documentation to describe Xilinx ZynqMP AES driver
bindings.
Signed-off-by: Kalyani Akula
---
Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.txt | 12
1 file changed, 12 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.txt
diff --git a/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.txt
b/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.txt
new file mode 100644
index 000..226bfb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.txt
@@ -0,0 +1,12 @@
+Xilinx ZynqMP AES hw acceleration support
+
+The ZynqMP PS-AES hw accelerator is used to encrypt/decrypt
+the given user data.
+
+Required properties:
+- compatible: should contain "xlnx,zynqmp-aes"
+
+Example:
+ zynqmp_aes {
+ compatible = "xlnx,zynqmp-aes";
+ };
--
1.9.5
[PATCH -next] xfs: remove duplicated xfs_defer.h
Remove duplicated include. Signed-off-by: YueHaibing --- fs/xfs/xfs_trans_bmap.c | 1 - fs/xfs/xfs_trans_extfree.c | 1 - fs/xfs/xfs_trans_refcount.c | 1 - fs/xfs/xfs_trans_rmap.c | 1 - 4 files changed, 4 deletions(-) diff --git a/fs/xfs/xfs_trans_bmap.c b/fs/xfs/xfs_trans_bmap.c index 11cff44..e1c7d55 100644 --- a/fs/xfs/xfs_trans_bmap.c +++ b/fs/xfs/xfs_trans_bmap.c @@ -17,7 +17,6 @@ #include "xfs_alloc.h" #include "xfs_bmap.h" #include "xfs_inode.h" -#include "xfs_defer.h" /* * This routine is called to allocate a "bmap update done" diff --git a/fs/xfs/xfs_trans_extfree.c b/fs/xfs/xfs_trans_extfree.c index 0710434..8ee7a3f 100644 --- a/fs/xfs/xfs_trans_extfree.c +++ b/fs/xfs/xfs_trans_extfree.c @@ -18,7 +18,6 @@ #include "xfs_alloc.h" #include "xfs_bmap.h" #include "xfs_trace.h" -#include "xfs_defer.h" /* * This routine is called to allocate an "extent free done" diff --git a/fs/xfs/xfs_trans_refcount.c b/fs/xfs/xfs_trans_refcount.c index 6c947ff..8d73472 100644 --- a/fs/xfs/xfs_trans_refcount.c +++ b/fs/xfs/xfs_trans_refcount.c @@ -16,7 +16,6 @@ #include "xfs_refcount_item.h" #include "xfs_alloc.h" #include "xfs_refcount.h" -#include "xfs_defer.h" /* * This routine is called to allocate a "refcount update done" diff --git a/fs/xfs/xfs_trans_rmap.c b/fs/xfs/xfs_trans_rmap.c index a428909..5c7936b 100644 --- a/fs/xfs/xfs_trans_rmap.c +++ b/fs/xfs/xfs_trans_rmap.c @@ -16,7 +16,6 @@ #include "xfs_rmap_item.h" #include "xfs_alloc.h" #include "xfs_rmap.h" -#include "xfs_defer.h" /* Set the map extent flags for this reverse mapping. */ static void -- 2.7.0
RE: [PATCH v3 1/2] dt-bindings: usb: ci-hdrc-usb2: add property power-active-high
> > The i.MX6q/dl USB controller may drive the usb power line directly, but the > polarity > depends on the board. Reset state of the polarity is low-active so add this > property > to allow it to be high-active. > As far as I know, most of i.mx USB controllers (except imx28/23, but they don't have non-core registers) work like this, and most of them are low active for PP default. Would you just use "i.mx" at both your code and your comment? Peter > Signed-off-by: Philipp Puschmann > --- > Changes in v3: add description > --- > Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt > b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt > index adae82385dd6..8696e3eff6e7 100644 > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt > @@ -93,6 +93,7 @@ i.mx specific properties > - over-current-active-low: over current signal polarity is active low. > - over-current-active-high: over current signal polarity is active high. >It's recommended to specify the over current polarity. > +- power-active-high: power signal polarity is high active (only for > +imx6q/dl) > - external-vbus-divider: enables off-chip resistor divider for Vbus > > Example: > -- > 2.20.1
[PATCH] iwlwifi: mvm: remove duplicated include from ops.c
Remove duplicated include. Signed-off-by: YueHaibing --- drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c index 30c5127..2e5621c 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c @@ -82,7 +82,6 @@ #include "fw/api/scan.h" #include "time-event.h" #include "fw-api.h" -#include "fw/api/scan.h" #include "fw/acpi.h" #define DRV_DESCRIPTION"The new Intel(R) wireless AGN driver for Linux" -- 2.7.0
[PATCH] iio: light: add driver support for MAX44009
The MAX44009 is a low-power ambient light sensor from Maxim Integrated.
It differs from the MAX44000 in that it doesn't have proximity sensing and that
it requires far less current (1 micro-amp vs 5 micro-amps). The register
mapping and feature set between the two are different enough to require a new
driver for the MAX44009.
Developed and tested with a BeagleBone Black and UDOO Neo (i.MX6SX)
Supported features:
* Rising and falling illuminance threshold
events
* Illuminance triggered buffers
* Integration time
https://datasheets.maximintegrated.com/en/ds/MAX44009.pdf
Signed-off-by: Robert Eshleman
---
.../bindings/iio/light/max44009.txt | 25 +
drivers/iio/light/Kconfig | 13 +
drivers/iio/light/Makefile| 1 +
drivers/iio/light/max44009.c | 696 ++
4 files changed, 735 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/max44009.txt
create mode 100644 drivers/iio/light/max44009.c
diff --git a/Documentation/devicetree/bindings/iio/light/max44009.txt
b/Documentation/devicetree/bindings/iio/light/max44009.txt
new file mode 100644
index ..220c2808dca1
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/max44009.txt
@@ -0,0 +1,25 @@
+* MAX44009 Ambient Light Sensor
+
+Required properties:
+
+- compatible: should be "maxim,max44009"
+- reg: the I2C address of the device (default is <0x4a>)
+
+Optional properties:
+
+- interrupts : interrupt mapping for GPIO IRQ. Should be configured with
+ IRQ_TYPE_EDGE_FALLING.
+
+Refer to interrupt-controller/interrupts.txt for generic interrupt client
+node bindings.
+
+Example:
+
+max44009: max44009@4a {
+ compatible = "maxim,max44009";
+ reg = <0x4a>;
+
+ interrupt-parent = <>;
+ interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
+};
+
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 36f458433480..cda544f1047d 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -299,6 +299,19 @@ config MAX44000
To compile this driver as a module, choose M here:
the module will be called max44000.
+config MAX44009
+ tristate "MAX44009 Ambient Light Sensor"
+ depends on I2C
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ select IIO_TRIGGERED_EVENT
+ help
+Say Y here if you want to build support for Maxim Integrated's
+MAX44009 ambient light sensor device.
+
+To compile this driver as a module, choose M here:
+the module will be called max44009.
+
config OPT3001
tristate "Texas Instruments OPT3001 Light Sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 286bf3975372..e40794fbb435 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_SENSORS_LM3533) += lm3533-als.o
obj-$(CONFIG_LTR501) += ltr501.o
obj-$(CONFIG_LV0104CS) += lv0104cs.o
obj-$(CONFIG_MAX44000) += max44000.o
+obj-$(CONFIG_MAX44009) += max44009.o
obj-$(CONFIG_OPT3001) += opt3001.o
obj-$(CONFIG_PA12203001) += pa12203001.o
obj-$(CONFIG_RPR0521) += rpr0521.o
diff --git a/drivers/iio/light/max44009.c b/drivers/iio/light/max44009.c
new file mode 100644
index ..e15aa8eeb2f6
--- /dev/null
+++ b/drivers/iio/light/max44009.c
@@ -0,0 +1,696 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * max44009.c - Support for MAX44009 Ambient Light Sensor
+ *
+ * Copyright (c) 2019 Robert Eshleman
+ *
+ * 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.
+ *
+ *
+ * Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX44009.pdf
+ *
+ * TODO: Support continuous mode and processed event value (IIO_EV_INFO_VALUE)
+ *
+ * Default I2C address: 0x4a
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAX44009_DRV_NAME "max44009"
+#define MAX44009_IRQ_NAME "max44009_event"
+
+/* Registers in datasheet order */
+#define MAX44009_REG_STATUS 0x0
+#define MAX44009_REG_ENABLE 0x1
+#define MAX44009_REG_CFG 0x2
+#define MAX44009_REG_LUX_HI 0x3
+#define MAX44009_REG_LUX_LO 0x4
+#define MAX44009_REG_UPPER_THR 0x5
+#define MAX44009_REG_LOWER_THR 0x6
+#define MAX44009_REG_THR_TIMER 0x7
+
+#define MAX44009_INT_TIME_MASK (BIT(2) | BIT(1) | BIT(0))
+#define MAX44009_INT_TIME_SHIFT (0)
+
+#define MAX44009_MANUAL_MODE_MASK BIT(6)
+
+/* The maxmimum raw rising threshold for the max44009 */
+#define MAX44009_MAXIMUM_THRESHOLD 8355840
+
+#define MAX44009_HI_NIBBLE(reg) (((reg) >> 4) & 0xf)
+#define MAX44009_LO_NIBBLE(reg) ((reg) & 0xf)
+
+#define MAX44009_EXP_MASK 0xf00
+#define MAX44009_EXP_RSHIFT 8
+#define
Re: [PATCH 05/13] clk: qcom: apcs-msm8916: get parent clock names from DT
On Mon 31 Dec 00:42 PST 2018, Jorge Ramirez wrote: [..] > I am not completely sure of what you mean. are you saying that the original > patch is good and we should just provide another patch (not part of the > current patch series) to remove the compatibility? > You're expected to make sure that db410c continues to function on existing DTBs, at least for a considerable amount of time. Regards, Bjorn
Re: [PATCH 09/17] x86/kprobes: Instruction pages initialization enhancements
On Wed, 16 Jan 2019 16:32:51 -0800
Rick Edgecombe wrote:
> From: Nadav Amit
>
> This patch is a preparatory patch for a following patch that makes
> module allocated pages non-executable. The patch sets the page as
> executable after allocation.
>
> In the future, we may get better protection of executables. For example,
> by using hypercalls to request the hypervisor to protect VM executable
> pages from modifications using nested page-tables. This would allow
> us to ensure the executable has not changed between allocation and
> its write-protection.
>
> While at it, do some small cleanup of what appears to be unnecessary
> masking.
>
OK, then this should be done.
Acked-by: Masami Hiramatsu
Thank you!
> Cc: Masami Hiramatsu
> Signed-off-by: Nadav Amit
> Signed-off-by: Rick Edgecombe
> ---
> arch/x86/kernel/kprobes/core.c | 24
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 4ba75afba527..fac692e36833 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -431,8 +431,20 @@ void *alloc_insn_page(void)
> void *page;
>
> page = module_alloc(PAGE_SIZE);
> - if (page)
> - set_memory_ro((unsigned long)page & PAGE_MASK, 1);
> + if (page == NULL)
> + return NULL;
> +
> + /*
> + * First make the page read-only, and then only then make it executable
> + * to prevent it from being W+X in between.
> + */
> + set_memory_ro((unsigned long)page, 1);
> +
> + /*
> + * TODO: Once additional kernel code protection mechanisms are set,
> ensure
> + * that the page was not maliciously altered and it is still zeroed.
> + */
> + set_memory_x((unsigned long)page, 1);
>
> return page;
> }
> @@ -440,8 +452,12 @@ void *alloc_insn_page(void)
> /* Recover page to RW mode before releasing it */
> void free_insn_page(void *page)
> {
> - set_memory_nx((unsigned long)page & PAGE_MASK, 1);
> - set_memory_rw((unsigned long)page & PAGE_MASK, 1);
> + /*
> + * First make the page non-executable, and then only then make it
> + * writable to prevent it from being W+X in between.
> + */
> + set_memory_nx((unsigned long)page, 1);
> + set_memory_rw((unsigned long)page, 1);
> module_memfree(page);
> }
>
> --
> 2.17.1
>
--
Masami Hiramatsu
[PATCH V2 4/5] crypto: ctr - use template array registering API to simplify the code
Use crypto template array registering API to simplify the code.
Signed-off-by: Xiongfeng Wang
---
crypto/ctr.c | 43 +++
1 file changed, 15 insertions(+), 28 deletions(-)
diff --git a/crypto/ctr.c b/crypto/ctr.c
index 4c743a9..d9f9d65 100644
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@ -171,12 +171,6 @@ static int crypto_ctr_create(struct crypto_template *tmpl,
struct rtattr **tb)
return err;
}
-static struct crypto_template crypto_ctr_tmpl = {
- .name = "ctr",
- .create = crypto_ctr_create,
- .module = THIS_MODULE,
-};
-
static int crypto_rfc3686_setkey(struct crypto_skcipher *parent,
const u8 *key, unsigned int keylen)
{
@@ -366,36 +360,29 @@ static int crypto_rfc3686_create(struct crypto_template
*tmpl,
goto out;
}
-static struct crypto_template crypto_rfc3686_tmpl = {
- .name = "rfc3686",
- .create = crypto_rfc3686_create,
- .module = THIS_MODULE,
+static struct crypto_template crypto_ctr_tmpls[] = {
+ {
+ .name = "ctr",
+ .create = crypto_ctr_create,
+ .module = THIS_MODULE,
+ }, {
+ .name = "rfc3686",
+ .create = crypto_rfc3686_create,
+ .module = THIS_MODULE,
+ },
};
+
static int __init crypto_ctr_module_init(void)
{
- int err;
-
- err = crypto_register_template(_ctr_tmpl);
- if (err)
- goto out;
-
- err = crypto_register_template(_rfc3686_tmpl);
- if (err)
- goto out_drop_ctr;
-
-out:
- return err;
-
-out_drop_ctr:
- crypto_unregister_template(_ctr_tmpl);
- goto out;
+ return crypto_register_templates(crypto_ctr_tmpls,
+ARRAY_SIZE(crypto_ctr_tmpls));
}
static void __exit crypto_ctr_module_exit(void)
{
- crypto_unregister_template(_rfc3686_tmpl);
- crypto_unregister_template(_ctr_tmpl);
+ crypto_unregister_templates(crypto_ctr_tmpls,
+ ARRAY_SIZE(crypto_ctr_tmpls));
}
module_init(crypto_ctr_module_init);
--
1.7.12.4
[PATCH V2 3/5] crypto: gcm - use template array registering API to simplify the code
Use crypto template array registering API to simplify the code.
Signed-off-by: Xiongfeng Wang
---
crypto/gcm.c | 73 +++-
1 file changed, 23 insertions(+), 50 deletions(-)
diff --git a/crypto/gcm.c b/crypto/gcm.c
index e438492..31eb694 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -727,12 +727,6 @@ static int crypto_gcm_create(struct crypto_template *tmpl,
struct rtattr **tb)
ctr_name, "ghash");
}
-static struct crypto_template crypto_gcm_tmpl = {
- .name = "gcm",
- .create = crypto_gcm_create,
- .module = THIS_MODULE,
-};
-
static int crypto_gcm_base_create(struct crypto_template *tmpl,
struct rtattr **tb)
{
@@ -756,12 +750,6 @@ static int crypto_gcm_base_create(struct crypto_template
*tmpl,
ctr_name, ghash_name);
}
-static struct crypto_template crypto_gcm_base_tmpl = {
- .name = "gcm_base",
- .create = crypto_gcm_base_create,
- .module = THIS_MODULE,
-};
-
static int crypto_rfc4106_setkey(struct crypto_aead *parent, const u8 *key,
unsigned int keylen)
{
@@ -989,12 +977,6 @@ static int crypto_rfc4106_create(struct crypto_template
*tmpl,
goto out;
}
-static struct crypto_template crypto_rfc4106_tmpl = {
- .name = "rfc4106",
- .create = crypto_rfc4106_create,
- .module = THIS_MODULE,
-};
-
static int crypto_rfc4543_setkey(struct crypto_aead *parent, const u8 *key,
unsigned int keylen)
{
@@ -1231,10 +1213,24 @@ static int crypto_rfc4543_create(struct crypto_template
*tmpl,
goto out;
}
-static struct crypto_template crypto_rfc4543_tmpl = {
- .name = "rfc4543",
- .create = crypto_rfc4543_create,
- .module = THIS_MODULE,
+static struct crypto_template crypto_gcm_tmpls[] = {
+ {
+ .name = "gcm_base",
+ .create = crypto_gcm_base_create,
+ .module = THIS_MODULE,
+ }, {
+ .name = "gcm",
+ .create = crypto_gcm_create,
+ .module = THIS_MODULE,
+ }, {
+ .name = "rfc4106",
+ .create = crypto_rfc4106_create,
+ .module = THIS_MODULE,
+ }, {
+ .name = "rfc4543",
+ .create = crypto_rfc4543_create,
+ .module = THIS_MODULE,
+ },
};
static int __init crypto_gcm_module_init(void)
@@ -1247,42 +1243,19 @@ static int __init crypto_gcm_module_init(void)
sg_init_one(_zeroes->sg, gcm_zeroes->buf, sizeof(gcm_zeroes->buf));
- err = crypto_register_template(_gcm_base_tmpl);
- if (err)
- goto out;
-
- err = crypto_register_template(_gcm_tmpl);
+ err = crypto_register_templates(crypto_gcm_tmpls,
+ ARRAY_SIZE(crypto_gcm_tmpls));
if (err)
- goto out_undo_base;
+ kfree(gcm_zeroes);
- err = crypto_register_template(_rfc4106_tmpl);
- if (err)
- goto out_undo_gcm;
-
- err = crypto_register_template(_rfc4543_tmpl);
- if (err)
- goto out_undo_rfc4106;
-
- return 0;
-
-out_undo_rfc4106:
- crypto_unregister_template(_rfc4106_tmpl);
-out_undo_gcm:
- crypto_unregister_template(_gcm_tmpl);
-out_undo_base:
- crypto_unregister_template(_gcm_base_tmpl);
-out:
- kfree(gcm_zeroes);
return err;
}
static void __exit crypto_gcm_module_exit(void)
{
kfree(gcm_zeroes);
- crypto_unregister_template(_rfc4543_tmpl);
- crypto_unregister_template(_rfc4106_tmpl);
- crypto_unregister_template(_gcm_tmpl);
- crypto_unregister_template(_gcm_base_tmpl);
+ crypto_unregister_templates(crypto_gcm_tmpls,
+ ARRAY_SIZE(crypto_gcm_tmpls));
}
module_init(crypto_gcm_module_init);
--
1.7.12.4
[PATCH V2 5/5] crypto: chacha20poly1305 - use template array registering API to simplify the code
Use crypto template array registering API to simplify the code.
Signed-off-by: Xiongfeng Wang
---
crypto/chacha20poly1305.c | 37 ++---
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/crypto/chacha20poly1305.c b/crypto/chacha20poly1305.c
index fef1144..ed2e12e 100644
--- a/crypto/chacha20poly1305.c
+++ b/crypto/chacha20poly1305.c
@@ -701,37 +701,28 @@ static int rfc7539esp_create(struct crypto_template
*tmpl, struct rtattr **tb)
return chachapoly_create(tmpl, tb, "rfc7539esp", 8);
}
-static struct crypto_template rfc7539_tmpl = {
- .name = "rfc7539",
- .create = rfc7539_create,
- .module = THIS_MODULE,
-};
-
-static struct crypto_template rfc7539esp_tmpl = {
- .name = "rfc7539esp",
- .create = rfc7539esp_create,
- .module = THIS_MODULE,
+static struct crypto_template rfc7539_tmpls[] = {
+ {
+ .name = "rfc7539",
+ .create = rfc7539_create,
+ .module = THIS_MODULE,
+ }, {
+ .name = "rfc7539esp",
+ .create = rfc7539esp_create,
+ .module = THIS_MODULE,
+ },
};
static int __init chacha20poly1305_module_init(void)
{
- int err;
-
- err = crypto_register_template(_tmpl);
- if (err)
- return err;
-
- err = crypto_register_template(_tmpl);
- if (err)
- crypto_unregister_template(_tmpl);
-
- return err;
+ return crypto_register_templates(rfc7539_tmpls,
+ARRAY_SIZE(rfc7539_tmpls));
}
static void __exit chacha20poly1305_module_exit(void)
{
- crypto_unregister_template(_tmpl);
- crypto_unregister_template(_tmpl);
+ crypto_unregister_templates(rfc7539_tmpls,
+ ARRAY_SIZE(rfc7539_tmpls));
}
module_init(chacha20poly1305_module_init);
--
1.7.12.4
[PATCH V2 2/5] crypto: ccm - use template array registering API to simplify the code
Use crypto template array registering API to simplify the code.
Signed-off-by: Xiongfeng Wang
---
crypto/ccm.c | 78 ++--
1 file changed, 23 insertions(+), 55 deletions(-)
diff --git a/crypto/ccm.c b/crypto/ccm.c
index b242fd0..50df8f0 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -589,12 +589,6 @@ static int crypto_ccm_create(struct crypto_template *tmpl,
struct rtattr **tb)
mac_name);
}
-static struct crypto_template crypto_ccm_tmpl = {
- .name = "ccm",
- .create = crypto_ccm_create,
- .module = THIS_MODULE,
-};
-
static int crypto_ccm_base_create(struct crypto_template *tmpl,
struct rtattr **tb)
{
@@ -618,12 +612,6 @@ static int crypto_ccm_base_create(struct crypto_template
*tmpl,
cipher_name);
}
-static struct crypto_template crypto_ccm_base_tmpl = {
- .name = "ccm_base",
- .create = crypto_ccm_base_create,
- .module = THIS_MODULE,
-};
-
static int crypto_rfc4309_setkey(struct crypto_aead *parent, const u8 *key,
unsigned int keylen)
{
@@ -854,12 +842,6 @@ static int crypto_rfc4309_create(struct crypto_template
*tmpl,
goto out;
}
-static struct crypto_template crypto_rfc4309_tmpl = {
- .name = "rfc4309",
- .create = crypto_rfc4309_create,
- .module = THIS_MODULE,
-};
-
static int crypto_cbcmac_digest_setkey(struct crypto_shash *parent,
const u8 *inkey, unsigned int keylen)
{
@@ -999,51 +981,37 @@ static int cbcmac_create(struct crypto_template *tmpl,
struct rtattr **tb)
return err;
}
-static struct crypto_template crypto_cbcmac_tmpl = {
- .name = "cbcmac",
- .create = cbcmac_create,
- .free = shash_free_instance,
- .module = THIS_MODULE,
+static struct crypto_template crypto_ccm_tmpls[] = {
+ {
+ .name = "cbcmac",
+ .create = cbcmac_create,
+ .free = shash_free_instance,
+ .module = THIS_MODULE,
+ }, {
+ .name = "ccm_base",
+ .create = crypto_ccm_base_create,
+ .module = THIS_MODULE,
+ }, {
+ .name = "ccm",
+ .create = crypto_ccm_create,
+ .module = THIS_MODULE,
+ }, {
+ .name = "rfc4309",
+ .create = crypto_rfc4309_create,
+ .module = THIS_MODULE,
+ },
};
static int __init crypto_ccm_module_init(void)
{
- int err;
-
- err = crypto_register_template(_cbcmac_tmpl);
- if (err)
- goto out;
-
- err = crypto_register_template(_ccm_base_tmpl);
- if (err)
- goto out_undo_cbcmac;
-
- err = crypto_register_template(_ccm_tmpl);
- if (err)
- goto out_undo_base;
-
- err = crypto_register_template(_rfc4309_tmpl);
- if (err)
- goto out_undo_ccm;
-
-out:
- return err;
-
-out_undo_ccm:
- crypto_unregister_template(_ccm_tmpl);
-out_undo_base:
- crypto_unregister_template(_ccm_base_tmpl);
-out_undo_cbcmac:
- crypto_register_template(_cbcmac_tmpl);
- goto out;
+ return crypto_register_templates(crypto_ccm_tmpls,
+ARRAY_SIZE(crypto_ccm_tmpls));
}
static void __exit crypto_ccm_module_exit(void)
{
- crypto_unregister_template(_rfc4309_tmpl);
- crypto_unregister_template(_ccm_tmpl);
- crypto_unregister_template(_ccm_base_tmpl);
- crypto_unregister_template(_cbcmac_tmpl);
+ crypto_unregister_templates(crypto_ccm_tmpls,
+ ARRAY_SIZE(crypto_ccm_tmpls));
}
module_init(crypto_ccm_module_init);
--
1.7.12.4
[PATCH V2 1/5] crypto: api - add a helper to (un)register a array of templates
This patch add a helper to (un)register a array of templates. The
following patches will use this helper to simplify the code.
Signed-off-by: Xiongfeng Wang
---
crypto/algapi.c | 27 +++
include/crypto/algapi.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 713baab..4c9c86b 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -494,6 +494,24 @@ int crypto_register_template(struct crypto_template *tmpl)
}
EXPORT_SYMBOL_GPL(crypto_register_template);
+int crypto_register_templates(struct crypto_template *tmpls, int count)
+{
+ int i, err;
+
+ for (i = 0; i < count; i++) {
+ err = crypto_register_template([i]);
+ if (err)
+ goto out;
+ }
+ return 0;
+
+out:
+ for (--i; i >= 0; --i)
+ crypto_unregister_template([i]);
+ return err;
+}
+EXPORT_SYMBOL_GPL(crypto_register_templates);
+
void crypto_unregister_template(struct crypto_template *tmpl)
{
struct crypto_instance *inst;
@@ -523,6 +541,15 @@ void crypto_unregister_template(struct crypto_template
*tmpl)
}
EXPORT_SYMBOL_GPL(crypto_unregister_template);
+void crypto_unregister_templates(struct crypto_template *tmpls, int count)
+{
+ int i;
+
+ for (i = count - 1; i >= 0; --i)
+ crypto_unregister_template([i]);
+}
+EXPORT_SYMBOL_GPL(crypto_unregister_templates);
+
static struct crypto_template *__crypto_lookup_template(const char *name)
{
struct crypto_template *q, *tmpl = NULL;
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index 093869f..4be38cd 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -143,7 +143,9 @@ struct ablkcipher_walk {
void crypto_mod_put(struct crypto_alg *alg);
int crypto_register_template(struct crypto_template *tmpl);
+int crypto_register_templates(struct crypto_template *tmpls, int count);
void crypto_unregister_template(struct crypto_template *tmpl);
+void crypto_unregister_templates(struct crypto_template *tmpls, int count);
struct crypto_template *crypto_lookup_template(const char *name);
int crypto_register_instance(struct crypto_template *tmpl,
--
1.7.12.4
[PATCH V2 0/5] Crypto Cleanup
The patchset introduce a helper to (un)register a array of crypto templates. The following patches use this helper to simplify the code. This is also a preparation for a coming patchset, which will register several crypto templates. Changelog: v1 -> v2: rebased to cryptodev, fix some format issue Xiongfeng Wang (5): crypto: api - add a helper to (un)register a array of templates crypto: ccm - use template array registering API to simplify the code crypto: gcm - use template array registering API to simplify the code crypto: ctr - use template array registering API to simplify the code crypto: chacha20poly1305 - use template array registering API to simplify the code crypto/algapi.c | 27 crypto/ccm.c | 78 ++- crypto/chacha20poly1305.c | 37 +- crypto/ctr.c | 43 +- crypto/gcm.c | 73 ++-- include/crypto/algapi.h | 2 ++ 6 files changed, 104 insertions(+), 156 deletions(-) -- 1.7.12.4
Re: [PATCH 01/17] Fix "x86/alternatives: Lockdep-enforce text_mutex in text_poke*()"
On Wed, 16 Jan 2019 16:32:43 -0800
Rick Edgecombe wrote:
> From: Nadav Amit
>
> text_mutex is currently expected to be held before text_poke() is
> called, but we kgdb does not take the mutex, and instead *supposedly*
> ensures the lock is not taken and will not be acquired by any other core
> while text_poke() is running.
>
> The reason for the "supposedly" comment is that it is not entirely clear
> that this would be the case if gdb_do_roundup is zero.
>
> This patch creates two wrapper functions, text_poke() and
> text_poke_kgdb() which do or do not run the lockdep assertion
> respectively.
>
> While we are at it, change the return code of text_poke() to something
> meaningful. One day, callers might actually respect it and the existing
> BUG_ON() when patching fails could be removed. For kgdb, the return
> value can actually be used.
Looks good to me.
Reviewed-by: Masami Hiramatsu
Thank you,
>
> Cc: Andy Lutomirski
> Cc: Kees Cook
> Cc: Dave Hansen
> Cc: Masami Hiramatsu
> Fixes: 9222f606506c ("x86/alternatives: Lockdep-enforce text_mutex in
> text_poke*()")
> Suggested-by: Peter Zijlstra
> Acked-by: Jiri Kosina
> Signed-off-by: Nadav Amit
> Signed-off-by: Rick Edgecombe
> ---
> arch/x86/include/asm/text-patching.h | 1 +
> arch/x86/kernel/alternative.c| 52
> arch/x86/kernel/kgdb.c | 11 +++---
> 3 files changed, 45 insertions(+), 19 deletions(-)
>
> diff --git a/arch/x86/include/asm/text-patching.h
> b/arch/x86/include/asm/text-patching.h
> index e85ff65c43c3..f8fc8e86cf01 100644
> --- a/arch/x86/include/asm/text-patching.h
> +++ b/arch/x86/include/asm/text-patching.h
> @@ -35,6 +35,7 @@ extern void *text_poke_early(void *addr, const void
> *opcode, size_t len);
> * inconsistent instruction while you patch.
> */
> extern void *text_poke(void *addr, const void *opcode, size_t len);
> +extern void *text_poke_kgdb(void *addr, const void *opcode, size_t len);
> extern int poke_int3_handler(struct pt_regs *regs);
> extern void *text_poke_bp(void *addr, const void *opcode, size_t len, void
> *handler);
> extern int after_bootmem;
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index ebeac487a20c..c6a3a10a2fd5 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -678,18 +678,7 @@ void *__init_or_module text_poke_early(void *addr, const
> void *opcode,
> return addr;
> }
>
> -/**
> - * text_poke - Update instructions on a live kernel
> - * @addr: address to modify
> - * @opcode: source of the copy
> - * @len: length to copy
> - *
> - * Only atomic text poke/set should be allowed when not doing early patching.
> - * It means the size must be writable atomically and the address must be
> aligned
> - * in a way that permits an atomic write. It also makes sure we fit on a
> single
> - * page.
> - */
> -void *text_poke(void *addr, const void *opcode, size_t len)
> +static void *__text_poke(void *addr, const void *opcode, size_t len)
> {
> unsigned long flags;
> char *vaddr;
> @@ -702,8 +691,6 @@ void *text_poke(void *addr, const void *opcode, size_t
> len)
>*/
> BUG_ON(!after_bootmem);
>
> - lockdep_assert_held(_mutex);
> -
> if (!core_kernel_text((unsigned long)addr)) {
> pages[0] = vmalloc_to_page(addr);
> pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
> @@ -732,6 +719,43 @@ void *text_poke(void *addr, const void *opcode, size_t
> len)
> return addr;
> }
>
> +/**
> + * text_poke - Update instructions on a live kernel
> + * @addr: address to modify
> + * @opcode: source of the copy
> + * @len: length to copy
> + *
> + * Only atomic text poke/set should be allowed when not doing early patching.
> + * It means the size must be writable atomically and the address must be
> aligned
> + * in a way that permits an atomic write. It also makes sure we fit on a
> single
> + * page.
> + */
> +void *text_poke(void *addr, const void *opcode, size_t len)
> +{
> + lockdep_assert_held(_mutex);
> +
> + return __text_poke(addr, opcode, len);
> +}
> +
> +/**
> + * text_poke_kgdb - Update instructions on a live kernel by kgdb
> + * @addr: address to modify
> + * @opcode: source of the copy
> + * @len: length to copy
> + *
> + * Only atomic text poke/set should be allowed when not doing early patching.
> + * It means the size must be writable atomically and the address must be
> aligned
> + * in a way that permits an atomic write. It also makes sure we fit on a
> single
> + * page.
> + *
> + * Context: should only be used by kgdb, which ensures no other core is
> running,
> + * despite the fact it does not hold the text_mutex.
> + */
> +void *text_poke_kgdb(void *addr, const void *opcode, size_t len)
> +{
> + return __text_poke(addr, opcode, len);
> +}
> +
> static void do_sync_core(void *info)
> {
> sync_core();
> diff --git a/arch/x86/kernel/kgdb.c
GPL revocation (GPC-Slots2): Alex "Skud" Bayley, Leigh Honeywell
Quote: " Then you should have used them. Not necessary, the language used in the press release identifies them easily. should As if I somehow can't just rescind using their names either. License to use/modify/etc the GPC Slots 2 code is hereby terminated for. Alex "Skud" Bayley, and Leigh Honeywell. (Note: this termination is not to be construed as a lifting of the previously issued termination regarding the "Geek Feminism collective", this termination is an addendum) --MikeeUSA-- (electronic signature :D ) 1019403 Their response is irrelevant. " Discussions with author of program involved: http://8ch.net/tech/res/1013409.html http://8ch.net/tech/res/1017824.html http://8ch.net/tech/res/1018729.html https://slashdot.org/submission/9087542/author-recinds-gpl p46 "As long as the project continues to honor the terms of the licenses under which it recieved contributions, the licenses continue in effect. There is one important caveat: Even a perpetual license can be revoked. See the discussion of bare licenses and contracts in Chapter 4" --Lawrence Rosen p56 "A third problem with bare licenses is that they may be revocable by the licensor. Specifically, /a license not coupled with an interest may be revoked./ The term /interest/ in this context usually means the payment of some royalty or license fee, but there are other more complicated ways to satisfy the interest requirement. For example, a licensee can demonstrate that he or she has paid some consideration-a contract law term not found in copyright or patent law-in order to avoid revocation. Or a licensee may claim that he or she relied on the software licensed under an open source license and now is dependent upon that software, but this contract law concept, called promissory estoppel, is both difficult to prove and unreliable in court tests. (The concepts of /consideration/ and /promissory estoppel/ are explained more fully in the next section.) Unless the courts allow us to apply these contract law principles to a license, we are faced with a bare license that is revocable. --Lawrence Rosen p278 "Notice that in a copyright dispute over a bare license, the plaintiff will almost certainly be the copyright owner. If a licensee were foolish enough to sue to enforce the terms and conditions of the license, the licensor can simply revoke the bare license, thus ending the dispute. Remeber that a bare license in the absence of an interest is revocable." --Lawrence Rosen Lawrence Rosen - Open Source Licensing - Sofware Freedom and Intellectual property Law p65 "Of all the licenses descibed in this book, only the GPL makes the explicity point that it wants nothing of /acceptance/ of /consideration/: ... The GPL authors intend that it not be treated as a contract. I will say much more about this license and these two provisions in Chapter 6. For now, I simply point out that the GPL licensors are in essentially the same situation as other open source licensors who cannot prove offer, acceptance, or consideration. There is no contract." --Lawrence Rosen David McGowan, Professor of Law, University of Minnesota Law School: "Termination of rights [...] The most plausible assumption is that a developer who releases code under the GPL may terminate GPL rights, probably at will. [...] My point is not that termination is a great risk, it is that it is not recognized as a risk even though it is probably relevant to commercial end-users, accustomed to having contractual rights they can enforce themselves.
Re: [PATCH 2/2] pwm: sifive: Add a driver for SiFive SoC PWM
On Wed, Jan 16, 2019 at 10:16 PM Uwe Kleine-König
wrote:
>
> Hello,
>
> On Wed, Jan 16, 2019 at 04:40:42PM +0530, Yash Shah wrote:
> > On Wed, Jan 16, 2019 at 3:30 AM Uwe Kleine-König
> > wrote:
> > > On Fri, Jan 11, 2019 at 01:52:44PM +0530, Yash Shah wrote:
> > > > Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC.
> > > >
> > > > Signed-off-by: Wesley W. Terpstra
> > > > [Atish: Various fixes and code cleanup]
> > > > Signed-off-by: Atish Patra
> > > > Signed-off-by: Yash Shah
> > > > ---
> > > > drivers/pwm/Kconfig | 10 ++
> > > > drivers/pwm/Makefile | 1 +
> > > > drivers/pwm/pwm-sifive.c | 246
> > > > +++
> > > > 3 files changed, 257 insertions(+)
> > > > create mode 100644 drivers/pwm/pwm-sifive.c
> > > >
> > > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> > > > index a8f47df..3bcaf6a 100644
> > > > --- a/drivers/pwm/Kconfig
> > > > +++ b/drivers/pwm/Kconfig
> > > > @@ -380,6 +380,16 @@ config PWM_SAMSUNG
> > > > To compile this driver as a module, choose M here: the module
> > > > will be called pwm-samsung.
> > > >
> > > > +config PWM_SIFIVE
> > > > + tristate "SiFive PWM support"
> > > > + depends on OF
> > > > + depends on COMMON_CLK
> > >
> > > I'd say add:
> > >
> > > depends on MACH_SIFIVE || COMPILE_TEST
> > >
> > > (I guess "MACH_SIFIVE" is wrong, but I assume you get what I mean.)
> >
> > As of now, MACH_SIFIVE/ARCH_SIFIVE isn't available.
> > @Paul, Do you have any comments on this?
>
> If this is not going to be available at least protect it by
>
> depends RISCV || COMPILE_TEST
>
> > > I wonder if such an instance should be only a single PWM instead of
> > > four. Then you were more flexible with the period lengths (using
> > > pwmcfg.pwmzerocmp) and could do stuff like inverted and uninverted mode.
> > >
> > > I didn't understand how the deglitch logic works yet. Currently it is
> > > not used which might result in four edges in a single period (which is
> > > bad).
> >
> > I can enable deglitch logic by just setting a bit (BIT_PWM_DEGLITCH) in
> > REG_PWMCFG. Will do that.
>
> This only works for the first pwm output though.
>
> > > > +struct sifive_pwm_device {
> > > > + struct pwm_chip chip;
> > > > + struct notifier_block notifier;
> > > > + struct clk *clk;
> > > > + void __iomem *regs;
> > > > + unsigned int approx_period;
>
> When thinking about this a bit more, I think the better approach would
> be to let the consumer change the period iff there is only one consumer.
> Then you can drop that approx-period stuff and the result is more
> flexible. (Having said that I still prefer making the driver provide
> only a single PWM with the ability to have periods other than powers of
> two.)
>
I am not confident about the implementation of the way you are suggesting.
As of now, I am going to stick with the current implementation.
> > > > + writel(frac, pwm->regs + REG_PWMCMP0 + dev->hwpwm * SIZE_PWMCMP);
> > >
> > > If you get a constant inactive output with frac=0 and a constant active
> > > output with frac=0x the calculation above seems wrong to me.
> > > (A value i written to the pwmcmpX register means a duty cycle of
> > > (i * period / 0x). Your calculation assumes a divisor of 0x1
> > > however.)
> >
> > Not sure if I get you completely. But, if divisor of 0x is your concern
> > then
> > does the below look ok?
> >
> > frac = div_u64(((u64)duty_cycle << 16) - duty_cycle, state->period);
>
> This works (I think, didn't redo the maths), but I would prefer
>
> frac = div_u64((u64)duty_cycle * 0x, state->period);
>
> for better readability. (Maybe the compiler is even clever enough to see
> this can be calculated as you suggested.)
Sure, will multiply it with 0x for better readability.
>
> > > > +static int sifive_pwm_clock_notifier(struct notifier_block *nb,
> > > > + unsigned long event, void *data)
> > > > +{
> > > > + struct clk_notifier_data *ndata = data;
> > > > + struct sifive_pwm_device *pwm =
> > > > + container_of(nb, struct sifive_pwm_device, notifier);
> > > > +
> > > > + if (event == POST_RATE_CHANGE)
> > > > + sifive_pwm_update_clock(pwm, ndata->new_rate);
> > >
> > > Does this need locking? (Maybe not with the current state.)
> >
> > No. We can add it when required.
>
> My thought was, that the clk freq might change while .apply is active.
> But given that you only configure the relative duty cycle this is
> independent of the actual clk freq.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König|
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
RE: [PATCH v3] Drivers: hv: vmbus: Expose counters for interrupts and full conditions
> From: Kimberly Brown
> Sent: Wednesday, January 16, 2019 8:38 PM
> To: Michael Kelley ; Long Li
> ; Sasha Levin ;
> Dexuan Cui
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; de...@linuxdriverproject.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH v3] Drivers: hv: vmbus: Expose counters for interrupts and
> full
> conditions
>
> Counter values for per-channel interrupts and ring buffer full
> conditions are useful for investigating performance.
>
> Expose counters in sysfs for 2 types of guest to host interrupts:
> 1) Interrupts caused by the channel's outbound ring buffer transitioning
> from empty to not empty
> 2) Interrupts caused by the channel's inbound ring buffer transitioning
> from full to not full while a packet is waiting for enough buffer space to
> become available
>
> Expose 2 counters in sysfs for the number of times that write operations
> encountered a full outbound ring buffer:
> 1) The total number of write operations that encountered a full
> condition
> 2) The number of write operations that were the first to encounter a
> full condition
>
> I tested this patch by confirming that the sysfs files were created and
> observing the counter values. The values seemed to increase by a
> reasonable amount when the Hyper-v related drivers were in use.
>
> Signed-off-by: Kimberly Brown
> ---
> Changes in v3:
> - Used the outbound ring buffer spinlock to protect the the full
>condition counters in set_channel_pending_send_size()
> - Corrected the KernelVersion values for the new entries in
>Documentation/ABI/stable/sysfs-bus-vmbus
>
> Changes in v2:
> - Added mailing lists to the cc list
> - Removed the host to guest interrupt counters proposed in v1 because
>they were not accurate
> - Added full condition counters for the channel's outbound ring buffer
>
> Documentation/ABI/stable/sysfs-bus-vmbus | 33
> drivers/hv/ring_buffer.c | 14 -
> drivers/hv/vmbus_drv.c | 32
> include/linux/hyperv.h | 38
>
> 4 files changed, 116 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus
> b/Documentation/ABI/stable/sysfs-bus-vmbus
> index 3fed8fdb873d..a0304c563467 100644
> --- a/Documentation/ABI/stable/sysfs-bus-vmbus
> +++ b/Documentation/ABI/stable/sysfs-bus-vmbus
> @@ -146,3 +146,36 @@ KernelVersion: 4.16
> Contact: Stephen Hemminger
> Description: Binary file created by uio_hv_generic for ring buffer
> Users: Userspace drivers
> +
> +What:
> /sys/bus/vmbus/devices//channels//intr_in_full
> +Date: January 2019
> +KernelVersion: 5.0
> +Contact:Michael Kelley
> +Description:Number of guest to host interrupts caused by the inbound
> ring
> + buffer transitioning from full to not full while a packet is
> + waiting for buffer space to become available
> +Users: Debugging tools
> +
> +What:
> /sys/bus/vmbus/devices//channels//intr_out_empty
> +Date: January 2019
> +KernelVersion: 5.0
> +Contact:Michael Kelley
> +Description:Number of guest to host interrupts caused by the outbound
> ring
> + buffer transitioning from empty to not empty
> +Users: Debugging tools
> +
> +What:
> /sys/bus/vmbus/devices//channels//out_full_first
> +Date: January 2019
> +KernelVersion: 5.0
> +Contact:Michael Kelley
> +Description:Number of write operations that were the first to encounter
> an
> + outbound ring buffer full condition
> +Users: Debugging tools
> +
> +What:
> /sys/bus/vmbus/devices//channels//out_full_total
> +Date: January 2019
> +KernelVersion: 5.0
> +Contact:Michael Kelley
> +Description:Total number of write operations that encountered an
> outbound
> + ring buffer full condition
> +Users: Debugging tools
> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> index 1f1a55e07733..9e8b31ccc142 100644
> --- a/drivers/hv/ring_buffer.c
> +++ b/drivers/hv/ring_buffer.c
> @@ -74,8 +74,10 @@ static void hv_signal_on_write(u32 old_write, struct
> vmbus_channel *channel)
>* This is the only case we need to signal when the
>* ring transitions from being empty to non-empty.
>*/
> - if (old_write == READ_ONCE(rbi->ring_buffer->read_index))
> + if (old_write == READ_ONCE(rbi->ring_buffer->read_index)) {
> + ++channel->intr_out_empty;
> vmbus_setevent(channel);
> + }
> }
>
> /* Get the next write location for the specified ring buffer. */
> @@ -272,10 +274,19 @@ int hv_ringbuffer_write(struct vmbus_channel
> *channel,
>* is empty since the read index == write index.
>*/
> if (bytes_avail_towrite <= totalbytes_towrite) {
> + ++channel->out_full_total;
> +
> + if
RE: [PATCH] usb: chipidea: Grab the (legacy) USB PHY by phandle first
>
> On Wed, 2019-01-16 at 14:44 +0100, Thomas Petazzoni wrote:
> > Well prior to your code, there was already a possibility for both
> > ci->phy and ci->usb_phy to be valid. I don't think it's really useful
> > to avoid the fallback when a generic PHY has already been found, it's
> > confusing. If really you want to clarify that, it should be:
> >
> > /* Let's first try to find a generic PHY */
> > ci->phy = devm_phy_get(dev->parent, "usb-phy");
> > if (IS_ERR(ci->phy)) {
Please consider -EPROBE_DEFER case
> > /* Fall back to legacy USB PHY */
> > ci->usb_phy = devm_usb_get_phy_by_phandle(dev->parent, "phys",
> 0);
Please consider -EPROBE_DEFER case
> > if (IS_ERR(ci->usb_phy))
> > ci->usb_phy = devm_usb_get_phy(dev->parent,
> USB_PHY_TYPE_USB2);
> > }
> >
Below code
if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy)) {
ret = -EPROBE_DEFER;
goto ulpi_exit;
}
needs to change as:
if (PTR_ERR(ci->phy) ==-EPROBE_DEFER || PTR_ERR(ci->usb_phy)
== -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
goto ulpi_exit;
}
Peter
> > With that, you would only have either ci->phy or ci->usb_phy be valid,
> > and never both. With your change, you can have ci->phy and
> > ci->usb_phy both be valid if the legacy USB PHY was found using
> > devm_usb_get_phy_by_phandle(), but not if we fell back to
> > devm_usb_get_phy().
>
> Okay that makes sense, your suggestion is indeed more consistent with the
> existing
> behavior. I'll go with that in the next revision!
>
Re: [PATCH 04/13] dt-bindings: mailbox: qcom: Add clock-name optional property
On Mon 17 Dec 01:46 PST 2018, Jorge Ramirez-Ortiz wrote:
> When the APCS clock is registered (platform dependent), it retrieves
> its parent names from hardcoded values in the driver.
>
> The following commit allows the DT node to provide such clock names to
> the platform data based clock driver therefore avoiding having to
> explicitly embed those names in the clock driver source code.
>
> Co-developed-by: Niklas Cassel
> Signed-off-by: Niklas Cassel
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> .../bindings/mailbox/qcom,apcs-kpss-global.txt | 21
> +
> 1 file changed, 21 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
> b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
> index 1232fc9..f252439 100644
> --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
> +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt
> @@ -23,6 +23,10 @@ platforms.
> Value type:
> Definition: phandle to the input PLL, which feeds the APCS mux/divider
>
> + Usage: required if #clock-names property is present
> + Value type:
> + Definition: phandles to the two parent clocks of the clock driver.
I presume you meant to replace the existing definition of "clocks"?
I think the purpose of "required if #clock-cells" comes from that
meaning that it represents a clock-controller if #clock-cells is
specified, in which case it requires the upstream clock(s).
Regards,
Bjorn
> +
> - #mbox-cells:
> Usage: required
> Value type:
> @@ -33,6 +37,12 @@ platforms.
> Value type:
> Definition: as described in clock.txt, must be 0
>
> +- clock-names:
> + Usage: required if the platform data based clock driver needs to
> + retrieve the parent clock names from device tree.
> + This will requires two mandatory clocks to be defined.
> + Value type:
> + Definition: must be "aux" and "pll"
>
> = EXAMPLE
> The following example describes the APCS HMSS found in MSM8996 and part of
> the
> @@ -65,3 +75,14 @@ Below is another example of the APCS binding on MSM8916
> platforms:
> clocks = <>;
> #clock-cells = <0>;
> };
> +
> +Below is another example of the APCS binding on QCS404 platforms:
> +
> + apcs_glb: mailbox@b011000 {
> + compatible = "qcom,qcs404-apcs-apps-global", "syscon";
> + reg = <0x0b011000 0x1000>;
> + #mbox-cells = <1>;
> + clocks = < GCC_GPLL0_AO_OUT_MAIN>, <_hfpll>;
> + clock-names = "aux", "pll";
> + #clock-cells = <0>;
> + };
> --
> 2.7.4
>
Re: [PATCH 10/13] arm64: dts: qcom: qcs404: Add HFPLL node
On Mon 17 Dec 11:39 PST 2018, Stephen Boyd wrote:
> Quoting Jorge Ramirez-Ortiz (2018-12-17 01:46:27)
> > The high frequency pll functionality is required to enable CPU
> > frequency scaling operation.
> >
> > Co-developed-by: Niklas Cassel
> > Signed-off-by: Niklas Cassel
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
> > arch/arm64/boot/dts/qcom/qcs404.dtsi | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > index 4594fea7..ec3f6c7 100644
> > --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > @@ -375,6 +375,15 @@
> > #mbox-cells = <1>;
> > };
> >
> > + apcs_hfpll: clock-controller@0b016000 {
>
> Drop leading 0 on unit address please.
>
> > + compatible = "qcom,hfpll";
> > + reg = <0x0b016000 0x30>;
>
> Wow that is small!
>
I double checked and it's actually 0x34, but the last register is
protected.
Regards,
Bjorn
> > + #clock-cells = <0>;
> > + clock-output-names = "apcs_hfpll";
> > + clocks = <_board>;
> > + clock-names = "xo";
> > + };
> > +
Re: [PATCH 12/13] arm64: dts: qcom: qcs404: Add cpufreq support
On Mon 17 Dec 01:46 PST 2018, Jorge Ramirez-Ortiz wrote:
> Support CPU frequency scaling on qcs404.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Niklas Cassel
> Signed-off-by: Niklas Cassel
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> index 2d9e70e..5a14887 100644
> --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> @@ -30,6 +30,8 @@
> reg = <0x100>;
> enable-method = "psci";
> next-level-cache = <_0>;
> + clocks = <_glb>;
> + operating-points-v2 = <_opp_table>;
> };
>
> CPU1: cpu@101 {
> @@ -38,6 +40,8 @@
> reg = <0x101>;
> enable-method = "psci";
> next-level-cache = <_0>;
> + clocks = <_glb>;
> + operating-points-v2 = <_opp_table>;
> };
>
> CPU2: cpu@102 {
> @@ -46,6 +50,8 @@
> reg = <0x102>;
> enable-method = "psci";
> next-level-cache = <_0>;
> + clocks = <_glb>;
> + operating-points-v2 = <_opp_table>;
> };
>
> CPU3: cpu@103 {
> @@ -54,6 +60,8 @@
> reg = <0x103>;
> enable-method = "psci";
> next-level-cache = <_0>;
> + clocks = <_glb>;
> + operating-points-v2 = <_opp_table>;
> };
>
> L2_0: l2-cache {
> --
> 2.7.4
>
Re: [PATCH 13/13] arm64: defconfig: Enable HFPLL
On Mon 17 Dec 01:46 PST 2018, Jorge Ramirez-Ortiz wrote: > The high frequency pll is required on compatible Qualcomm SoCs to > support the CPU frequency scaling feature. > Reviewed-by: Bjorn Andersson > Co-developed-by: Niklas Cassel > Signed-off-by: Niklas Cassel > Signed-off-by: Jorge Ramirez-Ortiz > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 5c2b1f6..da390aa 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -615,6 +615,7 @@ CONFIG_MSM_MMCC_8996=y > CONFIG_MSM_GCC_8998=y > CONFIG_QCS_GCC_404=y > CONFIG_SDM_GCC_845=y > +CONFIG_QCOM_HFPLL=y > CONFIG_HWSPINLOCK=y > CONFIG_HWSPINLOCK_QCOM=y > CONFIG_ARM_MHU=y > -- > 2.7.4 >
Re: [PATCH 11/13] arm64: dts: qcom: qcs404: Add the clocks for APCS mux/divider
On Mon 17 Dec 01:46 PST 2018, Jorge Ramirez-Ortiz wrote:
> Specify the clocks that feed the APCS mux/divider instead of using
> default hardcoded values in the source code.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Niklas Cassel
> Signed-off-by: Niklas Cassel
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> index ec3f6c7..2d9e70e 100644
> --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> @@ -373,6 +373,9 @@
> compatible = "qcom,qcs404-apcs-apps-global", "syscon";
> reg = <0x0b011000 0x1000>;
> #mbox-cells = <1>;
> + clocks = < GCC_GPLL0_AO_OUT_MAIN>, <_hfpll>;
> + clock-names = "aux", "pll";
> + #clock-cells = <0>;
> };
>
> apcs_hfpll: clock-controller@0b016000 {
> --
> 2.7.4
>
Re: [PATCH 09/13] arm64: dts: qcom: qcs404: Add OPP table
On Mon 17 Dec 01:46 PST 2018, Jorge Ramirez-Ortiz wrote:
> Add a CPU OPP table to qcs404
>
> Co-developed-by: Niklas Cassel
> Signed-off-by: Niklas Cassel
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> index 9b5c165..4594fea7 100644
> --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> @@ -62,6 +62,21 @@
> };
> };
>
> + cpu_opp_table: cpu_opp_table {
Please don't use _ in the node name. (cpu_opp_table: cpu-opp-table)
Apart from that, this looks good
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-109440 {
> + opp-hz = /bits/ 64 <109440>;
> + };
> + opp-124800 {
> + opp-hz = /bits/ 64 <124800>;
> + };
> + opp-140160 {
> + opp-hz = /bits/ 64 <140160>;
> + };
> + };
> +
> firmware {
> scm: scm {
> compatible = "qcom,scm-qcs404", "qcom,scm";
> --
> 2.7.4
>
[RFC PATCH] kbuild: support llvm-ar
I want to avoid applying this patch because this patch is ugly, and
people are trying to fix llvm-ar. I tried the latest llvm-ar, and I
saw some improvement, but still cannot build the kernel with it.
The main reason of this post is for the record, and suggest how llvm-ar
should work.
As you may have noticed, there are two issues:
[1] llvm-ar does not recognize the 'P' option
[2] llvm-ar does not flatten thin archives (not fixed yet)
Let me explain each of them.
[1] Why is 'P' option needed for GNU ar?
It may not be so clear the reason of commit 9a6cfca4f413 ("kbuild:
thin archives use P option to ar").
If two objects from different directories have the same file name,
GNU ar may drop the one when flattening thin archives.
Here is a simple test case:
$ gcc -c -x c /dev/null -o foo.o
$ mkdir a
$ gcc -c -x c /dev/null -o a/foo.o
$ ar rcST a/built-in.a a/foo.o
$ ar rcST built-in.a a/built-in.a foo.o
$ cat built-in.a
!
// 8 `
foo.o/
/0 0 0 0 644 944 `
We expect built-in.a contains both a/foo.o and foo.o, but the former
is lost. The 'P' option solves this.
$ rm -f built-in.a
$ ar rcSTP built-in.a a/built-in.a foo.o
$ cat built-in.a
!
// 16`
a/foo.o/
foo.o/
/0 0 0 0 644 944 `
/9 0 0 0 644 944 `
Interestingly, GNU ar works as expected without 'P' when the order of
a/built-in.a and foo.o are opposite:
$ rm built-in.a
$ ar rcST built-in.a foo.o a/built-in.a
$ cat built-in.a
!
// 16`
foo.o/
a/foo.o/
/0 0 0 0 644 944 `
/7 0 0 0 644 944 `
Anyway, even the latest GNU toolchain works like that, so
Kbuild does need the 'P' option.
The real world example is sh.
arch/sh/kernel/cpu/fpu.c
arch/sh/kernel/cpu/sh2a/fpu.c
arch/sh/kernel/cpu/sh4/fpu.c
arch/sh/kernel/cpu/sh5/fpu.c
[2] flattening thin archives
llvm-ar cannot flatten archives.
This issue was filed in the following:
https://bugs.llvm.org/show_bug.cgi?id=37530
Its status was marked as "RESOLVED FIXED", but actually not fixed
as of writing (Jan 17, 2019).
The older version of llvm-ar worked like this:
$ rm -f built-in.a a/built-in.a
$ llvm-ar rcST a/built-in.a a/foo.o
$ llvm-ar rcST built-in.a a/built-in.a
$ cat built-in.a !
// 14`
a/built-in.a/
/0 0 0 0 644 136 `
Recently, two commits were pushed to the trunk.
[llvm-ar] Flatten thin archives.
[llvm-ar] Resubmit recursive thin archive test with fix for full path names
and better error messages
As far as I tested, the latest llvm-ar works as follows:
$ llvm-ar rcST a/built-in.a a/foo.o
$ llvm-ar rcST built-in.a a/built-in.a
$ cat built-in.a
!
// 8 `
foo.o/
/0 0 0 0 644 800 `
OK, it flattens the thin archive, but the problem is it rips off
the directory path.
GNU ar works as follows:
$ ar rcST a/built-in.a a/foo.o
$ ar rcSTbuilt-in.a a/built-in.a
$ cat built-in.a
!
// 10`
a/foo.o/
/0 0 0 0 644 800 `
If you use the latest llvm-ar for building the kernel, you will see
a mysterious 'llvm-ar: error: No such file or directory.' error.
(I think the error message could be improved because it is unclear
what is missing.)
[Workaround in this patch]
Currently, llvm-ar cannot flatten thin archives correctly. So, Kbuild
uses '$(AR) t' to expand thin archives from subdirectories, then repack
all objects into the current directory built-in.a.
The 'P' for cmd_link_l_target is unneeded because Kbuild does not
support subdir objects for lib-y in the first place.
[How to use]
Pass AR=llvm-ar in the configuration and build command:
$ make AR=llvm-ar defconfig
$ make AR=llvm-ar
Or, simply in one line:
$ make AR=llvm-ar defconfig all
Signed-off-by: Masahiro Yamada
---
This patch can be cleanly applied to Linux 5.0-rc2 + the following:
https://patchwork.kernel.org/patch/10761625/
https://patchwork.kernel.org/patch/10767193/
https://patchwork.kernel.org/patch/10767195/
https://patchwork.kernel.org/patch/10767503/
https://patchwork.kernel.org/patch/10767509/
init/Kconfig | 3 +++
scripts/Makefile.build | 8 +++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/init/Kconfig b/init/Kconfig
index 513fa54..185274ac 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -23,6 +23,9 @@ config CLANG_VERSION
int
default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
+config AR_IS_LLVM
+ def_bool
Re: [PATCH 08/13] clk: qcom: hfpll: CLK_IGNORE_UNUSED
On Mon 17 Dec 01:46 PST 2018, Jorge Ramirez-Ortiz wrote:
> When COMMON_CLK_DISABLED_UNUSED is set, in an effort to save power and
> to keep the software model of the clock in line with reality, the
> framework transverses the clock tree and disables those clocks that
> were enabled by the firmware but have not been enabled by any device
> driver.
>
> If CPUFREQ is enabled, early during the system boot, it might attempt
> to change the CPU frequency ("set_rate"). If the HFPLL is selected as
> a provider, it will then change the rate for this clock.
>
> As boot continues, clk_disable_unused_subtree will run. Since it wont
> find a valid counter (enable_count) for a clock that is actually
> enabled it will attempt to disable it which will cause the CPU to
> stop. Notice that in this driver, calls to check whether the clock is
> enabled are routed via the is_enabled callback which queries the
> hardware.
>
With the CPUFREQ referencing the CPU clock driver, that has decided to
run off this clock, why is it not refcounted?
Regards,
Bjorn
> The following commit, rather than marking the clock critical and
> forcing the clock to be always enabled, addresses the above scenario
> making sure the clock is not disabled but it continues to rely on the
> firmware to enable the clock.
>
> Co-developed-by: Niklas Cassel
> Signed-off-by: Niklas Cassel
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> drivers/clk/qcom/hfpll.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c
> index 0ffed0d..9d92f5d 100644
> --- a/drivers/clk/qcom/hfpll.c
> +++ b/drivers/clk/qcom/hfpll.c
> @@ -58,6 +58,7 @@ static int qcom_hfpll_probe(struct platform_device *pdev)
> .parent_names = (const char *[]){ "xo" },
> .num_parents = 1,
> .ops = _ops_hfpll,
> + .flags = CLK_IGNORE_UNUSED,
> };
>
> h = devm_kzalloc(dev, sizeof(*h), GFP_KERNEL);
> --
> 2.7.4
>
Re: [PATCH v2 2/2] docs-rst: userspace: update verbs API details
Jonathan Corbet wrote on 01/15/2019 11:38:59 PM: > We are not attempting to duplicate the man pages; there's been occasional > talk of bringing them into the kernel tree, but enthusiasm for that is > scarce for a number of good reasons. But there's a lot of information > about the user-space API that isn't in the man pages, including the piece > you are converting to RST. My next task is to update the man pages for rdma-core since I touched libibverbs as well (the _other_ side of this API). So I just want to make sure everything is documented exactly once (no more, no less) and in the correct place. > For something like this, driver-api seems like the right place. Someday, > in some glorious future, it could contain a full manual on how these > drivers are written, using all of the nice kerneldoc comments that already > exist under drivers/infiniband. > > > OK, just to be clear - you are asking me to leave the original file as-is > > (well, after .rst conversion) but move it to the new location > > (Documentation/userspace-api), and put my new content into a new file in > > the old location (Documentation/infiniband)? > > I'd rather see you put the new stuff under Documentation/driver-api, either > in a standalone file or in a new subdirectory. I took a quick look at what is already there, and I don't see how the RDMA stuff fits. It looks like the majority is about various busses (SPI, PCI, I2C, USB, etc) or other general platform support (clk, edac) that I would use when writing a driver. My changes are very infiniband-specific, and user-facing and don't really seem to fit in with the aforementioned modules. It seems to me that if it does not belong in userspace-api, then leaving it where it is is the best choice. Regards, Joel
Re: [PATCH 07/13] clk: qcom: hfpll: register as clock provider
On Mon 17 Dec 01:46 PST 2018, Jorge Ramirez-Ortiz wrote:
> Make the output of the high frequency pll a clock provider.
> On the QCS404 this PLL controls cpu frequency scaling.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Niklas Cassel
> Signed-off-by: Niklas Cassel
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> drivers/clk/qcom/hfpll.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c
> index 87b7f46..0ffed0d 100644
> --- a/drivers/clk/qcom/hfpll.c
> +++ b/drivers/clk/qcom/hfpll.c
> @@ -53,6 +53,7 @@ static int qcom_hfpll_probe(struct platform_device *pdev)
> struct regmap *regmap;
> struct clk_hfpll *h;
> struct clk *pclk;
> + int ret;
> struct clk_init_data init = {
> .parent_names = (const char *[]){ "xo" },
> .num_parents = 1,
> @@ -87,7 +88,14 @@ static int qcom_hfpll_probe(struct platform_device *pdev)
> h->clkr.hw.init =
> spin_lock_init(>lock);
>
> - return devm_clk_register_regmap(>dev, >clkr);
> + ret = devm_clk_register_regmap(dev, >clkr);
> + if (ret) {
> + dev_err(dev, "failed to register regmap clock: %d\n", ret);
> + return ret;
> + }
> +
> + return devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get,
> +>clkr.hw);
> }
>
> static struct platform_driver qcom_hfpll_driver = {
> --
> 2.7.4
>
Re: [PATCH 06/13] clk: qcom: hfpll: get parent clock names from DT
On Mon 17 Dec 01:46 PST 2018, Jorge Ramirez-Ortiz wrote:
> Allow accessing the parent clock name required for the driver
> operation using the device tree node.
>
> This permits extending the driver to other platforms without having to
> modify its source code.
>
> For backwards compatibility leave the previous value as default.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Niklas Cassel
> Signed-off-by: Niklas Cassel
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> drivers/clk/qcom/hfpll.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c
> index a6de7101..87b7f46 100644
> --- a/drivers/clk/qcom/hfpll.c
> +++ b/drivers/clk/qcom/hfpll.c
> @@ -52,6 +52,7 @@ static int qcom_hfpll_probe(struct platform_device *pdev)
> void __iomem *base;
> struct regmap *regmap;
> struct clk_hfpll *h;
> + struct clk *pclk;
> struct clk_init_data init = {
> .parent_names = (const char *[]){ "xo" },
> .num_parents = 1,
> @@ -75,6 +76,13 @@ static int qcom_hfpll_probe(struct platform_device *pdev)
> 0, ))
> return -ENODEV;
>
> + /* get parent clock from device tree (optional) */
> + pclk = devm_clk_get(dev, "xo");
> + if (!IS_ERR(pclk))
> + init.parent_names = (const char *[]){ __clk_get_name(pclk) };
> + else if (PTR_ERR(pclk) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> h->d =
> h->clkr.hw.init =
> spin_lock_init(>lock);
> --
> 2.7.4
>
RE: [PATCH 0/3] can: flexcan: add imx8qm support
Kindly Ping... Best Regards, Joakim Zhang > -Original Message- > From: Joakim Zhang > Sent: 2018年12月19日 16:39 > To: m...@pengutronix.de; linux-...@vger.kernel.org > Cc: w...@grandegger.com; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; dl-linux-imx ; Joakim > Zhang > Subject: [PATCH 0/3] can: flexcan: add imx8qm support > > This patch set intends to add Flexcan support for i.MX8QM platform which > defaultly supports CAN FD protocol. Although BRS enabled by system reset > when the driver sets CAN FD mode, now this patch serial does not support BRS > in the driver. And then I will send patch to enable BRS by changing the > register > to set bit timing. > > Dong Aisheng (3): > can: rx-offload: add CANFD support based on offload > can: flexcan: add CAN FD mode support > can: flexcan: add imx8qm support > > drivers/net/can/flexcan.c | 114 ++--- > drivers/net/can/rx-offload.c | 16 +++-- > include/linux/can/rx-offload.h | 4 +- > 3 files changed, 117 insertions(+), 17 deletions(-) > > -- > 2.17.1
RE: [PATCH 0/2] can: flexcan: add PE clock source select support
Kindly Ping... Best Regards, Joakim Zhang > -Original Message- > From: Joakim Zhang > Sent: 2018年12月13日 15:08 > To: m...@pengutronix.de; r...@kernel.org > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; dl-linux-imx ; Joakim > Zhang > Subject: [PATCH 0/2] can: flexcan: add PE clock source select support > > The patch set intends to add support for PE clock source select. The FlexCAN > controller can parse "fsl,clk-source" property from device tree to select > clock > source. > > Dong Aisheng (2): > Documentation: can: flexcan: add PE clock source property to device > tree > can: flexcan: add support for PE clock source select > > .../bindings/net/can/fsl-flexcan.txt | 8 > drivers/net/can/flexcan.c | 18 ++ > 2 files changed, 22 insertions(+), 4 deletions(-) > > -- > 2.17.1
Re: [PATCH 03/13] mbox: qcom: replace integer with valid macro
On Mon 17 Dec 01:46 PST 2018, Jorge Ramirez-Ortiz wrote: > Use the correct macro when registering the platform device. > Reviewed-by: Bjorn Andersson > Co-developed-by: Niklas Cassel > Signed-off-by: Niklas Cassel > Signed-off-by: Jorge Ramirez-Ortiz > --- > drivers/mailbox/qcom-apcs-ipc-mailbox.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c > b/drivers/mailbox/qcom-apcs-ipc-mailbox.c > index dc8fdab1..b782173 100644 > --- a/drivers/mailbox/qcom-apcs-ipc-mailbox.c > +++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c > @@ -108,7 +108,7 @@ static int qcom_apcs_ipc_probe(struct platform_device > *pdev) > register_clk: > apcs->clk = platform_device_register_data(>dev, > "qcom-apcs-msm8916-clk", > - -1, NULL, 0); > + PLATFORM_DEVID_NONE, NULL, 0); > if (IS_ERR(apcs->clk)) > dev_err(>dev, "failed to register APCS clk\n"); > > -- > 2.7.4 >
RE: [PATCH] can: flexcan: add TX support for variable payload size
Kindly Ping...
Best Regards,
Joakim Zhang
> -Original Message-
> From: Joakim Zhang
> Sent: 2018年12月12日 14:47
> To: m...@pengutronix.de; linux-...@vger.kernel.org
> Cc: w...@grandegger.com; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org; dl-linux-imx ; Joakim
> Zhang
> Subject: [PATCH] can: flexcan: add TX support for variable payload size
>
> Now the FlexCAN driver always use last mailbox for TX, it will work well when
> MB payload size is 8/16 bytes.
> TX mailbox would change to 13 when MB payload size is 64 bytes to support
> CANFD. So we may need to set iflag register to add support for variable
> payload size.
>
> Signed-off-by: Joakim Zhang
> ---
> drivers/net/can/flexcan.c | 42 +--
> 1 file changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index
> 0f36eafe3ac1..13fd085fcf84 100644
> --- a/drivers/net/can/flexcan.c
> +++ b/drivers/net/can/flexcan.c
> @@ -141,7 +141,9 @@
> #define FLEXCAN_TX_MB_RESERVED_OFF_FIFO 8
> #define FLEXCAN_TX_MB_RESERVED_OFF_TIMESTAMP 0
> #define FLEXCAN_RX_MB_OFF_TIMESTAMP_FIRST
> (FLEXCAN_TX_MB_RESERVED_OFF_TIMESTAMP + 1)
> -#define FLEXCAN_IFLAG_MB(x) BIT((x) & 0x1f)
> +#define FLEXCAN_IFLAG1_MB_NUM32
> +#define FLEXCAN_IFLAG1_MB(x) BIT(x)
> +#define FLEXCAN_IFLAG2_MB(x) BIT((x) & 0x1f)
> #define FLEXCAN_IFLAG_RX_FIFO_OVERFLOW BIT(7)
> #define FLEXCAN_IFLAG_RX_FIFO_WARN BIT(6)
> #define FLEXCAN_IFLAG_RX_FIFO_AVAILABLE BIT(5)
> @@ -822,9 +824,15 @@ static inline u64 flexcan_read_reg_iflag_rx(struct
> flexcan_priv *priv)
> struct flexcan_regs __iomem *regs = priv->regs;
> u32 iflag1, iflag2;
>
> - iflag2 = priv->read(>iflag2) & priv->reg_imask2_default &
> - ~FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
> - iflag1 = priv->read(>iflag1) & priv->reg_imask1_default;
> + if (priv->tx_mb_idx >= FLEXCAN_IFLAG1_MB_NUM) {
> + iflag2 = priv->read(>iflag2) & priv->reg_imask2_default &
> + ~FLEXCAN_IFLAG2_MB(priv->tx_mb_idx);
> + iflag1 = priv->read(>iflag1) & priv->reg_imask1_default;
> + } else {
> + iflag2 = priv->read(>iflag2) & priv->reg_imask2_default;
> + iflag1 = priv->read(>iflag1) & priv->reg_imask1_default &
> + ~FLEXCAN_IFLAG1_MB(priv->tx_mb_idx);
> + }
>
> return (u64)iflag2 << 32 | iflag1;
> }
> @@ -836,7 +844,8 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
> struct flexcan_priv *priv = netdev_priv(dev);
> struct flexcan_regs __iomem *regs = priv->regs;
> irqreturn_t handled = IRQ_NONE;
> - u32 reg_iflag2, reg_esr;
> + u32 reg_tx_iflag, tx_iflag_idx, reg_esr;
> + void __iomem *reg_iflag;
> enum can_state last_state = priv->can.state;
>
> /* reception interrupt */
> @@ -870,10 +879,18 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
> }
> }
>
> - reg_iflag2 = priv->read(>iflag2);
> + if (priv->tx_mb_idx >= FLEXCAN_IFLAG1_MB_NUM) {
> + reg_tx_iflag = priv->read(>iflag2);
> + tx_iflag_idx = FLEXCAN_IFLAG2_MB(priv->tx_mb_idx);
> + reg_iflag = >iflag2;
> + } else {
> + reg_tx_iflag = priv->read(>iflag1);
> + tx_iflag_idx = FLEXCAN_IFLAG1_MB(priv->tx_mb_idx);
> + reg_iflag = >iflag1;
> + }
>
> /* transmission complete interrupt */
> - if (reg_iflag2 & FLEXCAN_IFLAG_MB(priv->tx_mb_idx)) {
> + if (reg_tx_iflag & tx_iflag_idx) {
> u32 reg_ctrl = priv->read(>tx_mb->can_ctrl);
>
> handled = IRQ_HANDLED;
> @@ -885,7 +902,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
> /* after sending a RTR frame MB is in RX mode */
> priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
> >tx_mb->can_ctrl);
> - priv->write(FLEXCAN_IFLAG_MB(priv->tx_mb_idx), >iflag2);
> + priv->write(tx_iflag_idx, reg_iflag);
> netif_wake_queue(dev);
> }
>
> @@ -1244,8 +1261,13 @@ static int flexcan_open(struct net_device *dev)
> priv->tx_mb_idx = priv->mb_count - 1;
> priv->tx_mb = flexcan_get_mb(priv, priv->tx_mb_idx);
>
> - priv->reg_imask1_default = 0;
> - priv->reg_imask2_default = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
> + if (priv->tx_mb_idx >= FLEXCAN_IFLAG1_MB_NUM) {
> + priv->reg_imask1_default = 0;
> + priv->reg_imask2_default = FLEXCAN_IFLAG2_MB(priv->tx_mb_idx);
> + } else {
> + priv->reg_imask1_default = FLEXCAN_IFLAG1_MB(priv->tx_mb_idx);
> + priv->reg_imask2_default = 0;
> + }
>
> priv->offload.mailbox_read = flexcan_mailbox_read;
>
> --
> 2.17.1
[PATCH] pstore/ram: Fix console ramoops to show the previous boot logs
commit b05c950698fe ("pstore/ram: Simplify ramoops_get_next_prz()
arguments") changed update assignment in getting next persistent
ram zone by adding a check for record type. But the check always
returns true since the record type is assigned 0. And this breaks
console ramoops by showing current console log instead of previous
log on warm reset and hard reset (actually hard reset should not
be showing any logs).
Fix this by having persistent ram zone type check instead of record
type check. Tested this on SDM845 MTP and dragonboard 410c.
Reproducing this issue is simple as below:
1. Trigger hard reset and mount pstore. Will see console-ramoops
record in the mounted location which is the current log.
2. Trigger warm reset and mount pstore. Will see the current
console-ramoops record instead of previous record.
Fixes: b05c950698fe ("pstore/ram: Simplify ramoops_get_next_prz() arguments")
Signed-off-by: Sai Prakash Ranjan
---
I guess commit msg can be improved.
---
fs/pstore/ram.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 96f7d32cd184..441a44215456 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -128,7 +128,7 @@ ramoops_get_next_prz(struct persistent_ram_zone *przs[],
int id,
struct pstore_record *record)
{
struct persistent_ram_zone *prz;
- bool update = (record->type == PSTORE_TYPE_DMESG);
+ bool update;
/* Give up if we never existed or have hit the end. */
if (!przs)
@@ -138,6 +138,8 @@ ramoops_get_next_prz(struct persistent_ram_zone *przs[],
int id,
if (!prz)
return NULL;
+ update = (prz->type == PSTORE_TYPE_DMESG);
+
/* Update old/shadowed buffer. */
if (update)
persistent_ram_save_old(prz);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 02/13] mbox: qcom: add APCS child device for QCS404
On Mon 17 Dec 01:46 PST 2018, Jorge Ramirez-Ortiz wrote:
> There is clock controller functionality in the APCS hardware block of
> qcs404 devices similar to msm8916.
>
Reviewed-by: Bjorn Andersson
> Co-developed-by: Niklas Cassel
> Signed-off-by: Niklas Cassel
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> drivers/mailbox/qcom-apcs-ipc-mailbox.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> index aed23ac..dc8fdab1 100644
> --- a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> +++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> @@ -97,16 +97,21 @@ static int qcom_apcs_ipc_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> - if (of_device_is_compatible(np, "qcom,msm8916-apcs-kpss-global")) {
> - apcs->clk = platform_device_register_data(>dev,
> -
> "qcom-apcs-msm8916-clk",
> - -1, NULL, 0);
> - if (IS_ERR(apcs->clk))
> - dev_err(>dev, "failed to register APCS clk\n");
> - }
> -
> platform_set_drvdata(pdev, apcs);
>
> + if (of_device_is_compatible(np, "qcom,msm8916-apcs-kpss-global") ||
> + of_device_is_compatible(np, "qcom,qcs404-apcs-apps-global"))
> + goto register_clk;
> +
> + return 0;
> +
> +register_clk:
> + apcs->clk = platform_device_register_data(>dev,
> + "qcom-apcs-msm8916-clk",
> + -1, NULL, 0);
> + if (IS_ERR(apcs->clk))
> + dev_err(>dev, "failed to register APCS clk\n");
> +
> return 0;
> }
>
> --
> 2.7.4
>
RE: [PATCH V4] can: flexcan: implement can Runtime PM
Kindly Ping...
Best Regards,
Joakim Zhang
> -Original Message-
> From: Joakim Zhang
> Sent: 2018年11月30日 16:53
> To: m...@pengutronix.de; linux-...@vger.kernel.org
> Cc: w...@grandegger.com; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org; dl-linux-imx ; Aisheng
> DONG ; Joakim Zhang
> Subject: [PATCH V4] can: flexcan: implement can Runtime PM
>
> From: Aisheng Dong
>
> Flexcan will be disabled during suspend if no wakeup function required and
> enabled after resume accordingly. During this period, we could explicitly
> disable clocks.
> Since PM is optional, the clock is enabled at probe to guarante the clock is
> running when PM is not enabled in the kernel.
>
> Implement Runtime PM which will:
> 1) Without CONFIG_PM, clock is running whether Flexcan up or down.
> 2) With CONFIG_PM, clock enabled while Flexcan up and disabled when
>Flexcan down.
> 3) Disable clock when do system suspend and enable clock while system
>resume.
> 4) Make Power Domain framework be able to shutdown the corresponding
>power domain of this device.
>
> Signed-off-by: Aisheng Dong
> Signed-off-by: Joakim Zhang
> ---
> ChangeLog:
> V1->V2:
> *rebased on patch "can: flexcan: add self wakeup support".
> V2->V3:
> *fix device fails to probe without CONFIG_PM.
> V3->V4:
> *runtime pm enable should ahead of registering device.
> *disable device even if keeping the clocks on.
> ---
> drivers/net/can/flexcan.c | 111 +-
> 1 file changed, 73 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index
> 0f36eafe3ac1..cad42f20cfe5 100644
> --- a/drivers/net/can/flexcan.c
> +++ b/drivers/net/can/flexcan.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -277,6 +278,7 @@ struct flexcan_priv {
> u32 reg_imask1_default;
> u32 reg_imask2_default;
>
> + struct device *dev;
> struct clk *clk_ipg;
> struct clk *clk_per;
> const struct flexcan_devtype_data *devtype_data; @@ -444,6 +446,27
> @@ static inline void flexcan_error_irq_disable(const struct flexcan_priv
> *priv)
> priv->write(reg_ctrl, >ctrl);
> }
>
> +static int flexcan_clks_enable(const struct flexcan_priv *priv) {
> + int err;
> +
> + err = clk_prepare_enable(priv->clk_ipg);
> + if (err)
> + return err;
> +
> + err = clk_prepare_enable(priv->clk_per);
> + if (err)
> + clk_disable_unprepare(priv->clk_ipg);
> +
> + return err;
> +}
> +
> +static void flexcan_clks_disable(const struct flexcan_priv *priv) {
> + clk_disable_unprepare(priv->clk_ipg);
> + clk_disable_unprepare(priv->clk_per);
> +}
> +
> static inline int flexcan_transceiver_enable(const struct flexcan_priv
> *priv) {
> if (!priv->reg_xceiver)
> @@ -570,19 +593,13 @@ static int flexcan_get_berr_counter(const struct
> net_device *dev,
> const struct flexcan_priv *priv = netdev_priv(dev);
> int err;
>
> - err = clk_prepare_enable(priv->clk_ipg);
> - if (err)
> + err = pm_runtime_get_sync(priv->dev);
> + if (err < 0)
> return err;
>
> - err = clk_prepare_enable(priv->clk_per);
> - if (err)
> - goto out_disable_ipg;
> -
> err = __flexcan_get_berr_counter(dev, bec);
>
> - clk_disable_unprepare(priv->clk_per);
> - out_disable_ipg:
> - clk_disable_unprepare(priv->clk_ipg);
> + pm_runtime_put(priv->dev);
>
> return err;
> }
> @@ -1215,17 +1232,13 @@ static int flexcan_open(struct net_device *dev)
> struct flexcan_priv *priv = netdev_priv(dev);
> int err;
>
> - err = clk_prepare_enable(priv->clk_ipg);
> - if (err)
> + err = pm_runtime_get_sync(priv->dev);
> + if (err < 0)
> return err;
>
> - err = clk_prepare_enable(priv->clk_per);
> - if (err)
> - goto out_disable_ipg;
> -
> err = open_candev(dev);
> if (err)
> - goto out_disable_per;
> + goto out_disable_clks;
>
> err = request_irq(dev->irq, flexcan_irq, IRQF_SHARED, dev->name, dev);
> if (err)
> @@ -1288,10 +1301,8 @@ static int flexcan_open(struct net_device *dev)
> free_irq(dev->irq, dev);
> out_close:
> close_candev(dev);
> - out_disable_per:
> - clk_disable_unprepare(priv->clk_per);
> - out_disable_ipg:
> - clk_disable_unprepare(priv->clk_ipg);
> + out_disable_clks:
> + pm_runtime_put(priv->dev);
>
> return err;
> }
> @@ -1306,10 +1317,9 @@ static int flexcan_close(struct net_device *dev)
>
> can_rx_offload_del(>offload);
> free_irq(dev->irq, dev);
> - clk_disable_unprepare(priv->clk_per);
> - clk_disable_unprepare(priv->clk_ipg);
>
> close_candev(dev);
> + pm_runtime_put(priv->dev);
>
> can_led_event(dev, CAN_LED_EVENT_STOP);
>
> @@ -1349,18 +1359,14 @@ static int register_flexcandev(struct
Re: [PATCH v2] misc: aspeed-lpc-ctrl: make parameter optional
On Thu, 17 Jan 2019 at 09:02, Vijay Khemka wrote:
>
> Makiing memory-region and flash as optional parameter in device
> tree if user needs to use these parameter through ioctl then
> need to define in devicetree.
>
> Signed-off-by: Vijay Khemka
Thanks! This looks okay to me. I tested it on one of our systems which
uses both flash and reserved memory and it was fine.
Reviewed-by: Joel Stanley
Can you also send a patch to update the bindings at
Documentation/devicetree/bindings/mfd/aspeed-lpc.txt ? I think the
only change you need to make is to move the memory region and flash
properties to optional (instead of required).
Cheers,
Joel
> ---
> drivers/misc/aspeed-lpc-ctrl.c | 58 +-
> 1 file changed, 36 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
> index a024f8042259..332210e06e98 100644
> --- a/drivers/misc/aspeed-lpc-ctrl.c
> +++ b/drivers/misc/aspeed-lpc-ctrl.c
> @@ -68,6 +68,7 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file,
> unsigned int cmd,
> unsigned long param)
> {
> struct aspeed_lpc_ctrl *lpc_ctrl = file_aspeed_lpc_ctrl(file);
> + struct device *dev = file->private_data;
> void __user *p = (void __user *)param;
> struct aspeed_lpc_ctrl_mapping map;
> u32 addr;
> @@ -90,6 +91,12 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file,
> unsigned int cmd,
> if (map.window_id != 0)
> return -EINVAL;
>
> + /* If memory-region is not described in device tree */
> + if (!lpc_ctrl->mem_size) {
> + dev_err(dev, "Didn't find reserved memory\n");
> + return -EINVAL;
> + }
> +
> map.size = lpc_ctrl->mem_size;
>
> return copy_to_user(p, , sizeof(map)) ? -EFAULT : 0;
> @@ -126,9 +133,18 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file,
> unsigned int cmd,
> return -EINVAL;
>
> if (map.window_type == ASPEED_LPC_CTRL_WINDOW_FLASH) {
> + if (!lpc_ctrl->pnor_size) {
> + dev_err(dev, "Didn't find host pnor flash\n");
> + return -EINVAL;
> + }
> addr = lpc_ctrl->pnor_base;
> size = lpc_ctrl->pnor_size;
> } else if (map.window_type == ASPEED_LPC_CTRL_WINDOW_MEMORY) {
> + /* If memory-region is not described in device tree */
> + if (!lpc_ctrl->mem_size) {
> + dev_err(dev, "Didn't find reserved memory\n");
> + return -EINVAL;
> + }
> addr = lpc_ctrl->mem_base;
> size = lpc_ctrl->mem_size;
> } else {
> @@ -196,17 +212,17 @@ static int aspeed_lpc_ctrl_probe(struct platform_device
> *pdev)
> if (!lpc_ctrl)
> return -ENOMEM;
>
> + /* If flash is described in device tree then store */
> node = of_parse_phandle(dev->of_node, "flash", 0);
> if (!node) {
> - dev_err(dev, "Didn't find host pnor flash node\n");
> - return -ENODEV;
> - }
> -
> - rc = of_address_to_resource(node, 1, );
> - of_node_put(node);
> - if (rc) {
> - dev_err(dev, "Couldn't address to resource for flash\n");
> - return rc;
> + dev_dbg(dev, "Didn't find host pnor flash node\n");
> + } else {
> + rc = of_address_to_resource(node, 1, );
> + of_node_put(node);
> + if (rc) {
> + dev_err(dev, "Couldn't address to resource for
> flash\n");
> + return rc;
> + }
> }
>
> lpc_ctrl->pnor_size = resource_size();
> @@ -214,22 +230,22 @@ static int aspeed_lpc_ctrl_probe(struct platform_device
> *pdev)
>
> dev_set_drvdata(>dev, lpc_ctrl);
>
> + /* If memory-region is described in device tree then store */
> node = of_parse_phandle(dev->of_node, "memory-region", 0);
> if (!node) {
> - dev_err(dev, "Didn't find reserved memory\n");
> - return -EINVAL;
> - }
> + dev_dbg(dev, "Didn't find reserved memory\n");
> + } else {
> + rc = of_address_to_resource(node, 0, );
> + of_node_put(node);
> + if (rc) {
> + dev_err(dev, "Couldn't address to resource for
> reserved memory\n");
> + return -ENOMEM;
> + }
>
> - rc = of_address_to_resource(node, 0, );
> - of_node_put(node);
> - if (rc) {
> - dev_err(dev, "Couldn't address to resource for reserved
> memory\n");
> - return
Re: uprobes: bug in comm/string output?
On Wed, 16 Jan 2019 11:16:07 +0100
Andreas Ziegler wrote:
>
> I went into this a bit deeper today, and right now it is simply failing
> to parse the code because there is no FETCH_OP_COMM case in
> process_fetch_insn() for uprobes so that will return -EILSEQ, leading to
> a make_data_loc(0, ...) in store_trace_args(). If we just add
> FETCH_OP_COMM and let val point to current->comm (that's what
> trace_kprobe.c does), we get an -EFAULT return value from
> fetch_store_string because strncpy_from_user() checks if the argument is
> in user space.
Correct. I missed to add OP_COMM support. And uprobe's fetch_store_string
is only for user space strings.
> So I think we might need a special case for that, something like
> FETCH_OP_ST_COMM_STRING which is only used for FETCH_OP_COMM and copies
> current->comm over to the dynamic area. The implementation could be
> similar to the old fetch_comm_string implementation before your rewrite.
Hmm, instead, I would like to add current->comm checker and only allows
to copy that. That would be simpler and enough.
Could you test below patch?
tracing: uprobes: Re-enable $comm support for uprobe events
From: Masami Hiramatsu
Since commit 533059281ee5 ("tracing: probeevent: Introduce new
argument fetching code") dropped the $comm support from uprobe
events, this re-enable it.
For $comm support, use strncpy() instead of strncpy_from_user()
to copy current task's comm. Because it is in the kernel space,
strncpy_from_user() always fails to copy the comm.
This also use strlen() instead of strlen_user() to measure the
length of the comm.
Signed-off-by: Masami Hiramatsu
Reported-by: Andreas Ziegler
---
kernel/trace/trace_uprobe.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index e335576b9411..97d134e83e0f 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -156,7 +156,10 @@ fetch_store_string(unsigned long addr, void *dest, void
*base)
if (unlikely(!maxlen))
return -ENOMEM;
- ret = strncpy_from_user(dst, src, maxlen);
+ if (addr == (unsigned long)current->comm)
+ ret = strlcpy(dst, current->comm, maxlen);
+ else
+ ret = strncpy_from_user(dst, src, maxlen);
if (ret >= 0) {
if (ret == maxlen)
dst[ret - 1] = '\0';
@@ -173,7 +176,10 @@ fetch_store_strlen(unsigned long addr)
int len;
void __user *vaddr = (void __force __user *) addr;
- len = strnlen_user(vaddr, MAX_STRING_SIZE);
+ if (addr == (unsigned long)current->comm)
+ len = strlen(current->comm);
+ else
+ len = strnlen_user(vaddr, MAX_STRING_SIZE);
return (len > MAX_STRING_SIZE) ? 0 : len;
}
@@ -213,6 +219,9 @@ process_fetch_insn(struct fetch_insn *code, struct pt_regs
*regs, void *dest,
case FETCH_OP_IMM:
val = code->immediate;
break;
+ case FETCH_OP_COMM:
+ val = (unsigned long)current->comm;
+ break;
case FETCH_OP_FOFFS:
val = translate_user_vaddr(code->immediate);
break;
Re: [PATCH] arm64: dts: qcom: sdm845-mtp: Add WCN3990 BT node
Hi Anderson,
On 2019-01-17 10:10, Bjorn Andersson wrote:
The SDM845 MTP has a WCN3990 Bluetooth chip on UART6, enable this.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 44 +
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index af8c6a2445a2..f65d5a674103 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -17,6 +17,7 @@
aliases {
serial0 =
+ hsuart0 =
};
chosen {
@@ -357,6 +358,10 @@
clock-frequency = <40>;
};
+_id_0 {
+ status = "okay";
+};
+
_id_1 {
status = "okay";
};
@@ -373,6 +378,20 @@
cd-gpios = < 126 GPIO_ACTIVE_LOW>;
};
+ {
+ status = "okay";
+
+ bluetooth {
+ compatible = "qcom,wcn3990-bt";
+
+ vddio-supply = <_s4a_1p8>;
+ vddxo-supply = <_l7a_1p8>;
+ vddrf-supply = <_l17a_1p3>;
+ vddch0-supply = <_l25a_3p3>;
+ max-speed = <320>;
+ };
+};
+
{
status = "okay";
};
@@ -470,6 +489,31 @@
};
};
+_uart6_default {
+ pinmux {
+ pins = "gpio45", "gpio46", "gpio47", "gpio48";
+ function = "qup6";
+ };
+
+ ctsrx {
+ pins = "gpio45", "gpio48";
+ drive-strength = <2>;
+ bias-no-pull;
+ };
+
+ rts {
+ pins = "gpio46";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ tx {
+ pins = "gpio47";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+};
+
_uart9_default {
pinconf-tx {
pins = "gpio4";
[Bala]:
GPIO 45 is CTS
GPIO 46 is RTS
GPIO 47 is Tx
GPIO 48 is Rx.
Tx & RTS are inputs to APPS processor, bias should be disable as
the source i.e. BT chip will pull them up.
CTS & RX are outputs from APPS processor, where as CTS is GPIO
which need to toggled, so the default state should be pull down.
RX is should be pulled up.
when TX & RX are pulled high it indicates that the lines are
ideal i.e. no data.
Above is just my assumption, not sure whether they work on MTP.
--
Regards
Balakrishna.
Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM
On Wed, 2019-01-16 at 08:47 +0100, Ard Biesheuvel wrote: > > As far as I know on x86 it doesn't, so when you have an un-cached page > > you can still access it with a snooping DMA read/write operation and > > don't cause trouble. > > > > I think it is the other way around. The question is, on an otherwise > cache coherent device, whether the NoSnoop attribute set by the GPU > propagates all the way to the bus so that it bypasses the caches. On powerpc it's ignored, all DMA accesses will be snooped. But that's fine regardless of whether the memory was mapped cachable or not, the snooper will simply not find anything if not. I *think* we only do cache inject if the line already exists in one of the caches. > On x86, we can tolerate if this is not the case, since uncached memory > accesses by the CPU snoop the caches as well. > > On other architectures, uncached accesses go straight to main memory, > so if the device wrote anything to the caches we won't see it. Well, on all powerpc implementations that I am aware of at least (dunno about ARM), they do, but we don't have a problem because I don't think the devices can/will write to the caches directly unless a corresponding line already exists (but I might be wrong, we need to double check all implementations which is tricky). I am not aware of any powerpc chip implementing NoSnoop. > So to use this optimization, you have to either be 100% sure that > NoSnoop is implemented correctly, or have a x86 CPU. > > > > The old hack of using non-cached mapping to avoid snoop cost in AGP and > > > others is just that ... an ugly and horrible hacks that should have > > > never eventuated, when the search for performance pushes HW people into > > > utter insanity :) > > > > Well I agree that un-cached system memory makes things much more > > complicated for a questionable gain. > > > > But fact is we now have to deal with the mess, so no point in > > complaining about it to much :) > > > > Indeed. I wonder if we should just disable it altogether unless CONFIG_X86=y The question is whether DMA from a device can instanciate cache lines in your system. This a system specific rather than architecture specific question I suspect... Cheers, Ben.
Re: [PATCH 2/2] x86/mce/amd: carve out MC4_MISC thresholding quirk
On 1/17/2019 12:55 AM, Borislav Petkov wrote: > On Wed, Jan 16, 2019 at 03:10:40PM +, S, Shirish wrote: >> MC4_MISC thresholding quirk needs to be applied during S5 -> S0 and >> S3 -> S0 state transitions, which follow different code paths, hence >> carve it out and move it mce_amd_feature_init(), which is the converging >> point of both code paths. >> >> Changelog[v2]: >> - move the quirk to mce/amd.c > For future reference: changelog lines ... > >> Signed-off-by: Shirish S >> --- > ... land below this line so that they are not part of the commit > message. Understood. >> arch/x86/kernel/cpu/mce/amd.c | 34 ++ >> arch/x86/kernel/cpu/mce/core.c | 29 - >> 2 files changed, 34 insertions(+), 29 deletions(-) >> >> diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c >> index 89298c8..f6a5c96 100644 >> --- a/arch/x86/kernel/cpu/mce/amd.c >> +++ b/arch/x86/kernel/cpu/mce/amd.c >> @@ -545,6 +545,33 @@ prepare_threshold_block(unsigned int bank, unsigned int >> block, u32 addr, >> return offset; >> } >> >> +void mc4_misc_thresholding_quirk(void) > Functions should have a verb in their names. > > I've fixed those and other issues now but make sure you take a look at > those nice documents here, for future reference, when preparing other > patches: > > https://www.kernel.org/doc/html/latest/process/index.html Thanks for the support, i shall follow the practice from next patch onwards. Regards, Shirish S > Thx. > -- Regards, Shirish S
Re: [PATCH] pseries/hotplug: Add more delay in pseries_cpu_die while waiting for rtas-stop
Hello Michael, On Mon, Jan 14, 2019 at 12:11:44PM -0600, Michael Bringmann wrote: > On 1/9/19 12:08 AM, Gautham R Shenoy wrote: > > > I did some testing during the holidays. Here are the observations: > > > > 1) With just your patch (without any additional debug patch), if I run > > DLPAR on /off operations on a system that has SMT=off, I am able to > > see a crash involving RTAS stack corruption within an hour's time. > > > > 2) With the debug patch (appended below) which has additional debug to > > capture the callers of stop-self, start-cpu, set-power-levels, the > > system is able to perform DLPAR on/off operations on a system with > > SMT=off for three days. And then, it crashed with the dead CPU showing > > a "Bad kernel stack pointer". From this log, I can clearly > > see that there were no concurrent calls to stop-self, start-cpu, > > set-power-levels. The only concurrent RTAS calls were the dying CPU > > calling "stop-self", and the CPU running the DLPAR operation calling > > "query-cpu-stopped-state". The crash signature is appended below as > > well. > > > > 3) Modifying your patch to remove the udelay and increase the loop > > count from 25 to 1000 doesn't improve the situation. We are still able > > to see the crash. > > > > 4) With my patch, even without any additional debug, I was able to > > observe the system run the tests successfully for over a week (I > > started the tests before the Christmas weekend, and forgot to turn it > > off!) > > So does this mean that the problem is fixed with your patch? No. On the contrary I think my patch unable to exploit the possible race window. From a technical point of view, Thiago's patch does the right things - It waits for the target CPU to come out of CEDE and set its state to CPU_STATE_OFFLINE. - Only then it then makes the "query-cpu-stopped-state" rtas call in a loop, while giving sufficient delay between successive queries. This reduces the unnecessary rtas-calls. In my patch, I don't do any of this, but simply keep calling "query-cpu-stopped-state" call in a loop for 4000 iterations. That said, if I incorporate the wait for the target CPU to set its state to CPU_STATE_OFFLINE in my patch and then make the "query-cpu-stopped-state" rtas call, then, even I am able to get the crash with the "RTAS CALL BUFFER CORRUPTION" message. I think that incorporating the wait for the target CPU set its state to CPU_STATE_OFFLINE increases the probability that "query-cpu-stopped-state" and "stop-self" rtas calls get called more or less at the same time. However since concurrent invocations of these rtas-calls is allowed by the PAPR, it should not result in a "RTAS CALL BUFFER CORRUPTION". Am I missing something here ? > > > > > It appears that there is a narrow race window involving rtas-stop-self > > and rtas-query-cpu-stopped-state calls that can be observed with your > > patch. Adding any printk's seems to reduce the probability of hitting > > this race window. It might be worth the while to check with RTAS > > folks, if they suspect something here. > > What would the RTAS folks be looking at here? The 'narrow race window' > is with respect to a patch that it sound like we should not be > using. IMHO, if the race-window exists, it would be better to confirm and fix it, given that we have a patch that can exploit it consistently. > > Thanks. > Michael > > -- > Michael W. Bringmann > Linux Technology Center > IBM Corporation > Tie-Line 363-5196 > External: (512) 286-5196 > Cell: (512) 466-0650 > m...@linux.vnet.ibm.com -- Thanks and Regards gautham.
Re: [PATCH v2 1/9] [ALREADY QUEUED] cpufreq: qcom-hw: Move to device_initcall
On 14-01-19, 15:51, Amit Kucheria wrote: > (Resent to allow people testing the series to test it easily) Maybe just share your branch then, instead of sending this again ? -- viresh
Re: [PATCH v2] tracing/uprobes: Fix output for multiple string arguments
On Wed, 16 Jan 2019 15:16:29 +0100
Andreas Ziegler wrote:
> When printing multiple uprobe arguments as strings the output for the
> earlier arguments would also include all later string arguments.
>
> This is best explained in an example:
>
> Consider adding a uprobe to a function receiving two strings as
> parameters which is at offset 0xa0 in strlib.so and we want to print
> both parameters when the uprobe is hit (on x86_64):
>
> $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
> /sys/kernel/debug/tracing/uprobe_events
>
> When the function is called as func("foo", "bar") and we hit the probe,
> the trace file shows a line like the following:
>
> [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
>
> Note the extra "bar" printed as part of arg1. This behaviour stacks up
> for additional string arguments.
>
> The strings are stored in a dynamically growing part of the uprobe
> buffer by fetch_store_string() after copying them from userspace via
> strncpy_from_user(). The return value of strncpy_from_user() is then
> directly used as the required size for the string. However, this does
> not take the terminating null byte into account as the documentation
> for strncpy_from_user() cleary states that it "[...] returns the
> length of the string (not including the trailing NUL)" even though the
> null byte will be copied to the destination.
>
> Therefore, subsequent calls to fetch_store_string() will overwrite
> the terminating null byte of the most recently fetched string with
> the first character of the current string, leading to the
> "accumulation" of strings in earlier arguments in the output.
>
> Fix this by incrementing the return value of strncpy_from_user() by
> one if we did not hit the maximum buffer size.
>
Yeah, I had eventually same conclusion. However, you also have to increse
the return value of fetch_store_strlen() too. (And I found another issue)
Could you fix fetch_store_strlen in the same patch?
Thank you,
> Signed-off-by: Andreas Ziegler
> ---
> v2: removed a wrong check for (ret > 0)
>
> kernel/trace/trace_uprobe.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index e335576b9411..3a1d5ab6b4ba 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -160,6 +160,13 @@ fetch_store_string(unsigned long addr, void *dest, void
> *base)
> if (ret >= 0) {
> if (ret == maxlen)
> dst[ret - 1] = '\0';
> + else
> + /*
> + * Include the terminating null byte. In this case it
> + * was copied by strncpy_from_user but not accounted
> + * for in ret.
> + */
> + ret++;
> *(u32 *)dest = make_data_loc(ret, (void *)dst - base);
> }
>
> --
> 2.17.1
>
--
Masami Hiramatsu
Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM
On Wed, 2019-01-16 at 07:35 +, Koenig, Christian wrote: > No, but you answer the wrong question. > > See we don't want to have different mappings of cached and non-cached on > the CPU, but rather want to know if a snooped DMA from the PCIe counts > as cached access as well. > > As far as I know on x86 it doesn't, so when you have an un-cached page > you can still access it with a snooping DMA read/write operation and > don't cause trouble. Hrm... well, if you map it uncached on the CPU on powerpc, a snoop DMA will work fine too, it won't hit any cache. The only problem I'm aware of is a core (or CAPI device) emiting non-cached load/stores colliding with a cache snooper. > > The old hack of using non-cached mapping to avoid snoop cost in AGP and > > others is just that ... an ugly and horrible hacks that should have > > never eventuated, when the search for performance pushes HW people into > > utter insanity :) > > Well I agree that un-cached system memory makes things much more > complicated for a questionable gain. > > But fact is we now have to deal with the mess, so no point in > complaining about it to much :) I wish we could just sent the HW designers home and tell them we won't support that crap... oh well. Ben. > Cheers, > Christian. > > > Cheers, > > Ben. > > > >
RE: [PATCH 2/3] kbuild: add real-prereqs shorthand for $(filter-out FORCE, $^)
Hi Alexey, > What is this series made on top of? This does not apply on top of master > from > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git If you want to apply this series cleanly, please apply the following first: https://patchwork.kernel.org/patch/10761625/ https://patchwork.kernel.org/patch/10767193/ The conflicts are not significant. You can use 'git am -C1' if you want to apply this series directly to Linus tree. Masahiro
Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)
‐‐‐ Original Message ‐‐‐
On Sunday, December 2, 2018 12:25 PM, Hans de Goede wrote:
> Hi,
>
> On 01-11-18 07:55, Mogens Jensen wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, October 31, 2018 9:29 AM, Hans de Goede hdego...@redhat.com
> > wrote:
> >
> > > Hi,
> > > On 31-10-18 07:02, Mogens Jensen wrote:
> > >
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On Tuesday, October 30, 2018 7:10 PM, Hans de Goede hdego...@redhat.com
> > > > wrote:
> > > >
> > > > > Hi,
> > > > > On 30-10-18 19:56, Mogens Jensen wrote:
> > > > >
> > > > > > ‐‐‐ Original Message ‐‐‐
> > > > > > On Tuesday, October 30, 2018 4:04 PM, Hans de Goede
> > > > > > hdego...@redhat.com wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > > On 30-10-18 16:46, Hans de Goede wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > > On 30-10-18 16:04, Pierre-Louis Bossart wrote:
> > > > > > > >
> > > > > > > > > In addition I am not aware of any baytrail device using
> > > > > > > > > plt_clk_0, so moving a common machine driver such a
> > > > > > > > > cht_bsw_max98090_ti to use plt_clk0 only would break other
> > > > > > > > > devices (e.g. Rambi/Orco). Asking for both clocks to be on
> > > > > > > > > might work though,
> > > > > > > >
> > > > > > > > Ok, so we need to have a DMI based quirk for the Swanky and
> > > > > > > > maybe also
> > > > > > > > the clapper to use plt_clk_0 there. Asking for 2 clks if we
> > > > > > > > only need
> > > > > > > > one does not seem like a good plan.
> > > > > > >
> > > > > > > Dean, Mogens,
> > > > > > > To write a proper patch for this I'm going to need DMI strings
> > > > > > > from your devices.
> > > > > > > Can you please run (as normal user):
> > > > > > > grep . /sys/class/dmi/id/* 2> /dev/null
> > > > > > > And reply with the output of this command?
> > > > > > > I have attached the output from a coreboot seabios based clapper.
> > > > >
> > > > > Thank you.
> > > > >
> > > > > > Should I still test
> > > > > > 0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch
> > > > > > with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and asoundrc from Dean?
> > > > > > There seems to have been some development in the case since that
> > > > > > request was made.
> > > > >
> > > > > Yes please test that, I expect that to also fix things for the
> > > > > Clapper, but I need to have that confirmed before submitting a
> > > > > patch upstream adding a quirk for the Clapper to use pmc_plt_clk_0
> > > > > instead of pmc_plt_clk_3.
> > > > > Regards,
> > > > > Hans
> > > >
> > > > Unfortunately I only have access to longterm kernel 4.14 for
> > > > building/running on this system, and
> > > > 0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch does
> > > > not patch against 4.14.78. Can a test patch for 4.14 be created?
> > >
> > > Can you run (as root):
> > > for i in /sys/kernel/debug/clk/pmc_plt_clk_?; do echo -n "$i: "; cat
> > > $i/clk_flags; echo; done
> > > When running a kernel with working audio?
> > > Then I can confirm that the Clapper is also using pmc_plt_clk_0, so that
> > > I can
> > > fix this for the clapper for 4.18+
> > > I've just checked the 4.14 sources and in 4.14 the
> > > SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH
> > > driver does not support mclk control yet, so for the 4.14 kernel the only
> > > way to
> > > fix this is to revert the 648e921888ad ("clk: x86: Stop marking clocks as
> > > CLK_IS_CRITICAL")
> > > commit.
> > > Regards,
> > > Hans
> >
> > Here is the output from the Clapper with 4.14.78 and working sound:
> > /sys/kernel/debug/clk/pmc_plt_clk_0: 0x0800
> > /sys/kernel/debug/clk/pmc_plt_clk_1: 0x
> > /sys/kernel/debug/clk/pmc_plt_clk_2: 0x
> > /sys/kernel/debug/clk/pmc_plt_clk_3: 0x
> > /sys/kernel/debug/clk/pmc_plt_clk_4: 0x
> > /sys/kernel/debug/clk/pmc_plt_clk_5: 0x
>
> Ok, so your Clapper model indeed is also using clk 0 and not clk 3 as
> expected. I've just submitted a patch upstream adding a quirk for this.
>
> As for what the plan is with 4.14, I don't know. I believe that
> reverting the commit causing the issue there is fine.
>
> Regards,
>
> Hans
Hi,
I have now tried the recently released kernel 4.19.14 on my Chromebook Clapper
as this version now contains the DMI quirk (commit
984bfb398a3af6fa9b7e80165e524933b0616686 upstream).
Kernel is compiled with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and the quirk
seems to have fixed the problem caused by commit 648e921888ad ("clk: x86: Stop
marking clocks as CLK_IS_CRITICAL"), as sound is now working if running
"speaker-test" on my system which is clean ALSA.
Unfortunately, SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH driver is unusable on
Clapper Chromebooks as audio played from everything but "speaker-test" as video
players or web browsers is extremly low and sounds like played at 10x speed. At
the same time kernel log is spammed with messages like this:
max98090 i2c-193C9890:00: PLL unlocked
Re: [PATCH v2 9/9] thermal: cpu_cooling: Clarify error message
On 14-01-19, 15:51, Amit Kucheria wrote:
> Make it clear that it is a failure if the cpufreq driver was unable to
> register as a cooling device. Makes it easier to find in logs and
> grepping for words like fail, err, warn.
>
> Signed-off-by: Amit Kucheria
> ---
> drivers/thermal/cpu_cooling.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index dfd23245f778..6fff16113628 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -774,7 +774,7 @@ of_cpufreq_cooling_register(struct cpufreq_policy *policy)
>
> cdev = __cpufreq_cooling_register(np, policy, capacitance);
> if (IS_ERR(cdev)) {
> - pr_err("cpu_cooling: cpu%d is not running as cooling
> device: %ld\n",
> + pr_err("cpu_cooling: cpu%d failed to register as
> cooling device: %ld\n",
> policy->cpu, PTR_ERR(cdev));
> cdev = NULL;
> }
Always keep such cleanup patches at the top, so the maintainers can
pick them up easily even if the entire series doesn't get in.
Acked-by: Viresh Kumar
--
viresh
[PATCH] driver core: move device->knode_class to device_private
As the description of struct device_private says, it stores data which
is private to driver core. And it already has similar fields like:
knode_parent, knode_driver, knode_driver and knode_bus. This look it is
more proper to put knode_class together with those fields to make it
private to driver core.
This patch move device->knode_class to device_private to make it comply
with code convention.
Signed-off-by: Wei Yang
---
drivers/base/base.h| 4
drivers/base/class.c | 12
drivers/base/core.c| 4 ++--
include/linux/device.h | 1 -
4 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 7a419a7a6235..37329a668935 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -60,6 +60,7 @@ struct driver_private {
* @knode_parent - node in sibling list
* @knode_driver - node in driver list
* @knode_bus - node in bus list
+ * @knode_class - node in class list
* @deferred_probe - entry in deferred_probe_list which is used to retry the
* binding of drivers which were unable to get all the resources needed by
* the device; typically because it depends on another driver getting
@@ -74,6 +75,7 @@ struct device_private {
struct klist_node knode_parent;
struct klist_node knode_driver;
struct klist_node knode_bus;
+ struct klist_node knode_class;
struct list_head deferred_probe;
struct device *device;
};
@@ -83,6 +85,8 @@ struct device_private {
container_of(obj, struct device_private, knode_driver)
#define to_device_private_bus(obj) \
container_of(obj, struct device_private, knode_bus)
+#define to_device_private_class(obj) \
+ container_of(obj, struct device_private, knode_class)
/* initialisation functions */
extern int devices_init(void);
diff --git a/drivers/base/class.c b/drivers/base/class.c
index 54def4e02f00..df7fde599407 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -119,14 +119,16 @@ static void class_put(struct class *cls)
static void klist_class_dev_get(struct klist_node *n)
{
- struct device *dev = container_of(n, struct device, knode_class);
+ struct device_private *p = to_device_private_class(n);
+ struct device *dev = p->device;
get_device(dev);
}
static void klist_class_dev_put(struct klist_node *n)
{
- struct device *dev = container_of(n, struct device, knode_class);
+ struct device_private *p = to_device_private_class(n);
+ struct device *dev = p->device;
put_device(dev);
}
@@ -277,7 +279,7 @@ void class_dev_iter_init(struct class_dev_iter *iter,
struct class *class,
struct klist_node *start_knode = NULL;
if (start)
- start_knode = >knode_class;
+ start_knode = >p->knode_class;
klist_iter_init_node(>p->klist_devices, >ki, start_knode);
iter->type = type;
}
@@ -298,13 +300,15 @@ EXPORT_SYMBOL_GPL(class_dev_iter_init);
struct device *class_dev_iter_next(struct class_dev_iter *iter)
{
struct klist_node *knode;
+ struct device_private *p;
struct device *dev;
while (1) {
knode = klist_next(>ki);
if (!knode)
return NULL;
- dev = container_of(knode, struct device, knode_class);
+ p = to_device_private_class(knode);
+ dev = p->device;
if (!iter->type || iter->type == dev->type)
return dev;
}
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 04bbcd779e11..a624d27d11c0 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1932,7 +1932,7 @@ int device_add(struct device *dev)
if (dev->class) {
mutex_lock(>class->p->mutex);
/* tie the class to the device */
- klist_add_tail(>knode_class,
+ klist_add_tail(>p->knode_class,
>class->p->klist_devices);
/* notify any interfaces that the device is here */
@@ -2069,7 +2069,7 @@ void device_del(struct device *dev)
if (class_intf->remove_dev)
class_intf->remove_dev(dev, class_intf);
/* remove the device from the class list */
- klist_del(>knode_class);
+ klist_del(>p->knode_class);
mutex_unlock(>class->p->mutex);
}
device_remove_file(dev, _attr_uevent);
diff --git a/include/linux/device.h b/include/linux/device.h
index 1b25c7a43f4c..040e97669f94 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1035,7 +1035,6 @@ struct device {
spinlock_t devres_lock;
struct list_headdevres_head;
- struct klist_node knode_class;
struct class*class;
const struct attribute_group **groups; /* optional groups */
--
Re: [PATCH] tools/perf: Remove duplicate header
On Tue, Jan 15, 2019 at 7:29 PM Brajeswar Ghosh wrote: > > Remove duplicate headers which are included more than once > > Signed-off-by: Brajeswar Ghosh Acked-by: Souptick Joarder > --- > tools/perf/builtin-stat.c | 1 - > tools/perf/tests/bp_account.c | 1 - > tools/perf/util/dso.h | 1 - > tools/perf/util/zlib.c| 1 - > 4 files changed, 4 deletions(-) > > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c > index d1028d7755bb..f919ffc4b3b3 100644 > --- a/tools/perf/builtin-stat.c > +++ b/tools/perf/builtin-stat.c > @@ -83,7 +83,6 @@ > #include > #include > #include > -#include > > #include "sane_ctype.h" > > diff --git a/tools/perf/tests/bp_account.c b/tools/perf/tests/bp_account.c > index a20cbc445426..57fc544aedb0 100644 > --- a/tools/perf/tests/bp_account.c > +++ b/tools/perf/tests/bp_account.c > @@ -15,7 +15,6 @@ > #include > #include > #include > -#include > > #include "tests.h" > #include "debug.h" > diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h > index c5380500bed4..722d67a407e2 100644 > --- a/tools/perf/util/dso.h > +++ b/tools/perf/util/dso.h > @@ -8,7 +8,6 @@ > #include > #include > #include "rwsem.h" > -#include > #include > #include "map.h" > #include "namespaces.h" > diff --git a/tools/perf/util/zlib.c b/tools/perf/util/zlib.c > index 902ce6384f57..512ad7c09b13 100644 > --- a/tools/perf/util/zlib.c > +++ b/tools/perf/util/zlib.c > @@ -6,7 +6,6 @@ > #include > #include > #include > -#include > > #include "util/compress.h" > #include "util/util.h" > -- > 2.17.1 >
Re: [PATCH v3 2/2] mfd: tps65218.c: Add input voltage options
On Wed, Jan 16, 2019 at 02:13:36PM +, Lee Jones wrote: > On Mon, 14 Jan 2019, Christian Hohnstaedt wrote: > > > These options apply to all regulators in this chip. > > > > ti,strict-supply-voltage-supervision: > > Set STRICT flag in CONFIG1 > > ti,under-voltage-limit-microvolt: > > Select 2.75, 2.95, 3.25 or 3.35 V UVLO in CONFIG1 > > ti,under-voltage-hyst-microvolt: > > Select 200mV or 400mV UVLOHYS in CONFIG2 > > > > Signed-off-by: Christian Hohnstaedt > > Tested-by: Keerthy > > Reviewed-by: Keerthy > > --- > > drivers/mfd/tps65218.c | 89 > > > > include/linux/mfd/tps65218.h | 4 ++ > > 2 files changed, 93 insertions(+) > > This looks like regulator code. > > Why aren't you placing it into the regulator driver? This code manages properties of the chip, affecting all regulators. The regulator-driver has no hook to be called once for the chip. Even if I put this code into the regulator driver file, I will have to call it from here. This would introduce a dependency from the mfd to the regulator code. Christian
linux-next: Tree for Jan 17
Hi all, Changes since 20190116: The vfs tree still had its build failure for which I applied a patch. The net-next tree gained a conflict against the net tree. The drm-intel tree gained a conflict against the drm tree. The mali-dp tree still had its failure for which I applied a merge fix patch. The block tree lost its bulid failures. I removed a patch from the akpm-current tree that was causing overnight build failures for the SH architecture. Non-merge commits (relative to Linus' tree): 2218 2435 files changed, 74847 insertions(+), 34257 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 295 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (47bfa6d9dc8c Merge tag 'selinux-pr-20190115' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux) Merging fixes/master (0ce4e20ca4ea x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (088b4fc71874 kbuild: mark prepare0 as PHONY to fix external module build) Merging arc-current/for-curr (5fac3149be6f ARC: adjust memblock_reserve of kernel memory) Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential uninitialized return) Merging arm64-fixes/for-next/fixes (7fa1e2e6afa7 kasan, arm64: remove redundant ARCH_SLAB_MINALIGN define) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (7bea7ac0ca01 powerpc/syscalls: Fix syscall tracing) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (a5a82d841186 ipv6: route: place a warning with duplicated string with correct extack) Merging bpf/master (6e8ccb4f624a tools/bpf: properly account for libbfd variations) Merging ipsec/master (35e6103861a3 xfrm: refine validation of template and selector families) Merging netfilter/master (80b3671e9377 ip6_gre: update version related info when changing link) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (ec5aecc0b227 iwlwifi: make IWLWIFI depend on CFG80211) Merging mac80211/master (1d51b4b1d3f2 Merge tag 'm68k-for-v4.20-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k) Merging rdma-fixes/for-rc (d6f4a21f309d RDMA/uverbs: Mark ioctl responses with UVERBS_ATTR_F_VALID_OUTPUT) Merging sound-current/for-linus (687ae9e287b3 ASoC: intel: skl: Fix display power regression) Merging sound-asoc-fixes/for-linus (36c2eef8bb58 Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (b3ffce399349 Merge branch 'regmap-5.0' into regmap-linus) Merging regulator-fixes/for-linus (b4c4aa249eff Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (dd14aa37977c Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (77f88abd4a6f PCI/MSI: Return -ENOSPC from pci_alloc_irq_vectors_affinity()) Merging driver-core.current/driver-core-linus (1c7fc5cbc339 Linux 5.0-rc2) Merging tty.current/tty-linus (1c7fc5cbc339 Linux 5.0-rc2) Merging usb.current/usb-linus (1c7fc5cbc339 Linux 5.0-rc2) Merging us
Re: [PATCH v1 00/10] cpufreq: Add flag to auto-register as cooling device
On 14-01-19, 22:04, Amit Kucheria wrote: > Add a flag to be used by cpufreq drivers to tell cpufreq core to > auto-register themselves as a thermal cooling device. > > There series converts over all the drivers except arm_big_little.c. > Tested on SDM845 with the qcom-cpufreq-hw driver. Only compile-tested the > others. > > Things needing fixing: > - Look at how to detect that we're not in IKS mode in arm_big_little's >.ready callback. is_bL_switching_enabled() lets you know if IKS is enabled or not. Set/clear flag conditionally before the cpufreq-driver is registered, based on the output of is_bL_switching_enabled(). > - The other pending issue is to fix allmodconfig that leaves us with >CPU_FREQ=y and THERMAL=m (CPU_THERMAL=y). That leads to undefined >references for functions defined in cpu_cooling.c Okay, that's a terrible thing and the solution looks to be rather difficult. For others who may not be aware of the issue here, currently the cpufreq drivers use helpers of cpu_cooling.c (CONFIG_CPU_THERMAL), which uses helpers of the thermal core (CONFIG_THERMAL). CONFIG_THERMAL is defined as tristate and CONFIG_CPU_THERMAL as bool in Kconfigs. The cpufreq drivers using the cpu_cooling.c file have this in their Kconfig entry: # if CPU_THERMAL is on and THERMAL=m, ARM_BIT_LITTLE_CPUFREQ cannot be =y # depends on !CPU_THERMAL || THERMAL This series now places the cpufreq core in place of the cpufreq driver and it messes up everything. It is not just about allmodconfig, but any configuration which makes the compilation fail. What are the solutions we have now ? 1. Have following for CONFIG_CPU_FREQ depends on !CPU_THERMAL || THERMAL The platforms which don't need CPU_THERMAL (like x86) should not enable CPU_THERMAL anymore if they want CONFIG_THERMAL=m. @amit: If this gets accepted, please update the Kconfig entries for all those drivers to not have above lines anymore. - Change CONFIG_THERMAL to bool instead of tristate ? - Anything else ? -- viresh
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On 1/16/19 5:08 AM, Jerome Glisse wrote: > On Wed, Jan 16, 2019 at 12:38:19PM +0100, Jan Kara wrote: >> On Tue 15-01-19 09:07:59, Jan Kara wrote: >>> Agreed. So with page lock it would actually look like: >>> >>> get_page_pin() >>> lock_page(page); >>> wait_for_stable_page(); >>> atomic_add(>_refcount, PAGE_PIN_BIAS); >>> unlock_page(page); >>> >>> And if we perform page_pinned() check under page lock, then if >>> page_pinned() returned false, we are sure page is not and will not be >>> pinned until we drop the page lock (and also until page writeback is >>> completed if needed). >> >> After some more though, why do we even need wait_for_stable_page() and >> lock_page() in get_page_pin()? >> >> During writepage page_mkclean() will write protect all page tables. So >> there can be no new writeable GUP pins until we unlock the page as all such >> GUPs will have to first go through fault and ->page_mkwrite() handler. And >> that will wait on page lock and do wait_for_stable_page() for us anyway. >> Am I just confused? > > Yeah with page lock it should synchronize on the pte but you still > need to check for writeback iirc the page is unlocked after file > system has queue up the write and thus the page can be unlock with > write back pending (and PageWriteback() == trye) and i am not sure > that in that states we can safely let anyone write to that page. I > am assuming that in some case the block device also expect stable > page content (RAID stuff). > > So the PageWriteback() test is not only for racing page_mkclean()/ > test_set_page_writeback() and GUP but also for pending write back. That was how I thought it worked too: page_mkclean and a few other things like page migration take the page lock, but writeback takes the lock, queues it up, then drops the lock, and writeback actually happens outside that lock. So on the GUP end, some combination of taking the page lock, and wait_on_page_writeback(), is required in order to flush out the writebacks. I think I just rephrased what Jerome said, actually. :) > > >> That actually touches on another question I wanted to get opinions on. GUP >> can be for read and GUP can be for write (that is one of GUP flags). >> Filesystems with page cache generally have issues only with GUP for write >> as it can currently corrupt data, unexpectedly dirty page etc.. DAX & memory >> hotplug have issues with both (DAX cannot truncate page pinned in any way, >> memory hotplug will just loop in kernel until the page gets unpinned). So >> we probably want to track both types of GUP pins and page-cache based >> filesystems will take the hit even if they don't have to for read-pins? > > Yes the distinction between read and write would be nice. With the map > count solution you can only increment the mapcount for GUP(write=true). > With pin bias the issue is that a big number of read pin can trigger > false positive ie you would do: > GUP(vaddr, write) > ... > if (write) > atomic_add(page->refcount, PAGE_PIN_BIAS) > else > atomic_inc(page->refcount) > > PUP(page, write) > if (write) > atomic_add(page->refcount, -PAGE_PIN_BIAS) > else > atomic_dec(page->refcount) > > I am guessing false positive because of too many read GUP is ok as > it should be unlikely and when it happens then we take the hit. > I'm also intrigued by the point that read-only GUP is harmless, and we could just focus on the writeable case. However, I'm rather worried about actually attempting it, because remember that so far, each call site does no special tracking of each struct page. It just remembers that it needs to do a put_page(), not whether or not that particular page was set up with writeable or read-only GUP. I mean, sure, they often call set_page_dirty before put_page, indicating that it might have been a writeable GUP call, but it seems sketchy to rely on that. So actually doing this could go from merely lots of work, to K*(lots_of_work)... thanks, -- John Hubbard NVIDIA
[PATCH v3,2/3] arm64: dts: Using standard CCF interface to set vcodec clk
Using standard CCF interface to set vdec/venc parent clk
and clk rate.
Signed-off-by: Yunfei Dong
Signed-off-by: Qianqian Yan
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 412ffd4d426b..126d11ee649a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1305,6 +1305,15 @@
"vencpll",
"venc_lt_sel",
"vdec_bus_clk_src";
+ assigned-clocks = < CLK_TOP_VENC_LT_SEL>,
+ < CLK_TOP_CCI400_SEL>,
+ < CLK_TOP_VDEC_SEL>,
+ < CLK_APMIXED_VCODECPLL>,
+ < CLK_APMIXED_VENCPLL>;
+ assigned-clock-parents = <
CLK_TOP_VCODECPLL_370P5>,
+< CLK_TOP_UNIVPLL_D2>,
+< CLK_TOP_VCODECPLL>;
+ assigned-clock-rates = <0>, <0>, <0>, <148200>,
<8>;
};
larb1: larb@1601 {
@@ -1370,6 +1379,10 @@
"venc_sel",
"venc_lt_sel_src",
"venc_lt_sel";
+ assigned-clocks = < CLK_TOP_VENC_SEL>,
+ < CLK_TOP_VENC_LT_SEL>;
+ assigned-clock-parents = < CLK_TOP_VENCPLL_D2>,
+<
CLK_TOP_UNIVPLL1_D2>;
};
vencltsys: clock-controller@1900 {
--
2.20.1
[PATCH v3,3/3] media: mtk-vcodec: Using common interface to manage vdec/venc clock
Vdec: Using standard CCF interface to set parent clock and
clock rate in dtsi and using common interface to open/close
video decoder clock.
Venc: Using standard CCF interface to set parent clock in dtsi
and using common interface to open/close video encoder clock.
Signed-off-by: Yunfei Dong
Signed-off-by: Qianqian Yan
---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 163 ++
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 31 ++--
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 104 ++-
3 files changed, 132 insertions(+), 166 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 79ca03ac449c..7884465afcd2 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -27,11 +27,14 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
struct device_node *node;
struct platform_device *pdev;
struct mtk_vcodec_pm *pm;
- int ret = 0;
+ struct mtk_vcodec_clk *dec_clk;
+ struct mtk_vcodec_clk_info *clk_info;
+ int i = 0, ret = 0;
pdev = mtkdev->plat_dev;
pm = >pm;
pm->mtkdev = mtkdev;
+ dec_clk = >vdec_clk;
node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
if (!node) {
mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
@@ -47,52 +50,34 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
pdev = mtkdev->plat_dev;
pm->dev = >dev;
- pm->vcodecpll = devm_clk_get(>dev, "vcodecpll");
- if (IS_ERR(pm->vcodecpll)) {
- mtk_v4l2_err("devm_clk_get vcodecpll fail");
- ret = PTR_ERR(pm->vcodecpll);
+ dec_clk->clk_num =
+ of_property_count_strings(pdev->dev.of_node, "clock-names");
+ if (dec_clk->clk_num > 0) {
+ dec_clk->clk_info = devm_kcalloc(>dev,
+ dec_clk->clk_num, sizeof(*clk_info),
+ GFP_KERNEL);
+ if (!dec_clk->clk_info)
+ return -ENOMEM;
+ } else {
+ mtk_v4l2_err("Failed to get vdec clock count");
+ return -EINVAL;
}
- pm->univpll_d2 = devm_clk_get(>dev, "univpll_d2");
- if (IS_ERR(pm->univpll_d2)) {
- mtk_v4l2_err("devm_clk_get univpll_d2 fail");
- ret = PTR_ERR(pm->univpll_d2);
- }
-
- pm->clk_cci400_sel = devm_clk_get(>dev, "clk_cci400_sel");
- if (IS_ERR(pm->clk_cci400_sel)) {
- mtk_v4l2_err("devm_clk_get clk_cci400_sel fail");
- ret = PTR_ERR(pm->clk_cci400_sel);
- }
-
- pm->vdec_sel = devm_clk_get(>dev, "vdec_sel");
- if (IS_ERR(pm->vdec_sel)) {
- mtk_v4l2_err("devm_clk_get vdec_sel fail");
- ret = PTR_ERR(pm->vdec_sel);
- }
-
- pm->vdecpll = devm_clk_get(>dev, "vdecpll");
- if (IS_ERR(pm->vdecpll)) {
- mtk_v4l2_err("devm_clk_get vdecpll fail");
- ret = PTR_ERR(pm->vdecpll);
- }
-
- pm->vencpll = devm_clk_get(>dev, "vencpll");
- if (IS_ERR(pm->vencpll)) {
- mtk_v4l2_err("devm_clk_get vencpll fail");
- ret = PTR_ERR(pm->vencpll);
- }
-
- pm->venc_lt_sel = devm_clk_get(>dev, "venc_lt_sel");
- if (IS_ERR(pm->venc_lt_sel)) {
- mtk_v4l2_err("devm_clk_get venc_lt_sel fail");
- ret = PTR_ERR(pm->venc_lt_sel);
- }
-
- pm->vdec_bus_clk_src = devm_clk_get(>dev, "vdec_bus_clk_src");
- if (IS_ERR(pm->vdec_bus_clk_src)) {
- mtk_v4l2_err("devm_clk_get vdec_bus_clk_src");
- ret = PTR_ERR(pm->vdec_bus_clk_src);
+ for (i = 0; i < dec_clk->clk_num; i++) {
+ clk_info = _clk->clk_info[i];
+ ret = of_property_read_string_index(pdev->dev.of_node,
+ "clock-names", i, _info->clk_name);
+ if (ret) {
+ mtk_v4l2_err("Failed to get clock name id = %d", i);
+ return ret;
+ }
+ clk_info->vcodec_clk = devm_clk_get(>dev,
+ clk_info->clk_name);
+ if (IS_ERR(clk_info->vcodec_clk)) {
+ mtk_v4l2_err("devm_clk_get (%d)%s fail", i,
+ clk_info->clk_name);
+ return PTR_ERR(clk_info->vcodec_clk);
+ }
}
pm_runtime_enable(>dev);
@@ -125,78 +110,36 @@ void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm)
void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
{
- int ret;
-
- ret = clk_set_rate(pm->vcodecpll, 1482 * 100);
- if (ret)
- mtk_v4l2_err("clk_set_rate vcodecpll fail %d", ret);
-
- ret = clk_set_rate(pm->vencpll, 800 * 100);
- if (ret)
-
[PATCH v3,1/3] media: dt-bindings: media: add 'assigned-clocks' to vcodec examples
Fix MTK binding document for MT8173 dtsi changed in order
to use standard CCF interface.
MT8173 SoC from Mediatek.
Signed-off-by: Yunfei Dong
Signed-off-by: Qianqian Yan
Reviewed-by: Rob Herring
---
.../devicetree/bindings/media/mediatek-vcodec.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 2a615d84a682..b6b5dde6abd8 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -66,6 +66,15 @@ vcodec_dec: vcodec@1600 {
"vencpll",
"venc_lt_sel",
"vdec_bus_clk_src";
+assigned-clocks = < CLK_TOP_VENC_LT_SEL>,
+ < CLK_TOP_CCI400_SEL>,
+ < CLK_TOP_VDEC_SEL>,
+ < CLK_APMIXED_VCODECPLL>,
+ < CLK_APMIXED_VENCPLL>;
+assigned-clock-parents = < CLK_TOP_VCODECPLL_370P5>,
+ < CLK_TOP_UNIVPLL_D2>,
+ < CLK_TOP_VCODECPLL>;
+assigned-clock-rates = <0>, <0>, <0>, <148200>, <8>;
};
vcodec_enc: vcodec@18002000 {
@@ -105,4 +114,8 @@ vcodec_dec: vcodec@1600 {
"venc_sel",
"venc_lt_sel_src",
"venc_lt_sel";
+assigned-clocks = < CLK_TOP_VENC_SEL>,
+ < CLK_TOP_VENC_LT_SEL>;
+assigned-clock-parents = < CLK_TOP_VENCPLL_D2>,
+ < CLK_TOP_UNIVPLL1_D2>;
};
--
2.20.1
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On 1/15/19 12:07 AM, Jan Kara wrote: > [...] >>> Also there is one more idea I had how to record number of pins in the page: >>> >>> #define PAGE_PIN_BIAS 1024 >>> >>> get_page_pin() >>> atomic_add(>_refcount, PAGE_PIN_BIAS); >>> >>> put_page_pin(); >>> atomic_add(>_refcount, -PAGE_PIN_BIAS); >>> >>> page_pinned(page) >>> (atomic_read(>_refcount) - page_mapcount(page)) > PAGE_PIN_BIAS >>> >>> This is pretty trivial scheme. It still gives us 22-bits for page pins >>> which should be plenty (but we should check for that and bail with error if >>> it would overflow). Also there will be no false negatives and false >>> positives only if there are more than 1024 non-page-table references to the >>> page which I expect to be rare (we might want to also subtract >>> hpage_nr_pages() for radix tree references to avoid excessive false >>> positives for huge pages although at this point I don't think they would >>> matter). Thoughts? Hi Jan, Some details, sorry I'm not fully grasping your plan without more explanation: Do I read it correctly that this uses the lower 10 bits for the original page->_refcount, and the upper 22 bits for gup-pinned counts? If so, I'm surprised, because gup-pinned is going to be less than or equal to the normal (get_page-based) pin count. And 1024 seems like it might be reached in a large system with lots of processes and IPC. Are you just allowing the lower 10 bits to overflow, and that's why the subtraction of mapcount? Wouldn't it be better to allow more than 10 bits, instead? Another question: do we just allow other kernel code to observe this biased _refcount, or do we attempt to filter it out? In other words, do you expect problems due to some kernel code checking the _refcount and finding a large number there, when it expected, say, 3? I recall some code tries to do that...in fact, ZONE_DEVICE is 1-based, instead of zero-based, with respect to _refcount, right? thanks, -- John Hubbard NVIDIA
