* [PATCH 3/4] KVM: arm/arm64: Remove unnecessary CMOs when creating HYP page tables
From: Catalin Marinas @ 2018-05-24 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517103548.5622-4-marc.zyngier@arm.com>
On Thu, May 17, 2018 at 11:35:47AM +0100, Marc Zyngier wrote:
> There is no need to perform cache maintenance operations when
> creating the HYP page tables if we have the multiprocessing
> extensions. ARMv7 mandates them with the virtualization support,
> and ARMv8 just mandates them unconditionally.
>
> Let's remove these operations.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> virt/kvm/arm/mmu.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index ba66bf7ae299..acbfea09578c 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -578,7 +578,6 @@ static void create_hyp_pte_mappings(pmd_t *pmd, unsigned long start,
> pte = pte_offset_kernel(pmd, addr);
> kvm_set_pte(pte, pfn_pte(pfn, prot));
> get_page(virt_to_page(pte));
> - kvm_flush_dcache_to_poc(pte, sizeof(*pte));
> pfn++;
> } while (addr += PAGE_SIZE, addr != end);
> }
> @@ -605,7 +604,6 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned long start,
> }
> pmd_populate_kernel(NULL, pmd, pte);
> get_page(virt_to_page(pmd));
> - kvm_flush_dcache_to_poc(pmd, sizeof(*pmd));
> }
>
> next = pmd_addr_end(addr, end);
> @@ -638,7 +636,6 @@ static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
> }
> pud_populate(NULL, pud, pmd);
> get_page(virt_to_page(pud));
> - kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> }
>
> next = pud_addr_end(addr, end);
> @@ -675,7 +672,6 @@ static int __create_hyp_mappings(pgd_t *pgdp, unsigned long ptrs_per_pgd,
> }
> pgd_populate(NULL, pgd, pud);
> get_page(virt_to_page(pgd));
> - kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
> }
>
> next = pgd_addr_end(addr, end);
> @@ -685,6 +681,7 @@ static int __create_hyp_mappings(pgd_t *pgdp, unsigned long ptrs_per_pgd,
> pfn += (next - addr) >> PAGE_SHIFT;
> } while (addr = next, addr != end);
> out:
> + dsb(ishst);
> mutex_unlock(&kvm_hyp_pgd_mutex);
Why do we need the DSB here? A comment would help.
If a DMB is sufficient, I think mutex_unlock has release semantics.
--
Catalin
^ permalink raw reply
* [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains
From: Jon Hunter @ 2018-05-24 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526639490-12167-10-git-send-email-ulf.hansson@linaro.org>
On 18/05/18 11:31, Ulf Hansson wrote:
> The existing dev_pm_domain_attach() function, allows a single PM domain to
> be attached per device. To be able to support devices that are partitioned
> across multiple PM domains, let's introduce a new interface,
> dev_pm_domain_attach_by_id().
>
> The dev_pm_domain_attach_by_id() returns a new allocated struct device with
> the corresponding attached PM domain. This enables for example a driver to
> operate on the new device from a power management point of view. The driver
> may then also benefit from using the received device, to set up so called
> device-links towards its original device. Depending on the situation, these
> links may then be dynamically changed.
>
> The new interface is typically called by drivers during their probe phase,
> in case they manages devices which uses multiple PM domains. If that is the
> case, the driver also becomes responsible of managing the detaching of the
> PM domains, which typically should be done at the remove phase. Detaching
> is done by calling the existing dev_pm_domain_detach() function and for
> each of the received devices from dev_pm_domain_attach_by_id().
>
> Note, currently its only genpd that supports multiple PM domains per
> device, but dev_pm_domain_attach_by_id() can easily by extended to cover
> other PM domain types, if/when needed.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/base/power/common.c | 33 ++++++++++++++++++++++++++++++++-
> include/linux/pm_domain.h | 7 +++++++
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
> index 7ae62b6..d3db974 100644
> --- a/drivers/base/power/common.c
> +++ b/drivers/base/power/common.c
> @@ -117,13 +117,44 @@ int dev_pm_domain_attach(struct device *dev, bool power_on)
> EXPORT_SYMBOL_GPL(dev_pm_domain_attach);
>
> /**
> + * dev_pm_domain_attach_by_id - Attach a device to one of its PM domains.
Isn't this more of a 'get'?
> + * @index: The index of the PM domain.
> + * @dev: Device to attach.
Isn't this just the device associated with the PM domain we are getting?
> + *
> + * As @dev may only be attached to a single PM domain, the backend PM domain
> + * provider should create a virtual device to attach instead. As attachment
> + * succeeds, the ->detach() callback in the struct dev_pm_domain should be
> + * assigned by the corresponding backend attach function.
> + *
> + * This function should typically be invoked from drivers during probe phase.
> + * Especially for those that manages devices which requires power management
> + * through more than one PM domain.
> + *
> + * Callers must ensure proper synchronization of this function with power
> + * management callbacks.
> + *
> + * Returns the virtual attached device in case successfully attached PM domain,
> + * NULL in case @dev don't need a PM domain, else a PTR_ERR().
Should this be 'NULL in the case where the @dev already has a power-domain'?
> + */
> +struct device *dev_pm_domain_attach_by_id(struct device *dev,
> + unsigned int index)
> +{
> + if (dev->pm_domain)
I wonder if this is worthy of a ...
if (WARN_ON(dev->pm_domain))
> + return NULL;
Don't we consider this an error case? I wonder why not return PTR_ERR
here as well? This would be consistent with dev_pm_domain_attach().
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH 1/6] coresight: remove CORESIGHT_LINKS_AND_SINKS dependencies and selections
From: Mathieu Poirier @ 2018-05-24 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523145155.5929dd09c78a056ef19329be@arm.com>
On 23 May 2018 at 13:51, Kim Phillips <kim.phillips@arm.com> wrote:
> On Tue, 22 May 2018 11:31:40 -0600
> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>
>> On Thu, May 17, 2018 at 08:20:19PM -0500, Kim Phillips wrote:
>> > A coresight topology doesn't need to include links, i.e., a source can
>> > be directly connected to a sink. As such, selecting and/or depending on
>> > LINKS_AND_SINKS is no longer needed.
>>
>> I'm good with this patch but now the help text for CORESIGHT_LINKS_AND_SINKS no
>> longer match what the config does. I see two ways to fix this:
>
> This patch doesn't change what the config does, it just changes what
> other config options depend on it.
>
>> 1) Rework the help text.
>
> I don't see how, given the above. Here's the text:
>
> config CORESIGHT_LINKS_AND_SINKS
> bool "CoreSight Link and Sink drivers"
> help
> This enables support for CoreSight link and sink drivers that are
> responsible for transporting and collecting the trace data
> respectively. Link and sinks are dynamically aggregated with a trace
> entity at run time to form a complete trace path.
>
> What part of that becomes invalid with this patch?
Looking at the new Kconfig, what sink component depend on
CORESIGHT_LINKS_AND_SINKS?
config CORESIGHT_LINKS
bool "CoreSight Link drivers"
help
This enables support for CoreSight link drivers that are responsible
for transporting trace data from source to sink. Links are
dynamically
aggregated with other traces entities at run time to form a
complete trace
path.
>
>> 2) Rework CORESIGHT_LINKS_AND_SINKS to be CORESIGHT_FUNNEL and move
>> coresight-replicator.o under CORESIGHT_DYNAMIC_REPLICATOR in the Makefile. I
>> really liked your idea of making the replicator driver intelligent enough to
>> deal with both DT and platform declaration, which merges two driver into one.
>>
>> I'm obviously favouring the second option but recognise it doesn't have to be
>> part of this patchet. So for this set please rework the help text for
>> CORESIGHT_LINKS_AND_SINKS. Once we've dealt with this topic we can refactor the
>> replicator driver.
>
> I'd really like to just focus on getting CoreSight to load as modules,
> something for which this patch isn't technically required...
The only thing I'm asking is that the config description and help text
reflect what the Makefile does.
>
> Thanks,
>
> Kim
^ permalink raw reply
* [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Sean Wang @ 2018-05-24 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37400FCE-8F9A-433B-8E3A-DE9CBEB469D7@holtmann.org>
On Thu, 2018-05-24 at 09:47 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
> >>>>
> >>>> [ ... ]
[ ... ]
> > I post it as plain text as below
> >
> >
> > Bluetooth monitor ver 5.37
> > = Note: Linux version 4.16.0-rc1+ (aarch64) 0.641494
> > = Note: Bluetooth subsystem version 2.22 0.641502
> > = New Index: 00:00:46:76:22:01 (BR/EDR,UART,hci0) [hci0] 0.641505
> > * Unknown packet (code 14 len 30) 0.641509
> > 01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..............bl
> > 75 65 74 6f 6f 74 68 64 00 00 00 00 00 00 uetoothd......
> > * Unknown packet (code 14 len 30) 0.641592
> > 02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..............bt
> > 6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00 mon...........
> > * Unknown packet (code 16 len 7) [hci0] 6.536771
> > 01 00 00 00 05 00 01 .......
> > = Open Index: 00:00:46:76:22:01 [hci0] 6.717019
> > = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 6.717030
>
> can you try with the latest BlueZ 5.49 or git version. Seems it actually stumbles over the extra packet here. Fun fact is that I can not get a backtrace to pin-point the issue in btmon and why it crashes.
>
I had less experience updating user land BlueZ, but I can try it as possible and see whether Unknown packets still are present at newest version BlueZ. Hopefully I don't misunderstand your point here.
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.741093
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.742088
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.743102
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.744105
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.745109
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.746104
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.747097
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.748090
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.749078
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.750070
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.751061
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.752054
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.753046
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.754038
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.755031
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.756025
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.757013
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758006
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758999
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.759991
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.760983
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.761975
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.762963
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.763956
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.764948
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.765941
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.766933
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.767926
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.768919
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.769914
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.770909
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.771908
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.772904
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.773898
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.774892
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.775890
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.776882
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.777877
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.778871
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.779869
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.780864
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.781858
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.782852
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.783850
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.784845
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.785839
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.786833
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.787831
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.788826
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.789820
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.790814
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.791813
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.792809
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.793803
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.794798
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.795797
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.796791
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.797786
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.798779
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.799778
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.800774
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.801769
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.802763
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.803761
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.804755
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.805749
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.806743
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.807741
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.808737
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.809731
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.810725
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.811725
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.812719
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.813714
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.814708
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.815705
> > 02 01 01 00 00 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816378
> > 02 01 01 00 00 .....
>
> Why do I see only HCI events here? Is this event conveying any useful information. It is kinda complicated that this is 0xe4 event code which is actually reserved for future use by the Bluetooth SIG. Are there any accompanying HCI commands for this and they just not make it into btmon?
>
I have made all vendor HCI commands go through BlueZ core in v2 patch.
And for these HCI events, they are all corresponding to vendor ACL data, applied only to firmware setup packets, but they're not being sent via BlueZ core, so they are not being logged in btmon.
As for its event, where heading 0xe4 refers to a vendor event and is used on notification of that either vendor ACL data or vendor HCI command have been done.
>
>
> > < HCI Command: Vendor (0x3f|0x006f) plen 5 [hci0] 6.816413
> > 01 07 01 00 04 .....
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816536
> > 02 07 01 00 00 .....
> > < HCI Command: Vendor (0x3f|0x006f) plen 6 [hci0] 8.845071
> > 01 06 02 00 00 01 ......
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 8.923456
> > 02 06 01 00 00 .....
>
> Here it looks like you have 0x006f opcode with first octet 0x01 for command and then vendor event 0xe4 with first octet 0x02 for event. I assume the second octet is then the vendor command code for these.
>
Yes, you're right.
> > < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 10.861118
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.865763
> > Reset (0x03|0x0003) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Read Local Supported Fe.. (0x04|0x0003) plen 0 [hci0] 10.865805
> >> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.865965
> > Read Local Supported Features (0x04|0x0003) ncmd 1
> > Status: Success (0x00)
> > Features: 0xbf 0x3e 0x8d 0xfe 0xdb 0xff 0x7b 0x87
> > 3 slot packets
> > 5 slot packets
> > Encryption
> > Slot offset
> > Timing accuracy
> > Role switch
> > Sniff mode
> > Power control requests
> > Channel quality driven data rate (CQDDR)
> > SCO link
> > HV2 packets
> > HV3 packets
> > CVSD synchronous data
> > Power control
> > Transparent synchronous data
> > Broadcast Encryption
> > Enhanced Data Rate ACL 2 Mbps mode
> > Enhanced Data Rate ACL 3 Mbps mode
> > Enhanced inquiry scan
> > Interlaced inquiry scan
> > Interlaced page scan
> > RSSI with inquiry results
> > Extended SCO link (EV3 packets)
> > EV4 packets
> > EV5 packets
> > AFH capable slave
> > AFH classification slave
> > LE Supported (Controller)
> > 3-slot Enhanced Data Rate ACL packets
> > 5-slot Enhanced Data Rate ACL packets
> > Sniff subrating
> > Pause encryption
> > AFH capable master
> > AFH classification master
> > Enhanced Data Rate eSCO 2 Mbps mode
> > Enhanced Data Rate eSCO 3 Mbps mode
> > 3-slot Enhanced Data Rate eSCO packets
> > Extended Inquiry Response
> > Simultaneous LE and BR/EDR (Controller)
> > Secure Simple Pairing
> > Encapsulated PDU
> > Erroneous Data Reporting
> > Non-flushable Packet Boundary Flag
> > Link Supervision Timeout Changed Event
> > Inquiry TX Power Level
> > Enhanced Power Control
> > Extended features
> > < HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0 [hci0] 10.865987
> >> HCI Event: Vendor (0xff) plen 9 [hci0] 10.866259
> > 29 19 09 17 20 48 07 11 00 )... H?
>
> Is this meant to happen here?
>
If event received is not expected as the specification defines, I think it's probably incorrect.
But it requires more discussion with firmware people to make it clearer.
> >> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.866372
> > Read Local Version Information (0x04|0x0001) ncmd 1
> > Status: Success (0x00)
> > HCI version: Bluetooth 4.2 (0x08) - Revision 4359 (0x1107)
> > LMP version: Bluetooth 4.2 (0x08) - Subversion 2329 (0x0919)
> > Manufacturer: MediaTek, Inc. (70)
> > < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 [hci0] 10.866391
> >> HCI Event: Command Complete (0x0e) plen 10 [hci0] 10.866539
> > Read BD ADDR (0x04|0x0009) ncmd 1
> > Status: Success (0x00)
> > Address: 00:00:46:76:22:01 (OLIVETTI NORTH AMERICA)
> > < HCI Command: Read Buffer Size (0x04|0x0005) plen 0 [hci0] 10.866609
> >> HCI Event: Command Complete (0x0e) plen 11 [hci0] 10.866754
> > Read Buffer Size (0x04|0x0005) ncmd 1
> > Status: Success (0x00)
> > ACL MTU: 1021 ACL max packet: 8
> > SCO MTU: 184 SCO max packet: 1
> > < HCI Command: Read Class of Device (0x03|0x0023) plen 0 [hci0] 10.866775
> >> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.866920
> > Read Class of Device (0x03|0x0023) ncmd 1
> > Status: Success (0x00)
> > Class: 0x001f00
> > Major class: Uncategorized, specific device code not specified
> > Minor class: 0x00
> > < HCI Command: Read Local Name (0x03|0x0014) plen 0 [hci0] 10.866939
> >> HCI Event: Command Complete (0x0e) plen 252 [hci0] 10.867256
> > Read Local Name (0x03|0x0014) ncmd 1
> > Status: Success (0x00)
> > Name: MTK MT7622 #1
> > < HCI Command: Read Voice Setting (0x03|0x0025) plen 0 [hci0] 10.867308
> >> HCI Event: Command Complete (0x0e) plen 6 [hci0] 10.867447
> > Read Voice Setting (0x03|0x0025) ncmd 1
> > Status: Success (0x00)
> > Setting: 0x0060
> > Input Coding: Linear
> > Input Data Format: 2's complement
> > Input Sample Size: 16-bit
> > # of bits padding at MSB: 0
> > Air Coding Format: CVSD
> > < HCI Command: Read Number of Supporte.. (0x03|0x0038) plen 0 [hci0] 10.867474
> >> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.867611
> > Read Number of Supported IAC (0x03|0x0038) ncmd 1
> > Status: Success (0x00)
> > Number of IAC: 4
> > < HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 [hci0] 10.867678
> >> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.867865
> > Read Current IAC LAP (0x03|0x0039) ncmd 1
> > Status: Success (0x00)
> > Number of IAC: 1
> > Access code: 0x9e8b33 (General Inquiry)
> > < HCI Command: Set Event Filter (0x03|0x0005) plen 1 [hci0] 10.867890
> > Type: Clear All Filters (0x00)
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868033
> > Set Event Filter (0x03|0x0005) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Write Connection Accept.. (0x03|0x0016) plen 2 [hci0] 10.868054
> > Timeout: 20000.000 msec (0x7d00)
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868235
> > Write Connection Accept Timeout (0x03|0x0016) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: LE Read Buffer Size (0x08|0x0002) plen 0 [hci0] 10.868262
> >> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.868392
> > LE Read Buffer Size (0x08|0x0002) ncmd 1
> > Status: Success (0x00)
> > Data packet length: 251
> > Num data packets: 8
> > < HCI Command: LE Read Local Supported.. (0x08|0x0003) plen 0 [hci0] 10.868413
> >> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868587
> > LE Read Local Supported Features (0x08|0x0003) ncmd 1
> > Status: Success (0x00)
> > Features: 0xfd 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> > LE Encryption
> > Extended Reject Indication
> > Slave-initiated Features Exchange
> > LE Ping
> > LE Data Packet Length Extension
> > LL Privacy
> > Extended Scanner Filter Policies
> > < HCI Command: LE Read Supported States (0x08|0x001c) plen 0 [hci0] 10.868646
> >> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868787
> > LE Read Supported States (0x08|0x001c) ncmd 1
> > Status: Success (0x00)
> > States: 0x000000001fffffff
> > Non-connectable Advertising State
> > Scannable Advertising State
> > Connectable Advertising State
> > High Duty Cycle Directed Advertising State
> > Passive Scanning State
> > Active Scanning State
> > Initiating State
> > and Connection State (Master Role)
> > Connection State (Slave Role)
> > Non-connectable Advertising State
> > and Passive Scanning State
> > Scannable Advertising State
> > and Passive Scanning State
> > Connectable Advertising State
> > and Passive Scanning State
> > High Duty Cycle Directed Advertising State
> > and Passive Scanning State
> > Non-connectable Advertising State
> > and Active Scanning State
> > Scannable Advertising State
> > and Active Scanning State
> > Connectable Advertising State
> > and Active Scanning State
> > High Duty Cycle Directed Advertising State
> > and Active Scanning State
> > Non-connectable Advertising State
> > and Initiating State
> > Scannable Advertising State
> > and Initiating State
> > Non-connectable Advertising State
> > and Connection State (Master Role)
> > Scannable Advertising State
> > and Connection State (Master Role)
> > Non-connectable Advertising State
> > and Connection State (Slave Role)
> > Scannable Advertising State
> > and Connection State (Slave Role)
> > Passive Scanning State
> > and Initiating State
> > Active Scanning State
> > and Initiating State
> > Passive Scanning State
> > and Connection State (Master Role)
> > Active Scanning State
> > and Connection State (Master Role)
> > Passive Scanning State
> > and Connection State (Slave Role)
> > Active Scanning State
> > and Connection State (Slave Role)
> > Initiating State
> > and Connection State (Master Role)
> > and Master Role & Master Role
> > < HCI Command: Read Local Supported Co.. (0x04|0x0002) plen 0 [hci0] 10.868807
> >> HCI Event: Command Complete (0x0e) plen 68 [hci0] 10.868985
> > Read Local Supported Commands (0x04|0x0002) ncmd 1
> > Status: Success (0x00)
> > Commands: 176 entries
> > Inquiry (Octet 0 - Bit 0)
> > Inquiry Cancel (Octet 0 - Bit 1)
> > Periodic Inquiry Mode (Octet 0 - Bit 2)
> > Exit Periodic Inquiry Mode (Octet 0 - Bit 3)
> > Create Connection (Octet 0 - Bit 4)
> > Disconnect (Octet 0 - Bit 5)
> > Add SCO Connection (Octet 0 - Bit 6)
> > Create Connection Cancel (Octet 0 - Bit 7)
> > Accept Connection Request (Octet 1 - Bit 0)
> > Reject Connection Request (Octet 1 - Bit 1)
> > Link Key Request Reply (Octet 1 - Bit 2)
> > Link Key Request Negative Reply (Octet 1 - Bit 3)
> > PIN Code Request Reply (Octet 1 - Bit 4)
> > PIN Code Request Negative Reply (Octet 1 - Bit 5)
> > Change Connection Packet Type (Octet 1 - Bit 6)
> > Authentication Requested (Octet 1 - Bit 7)
> > Set Connection Encryption (Octet 2 - Bit 0)
> > Change Connection Link Key (Octet 2 - Bit 1)
> > Master Link Key (Octet 2 - Bit 2)
> > Remote Name Request (Octet 2 - Bit 3)
> > Remote Name Request Cancel (Octet 2 - Bit 4)
> > Read Remote Supported Features (Octet 2 - Bit 5)
> > Read Remote Extended Features (Octet 2 - Bit 6)
> > Read Remote Version Information (Octet 2 - Bit 7)
> > Read Clock Offset (Octet 3 - Bit 0)
> > Read LMP Handle (Octet 3 - Bit 1)
> > Sniff Mode (Octet 4 - Bit 2)
> > Exit Sniff Mode (Octet 4 - Bit 3)
> > QoS Setup (Octet 4 - Bit 6)
> > Role Discovery (Octet 4 - Bit 7)
> > Switch Role (Octet 5 - Bit 0)
> > Read Link Policy Settings (Octet 5 - Bit 1)
> > Write Link Policy Settings (Octet 5 - Bit 2)
> > Read Default Link Policy Settings (Octet 5 - Bit 3)
> > Write Default Link Policy Settings (Octet 5 - Bit 4)
> > Flow Specification (Octet 5 - Bit 5)
> > Set Event Mask (Octet 5 - Bit 6)
> > Reset (Octet 5 - Bit 7)
> > Set Event Filter (Octet 6 - Bit 0)
> > Flush (Octet 6 - Bit 1)
> > Read PIN Type (Octet 6 - Bit 2)
> > Write PIN Type (Octet 6 - Bit 3)
> > Create New Unit Key (Octet 6 - Bit 4)
> > Read Stored Link Key (Octet 6 - Bit 5)
> > Write Stored Link Key (Octet 6 - Bit 6)
> > Delete Stored Link Key (Octet 6 - Bit 7)
> > Write Local Name (Octet 7 - Bit 0)
> > Read Local Name (Octet 7 - Bit 1)
> > Read Connection Accept Timeout (Octet 7 - Bit 2)
> > Write Connection Accept Timeout (Octet 7 - Bit 3)
> > Read Page Timeout (Octet 7 - Bit 4)
> > Write Page Timeout (Octet 7 - Bit 5)
> > Read Scan Enable (Octet 7 - Bit 6)
> > Write Scan Enable (Octet 7 - Bit 7)
> > Read Page Scan Activity (Octet 8 - Bit 0)
> > Write Page Scan Activity (Octet 8 - Bit 1)
> > Read Inquiry Scan Activity (Octet 8 - Bit 2)
> > Write Inquiry Scan Activity (Octet 8 - Bit 3)
> > Read Authentication Enable (Octet 8 - Bit 4)
> > Write Authentication Enable (Octet 8 - Bit 5)
> > Read Encryption Mode (Octet 8 - Bit 6)
> > Write Encryption Mode (Octet 8 - Bit 7)
> > Read Class of Device (Octet 9 - Bit 0)
> > Write Class of Device (Octet 9 - Bit 1)
> > Read Voice Setting (Octet 9 - Bit 2)
> > Write Voice Setting (Octet 9 - Bit 3)
> > Read Automatic Flush Timeout (Octet 9 - Bit 4)
> > Write Automatic Flush Timeout (Octet 9 - Bit 5)
> > Read Num Broadcast Retransmissions (Octet 9 - Bit 6)
> > Write Num Broadcast Retransmissions (Octet 9 - Bit 7)
> > Read Transmit Power Level (Octet 10 - Bit 2)
> > Read Sync Flow Control Enable (Octet 10 - Bit 3)
> > Write Sync Flow Control Enable (Octet 10 - Bit 4)
> > Set Controller To Host Flow Control (Octet 10 - Bit 5)
> > Host Buffer Size (Octet 10 - Bit 6)
> > Host Number of Completed Packets (Octet 10 - Bit 7)
> > Read Link Supervision Timeout (Octet 11 - Bit 0)
> > Write Link Supervision Timeout (Octet 11 - Bit 1)
> > Read Number of Supported IAC (Octet 11 - Bit 2)
> > Read Current IAC LAP (Octet 11 - Bit 3)
> > Write Current IAC LAP (Octet 11 - Bit 4)
> > Read Page Scan Mode (Octet 11 - Bit 7)
> > Write Page Scan Mode (Octet 12 - Bit 0)
> > Set AFH Host Channel Classification (Octet 12 - Bit 1)
> > Read Inquiry Scan Type (Octet 12 - Bit 4)
> > Write Inquiry Scan Type (Octet 12 - Bit 5)
> > Read Inquiry Mode (Octet 12 - Bit 6)
> > Write Inquiry Mode (Octet 12 - Bit 7)
> > Read Page Scan Type (Octet 13 - Bit 0)
> > Write Page Scan Type (Octet 13 - Bit 1)
> > Read AFH Channel Assessment Mode (Octet 13 - Bit 2)
> > Write AFH Channel Assessment Mode (Octet 13 - Bit 3)
> > Read Local Version Information (Octet 14 - Bit 3)
> > Read Local Supported Features (Octet 14 - Bit 5)
> > Read Local Extended Features (Octet 14 - Bit 6)
> > Read Buffer Size (Octet 14 - Bit 7)
> > Read Country Code (Octet 15 - Bit 0)
> > Read BD ADDR (Octet 15 - Bit 1)
> > Read Failed Contact Counter (Octet 15 - Bit 2)
> > Reset Failed Contact Counter (Octet 15 - Bit 3)
> > Read Link Quality (Octet 15 - Bit 4)
> > Read RSSI (Octet 15 - Bit 5)
> > Read AFH Channel Map (Octet 15 - Bit 6)
> > Read Clock (Octet 15 - Bit 7)
> > Read Loopback Mode (Octet 16 - Bit 0)
> > Write Loopback Mode (Octet 16 - Bit 1)
> > Enable Device Under Test Mode (Octet 16 - Bit 2)
> > Setup Synchronous Connection (Octet 16 - Bit 3)
> > Accept Synchronous Connection Request (Octet 16 - Bit 4)
> > Reject Synchronous Connection Request (Octet 16 - Bit 5)
> > Read Extended Inquiry Response (Octet 17 - Bit 0)
> > Write Extended Inquiry Response (Octet 17 - Bit 1)
> > Refresh Encryption Key (Octet 17 - Bit 2)
> > Sniff Subrating (Octet 17 - Bit 4)
> > Read Simple Pairing Mode (Octet 17 - Bit 5)
> > Write Simple Pairing Mode (Octet 17 - Bit 6)
> > Read Local OOB Data (Octet 17 - Bit 7)
> > Read Inquiry Response TX Power Level (Octet 18 - Bit 0)
> > Write Inquiry Transmit Power Level (Octet 18 - Bit 1)
> > Read Default Erroneous Data Reporting (Octet 18 - Bit 2)
> > Write Default Erroneous Data Reporting (Octet 18 - Bit 3)
> > IO Capability Request Reply (Octet 18 - Bit 7)
> > User Confirmation Request Reply (Octet 19 - Bit 0)
> > User Confirmation Request Neg Reply (Octet 19 - Bit 1)
> > User Passkey Request Reply (Octet 19 - Bit 2)
> > User Passkey Request Negative Reply (Octet 19 - Bit 3)
> > Remote OOB Data Request Reply (Octet 19 - Bit 4)
> > Write Simple Pairing Debug Mode (Octet 19 - Bit 5)
> > Enhanced Flush (Octet 19 - Bit 6)
> > Remote OOB Data Request Neg Reply (Octet 19 - Bit 7)
> > Send Keypress Notification (Octet 20 - Bit 2)
> > IO Capability Request Negative Reply (Octet 20 - Bit 3)
> > Read Encryption Key Size (Octet 20 - Bit 4)
> > Set Event Mask Page 2 (Octet 22 - Bit 2)
> > Read Enhanced Transmit Power Level (Octet 24 - Bit 0)
> > Enhanced Setup Synchronous Connection (Octet 29 - Bit 3)
> > Enhanced Accept Synchronous Connection Request (Octet 29 - Bit 4)
> > Read Local Supported Codecs (Octet 29 - Bit 5)
> > Set Triggered Clock Capture (Octet 30 - Bit 5)
> > Truncated Page (Octet 30 - Bit 6)
> > Truncated Page Cancel (Octet 30 - Bit 7)
> > Set Connectionless Slave Broadcast (Octet 31 - Bit 0)
> > Start Synchronization Train (Octet 31 - Bit 2)
> > Set Reserved LT_ADDR (Octet 31 - Bit 4)
> > Delete Reserved LT_ADDR (Octet 31 - Bit 5)
> > Set Connectionless Slave Broadcast Data (Octet 31 - Bit 6)
> > Read Synchronization Train Parameters (Octet 31 - Bit 7)
> > Write Synchronization Train Parameters (Octet 32 - Bit 0)
> > Remote OOB Extended Data Request Reply (Octet 32 - Bit 1)
> > Read Authenticated Payload Timeout (Octet 32 - Bit 4)
> > Write Authenticated Payload Timeout (Octet 32 - Bit 5)
> > Read Local OOB Extended Data (Octet 32 - Bit 6)
> > Write Secure Connections Test Mode (Octet 32 - Bit 7)
> > Read Extended Page Timeout (Octet 33 - Bit 0)
> > Write Extended Page Timeout (Octet 33 - Bit 1)
> > Read Extended Inquiry Length (Octet 33 - Bit 2)
> > Write Extended Inquiry Length (Octet 33 - Bit 3)
> > LE Set Data Length (Octet 33 - Bit 6)
> > LE Read Suggested Default Data Length (Octet 33 - Bit 7)
> > LE Write Suggested Default Data Length (Octet 34 - Bit 0)
> > LE Read Local P-256 Public Key (Octet 34 - Bit 1)
> > LE Generate DHKey (Octet 34 - Bit 2)
> > LE Add Device To Resolving List (Octet 34 - Bit 3)
> > LE Remove Device From Resolving List (Octet 34 - Bit 4)
> > LE Clear Resolving List (Octet 34 - Bit 5)
> > LE Read Resolving List Size (Octet 34 - Bit 6)
> > LE Read Peer Resolvable Address (Octet 34 - Bit 7)
> > LE Read Local Resolvable Address (Octet 35 - Bit 0)
> > LE Set Address Resolution Enable (Octet 35 - Bit 1)
> > LE Set Resolvable Private Address Timeout (Octet 35 - Bit 2)
> > LE Read Maximum Data Length (Octet 35 - Bit 3)
> > Octet 35 - Bit 4
> > Octet 35 - Bit 5
> > Octet 35 - Bit 6
> > Octet 35 - Bit 7
> > Octet 36 - Bit 0
>
> So you support the PHY commands, but do not indicate support LE 2M or LE Coded? Also these are Bluetooth 5.0 commands.
>
To be honest. When I ported the device into Bluez core, a unexpected event for LE read local feature would cause a fail at Bluez core, so I made a hack on Bluez core
to allow that I can keeping bring up the device without be blocked by the issue most probably from firmware.
Below code snippet is the only thing I added to avoid a fail at Bluez core to bring up the device.
@@ -927,6 +927,8 @@ static void hci_cc_le_read_local_features(struct hci_dev *hdev,
return;
memcpy(hdev->le_features, rp->features, 8);
+ hdev->le_features[0] = 0;
+ hdev->le_features[1] = 0;
}
> > < HCI Command: Write Simple Pairing Mode (0x03|0x0056) plen 1 [hci0] 10.869023
> > Mode: Enabled (0x01)
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.869185
> > Write Simple Pairing Mode (0x03|0x0056) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Write Inquiry Mode (0x03|0x0045) plen 1 [hci0] 10.869239
> > Mode: Inquiry Result with RSSI or Extended Inquiry Result (0x02)
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.869371
> > Write Inquiry Mode (0x03|0x0045) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Read Inquiry Response T.. (0x03|0x0058) plen 0 [hci0] 10.869396
> >> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.869552
> > Read Inquiry Response TX Power Level (0x03|0x0058) ncmd 1
> > Status: Success (0x00)
> > TX power: -1 dBm
> > < HCI Command: Read Local Extended Fea.. (0x04|0x0004) plen 1 [hci0] 10.869572
> > Page: 1
> >> HCI Event: Command Complete (0x0e) plen 14 [hci0] 10.869729
> > Read Local Extended Features (0x04|0x0004) ncmd 1
> > Status: Success (0x00)
> > Page: 1/2
> > Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> > Secure Simple Pairing (Host Support)
> > < HCI Command: Set Event Mask (0x03|0x0001) plen 8 [hci0] 10.869783
> > Mask: 0x3dbff807fffbffff
> > Inquiry Complete
> > Inquiry Result
> > Connection Complete
> > Connection Request
> > Disconnection Complete
> > Authentication Complete
> > Remote Name Request Complete
> > Encryption Change
> > Change Connection Link Key Complete
> > Master Link Key Complete
> > Read Remote Supported Features Complete
> > Read Remote Version Information Complete
> > QoS Setup Complete
> > Command Complete
> > Command Status
> > Hardware Error
> > Flush Occurred
> > Role Change
> > Mode Change
> > Return Link Keys
> > PIN Code Request
> > Link Key Request
> > Link Key Notification
> > Loopback Command
> > Data Buffer Overflow
> > Max Slots Change
> > Read Clock Offset Complete
> > Connection Packet Type Changed
> > QoS Violation
> > Page Scan Mode Change
> > Page Scan Repetition Mode Change
> > Flow Specification Complete
> > Inquiry Result with RSSI
> > Read Remote Extended Features Complete
> > Synchronous Connection Complete
> > Synchronous Connection Changed
> > Sniff Subrating
> > Extended Inquiry Result
> > Encryption Key Refresh Complete
> > IO Capability Request
> > IO Capability Request Reply
> > User Confirmation Request
> > User Passkey Request
> > Remote OOB Data Request
> > Simple Pairing Complete
> > Link Supervision Timeout Changed
> > Enhanced Flush Complete
> > User Passkey Notification
> > Keypress Notification
> > Remote Host Supported Features Notification
> > LE Meta
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.869921
> > Set Event Mask (0x03|0x0001) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Read Stored Link Key (0x03|0x000d) plen 7 [hci0] 10.869947
> > Address: 00:00:00:00:00:00 (OUI 00-00-00)
> > Read all: 0x01
> >> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.870129
> > Read Stored Link Key (0x03|0x000d) ncmd 1
> > Status: Success (0x00)
> > Max num keys: 4
> > Num keys: 0
> > < HCI Command: Write Default Link Poli.. (0x02|0x000f) plen 2 [hci0] 10.870148
> > Link policy: 0x0005
> > Enable Role Switch
> > Enable Sniff Mode
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.870310
> > Write Default Link Policy Settings (0x02|0x000f) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Read Page Scan Activity (0x03|0x001b) plen 0 [hci0] 10.870331
> >> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.870485
> > Read Page Scan Activity (0x03|0x001b) ncmd 1
> > Status: Success (0x00)
> > Interval: 1280.000 msec (0x0800)
> > Window: 11.250 msec (0x0012)
> > < HCI Command: Read Page Scan Type (0x03|0x0046) plen 0 [hci0] 10.870504
> >> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.870652
> > Read Page Scan Type (0x03|0x0046) ncmd 1
> > Status: Success (0x00)
> > Type: Standard Scan (0x00)
> > < HCI Command: LE Set Event Mask (0x08|0x0001) plen 8 [hci0] 10.870671
> > Mask: 0x0000000000000980
> > LE Read Local P-256 Public Key Complete
> > LE Generate DHKey Complete
> > Unknown mask (0x0000000000000800)
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.870839
> > LE Set Event Mask (0x08|0x0001) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Write LE Host Supported (0x03|0x006d) plen 2 [hci0] 10.870859
> > Supported: 0x01
> > Simultaneous: 0x00
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.871028
> > Write LE Host Supported (0x03|0x006d) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Read Local Extended Fea.. (0x04|0x0004) plen 1 [hci0] 10.871059
> > Page: 2
> >> HCI Event: Command Complete (0x0e) plen 14 [hci0] 10.871201
> > Read Local Extended Features (0x04|0x0004) ncmd 1
> > Status: Success (0x00)
> > Page: 2/2
> > Features: 0x25 0x0b 0x00 0x00 0x00 0x00 0x00 0x00
> > Connectionless Slave Broadcast - Master
> > Synchronization Train
> > Generalized interlaced scan
> > Secure Connections (Controller Support)
> > Ping
> > Train nudging
> > < HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7 [hci0] 10.871240
> > Address: 00:00:00:00:00:00 (OUI 00-00-00)
> > Delete all: 0x01
> >> HCI Event: Command Complete (0x0e) plen 6 [hci0] 10.871384
> > Delete Stored Link Key (0x03|0x0012) ncmd 1
> > Status: Success (0x00)
> > Num keys: 0
> > < HCI Command: Set Event Mask Page 2 (0x03|0x0063) plen 8 [hci0] 10.871403
> > Mask: 0x0000000000b0c000
> > Triggered Clock Capture
> > Synchronization Train Complete
> > Slave Page Response Timeout
> > Connectionless Slave Broadcast Channel Map Change
> > Authenticated Payload Timeout Expired
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.871566
> > Set Event Mask Page 2 (0x03|0x0063) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Read Local Supported Co.. (0x04|0x000b) plen 0 [hci0] 10.871599
> >> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.871750
> > Read Local Supported Codecs (0x04|0x000b) ncmd 1
> > Status: Success (0x00)
> > Number of supported codecs: 2
> > Codec: CVSD (0x02)
> > Codec: Transparent (0x03)
> > Number of vendor codecs: 0
> > < HCI Command: Read Synchronization Tr.. (0x03|0x0077) plen 0 [hci0] 10.871769
> >> HCI Event: Command Complete (0x0e) plen 11 [hci0] 10.871928
> > Read Synchronization Train Parameters (0x03|0x0077) ncmd 1
> > Status: Success (0x00)
> > Interval: 0.000 msec (0x0000)
> > Timeout: 0.000 msec (0x00000000)
> > Service data: 0x00
> > < HCI Command: Write Secure Connection.. (0x03|0x007a) plen 1 [hci0] 10.871947
> > Support: Enabled (0x01)
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872098
> > Write Secure Connections Host Support (0x03|0x007a) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Unknown (0x08|0x0031) plen 3 [hci0] 10.872156
> > 03 00 00 ...
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872322
> > Unknown (0x08|0x0031) ncmd 1
> > Status: Success (0x00)
> > = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 10.872361
>
> This extra index info worries me a little bit. I need to check if that is suppose to happen.
> > < HCI Command: LE Set Scan Response D.. (0x08|0x0009) plen 32 [hci0] 10.872431
> > Length: 10
> > Name (complete): builder
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872606
> > LE Set Scan Response Data (0x08|0x0009) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Write Scan Enable (0x03|0x001a) plen 1 [hci0] 10.872627
> > Scan enable: Page Scan (0x02)
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.872819
> > Write Scan Enable (0x03|0x001a) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Write Class of Device (0x03|0x0024) plen 3 [hci0] 10.872841
> > Class: 0x000000
> > Major class: Miscellaneous
> > Minor class: 0x00
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.873036
> > Write Class of Device (0x03|0x0024) ncmd 1
> > Status: Success (0x00)
> > * Unknown packet (code 17 len 9) [hci0] 10.873069
> > 02 00 00 00 07 00 00 00 00 .........
> > * Unknown packet (code 17 len 9) [hci0] 10.873069
> > 01 00 00 00 07 00 00 00 00 .........
> > < HCI Command: Write Local Name (0x03|0x0013) plen 248 [hci0] 10.873096
> > Name: builder
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.873446
> > Write Local Name (0x03|0x0013) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Write Extended Inquir.. (0x03|0x0052) plen 241 [hci0] 10.873470
> > FEC: Not required (0x00)
> > Name (complete): builder
> > TX power: -1 dBm
> > Device ID: USB Implementer's Forum assigned (0x0002)
> > Vendor: Linux Foundation (0x1d6b)
> > Product: 0x0246
> > Version: 5.2.11 (0x052b)
> > 16-bit Service UUIDs (complete): 4 entries
> > Generic Access Profile (0x1800)
> > Generic Attribute Profile (0x1801)
> > A/V Remote Control (0x110e)
> > A/V Remote Control Target (0x110c)
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.873857
> > Write Extended Inquiry Response (0x03|0x0052) ncmd 1
> > Status: Success (0x00)
> > * Unknown packet (code 17 len 13) [hci0] 10.873903
> > 01 00 00 00 01 00 05 00 00 d1 0a 00 00 .............
> > * Unknown packet (code 17 len 10) [hci0] 10.873913
> > 02 00 00 00 06 00 d1 0a 00 00 ..........
> > * Unknown packet (code 16 len 7) [hci0] 17.803939
> > 01 00 00 00 05 00 00 .......
> > < HCI Command: Write Scan Enable (0x03|0x001a) plen 1 [hci0] 17.803983
> > Scan enable: No Scans (0x00)
> >> HCI Event: Command Complete (0x0e) plen 4 [hci0] 17.804233
> > Write Scan Enable (0x03|0x001a) ncmd 1
> > Status: Success (0x00)
> > < HCI Command: Vendor (0x3f|0x006f) plen 6 [hci0] 17.804282
> > 01 06 02 00 00 00 ......
> >> HCI Event: Unknown (0xe4) plen 5 [hci0] 17.804636
> > 02 06 01 00 00 .....
> > * Unknown packet (code 17 len 13) [hci0] 17.811580
> > 01 00 00 00 01 00 05 00 00 d0 0a 00 00 .............
> > * Unknown packet (code 17 len 10) [hci0] 17.811596
> > 02 00 00 00 06 00 d0 0a 00 00 ..........
> > = Close Index: 00:00:46:76:22:01 [hci0] 17.811625
>
> Regards
>
> Marcel
>
^ permalink raw reply
* [PATCH v10 18/18] KVM: arm64: Invoke FPSIMD context switch trap from C
From: Alex Bennée @ 2018-05-24 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527005119-6842-19-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> The conversion of the FPSIMD context switch trap code to C has added
> some overhead to calling it, due to the need to save registers that
> the procedure call standard defines as caller-saved.
>
> So, perhaps it is no longer worth invoking this trap handler quite
> so early.
>
> Instead, we can invoke it from fixup_guest_exit(), with little
> likelihood of increasing the overhead much further.
>
> As a convenience, this patch gives __hyp_switch_fpsimd() the same
> return semantics fixup_guest_exit(). For now there is no
> possibility of a spurious FPSIMD trap, so the function always
> returns true, but this allows it to be tail-called with a single
> return statement.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> arch/arm64/kvm/hyp/entry.S | 30 ------------------------------
> arch/arm64/kvm/hyp/hyp-entry.S | 19 -------------------
> arch/arm64/kvm/hyp/switch.c | 15 +++++++++++++--
> 3 files changed, 13 insertions(+), 51 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
> index 40f349b..fad1e16 100644
> --- a/arch/arm64/kvm/hyp/entry.S
> +++ b/arch/arm64/kvm/hyp/entry.S
> @@ -166,33 +166,3 @@ abort_guest_exit_end:
> orr x0, x0, x5
> 1: ret
> ENDPROC(__guest_exit)
> -
> -ENTRY(__fpsimd_guest_restore)
> - // x0: esr
> - // x1: vcpu
> - // x2-x29,lr: vcpu regs
> - // vcpu x0-x1 on the stack
> - stp x2, x3, [sp, #-144]!
> - stp x4, x5, [sp, #16]
> - stp x6, x7, [sp, #32]
> - stp x8, x9, [sp, #48]
> - stp x10, x11, [sp, #64]
> - stp x12, x13, [sp, #80]
> - stp x14, x15, [sp, #96]
> - stp x16, x17, [sp, #112]
> - stp x18, lr, [sp, #128]
> -
> - bl __hyp_switch_fpsimd
> -
> - ldp x4, x5, [sp, #16]
> - ldp x6, x7, [sp, #32]
> - ldp x8, x9, [sp, #48]
> - ldp x10, x11, [sp, #64]
> - ldp x12, x13, [sp, #80]
> - ldp x14, x15, [sp, #96]
> - ldp x16, x17, [sp, #112]
> - ldp x18, lr, [sp, #128]
> - ldp x0, x1, [sp, #144]
> - ldp x2, x3, [sp], #160
> - eret
> -ENDPROC(__fpsimd_guest_restore)
> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
> index bffece2..753b9d2 100644
> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> @@ -113,25 +113,6 @@ el1_hvc_guest:
>
> el1_trap:
> get_vcpu_ptr x1, x0
> -
> - mrs x0, esr_el2
> - lsr x0, x0, #ESR_ELx_EC_SHIFT
> - /*
> - * x0: ESR_EC
> - * x1: vcpu pointer
> - */
> -
> - /*
> - * We trap the first access to the FP/SIMD to save the host context
> - * and restore the guest context lazily.
> - * If FP/SIMD is not implemented, handle the trap and inject an
> - * undefined instruction exception to the guest.
> - */
> -alternative_if_not ARM64_HAS_NO_FPSIMD
> - cmp x0, #ESR_ELx_EC_FP_ASIMD
> - b.eq __fpsimd_guest_restore
> -alternative_else_nop_endif
> -
> mov x0, #ARM_EXCEPTION_TRAP
> b __guest_exit
>
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 4fbee95..2d45bd7 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -328,8 +328,7 @@ static bool __hyp_text __skip_instr(struct kvm_vcpu *vcpu)
> }
> }
>
> -void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
> - struct kvm_vcpu *vcpu)
> +static bool __hyp_text __hyp_switch_fpsimd(struct kvm_vcpu *vcpu)
> {
> struct user_fpsimd_state *host_fpsimd = vcpu->arch.host_fpsimd_state;
>
> @@ -369,6 +368,8 @@ void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
> fpexc32_el2);
>
> vcpu->arch.flags |= KVM_ARM64_FP_ENABLED;
> +
> + return true;
> }
>
> /*
> @@ -390,6 +391,16 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> if (*exit_code != ARM_EXCEPTION_TRAP)
> goto exit;
>
> + /*
> + * We trap the first access to the FP/SIMD to save the host context
> + * and restore the guest context lazily.
> + * If FP/SIMD is not implemented, handle the trap and inject an
> + * undefined instruction exception to the guest.
> + */
> + if (system_supports_fpsimd() &&
> + kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_FP_ASIMD)
> + return __hyp_switch_fpsimd(vcpu);
> +
> if (!__populate_fault_info(vcpu))
> return true;
--
Alex Benn?e
^ permalink raw reply
* [PATCH v2 9/9] ARM: dts: silk: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-24 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524150721.28964-1-marek.vasut+renesas@gmail.com>
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k(loader),4m(user),-(flash)
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc at vger.kernel.org
---
V2: Drop the @0 anchor from the commit message, use 4m
---
arch/arm/boot/dts/r8a7794-silk.dts | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
index 7808aaee6644..b8163a0e2190 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -444,27 +444,6 @@
spi-cpol;
spi-cpha;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition at 0 {
- label = "loader";
- reg = <0x00000000 0x00040000>;
- read-only;
- };
- partition at 40000 {
- label = "user";
- reg = <0x00040000 0x00400000>;
- read-only;
- };
- partition at 440000 {
- label = "flash";
- reg = <0x00440000 0x03bc0000>;
- };
- };
};
};
--
2.16.2
^ permalink raw reply related
* [PATCH v2 8/9] ARM: dts: alt: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-24 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524150721.28964-1-marek.vasut+renesas@gmail.com>
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k(loader),256k(system),-(user)
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc at vger.kernel.org
---
V2: Drop the @0 anchor from the commit message
---
arch/arm/boot/dts/r8a7794-alt.dts | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
index e17027532941..1d044ed598f3 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -419,26 +419,5 @@
spi-cpol;
spi-cpha;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition at 0 {
- label = "loader";
- reg = <0x00000000 0x00040000>;
- read-only;
- };
- partition at 40000 {
- label = "system";
- reg = <0x00040000 0x00040000>;
- read-only;
- };
- partition at 80000 {
- label = "user";
- reg = <0x00080000 0x03f80000>;
- };
- };
};
};
--
2.16.2
^ permalink raw reply related
* [PATCH v2 7/9] ARM: dts: gose: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-24 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524150721.28964-1-marek.vasut+renesas@gmail.com>
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k(loader),4m(user),-(flash)
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc at vger.kernel.org
---
V2: Drop the @0 anchor from the commit message, use 4m
---
arch/arm/boot/dts/r8a7793-gose.dts | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index aa209f6e5d71..b2dd54fbe40c 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -676,27 +676,6 @@
spi-cpol;
spi-cpha;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition at 0 {
- label = "loader";
- reg = <0x00000000 0x00040000>;
- read-only;
- };
- partition at 40000 {
- label = "user";
- reg = <0x00040000 0x00400000>;
- read-only;
- };
- partition at 440000 {
- label = "flash";
- reg = <0x00440000 0x03bc0000>;
- };
- };
};
};
--
2.16.2
^ permalink raw reply related
* [PATCH v2 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-24 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524150721.28964-1-marek.vasut+renesas@gmail.com>
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k(loader),4m(user),-(flash)
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc at vger.kernel.org
---
V2: Drop the @0 anchor from the commit message, use 4m
---
arch/arm/boot/dts/r8a7792-wheat.dts | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts b/arch/arm/boot/dts/r8a7792-wheat.dts
index db01de7a3811..93f78716225a 100644
--- a/arch/arm/boot/dts/r8a7792-wheat.dts
+++ b/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -217,27 +217,6 @@
spi-cpol;
spi-cpha;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition at 0 {
- label = "loader";
- reg = <0x00000000 0x00040000>;
- read-only;
- };
- partition at 40000 {
- label = "user";
- reg = <0x00040000 0x00400000>;
- read-only;
- };
- partition at 440000 {
- label = "flash";
- reg = <0x00440000 0x03bc0000>;
- };
- };
};
};
--
2.16.2
^ permalink raw reply related
* [PATCH v2 5/9] ARM: dts: porter: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-24 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524150721.28964-1-marek.vasut+renesas@gmail.com>
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k(loader_prg),4m(user_prg),-(flash_fs)
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc at vger.kernel.org
---
V2: Drop the @0 anchor from the commit message, use 4m
---
arch/arm/boot/dts/r8a7791-porter.dts | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index a01101b49d99..45d89e064407 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -344,27 +344,6 @@
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition at 0 {
- label = "loader_prg";
- reg = <0x00000000 0x00040000>;
- read-only;
- };
- partition at 40000 {
- label = "user_prg";
- reg = <0x00040000 0x00400000>;
- read-only;
- };
- partition at 440000 {
- label = "flash_fs";
- reg = <0x00440000 0x03bc0000>;
- };
- };
};
};
--
2.16.2
^ permalink raw reply related
* [PATCH v2 4/9] ARM: dts: koelsch: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-24 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524150721.28964-1-marek.vasut+renesas@gmail.com>
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:512k(loader),5632k(user),-(flash)
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc at vger.kernel.org
---
V2: Drop the @0 anchor from the commit message
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 8ab793d8b2fd..406d5d29e29c 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -724,27 +724,6 @@
spi-cpha;
spi-cpol;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition at 0 {
- label = "loader";
- reg = <0x00000000 0x00080000>;
- read-only;
- };
- partition at 80000 {
- label = "user";
- reg = <0x00080000 0x00580000>;
- read-only;
- };
- partition at 600000 {
- label = "flash";
- reg = <0x00600000 0x03a00000>;
- };
- };
};
};
--
2.16.2
^ permalink raw reply related
* [PATCH v2 3/9] ARM: dts: stout: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-24 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524150721.28964-1-marek.vasut+renesas@gmail.com>
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:512k(loader),256k(uboot),256k(uboot-env),-(flash)
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc at vger.kernel.org
---
V2: Drop the @0 anchor from the commit message
---
arch/arm/boot/dts/r8a7790-stout.dts | 26 --------------------------
1 file changed, 26 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-stout.dts b/arch/arm/boot/dts/r8a7790-stout.dts
index a13a92c26645..dc65519d53ab 100644
--- a/arch/arm/boot/dts/r8a7790-stout.dts
+++ b/arch/arm/boot/dts/r8a7790-stout.dts
@@ -211,32 +211,6 @@
spi-cpha;
spi-cpol;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition at 0 {
- label = "loader";
- reg = <0x00000000 0x00080000>;
- read-only;
- };
- partition at 80000 {
- label = "uboot";
- reg = <0x00080000 0x00040000>;
- read-only;
- };
- partition at c0000 {
- label = "uboot-env";
- reg = <0x000c0000 0x00040000>;
- read-only;
- };
- partition at 100000 {
- label = "flash";
- reg = <0x00100000 0x03f00000>;
- };
- };
};
};
--
2.16.2
^ permalink raw reply related
* [PATCH v2 2/9] ARM: dts: lager: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-24 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524150721.28964-1-marek.vasut+renesas@gmail.com>
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k(loader),4m(user),-(flash)
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc at vger.kernel.org
---
V2: Drop the @0 anchor from the commit message, use 4m
---
arch/arm/boot/dts/r8a7790-lager.dts | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 092610e3f953..7c95e62efd46 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -710,27 +710,6 @@
spi-cpha;
spi-cpol;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition at 0 {
- label = "loader";
- reg = <0x00000000 0x00040000>;
- read-only;
- };
- partition at 40000 {
- label = "user";
- reg = <0x00040000 0x00400000>;
- read-only;
- };
- partition at 440000 {
- label = "flash";
- reg = <0x00440000 0x03bc0000>;
- };
- };
};
};
--
2.16.2
^ permalink raw reply related
* [PATCH v2 1/9] ARM: shmobile: defconfig: Enable MTD command line partition parsing
From: Marek Vasut @ 2018-05-24 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In preparation for removing MTD partitioning from the DTs and moving
it over to kernel command line partition parsing, enable the support
for kernel command line MTD partition parsing.
The argument for not having MTD partitions in the DT is the same as
for not having hard drive partitions in DT, neither describes the
hardware itself, so it shouldn't be in the DT. Furthermore, kernel
command line MTD partition passing allows greater flexibility in
case someone decided to repartition the flash, which is well in the
realm of possibility with these systems.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc at vger.kernel.org
---
V2: No change
---
arch/arm/configs/shmobile_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index b49887e86a3d..4d0d5a00a188 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -64,6 +64,7 @@ CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=64
CONFIG_SIMPLE_PM_BUS=y
CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
CONFIG_MTD_SPI_NOR=y
--
2.16.2
^ permalink raw reply related
* [PATCH v10 17/18] KVM: arm64: Fold redundant exit code checks out of fixup_guest_exit()
From: Alex Bennée @ 2018-05-24 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527005119-6842-18-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> The entire tail of fixup_guest_exit() is contained in if statements
> of the form if (x && *exit_code == ARM_EXCEPTION_TRAP). As a result,
> we can check just once and bail out of the function early, allowing
> the remaining if conditions to be simplified.
>
> The only awkward case is where *exit_code is changed to
> ARM_EXCEPTION_EL1_SERROR in the case of an illegal GICv2 CPU
> interface access: in that case, the GICv3 trap handling code is
> skipped using a goto. This avoids pointlessly evaluating the
> static branch check for the GICv3 case, even though we can't have
> vgic_v2_cpuif_trap and vgic_v3_cpuif_trap true simultaneously
> unless we have a GICv3 and GICv2 on the host: that sounds stupid,
> but I haven't satisfied myself that it can't happen.
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> arch/arm64/kvm/hyp/switch.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 18d0faa..4fbee95 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -387,11 +387,13 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> * same PC once the SError has been injected, and replay the
> * trapping instruction.
> */
> - if (*exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
> + if (*exit_code != ARM_EXCEPTION_TRAP)
> + goto exit;
> +
> + if (!__populate_fault_info(vcpu))
> return true;
>
> - if (static_branch_unlikely(&vgic_v2_cpuif_trap) &&
> - *exit_code == ARM_EXCEPTION_TRAP) {
> + if (static_branch_unlikely(&vgic_v2_cpuif_trap)) {
> bool valid;
>
> valid = kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_DABT_LOW &&
> @@ -417,11 +419,12 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> *vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
> *exit_code = ARM_EXCEPTION_EL1_SERROR;
> }
> +
> + goto exit;
> }
> }
>
> if (static_branch_unlikely(&vgic_v3_cpuif_trap) &&
> - *exit_code == ARM_EXCEPTION_TRAP &&
> (kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_SYS64 ||
> kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_CP15_32)) {
> int ret = __vgic_v3_perform_cpuif_access(vcpu);
> @@ -430,6 +433,7 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> return true;
> }
>
> +exit:
> /* Return to the host kernel and handle the exit */
> return false;
> }
--
Alex Benn?e
^ permalink raw reply
* [PATCH v2 03/40] iommu/sva: Manage process address spaces
From: Jean-Philippe Brucker @ 2018-05-24 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524115039.GA10260@apalos>
On 24/05/18 12:50, Ilias Apalodimas wrote:
>> Interesting, I hadn't thought about this use-case before. At first I
>> thought you were talking about mdev devices assigned to VMs, but I think
>> you're referring to mdevs assigned to userspace drivers instead? Out of
>> curiosity, is it only theoretical or does someone actually need this?
>
> There has been some non upstreamed efforts to have mdev and produce userspace
> drivers. Huawei is using it on what they call "wrapdrive" for crypto devices and
> we did a proof of concept for ethernet interfaces. At the time we choose not to
> involve the IOMMU for the reason you mentioned, but having it there would be
> good.
I'm guessing there were good reasons to do it that way but I wonder, is
it not simpler to just have the kernel driver create a /dev/foo, with a
standard ioctl/mmap/poll interface? Here VFIO adds a layer of
indirection, and since the mediating driver has to implement these
operations already, what is gained?
Thanks,
Jean
^ permalink raw reply
* [PATCH v2 13/40] vfio: Add support for Shared Virtual Addressing
From: Jean-Philippe Brucker @ 2018-05-24 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5B06B17C.1090809@huawei.com>
On 24/05/18 13:35, Xu Zaibo wrote:
>> Right, sva_init() must be called once for any device that intends to use
>> bind(). For the second process though, group->sva_enabled will be true
>> so we won't call sva_init() again, only bind().
>
> Well, while I create mediated devices based on one parent device to support multiple
> processes(a new process will create a new 'vfio_group' for the corresponding mediated device,
> and 'sva_enabled' cannot work any more), in fact, *sva_init and *sva_shutdown are basically
> working on parent device, so, as a result, I just only need sva initiation and shutdown on the
> parent device only once. So I change the two as following:
>
> @@ -551,8 +565,18 @@ int iommu_sva_device_init(struct device *dev, unsigned long features,
> if (features & ~IOMMU_SVA_FEAT_IOPF)
> return -EINVAL;
>
> + /* If already exists, do nothing */
> + mutex_lock(&dev->iommu_param->lock);
> + if (dev->iommu_param->sva_param) {
> + mutex_unlock(&dev->iommu_param->lock);
> + return 0;
> + }
> + mutex_unlock(&dev->iommu_param->lock);
>
> if (features & IOMMU_SVA_FEAT_IOPF) {
> ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf,
>
>
> @@ -621,6 +646,14 @@ int iommu_sva_device_shutdown(struct device *dev)
> if (!domain)
> return -ENODEV;
>
> + /* If any other process is working on the device, shut down does nothing. */
> + mutex_lock(&dev->iommu_param->lock);
> + if (!list_empty(&dev->iommu_param->sva_param->mm_list)) {
> + mutex_unlock(&dev->iommu_param->lock);
> + return 0;
> + }
> + mutex_unlock(&dev->iommu_param->lock);
I don't think iommu-sva.c is the best place for this, it's probably
better to implement an intermediate layer (the mediating driver), that
calls iommu_sva_device_init() and iommu_sva_device_shutdown() once. Then
vfio-pci would still call these functions itself, but for mdev the
mediating driver keeps a refcount of groups, and calls device_shutdown()
only when freeing the last mdev.
A device driver (non mdev in this example) expects to be able to free
all its resources after sva_device_shutdown() returns. Imagine the
mm_list isn't empty (mm_exit() is running late), and instead of waiting
in unbind_dev_all() below, we return 0 immediately. Then the calling
driver frees its resources, and the mm_exit callback along with private
data passed to bind() disappear. If a mm_exit() is still running in
parallel, then it will try to access freed data and corrupt memory. So
in this function if mm_list isn't empty, the only thing we can do is wait.
Thanks,
Jean
> +
> __iommu_sva_unbind_dev_all(dev);
>
> mutex_lock(&dev->iommu_param->lock);
>
> I add the above two checkings in both *sva_init and *sva_shutdown, it is working now,
> but i don't know if it will cause any new problems. What's more, i doubt if it is
> reasonable to check this to avoid repeating operation in VFIO, maybe it is better to check
> in IOMMU. :)
^ permalink raw reply
* [PATCH v10 16/18] KVM: arm64: Remove redundant *exit_code changes in fpsimd_guest_exit()
From: Alex Bennée @ 2018-05-24 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527005119-6842-17-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> In fixup_guest_exit(), there are a couple of cases where after
> checking what the exit code was, we assign it explicitly with the
> value it already had.
>
> Assuming this is not indicative of a bug, these assignments are not
> needed.
>
> This patch removes the redundant assignments, and simplifies some
> if-nesting that becomes trivial as a result.
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
--
Alex Benn?e
^ permalink raw reply
* [PATCH v10 3/4] arm64: Implement page table free interfaces
From: Chintan Pandya @ 2018-05-24 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527170250-5291-4-git-send-email-cpandya@codeaurora.org>
On 5/24/2018 7:27 PM, Chintan Pandya wrote:
> Implement pud_free_pmd_page() and pmd_free_pte_page().
>
> Implementation requires,
> 1) Clearing off the current pud/pmd entry
> 2) Invalidate TLB which could have previously
> valid but not stale entry
> 3) Freeing of the un-used next level page tables
>
> Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
> ---
> arch/arm64/mm/mmu.c | 34 ++++++++++++++++++++++++++++++----
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index da98828..17d9282 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -45,6 +45,7 @@
> #include <asm/memblock.h>
> #include <asm/mmu_context.h>
> #include <asm/ptdump.h>
> +#include <asm/tlbflush.h>
>
> #define NO_BLOCK_MAPPINGS BIT(0)
> #define NO_CONT_MAPPINGS BIT(1)
> @@ -973,12 +974,37 @@ int pmd_clear_huge(pmd_t *pmdp)
> return 1;
> }
>
> -int pud_free_pmd_page(pud_t *pud, unsigned long addr)
> +int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
> {
> - return pud_none(*pud);
> + pmd_t *table;
> + pmd_t pmd;
> +
> + pmd = READ_ONCE(*pmdp);
> + if (pmd_present(pmd)) {
> + table = __va(pmd_val(pmd));
> + pmd_clear(pmdp);
> + __flush_tlb_kernel_pgtable(addr);
> + pte_free_kernel(NULL, (pte_t *) table);
> + }
> + return 1;
> }
>
> -int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
> +int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
> {
> - return pmd_none(*pmd);
> + pmd_t *table;
> + pud_t pud;
> + int i = 0;
> +
> + pud = READ_ONCE(*pudp);
> + if (pud_present(pud)) {
> + table = __va(pud_val(pud));
> + do {
> + pmd_free_pte_page(&table[i], addr + (i * PMD_SIZE));
> + } while (i++, i < PTRS_PER_PMD);
Hi Will,
Right after sending these patches, I realized that do-while condition
can be made to look like what we see in ioremap/vmalloc code. I guess,
that's what you suggested. So, I'll raise v11 fixing that. Any more
concerns ?
> +
> + pud_clear(pudp);
> + __flush_tlb_kernel_pgtable(addr);
> + pmd_free(NULL, table);
> + }
> + return 1;
> }
>
Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply
* [PATCH v10 15/18] KVM: arm64: Remove eager host SVE state saving
From: Alex Bennée @ 2018-05-24 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527005119-6842-16-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> Now that the host SVE context can be saved on demand from Hyp,
> there is no longer any need to save this state in advance before
> entering the guest.
>
> This patch removes the relevant call to
> kvm_fpsimd_flush_cpu_state().
>
> Since the problem that function was intended to solve now no longer
> exists, the function and its dependencies are also deleted.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Acked-by: Christoffer Dall <christoffer.dall@arm.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> arch/arm/include/asm/kvm_host.h | 3 ---
> arch/arm64/include/asm/kvm_host.h | 10 ----------
> arch/arm64/kernel/fpsimd.c | 21 ---------------------
> virt/kvm/arm/arm.c | 3 ---
> 4 files changed, 37 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 3b85bbb..f079a20 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -312,9 +312,6 @@ static inline void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu) {}
> static inline void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu) {}
> static inline void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu) {}
>
> -/* All host FP/SIMD state is restored on guest exit, so nothing to save: */
> -static inline void kvm_fpsimd_flush_cpu_state(void) {}
> -
> static inline void kvm_arm_vhe_guest_enter(void) {}
> static inline void kvm_arm_vhe_guest_exit(void) {}
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 06d5a61..ce7ed92 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -457,16 +457,6 @@ static inline int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> }
> #endif
>
> -/*
> - * All host FP/SIMD state is restored on guest exit, so nothing needs
> - * doing here except in the SVE case:
> -*/
> -static inline void kvm_fpsimd_flush_cpu_state(void)
> -{
> - if (system_supports_sve())
> - sve_flush_cpu_state();
> -}
> -
> static inline void kvm_arm_vhe_guest_enter(void)
> {
> local_daif_mask();
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index f39d3b0..ea5d780 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -120,7 +120,6 @@
> */
> struct fpsimd_last_state_struct {
> struct user_fpsimd_state *st;
> - bool sve_in_use;
> };
>
> static DEFINE_PER_CPU(struct fpsimd_last_state_struct, fpsimd_last_state);
> @@ -1003,7 +1002,6 @@ void fpsimd_bind_task_to_cpu(void)
> this_cpu_ptr(&fpsimd_last_state);
>
> last->st = ¤t->thread.uw.fpsimd_state;
> - last->sve_in_use = test_thread_flag(TIF_SVE);
> current->thread.fpsimd_cpu = smp_processor_id();
>
> if (system_supports_sve()) {
> @@ -1025,7 +1023,6 @@ void fpsimd_bind_state_to_cpu(struct user_fpsimd_state *st)
> WARN_ON(!in_softirq() && !irqs_disabled());
>
> last->st = st;
> - last->sve_in_use = false;
> }
>
> /*
> @@ -1086,24 +1083,6 @@ void fpsimd_flush_cpu_state(void)
> set_thread_flag(TIF_FOREIGN_FPSTATE);
> }
>
> -/*
> - * Invalidate any task SVE state currently held in this CPU's regs.
> - *
> - * This is used to prevent the kernel from trying to reuse SVE register data
> - * that is detroyed by KVM guest enter/exit. This function should go away when
> - * KVM SVE support is implemented. Don't use it for anything else.
> - */
> -#ifdef CONFIG_ARM64_SVE
> -void sve_flush_cpu_state(void)
> -{
> - struct fpsimd_last_state_struct const *last =
> - this_cpu_ptr(&fpsimd_last_state);
> -
> - if (last->st && last->sve_in_use)
> - fpsimd_flush_cpu_state();
> -}
> -#endif /* CONFIG_ARM64_SVE */
> -
> #ifdef CONFIG_KERNEL_MODE_NEON
>
> DEFINE_PER_CPU(bool, kernel_neon_busy);
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index ce7c6f3..39e7771 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -682,9 +682,6 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
> */
> preempt_disable();
>
> - /* Flush FP/SIMD state that can't survive guest entry/exit */
> - kvm_fpsimd_flush_cpu_state();
> -
> kvm_pmu_flush_hwstate(vcpu);
>
> local_irq_disable();
--
Alex Benn?e
^ permalink raw reply
* [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Marek Vasut @ 2018-05-24 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXnNABJSJZ6MLF+aQu8QKpFoMCAvno9Yc-9LOe810NtbA@mail.gmail.com>
On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Wed, May 23, 2018 at 12:01 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
>>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> Drop the MTD partitioning from DT, since it does not describe HW
>>>> and to give way to a more flexible kernel command line partition
>>>> passing.
>>>>
>>>> To retain the original partitioning, assure you have enabled
>>>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
>>>> following to your kernel command line:
>>>>
>>>> mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)
>>>
>>> I think the "@0" can be dropped, as it's optional?
>>> 4m?
>>
>> My take on this is that the loader is actually at offset 0x0 of the MTD
>> device and we explicitly state that in the mtdparts to anchor the first
>> partition within the MTD device and all the other partitions are at
>> offset +(sum of the sizes of all partitions listed before the current
>> one) relative to that first partition.
>
> Where is this explicitly states for the first partition?
>
>> Removing the @0 feels fragile at best and it seems to depend on the
>> current behavior of the code.
>
> Better, it also depends on the documented behavior:
>
> Documentation/admin-guide/kernel-parameters.txt refers to
> drivers/mtd/cmdlinepart.c, which states:
>
> * <offset> := standard linux memsize
> * if omitted the part will immediately follow the previous part
> * or 0 if the first part
>
> None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
> help text, or in a defconfig bundled with the kernel, use @0 for the first
> partition.
I think this is exceptionally fragile and dangerous to depend on this,
but so be it.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v10 14/18] KVM: arm64: Save host SVE context as appropriate
From: Alex Bennée @ 2018-05-24 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527005119-6842-15-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> This patch adds SVE context saving to the hyp FPSIMD context switch
> path. This means that it is no longer necessary to save the host
> SVE state in advance of entering the guest, when in use.
>
> In order to avoid adding pointless complexity to the code, VHE is
> assumed if SVE is in use. VHE is an architectural prerequisite for
> SVE, so there is no good reason to turn CONFIG_ARM64_VHE off in
> kernels that support both SVE and KVM.
>
> Historically, software models exist that can expose the
> architecturally invalid configuration of SVE without VHE, so if
> this situation is detected at kvm_init() time then KVM will be
> disabled.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
>
> ---
>
> * Tags stripped since v8, please reconfirm if possible:
>
> Formerly-Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
> Formerly-Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> Formerly-Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> Changes since v9:
>
> Requested by Marc Zyngier:
>
> * Inline check for VHE if SVE is present into kvm_host.h.
>
> The check has been renamed to the more specific
> kvm_arch_check_sve_has_vhe(), and the kvm_pr_unimpl() moved back to
> arm.c (to avoid circular include issues).
>
> arm.c is not single-arch code, but it is all Arm-specific, so
> adding a hook like this doesn't seem too unreasonable.
>
> Changes since v8:
>
> * Add kvm_arch_check_supported() hook, and move arm64-specific check
> for SVE-implies-VHE into arch/arm64/.
>
> Due to circular header dependency problems, it is difficult to get
> the prototype for kvm_pr_*() functions in <asm/kvm_host.h>, so this
> patch puts arm64's kvm_arch_check_supported() hook out of line.
> This is not a hot function.
> ---
> arch/arm/include/asm/kvm_host.h | 1 +
> arch/arm64/Kconfig | 7 +++++++
> arch/arm64/include/asm/kvm_host.h | 13 +++++++++++++
> arch/arm64/kvm/fpsimd.c | 1 -
> arch/arm64/kvm/hyp/switch.c | 20 +++++++++++++++++++-
> virt/kvm/arm/arm.c | 7 +++++++
> 6 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index ac870b2..3b85bbb 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -280,6 +280,7 @@ void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
>
> struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
>
> +static inline bool kvm_arch_check_sve_has_vhe(void) { return true; }
> static inline void kvm_arch_hardware_unsetup(void) {}
> static inline void kvm_arch_sync_events(struct kvm *kvm) {}
> static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index eb2cf49..b0d3820 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1130,6 +1130,7 @@ endmenu
> config ARM64_SVE
> bool "ARM Scalable Vector Extension support"
> default y
> + depends on !KVM || ARM64_VHE
> help
> The Scalable Vector Extension (SVE) is an extension to the AArch64
> execution state which complements and extends the SIMD functionality
> @@ -1155,6 +1156,12 @@ config ARM64_SVE
> booting the kernel. If unsure and you are not observing these
> symptoms, you should assume that it is safe to say Y.
>
> + CPUs that support SVE are architecturally required to support the
> + Virtualization Host Extensions (VHE), so the kernel makes no
> + provision for supporting SVE alongside KVM without VHE enabled.
> + Thus, you will need to enable CONFIG_ARM64_VHE if you want to support
> + KVM in the same kernel image.
> +
> config ARM64_MODULE_PLTS
> bool
> select HAVE_MOD_ARCH_SPECIFIC
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index b3fe730..06d5a61 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -405,6 +405,19 @@ static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
> kvm_call_hyp(__kvm_set_tpidr_el2, tpidr_el2);
> }
>
> +static inline bool kvm_arch_check_sve_has_vhe(void)
> +{
> + /*
> + * The Arm architecture specifies that imlpementation of SVE
> + * requires VHE also to be implemented. The KVM code for arm64
> + * relies on this when SVE is present:
> + */
> + if (system_supports_sve())
> + return has_vhe();
> + else
> + return true;
> +}
> +
> static inline void kvm_arch_hardware_unsetup(void) {}
> static inline void kvm_arch_sync_events(struct kvm *kvm) {}
> static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 365933a..dc6ecfa 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -59,7 +59,6 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
> */
> void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> {
> - BUG_ON(system_supports_sve());
> BUG_ON(!current->mm);
>
> vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_HOST_SVE_IN_USE);
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 118f300..a6a8c7d 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -21,6 +21,7 @@
>
> #include <kvm/arm_psci.h>
>
> +#include <asm/cpufeature.h>
> #include <asm/kvm_asm.h>
> #include <asm/kvm_emulate.h>
> #include <asm/kvm_host.h>
> @@ -28,6 +29,7 @@
> #include <asm/kvm_mmu.h>
> #include <asm/fpsimd.h>
> #include <asm/debug-monitors.h>
> +#include <asm/processor.h>
> #include <asm/thread_info.h>
>
> /* Check whether the FP regs were dirtied while in the host-side run loop: */
> @@ -329,6 +331,8 @@ static bool __hyp_text __skip_instr(struct kvm_vcpu *vcpu)
> void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
> struct kvm_vcpu *vcpu)
> {
> + struct user_fpsimd_state *host_fpsimd = vcpu->arch.host_fpsimd_state;
> +
> if (has_vhe())
> write_sysreg(read_sysreg(cpacr_el1) | CPACR_EL1_FPEN,
> cpacr_el1);
> @@ -339,7 +343,21 @@ void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
> isb();
>
> if (vcpu->arch.flags & KVM_ARM64_FP_HOST) {
> - __fpsimd_save_state(vcpu->arch.host_fpsimd_state);
> + /*
> + * In the SVE case, VHE is assumed: it is enforced by
> + * Kconfig and kvm_arch_init().
> + */
> + if (system_supports_sve() &&
> + (vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE)) {
> + struct thread_struct *thread = container_of(
> + host_fpsimd,
> + struct thread_struct, uw.fpsimd_state);
> +
> + sve_save_state(sve_pffr(thread), &host_fpsimd->fpsr);
> + } else {
> + __fpsimd_save_state(host_fpsimd);
> + }
> +
> vcpu->arch.flags &= ~KVM_ARM64_FP_HOST;
> }
>
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index bee226c..ce7c6f3 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -16,6 +16,7 @@
> * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
> */
>
> +#include <linux/bug.h>
> #include <linux/cpu_pm.h>
> #include <linux/errno.h>
> #include <linux/err.h>
> @@ -41,6 +42,7 @@
> #include <asm/mman.h>
> #include <asm/tlbflush.h>
> #include <asm/cacheflush.h>
> +#include <asm/cpufeature.h>
> #include <asm/virt.h>
> #include <asm/kvm_arm.h>
> #include <asm/kvm_asm.h>
> @@ -1574,6 +1576,11 @@ int kvm_arch_init(void *opaque)
> return -ENODEV;
> }
>
> + if (!kvm_arch_check_sve_has_vhe()) {
> + kvm_pr_unimpl("SVE system without VHE unsupported. Broken cpu?");
> + return -ENODEV;
> + }
> +
Ahh this is going to be a pain when people want to enable system
emulation for SVE in QEMU given our patchy feature implementation (i.e.
we haven't done VHE yet). However that's totally our problem not yours
;-)
Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
> for_each_online_cpu(cpu) {
> smp_call_function_single(cpu, check_kvm_target_cpu, &ret, 1);
> if (ret < 0) {
--
Alex Benn?e
^ permalink raw reply
* [PATCH v10 07/18] arm64: fpsimd: Eliminate task->mm checks
From: Dave Martin @ 2018-05-24 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524100659.GO55598@C02W217FHV2R.local>
On Thu, May 24, 2018 at 12:06:59PM +0200, Christoffer Dall wrote:
> On Thu, May 24, 2018 at 10:50:56AM +0100, Dave Martin wrote:
> > On Thu, May 24, 2018 at 10:33:50AM +0200, Christoffer Dall wrote:
[...]
> > > ...with a risk of being a bit over-pedantic and annoying, may I suggest
> > > the following complete commit text:
> > >
> > > ------8<------
> > > Currently the FPSIMD handling code uses the condition task->mm ==
> > > NULL as a hint that task has no FPSIMD register context.
> > >
> > > The ->mm check is only there to filter out tasks that cannot
> > > possibly have FPSIMD context loaded, for optimisation purposes.
> > > However, TIF_FOREIGN_FPSTATE must always be checked anyway before
> > > saving FPSIMD context back to memory. For this reason, the ->mm
> > > checks are not useful, providing that that TIF_FOREIGN_FPSTATE is
> > > maintained properly for kernel threads.
> > >
> > > FPSIMD context is never preserved for kernel threads across a context
> > > switch and therefore TIF_FOREIGN_FPSTATE should always be true for
> >
> > (This refactoring opens up the interesting possibility of making
> > kernel-mode NEON in task context preemptible for kernel threads so
> > that we actually do preserve state... but that's a discussion for
> > another day. There may be code around that relies on
> > kernel_neon_begin() disabling preemption for real.)
> >
> > > kernel threads. This is indeed the case, as the wrong_task and
> >
> > This suggests that TIF_FOREIGN_FPSTATE is always true for kernel
> > threads today. This is not quite because use_mm() can make mm non-
> > NULL.
> >
>
> I was suggesting that it's always true after this patch.
I tend to read the present tense as describing the situation before the
patch, but this convention isn't followed universally.
This was part of the problem with my "true by construction" weasel
words: the described property wasn't true by construction prior to the
patch, and there wasn't sufficient explanation to convince people it's
true afterwards. If people are bring rigorous, it takes a _lot_ of
explanation...
>
> > > wrong_cpu tests in fpsimd_thread_switch() will always yield false for
> > > kernel threads.
> >
> > ("false" -> "true". My bad.)
> >
> > > Further, the context switch logic is already deliberately optimised to
> > > defer reloads of the FPSIMD context until ret_to_user (or sigreturn as a
> > > special case), which kernel threads by definition never reach, and
> > > therefore this change introduces no additional work in the critical
> > > path.
> > >
> > > This patch removes the redundant checks and special-case code.
> > > ------8<------
> >
> > Looking at my existing text, I rather reworded it like this.
> > Does this work any better for you?
> >
> > --8<--
> >
> > Currently the FPSIMD handling code uses the condition task->mm ==
> > NULL as a hint that task has no FPSIMD register context.
> >
> > The ->mm check is only there to filter out tasks that cannot
> > possibly have FPSIMD context loaded, for optimisation purposes.
> > Also, TIF_FOREIGN_FPSTATE must always be checked anyway before
> > saving FPSIMD context back to memory. For these reasons, the ->mm
> > checks are not useful, providing that TIF_FOREIGN_FPSTATE is
> > maintained in a consistent way for kernel threads.
>
> Consistent with what? Without more context or explanation,
Consistent with the handling of user threads (though I admit it's not
explicit in the text.)
> I'm not sure what the reader is to make of that. Do you not mean the
> TIF_FOREIGN_FPSTATE is always true for kernel threads?
Again, this is probably a red herring. TIF_FOREIGN_FPSTATE is always
true for kernel threads prior to the patch, except (randomly) for the
init task.
This change is not really about TIF_FOREIGN_FPSTATE at all, rather
that there is nothing to justify handling kernel threads differently,
or even distinguishing kernel threads from user threads at all in this
code.
Part of the confusion (and I had confused myself) comes from the fact
that TIF_FOREIGN_FPSTATE is really a per-cpu property and doesn't make
sense as a per-task property -- i.e., the flag is meaningless for
scheduled-out tasks and we must explicitly "repair" it when scheduling
a task in anyway. I think it's a thread flag primarily so that it's
convenient to check alongside other thread flags in the ret_to_user
work loop. This is somewhat less of a justification now that loop was
ported to C.
> >
> > The context switch logic is already deliberately optimised to defer
> > reloads of the regs until ret_to_user (or sigreturn as a special
> > case), and save them only if they have been previously loaded.
Does it help to insert the following here?
"These paths are the only places where the wrong_task and wrong_cpu
conditions can be made false, by calling fpsimd_bind_task_to_cpu()."
> > Kernel threads by definition never reach these paths. As a result,
>
> I'm struggling with the "As a result," here. Is this because reloads of
> regs in ret_to_user (or sigreturn) are the only places that can make
> wrong_cpu or wrong_task be false?
See the proposed clarification above. Is that sufficient?
> (I'm actually wanting to understand this, not just bikeshedding the
> commit message, as new corner cases keep coming up on this logic.)
That's a good thing, and I would really like to explain it in a
concise manner. See [*] below for the "concise" explanation -- it may
demonstrate why I've been evasive...
> > the wrong_task and wrong_cpu tests in fpsimd_thread_switch() will
> > always yield true for kernel threads.
> >
> > This patch removes the redundant checks and special-case code, ensuring that TIF_FOREIGN_FPSTATE is set whenever a kernel thread is scheduled in, and ensures that this flag is set for the init
> > task. The fpsimd_flush_task_state() call already present in copy_thread() ensures the same for any new task.
>
> nit: funny formatting
Dang, I was repeatedly pasing between Mutt and git commit terminals,
which doesn't always work as I'd like...
> nit: ensuring that TIF_FOREIGN_FPSTATE *remains* set whenever a kernel
> thread is scheduled in?
Er, yes.
> > With TIF_FOREIGN_FPSTATE always set for kernel threads, this patch
> > ensures that no extra context save work is added for kernel
> > threads, and eliminates the redundant context saving that may
> > currently occur for kernel threads that have acquired an mm via
> > use_mm().
> >
> > -->8--
>
> If you can slightly connect the dots with the "As a result" above, I'm
> fine with your version of the text.
As an aside, the big wall of text before the definition of struct
fpsimd_last_state_struct is looking out of date and could use an
update to cover at least some of what is explained in [*] better.
I'm currently considering that out of scope for this series, but I will
keep it in mind to refresh it in the not too distant future.
Cheers
---Dave
--8<--
[*] The bigger picture:
* Consider a relation (C,T) between cpus C and tasks T, such that
(C,T) means "T's FPSIMD regs are loaded on cpu C".
At a given point of execution of some cpu C, there is at most one task
T for which (C,T) holds.
At a given point of execution of some task T, there is at most one
cpu C for which (C,T) holds.
* (C,T) becomes true whenever T's registers are loaded into cpu C.
* At sched-out, we must ensure that the registers of current are
loaded before writing them to current's thread_struct. Thus, we
must save the registers if and only if (smp_processor_id(), current)
holds@this time.
* Before entering userspace, we must ensure that current's regs
are loaded, and we must only load the regs if they are not loaded
already (since if so, they might have been dirtied by current in
userspace since last loaded).
Thus, when entering userspace, we must load the regs from memory
if and only if (smp_processor_id(), current) does not hold.
* Checking this relation involves per-CPU access and inspection of
current->thread, and was presumably considered too cumbersome for
implemenation an entry.S, particluarly in the ret_to_user work
pending loop (which is where the FPSIMD regs are finally loaded
before entering userspace, if they weren't loaded already).
To mitigate this, the status of the check is cached in a thread flag
TIF_FOREIGN_FPSTATE: with softirqs disabled, (smp_processor_id(),
current) holds if and only if TIF_FOREIGN_FPSTATE is false.
TIF_FOREIGN_FPSTATE is corrected on sched-in by the code in
fpsimd_thread_switch().
[2] Anything that changes the state of the relation for current
requires its TIF_FOREIGN_FPSTATE to be changed to match.
* (smp_processor_id(), current) is established in
fpsimd_bind_task_to_cpu(). This is the only way the relation can be
made to hold between a task and a CPU.
* (C,T) is broken whenever
[1] T is created;
* T's regs are loaded onto a different cpu C2, so (C2,T) becomes
true and (C,T) necessarily becomes false;
* another task's regs are loaded into C, so (C,T2) becomes true
and (C,T) necessarily becomes false;
* the kernel clobbers the regs on C for its own purposes, so
(C,T) becomes false but there is no T2 for which (C,T2) becomes
true as a result. Examples are kernel-mode NEON and loading
the regs for a KVM vcpu;
* T's register context changes via a thread_struct update instead
of running instructions in userspace, requiring the contents of
the hardware regs to be thrown away. Examples are exec() (which
requires the registers to be zeroed), sigreturn (which populates the
regs from the user signal frame) and modification of the registers
via PTRACE_SETREGSET;
As a (probably unnecesary) optimisation, sigreturn immediately
loads the registers and reestablishes (smp_processor_id(), current)
in anticipation of the return to userspace which is likely to
occur soon. This allows the relation breaking logic to be omitted
in fpsimd_update_current_state() which does the work.
* In general, these relation breakings involve an unknown: knowing
either C or T but *not* both, we want to break (C,T). If the
relation were recorded in task_struct only, we would need to scan all
tasks in the "T unknown" case. If the relation were recorded in a
percpu variable only, we would need to scan all CPUs in the "C
unknown" case. As well as having gnarly synchronisation
requirements, these would get expensive in many-tasks or many-cpus
situations.
This is why the relation is recorded in both places, and is only
deemed to hold if the two records match up. This is what
fpsimd_thread_switch() is checking for the task being scheduled in.
The invalidation (breaking) operations are now factored as
fpsimd_flush_task_state(): falsify (C,current) for every cpu C.
This is done by zapping current->thread.fpsimd_cpu with NR_CPUS
(chosen because it cannot match smp_processor_id()).
fpsumd_flush_cpu_state(): falsify (smp_processor_id(),T) for every
task T. This is done by zapping this_cpu(fpsimd_last_state.st)
with NULL (chosen because it cannot match &T->thread.uw.fpsimd_state
for any task).
By [2] above, it is necessary to ensure that TIF_FOREIGN_FPSTATE is
set after calling either of the above functions. Of the two,
fpsimd_flush_cpu_state() now does this implicitly but
fpsimd_flush_task_state() does not: but the caller must do it
instead. I have a vague memory of some refactoring obstacle that
dissuaded me from pulling the set_thread_flag in, but I can't
remember it now. I may review this later.
* Because the (C,T) relation may need to be manipulated by
kernel_neon_{begin,end}() in softirq context, examining or
manipulating for current or the running CPU must be done under
local_bh_disable(). The same goes for TIF_FOREIGN_FPSTATE which is
supposed to represent the same condition but may spontaneously become
stale if softirqs are not masked. (The rule is not quite as strict
as this, but in order to make the code easier to reason about, I skip
the local_bh_disable() only where absolutely necessary --
restore_sve_fpsimd_context() is the only example today.)
Now, imagine that T is a kernel thread, and consider what needs to
be done differently. The observation of this patch is that nothing
needs to be done differently at all.
There is a single anomaly relating to [1] above, in the form of a task
that can run without ever being scheduled in: the init task. Beyond
that, kernel_neon_begin() before the first reschedule would spuriously
save the FPSIMD regs into the init_task's thread struct, even though it
is pointless to do so. This patch fixes those anomalies by updating
INIT_THREAD and INIT_THREAD_INFO to set up the init task so that it
looks the same as some other kernel thread that has been scheduled in.
There is a strong design motivation to avoid unnecessary loads and
saves of the state, so if removing the special-casing of kernel threads
were to add cost it would imply that the code were _already_ suboptimal
for user tasks. This patch does not attempt to address that at all,
but by assuming that the code is already well-optimised, "unnecessary"
save/restore work will not be added. If this were not the case, it
could in any case be fixed independently.
The observation of this _series_ is that we don't need to do very
much in order to be able to generalise the logic to accept KVM vcpus
in place of T.
^ permalink raw reply
* [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd
From: Jon Hunter @ 2018-05-24 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFravSx3h6UnsjNGM2ViZtkxvPMULyVQnoVT9jsEP5az+A@mail.gmail.com>
On 24/05/18 13:17, Ulf Hansson wrote:
> On 24 May 2018 at 11:36, Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>> On 24/05/18 08:04, Ulf Hansson wrote:
>>
>> ...
>>
>>>> Any reason why we could not add a 'boolean' argument to the API to
>>>> indicate
>>>> whether the new device should be linked? I think that I prefer the API
>>>> handles it, but I can see there could be instances where drivers may wish
>>>> to
>>>> handle it themselves.
>>>
>>>
>>> Coming back to this question. Both Tegra XUSB and Qcom Camera use
>>> case, would benefit from doing the linking themselves, as it needs
>>> different PM domains to be powered on depending on the current use
>>> case - as to avoid wasting power.
>>>
>>> However, I can understand that you prefer some simplicity over
>>> optimizations, as you told us. Then, does it mean that you are
>>> insisting on extending the APIs with a boolean for linking, or are you
>>> fine with the driver to call device_link_add()?
>>
>>
>> I am fine with the driver calling device_link_add(), but I just wonder if we
>> will find a several drivers doing this and then we will end up doing this
>> later anyway.
>
> Okay.
>
>>
>> The current API is called ...
>>
>> * genpd_dev_pm_attach_by_id() - Attach a device to one of its PM domain.
>> * @dev: Device to attach.
>> * @index: The index of the PM domain.
>>
>> This naming and description is a bit misleading, because really it is not
>> attaching the device that is passed, but creating a new device to attach a
>> PM domain to. So we should consider renaming and changing the description
>> and indicate that users need to link the device.
>
> I picked the name to be consistent with the existing
> genpd_dev_pm_attach(). Do you have a better suggestion?
Well, it appears to get more of a 'get' function and so I don't see why
we could not have 'genpd_dev_get_by_id()' and then we could have a
genpd_dev_put() as well (which would call genpd_dev_pm_detach).
> I agree, some details is missing to the description, let me try to
> improve it. Actually, I was trying to follow existing descriptions
> from genpd_dev_pm_attach(), so perhaps that also needs a little
> update.
>
> However, do note that, neither genpd_dev_pm_attach() or
> genpd_dev_pm_attach_by_id() is supposed to be called by drivers, but
> rather only by the driver core. So description may not be so
> important.
>
> In regards to good descriptions, for sure the API added in patch9,
> dev_pm_domain_attach_by_id(), needs a good one, as this is what
> drivers should be using.
OK. Same appears to apply here to the description as I mentioned above.
Still seems to be more of a 'get' than an attach. So I wonder if it
should be dev_pm_domain_get_by_id() instead?
>> Finally, how is a PM domain attached via calling genpd_dev_pm_attach_by_id()
>> detached?
>
> Via the existing genpd_dev_pm_detach(), according to what I have
> described in the change log. I clarify the description in regards to
> this as well.
OK, so this bit is a to-do as that is not yet exposed AFAICT. I see that
you said 'although we need to extend it to cover cleanup of the earlier
registered device, via calling device_unregister().' So if we do this
then that would be fine.
Cheers!
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v9 07/11] arm64: kexec_file: add crash dump support
From: Rob Herring @ 2018-05-24 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521101425.GC9887@linaro.org>
On Mon, May 21, 2018 at 5:14 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> Hi Rob,
>
> On Fri, May 18, 2018 at 10:35:52AM -0500, Rob Herring wrote:
>> On Tue, May 15, 2018 at 06:12:59PM +0100, James Morse wrote:
>> > Hi guys,
>> >
>> > (CC: +RobH, devicetree list)
>>
>> Thanks.
>>
>> > On 25/04/18 07:26, AKASHI Takahiro wrote:
>> > > Enabling crash dump (kdump) includes
>> > > * prepare contents of ELF header of a core dump file, /proc/vmcore,
>> > > using crash_prepare_elf64_headers(), and
>> > > * add two device tree properties, "linux,usable-memory-range" and
>> > > "linux,elfcorehdr", which represent repsectively a memory range
>> > > to be used by crash dump kernel and the header's location
>>
>> BTW, I intend to move existing parsing these out of the arch code.
>> Please don't add more DT handling to arch/ unless it is *really* arch
>> specific. I'd assume that the next arch to add kexec support will use
>> these bindings instead of the powerpc way.
>
> So do you expect all the fdt-related stuff in my current implementation
> for arm64 to be put into libfdt, or at least drivers/of, from the beginning?
Yes.
> I'm not sure how arch-specific the properties here are. For instance,
> it is only arm64 that uses "linux,usable-memory-range" right now but
> if some other arch follows, it is no more arch-specific.
> # I remember that you didn't like this property :)
The question I guess is what will the next arch use. I don't think any
other DT based arch supports crashdump or kexec yet.
>> > > +{
>> > > + void *buf, *prop;
>> > > + size_t buf_size;
>> > > + int result;
>> > > +
>> > > + buf_size = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
>> > > + prop = buf = vmalloc(buf_size);
>>
>> This can go on the stack instead (and would be required to to work in
>> libfdt).
>
> Well, I can't agree with you here since we are now in effort, as far as
> I correctly understand, of purging all the variable-sized arrays on a local
> stack out of the kernel code.
You don't need a variable sized array. The array size just needs to
the the maximum size (16 bytes).
Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox