* Re: [PATCH] Bluetooth: hidp: Fix assumptions on the return value of hidp_send_message
From: Jiri Kosina @ 2019-09-06 11:31 UTC (permalink / raw)
To: Dan Elkouby
Cc: Dan Carpenter, Benjamin Tissoires, Marcel Holtmann, Johan Hedberg,
David S. Miller, Brian Norris, Fabian Henneke, Al Viro,
Andrea Parri, linux-input, linux-kernel, linux-bluetooth, netdev
In-Reply-To: <20190906110645.27601-1-streetwalkermc@gmail.com>
On Fri, 6 Sep 2019, Dan Elkouby wrote:
> hidp_send_message was changed to return non-zero values on success,
> which some other bits did not expect. This caused spurious errors to be
> propagated through the stack, breaking some drivers, such as hid-sony
> for the Dualshock 4 in Bluetooth mode.
>
> As pointed out by Dan Carpenter, hid-microsoft directly relied on that
> assumption as well.
>
> Fixes: 48d9cc9d85dd ("Bluetooth: hidp: Let hidp_send_message return number of queued bytes")
>
> Signed-off-by: Dan Elkouby <streetwalkermc@gmail.com>
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Marcel, are you taking this through your tree?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] net/ixgbevf: make array api static const, makes object smaller
From: Colin King @ 2019-09-06 11:33 UTC (permalink / raw)
To: gJeff Kirsher, David S . Miller, intel-wired-lan, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the array api on the stack but instead make it
static const. Makes the object code smaller by 58 bytes.
Before:
text data bss dec hex filename
82969 9763 256 92988 16b3c ixgbevf/ixgbevf_main.o
After:
text data bss dec hex filename
82815 9859 256 92930 16b02 ixgbevf/ixgbevf_main.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 8c011d4ce7a9..46c8e2501084 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -2261,12 +2261,14 @@ static void ixgbevf_init_last_counter_stats(struct ixgbevf_adapter *adapter)
static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
- int api[] = { ixgbe_mbox_api_14,
- ixgbe_mbox_api_13,
- ixgbe_mbox_api_12,
- ixgbe_mbox_api_11,
- ixgbe_mbox_api_10,
- ixgbe_mbox_api_unknown };
+ static const int api[] = {
+ ixgbe_mbox_api_14,
+ ixgbe_mbox_api_13,
+ ixgbe_mbox_api_12,
+ ixgbe_mbox_api_11,
+ ixgbe_mbox_api_10,
+ ixgbe_mbox_api_unknown
+ };
int err, idx = 0;
spin_lock_bh(&adapter->mbx_lock);
--
2.20.1
^ permalink raw reply related
* [PATCH] net/mlx4_en: ethtool: make array modes static const, makes object smaller
From: Colin King @ 2019-09-06 11:53 UTC (permalink / raw)
To: Tariq Toukan, David S . Miller, netdev, linux-rdma
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the array modes on the stack but instead make it
static const. Makes the object code smaller by 303 bytes.
Before:
text data bss dec hex filename
51240 5008 1312 57560 e0d8 mellanox/mlx4/en_ethtool.o
After:
text data bss dec hex filename
50937 5008 1312 57257 dfa9 mellanox/mlx4/en_ethtool.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index 94c59939a8cf..d8313e2ee600 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -639,7 +639,7 @@ static unsigned long *ptys2ethtool_link_mode(struct ptys2ethtool_config *cfg,
#define MLX4_BUILD_PTYS2ETHTOOL_CONFIG(reg_, speed_, ...) \
({ \
struct ptys2ethtool_config *cfg; \
- const unsigned int modes[] = { __VA_ARGS__ }; \
+ static const unsigned int modes[] = { __VA_ARGS__ }; \
unsigned int i; \
cfg = &ptys2ethtool_map[reg_]; \
cfg->speed = speed_; \
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: hidp: Fix error checks in hidp_get/set_raw_report
From: Dan Carpenter @ 2019-09-06 10:58 UTC (permalink / raw)
To: Dan Elkouby
Cc: Marcel Holtmann, Johan Hedberg, David S. Miller, Fabian Henneke,
Brian Norris, Al Viro, Andrea Parri, linux-bluetooth, netdev,
linux-kernel
In-Reply-To: <CANnEQ3HX0SNG+Hzs2b+BzLwuewsC8-3sF2urWV+bqUahXq0hVA@mail.gmail.com>
On Fri, Sep 06, 2019 at 01:40:15PM +0300, Dan Elkouby wrote:
> On Fri, Sep 6, 2019 at 1:14 PM Dan Carpenter wrote:
> > I think we also need to update update ms_ff_worker() which assumes that
> > hid_hw_output_report() returns zero on success.
>
> Yes, it looks like that's the case. Should I amend my patch to include
> this fix, or should it be a separate patch? I don't have access to any
> hardware covered by hid-microsoft, so I won't be able to test it.
>
Yes. Please amend the patch. We all understand that you don't have
the hardware so it's not a problem. If you want to blame me in the
commit message that's fine. "Dan Carpenter pointed out a related issue
in ms_ff_worker()". But we're only silencing a warning so it can't
really break anything.
You can add my Reviewed-by tag as well when you resend.
regards,
dan carpenter
^ permalink raw reply
* RE: [RFC PATCH 3/3] Enable ptp_kvm for arm64
From: Jianyong Wu (Arm Technology China) @ 2019-09-06 11:58 UTC (permalink / raw)
To: Marc Zyngier, netdev@vger.kernel.org, pbonzini@redhat.com,
sean.j.christopherson@intel.com, richardcochran@gmail.com,
Mark Rutland, Will Deacon, Suzuki Poulose
Cc: linux-kernel@vger.kernel.org, Steve Capper,
Kaly Xin (Arm Technology China), Justin He (Arm Technology China)
In-Reply-To: <4d04867c-2188-9574-fbd1-2356c6b99b7d@kernel.org>
Hi Marc,
Very sorry to have missed this comments.
> -----Original Message-----
> From: Marc Zyngier <maz@kernel.org>
> Sent: Thursday, August 29, 2019 6:33 PM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>;
> netdev@vger.kernel.org; pbonzini@redhat.com;
> sean.j.christopherson@intel.com; richardcochran@gmail.com; Mark Rutland
> <Mark.Rutland@arm.com>; Will Deacon <Will.Deacon@arm.com>; Suzuki
> Poulose <Suzuki.Poulose@arm.com>
> Cc: linux-kernel@vger.kernel.org; Steve Capper <Steve.Capper@arm.com>;
> Kaly Xin (Arm Technology China) <Kaly.Xin@arm.com>; Justin He (Arm
> Technology China) <Justin.He@arm.com>
> Subject: Re: [RFC PATCH 3/3] Enable ptp_kvm for arm64
>
> On 29/08/2019 07:39, Jianyong Wu wrote:
> > Currently in arm64 virtualization environment, there is no mechanism
> > to keep time sync between guest and host. Time in guest will drift
> > compared with host after boot up as they may both use third party time
> > sources to correct their time respectively. The time deviation will be
> > in order of milliseconds but some scenarios ask for higher time
> > precision, like in cloud envirenment, we want all the VMs running in
> > the host aquire the same level accuracy from host clock.
> >
> > Use of kvm ptp clock, which choose the host clock source clock as a
> > reference clock to sync time clock between guest and host has been
> > adopted by x86 which makes the time sync order from milliseconds to
> nanoseconds.
> >
> > This patch enable kvm ptp on arm64 and we get the similar clock drift
> > as found with x86 with kvm ptp.
> >
> > Test result comparison between with kvm ptp and without it in arm64
> > are as follows. This test derived from the result of command 'chronyc
> > sources'. we should take more cure of the last sample column which
> > shows the offset between the local clock and the source at the last
> measurement.
> >
> > no kvm ptp in guest:
> > MS Name/IP address Stratum Poll Reach LastRx Last sample
> >
> ==========================================================
> ==============
> > ^* dns1.synet.edu.cn 2 6 377 13 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 21 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 29 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 37 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 45 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 53 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 61 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 4 -130us[ +796us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 12 -130us[ +796us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 20 -130us[ +796us] +/- 21ms
> >
> > in host:
> > MS Name/IP address Stratum Poll Reach LastRx Last sample
> >
> ==========================================================
> ==============
> > ^* 120.25.115.20 2 7 377 72 -470us[ -603us] +/- 18ms
> > ^* 120.25.115.20 2 7 377 92 -470us[ -603us] +/- 18ms
> > ^* 120.25.115.20 2 7 377 112 -470us[ -603us] +/- 18ms
> > ^* 120.25.115.20 2 7 377 2 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 22 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 43 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 63 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 83 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 103 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 123 +872ns[-6808ns] +/- 17ms
> >
> > The dns1.synet.edu.cn is the network reference clock for guest and
> > 120.25.115.20 is the network reference clock for host. we can't get
> > the clock error between guest and host directly, but a roughly
> > estimated value will be in order of hundreds of us to ms.
> >
> > with kvm ptp in guest:
> > chrony has been disabled in host to remove the disturb by network clock.
>
> Is that a realistic use case? Why should the host not use NTP?
>
Not really, NTP will change the the host clock which will contaminate the data of sync between
Host and guest. But in reality, we will keep NTP online.
> >
> > MS Name/IP address Stratum Poll Reach LastRx Last sample
> >
> ==========================================================
> ==============
> > * PHC0 0 3 377 8 -7ns[ +1ns] +/- 3ns
> > * PHC0 0 3 377 8 +1ns[ +16ns] +/- 3ns
> > * PHC0 0 3 377 6 -4ns[ -0ns] +/- 6ns
> > * PHC0 0 3 377 6 -8ns[ -12ns] +/- 5ns
> > * PHC0 0 3 377 5 +2ns[ +4ns] +/- 4ns
> > * PHC0 0 3 377 13 +2ns[ +4ns] +/- 4ns
> > * PHC0 0 3 377 12 -4ns[ -6ns] +/- 4ns
> > * PHC0 0 3 377 11 -8ns[ -11ns] +/- 6ns
> > * PHC0 0 3 377 10 -14ns[ -20ns] +/- 4ns
> > * PHC0 0 3 377 8 +4ns[ +5ns] +/- 4ns
> >
> > The PHC0 is the ptp clock which choose the host clock as its source
> > clock. So we can be sure to say that the clock error between host and
> > guest is in order of ns.
> >
> > Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> > ---
> > arch/arm64/include/asm/arch_timer.h | 3 ++
> > arch/arm64/kvm/arch_ptp_kvm.c | 76
> ++++++++++++++++++++++++++++
> > drivers/clocksource/arm_arch_timer.c | 6 ++-
> > drivers/ptp/Kconfig | 2 +-
> > include/linux/arm-smccc.h | 14 +++++
> > virt/kvm/arm/psci.c | 17 +++++++
> > 6 files changed, 115 insertions(+), 3 deletions(-) create mode
> > 100644 arch/arm64/kvm/arch_ptp_kvm.c
>
> Please split this patch into two parts: the hypervisor code in a patch and the
> guest code in another patch. Having both of them together is confusing.
>
Ok, really better.
> >
> > diff --git a/arch/arm64/include/asm/arch_timer.h
> > b/arch/arm64/include/asm/arch_timer.h
> > index 6756178c27db..880576a814b6 100644
> > --- a/arch/arm64/include/asm/arch_timer.h
> > +++ b/arch/arm64/include/asm/arch_timer.h
> > @@ -229,4 +229,7 @@ static inline int arch_timer_arch_init(void)
> > return 0;
> > }
> >
> > +extern struct clocksource clocksource_counter; extern u64
> > +arch_counter_read(struct clocksource *cs);
>
> I'm definitely not keen on exposing the internals of the arch_timer driver to
> random subsystems. Furthermore, you seem to expect that the guest kernel
> will only use the arch timer as a clocksource, and nothing really guarantees
> that (in which case get_device_system_crosststamp will fail).
>
The code here is really ugly, I need a better solution to offer a clock source
For the guest.
> It looks to me that we'd be better off exposing a core timekeeping API that
> populates a struct system_counterval_t based on the *current* timekeeper
> monotonic clocksource. This would simplify the split between generic and
> arch-specific code.
>
I think it really necessary.
> Whether or not tglx will be happy with the idea is another problem, but I'm
> certainly not taking any change to the arch timer code based on this.
>
I can have a try, but the detail is not clear for me now.
> > +
> > #endif
> > diff --git a/arch/arm64/kvm/arch_ptp_kvm.c
> > b/arch/arm64/kvm/arch_ptp_kvm.c
>
> We don't put non-hypervisor in arch/arm64/kvm. Please move it back to
> drivers/ptp (as well as its x86 counterpart), and just link the two parts there.
> This should also allow this to be enabled for 32bit guests.
>
Err, sorry, what's mean of "link the two parts there"? should I add another two file update driver/ptp/
Both for arm64 and x86 to contains these arch-specific code or pack them all into ptp_kvm.c?
> > new file mode 100644
> > index 000000000000..6b2165ebce62
> > --- /dev/null
> > +++ b/arch/arm64/kvm/arch_ptp_kvm.c
> > @@ -0,0 +1,76 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Virtual PTP 1588 clock for use with KVM guests
> > + * Copyright (C) 2019 ARM Ltd.
> > + * All Rights Reserved
> > + */
> > +
> > +#include <asm/hypervisor.h>
> > +#include <linux/module.h>
> > +#include <linux/psci.h>
> > +#include <linux/arm-smccc.h>
> > +#include <linux/timecounter.h>
> > +#include <linux/sched/clock.h>
> > +#include <asm/arch_timer.h>
> > +
> > +/*
> > + * as trap call cause delay, this function will return the delay in
> > +nanosecond */ static u64 arm_smccc_1_1_invoke_delay(u32 id, struct
> > +arm_smccc_res *res) {
> > + u64 ns, t1, t2;
> > +
> > + t1 = sched_clock();
> > + arm_smccc_1_1_invoke(id, res);
> > + t2 = sched_clock();
> > + t2 -= t1;
> > + ns = t2;
> > + return ns;
>
> I think you can get rid of the ns variable here...
Yeah, ns is really redundant.
>
> > +}
> > +
> > +int kvm_arch_ptp_init(void)
> > +{
> > + return 0;
> > +}
> > +
> > +int kvm_arch_ptp_get_clock(struct timespec64 *ts) {
> > + u64 ns;
> > + struct arm_smccc_res hvc_res;
> > +
> > + if (!kvm_arm_hyp_service_available(
> > + ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID)) {
> > + return -EOPNOTSUPP;
> > + }
> > + ns =
> arm_smccc_1_1_invoke_delay(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FU
> NC_ID,
> > + &hvc_res);
> > + ts->tv_sec = hvc_res.a0;
> > + ts->tv_nsec = hvc_res.a1;
> > + timespec64_add_ns(ts, ns);
> > + return 0;
> > +}
> > +
> > +int kvm_arch_ptp_get_clock_fn(long *cycle, struct timespec64 *ts,
> > + struct clocksource **cs)
> > +{
> > + u64 ns;
> > + struct arm_smccc_res hvc_res;
> > +
> > + if (!kvm_arm_hyp_service_available(
> > + ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID)) {
> > + return -EOPNOTSUPP;
> > + }
> > + ns =
> arm_smccc_1_1_invoke_delay(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FU
> NC_ID,
> > + &hvc_res);
> > + ts->tv_sec = hvc_res.a0;
> > + ts->tv_nsec = hvc_res.a1;
> > + timespec64_add_ns(ts, ns);
> > + *cycle = hvc_res.a2;
> > + *cs = &clocksource_counter;
> > +
> > + return 0;
> > +}
>
> Why do we have two functions doing almost the same thing? Why do you call
> kvm_arm_hyp_service_available on each and every time? Isn't it enough to
> check in kvm_arch_ptp_init()?
>
Yeah, it's better.
> > +
> > +MODULE_AUTHOR("Marcelo Tosatti <mtosatti@redhat.com>");
> > +MODULE_DESCRIPTION("PTP clock using KVMCLOCK");
> > +MODULE_LICENSE("GPL");
>
> This should only exist in the generic code.
Ok. I will remove them.
>
> > diff --git a/drivers/clocksource/arm_arch_timer.c
> > b/drivers/clocksource/arm_arch_timer.c
> > index 07e57a49d1e8..021e3f69364c 100644
> > --- a/drivers/clocksource/arm_arch_timer.c
> > +++ b/drivers/clocksource/arm_arch_timer.c
> > @@ -175,23 +175,25 @@ static notrace u64 arch_counter_get_cntvct(void)
> > u64 (*arch_timer_read_counter)(void) = arch_counter_get_cntvct;
> > EXPORT_SYMBOL_GPL(arch_timer_read_counter);
> >
> > -static u64 arch_counter_read(struct clocksource *cs)
> > +u64 arch_counter_read(struct clocksource *cs)
> > {
> > return arch_timer_read_counter();
> > }
> > +EXPORT_SYMBOL(arch_counter_read);
> >
> > static u64 arch_counter_read_cc(const struct cyclecounter *cc) {
> > return arch_timer_read_counter();
> > }
> >
> > -static struct clocksource clocksource_counter = {
> > +struct clocksource clocksource_counter = {
> > .name = "arch_sys_counter",
> > .rating = 400,
> > .read = arch_counter_read,
> > .mask = CLOCKSOURCE_MASK(56),
> > .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> > };
> > +EXPORT_SYMBOL(clocksource_counter);
>
> I've said what I thought about this. Not happening.
>
Ok.
> >
> > static struct cyclecounter cyclecounter __ro_after_init = {
> > .read = arch_counter_read_cc,
> > diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index
> > 9b8fee5178e8..e032fafdafa7 100644
> > --- a/drivers/ptp/Kconfig
> > +++ b/drivers/ptp/Kconfig
> > @@ -110,7 +110,7 @@ config PTP_1588_CLOCK_PCH config
> > PTP_1588_CLOCK_KVM
> > tristate "KVM virtual PTP clock"
> > depends on PTP_1588_CLOCK
> > - depends on KVM_GUEST && X86
> > + depends on KVM_GUEST && X86 || ARM64
> > default y
> > help
> > This driver adds support for using kvm infrastructure as a PTP
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index a6e4d3e3d10a..2a222a1a8594 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -94,6 +94,7 @@
> >
> > /* KVM "vendor specific" services */
> > #define ARM_SMCCC_KVM_FUNC_FEATURES 0
> > +#define ARM_SMCCC_KVM_PTP 1
> > #define ARM_SMCCC_KVM_FUNC_FEATURES_2 127
> > #define ARM_SMCCC_KVM_NUM_FUNCS 128
> >
> > @@ -102,6 +103,16 @@
> > ARM_SMCCC_SMC_32,
> \
> > ARM_SMCCC_OWNER_VENDOR_HYP,
> \
> > ARM_SMCCC_KVM_FUNC_FEATURES)
> > +/*
> > + * This ID used for virtual ptp kvm clock and it will pass second
> > +value
> > + * and nanosecond value of host real time and system counter by vcpu
> > + * register to guest.
> > + */
> > +#define ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID
> \
> > + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,
> \
> > + ARM_SMCCC_SMC_32,
> \
> > + ARM_SMCCC_OWNER_VENDOR_HYP,
> \
> > + ARM_SMCCC_KVM_PTP)
> >
> > #ifndef __ASSEMBLY__
> >
> > @@ -373,5 +384,8 @@ asmlinkage void __arm_smccc_hvc(unsigned long
> a0, unsigned long a1,
> > method;
> \
> > })
> >
> > +#include <linux/psci.h>
> > +#include <linux/clocksource.h>
> > +
> > #endif /*__ASSEMBLY__*/
> > #endif /*__LINUX_ARM_SMCCC_H*/
> > diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c index
> > 0debf49bf259..7fffdb25d32c 100644
> > --- a/virt/kvm/arm/psci.c
> > +++ b/virt/kvm/arm/psci.c
> > @@ -392,6 +392,8 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > u32 func_id = smccc_get_function(vcpu);
> > u32 val[4] = {};
> > u32 option;
> > + struct timespec *ts;
> > + u64 cnt;
> >
> > val[0] = SMCCC_RET_NOT_SUPPORTED;
> >
> > @@ -431,6 +433,21 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > break;
> > + /*
> > + * This will used for virtual ptp kvm clock. three
> > + * values will be passed back.
> > + * reg0 stores seconds of host real time;
> > + * reg1 stores nanoseconds of host real time;
> > + * reg2 stotes system counter cycle value.
>
> stores
Yeah
>
> > + */
> > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > + getnstimeofday(ts);
> > + cnt = arch_timer_read_counter();
> > + val[0] = ts->tv_sec;
> > + val[1] = ts->tv_nsec;
> > + val[2] = cnt;
>
> Can you explain what the purpose of exposing this counter is? The guest
> should have access to the physical counter already.
One api of ptp_kvm called ptp_kvm_get_time_fn need a clock sources passed from host as system_counter.
>
> > + val[3] = 0;
> > + break;
>
> This will probably conflict with Steven's stolen time series. Not a big deal
> though.
Err, sorry I am not familiar with this theory. Let me check it.
>
> > default:
> > return kvm_psci_call(vcpu);
> > }
> >
>
> Other questions: how does this works with VM migration? Specially when
> moving from a hypervisor that supports the feature to one that doesn't?
>
I think it won't solve the problem generated by VM migration and only for VMs in a single machine.
Ptp_kvm only works for VMs in the same machine.
But using ptp (not ptp_kvm) clock, all the machines in a low latency network environment can keep time sync in high precision,
Then VMs move from one machine to another will obtain a high precision time sync.
Thanks
Jianyong Wu
> Thanks,
>
> M.
> --
> Jazz is not dead, it just smells funny...
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH] mt76: mt76x0e: make array mt76x0_chan_map static const, makes object smaller
From: Colin King @ 2019-09-06 12:19 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo, Kalle Valo,
David S . Miller, Matthias Brugger, linux-wireless, netdev,
linux-arm-kernel, linux-mediatek
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the array mt76x0_chan_map on the stack but instead make it
static const. Makes the object code smaller by 80 bytes.
Before:
text data bss dec hex filename
7685 1192 0 8877 22ad mediatek/mt76/mt76x0/eeprom.o
After:
text data bss dec hex filename
7541 1256 0 8797 225d mediatek/mt76/mt76x0/eeprom.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
index 9d4426f6905f..96368fac4228 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
@@ -212,7 +212,7 @@ void mt76x0_get_tx_power_per_rate(struct mt76x02_dev *dev,
void mt76x0_get_power_info(struct mt76x02_dev *dev,
struct ieee80211_channel *chan, s8 *tp)
{
- struct mt76x0_chan_map {
+ static const struct mt76x0_chan_map {
u8 chan;
u8 offset;
} chan_map[] = {
--
2.20.1
^ permalink raw reply related
* Apply@ 5% Fixed Interest Rate,no Cre-dit Review,From R20,000.00 to R30million*
From: RCS Finance @ 2019-09-06 12:29 UTC (permalink / raw)
To: netdev
[-- Attachment #1.1: Type: text/plain, Size: 497 bytes --]
To Whom It May Concern:
Kindly find attached for more info on our 5% Fixed Interest Rate.
*NOTE that our current calculated 5% interest rate is our on-going promotional interest rate and has been extended to the End of Sept 2019.
Don't miss this opportunity as we look forward to welcoming you to the RCS FAMILY.
PLEASE NOTE: This is an automated email message, please do NOT reply to the sender ***
*Kindly direct all required details to : info@rcsgroupsa.com
Sincerely,
RCS GROUP
[-- Attachment #1.2: Type: text/html, Size: 1238 bytes --]
[-- Attachment #2: RCS_FINANCE SA.pdf --]
[-- Type: application/octet-stream, Size: 148257 bytes --]
^ permalink raw reply
* [PATCH] net: stmmac: socfpga: re-use the `interface` parameter from platform data
From: Alexandru Ardelean @ 2019-09-06 12:30 UTC (permalink / raw)
To: netdev, linux-stm32, linux-arm-kernel, linux-kernel
Cc: peppe.cavallaro, alexandre.torgue, joabreu, mcoquelin.stm32,
davem, Alexandru Ardelean
The socfpga sub-driver defines an `interface` field in the `socfpga_dwmac`
struct and parses it on init.
The shared `stmmac_probe_config_dt()` function also parses this from the
device-tree and makes it available on the returned `plat_data` (which is
the same data available via `netdev_priv()`).
All that's needed now is to dig that information out, via some
`dev_get_drvdata()` && `netdev_priv()` calls and re-use it.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index c141fe783e87..3094bb1f77e5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -46,7 +46,6 @@ struct socfpga_dwmac_ops {
};
struct socfpga_dwmac {
- int interface;
u32 reg_offset;
u32 reg_shift;
struct device *dev;
@@ -110,8 +109,6 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
struct resource res_tse_pcs;
struct resource res_sgmii_adapter;
- dwmac->interface = of_get_phy_mode(np);
-
sys_mgr_base_addr =
altr_sysmgr_regmap_lookup_by_phandle(np, "altr,sysmgr-syscon");
if (IS_ERR(sys_mgr_base_addr)) {
@@ -231,8 +228,12 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
return ret;
}
-static int socfpga_set_phy_mode_common(int phymode, u32 *val)
+static int socfpga_set_phy_mode_common(struct socfpga_dwmac *dwmac, u32 *val)
{
+ struct net_device *ndev = dev_get_drvdata(dwmac->dev);
+ struct stmmac_priv *priv = netdev_priv(ndev);
+ int phymode = priv->plat->interface;
+
switch (phymode) {
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
@@ -255,12 +256,11 @@ static int socfpga_set_phy_mode_common(int phymode, u32 *val)
static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
{
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
- int phymode = dwmac->interface;
u32 reg_offset = dwmac->reg_offset;
u32 reg_shift = dwmac->reg_shift;
u32 ctrl, val, module;
- if (socfpga_set_phy_mode_common(phymode, &val)) {
+ if (socfpga_set_phy_mode_common(dwmac, &val)) {
dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
return -EINVAL;
}
@@ -314,12 +314,11 @@ static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
static int socfpga_gen10_set_phy_mode(struct socfpga_dwmac *dwmac)
{
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
- int phymode = dwmac->interface;
u32 reg_offset = dwmac->reg_offset;
u32 reg_shift = dwmac->reg_shift;
u32 ctrl, val, module;
- if (socfpga_set_phy_mode_common(phymode, &val))
+ if (socfpga_set_phy_mode_common(dwmac, &val))
return -EINVAL;
/* Overwrite val to GMII if splitter core is enabled. The phymode here
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 2/2] vhost: re-introducing metadata acceleration through kernel virtual address
From: Jason Wang @ 2019-09-06 12:51 UTC (permalink / raw)
To: Hillf Danton
Cc: mst, kvm, virtualization, netdev, linux-kernel, jgg, aarcange,
jglisse, linux-mm, James Bottomley, Christoph Hellwig,
David Miller, linux-arm-kernel, linux-parisc
In-Reply-To: <20190906032154.9376-1-hdanton@sina.com>
On 2019/9/6 上午11:21, Hillf Danton wrote:
> On Thu, 5 Sep 2019 20:27:36 +0800 From: Jason Wang <jasowang@redhat.com>
>> +static void vhost_set_map_dirty(struct vhost_virtqueue *vq,
>> + struct vhost_map *map, int index)
>> +{
>> + struct vhost_uaddr *uaddr = &vq->uaddrs[index];
>> + int i;
>> +
>> + if (uaddr->write) {
>> + for (i = 0; i < map->npages; i++)
>> + set_page_dirty(map->pages[i]);
>> + }
> Not sure need to set page dirty under page lock.
Just to make sure I understand the issue. Do you mean there's no need
for set_page_dirty() here? If yes, is there any other function that
already did this?
Thanks
^ permalink raw reply
* Re: [PATCH v1 net-next 00/15] tc-taprio offload for SJA1105 DSA
From: David Miller @ 2019-09-06 12:54 UTC (permalink / raw)
To: olteanv
Cc: f.fainelli, vivien.didelot, andrew, vinicius.gomes, vedang.patel,
richardcochran, weifeng.voon, jiri, m-karicheri2, Jose.Abreu,
ilias.apalodimas, jhs, xiyou.wangcong, kurt.kanzenbach, netdev
In-Reply-To: <20190902162544.24613-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Mon, 2 Sep 2019 19:25:29 +0300
> This is the first attempt to submit the tc-taprio offload model for
> inclusion in the net tree.
Someone really needs to review this.
I'm not applying this patch series until someone knowledgable in this
area does some kind of review.
Thanks.
^ permalink raw reply
* Re: general protection fault in dev_map_hash_update_elem
From: Jesper Dangaard Brouer @ 2019-09-06 12:54 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: syzbot, bpf, Daniel Borkmann, Jesper Dangaard Brouer, LKML,
Network Development, syzkaller-bugs,
Toke Høiland-Jørgensen
In-Reply-To: <CAADnVQK94boXD8Y=g1LsBtNG4wrYQ0Jnjxhq7hdxvyBKZuPwXw@mail.gmail.com>
On Thu, 5 Sep 2019 14:44:37 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Thu, Sep 5, 2019 at 1:08 PM syzbot
> <syzbot+4e7a85b1432052e8d6f8@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 6d028043 Add linux-next specific files for 20190830
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=135c1a92600000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=82a6bec43ab0cb69
> > dashboard link: https://syzkaller.appspot.com/bug?extid=4e7a85b1432052e8d6f8
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=109124e1600000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+4e7a85b1432052e8d6f8@syzkaller.appspotmail.com
> >
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > general protection fault: 0000 [#1] PREEMPT SMP KASAN
> > CPU: 1 PID: 10235 Comm: syz-executor.0 Not tainted 5.3.0-rc6-next-20190830
> > #75
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RIP: 0010:__write_once_size include/linux/compiler.h:203 [inline]
> > RIP: 0010:__hlist_del include/linux/list.h:795 [inline]
> > RIP: 0010:hlist_del_rcu include/linux/rculist.h:475 [inline]
> > RIP: 0010:__dev_map_hash_update_elem kernel/bpf/devmap.c:668 [inline]
> > RIP: 0010:dev_map_hash_update_elem+0x3c8/0x6e0 kernel/bpf/devmap.c:691
> > Code: 48 89 f1 48 89 75 c8 48 c1 e9 03 80 3c 11 00 0f 85 d3 02 00 00 48 b9
> > 00 00 00 00 00 fc ff df 48 8b 53 10 48 89 d6 48 c1 ee 03 <80> 3c 0e 00 0f
> > 85 97 02 00 00 48 85 c0 48 89 02 74 38 48 89 55 b8
> > RSP: 0018:ffff88808d607c30 EFLAGS: 00010046
> > RAX: 0000000000000000 RBX: ffff8880a7f14580 RCX: dffffc0000000000
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8880a7f14588
> > RBP: ffff88808d607c78 R08: 0000000000000004 R09: ffffed1011ac0f73
> > R10: ffffed1011ac0f72 R11: 0000000000000003 R12: ffff88809f4e9400
> > R13: ffff88809b06ba00 R14: 0000000000000000 R15: ffff88809f4e9528
> > FS: 00007f3a3d50c700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007feb3fcd0000 CR3: 00000000986b9000 CR4: 00000000001406e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > map_update_elem+0xc82/0x10b0 kernel/bpf/syscall.c:966
> > __do_sys_bpf+0x8b5/0x3350 kernel/bpf/syscall.c:2854
> > __se_sys_bpf kernel/bpf/syscall.c:2825 [inline]
> > __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:2825
> > do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x459879
> > Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:00007f3a3d50bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
> > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459879
> > RDX: 0000000000000020 RSI: 0000000020000040 RDI: 0000000000000002
> > RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3a3d50c6d4
> > R13: 00000000004bfc86 R14: 00000000004d1960 R15: 00000000ffffffff
> > Modules linked in:
> > ---[ end trace 083223e21dbd0ae5 ]---
> > RIP: 0010:__write_once_size include/linux/compiler.h:203 [inline]
> > RIP: 0010:__hlist_del include/linux/list.h:795 [inline]
> > RIP: 0010:hlist_del_rcu include/linux/rculist.h:475 [inline]
> > RIP: 0010:__dev_map_hash_update_elem kernel/bpf/devmap.c:668 [inline]
> > RIP: 0010:dev_map_hash_update_elem+0x3c8/0x6e0 kernel/bpf/devmap.c:691
>
> Toke,
> please take a look.
> Thanks!
Hi Toke,
I think the problem is that you read:
old_dev = __dev_map_hash_lookup_elem(map, idx);
Before holding the lock dtab->index_lock...
I'm not sure this is the correct fix, but I think below change should
solve the issue (not even compile tested):
[bpf-next]$ git diff
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index 9af048a932b5..c41854a68e9e 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -664,6 +664,9 @@ static int __dev_map_hash_update_elem(struct net *net, struct bpf_map *map,
spin_lock_irqsave(&dtab->index_lock, flags);
+ /* Re-read old_dev while holding lock*/
+ old_dev = __dev_map_hash_lookup_elem(map, idx);
+
if (old_dev) {
hlist_del_rcu(&old_dev->index_hlist);
} else {
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply related
* Re: [PATCH net-next,v3 0/4] flow_offload: update mangle action representation
From: Edward Cree @ 2019-09-06 12:55 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, jakub.kicinski, jiri, saeedm,
vishal, vladbu
In-Reply-To: <20190906105638.hylw6quhk7t3wff2@salvia>
On 06/09/2019 11:56, Pablo Neira Ayuso wrote:
> On Fri, Sep 06, 2019 at 11:02:18AM +0100, Edward Cree wrote:
>> Still NAK for the same reasons as three versions ago (when it was called
>> "netfilter: payload mangling offload support"), you've never managed to
>> explain why this extra API complexity is useful. (Reducing LOC does not
>> mean you've reduced complexity.)
> Oh well...
>
> Patch 1) Mask is inverted for no reason, just because tc pedit needs
> this in this way. All drivers reverse this mask.
>
> Patch 2) All drivers mask out meaningless fields in the value field.
To be clear: I have no issue with these two patches; they look fine to me.
(Though I'd like to see some comments on struct flow_action_entry specifying
the semantics of these fields, especially if they're going to differ from
the corresponding fields in struct tc_pedit_key.)
> Patch 3) Without this patchset, offsets are on the 32-bit boundary.
> Drivers need to play with the 32-bit mask to infer what field they are
> supposed to mangle... eg. with 32-bit offset alignment, checking if
> the use want to alter the ttl/hop_limit need for helper structures to
> check the 32-bit mask. Mangling a IPv6 address comes with one single
> action...
Drivers are still going to need to handle multiple pedit actions, in
case the original rule wanted to mangle two non-consecutive fields.
And you can't just coalesce all consecutive mangles, because if you
mangle two consecutive fields (e.g. UDP sport and dport) the driver
still needs to disentangle that if it works on a 'fields' (rather
than 'u32s') level.
So either have the core convert things into named protocol fields
(i.e. "set src IPv6 to 1234::5 and add 1 to UDP sport"), or leave
the current sequence-of-u32-mangles as it is. This in-between "we'll
coalesce things together despite not knowing what fields they are" is
neither fish nor fowl.
-Ed
^ permalink raw reply
* Re: [PATCH 2/3] nfp: Drop unnecessary continue in nfp_net_pf_alloc_vnics
From: David Miller @ 2019-09-06 12:58 UTC (permalink / raw)
To: zhongjiang; +Cc: kvalo, pkshih, netdev, linux-kernel
In-Reply-To: <1567568784-9669-3-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Wed, 4 Sep 2019 11:46:23 +0800
> Continue is not needed at the bottom of a loop.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next v4 1/1] net: openvswitch: Set OvS recirc_id from tc chain index
From: David Miller @ 2019-09-06 12:59 UTC (permalink / raw)
To: paulb
Cc: pshelar, netdev, jpettit, simon.horman, marcelo.leitner, vladbu,
jiri, roid, yossiku, ronye, ozsh
In-Reply-To: <1567605397-14060-2-git-send-email-paulb@mellanox.com>
From: Paul Blakey <paulb@mellanox.com>
Date: Wed, 4 Sep 2019 16:56:37 +0300
> Offloaded OvS datapath rules are translated one to one to tc rules,
> for example the following simplified OvS rule:
>
> recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
>
> Will be translated to the following tc rule:
>
> $ tc filter add dev dev1 ingress \
> prio 1 chain 0 proto ip \
> flower tcp ct_state -trk \
> action ct pipe \
> action goto chain 2
>
> Received packets will first travel though tc, and if they aren't stolen
> by it, like in the above rule, they will continue to OvS datapath.
> Since we already did some actions (action ct in this case) which might
> modify the packets, and updated action stats, we would like to continue
> the proccessing with the correct recirc_id in OvS (here recirc_id(2))
> where we left off.
>
> To support this, introduce a new skb extension for tc, which
> will be used for translating tc chain to ovs recirc_id to
> handle these miss cases. Last tc chain index will be set
> by tc goto chain action and read by OvS datapath.
>
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> ---
> Changelog:
> V3->V4:
> Removed changes to tcf_result, instead us action return value to get chain index
Applied to net-next.
^ permalink raw reply
* Re: [v3] net_sched: act_police: add 2 new attributes to support police 64bit rate and peakrate
From: David Miller @ 2019-09-06 13:02 UTC (permalink / raw)
To: zdai; +Cc: jhs, xiyou.wangcong, jiri, netdev, linux-kernel, zdai
In-Reply-To: <1567609423-26826-1-git-send-email-zdai@linux.vnet.ibm.com>
From: David Dai <zdai@linux.vnet.ibm.com>
Date: Wed, 4 Sep 2019 10:03:43 -0500
> For high speed adapter like Mellanox CX-5 card, it can reach upto
> 100 Gbits per second bandwidth. Currently htb already supports 64bit rate
> in tc utility. However police action rate and peakrate are still limited
> to 32bit value (upto 32 Gbits per second). Add 2 new attributes
> TCA_POLICE_RATE64 and TCA_POLICE_RATE64 in kernel for 64bit support
> so that tc utility can use them for 64bit rate and peakrate value to
> break the 32bit limit, and still keep the backward binary compatibility.
>
> Tested-by: David Dai <zdai@linux.vnet.ibm.com>
> Signed-off-by: David Dai <zdai@linux.vnet.ibm.com>
> ---
> Changelog:
> v1->v2:
> - Move 2 attributes TCA_POLICE_RATE64 TCA_POLICE_PEAKRATE64 after
> TCA_POLICE_PAD in pkt_cls.h header.
> v2->v3:
> - Use TCA_POLICE_PAD instead of __TCA_POLICE_MAX as padding attr
> in last parameter in nla_put_u64_64bit() routine.
Applied to net-next.
^ permalink raw reply
* [PATCH 1/2] net: stmmac: implement support for passive mode converters via dt
From: Alexandru Ardelean @ 2019-09-06 13:02 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, peppe.cavallaro, alexandre.torgue, --cc=andrew,
Alexandru Ardelean
In-between the MAC & PHY there can be a mode converter, which converts one
mode to another (e.g. GMII-to-RGMII).
The converter, can be passive (i.e. no driver or OS/SW information
required), so the MAC & PHY need to be configured differently.
For the `stmmac` driver, this is implemented via a `mac-mode` property in
the device-tree, which configures the MAC into a certain mode, and for the
PHY a `phy_interface` field will hold the mode of the PHY. The mode of the
PHY will be passed to the PHY and from there-on it work in a different
mode. If unspecified, the default `phy-mode` will be used for both.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
.../ethernet/stmicro/stmmac/stmmac_platform.c | 34 ++++++++++++++++++-
include/linux/stmmac.h | 1 +
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c3baca9f587b..ec7aa42128a5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1029,7 +1029,7 @@ static int stmmac_init_phy(struct net_device *dev)
static int stmmac_phy_setup(struct stmmac_priv *priv)
{
struct fwnode_handle *fwnode = of_fwnode_handle(priv->plat->phylink_node);
- int mode = priv->plat->interface;
+ int mode = priv->plat->phy_interface;
struct phylink *phylink;
priv->phylink_config.dev = &priv->dev->dev;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index eaf8f08f2e91..401cbbfc06f0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -355,6 +355,32 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
return 0;
}
+/**
+ * stmmac_of_get_mac_mode - retrieves the interface of the MAC
+ * @np - device-tree node
+ * Description:
+ * Similar to `of_get_phy_mode()`, this function will retrieve (from
+ * the device-tree) the interface mode on the MAC side. This assumes
+ * that there is mode converter in-between the MAC & PHY
+ * (e.g. GMII-to-RGMII).
+ */
+static int stmmac_of_get_mac_mode(struct device_node *np)
+{
+ const char *pm;
+ int err, i;
+
+ err = of_property_read_string(np, "mac-mode", &pm);
+ if (err < 0)
+ return err;
+
+ for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++) {
+ if (!strcasecmp(pm, phy_modes(i)))
+ return i;
+ }
+
+ return -ENODEV;
+}
+
/**
* stmmac_probe_config_dt - parse device-tree driver parameters
* @pdev: platform_device structure
@@ -383,7 +409,13 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
*mac = NULL;
}
- plat->interface = of_get_phy_mode(np);
+ plat->phy_interface = of_get_phy_mode(np);
+ if (plat->phy_interface < 0)
+ return ERR_PTR(plat->phy_interface);
+
+ plat->interface = stmmac_of_get_mac_mode(np);
+ if (plat->interface < 0)
+ plat->interface = plat->phy_interface;
/* Some wrapper drivers still rely on phy_node. Let's save it while
* they are not converted to phylink. */
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 7ad7ae35cf88..dc60d03c4b60 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -131,6 +131,7 @@ struct plat_stmmacenet_data {
int bus_id;
int phy_addr;
int interface;
+ int phy_interface;
struct stmmac_mdio_bus_data *mdio_bus_data;
struct device_node *phy_node;
struct device_node *phylink_node;
--
2.20.1
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: net: dwmac: document 'mac-mode' property
From: Alexandru Ardelean @ 2019-09-06 13:02 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, peppe.cavallaro, alexandre.torgue, --cc=andrew,
Alexandru Ardelean
In-Reply-To: <20190906130256.10321-1-alexandru.ardelean@analog.com>
This change documents the 'mac-mode' property that was introduced in the
'stmmac' driver to support passive mode converters that can sit in-between
the MAC & PHY.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
Documentation/devicetree/bindings/net/snps,dwmac.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index c78be15704b9..ebe4537a7cce 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -112,6 +112,14 @@ properties:
reset-names:
const: stmmaceth
+ mac-mode:
+ maxItems: 1
+ description:
+ The property is identical to 'phy-mode', and assumes that there is mode
+ converter in-between the MAC & PHY (e.g. GMII-to-RGMII). This converter
+ can be passive (no SW requirement), and requires that the MAC operate
+ in a different mode than the PHY in order to function.
+
snps,axi-config:
$ref: /schemas/types.yaml#definitions/phandle
description:
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 net] net: sonic: return NETDEV_TX_OK if failed to map buffer
From: David Miller @ 2019-09-06 13:05 UTC (permalink / raw)
To: maowenan; +Cc: eric.dumazet, tsbogend, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20190905015712.107173-1-maowenan@huawei.com>
From: Mao Wenan <maowenan@huawei.com>
Date: Thu, 5 Sep 2019 09:57:12 +0800
> NETDEV_TX_BUSY really should only be used by drivers that call
> netif_tx_stop_queue() at the wrong moment. If dma_map_single() is
> failed to map tx DMA buffer, it might trigger an infinite loop.
> This patch use NETDEV_TX_OK instead of NETDEV_TX_BUSY, and change
> printk to pr_err_ratelimited.
>
> Fixes: d9fb9f384292 ("*sonic/natsemi/ns83829: Move the National Semi-conductor drivers")
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCHv3 1/1] forcedeth: use per cpu to collect xmit/recv statistics
From: David Miller @ 2019-09-06 13:07 UTC (permalink / raw)
To: yanjun.zhu; +Cc: eric.dumazet, netdev
In-Reply-To: <1567674942-5132-2-git-send-email-yanjun.zhu@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Thu, 5 Sep 2019 05:15:42 -0400
> When testing with a background iperf pushing 1Gbit/sec traffic and running
> both ifconfig and netstat to collect statistics, some deadlocks occurred.
>
> Ifconfig and netstat will call nv_get_stats64 to get software xmit/recv
> statistics. In the commit f5d827aece36 ("forcedeth: implement
> ndo_get_stats64() API"), the normal tx/rx variables is to collect tx/rx
> statistics. The fix is to replace normal tx/rx variables with per
> cpu 64-bit variable to collect xmit/recv statistics. The per cpu variable
> will avoid deadlocks and provide fast efficient statistics updates.
>
> In nv_probe, the per cpu variable is initialized. In nv_remove, this
> per cpu variable is freed.
>
> In xmit/recv process, this per cpu variable will be updated.
>
> In nv_get_stats64, this per cpu variable on each cpu is added up. Then
> the driver can get xmit/recv packets statistics.
>
> A test runs for several days with this commit, the deadlocks disappear
> and the performance is better.
>
> Tested:
...
> Fixes: f5d827aece36 ("forcedeth: implement ndo_get_stats64() API")
> CC: Joe Jin <joe.jin@oracle.com>
> CC: JUNXIAO_BI <junxiao.bi@oracle.com>
> Reported-and-tested-by: Nan san <nan.1986san@gmail.com>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Applied.
^ permalink raw reply
* Re: pull request (net): ipsec 2019-09-05
From: David Miller @ 2019-09-06 13:09 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20190905102201.1636-1-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 5 Sep 2019 12:21:56 +0200
> 1) Several xfrm interface fixes from Nicolas Dichtel:
> - Avoid an interface ID corruption on changelink.
> - Fix wrong intterface names in the logs.
> - Fix a list corruption when changing network namespaces.
> - Fix unregistation of the underying phydev.
>
> 2) Fix a potential warning when merging xfrm_plocy nodes.
> From Florian Westphal.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Do not check Link status when loopback is enabled
From: David Miller @ 2019-09-06 13:11 UTC (permalink / raw)
To: Jose.Abreu
Cc: netdev, Joao.Pinto, andrew, f.fainelli, hkallweit1, linux-kernel
In-Reply-To: <7db46f6b1318ec22d45f7e6f6f907eda015a9df6.1567683751.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Thu, 5 Sep 2019 13:43:10 +0200
> While running stmmac selftests I found that in my 1G setup some tests
> were failling when running with PHY loopback enabled.
>
> It looks like when loopback is enabled the PHY will report that Link is
> down even though there is a valid connection.
>
> As in loopback mode the data will not be sent anywhere we can bypass the
> logic of checking if Link is valid thus saving unecessary reads.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net] net: sched: fix reordering issues
From: David Miller @ 2019-09-06 13:13 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, john.fastabend
In-Reply-To: <20190905122022.106680-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 5 Sep 2019 05:20:22 -0700
> Whenever MQ is not used on a multiqueue device, we experience
> serious reordering problems. Bisection found the cited
> commit.
>
> The issue can be described this way :
>
> - A single qdisc hierarchy is shared by all transmit queues.
> (eg : tc qdisc replace dev eth0 root fq_codel)
>
> - When/if try_bulk_dequeue_skb_slow() dequeues a packet targetting
> a different transmit queue than the one used to build a packet train,
> we stop building the current list and save the 'bad' skb (P1) in a
> special queue. (bad_txq)
>
> - When dequeue_skb() calls qdisc_dequeue_skb_bad_txq() and finds this
> skb (P1), it checks if the associated transmit queues is still in frozen
> state. If the queue is still blocked (by BQL or NIC tx ring full),
> we leave the skb in bad_txq and return NULL.
>
> - dequeue_skb() calls q->dequeue() to get another packet (P2)
>
> The other packet can target the problematic queue (that we found
> in frozen state for the bad_txq packet), but another cpu just ran
> TX completion and made room in the txq that is now ready to accept
> new packets.
>
> - Packet P2 is sent while P1 is still held in bad_txq, P1 might be sent
> at next round. In practice P2 is the lead of a big packet train
> (P2,P3,P4 ...) filling the BQL budget and delaying P1 by many packets :/
>
> To solve this problem, we have to block the dequeue process as long
> as the first packet in bad_txq can not be sent. Reordering issues
> disappear and no side effects have been seen.
>
> Fixes: a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next,v3 0/4] flow_offload: update mangle action representation
From: Pablo Neira Ayuso @ 2019-09-06 13:14 UTC (permalink / raw)
To: Edward Cree
Cc: netfilter-devel, davem, netdev, jakub.kicinski, jiri, saeedm,
vishal, vladbu
In-Reply-To: <b8baf681-b808-4b83-d521-0353c3136516@solarflare.com>
On Fri, Sep 06, 2019 at 01:55:29PM +0100, Edward Cree wrote:
> On 06/09/2019 11:56, Pablo Neira Ayuso wrote:
> > On Fri, Sep 06, 2019 at 11:02:18AM +0100, Edward Cree wrote:
> >> Still NAK for the same reasons as three versions ago (when it was called
> >> "netfilter: payload mangling offload support"), you've never managed to
> >> explain why this extra API complexity is useful. (Reducing LOC does not
> >> mean you've reduced complexity.)
> > Oh well...
> >
> > Patch 1) Mask is inverted for no reason, just because tc pedit needs
> > this in this way. All drivers reverse this mask.
> >
> > Patch 2) All drivers mask out meaningless fields in the value field.
>
> To be clear: I have no issue with these two patches; they look fine to me.
> (Though I'd like to see some comments on struct flow_action_entry specifying
> the semantics of these fields, especially if they're going to differ from
> the corresponding fields in struct tc_pedit_key.)
OK, I can document this semantics, I need just _time_ to write that
documentation. I was expecting this patch description is enough by now
until I can get to finish that documentation.
> > Patch 3) Without this patchset, offsets are on the 32-bit boundary.
> > Drivers need to play with the 32-bit mask to infer what field they are
> > supposed to mangle... eg. with 32-bit offset alignment, checking if
> > the use want to alter the ttl/hop_limit need for helper structures to
> > check the 32-bit mask. Mangling a IPv6 address comes with one single
> > action...
>
> Drivers are still going to need to handle multiple pedit actions, in
> case the original rule wanted to mangle two non-consecutive fields.
> And you can't just coalesce all consecutive mangles, because if you
> mangle two consecutive fields (e.g. UDP sport and dport) the driver
> still needs to disentangle that if it works on a 'fields' (rather
> than 'u32s') level.
This infrastructure is _not_ coalescing two consecutive field, e.g.
UDP sport and dport is _not_ coalesced. The coalesce routine does
_not_ handle multiple tc pedit ex actions.
I'll clarify this in the cover letter in the next patchset round.
> So either have the core convert things into named protocol fields
> (i.e. "set src IPv6 to 1234::5 and add 1 to UDP sport"), or leave
> the current sequence-of-u32-mangles as it is. This in-between "we'll
> coalesce things together despite not knowing what fields they are" is
> neither fish nor fowl.
The model you propose would still need this code for tc pedit to
adjust offset/length and coalesce u32 fields.
^ permalink raw reply
* Re: [PATCH 0/2] Revert and rework on the metadata accelreation
From: David Miller @ 2019-09-06 13:15 UTC (permalink / raw)
To: jasowang
Cc: jgg, mst, kvm, virtualization, netdev, linux-kernel, aarcange,
jglisse, linux-mm
In-Reply-To: <7785d39b-b4e7-8165-516c-ee6a08ac9c4e@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Fri, 6 Sep 2019 18:02:35 +0800
> On 2019/9/5 下午9:59, Jason Gunthorpe wrote:
>> I think you should apply the revert this cycle and rebase the other
>> patch for next..
>>
>> Jason
>
> Yes, the plan is to revert in this release cycle.
Then you should reset patch #1 all by itself targetting 'net'.
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: add myself as maintainer for xilinx axiethernet driver
From: David Miller @ 2019-09-06 13:17 UTC (permalink / raw)
To: radhey.shyam.pandey
Cc: netdev, michal.simek, anirudha.sarangi, john.linn,
mchehab+samsung, gregkh, nicolas.ferre, linux-arm-kernel,
linux-kernel
In-Reply-To: <1567688168-20607-1-git-send-email-radhey.shyam.pandey@xilinx.com>
From: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Date: Thu, 5 Sep 2019 18:26:08 +0530
> I am maintaining xilinx axiethernet driver in xilinx tree and would like
> to maintain it in the mainline kernel as well. Hence adding myself as a
> maintainer. Also Anirudha and John has moved to new roles, so based on
> request removing them from the maintainer list.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> Acked-by: John Linn <john.linn@xilinx.com>
> Acked-by: Michal Simek <michal.simek@xilinx.com>
> ---
> I am resending this patch as earlier version didn't go through mailing
> list due to some config restriction on the external email addresses.
> Also adding Michal's acked-by tag.
Applied to 'net'.
^ 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