Re: [PATCH 2/2] staging: mt7621-dts: Match pcie format to mt7623.dtsi
On Mon, Jun 4, 2018 at 3:25 PM, NeilBrown wrote:
> On Mon, Jun 04 2018, Rosen Penev wrote:
>
>> This currently fixes the remaining dtb warnings:
>>
>> Node /pcie@1e14/pcie0 has a reg or ranges property, but no unit name
>> Node /pcie@1e14/pcie1 has a reg or ranges property, but no unit name
>> Node /pcie@1e14/pcie2 has a reg or ranges property, but no unit name
>> Node /pcie@1e14/pcie0 node name is not "pci" or "pcie"
>> Node /pcie@1e14/pcie0 missing ranges for PCI bridge (or not a bridge)
>> Node /pcie@1e14/pcie0 missing bus-range for PCI bridge
>> Node /pcie@1e14/pcie1 node name is not "pci" or "pcie"
>> Node /pcie@1e14/pcie1 missing ranges for PCI bridge (or not a bridge)
>> Node /pcie@1e14/pcie1 missing bus-range for PCI bridge
>> Node /pcie@1e14/pcie2 node name is not "pci" or "pcie"
>> Node /pcie@1e14/pcie2 missing ranges for PCI bridge (or not a bridge)
>> Node /pcie@1e14/pcie2 missing bus-range for PCI bridge
>> Warning (unit_address_format): Failed prerequisite 'pci_bridge'
>> Warning (pci_device_reg): Failed prerequisite 'pci_bridge'
>> Warning (pci_device_bus_num): Failed prerequisite 'pci_bridge'
>>
>> In addition, it sets each pcie port to disabled in order to allow future
>> boards to be added that only have 1 or 2 pcie lanes wired up. gbpc1.dts
>> was changed to accomidate.
>
> I don't think you are using the word "lanes" correctly.
> A lane is a pair of wires for carrying data. a x1 PCIe slot has
> 1 lane and send all data serially. A x8 PCIe slot has 8 lanes
> and sends 8 bits at a time.
According to the datasheet, mt7621 has 3 pcie 1.1 interfaces running
at x1 speeds. Seems to be correct. Although...
> The enable/disable here seem to apply to ports (hosts? end-points?).
> The mt7621 has a 3port pcie bridge (switch?) and 3 individual pci
> end-points which can connect to 3 different devices.
>
>>
>> Signed-off-by: Rosen Penev
>> ---
>> drivers/staging/mt7621-dts/gbpc1.dts | 15 +++
>> drivers/staging/mt7621-dts/mt7621.dtsi | 24
>> 2 files changed, 27 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
>> b/drivers/staging/mt7621-dts/gbpc1.dts
>> index 6b13d85d9d34..cd7f90e4ec6d 100644
>> --- a/drivers/staging/mt7621-dts/gbpc1.dts
>> +++ b/drivers/staging/mt7621-dts/gbpc1.dts
>> @@ -113,7 +113,22 @@
>> };
>>
>> &pcie {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pcie_pins>;
>> status = "okay";
>> +
>> + pcie@0,0 {
>> + status = "okay";
>> + };
>> +
>> + pcie@1,0 {
>> + status = "okay";
>> + };
>> +
>> + pcie@2,0 {
>> + status = "okay";
>> + };
>> +
>> };
>>
>> ðernet {
>> diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
>> b/drivers/staging/mt7621-dts/mt7621.dtsi
>> index 5a94fcb96402..16583647797f 100644
>> --- a/drivers/staging/mt7621-dts/mt7621.dtsi
>> +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
>> @@ -452,31 +452,31 @@
>> clocks = <&clkctrl 24 &clkctrl 25 &clkctrl 26>;
>> clock-names = "pcie0", "pcie1", "pcie2";
>>
>> - pcie0 {
>> + pcie@0,0 {
>> reg = <0x 0 0 0 0>;
>> -
>> #address-cells = <3>;
>> #size-cells = <2>;
>> -
>> - device_type = "pci";
>> + ranges;
>> + num-lanes = <1>;
>> + status = "disabled";
>
> Some of this looks good, however...
>
> 1/ The 'status = "disabled"' doesn't actually work. I removed the
> 'status = "okay"' for pcie@2,0 in gbpc1, and all 3 PCIe devices were
> still active. Maybe we just need to add code somewhere.
>
> 2/ Why do you remove 'device_type = "pci";'?? Without a device type,
> no-one knows what sort of device it is - though that doesn't seem to
> stop it from working
I did it to match mt7623.dtsi. I think it continues to work because of
the pcie name being recognized.
>
> 3/ the "num-lanes" might make sense, but no code actually processes
>it. "num-lanes" is only examined by:
>
> drivers/pci/dwc/pcie-designware.c: ret = of_property_read_u32(np,
> "num-lanes", &lanes);
> drivers/pci/host/pcie-mediatek.c: err = of_property_read_u32(node,
> "num-lanes", &port->lane);
> drivers/pci/host/pcie-rockchip.c: err = of_property_read_u32(node,
> "num-lanes", &rockchip->lanes);
>
> so I cannot see why it belongs here.
Will remove. The SoC does not support anything higher than x1 anyway.
> So:
> I like the name change (pcie0 -> pcie@0,0)
> I like the status="disabled", except that it doesn't work.
> I think the addition of "ranges;" is correct.
Is it really? On most dts files that I've seen there are values for
it. I'm not really sure if it's needed though.
> I don't understand the rest.
One thing I also do not understand is that after this change, the
vIRQs in /proc/interrupts get incremented with ttyS0 a
RE: [PATCH v4] Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic
> From: Sunil Muthuswamy > Sent: Wednesday, June 6, 2018 12:31 > ... > + int sysctl_record_panic_msg = 1; This variable can be static. -- Dexuan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in hv_compose_msi_msg()
> From: Haiyang Zhang
> Sent: Friday, May 25, 2018 12:52
> To: Dexuan Cui ; Lorenzo Pieralisi
> ; Bjorn Helgaas ;
> linux-...@vger.kernel.org; KY Srinivasan ; Stephen
> Hemminger ; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com
> Cc: linux-ker...@vger.kernel.org; driverdev-devel@linuxdriverproject.org;
> vkuzn...@redhat.com; marcelo.ce...@canonical.com
> Subject: RE: [PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in
> hv_compose_msi_msg()
>
> > From: Dexuan Cui
> > Sent: Tuesday, May 22, 2018 8:18 PM
> > To: Lorenzo Pieralisi ; Bjorn Helgaas
> > ; linux-...@vger.kernel.org; KY Srinivasan
> > ; Stephen Hemminger ;
> > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com
> > Cc: linux-ker...@vger.kernel.org; driverdev-devel@linuxdriverproject.org;
> > Haiyang Zhang ; vkuzn...@redhat.com;
> > marcelo.ce...@canonical.com
> > Subject: [PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in
> > hv_compose_msi_msg()
> >
> >
> > Commit de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in
> hv_compose_msi_msg()")
> > uses local_bh_disable()/enable(), because hv_pci_onchannelcallback() can
> also
> > run in tasklet context as the channel event callback.
> >
> > With CONFIG_PROVE_LOCKING=y in the latest mainline, or old kernels that
> > don't have commit f71b74bca637 ("irq/softirqs: Use lockdep to assert IRQs
> are
> > disabled/enabled"), it turns out can we trigger a warning at the beginning
> > of
> > __local_bh_enable_ip(), because the upper layer irq code can call
> > hv_compose_msi_msg() with local irqs disabled.
> >
> > Let's fix the warning by switching to local_irq_save()/restore(). This is
> > not an
> > issue because hv_pci_onchannelcallback() is not slow, and it not a hot path.
> >
> > Fixes: de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()")
> > Signed-off-by: Dexuan Cui
> > Cc:
> > Cc: Stephen Hemminger
> > Cc: K. Y. Srinivasan
> > ---
>
> Reviewed-by: Haiyang Zhang
>
> Thanks you.
Hi Lorenzo,
Can I have your reply to this patch?
-- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: drop test
The test selects between two identical values, so it doesn't look useful.
It turns out that the tested expression can only be true anyway, so drop
the test, the corresponding parameter, and the corresponding argument at
the only call site.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression e,e1;
@@
* e ? e1 : e1
//
Signed-off-by: Julia Lawall
---
drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c
b/drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c
index 2ee25b2..53d3bdf 100644
--- a/drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c
+++ b/drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c
@@ -1352,7 +1352,6 @@ static void _PHY_ReloadMACRegisters8723B(
static void _PHY_PathADDAOn8723B(
struct adapter *padapter,
u32 *ADDAReg,
- bool isPathAOn,
bool is2T
)
{
@@ -1363,7 +1362,7 @@ static void _PHY_PathADDAOn8723B(
ODM_RT_TRACE(pDM_Odm, ODM_COMP_CALIBRATION, ODM_DBG_LOUD, ("ADDA
ON.\n"));
- pathOn = isPathAOn ? 0x01c00014 : 0x01c00014;
+ pathOn = 0x01c00014;
if (false == is2T) {
pathOn = 0x01c00014;
PHY_SetBBReg(pDM_Odm->Adapter, ADDAReg[0], bMaskDWord,
0x01c00014);
@@ -1556,7 +1555,7 @@ static void phy_IQCalibrate_8723B(
}
ODM_RT_TRACE(pDM_Odm, ODM_COMP_CALIBRATION, ODM_DBG_LOUD, ("IQ
Calibration for %s for %d times\n", (is2T ? "2T2R" : "1T1R"), t));
- _PHY_PathADDAOn8723B(padapter, ADDA_REG, true, is2T);
+ _PHY_PathADDAOn8723B(padapter, ADDA_REG, is2T);
/* no serial mode */
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On Thu, Jun 07, 2018 at 12:41:12AM +0200, Ard Biesheuvel wrote: > On 7 June 2018 at 00:29, Luis R. Rodriguez wrote: > > Given no one is providing a clear answer, and we cannot easily describe the > > buffer at run time we'll just move forward with > > READING_FIRMWARE_DMA_COHERENT. > > I seriously wonder whether the QCOM code cannot switch to the > streaming API instead. That is generally preferred anyway (for > performance, although that should not matter for loading firmware) but > also removes this single wart for which we have to invent new flags > and new security code plus the associated validation overhead. Given 1 month and no response I don't think we can count on that at this point. Luis -- Do not panic ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_netvsc: Add per-cpu ethtool stats for netvsc
On Wed, 6 Jun 2018 15:27:00 -0700
Yidong Ren wrote:
> From: Yidong Ren
>
> This patch implements following ethtool stats fields for netvsc:
> cpu_tx/rx_packets/bytes
> cpu_vf_tx/rx_packets/bytes
>
> Corresponding per-cpu counters exist in current code. Exposing these
> counters will help troubleshooting performance issues.
>
> Signed-off-by: Yidong Ren
This patch would be targeted for net-next (davem's tree);
but net-next is currently closed until 4.19-rc1 is done.
> ---
> drivers/net/hyperv/hyperv_net.h | 11
> drivers/net/hyperv/netvsc_drv.c | 104 +++-
> 2 files changed, 113 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
> index 960f06141472..f8c798bf9418 100644
> --- a/drivers/net/hyperv/hyperv_net.h
> +++ b/drivers/net/hyperv/hyperv_net.h
> @@ -710,6 +710,17 @@ struct netvsc_ethtool_stats {
> unsigned long wake_queue;
> };
>
> +struct netvsc_ethtool_pcpu_stats {
> + u64 rx_packets;
> + u64 rx_bytes;
> + u64 tx_packets;
> + u64 tx_bytes;
> + u64 vf_rx_packets;
> + u64 vf_rx_bytes;
> + u64 vf_tx_packets;
> + u64 vf_tx_bytes;
> +};
> +
> struct netvsc_vf_pcpu_stats {
> u64 rx_packets;
> u64 rx_bytes;
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index da07ccdf84bf..c43e64606c1a 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -1104,6 +1104,66 @@ static void netvsc_get_vf_stats(struct net_device *net,
> }
> }
>
> +static void netvsc_get_pcpu_stats(struct net_device *net,
> + struct netvsc_ethtool_pcpu_stats
> + __percpu *pcpu_tot)
> +{
> + struct net_device_context *ndev_ctx = netdev_priv(net);
> + struct netvsc_device *nvdev = rcu_dereference_rtnl(ndev_ctx->nvdev);
> + int i;
> +
> + // fetch percpu stats of vf
If you ran checkpatch you would see that Linux always uses C style
comments, and not C++ style //
> + for_each_possible_cpu(i) {
> + const struct netvsc_vf_pcpu_stats *stats =
> + per_cpu_ptr(ndev_ctx->vf_stats, i);
> + struct netvsc_ethtool_pcpu_stats *this_tot =
> + per_cpu_ptr(pcpu_tot, i);
> + unsigned int start;
> +
> + do {
> + start = u64_stats_fetch_begin_irq(&stats->syncp);
> + this_tot->vf_rx_packets = stats->rx_packets;
> + this_tot->vf_tx_packets = stats->tx_packets;
> + this_tot->vf_rx_bytes = stats->rx_bytes;
> + this_tot->vf_tx_bytes = stats->tx_bytes;
> + } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
> + this_tot->rx_packets = this_tot->vf_rx_packets;
> + this_tot->tx_packets = this_tot->vf_tx_packets;
> + this_tot->rx_bytes = this_tot->vf_rx_bytes;
> + this_tot->tx_bytes = this_tot->vf_tx_bytes;
> + }
> +
> + // fetch percpu stats of netvsc
> + for (i = 0; i < nvdev->num_chn; i++) {
> + const struct netvsc_channel *nvchan = &nvdev->chan_table[i];
> + const struct netvsc_stats *stats;
> + struct netvsc_ethtool_pcpu_stats *this_tot =
> + per_cpu_ptr(pcpu_tot, nvchan->channel->target_cpu);
> + u64 packets, bytes;
> + unsigned int start;
> +
> + stats = &nvchan->tx_stats;
> + do {
> + start = u64_stats_fetch_begin_irq(&stats->syncp);
> + packets = stats->packets;
> + bytes = stats->bytes;
> + } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
> +
> + this_tot->tx_bytes += bytes;
> + this_tot->tx_packets+= packets;
> +
> + stats = &nvchan->rx_stats;
> + do {
> + start = u64_stats_fetch_begin_irq(&stats->syncp);
> + packets = stats->packets;
> + bytes = stats->bytes;
> + } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
> +
> + this_tot->rx_bytes += bytes;
> + this_tot->rx_packets+= packets;
> + }
> +}
> +
> static void netvsc_get_stats64(struct net_device *net,
> struct rtnl_link_stats64 *t)
> {
> @@ -1201,6 +1261,23 @@ static const struct {
> { "rx_no_memory", offsetof(struct netvsc_ethtool_stats, rx_no_memory) },
> { "stop_queue", offsetof(struct netvsc_ethtool_stats, stop_queue) },
> { "wake_queue", offsetof(struct netvsc_ethtool_stats, wake_queue) },
> +}, pcpu_stats[] = {
> + { "cpu%u_rx_packets",
> + offsetof(struct netvsc_ethtool_pcpu_stats, rx_packets) },
> + { "cpu%u_rx_bytes",
> + offsetof(struct
RE: [PATCH] HV: Fix definition of struct hv_vp_assist_page.
+Allen
> -Original Message-
> From: Thomas Gleixner
> Sent: Wednesday, June 6, 2018 3:18 AM
> To: Tianyu Lan
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; mi...@redhat.com; h...@zytor.com;
> x...@kernel.org; vkuzn...@redhat.com; Alexander Grest
> ; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] HV: Fix definition of struct hv_vp_assist_page.
>
> On Mon, 21 May 2018, Tianyu Lan wrote:
>
> KY
I am looking at the published Hyper-V Top Level Functional Spec now; will get
back shortly.
>
> > The struct hv_vp_assist_page was defined incorrectly.
> > The "vtl_control" should be u64[3], "nested_enlightenments_control"
> > should be a u64 and there is 7 reserved bytes following
> "enlighten_vmentry".
> > This patch is to fix it.
> >
> > Signed-off-by: Lan Tianyu
> > ---
> > arch/x86/include/asm/hyperv-tlfs.h | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/hyperv-tlfs.h
> b/arch/x86/include/asm/hyperv-tlfs.h
> > index f7be6d03a310..fae0a5431cdd 100644
> > --- a/arch/x86/include/asm/hyperv-tlfs.h
> > +++ b/arch/x86/include/asm/hyperv-tlfs.h
> > @@ -496,10 +496,11 @@ struct hv_timer_message_payload {
> > /* Define virtual processor assist page structure. */
> > struct hv_vp_assist_page {
> > __u32 apic_assist;
> > - __u32 reserved;
> > - __u64 vtl_control[2];
> > - __u64 nested_enlightenments_control[2];
> > - __u32 enlighten_vmentry;
> > + __u32 reserved1;
> > + __u64 vtl_control[3];
> > + __u64 nested_enlightenments_control;
> > + __u8 enlighten_vmentry;
> > + __u8 reserved2[7];
> > __u64 current_nested_vmcs;
> > };
> >
> > --
> > 2.14.3
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On 7 June 2018 at 00:29, Luis R. Rodriguez wrote: > On Wed, Jun 06, 2018 at 10:41:07PM +0200, Ard Biesheuvel wrote: >> On 6 June 2018 at 22:32, Luis R. Rodriguez wrote: >> > On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: >> >> On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: >> >> > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: >> >> > > >> >> > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already >> >> > > cc'd here) are better suited to answer that question. >> >> > >> >> > Andy, David, Bjorn? >> >> >> >> Andy, David, Bjorn? >> > >> > A month now with no answer... >> > >> > Perhaps someone who has this hardware can find out empirically for us, as >> > follows (mm folks is this right?): >> > >> > page = virt_to_page(address); >> > if (!page) >> >fail closed... >> > if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32) >> > this is a DMA buffer >> > else >> > not DMA! >> > >> >> As I replied in the other thread, this code makes no sense. > > OK thanks. If we can't figure it out in code we will have no option > but to expect the worst, specially considering the silence. > >> In general, any address covered by the kernel direct mapping can be >> passed to the streaming DMA api and be mapped for device read xor >> device write. > > Right, thanks for the details -- on the other thread [0] you've clarified > that with streaming DMA API the CPU *should not* use the buffer and so > *should *be "safe", however that's still a judgement and design call. > True. > [0] https://lkml.kernel.org/r/20180606220605.gj4...@wotan.suse.de > >> Only DMA mappings that will be accessed randomly by the >> device and the CPU at the same time require the use of >> dma_alloc_coherent(), so it can take special precautions (e.g, create >> an uncached mapping if DMA is non cache coherent) > > Right and the qcom drivers *does not* use the streaming DMA API, it uses > use dma_alloc_coherent() which explicitly allows the CPU to *immediately* > have access the buffer. We have no control over the CPU and have no ways > to vet that the data we give is complete and correct. > Do you mean 'device' rather than 'CPU' here? The CPU always has access to memory allocation, but the device generally can only access the buffer after it has been mapped. Do note that especially in pc-centric code (which uses cache coherent DMA that is mapped 1:1 between the CPU physical address space and the DMA address space), you can actually get away with ignoring map/unmap entirely, in which case this becomes a 'should' as well. >> The DMA zone thing is primarily about reserving low memory ranges for >> DMA because some hardware may not have sufficient address lines wired >> up to access all of DRAM. > > Right. > > The point to all this is that it is up to LSMs to decide and trust something, > and in this case, even with the streaming DMA API in mind, it is up to LSMs > to decide. In this case we have only *one* user of request_firmware_into_buf() > and code inspection is finding that very likely the dma_alloc_coherent() calls > on the path is actually using this same coherent DMA buffer for firmware. > >> > Note that when request_firmware_into_buf() was being reviewed Mimi had >> > asked back >> > in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA >> > should be >> > used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine. >> > >> > If it is a DMA buffer *now*, why / how did this change? >> > >> > [0] https://patchwork.kernel.org/patch/9074611/ > > So it is *specially* very odd and disappointing that even though Mimi > *specifically* asked a long time ago that if a DMA buffer would be used it > should be annotated as such with READING_FIRMWARE_DMA, why the annotation > continued forward with READING_FIRMWARE_PREALLOC_BUFFER instead. > > Just as Mimi asked for READING_FIRMWARE_DMA it would seem we could reasonably > also > ask now or READING_FIRMWARE_DMA_COHERENT and READING_FIRMWARE_DMA_STREAM and > some > LSMs will just reject these calls. We don't need READING_FIRMWARE_DMA_STREAM > now > as request_firmware_into_buf() users are using dma_alloc_coherent() so we are > trying to determine if request_firmware_into_buf() should pass: > > READING_FIRMWARE_DMA_COHERENT > > Given no one is providing a clear answer, and we cannot easily describe the > buffer at run time we'll just move forward with READING_FIRMWARE_DMA_COHERENT. > I seriously wonder whether the QCOM code cannot switch to the streaming API instead. That is generally preferred anyway (for performance, although that should not matter for loading firmware) but also removes this single wart for which we have to invent new flags and new security code plus the associated validation overhead. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On Wed, Jun 06, 2018 at 10:41:07PM +0200, Ard Biesheuvel wrote: > On 6 June 2018 at 22:32, Luis R. Rodriguez wrote: > > On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: > >> On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: > >> > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: > >> > > > >> > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already > >> > > cc'd here) are better suited to answer that question. > >> > > >> > Andy, David, Bjorn? > >> > >> Andy, David, Bjorn? > > > > A month now with no answer... > > > > Perhaps someone who has this hardware can find out empirically for us, as > > follows (mm folks is this right?): > > > > page = virt_to_page(address); > > if (!page) > >fail closed... > > if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32) > > this is a DMA buffer > > else > > not DMA! > > > > As I replied in the other thread, this code makes no sense. OK thanks. If we can't figure it out in code we will have no option but to expect the worst, specially considering the silence. > In general, any address covered by the kernel direct mapping can be > passed to the streaming DMA api and be mapped for device read xor > device write. Right, thanks for the details -- on the other thread [0] you've clarified that with streaming DMA API the CPU *should not* use the buffer and so *should *be "safe", however that's still a judgement and design call. [0] https://lkml.kernel.org/r/20180606220605.gj4...@wotan.suse.de > Only DMA mappings that will be accessed randomly by the > device and the CPU at the same time require the use of > dma_alloc_coherent(), so it can take special precautions (e.g, create > an uncached mapping if DMA is non cache coherent) Right and the qcom drivers *does not* use the streaming DMA API, it uses use dma_alloc_coherent() which explicitly allows the CPU to *immediately* have access the buffer. We have no control over the CPU and have no ways to vet that the data we give is complete and correct. > The DMA zone thing is primarily about reserving low memory ranges for > DMA because some hardware may not have sufficient address lines wired > up to access all of DRAM. Right. The point to all this is that it is up to LSMs to decide and trust something, and in this case, even with the streaming DMA API in mind, it is up to LSMs to decide. In this case we have only *one* user of request_firmware_into_buf() and code inspection is finding that very likely the dma_alloc_coherent() calls on the path is actually using this same coherent DMA buffer for firmware. > > Note that when request_firmware_into_buf() was being reviewed Mimi had > > asked back > > in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA > > should be > > used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine. > > > > If it is a DMA buffer *now*, why / how did this change? > > > > [0] https://patchwork.kernel.org/patch/9074611/ So it is *specially* very odd and disappointing that even though Mimi *specifically* asked a long time ago that if a DMA buffer would be used it should be annotated as such with READING_FIRMWARE_DMA, why the annotation continued forward with READING_FIRMWARE_PREALLOC_BUFFER instead. Just as Mimi asked for READING_FIRMWARE_DMA it would seem we could reasonably also ask now or READING_FIRMWARE_DMA_COHERENT and READING_FIRMWARE_DMA_STREAM and some LSMs will just reject these calls. We don't need READING_FIRMWARE_DMA_STREAM now as request_firmware_into_buf() users are using dma_alloc_coherent() so we are trying to determine if request_firmware_into_buf() should pass: READING_FIRMWARE_DMA_COHERENT Given no one is providing a clear answer, and we cannot easily describe the buffer at run time we'll just move forward with READING_FIRMWARE_DMA_COHERENT. Luis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] hv_netvsc: Add per-cpu ethtool stats for netvsc
From: Yidong Ren
This patch implements following ethtool stats fields for netvsc:
cpu_tx/rx_packets/bytes
cpu_vf_tx/rx_packets/bytes
Corresponding per-cpu counters exist in current code. Exposing these
counters will help troubleshooting performance issues.
Signed-off-by: Yidong Ren
---
drivers/net/hyperv/hyperv_net.h | 11
drivers/net/hyperv/netvsc_drv.c | 104 +++-
2 files changed, 113 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 960f06141472..f8c798bf9418 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -710,6 +710,17 @@ struct netvsc_ethtool_stats {
unsigned long wake_queue;
};
+struct netvsc_ethtool_pcpu_stats {
+ u64 rx_packets;
+ u64 rx_bytes;
+ u64 tx_packets;
+ u64 tx_bytes;
+ u64 vf_rx_packets;
+ u64 vf_rx_bytes;
+ u64 vf_tx_packets;
+ u64 vf_tx_bytes;
+};
+
struct netvsc_vf_pcpu_stats {
u64 rx_packets;
u64 rx_bytes;
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index da07ccdf84bf..c43e64606c1a 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1104,6 +1104,66 @@ static void netvsc_get_vf_stats(struct net_device *net,
}
}
+static void netvsc_get_pcpu_stats(struct net_device *net,
+ struct netvsc_ethtool_pcpu_stats
+ __percpu *pcpu_tot)
+{
+ struct net_device_context *ndev_ctx = netdev_priv(net);
+ struct netvsc_device *nvdev = rcu_dereference_rtnl(ndev_ctx->nvdev);
+ int i;
+
+ // fetch percpu stats of vf
+ for_each_possible_cpu(i) {
+ const struct netvsc_vf_pcpu_stats *stats =
+ per_cpu_ptr(ndev_ctx->vf_stats, i);
+ struct netvsc_ethtool_pcpu_stats *this_tot =
+ per_cpu_ptr(pcpu_tot, i);
+ unsigned int start;
+
+ do {
+ start = u64_stats_fetch_begin_irq(&stats->syncp);
+ this_tot->vf_rx_packets = stats->rx_packets;
+ this_tot->vf_tx_packets = stats->tx_packets;
+ this_tot->vf_rx_bytes = stats->rx_bytes;
+ this_tot->vf_tx_bytes = stats->tx_bytes;
+ } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
+ this_tot->rx_packets = this_tot->vf_rx_packets;
+ this_tot->tx_packets = this_tot->vf_tx_packets;
+ this_tot->rx_bytes = this_tot->vf_rx_bytes;
+ this_tot->tx_bytes = this_tot->vf_tx_bytes;
+ }
+
+ // fetch percpu stats of netvsc
+ for (i = 0; i < nvdev->num_chn; i++) {
+ const struct netvsc_channel *nvchan = &nvdev->chan_table[i];
+ const struct netvsc_stats *stats;
+ struct netvsc_ethtool_pcpu_stats *this_tot =
+ per_cpu_ptr(pcpu_tot, nvchan->channel->target_cpu);
+ u64 packets, bytes;
+ unsigned int start;
+
+ stats = &nvchan->tx_stats;
+ do {
+ start = u64_stats_fetch_begin_irq(&stats->syncp);
+ packets = stats->packets;
+ bytes = stats->bytes;
+ } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
+
+ this_tot->tx_bytes += bytes;
+ this_tot->tx_packets+= packets;
+
+ stats = &nvchan->rx_stats;
+ do {
+ start = u64_stats_fetch_begin_irq(&stats->syncp);
+ packets = stats->packets;
+ bytes = stats->bytes;
+ } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
+
+ this_tot->rx_bytes += bytes;
+ this_tot->rx_packets+= packets;
+ }
+}
+
static void netvsc_get_stats64(struct net_device *net,
struct rtnl_link_stats64 *t)
{
@@ -1201,6 +1261,23 @@ static const struct {
{ "rx_no_memory", offsetof(struct netvsc_ethtool_stats, rx_no_memory) },
{ "stop_queue", offsetof(struct netvsc_ethtool_stats, stop_queue) },
{ "wake_queue", offsetof(struct netvsc_ethtool_stats, wake_queue) },
+}, pcpu_stats[] = {
+ { "cpu%u_rx_packets",
+ offsetof(struct netvsc_ethtool_pcpu_stats, rx_packets) },
+ { "cpu%u_rx_bytes",
+ offsetof(struct netvsc_ethtool_pcpu_stats, rx_bytes) },
+ { "cpu%u_tx_packets",
+ offsetof(struct netvsc_ethtool_pcpu_stats, tx_packets) },
+ { "cpu%u_tx_bytes",
+ offsetof(struct netvsc_ethtool_pcpu_stats, tx_bytes) },
+ { "cpu%u_vf_rx_packets",
+ offsetof(struct netvsc_ethtool_pcpu_stats, vf_rx_packets) },
+ { "cpu
[PATCH 5/5] staging: mt7621-dts: convert to gpio-keys
Now that gpio-interrupts work correctly, we
can use gpio-keys instead of gpio-keys-polled
for the single push-button on the gbpc-1.
Signed-off-by: NeilBrown
---
drivers/staging/mt7621-dts/gbpc1.dts |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
b/drivers/staging/mt7621-dts/gbpc1.dts
index 47bcee51e016..570d59e847bf 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -24,11 +24,8 @@
};
};
- gpio-keys-polled {
- compatible = "gpio-keys-polled";
- #address-cells = <1>;
- #size-cells = <0>;
- poll-interval = <20>;
+ gpio-keys {
+ compatible = "gpio-keys";
reset {
label = "reset";
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/5] staging: mt7621-dts: correct various clock frequencies.
The MT7621 documentation says that the sys clock - also known
as OCP clock for the Open Core Protocol - can be configured to
1/3 or 1/4 of the CPU clock.
Testing on my hardware, using the fact that the SPI clock is
based on the OCP clock and measuring transfer rates, shows
a clock of a little over 200MHz with a CPU clock of 900MHz.
So assume 1/4 is the default.
Also, the nor-flash in the gbpc1 is documented as accepting 50MHz
for request requests, and higher for other requests. So set
maximum to 50MHz.
Signed-off-by: NeilBrown
---
drivers/staging/mt7621-dts/gbpc1.dts |5 +++--
drivers/staging/mt7621-dts/mt7621.dtsi |4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
b/drivers/staging/mt7621-dts/gbpc1.dts
index 6b13d85d9d34..47bcee51e016 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -74,7 +74,7 @@
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <0>;
- spi-max-frequency = <1000>;
+ spi-max-frequency = <5000>;
partition@0 {
label = "u-boot";
@@ -104,7 +104,8 @@
&sysclock {
compatible = "fixed-clock";
- clock-frequency = <9000>;
+ /* This is normally 1/4 of cpuclock */
+ clock-frequency = <22500>;
};
&cpuclock {
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index eb3966b7f033..4a58e94c2060 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -38,8 +38,8 @@
#clock-cells = <0>;
compatible = "fixed-clock";
- /* FIXME: there should be way to detect this */
- clock-frequency = <5000>;
+ /* This is normally 1/4 of cpuclock */
+ clock-frequency = <22000>;
};
palmbus: palmbus@1E00 {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/5] staging: mt7621-spi: change mt7621_spi_wait_till_ready to take struct mt7621_spi
All callers have a 'struct mt7621_spi' and that is all
mt7621_spi_wait_till_ready() needs. So just pass it
instead of the spi_device.
Signed-off-by: NeilBrown
---
drivers/staging/mt7621-spi/spi-mt7621.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
b/drivers/staging/mt7621-spi/spi-mt7621.c
index 37f299080410..d43576d2a3f9 100644
--- a/drivers/staging/mt7621-spi/spi-mt7621.c
+++ b/drivers/staging/mt7621-spi/spi-mt7621.c
@@ -155,9 +155,8 @@ static int mt7621_spi_prepare(struct spi_device *spi,
unsigned int speed)
return 0;
}
-static inline int mt7621_spi_wait_till_ready(struct spi_device *spi)
+static inline int mt7621_spi_wait_till_ready(struct mt7621_spi *rs)
{
- struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
int i;
for (i = 0; i < RALINK_SPI_WAIT_MAX_LOOP; i++) {
@@ -187,7 +186,7 @@ static int mt7621_spi_transfer_half_duplex(struct
spi_master *master,
u32 data[9] = { 0 };
u32 val;
- mt7621_spi_wait_till_ready(spi);
+ mt7621_spi_wait_till_ready(rs);
list_for_each_entry(t, &m->transfers, transfer_list) {
const u8 *buf = t->tx_buf;
@@ -238,7 +237,7 @@ static int mt7621_spi_transfer_half_duplex(struct
spi_master *master,
val |= SPI_CTL_START;
mt7621_spi_write(rs, MT7621_SPI_TRANS, val);
- mt7621_spi_wait_till_ready(spi);
+ mt7621_spi_wait_till_ready(rs);
mt7621_spi_set_cs(spi, 0);
@@ -278,7 +277,7 @@ static int mt7621_spi_transfer_full_duplex(struct
spi_master *master,
u32 data[9] = { 0 };
u32 val = 0;
- mt7621_spi_wait_till_ready(spi);
+ mt7621_spi_wait_till_ready(rs);
list_for_each_entry(t, &m->transfers, transfer_list) {
const u8 *buf = t->tx_buf;
@@ -323,7 +322,7 @@ static int mt7621_spi_transfer_full_duplex(struct
spi_master *master,
val |= SPI_CTL_START;
mt7621_spi_write(rs, MT7621_SPI_TRANS, val);
- mt7621_spi_wait_till_ready(spi);
+ mt7621_spi_wait_till_ready(rs);
mt7621_spi_set_cs(spi, 0);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/5] staging: mt7621-pci: use rt_sysc_?32() to access system-control register.
This driver currently has internal knowledge ofthe address
of system-control registers and accesses them by dereferencing
a constant pointer.
It is cleaner to use rt_sysc_r32(), rt_sysc_w32(), rt_sysc_m32()
which is a more standard interface.
So change the defined names to offsets instead of pointers,
and use these functions.
Signed-off-by: NeilBrown
---
drivers/staging/mt7621-pci/pci-mt7621.c | 57 +++
1 file changed, 27 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 17f2105ec698..4d892f2136ec 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -55,6 +55,7 @@
#include
#include
+#include
/*
* These functions and structures provide the BIOS scan and mapping of the PCI
@@ -72,7 +73,6 @@
#define RALINK_PCIE0_RST (1<<24)
#define RALINK_PCIE1_RST (1<<25)
#define RALINK_PCIE2_RST (1<<26)
-#define RALINK_SYSCTL_BASE 0xBE00
#define RALINK_PCI_PCICFG_ADDR *(volatile u32 *)(RALINK_PCI_BASE +
0x)
#define RALINK_PCI_PCIMSK_ADDR *(volatile u32 *)(RALINK_PCI_BASE +
0x000C)
@@ -133,31 +133,28 @@
#define RALINK_PCI_MM_MAP_BASE 0x6000
#define RALINK_PCI_IO_MAP_BASE 0x1e16
-#define RALINK_SYSTEM_CONTROL_BASE 0xbe00
-
#define ASSERT_SYSRST_PCIE(val)\
do {\
- if (*(unsigned int *)(0xbe0c) == 0x00030101)\
- RALINK_RSTCTRL |= val; \
+ if (rt_sysc_r32(SYSC_REG_CHIP_REV) == 0x00030101) \
+ rt_sysc_m32(0, val, RALINK_RSTCTRL);\
else\
- RALINK_RSTCTRL &= ~val; \
+ rt_sysc_m32(val, 0, RALINK_RSTCTRL);\
} while(0)
#define DEASSERT_SYSRST_PCIE(val) \
do {\
- if (*(unsigned int *)(0xbe0c) == 0x00030101)\
- RALINK_RSTCTRL &= ~val; \
+ if (rt_sysc_r32(SYSC_REG_CHIP_REV) == 0x00030101) \
+ rt_sysc_m32(val, 0, RALINK_RSTCTRL);\
else\
- RALINK_RSTCTRL |= val; \
+ rt_sysc_m32(0, val, RALINK_RSTCTRL);\
} while(0)
-#define RALINK_SYSCFG1 *(unsigned int
*)(RALINK_SYSTEM_CONTROL_BASE + 0x14)
-#define RALINK_CLKCFG1 *(unsigned int
*)(RALINK_SYSTEM_CONTROL_BASE + 0x30)
-#define RALINK_RSTCTRL *(unsigned int
*)(RALINK_SYSTEM_CONTROL_BASE + 0x34)
-#define RALINK_GPIOMODE*(unsigned int
*)(RALINK_SYSTEM_CONTROL_BASE + 0x60)
-#define RALINK_PCIE_CLK_GEN*(unsigned int
*)(RALINK_SYSTEM_CONTROL_BASE + 0x7c)
-#define RALINK_PCIE_CLK_GEN1 *(unsigned int
*)(RALINK_SYSTEM_CONTROL_BASE + 0x80)
-#define PPLL_CFG1 *(unsigned int
*)(RALINK_SYSTEM_CONTROL_BASE + 0x9c)
-#define PPLL_DRV *(unsigned int
*)(RALINK_SYSTEM_CONTROL_BASE + 0xa0)
-//RALINK_SYSCFG1 bit
+#define RALINK_CLKCFG1 0x30
+#define RALINK_RSTCTRL 0x34
+#define RALINK_GPIOMODE0x60
+#define RALINK_PCIE_CLK_GEN0x7c
+#define RALINK_PCIE_CLK_GEN1 0x80
+#define PPLL_CFG1 0x9c
+#define PPLL_DRV 0xa0
+/* SYSC_REG_SYSTEM_CONFIG1 bits */
#define RALINK_PCI_HOST_MODE_EN(1<<7)
#define RALINK_PCIE_RC_MODE_EN (1<<8)
//RALINK_RSTCTRL bit
@@ -383,7 +380,7 @@ bypass_pipe_rst(void)
void
set_phy_for_ssc(void)
{
- unsigned long reg = (*(volatile u32 *)(RALINK_SYSCTL_BASE + 0x10));
+ unsigned long reg = rt_sysc_r32(SYSC_REG_SYSTEM_CONFIG0);
reg = (reg >> 6) & 0x7;
/* Set PCIe Port0 & Port1 PHY to disable SSC */
@@ -521,15 +518,15 @@ static int mt7621_pci_probe(struct platform_device *pdev)
read_config(0, 2, 0, 0x70c, &val);
printk("Port 2 N_FTS = %x\n", (unsigned int)val);
- RALINK_RSTCTRL = (RALINK_RSTCTRL | RALINK_PCIE_RST);
- RALINK_SYSCFG1 &= ~(0x30);
- RALINK_SYSCFG1 |= (2<<4);
- RALINK_PCIE_CLK_GEN &= 0x7fff;
- RALINK_PCIE_CLK_GEN1 &= 0x80ff;
- RALINK_PCIE_CLK_GEN1 |= 0xa << 24;
- RALINK_PCIE_CLK_GEN |= 0x8000;
+ rt_sysc_m32(0, RALINK_PCIE_RST, RALINK_RSTCTRL);
+ rt_sysc_m32(0x30, 2 << 4, SYSC_REG_SYSTEM_CONFIG1);
+
+ rt_sysc_m32(0x8000, 0, RALINK_PCIE_CLK_GEN);
+ rt_sysc_m32(0x7f0
[PATCH 3/5] staging: mt7621-spi: revised half-duplex message handling
The mt7621 SPI engine has a 32 byte buffer and the driver
currently only allows 32-byte read requests and 36 bytes writes
(there is a 4byte op/addr buffer).
This is an unnecessary limitation. As the SPI clock is controlled
by the host it is quite acceptable to send a larger message in
multiple smaller transactions. As long as Chip Select is kept asserted
the whole time, the SPI engine can be run multiple times for
a single SPI message.
This patch factors out the transaction logic and calls for each
transfer in the message. A write transfer might leave bytes in the
buffer to be combined with a following read transfer, as this is
a common pattern.
With this in place, we can remove the current max_transfer_size limit.
In testing, this increases the read throughput for a NOR flash chip
from 1.4MB/s to 2.3MB/s, a 50% improvement.
Signed-off-by: NeilBrown
---
drivers/staging/mt7621-spi/spi-mt7621.c | 165 ++-
1 file changed, 98 insertions(+), 67 deletions(-)
diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
b/drivers/staging/mt7621-spi/spi-mt7621.c
index d43576d2a3f9..11474e6ad01b 100644
--- a/drivers/staging/mt7621-spi/spi-mt7621.c
+++ b/drivers/staging/mt7621-spi/spi-mt7621.c
@@ -65,6 +65,7 @@ struct mt7621_spi {
unsigned intsys_freq;
unsigned intspeed;
struct clk *clk;
+ int pending_write;
struct mt7621_spi_ops *ops;
};
@@ -96,6 +97,7 @@ static void mt7621_spi_reset(struct mt7621_spi *rs, int
duplex)
master &= ~(1 << 10);
mt7621_spi_write(rs, MT7621_SPI_MASTER, master);
+ rs->pending_write = 0;
}
static void mt7621_spi_set_cs(struct spi_device *spi, int enable)
@@ -173,90 +175,124 @@ static inline int mt7621_spi_wait_till_ready(struct
mt7621_spi *rs)
return -ETIMEDOUT;
}
-static int mt7621_spi_transfer_half_duplex(struct spi_master *master,
- struct spi_message *m)
+static void mt7621_spi_read_half_duplex(struct mt7621_spi *rs,
+ int rx_len, u8 *buf)
{
- struct mt7621_spi *rs = spi_master_get_devdata(master);
- struct spi_device *spi = m->spi;
- unsigned int speed = spi->max_speed_hz;
- struct spi_transfer *t = NULL;
- int status = 0;
- int i, len = 0;
- int rx_len = 0;
- u32 data[9] = { 0 };
- u32 val;
+ /* Combine with any pending write, and perform one or
+* more half-duplex transactions reading 'len' bytes.
+* Data to be written is already in MT7621_SPI_DATA*
+*/
+ int tx_len = rs->pending_write;
- mt7621_spi_wait_till_ready(rs);
+ rs->pending_write = 0;
- list_for_each_entry(t, &m->transfers, transfer_list) {
- const u8 *buf = t->tx_buf;
+ while (rx_len || tx_len) {
+ int i;
+ u32 val = (min(tx_len, 4) * 8) << 24;
+ int rx = min(rx_len, 32);
- if (t->rx_buf)
- rx_len += t->len;
+ if (tx_len > 4)
+ val |= (tx_len - 4) * 8;
+ val |= (rx * 8) << 12;
+ mt7621_spi_write(rs, MT7621_SPI_MOREBUF, val);
- if (!buf)
- continue;
+ tx_len = 0;
- if (t->speed_hz < speed)
- speed = t->speed_hz;
+ val = mt7621_spi_read(rs, MT7621_SPI_TRANS);
+ val |= SPI_CTL_START;
+ mt7621_spi_write(rs, MT7621_SPI_TRANS, val);
- if (WARN_ON(len + t->len > 36)) {
- status = -EIO;
- goto msg_done;
- }
+ mt7621_spi_wait_till_ready(rs);
- for (i = 0; i < t->len; i++, len++)
- data[len / 4] |= buf[i] << (8 * (len & 3));
+ for (i = 0; i < rx; i++) {
+ if ((i % 4) == 0)
+ val = mt7621_spi_read(rs, MT7621_SPI_DATA0 + i);
+ *buf++ = val & 0xff;
+ val >>= 8;
+ }
+ rx_len -= i;
}
+}
- if (WARN_ON(rx_len > 32)) {
- status = -EIO;
- goto msg_done;
- }
+static inline void mt7621_spi_flush(struct mt7621_spi *rs)
+{
+ mt7621_spi_read_half_duplex(rs, 0, NULL);
+}
- if (mt7621_spi_prepare(spi, speed)) {
- status = -EIO;
- goto msg_done;
+static void mt7621_spi_write_half_duplex(struct mt7621_spi *rs,
+int tx_len, const u8 *buf)
+{
+ int val = 0;
+ int len = rs->pending_write;
+
+ if (len & 3) {
+ val = mt7621_spi_read(rs, MT7621_SPI_OPCODE + (len & ~3));
+ if (len < 4) {
+ val <<= (4 - len) * 8;
+ val = swab
[PATCH 0/5] staging: mt7621 improvements, particularly SPI
The highlight here is a substantial rewrite of the mt7621 SPI driver so that it makes sensible use of the hardware. The hardware is quite capable of transceiving large messages, it just needs to handle them 32 bytes at a time. This is more efficient than requiring upper levels to only send 32byte messages. Thanks, NeilBrown --- NeilBrown (5): staging: mt7621-pci: use rt_sysc_?32() to access system-control register. staging: mt7621-spi: change mt7621_spi_wait_till_ready to take struct mt7621_spi staging: mt7621-spi: revised half-duplex message handling staging: mt7621-dts: correct various clock frequencies. staging: mt7621-dts: convert to gpio-keys drivers/staging/mt7621-dts/gbpc1.dts| 12 +- drivers/staging/mt7621-dts/mt7621.dtsi |4 - drivers/staging/mt7621-pci/pci-mt7621.c | 57 +- drivers/staging/mt7621-spi/spi-mt7621.c | 174 ++- 4 files changed, 136 insertions(+), 111 deletions(-) -- Signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] hv_netvsc: Fix a network regression after ifdown/ifup
> From: Stephen Hemminger > Sent: Wednesday, June 6, 2018 14:07 > ... > Ok, just skip the check and big comment. > wake all queues is harmless if they are already awake. Ok, I'll post a v2 without the check and the comment shortly. -- Dexuan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] hv_netvsc: Fix a network regression after ifdown/ifup
Recently people reported the NIC stops working after
"ifdown eth0; ifup eth0". It turns out in this case the TX queues are not
enabled, after the refactoring of the common detach logic: when the NIC
has sub-channels, usually we enable all the TX queues after all
sub-channels are set up: see rndis_set_subchannel() ->
netif_device_attach(), but in the case of "ifdown eth0; ifup eth0" where
the number of channels doesn't change, we also must make sure the TX queues
are enabled. The patch fixes the regression.
Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
Signed-off-by: Dexuan Cui
Cc: sta...@vger.kernel.org
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
---
Changes since v1:
Removed the check and the comment from the code [Stephen Hemminger]
drivers/net/hyperv/netvsc_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index da07ccd..eb8dccd 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -126,8 +126,10 @@ static int netvsc_open(struct net_device *net)
}
rdev = nvdev->extension;
- if (!rdev->link_state)
+ if (!rdev->link_state) {
netif_carrier_on(net);
+ netif_tx_wake_all_queues(net);
+ }
if (vf_netdev) {
/* Setting synthetic device up transparently sets
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] hv_netvsc: Fix a network regression after ifdown/ifup
Recently people reported the NIC stops working after
"ifdown eth0; ifup eth0". It turns out in this case the TX queues are not
enabled, after the refactoring of the common detach logic. The patch fixes
the regression.
Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
Signed-off-by: Dexuan Cui
Cc: sta...@vger.kernel.org
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
---
drivers/net/hyperv/netvsc_drv.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index da07ccd..4461e16 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -126,9 +126,20 @@ static int netvsc_open(struct net_device *net)
}
rdev = nvdev->extension;
- if (!rdev->link_state)
+ if (!rdev->link_state) {
netif_carrier_on(net);
+ /* When the NIC has sub-channels, usually we enable all the
+* TX queues after all sub-channels are set up: see
+* rndis_set_subchannel() -> netif_device_attach(), but in
+* the case of "ifdown eth0; ifup eth0" where the number of
+* channels doesn't change, we also must make sure the
+* TX queues are enabled.
+*/
+ if (atomic_read(&nvdev->open_chn) == nvdev->num_chn)
+ netif_tx_wake_all_queues(net);
+ }
+
if (vf_netdev) {
/* Setting synthetic device up transparently sets
* slave as up. If open fails, then slave will be
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On 6 June 2018 at 22:32, Luis R. Rodriguez wrote: > On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: >> On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: >> > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: >> > > >> > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already >> > > cc'd here) are better suited to answer that question. >> > >> > Andy, David, Bjorn? >> >> Andy, David, Bjorn? > > A month now with no answer... > > Perhaps someone who has this hardware can find out empirically for us, as > follows (mm folks is this right?): > > page = virt_to_page(address); > if (!page) >fail closed... > if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32) > this is a DMA buffer > else > not DMA! > As I replied in the other thread, this code makes no sense. In general, any address covered by the kernel direct mapping can be passed to the streaming DMA api and be mapped for device read xor device write. Only DMA mappings that will be accessed randomly by the device and the CPU at the same time require the use of dma_alloc_coherent(), so it can take special precautions (e.g, create an uncached mapping if DMA is non cache coherent) The DMA zone thing is primarily about reserving low memory ranges for DMA because some hardware may not have sufficient address lines wired up to access all of DRAM. > Note that when request_firmware_into_buf() was being reviewed Mimi had asked > back > in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA > should be > used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine. > > If it is a DMA buffer *now*, why / how did this change? > > [0] https://patchwork.kernel.org/patch/9074611/ > > Luis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: > On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: > > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: > > > > > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already > > > cc'd here) are better suited to answer that question. > > > > Andy, David, Bjorn? > > Andy, David, Bjorn? A month now with no answer... Perhaps someone who has this hardware can find out empirically for us, as follows (mm folks is this right?): page = virt_to_page(address); if (!page) fail closed... if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32) this is a DMA buffer else not DMA! Note that when request_firmware_into_buf() was being reviewed Mimi had asked back in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA should be used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine. If it is a DMA buffer *now*, why / how did this change? [0] https://patchwork.kernel.org/patch/9074611/ Luis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: refactor synths array to use a list
On Wed, Jun 06, 2018 at 03:26:28PM +0200, Samuel Thibault wrote: > Hello, > > Justin Skists, le lun. 04 juin 2018 10:52:12 +0100, a ecrit: > > The synths[] array is a collection of synths acting like a list. > > There is no need for synths to be an array, so refactor synths[] to use > > standard kernel list_head API, instead, and modify the usages to suit. > > As a side-effect, the maximum number of synths has also become redundant. > > This looks good to me, > > Reviewed-by: Samuel Thibault Thank you. > Did you test to e.g. insmod speakup_soft ; insmod speakup_dummy ; rmmod > speakup_soft ; rmmod speakup_dummy > > to make sure it did work correctly? I did. And I swapped synths via the sysfs interface. As always, it's always good to double-check. So, I've scripted the test sequence that I used and attached the output. > I'd also rather see it tested in the real wild before committing. As it should be. :) Justin Kernel info --- # uname -a Linux buildroot 4.17.0-rc7-next-20180601 #1 SMP Mon Jun 4 09:31:05 BST 2018 x86_64 GNU/Linux insert modules -- # modprobe speakup # modprobe speakup_dummy dev=ttyS1 ser=1 start=1 # modprobe speakup_soft # lsmod Module Size Used byTainted: G speakup_soft 16384 0 speakup_dummy 16384 0 speakup 118784 2 speakup_soft,speakup_dummy switching to soft - # echo 'soft' > /sys/accessibility/speakup/synth # cat /sys/accessibility/speakup/synth soft switching to dummy -- # echo 'dummy' > /sys/accessibility/speakup/synth # cat /sys/accessibility/speakup/synth dummy Removing modules # rmmod speakup_dummy # rmmod speakup_soft # lsmod Module Size Used byTainted: G speakup 118784 0 view message log # tail -25 /var/log/messages Jun 6 20:06:57 buildroot kern.notice kernel: random: ssh-keygen: uninitialized urandom read (32 bytes read) Jun 6 20:06:57 buildroot kern.notice kernel: random: sshd: uninitialized urandom read (32 bytes read) Jun 6 20:06:57 buildroot auth.info sshd[105]: Server listening on :: port 22. Jun 6 20:06:57 buildroot auth.info sshd[105]: Server listening on 0.0.0.0 port 22. Jun 6 20:06:57 buildroot daemon.info : starting pid 107, tty '/dev/tty1': '/sbin/getty -L tty1 0 vt100 ' Jun 6 20:07:00 buildroot auth.info login[107]: root login on 'tty1' Jun 6 20:07:08 buildroot kern.notice kernel: random: crng init done Jun 6 20:07:12 buildroot kern.warn kernel: speakup: module is from the staging directory, the quality is unknown, you have been warned. Jun 6 20:07:13 buildroot kern.info kernel: input: Speakup as /devices/virtual/input/input4 Jun 6 20:07:13 buildroot kern.info kernel: initialized device: /dev/synth, node (MAJOR 10, MINOR 25) Jun 6 20:07:13 buildroot kern.info kernel: speakup 3.1.6: initialized Jun 6 20:07:13 buildroot kern.info kernel: synth name on entry is: (null) Jun 6 20:07:13 buildroot kern.warn kernel: speakup_dummy: module is from the staging directory, the quality is unknown, you have been warned. Jun 6 20:07:13 buildroot kern.warn kernel: synth probe Jun 6 20:07:13 buildroot kern.warn kernel: speakup_soft: module is from the staging directory, the quality is unknown, you have been warned. Jun 6 20:07:13 buildroot kern.info kernel: releasing synth dummy Jun 6 20:07:13 buildroot kern.warn kernel: synth probe Jun 6 20:07:13 buildroot kern.info kernel: initialized device: /dev/softsynth, node (MAJOR 10, MINOR 26) Jun 6 20:07:13 buildroot kern.info kernel: initialized device: /dev/softsynthu, node (MAJOR 10, MINOR 27) Jun 6 20:07:13 buildroot kern.warn kernel: soft already in use Jun 6 20:07:13 buildroot kern.info kernel: releasing synth soft Jun 6 20:07:13 buildroot kern.info kernel: unregistered /dev/softsynth Jun 6 20:07:13 buildroot kern.info kernel: unregistered /dev/softsynthu Jun 6 20:07:13 buildroot kern.warn kernel: synth probe Jun 6 20:07:13 buildroot kern.info kernel: releasing synth dummy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4] Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic
In the VM mode on Hyper-V, currently, when the kernel panics, an error
code and few register values are populated in an MSR and the Hypervisor
notified. This information is collected on the host. The amount of
information currently collected is found to be limited and not very
actionable. To gather more actionable data, such as stack trace, the
proposal is to write one page worth of kmsg data on an allocated page
and the Hypervisor notified of the page address through the MSR.
- Sysctl option to control the behavior, with ON by default.
Cc: K. Y. Srinivasan
Cc: Stephen Hemminger
Signed-off-by: Sunil Muthuswamy
Drivers: HV:Send one page worth of kmsg dump over Hyper-V during panic
Signed-off-by: Sunil Muthuswamy
---
Changes since v1:
- Added a sysctl config option to allow the user to control if panic message
should be reported to Hyper-V.
Changes since v2:
- Addressed comments from Greg KH.
- Moved the sysctl config option from 'kernel.hyperv' to 'kernel.' since the
likelihood of having many Hyper-V specific sysctl config options seemed less
and so having a specific dir for Hyper-V seemed unnecessary overhead.
Changes since v3:
- The feature is only enabled if the capability is supported by the hypervisor.
This is done by reading the crash control MSR, in addition to the pre-existing
check for the hypervisor feature using the CPUID.
---
Documentation/sysctl/kernel.txt| 11
arch/x86/hyperv/hv_init.c | 27 +
arch/x86/include/asm/hyperv-tlfs.h | 5 +-
arch/x86/include/asm/mshyperv.h| 1 +
drivers/hv/vmbus_drv.c | 116 +
5 files changed, 158 insertions(+), 2 deletions(-)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index eded671d..5958503 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -39,6 +39,7 @@ show up in /proc/sys/kernel:
- hung_task_check_count
- hung_task_timeout_secs
- hung_task_warnings
+- hyperv_record_panic_msg
- kexec_load_disabled
- kptr_restrict
- l2cr[ PPC only ]
@@ -374,6 +375,16 @@ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
==
+hyperv_record_panic_msg:
+
+Controls whether the panic kmsg data should be reported to Hyper-V.
+
+0: do not report panic kmsg data.
+
+1: report the panic kmsg data. This is the default behavior.
+
+==
+
kexec_load_disabled:
A toggle indicating if the kexec_load syscall has been disabled. This
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index cfecc22..af57162 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -395,6 +395,33 @@ void hyperv_report_panic(struct pt_regs *regs, long err)
}
EXPORT_SYMBOL_GPL(hyperv_report_panic);
+/**
+ * hyperv_report_panic_msg - report panic message to Hyper-V
+ * @pa: physical address of the panic page containing the message
+ * @size: size of the message in the page
+ */
+void hyperv_report_panic_msg(phys_addr_t pa, size_t size)
+{
+ /*
+* P3 to contain the physical address of the panic page & P4 to
+* contain the size of the panic data in that page. Rest of the
+* registers are no-op when the NOTIFY_MSG flag is set.
+*/
+ wrmsrl(HV_X64_MSR_CRASH_P0, 0);
+ wrmsrl(HV_X64_MSR_CRASH_P1, 0);
+ wrmsrl(HV_X64_MSR_CRASH_P2, 0);
+ wrmsrl(HV_X64_MSR_CRASH_P3, pa);
+ wrmsrl(HV_X64_MSR_CRASH_P4, size);
+
+ /*
+* Let Hyper-V know there is crash data available along with
+* the panic message.
+*/
+ wrmsrl(HV_X64_MSR_CRASH_CTL,
+ (HV_CRASH_CTL_CRASH_NOTIFY | HV_CRASH_CTL_CRASH_NOTIFY_MSG));
+}
+EXPORT_SYMBOL_GPL(hyperv_report_panic_msg);
+
bool hv_is_hyperv_initialized(void)
{
union hv_x64_msr_hypercall_contents hypercall_msr;
diff --git a/arch/x86/include/asm/hyperv-tlfs.h
b/arch/x86/include/asm/hyperv-tlfs.h
index 416cb0e..76c58af 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -171,9 +171,10 @@
#define HV_X64_ENLIGHTENED_VMCS_RECOMMENDED(1 << 14)
/*
- * Crash notification flag.
+ * Crash notification flags.
*/
-#define HV_CRASH_CTL_CRASH_NOTIFY (1ULL << 63)
+#define HV_CRASH_CTL_CRASH_NOTIFY_MSG BIT_ULL(62)
+#define HV_CRASH_CTL_CRASH_NOTIFY BIT_ULL(63)
/* MSR used to identify the guest OS. */
#define HV_X64_MSR_GUEST_OS_ID 0x4000
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index b90e796..ac83f2d 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -262,6 +262,7 @@ void hyperv_init(void);
void hyperv_setup_mmu_ops(void);
void hyper_alloc_mmu(void);
void hyperv_report_panic(struct pt_regs *regs, long err);
+void hyperv_report_panic_msg(phys_addr_t pa, size_t size);
bool hv_is
Re: [PATCH] staging: speakup: refactor synths array to use a list
Hello,
Justin Skists, le lun. 04 juin 2018 10:52:12 +0100, a ecrit:
> The synths[] array is a collection of synths acting like a list.
> There is no need for synths to be an array, so refactor synths[] to use
> standard kernel list_head API, instead, and modify the usages to suit.
> As a side-effect, the maximum number of synths has also become redundant.
This looks good to me,
Reviewed-by: Samuel Thibault
Did you test to e.g. insmod speakup_soft ; insmod speakup_dummy ; rmmod
speakup_soft ; rmmod speakup_dummy
to make sure it did work correctly?
I'd also rather see it tested in the real wild before committing. Could
somebody on the speakup mailing list test the patch? (which I have
re-attached as a file for conveniency).
Samuel
---
drivers/staging/speakup/spk_types.h | 2 ++
drivers/staging/speakup/synth.c | 40 ++---
2 files changed, 15 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/speakup/spk_types.h
b/drivers/staging/speakup/spk_types.h
index 3e082dc3d45c..a2fc72c29894 100644
--- a/drivers/staging/speakup/spk_types.h
+++ b/drivers/staging/speakup/spk_types.h
@@ -160,6 +160,8 @@ struct spk_io_ops {
};
struct spk_synth {
+ struct list_head node;
+
const char *name;
const char *version;
const char *long_name;
diff --git a/drivers/staging/speakup/synth.c b/drivers/staging/speakup/synth.c
index 7deeb7061018..25f259ee4ffc 100644
--- a/drivers/staging/speakup/synth.c
+++ b/drivers/staging/speakup/synth.c
@@ -18,8 +18,7 @@
#include "speakup.h"
#include "serialio.h"
-#define MAXSYNTHS 16 /* Max number of synths in array. */
-static struct spk_synth *synths[MAXSYNTHS + 1];
+static LIST_HEAD(synths);
struct spk_synth *synth;
char spk_pitch_buff[32] = "";
static int module_status;
@@ -355,9 +354,8 @@ struct var_t synth_time_vars[] = {
/* called by: speakup_init() */
int synth_init(char *synth_name)
{
- int i;
int ret = 0;
- struct spk_synth *synth = NULL;
+ struct spk_synth *tmp, *synth = NULL;
if (!synth_name)
return 0;
@@ -371,9 +369,10 @@ int synth_init(char *synth_name)
mutex_lock(&spk_mutex);
/* First, check if we already have it loaded. */
- for (i = 0; i < MAXSYNTHS && synths[i]; i++)
- if (strcmp(synths[i]->name, synth_name) == 0)
- synth = synths[i];
+ list_for_each_entry(tmp, &synths, node) {
+ if (strcmp(tmp->name, synth_name) == 0)
+ synth = tmp;
+ }
/* If we got one, initialize it now. */
if (synth)
@@ -448,29 +447,23 @@ void synth_release(void)
/* called by: all_driver_init() */
int synth_add(struct spk_synth *in_synth)
{
- int i;
int status = 0;
+ struct spk_synth *tmp;
mutex_lock(&spk_mutex);
- for (i = 0; i < MAXSYNTHS && synths[i]; i++)
- /* synth_remove() is responsible for rotating the array down */
- if (in_synth == synths[i]) {
+
+ list_for_each_entry(tmp, &synths, node) {
+ if (tmp == in_synth) {
mutex_unlock(&spk_mutex);
return 0;
}
- if (i == MAXSYNTHS) {
- pr_warn("Error: attempting to add a synth past end of array\n");
- mutex_unlock(&spk_mutex);
- return -1;
}
if (in_synth->startup)
status = do_synth_init(in_synth);
- if (!status) {
- synths[i++] = in_synth;
- synths[i] = NULL;
- }
+ if (!status)
+ list_add_tail(&in_synth->node, &synths);
mutex_unlock(&spk_mutex);
return status;
@@ -479,17 +472,10 @@ EXPORT_SYMBOL_GPL(synth_add);
void synth_remove(struct spk_synth *in_synth)
{
- int i;
-
mutex_lock(&spk_mutex);
if (synth == in_synth)
synth_release();
- for (i = 0; synths[i]; i++) {
- if (in_synth == synths[i])
- break;
- }
- for ( ; synths[i]; i++) /* compress table */
- synths[i] = synths[i + 1];
+ list_del(&in_synth->node);
module_status = 0;
mutex_unlock(&spk_mutex);
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] android: binder: Drop dependency on !M68K
On Wed, Jun 06, 2018 at 02:40:56PM +0200, Geert Uytterhoeven wrote:
> As of commit 7124330dabe5b3cb ("m68k/uaccess: Revive 64-bit
> get_user()"), the 64-bit Android binder interface builds fine on m68k.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/android/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> index ee4880bfdcdc98d2..432e9ad770703275 100644
> --- a/drivers/android/Kconfig
> +++ b/drivers/android/Kconfig
> @@ -10,7 +10,7 @@ if ANDROID
>
> config ANDROID_BINDER_IPC
> bool "Android Binder IPC Driver"
> - depends on MMU && !M68K
> + depends on MMU
Wonderful! Thanks for this, I'll queue it up after 4.18-rc1 is out.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] hv_netvsc: add per-cpu ethtool stats for netvsc
Thank you, Greg. I'm sorry for didn't read the guidelines on kernel newbies. Please ignore this patch. Thanks, Yidong -Original Message- From: Greg KH Sent: Wednesday, June 6, 2018 1:34 AM To: Yidong Ren Cc: driverdev-devel@linuxdriverproject.org; Haiyang Zhang ; Stephen Hemminger ; Madhan Sivakumar Subject: Re: [PATCH] hv_netvsc: add per-cpu ethtool stats for netvsc On Tue, Jun 05, 2018 at 08:14:06PM +, Yidong Ren wrote: > This patch implements following ethtool stats fields for netvsc: > cpu_rx_packets > cpu_tx_packets > cpu_rx_bytes > cpu_tx_bytes > cpu_vf_rx_packets > cpu_vf_tx_packets > cpu_vf_rx_bytes > cpu_vf_tx_bytes > --- No signed-off-by line? Always use scripts/checkpatch.pl on your patches os you do not get grumpy kernel maintainers telling you to run checkpatch.pl on your patches... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] android: binder: Drop dependency on !M68K
As of commit 7124330dabe5b3cb ("m68k/uaccess: Revive 64-bit
get_user()"), the 64-bit Android binder interface builds fine on m68k.
Signed-off-by: Geert Uytterhoeven
---
drivers/android/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
index ee4880bfdcdc98d2..432e9ad770703275 100644
--- a/drivers/android/Kconfig
+++ b/drivers/android/Kconfig
@@ -10,7 +10,7 @@ if ANDROID
config ANDROID_BINDER_IPC
bool "Android Binder IPC Driver"
- depends on MMU && !M68K
+ depends on MMU
default n
---help---
Binder is used in Android for both communication between processes,
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: rtl8192e: Series of coding style changes
> On 06 June 2018 at 12:39 John Whitmore wrote: > Again these are just some simple coding style changes to the file, so nothing > of importance. If it keeps grumpy maintainers happy, then it's of great importance! :-) Justin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 7/8] staging: rtl8192e: Optimise Comparison to NULL tests - Coding Style
Change comparison to NULL to better adhere to coding standard.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index 7ea516609d4c..9cca4a8f1cf5 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -520,7 +520,7 @@ void HTConstructCapabilityElement(struct ieee80211_device
*ieee, u8 *posHTCap, u
PHT_CAPABILITY_ELE pCapELE = NULL;
//u8 bIsDeclareMCS13;
- if ((posHTCap == NULL) || (pHT == NULL)) {
+ if (!posHTCap || !pHT) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "posHTCap or pHTInfo can't be
null in HTConstructCapabilityElement()\n");
return;
}
@@ -624,7 +624,7 @@ void HTConstructInfoElement(struct ieee80211_device *ieee,
u8 *posHTInfo, u8 *le
PRT_HIGH_THROUGHPUT pHT = ieee->pHTInfo;
PHT_INFORMATION_ELE pHTInfoEle =
(PHT_INFORMATION_ELE)posHTInfo;
- if ((posHTInfo == NULL) || (pHTInfoEle == NULL)) {
+ if (!posHTInfo || !pHTInfoEle) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "posHTInfo or pHTInfoEle
can't be null in HTConstructInfoElement()\n");
return;
}
@@ -687,7 +687,7 @@ void HTConstructInfoElement(struct ieee80211_device *ieee,
u8 *posHTInfo, u8 *le
*
*/
void HTConstructRT2RTAggElement(struct ieee80211_device *ieee, u8
*posRT2RTAgg, u8 *len)
{
- if (posRT2RTAgg == NULL) {
+ if (!posRT2RTAgg) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "posRT2RTAgg can't be null in
HTConstructRT2RTAggElement()\n");
return;
}
@@ -737,7 +737,7 @@ static u8 HT_PickMCSRate(struct ieee80211_device *ieee, u8
*pOperateMCS)
{
u8 i;
- if (pOperateMCS == NULL) {
+ if (!pOperateMCS) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "pOperateMCS can't be null in
HT_PickMCSRate()\n");
return false;
}
@@ -799,7 +799,7 @@ u8 HTGetHighestMCSRate(struct ieee80211_device *ieee, u8
*pMCSRateSet, u8 *pMCSF
u8 mcsRate = 0;
u8 availableMcsRate[16];
- if (pMCSRateSet == NULL || pMCSFilter == NULL) {
+ if (!pMCSRateSet || !pMCSFilter) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "pMCSRateSet or pMCSFilter
can't be null in HTGetHighestMCSRate()\n");
return false;
}
--
2.17.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 6/8] staging: rtl8192e: Correct declaration of HTResetIOTSetting - Coding Style
Declaration of function was spread over three lines.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index 981433f6c4f2..7ea516609d4c 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -498,9 +498,7 @@ static u8 HTIOTActIsCCDFsync(u8 *PeerMacAddr)
return retValue;
}
-void HTResetIOTSetting(
- PRT_HIGH_THROUGHPUT pHTInfo
-)
+void HTResetIOTSetting(PRT_HIGH_THROUGHPUT pHTInfo)
{
pHTInfo->IOTAction = 0;
pHTInfo->IOTPeer = HT_IOT_PEER_UNKNOWN;
--
2.17.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 4/8] staging: rtl8192e: Correct alignment of if statements - Coding Style
Function HTIOTPeerDetermine used incorrect indentation in if statements. Signed-off-by: John Whitmore --- .../staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c index 65b2cd692ec8..10d9c58680a2 100644 --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c @@ -362,16 +362,16 @@ static void HTIOTPeerDetermine(struct ieee80211_device *ieee) else if (net->broadcom_cap_exist) pHTInfo->IOTPeer = HT_IOT_PEER_BROADCOM; else if ((memcmp(net->bssid, UNKNOWN_BORADCOM, 3) == 0) || - (memcmp(net->bssid, LINKSYSWRT330_LINKSYSWRT300_BROADCOM, 3) == 0) || - (memcmp(net->bssid, LINKSYSWRT350_LINKSYSWRT150_BROADCOM, 3) == 0) || - (memcmp(net->bssid, NETGEAR834Bv2_BROADCOM, 3) == 0)) +(memcmp(net->bssid, LINKSYSWRT330_LINKSYSWRT300_BROADCOM, 3) == 0) || +(memcmp(net->bssid, LINKSYSWRT350_LINKSYSWRT150_BROADCOM, 3) == 0) || +(memcmp(net->bssid, NETGEAR834Bv2_BROADCOM, 3) == 0)) pHTInfo->IOTPeer = HT_IOT_PEER_BROADCOM; else if ((memcmp(net->bssid, BELKINF5D8233V1_RALINK, 3) == 0) || - (memcmp(net->bssid, BELKINF5D82334V3_RALINK, 3) == 0) || - (memcmp(net->bssid, PCI_RALINK, 3) == 0) || - (memcmp(net->bssid, EDIMAX_RALINK, 3) == 0) || - (memcmp(net->bssid, AIRLINK_RALINK, 3) == 0) || -net->ralink_cap_exist) +(memcmp(net->bssid, BELKINF5D82334V3_RALINK, 3) == 0) || +(memcmp(net->bssid, PCI_RALINK, 3) == 0) || +(memcmp(net->bssid, EDIMAX_RALINK, 3) == 0) || +(memcmp(net->bssid, AIRLINK_RALINK, 3) == 0) || +net->ralink_cap_exist) pHTInfo->IOTPeer = HT_IOT_PEER_RALINK; else if (net->atheros_cap_exist) pHTInfo->IOTPeer = HT_IOT_PEER_ATHEROS; -- 2.17.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 8/8] staging: rtl8192e: remove unnecessary parentheses - Coding Style
Remove unneccessary parentheses - Coding Style change
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index 9cca4a8f1cf5..fad740309558 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -529,7 +529,7 @@ void HTConstructCapabilityElement(struct ieee80211_device
*ieee, u8 *posHTCap, u
u8 EWC11NHTCap[] = {0x00, 0x90, 0x4c, 0x33}; // For
11n EWC definition, 2007.07.17, by Emily
memcpy(posHTCap, EWC11NHTCap, sizeof(EWC11NHTCap));
- pCapELE = (PHT_CAPABILITY_ELE)&(posHTCap[4]);
+ pCapELE = (PHT_CAPABILITY_ELE)&posHTCap[4];
} else {
pCapELE = (PHT_CAPABILITY_ELE)posHTCap;
}
@@ -1072,10 +1072,10 @@ void HTInitializeHTInfo(struct ieee80211_device *ieee)
pHTInfo->CurrentAMPDUFactor = pHTInfo->AMPDU_Factor;
// Initialize all of the parameters related to 11n
- memset((void *)(&(pHTInfo->SelfHTCap)), 0, sizeof(pHTInfo->SelfHTCap));
- memset((void *)(&(pHTInfo->SelfHTInfo)), 0,
sizeof(pHTInfo->SelfHTInfo));
- memset((void *)(&(pHTInfo->PeerHTCapBuf)), 0,
sizeof(pHTInfo->PeerHTCapBuf));
- memset((void *)(&(pHTInfo->PeerHTInfoBuf)), 0,
sizeof(pHTInfo->PeerHTInfoBuf));
+ memset((void *)(&pHTInfo->SelfHTCap), 0, sizeof(pHTInfo->SelfHTCap));
+ memset((void *)(&pHTInfo->SelfHTInfo), 0, sizeof(pHTInfo->SelfHTInfo));
+ memset((void *)(&pHTInfo->PeerHTCapBuf), 0,
sizeof(pHTInfo->PeerHTCapBuf));
+ memset((void *)(&pHTInfo->PeerHTInfoBuf), 0,
sizeof(pHTInfo->PeerHTInfoBuf));
pHTInfo->bSwBwInProgress = false;
pHTInfo->ChnlOp = CHNLOP_NONE;
@@ -1091,7 +1091,7 @@ void HTInitializeHTInfo(struct ieee80211_device *ieee)
//MCS rate initialized here
{
- u8 *RegHTSuppRateSets = &(ieee->RegHTSuppRateSet[0]);
+ u8 *RegHTSuppRateSets = &ieee->RegHTSuppRateSet[0];
RegHTSuppRateSets[0] = 0xFF;//support MCS 0~7
RegHTSuppRateSets[1] = 0xFF;//support MCS 8~15
--
2.17.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 5/8] staging: rtl8192e: Remove unrequired space at start of line - Coding Style
Function HTIOTActIsDisableMCS14 contained spurious space at start of line.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index 10d9c58680a2..981433f6c4f2 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -394,7 +394,7 @@ static void HTIOTPeerDetermine(struct ieee80211_device
*ieee)
static u8 HTIOTActIsDisableMCS14(struct ieee80211_device *ieee, u8
*PeerMacAddr)
{
return 0;
- }
+}
/**
* Function:HTIOTActIsDisableMCS15
--
2.17.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
staging: rtl8192e: Series of coding style changes
Version 6 : Sorry to send this out again but version 5 contained a little less verbosity then required. Again these are just some simple coding style changes to the file, so nothing of importance. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 3/8] staging: rtl8192e: Remove unnecessary return statements - Coding style
Return statments from void functions are not required by the coding standard. Signed-off-by: John Whitmore --- drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c index 0db98c77a8e9..65b2cd692ec8 100644 --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c @@ -145,7 +145,6 @@ void HTDebugHTCapability(u8 *CapIE, u8 *TitleString) IEEE80211_DEBUG(IEEE80211_DL_HT, "\tMPDU Density = %d\n", pCapELE->MPDUDensity); IEEE80211_DEBUG(IEEE80211_DL_HT, "\tMCS Rate Set = [%x][%x][%x][%x][%x]\n", pCapELE->MCS[0],\ pCapELE->MCS[1], pCapELE->MCS[2], pCapELE->MCS[3], pCapELE->MCS[4]); - return; } / @@ -207,7 +206,6 @@ void HTDebugHTInfo(u8 *InfoIE, u8 *TitleString) IEEE80211_DEBUG(IEEE80211_DL_HT, "\tBasic MCS Rate Set = [%x][%x][%x][%x][%x]\n", pHTInfoEle->BasicMSC[0],\ pHTInfoEle->BasicMSC[1], pHTInfoEle->BasicMSC[2], pHTInfoEle->BasicMSC[3], pHTInfoEle->BasicMSC[4]); - return; } /* @@ -611,7 +609,6 @@ void HTConstructCapabilityElement(struct ieee80211_device *ieee, u8 *posHTCap, u //Print each field in detail. Driver should not print out this message by default // HTDebugHTCapability(posHTCap, (u8*)"HTConstructCapability()"); - return; } / @@ -661,7 +658,6 @@ void HTConstructInfoElement(struct ieee80211_device *ieee, u8 *posHTInfo, u8 *le } //IEEE80211_DEBUG_DATA(IEEE80211_DL_DATA | IEEE80211_DL_HT, posHTInfo, *len - 2); //HTDebugHTInfo(posHTInfo, "HTConstructInforElement"); - return; } /* -- 2.17.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 2/8] staging: rtl8192e: Addition of prefered spacing - Coding style
Added spaces around various operators, as preferred by coding style.
Signed-off-by: John Whitmore
---
.../rtl8192u/ieee80211/rtl819x_HTProc.c | 22 +--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index 47b6add256d0..0db98c77a8e9 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -264,7 +264,7 @@ u16 HTHalfMcsToDataRate(struct ieee80211_device *ieee,
u8 nMcsRate)
is40MHz = (IsHTHalfNmode40Bandwidth(ieee)) ? 1 : 0;
isShortGI = (IsHTHalfNmodeSGI(ieee, is40MHz)) ? 1 : 0;
- return MCS_DATA_RATE[is40MHz][isShortGI][(nMcsRate&0x7f)];
+ return MCS_DATA_RATE[is40MHz][isShortGI][(nMcsRate & 0x7f)];
}
u16 HTMcsToDataRate(struct ieee80211_device *ieee, u8 nMcsRate)
@@ -275,7 +275,7 @@ u16 HTMcsToDataRate(struct ieee80211_device *ieee, u8
nMcsRate)
u8 isShortGI = (pHTInfo->bCurBW40MHz) ?
((pHTInfo->bCurShortGI40MHz) ?
1 : 0) :
((pHTInfo->bCurShortGI20MHz) ?
1 : 0);
- return MCS_DATA_RATE[is40MHz][isShortGI][(nMcsRate&0x7f)];
+ return MCS_DATA_RATE[is40MHz][isShortGI][(nMcsRate & 0x7f)];
}
/
@@ -317,7 +317,7 @@ u16 TxCountToDataRate(struct ieee80211_device *ieee, u8
nDataRate)
//nDataRate = nDataRate - 60;
}
- return MCS_DATA_RATE[is40MHz][isShortGI][nDataRate&0xf];
+ return MCS_DATA_RATE[is40MHz][isShortGI][nDataRate & 0xf];
}
}
@@ -823,15 +823,15 @@ u8 HTGetHighestMCSRate(struct ieee80211_device *ieee, u8
*pMCSRateSet, u8 *pMCSF
if (availableMcsRate[i] != 0) {
bitMap = availableMcsRate[i];
for (j = 0; j < 8; j++) {
- if ((bitMap%2) != 0) {
- if (HTMcsToDataRate(ieee, (8*i+j)) >
HTMcsToDataRate(ieee, mcsRate))
- mcsRate = (8*i+j);
+ if ((bitMap % 2) != 0) {
+ if (HTMcsToDataRate(ieee, (8 * i + j))
> HTMcsToDataRate(ieee, mcsRate))
+ mcsRate = (8 * i + j);
}
bitMap >>= 1;
}
}
}
- return (mcsRate|0x80);
+ return (mcsRate | 0x80);
}
/*
@@ -850,7 +850,7 @@ static u8 HTFilterMCSRate(struct ieee80211_device *ieee, u8
*pSupportMCS,
// filter out operational rate set not supported by AP, the length of
it is 16
for (i = 0; i <= 15; i++) {
- pOperateMCS[i] =
ieee->Regdot11HTOperationalRateSet[i]&pSupportMCS[i];
+ pOperateMCS[i] = ieee->Regdot11HTOperationalRateSet[i] &
pSupportMCS[i];
}
// TODO: adjust our operational rate set according to our channel
bandwidth, STBC and Antenna number
@@ -909,7 +909,7 @@ void HTOnAssocRsp(struct ieee80211_device *ieee)
// Configurations:
- IEEE80211_DEBUG_DATA(IEEE80211_DL_DATA|IEEE80211_DL_HT, pPeerHTCap,
sizeof(HT_CAPABILITY_ELE));
+ IEEE80211_DEBUG_DATA(IEEE80211_DL_DATA | IEEE80211_DL_HT, pPeerHTCap,
sizeof(HT_CAPABILITY_ELE));
// IEEE80211_DEBUG_DATA(IEEE80211_DL_DATA|IEEE80211_DL_HT, pPeerHTInfo,
sizeof(HT_INFORMATION_ELE));
// Config Supported Channel Width setting
//
@@ -1303,9 +1303,9 @@ void HTSetConnectBwModeCallback(struct ieee80211_device
*ieee)
if (pHTInfo->bCurBW40MHz) {
if (pHTInfo->CurSTAExtChnlOffset == HT_EXTCHNL_OFFSET_UPPER)
- ieee->set_chan(ieee->dev,
ieee->current_network.channel+2);
+ ieee->set_chan(ieee->dev, ieee->current_network.channel
+ 2);
else if (pHTInfo->CurSTAExtChnlOffset ==
HT_EXTCHNL_OFFSET_LOWER)
- ieee->set_chan(ieee->dev,
ieee->current_network.channel-2);
+ ieee->set_chan(ieee->dev, ieee->current_network.channel
- 2);
else
ieee->set_chan(ieee->dev,
ieee->current_network.channel);
--
2.17.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 1/8] staging: rtl8192e: Add and remove blank lines - Coding style
Simple addition & removal of blank lines as required
Signed-off-by: John Whitmore
---
.../rtl8192u/ieee80211/rtl819x_HTProc.c | 64 +--
1 file changed, 16 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index 1b61a8de1edf..47b6add256d0 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -111,9 +111,8 @@ void HTUpdateDefaultSetting(struct ieee80211_device *ieee)
pHTInfo->UsbRxFwAggrPacketNum = 8;
pHTInfo->UsbRxFwAggrTimeout = 16; usb rx FW aggregation timeout
threshold.It's in units of 64us
#endif
-
-
}
+
/
*function: This function print out each field on HT capability IE mainly
from (Beacon/ProbeRsp/AssocReq)
* input: u8* CapIE //Capability IE to be printed out
@@ -124,7 +123,6 @@ void HTUpdateDefaultSetting(struct ieee80211_device *ieee)
*
*/
void HTDebugHTCapability(u8 *CapIE, u8 *TitleString)
{
-
static u8 EWC11NHTCap[] = {0x00, 0x90, 0x4c, 0x33}; // For
11n EWC definition, 2007.07.17, by Emily
PHT_CAPABILITY_ELE pCapELE;
@@ -148,8 +146,8 @@ void HTDebugHTCapability(u8 *CapIE, u8 *TitleString)
IEEE80211_DEBUG(IEEE80211_DL_HT, "\tMCS Rate Set =
[%x][%x][%x][%x][%x]\n", pCapELE->MCS[0],\
pCapELE->MCS[1], pCapELE->MCS[2],
pCapELE->MCS[3], pCapELE->MCS[4]);
return;
-
}
+
/
*function: This function print out each field on HT Information IE mainly
from (Beacon/ProbeRsp)
* input: u8* InfoIE //Capability IE to be printed out
@@ -160,7 +158,6 @@ void HTDebugHTCapability(u8 *CapIE, u8 *TitleString)
*
*/
void HTDebugHTInfo(u8 *InfoIE, u8 *TitleString)
{
-
static u8 EWC11NHTInfo[] = {0x00, 0x90, 0x4c, 0x34}; // For
11n EWC definition, 2007.07.17, by Emily
PHT_INFORMATION_ELE pHTInfoEle;
@@ -261,7 +258,6 @@ static bool IsHTHalfNmodeSGI(struct ieee80211_device *ieee,
bool is40MHz)
u16 HTHalfMcsToDataRate(struct ieee80211_device *ieee, u8 nMcsRate)
{
-
u8 is40MHz;
u8 isShortGI;
@@ -271,7 +267,6 @@ u16 HTHalfMcsToDataRate(struct ieee80211_device *ieee,
u8 nMcsRate)
return MCS_DATA_RATE[is40MHz][isShortGI][(nMcsRate&0x7f)];
}
-
u16 HTMcsToDataRate(struct ieee80211_device *ieee, u8 nMcsRate)
{
PRT_HIGH_THROUGHPUT pHTInfo = ieee->pHTInfo;
@@ -326,12 +321,11 @@ u16 TxCountToDataRate(struct ieee80211_device *ieee, u8
nDataRate)
}
}
-
-
bool IsHTHalfNmodeAPs(struct ieee80211_device *ieee)
{
boolretValue = false;
struct ieee80211_network *net = &ieee->current_network;
+
if ((memcmp(net->bssid, BELKINF5D8233V1_RALINK, 3) == 0) ||
(memcmp(net->bssid, BELKINF5D82334V3_RALINK, 3) == 0) ||
(memcmp(net->bssid, PCI_RALINK, 3) == 0) ||
@@ -364,6 +358,7 @@ static void HTIOTPeerDetermine(struct ieee80211_device
*ieee)
{
PRT_HIGH_THROUGHPUT pHTInfo = ieee->pHTInfo;
struct ieee80211_network *net = &ieee->current_network;
+
if (net->bssht.bdRT2RTAggregation)
pHTInfo->IOTPeer = HT_IOT_PEER_REALTEK;
else if (net->broadcom_cap_exist)
@@ -389,6 +384,7 @@ static void HTIOTPeerDetermine(struct ieee80211_device
*ieee)
IEEE80211_DEBUG(IEEE80211_DL_IOT, "Joseph debug!! IOTPEER: %x\n",
pHTInfo->IOTPeer);
}
+
/
*function: Check whether driver should declare received rate up to MCS13
only since some chipset is not good
* at receiving MCS14~15 frame from some AP.
@@ -402,7 +398,6 @@ static u8 HTIOTActIsDisableMCS14(struct ieee80211_device
*ieee, u8 *PeerMacAddr)
return 0;
}
-
/**
* Function:HTIOTActIsDisableMCS15
*
@@ -496,6 +491,7 @@ static u8 HTIOTActIsMgntUseCCK6M(struct ieee80211_network
*network)
static u8 HTIOTActIsCCDFsync(u8 *PeerMacAddr)
{
u8 retValue = 0;
+
if ((memcmp(PeerMacAddr, UNKNOWN_BORADCOM, 3) == 0) ||
(memcmp(PeerMacAddr, LINKSYSWRT330_LINKSYSWRT300_BROADCOM, 3) == 0)
||
(memcmp(PeerMacAddr, LINKSYSWRT350_LINKSYSWRT150_BROADCOM, 3) == 0))
@@ -512,7 +508,6 @@ void HTResetIOTSetting(
pHTInfo->IOTPeer = HT_IOT_PEER_UNKNOWN;
}
-
/
Re: [PATCH v5 8/8] staging: rtl8192e: remove unnecessary parentheses - Coding Style
On Wed, Jun 06, 2018 at 11:25:14AM +0100, John Whitmore wrote: > On Sun, Jun 03, 2018 at 02:28:35PM +0200, Greg KH wrote: > > On Sun, Jun 03, 2018 at 01:04:13PM +0100, John Whitmore wrote: > > > Signed-off-by: John Whitmore > > > --- > > > drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 12 ++-- > > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > I can not take patches without any changelog text at all :( > > Sorry I created a one line commit message, which became the subject of the > patch email. I couldn't think of anything more to add for a second line. My > mistake. I did an ammend of that, as it was the last commit, to add a second > line. > > Now I'm probably going to get this next bit wrong. Can I simply bump the > version of patch 8/8 to v6 and resend that single patch file, or bump all 8 > patches to v6 and resend all of them? I'll bump the last patch file and attach > it to this email, hope for the best. I can't take attachments, sorry. Try resending the whole series, as a new version (v6), and all should be fine. Note that I can't do anything with patches until the merge window closes, in 2 weeks, so don't expect a response until then. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 8/8] staging: rtl8192e: remove unnecessary parentheses - Coding Style
On Sun, Jun 03, 2018 at 02:28:35PM +0200, Greg KH wrote:
> On Sun, Jun 03, 2018 at 01:04:13PM +0100, John Whitmore wrote:
> > Signed-off-by: John Whitmore
> > ---
> > drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
>
> I can not take patches without any changelog text at all :(
Sorry I created a one line commit message, which became the subject of the
patch email. I couldn't think of anything more to add for a second line. My
mistake. I did an ammend of that, as it was the last commit, to add a second
line.
Now I'm probably going to get this next bit wrong. Can I simply bump the
version of patch 8/8 to v6 and resend that single patch file, or bump all 8
patches to v6 and resend all of them? I'll bump the last patch file and attach
it to this email, hope for the best.
>From 4d01cfb7d18e507b163a25a69938f323cd61e9fe Mon Sep 17 00:00:00 2001
From: John Whitmore
Date: Sun, 3 Jun 2018 12:54:22 +0100
Subject: [PATCH v6 8/8] staging: rtl8192e: remove unnecessary parentheses -
Coding Style
Remove unneccessary parentheses - Coding Style change
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index 9cca4a8f1cf5..fad740309558 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -529,7 +529,7 @@ void HTConstructCapabilityElement(struct ieee80211_device *ieee, u8 *posHTCap, u
u8 EWC11NHTCap[] = {0x00, 0x90, 0x4c, 0x33}; // For 11n EWC definition, 2007.07.17, by Emily
memcpy(posHTCap, EWC11NHTCap, sizeof(EWC11NHTCap));
- pCapELE = (PHT_CAPABILITY_ELE)&(posHTCap[4]);
+ pCapELE = (PHT_CAPABILITY_ELE)&posHTCap[4];
} else {
pCapELE = (PHT_CAPABILITY_ELE)posHTCap;
}
@@ -1072,10 +1072,10 @@ void HTInitializeHTInfo(struct ieee80211_device *ieee)
pHTInfo->CurrentAMPDUFactor = pHTInfo->AMPDU_Factor;
// Initialize all of the parameters related to 11n
- memset((void *)(&(pHTInfo->SelfHTCap)), 0, sizeof(pHTInfo->SelfHTCap));
- memset((void *)(&(pHTInfo->SelfHTInfo)), 0, sizeof(pHTInfo->SelfHTInfo));
- memset((void *)(&(pHTInfo->PeerHTCapBuf)), 0, sizeof(pHTInfo->PeerHTCapBuf));
- memset((void *)(&(pHTInfo->PeerHTInfoBuf)), 0, sizeof(pHTInfo->PeerHTInfoBuf));
+ memset((void *)(&pHTInfo->SelfHTCap), 0, sizeof(pHTInfo->SelfHTCap));
+ memset((void *)(&pHTInfo->SelfHTInfo), 0, sizeof(pHTInfo->SelfHTInfo));
+ memset((void *)(&pHTInfo->PeerHTCapBuf), 0, sizeof(pHTInfo->PeerHTCapBuf));
+ memset((void *)(&pHTInfo->PeerHTInfoBuf), 0, sizeof(pHTInfo->PeerHTInfoBuf));
pHTInfo->bSwBwInProgress = false;
pHTInfo->ChnlOp = CHNLOP_NONE;
@@ -1091,7 +1091,7 @@ void HTInitializeHTInfo(struct ieee80211_device *ieee)
//MCS rate initialized here
{
- u8 *RegHTSuppRateSets = &(ieee->RegHTSuppRateSet[0]);
+ u8 *RegHTSuppRateSets = &ieee->RegHTSuppRateSet[0];
RegHTSuppRateSets[0] = 0xFF; //support MCS 0~7
RegHTSuppRateSets[1] = 0xFF; //support MCS 8~15
--
2.17.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] HV: Fix definition of struct hv_vp_assist_page.
On Mon, 21 May 2018, Tianyu Lan wrote:
KY
> The struct hv_vp_assist_page was defined incorrectly.
> The "vtl_control" should be u64[3], "nested_enlightenments_control"
> should be a u64 and there is 7 reserved bytes following "enlighten_vmentry".
> This patch is to fix it.
>
> Signed-off-by: Lan Tianyu
> ---
> arch/x86/include/asm/hyperv-tlfs.h | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/hyperv-tlfs.h
> b/arch/x86/include/asm/hyperv-tlfs.h
> index f7be6d03a310..fae0a5431cdd 100644
> --- a/arch/x86/include/asm/hyperv-tlfs.h
> +++ b/arch/x86/include/asm/hyperv-tlfs.h
> @@ -496,10 +496,11 @@ struct hv_timer_message_payload {
> /* Define virtual processor assist page structure. */
> struct hv_vp_assist_page {
> __u32 apic_assist;
> - __u32 reserved;
> - __u64 vtl_control[2];
> - __u64 nested_enlightenments_control[2];
> - __u32 enlighten_vmentry;
> + __u32 reserved1;
> + __u64 vtl_control[3];
> + __u64 nested_enlightenments_control;
> + __u8 enlighten_vmentry;
> + __u8 reserved2[7];
> __u64 current_nested_vmcs;
> };
>
> --
> 2.14.3
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_netvsc: add per-cpu ethtool stats for netvsc
On Tue, Jun 05, 2018 at 08:14:06PM +, Yidong Ren wrote: > This patch implements following ethtool stats fields for netvsc: > cpu_rx_packets > cpu_tx_packets > cpu_rx_bytes > cpu_tx_bytes > cpu_vf_rx_packets > cpu_vf_tx_packets > cpu_vf_rx_bytes > cpu_vf_tx_bytes > --- No signed-off-by line? Always use scripts/checkpatch.pl on your patches os you do not get grumpy kernel maintainers telling you to run checkpatch.pl on your patches... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH][next] staging: vc04_services: make a couple of pointers static
From: Colin Ian King
The pointers vchiq_dbg_dir and vchiq_dbg_clients are local to the
source and do not need to be in global scope, so make them static.
Cleans up sparse warnings:
warning: symbol 'vchiq_dbg_dir' was not declared. Should it be static?
warning: symbol 'vchiq_dbg_clients' was not declared. Should it be static?
Signed-off-by: Colin Ian King
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
index 38805504d462..6a9e71a61142 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
@@ -52,8 +52,8 @@
#define VCHIQ_LOG_TRACE_STR "trace"
/* Global 'vchiq' debugfs and clients entry used by all instances */
-struct dentry *vchiq_dbg_dir;
-struct dentry *vchiq_dbg_clients;
+static struct dentry *vchiq_dbg_dir;
+static struct dentry *vchiq_dbg_clients;
/* Log category debugfs entries */
struct vchiq_debugfs_log_entry {
--
2.17.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
