* Re: [PATCH 4/4] mt76: mt76x02: run mt76x02_edcca_init atomically in mt76_edcca_set
From: Lorenzo Bianconi @ 2019-05-11 14:29 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Lorenzo Bianconi, linux-wireless, Stanislaw Gruszka
In-Reply-To: <97ef0073-6dae-f9d1-e97f-9aadaa629628@nbd.name>
>
> On 2019-05-11 12:17, Lorenzo Bianconi wrote:
> > Run mt76x02_edcca_init atomically in mt76_edcca_set since it runs
> > concurrently with calibration work and mt76x2_set_channel.
> > Introduce __mt76x02_edcca_init helper routine
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> I don't think this is enough. To prevent issues with calibration, we
> probably need to hold the mutex for the duration of the calibration
> anyway. Otherwise it might get enabled right in the middle of it and
> screw things up.
> Also, it probably simplifies the patch if you don't add the wrapper
> function that takes the mutex, and instead just explicitly take the
> mutex where needed.
So IIUC it would be better to hold the mutex during
mt76x2_phy_calibrate processing, right?
If so, do I need to repost all the series or just this patch?
Regards,
Lorenzo
>
> - Felix
^ permalink raw reply
* Re: [PATCH 4/4] mt76: mt76x02: run mt76x02_edcca_init atomically in mt76_edcca_set
From: Felix Fietkau @ 2019-05-11 14:30 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Lorenzo Bianconi, linux-wireless, Stanislaw Gruszka
In-Reply-To: <CAJ0CqmW8RyBmn1_-M0gQGvLOsTd45kAji7wmurs-GHBLac9Dyg@mail.gmail.com>
On 2019-05-11 16:29, Lorenzo Bianconi wrote:
>>
>> On 2019-05-11 12:17, Lorenzo Bianconi wrote:
>> > Run mt76x02_edcca_init atomically in mt76_edcca_set since it runs
>> > concurrently with calibration work and mt76x2_set_channel.
>> > Introduce __mt76x02_edcca_init helper routine
>> >
>> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>> I don't think this is enough. To prevent issues with calibration, we
>> probably need to hold the mutex for the duration of the calibration
>> anyway. Otherwise it might get enabled right in the middle of it and
>> screw things up.
>> Also, it probably simplifies the patch if you don't add the wrapper
>> function that takes the mutex, and instead just explicitly take the
>> mutex where needed.
>
> So IIUC it would be better to hold the mutex during
> mt76x2_phy_calibrate processing, right?
Right.
> If so, do I need to repost all the series or just this patch?
Feel free to repost just this patch.
Thanks,
- Felix
^ permalink raw reply
* [PATCH v2 4/4] mt76: mt76x02: run mt76x02_edcca_init atomically in mt76_edcca_set
From: Lorenzo Bianconi @ 2019-05-11 15:30 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka
In-Reply-To: <cover.1557587336.git.lorenzo@kernel.org>
Run mt76x02_edcca_init atomically in mt76_edcca_set since it runs
concurrently with calibration work and mt76x2_set_channel.
Moreover perform phy calibration atomically
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c | 4 ++++
drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c | 6 ++++++
drivers/net/wireless/mediatek/mt76/mt76x2/usb_phy.c | 5 +++++
3 files changed, 15 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c b/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
index 7853078e8ca4..f412c779d8e2 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
@@ -122,11 +122,15 @@ mt76_edcca_set(void *data, u64 val)
struct mt76x02_dev *dev = data;
enum nl80211_dfs_regions region = dev->dfs_pd.region;
+ mutex_lock(&dev->mt76.mutex);
+
dev->ed_monitor_enabled = !!val;
dev->ed_monitor = dev->ed_monitor_enabled &&
region == NL80211_DFS_ETSI;
mt76x02_edcca_init(dev);
+ mutex_unlock(&dev->mt76.mutex);
+
return 0;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c
index 7a39a390a7ac..2edf1bd0c18c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c
@@ -294,10 +294,16 @@ void mt76x2_phy_calibrate(struct work_struct *work)
struct mt76x02_dev *dev;
dev = container_of(work, struct mt76x02_dev, cal_work.work);
+
+ mutex_lock(&dev->mt76.mutex);
+
mt76x2_phy_channel_calibrate(dev, false);
mt76x2_phy_tssi_compensate(dev);
mt76x2_phy_temp_compensate(dev);
mt76x2_phy_update_channel_gain(dev);
+
+ mutex_unlock(&dev->mt76.mutex);
+
ieee80211_queue_delayed_work(mt76_hw(dev), &dev->cal_work,
MT_CALIBRATE_INTERVAL);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_phy.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_phy.c
index c7208c5375ac..dfd54f9b0e97 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_phy.c
@@ -55,10 +55,15 @@ void mt76x2u_phy_calibrate(struct work_struct *work)
struct mt76x02_dev *dev;
dev = container_of(work, struct mt76x02_dev, cal_work.work);
+
+ mutex_lock(&dev->mt76.mutex);
+
mt76x2u_phy_channel_calibrate(dev, false);
mt76x2_phy_tssi_compensate(dev);
mt76x2_phy_update_channel_gain(dev);
+ mutex_unlock(&dev->mt76.mutex);
+
ieee80211_queue_delayed_work(mt76_hw(dev), &dev->cal_work,
MT_CALIBRATE_INTERVAL);
}
--
2.20.1
^ permalink raw reply related
* [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Lorenzo Bianconi @ 2019-05-11 16:38 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless
In-Reply-To: <cover.1557591530.git.lorenzo@kernel.org>
Introduce a knob in mt7603 debugfs in order to enable/disable
edcca processing
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../wireless/mediatek/mt76/mt7603/debugfs.c | 30 +++++++++++++++++++
.../net/wireless/mediatek/mt76/mt7603/init.c | 4 ++-
.../net/wireless/mediatek/mt76/mt7603/main.c | 3 +-
.../wireless/mediatek/mt76/mt7603/mt7603.h | 6 +++-
4 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
index f8b3b6ab6297..efc1cf5ae870 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
@@ -40,6 +40,35 @@ mt7603_radio_read(struct seq_file *s, void *data)
return 0;
}
+static int
+mt7603_edcca_set(void *data, u64 val)
+{
+ struct mt7603_dev *dev = data;
+
+ mutex_lock(&dev->mt76.mutex);
+
+ dev->ed_monitor_enabled = !!val;
+ dev->ed_monitor = dev->ed_monitor_enabled &&
+ dev->region == NL80211_DFS_ETSI;
+ mt7603_init_edcca(dev);
+
+ mutex_unlock(&dev->mt76.mutex);
+
+ return 0;
+}
+
+static int
+mt7603_edcca_get(void *data, u64 *val)
+{
+ struct mt7603_dev *dev = data;
+
+ *val = dev->ed_monitor_enabled;
+ return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(fops_edcca, mt7603_edcca_get,
+ mt7603_edcca_set, "%lld\n");
+
void mt7603_init_debugfs(struct mt7603_dev *dev)
{
struct dentry *dir;
@@ -48,6 +77,7 @@ void mt7603_init_debugfs(struct mt7603_dev *dev)
if (!dir)
return;
+ debugfs_create_file("edcca", 0400, dir, dev, &fops_edcca);
debugfs_create_u32("reset_test", 0600, dir, &dev->reset_test);
debugfs_create_devm_seqfile(dev->mt76.dev, "reset", dir,
mt7603_reset_read);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/init.c b/drivers/net/wireless/mediatek/mt76/mt7603/init.c
index 78cdbb70e178..4e269044f8a4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/init.c
@@ -437,7 +437,9 @@ mt7603_regd_notifier(struct wiphy *wiphy,
struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
struct mt7603_dev *dev = hw->priv;
- dev->ed_monitor = request->dfs_region == NL80211_DFS_ETSI;
+ dev->region = request->dfs_region;
+ dev->ed_monitor = dev->ed_monitor_enabled &&
+ dev->region == NL80211_DFS_ETSI;
}
static int
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/main.c b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
index 0a0334dc40d5..e931af92af43 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
@@ -103,8 +103,7 @@ mt7603_remove_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
mutex_unlock(&dev->mt76.mutex);
}
-static void
-mt7603_init_edcca(struct mt7603_dev *dev)
+void mt7603_init_edcca(struct mt7603_dev *dev)
{
/* Set lower signal level to -65dBm */
mt76_rmw_field(dev, MT_RXTD(8), MT_RXTD_8_LOWER_SIGNAL, 0x23);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h b/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
index fa64bbaab0d2..944dc9a11a15 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
@@ -117,8 +117,11 @@ struct mt7603_dev {
u8 mac_work_count;
u8 mcu_running;
- u8 ed_monitor;
+ enum nl80211_dfs_regions region;
+
+ u8 ed_monitor_enabled;
+ u8 ed_monitor;
s8 ed_trigger;
u8 ed_strict_mode;
u8 ed_strong_signal;
@@ -241,4 +244,5 @@ void mt7603_update_channel(struct mt76_dev *mdev);
void mt7603_edcca_set_strict(struct mt7603_dev *dev, bool val);
void mt7603_cca_stats_reset(struct mt7603_dev *dev);
+void mt7603_init_edcca(struct mt7603_dev *dev);
#endif
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Kalle Valo @ 2019-05-13 4:26 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <0691acb931e963cb6028d4687cdd61032d0aaf52.1557591530.git.lorenzo@kernel.org>
Lorenzo Bianconi <lorenzo@kernel.org> writes:
> Introduce a knob in mt7603 debugfs in order to enable/disable
> edcca processing
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
It's good to explain what edcca does and how the file is used supposed
to be used. In other words, have a small introduction for the user.
> @@ -48,6 +77,7 @@ void mt7603_init_debugfs(struct mt7603_dev *dev)
> if (!dir)
> return;
>
> + debugfs_create_file("edcca", 0400, dir, dev, &fops_edcca);
Why 0400 and not 0600?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mac80211: remove warning message
From: Yibo Zhao @ 2019-05-13 6:20 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <7119f24f-5b88-629a-d507-73776b841f65@candelatech.com>
On 2019-05-10 22:04, Ben Greear wrote:
> On 05/10/2019 12:01 AM, Yibo Zhao wrote:
>> In multiple SSID cases, it takes time to prepare every AP interface
>> to be ready in initializing phase. If a sta already knows everything
>> it
>> needs to join one of the APs and sends authentication to the AP which
>> is not fully prepared at this point of time, AP's channel context
>> could be NULL. As a result, warning message occurs.
>>
>> Even worse, if the AP is under attack via tools such as MDK3 and
>> massive
>> authentication requests are received in a very short time, console
>> will
>> be hung due to kernel warning messages.
>
> Since it is a WARN_ON_ONCE, how it the console hang due to warnings?
> You should
> get no more than once per boot?
>
Hi Ben,
I was planning to use WARN_ON_ONCE() in the first place to replace
WARN_ON() then after some discussion, we think removing it could be
better. So the patch was based on my first version. Sorry for the
confusing. Will raise another one.
> I have no problem with removing it though. Seems a harmless splat and
> I removed
> it from my tree some time back as well.
>
> Thanks,
> Ben
>
>>
>> If this case can be hit during normal functionality, there should be
>> no
>> WARN_ON(). Those should be reserved to cases that are not supposed to
>> be
>> hit at all or some other more specific cases like indicating obsolete
>> interface.
>>
>> Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
>> Signed-off-by: Yibo Zhao <yiboz@codeaurora.org>
>> ---
>> net/mac80211/ieee80211_i.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
>> index 2ae0364..f39c289 100644
>> --- a/net/mac80211/ieee80211_i.h
>> +++ b/net/mac80211/ieee80211_i.h
>> @@ -1435,7 +1435,7 @@ struct ieee80211_local {
>> rcu_read_lock();
>> chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
>>
>> - if (WARN_ON_ONCE(!chanctx_conf)) {
>> + if (!chanctx_conf) {
>> rcu_read_unlock();
>> return NULL;
>> }
>>
--
Yibo
^ permalink raw reply
* Re: [PATCH 03/16] lib,treewide: add new match_string() helper/macro
From: Ardelean, Alexandru @ 2019-05-13 7:00 UTC (permalink / raw)
To: andriy.shevchenko@linux.intel.com
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org, linux-usb@vger.kernel.org,
linux-mmc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
cgroups@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linux-pm@vger.kernel.org, linux-mm@kvack.org,
linux-omap@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-security-module@vger.kernel.org, devel@driverdev.osuosl.org,
linux-mtd@lists.infradead.org, linux-integrity@vger.kernel.org,
dri-devel@lists.freedesktop.org,
linux-rpi-kernel@lists.infradead.org, linux-fbdev@vger.kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
linux-tegra@vger.kernel.org, netdev@vger.kernel.org,
linux-rockchip@lists.infradead.org, alsa-devel@alsa-project.org,
linux-pci@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20190510143407.GA9224@smile.fi.intel.com>
On Fri, 2019-05-10 at 17:34 +0300, andriy.shevchenko@linux.intel.com wrote:
> [External]
>
>
> On Fri, May 10, 2019 at 09:15:27AM +0000, Ardelean, Alexandru wrote:
> > On Wed, 2019-05-08 at 16:22 +0300, Alexandru Ardelean wrote:
> > > On Wed, 2019-05-08 at 15:18 +0200, Greg KH wrote:
> > > > On Wed, May 08, 2019 at 04:11:28PM +0300, Andy Shevchenko wrote:
> > > > > On Wed, May 08, 2019 at 02:28:29PM +0300, Alexandru Ardelean
> > > > > wrote:
> > > > > Can you split include/linux/ change from the rest?
> > > >
> > > > That would break the build, why do you want it split out? This
> > > > makes
> > > > sense all as a single patch to me.
> > > >
> > >
> > > Not really.
> > > It would be just be the new match_string() helper/macro in a new
> > > commit.
> > > And the conversions of the simple users of match_string() (the ones
> > > using
> > > ARRAY_SIZE()) in another commit.
> > >
> >
> > I should have asked in my previous reply.
> > Leave this as-is or re-formulate in 2 patches ?
>
> Depends on on what you would like to spend your time: collecting Acks for
> all
> pieces in treewide patch or send new API first followed up by per driver
> /
> module update in next cycle.
I actually would have preferred new API first, with the current
`match_string()` -> `__match_string()` rename from the start, but I wasn't
sure. I am still navigating through how feedbacks are working in this
realm.
I'll send a V2 with the API change-first/only; should be a smaller list.
Then see about follow-ups/changes per subsystems.
>
> I also have no strong preference.
> And I think it's good to add Heikki Krogerus to Cc list for both patch
> series,
> since he is the author of sysfs variant and may have something to comment
> on
> the rest.
Thanks for the reference.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v2 3/7] lib/hexdump.c: Optionally suppress lines of repeated bytes
From: Geert Uytterhoeven @ 2019-05-13 7:01 UTC (permalink / raw)
To: Alastair D'Silva
Cc: alastair, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
David Airlie, Daniel Vetter, Dan Carpenter, Karsten Keil,
Jassi Brar, Tom Lendacky, David S. Miller, Jose Abreu, Kalle Valo,
Stanislaw Gruszka, Benson Leung, Enric Balletbo i Serra,
James E.J. Bottomley, Martin K. Petersen, Greg Kroah-Hartman,
Alexander Viro, Petr Mladek, Sergey Senozhatsky, Steven Rostedt,
David Laight, Andrew Morton, Intel Graphics Development,
DRI Development, Linux Kernel Mailing List, netdev, ath10k,
linux-wireless, scsi, Linux Fbdev development list, driverdevel,
Linux FS Devel
In-Reply-To: <20190508070148.23130-4-alastair@au1.ibm.com>
Hi Alastair,
Thanks for your patch!
On Wed, May 8, 2019 at 9:04 AM Alastair D'Silva <alastair@au1.ibm.com> wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Some buffers may only be partially filled with useful data, while the rest
> is padded (typically with 0x00 or 0xff).
>
> This patch introduces a flag to allow the supression of lines of repeated
> bytes,
Given print_hex_dump() operates on entities of groupsize (1, 2, 4, or 8)
bytes, wouldn't it make more sense to consider repeated groups instead
of repeated bytes?
> which are replaced with '** Skipped %u bytes of value 0x%x **'
Using a custom message instead of just "*", like "hexdump" uses, will
require preprocessing the output when recovering the original binary
data by feeding it to e.g. "xxd".
This may sound worse than it is, though, as I never got "xxd" to work
without preprocessing anyway ;-)
$ cat $(type -p unhexdump)
#!/bin/sh
sed 's/^[0-9a-f]*//' $1 | xxd -r -p | dd conv=swab
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH v2 3/7] lib/hexdump.c: Optionally suppress lines of repeated bytes
From: Alastair D'Silva @ 2019-05-13 7:35 UTC (permalink / raw)
To: 'Geert Uytterhoeven', 'Alastair D'Silva'
Cc: 'Jani Nikula', 'Joonas Lahtinen',
'Rodrigo Vivi', 'David Airlie',
'Daniel Vetter', 'Dan Carpenter',
'Karsten Keil', 'Jassi Brar',
'Tom Lendacky', 'David S. Miller',
'Jose Abreu', 'Kalle Valo',
'Stanislaw Gruszka', 'Benson Leung',
'Enric Balletbo i Serra', 'James E.J. Bottomley',
'Martin K. Petersen', 'Greg Kroah-Hartman',
'Alexander Viro', 'Petr Mladek',
'Sergey Senozhatsky', 'Steven Rostedt',
'David Laight', 'Andrew Morton',
'Intel Graphics Development', 'DRI Development',
'Linux Kernel Mailing List', 'netdev', ath10k,
'linux-wireless', 'scsi',
'Linux Fbdev development list', 'driverdevel',
'Linux FS Devel'
In-Reply-To: <CAMuHMdVefYTgHzGKBc0ebku1z8V3wsM0ydN+6-S2nFKaB8eH_Q@mail.gmail.com>
> -----Original Message-----
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: Monday, 13 May 2019 5:01 PM
> To: Alastair D'Silva <alastair@au1.ibm.com>
> Cc: alastair@d-silva.org; Jani Nikula <jani.nikula@linux.intel.com>; Joonas
> Lahtinen <joonas.lahtinen@linux.intel.com>; Rodrigo Vivi
> <rodrigo.vivi@intel.com>; David Airlie <airlied@linux.ie>; Daniel Vetter
> <daniel@ffwll.ch>; Dan Carpenter <dan.carpenter@oracle.com>; Karsten
> Keil <isdn@linux-pingi.de>; Jassi Brar <jassisinghbrar@gmail.com>; Tom
> Lendacky <thomas.lendacky@amd.com>; David S. Miller
> <davem@davemloft.net>; Jose Abreu <Jose.Abreu@synopsys.com>; Kalle
> Valo <kvalo@codeaurora.org>; Stanislaw Gruszka <sgruszka@redhat.com>;
> Benson Leung <bleung@chromium.org>; Enric Balletbo i Serra
> <enric.balletbo@collabora.com>; James E.J. Bottomley
> <jejb@linux.ibm.com>; Martin K. Petersen <martin.petersen@oracle.com>;
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Alexander Viro
> <viro@zeniv.linux.org.uk>; Petr Mladek <pmladek@suse.com>; Sergey
> Senozhatsky <sergey.senozhatsky@gmail.com>; Steven Rostedt
> <rostedt@goodmis.org>; David Laight <David.Laight@aculab.com>; Andrew
> Morton <akpm@linux-foundation.org>; Intel Graphics Development <intel-
> gfx@lists.freedesktop.org>; DRI Development <dri-
> devel@lists.freedesktop.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>; netdev <netdev@vger.kernel.org>;
> ath10k@lists.infradead.org; linux-wireless <linux-wireless@vger.kernel.org>;
> scsi <linux-scsi@vger.kernel.org>; Linux Fbdev development list <linux-
> fbdev@vger.kernel.org>; driverdevel <devel@driverdev.osuosl.org>; Linux
> FS Devel <linux-fsdevel@vger.kernel.org>
> Subject: Re: [PATCH v2 3/7] lib/hexdump.c: Optionally suppress lines of
> repeated bytes
>
> Hi Alastair,
>
> Thanks for your patch!
And thanks for your politeness :)
>
> On Wed, May 8, 2019 at 9:04 AM Alastair D'Silva <alastair@au1.ibm.com>
> wrote:
> > From: Alastair D'Silva <alastair@d-silva.org>
> >
> > Some buffers may only be partially filled with useful data, while the
> > rest is padded (typically with 0x00 or 0xff).
> >
> > This patch introduces a flag to allow the supression of lines of
> > repeated bytes,
>
> Given print_hex_dump() operates on entities of groupsize (1, 2, 4, or 8)
> bytes, wouldn't it make more sense to consider repeated groups instead of
> repeated bytes?
Maybe, it would mean that subsequent addresses may not be a multiple of rowsize though, which is useful.
> > which are replaced with '** Skipped %u bytes of value 0x%x **'
>
> Using a custom message instead of just "*", like "hexdump" uses, will require
> preprocessing the output when recovering the original binary data by
> feeding it to e.g. "xxd".
> This may sound worse than it is, though, as I never got "xxd" to work without
> preprocessing anyway ;-)
I think showing the details of the skipped values is useful when reading the output directly. In situations where binary extracts are desired, the feature can always be disabled.
--
Alastair D'Silva mob: 0423 762 819
skype: alastair_dsilva msn: alastair@d-silva.org
blog: http://alastair.d-silva.org Twitter: @EvilDeece
^ permalink raw reply
* Re: [PATCH 3/4] mt76: mt76x2: move mutex_lock inside mt76x2_set_channel
From: Stanislaw Gruszka @ 2019-05-13 8:37 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <1527e88fc4a307aa218f515811f2f2c15786caec.1557567465.git.lorenzo@kernel.org>
On Sat, May 11, 2019 at 12:17:53PM +0200, Lorenzo Bianconi wrote:
> This is a preliminary patch to run mt76x02_edcca_init atomically
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../wireless/mediatek/mt76/mt76x2/pci_main.c | 16 ++++++++------
> .../wireless/mediatek/mt76/mt76x2/usb_main.c | 22 ++++++++++---------
> 2 files changed, 21 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> index e416eee6a306..3a1467326f4d 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> @@ -54,14 +54,14 @@ mt76x2_set_channel(struct mt76x02_dev *dev, struct cfg80211_chan_def *chandef)
> int ret;
>
> cancel_delayed_work_sync(&dev->cal_work);
Since now you use mutex in mt76x2_phy_calibrate() you can remove
cancel_delayed_work_sync() and drop other changes from this patch
as releasing mutex just to acquire it in almost next step make
no sense.
Stanislaw
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Lorenzo Bianconi @ 2019-05-13 8:41 UTC (permalink / raw)
To: Kalle Valo; +Cc: nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <87r293ugia.fsf@purkki.adurom.net>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>
> > Introduce a knob in mt7603 debugfs in order to enable/disable
> > edcca processing
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> It's good to explain what edcca does and how the file is used supposed
> to be used. In other words, have a small introduction for the user.
Hi Kalle,
edcca is used for adjusting energy detect based on CCA thresholds.
The code was already there so I just reported the acronym.
>
> > @@ -48,6 +77,7 @@ void mt7603_init_debugfs(struct mt7603_dev *dev)
> > if (!dir)
> > return;
> >
> > + debugfs_create_file("edcca", 0400, dir, dev, &fops_edcca);
>
> Why 0400 and not 0600?
yes, right. There is the same issue in mt76x02 code, I will fix both of them.
Thx.
Regards,
Lorenzo
>
> --
> Kalle Valo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] mt76: mt76x2: move mutex_lock inside mt76x2_set_channel
From: Lorenzo Bianconi @ 2019-05-13 9:19 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190513083755.GA13726@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]
> On Sat, May 11, 2019 at 12:17:53PM +0200, Lorenzo Bianconi wrote:
> > This is a preliminary patch to run mt76x02_edcca_init atomically
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > .../wireless/mediatek/mt76/mt76x2/pci_main.c | 16 ++++++++------
> > .../wireless/mediatek/mt76/mt76x2/usb_main.c | 22 ++++++++++---------
> > 2 files changed, 21 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> > index e416eee6a306..3a1467326f4d 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> > @@ -54,14 +54,14 @@ mt76x2_set_channel(struct mt76x02_dev *dev, struct cfg80211_chan_def *chandef)
> > int ret;
> >
> > cancel_delayed_work_sync(&dev->cal_work);
>
> Since now you use mutex in mt76x2_phy_calibrate() you can remove
> cancel_delayed_work_sync() and drop other changes from this patch
> as releasing mutex just to acquire it in almost next step make
> no sense.
I agree with you, the only difference is in that way we will perform phy
calibration even during scanning. If the there are no
objections I will post a v3 removing cancel_delayed_work_sync and
reworking patch 3/4
Regards,
Lorenzo
>
> Stanislaw
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] brcmfmac: sanitize DMI strings v2
From: Arend Van Spriel @ 2019-05-13 9:21 UTC (permalink / raw)
To: Hans de Goede, Victor Bravo, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
David S. Miller, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, linux-kernel, Luis Chamberlain
In-Reply-To: <02a6dc11-7def-7d72-4640-d9d42ccec47c@redhat.com>
On 5/7/2019 5:38 PM, Hans de Goede wrote:
> Hi,
>
> On 06-05-19 21:30, Arend Van Spriel wrote:
>> + Luis (for real this time)
>>
>> On 5/6/2019 6:05 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 06-05-19 17:24, Victor Bravo wrote:
>>>> On Mon, May 06, 2019 at 03:26:28PM +0300, Kalle Valo wrote:
>>>>> Hans de Goede <hdegoede@redhat.com> writes:
>>>>>
>>>>>> If we're going to do some filtering, then I suggest we play it
>>>>>> safe and also
>>>>>> disallow other chars which may be used as a separator somewhere,
>>>>>> specifically
>>>>>> ':' and ','.
>>>>>>
>>>>>> Currently upstream linux-firmware has these files which rely on
>>>>>> the DMI
>>>>>> matching:
>>>>>>
>>>>>> brcmfmac4330-sdio.Prowise-PT301.txt
>>>>>> brcmfmac43430-sdio.Hampoo-D2D3_Vi8A1.txt
>>>>>> brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt
>>>>>>
>>>>>> The others are either part of the DMI override table for devices
>>>>>> with unsuitable
>>>>>> DMI strings like "Default String"; or are device-tree based.
>>>>>>
>>>>>> So as long as we don't break those 3 (or break the ONDA one but
>>>>>> get a symlink
>>>>>> in place) we can sanitize a bit more then just non-printable and '/'.
>>>>>>
>>>>>> Kalle, Arend, what is your opinion on this?
>>>>>>
>>>>>> Note I do not expect the ONDA V80 Plus to have a lot of Linux users,
>>>>>> but it definitely has some.
>>>>>
>>>>> To me having spaces in filenames is a bad idea, but on the other
>>>>> hand we
>>>>> do have the "don't break existing setups" rule, so it's not so
>>>>> simple. I
>>>>> vote for not allowing spaces, I think that's the best for the long
>>>>> run,
>>>>> but don't know what Arend thinks.
>>
>> Hi,
>>
>> Had a day off today so I did see some of the discussion, but was not
>> able to chime in until now.
>>
>> To be honest I always disliked spaces in filenames, but that does not
>> necessarily make it a bad idea. What I would like to know is why
>> built-in firmware can not deal with spaces in the firmware file names.
>> I think Hans mentioned it in the thread and it crossed my mind as well
>> last night. From driver perspective, being brcmfmac or any other for
>> that matter, there is only one API to request firmware and in my
>> opinion it should behave the same no matter where the firmware is
>> coming from. I would prefer to fix that for built-in firmware, but we
>> need to understand where this limitation is coming from. Hopefully
>> Luis can elaborate on that.
>
> Ok.
The issue is probably that make does simply split the EXTRA_FIRMWARE
setting at each space character. I tried to use single quote so
"'brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-T100HAN.txt'
brcmfmac43340-sdio.bin". No luck. So all I could think of is patch below
which require the user to enter a special sequence, ie. _-_ where space
should be.
"brcmfmac43340-sdio.ASUSTeK_-_COMPUTER_-_INC.-T100HAN.txt
brcmfmac43340-sdio.bin"
It works but I had to drop the dependency so it's all a bit hacky.
Regards,
Arend
diff --git a/firmware/Makefile b/firmware/Makefile
index 37e5ae387400..a536e5d12d5f 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -5,10 +5,11 @@
fwdir := $(subst $(quote),,$(CONFIG_EXTRA_FIRMWARE_DIR))
fwdir := $(addprefix $(srctree)/,$(filter-out /%,$(fwdir)))$(filter
/%,$(fwdir))
+fw_space_escape := _-_
obj-y := $(addsuffix .gen.o, $(subst $(quote),,$(CONFIG_EXTRA_FIRMWARE)))
-FWNAME = $(patsubst $(obj)/%.gen.S,%,$@)
-FWSTR = $(subst /,_,$(subst .,_,$(subst -,_,$(FWNAME))))
+FWNAME = $(subst $(fw_space_escape),$(space),$(patsubst
$(obj)/%.gen.S,%,$@))
+FWSTR = $(subst $(space),_,$(subst /,_,$(subst .,_,$(subst
-,_,$(FWNAME)))))
ASM_WORD = $(if $(CONFIG_64BIT),.quad,.long)
ASM_ALIGN = $(if $(CONFIG_64BIT),3,2)
PROGBITS = $(if $(CONFIG_ARM),%,@)progbits
@@ -34,7 +35,7 @@ $(obj)/%.gen.S: FORCE
$(call filechk,fwbin)
# The .o files depend on the binaries directly; the .S files don't.
-$(addprefix $(obj)/, $(obj-y)): $(obj)/%.gen.o: $(fwdir)/%
+$(addprefix $(obj)/, $(obj-y)): $(obj)/%.gen.o:
targets := $(patsubst $(obj)/%,%, \
$(shell find $(obj) -name \*.gen.S
2>/dev/null))
^ permalink raw reply related
* Re: [linux-nfc] ThinkPad T470 and NXP PN5xx (PN547 or PN548)
From: Sedat Dilek @ 2019-05-13 9:27 UTC (permalink / raw)
To: Oleg Zhurakivskyy
Cc: Samuel Ortiz, Andy Shevchenko, linux-wireless, linux-nfc
In-Reply-To: <06fbacb5-7739-1ca1-3bf4-8049a3ef019b@intel.com>
On Sat, May 11, 2019 at 3:28 PM Oleg Zhurakivskyy
<oleg.zhurakivskyy@intel.com> wrote:
>
>
> Hi Sedat,
>
> On 5/10/19 10:40 PM, Sedat Dilek wrote:
>
> > Can you guide me how to do that?
>
> I try and then decide whether this is help or not.
>
> If I remember correctly, support for PN547 was done by multiple parties for some Broadwell based designs through the upstream, both on the kernel and neard side.
>
> Assuming the integration details of PN547 didn’t deviate much, this might be:
>
> - From relatively simple, i.e. getting the relevant data from ACPI and hinting the kernel/driver with a minimally sufficient changes. Most likely, once you sort the basic details (i2c, gpio, etc), everything would just work.
>
> - To more laborious and would require a working and ideally open source reference. An option here might be Broadwell based Chromebooks with PN547 (just not sure whether plain or OEMs).
>
By cloning the driver from [1] which enhances the original driver [1]
with ACPI support and auto-detecting/auto-configuring the "NXP 1001"
device (see [1] and [2])...
...and using NXP's libnfc-nci...
configure-line: PREFIX="/opt/libnfc-nci" ; ./configure
--prefix="$PREFIX" --enable-i2c --enable-debug
...and enabling all available debug options in the provided *.conf
files in /usr/local/etc/...
...en plus I have activated all sort of I2C and GPIO debug kernel options...
...I was able to run the demo-app...
# /opt/libnfc-nci/sbin/nfcDemoApp poll 2>&1 | tee /tmp/nfcDemoApp-poll.txt
While in polling mode, I threw my YubiKey on the NFC device on my
Lenovo ThinkPad T470 and see...
NxpTml: PN54X - I2C Read successful.....
NxpNciR: len = 44 >
61052901020400FF010C4400072700000092D3490120000000121178B384008073C021C057597562694B6579
NxpTml: PN54X - Posting read message.....
NxpHal: read successful status = 0x0
NxpHal: NxpNci: RF Interface = ISO-DEP
NxpHal: NxpNci: Protocol = ISO-DEP
NxpHal: NxpNci: Mode = A Passive Poll
NxpFunc: NfcAdaptation::HalDeviceContextDataCallback: len=44
NxpFunc: NxpTml: PN54X - Read requested.....
Then I checked what the value...
HEX: 61052901020400FF010C4400072700000092D3490120000000121178B384008073C021C057597562694B6579
...means in ASCII...
$ cut -c 11- HEX.txt | xxd -r -p
�
D'��I x���s�!�WYubiKey
So, this seems to work.
I still have no glue how to use this experience in Linux to use NFC
and especially my YubiKey.
The binaries provided by Debian's libnfc-bin do not work.
Sorry to say, I still have not get all correlations...
- Sedat -
[0] https://github.com/nfc-tools/libnfc/issues/455
[1] https://github.com/NXPNFCLinux/nxp-pn5xx
[2] https://github.com/jr64/nxp-pn5xx
[3] https://github.com/NXPNFCLinux/nxp-pn5xx/issues/20
[4] https://github.com/NXPNFCLinux/linux_libnfc-nci
[5] https://www.rapidtables.com/convert/number/hex-to-ascii.html
[6] https://superuser.com/questions/244025/tool-to-convert-a-file-of-hex-to-ascii-character-set
^ permalink raw reply
* Re: [PATCH 3/4] mt76: mt76x2: move mutex_lock inside mt76x2_set_channel
From: Felix Fietkau @ 2019-05-13 9:30 UTC (permalink / raw)
To: Lorenzo Bianconi, Stanislaw Gruszka; +Cc: lorenzo.bianconi, linux-wireless
In-Reply-To: <20190513091905.GB3127@localhost.localdomain>
On 2019-05-13 11:19, Lorenzo Bianconi wrote:
>> On Sat, May 11, 2019 at 12:17:53PM +0200, Lorenzo Bianconi wrote:
>> > This is a preliminary patch to run mt76x02_edcca_init atomically
>> >
>> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>> > ---
>> > .../wireless/mediatek/mt76/mt76x2/pci_main.c | 16 ++++++++------
>> > .../wireless/mediatek/mt76/mt76x2/usb_main.c | 22 ++++++++++---------
>> > 2 files changed, 21 insertions(+), 17 deletions(-)
>> >
>> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
>> > index e416eee6a306..3a1467326f4d 100644
>> > --- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
>> > +++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
>> > @@ -54,14 +54,14 @@ mt76x2_set_channel(struct mt76x02_dev *dev, struct cfg80211_chan_def *chandef)
>> > int ret;
>> >
>> > cancel_delayed_work_sync(&dev->cal_work);
>>
>> Since now you use mutex in mt76x2_phy_calibrate() you can remove
>> cancel_delayed_work_sync() and drop other changes from this patch
>> as releasing mutex just to acquire it in almost next step make
>> no sense.
>
> I agree with you, the only difference is in that way we will perform phy
> calibration even during scanning. If the there are no
> objections I will post a v3 removing cancel_delayed_work_sync and
> reworking patch 3/4
I don't agree for two reasons:
1. If we only rely on the mutex, we're blocking the workqueue. That
might have some unwanted side effects.
2. We really should avoid having the calibration work during scanning,
otherwise this creates extra latency on channel changes, making the
whole scan slower.
- Felix
^ permalink raw reply
* Re: [PATCH 3/4] mt76: mt76x2: move mutex_lock inside mt76x2_set_channel
From: Stanislaw Gruszka @ 2019-05-13 9:41 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190513091905.GB3127@localhost.localdomain>
On Mon, May 13, 2019 at 11:19:06AM +0200, Lorenzo Bianconi wrote:
> > On Sat, May 11, 2019 at 12:17:53PM +0200, Lorenzo Bianconi wrote:
> > > This is a preliminary patch to run mt76x02_edcca_init atomically
> > >
> > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > ---
> > > .../wireless/mediatek/mt76/mt76x2/pci_main.c | 16 ++++++++------
> > > .../wireless/mediatek/mt76/mt76x2/usb_main.c | 22 ++++++++++---------
> > > 2 files changed, 21 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> > > index e416eee6a306..3a1467326f4d 100644
> > > --- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> > > +++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_main.c
> > > @@ -54,14 +54,14 @@ mt76x2_set_channel(struct mt76x02_dev *dev, struct cfg80211_chan_def *chandef)
> > > int ret;
> > >
> > > cancel_delayed_work_sync(&dev->cal_work);
> >
> > Since now you use mutex in mt76x2_phy_calibrate() you can remove
> > cancel_delayed_work_sync() and drop other changes from this patch
> > as releasing mutex just to acquire it in almost next step make
> > no sense.
>
> I agree with you, the only difference is in that way we will perform phy
> calibration even during scanning. If the there are no
> objections I will post a v3 removing cancel_delayed_work_sync and
> reworking patch 3/4
Oh, calibration work should not be done during scanning, so cancel
cal_work should be added to .sw_scan_start() callback or this patch
should stay unchanged.
Stanislaw
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Stanislaw Gruszka @ 2019-05-13 9:48 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190513084127.GA3127@localhost.localdomain>
On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> >
> > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > edcca processing
> > >
> > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> >
> > It's good to explain what edcca does and how the file is used supposed
> > to be used. In other words, have a small introduction for the user.
>
> Hi Kalle,
>
> edcca is used for adjusting energy detect based on CCA thresholds.
> The code was already there so I just reported the acronym.
What for it is needed ?
Stanislaw
^ permalink raw reply
* Re: [linux-nfc] ThinkPad T470 and NXP PN5xx (PN547 or PN548)
From: Andy Shevchenko @ 2019-05-13 9:50 UTC (permalink / raw)
To: Sedat Dilek; +Cc: Oleg Zhurakivskyy, Samuel Ortiz, linux-wireless, linux-nfc
In-Reply-To: <CA+icZUWJ0kZSqogg18LdP2YkNXk=_SNnT7-ufkd_Xp1ak7uchg@mail.gmail.com>
On Mon, May 13, 2019 at 11:27:07AM +0200, Sedat Dilek wrote:
> Sorry to say, I still have not get all correlations...
Can you provide the output of the following on running Linux system with latest
possible kernel you can install (I am expecting v5.1) and command line with
'ignore_loglevel'?
1. `dmesg`
2. `grep -H 15 /sys/bus/acpi/devices/*/status`
3. `acpidump -o t470-tables.dat` # the file t470-tables.dat
4. `lspci -vv -nk`
P.S. You may use GitHub gist for this set (please, don't share archives) or any
other resource like pastebin.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [linux-nfc] ThinkPad T470 and NXP PN5xx (PN547 or PN548)
From: Oleg Zhurakivskyy @ 2019-05-13 10:15 UTC (permalink / raw)
To: sedat.dilek; +Cc: Samuel Ortiz, Andy Shevchenko, linux-wireless, linux-nfc
In-Reply-To: <CA+icZUWJ0kZSqogg18LdP2YkNXk=_SNnT7-ufkd_Xp1ak7uchg@mail.gmail.com>
Hi Sedat,
On 5/13/19 12:27 PM, Sedat Dilek wrote:
> So, this seems to work.
I spent a bit of time trying to find T470, couldn’t, anyway managed to get to ”NXP 1001” and was going to hint you further.
Congratulations, great job!
And thanks a lot for documenting everything and posting it here. Perhaps, eventually it could be upstreamed.
Regards,
Oleg
^ permalink raw reply
* [PATCH v2] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Lorenzo Bianconi @ 2019-05-13 10:19 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless
In-Reply-To: <cover.1557739809.git.lorenzo@kernel.org>
Introduce a knob in mt7603 debugfs in order to enable/disable
energy detection based on CCA thresholds
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes since v1:
- fix file permission
---
.../wireless/mediatek/mt76/mt7603/debugfs.c | 30 +++++++++++++++++++
.../net/wireless/mediatek/mt76/mt7603/init.c | 4 ++-
.../net/wireless/mediatek/mt76/mt7603/main.c | 3 +-
.../wireless/mediatek/mt76/mt7603/mt7603.h | 6 +++-
4 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
index f8b3b6ab6297..9c0bea489e1f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
@@ -40,6 +40,35 @@ mt7603_radio_read(struct seq_file *s, void *data)
return 0;
}
+static int
+mt7603_edcca_set(void *data, u64 val)
+{
+ struct mt7603_dev *dev = data;
+
+ mutex_lock(&dev->mt76.mutex);
+
+ dev->ed_monitor_enabled = !!val;
+ dev->ed_monitor = dev->ed_monitor_enabled &&
+ dev->region == NL80211_DFS_ETSI;
+ mt7603_init_edcca(dev);
+
+ mutex_unlock(&dev->mt76.mutex);
+
+ return 0;
+}
+
+static int
+mt7603_edcca_get(void *data, u64 *val)
+{
+ struct mt7603_dev *dev = data;
+
+ *val = dev->ed_monitor_enabled;
+ return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(fops_edcca, mt7603_edcca_get,
+ mt7603_edcca_set, "%lld\n");
+
void mt7603_init_debugfs(struct mt7603_dev *dev)
{
struct dentry *dir;
@@ -48,6 +77,7 @@ void mt7603_init_debugfs(struct mt7603_dev *dev)
if (!dir)
return;
+ debugfs_create_file("edcca", 0600, dir, dev, &fops_edcca);
debugfs_create_u32("reset_test", 0600, dir, &dev->reset_test);
debugfs_create_devm_seqfile(dev->mt76.dev, "reset", dir,
mt7603_reset_read);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/init.c b/drivers/net/wireless/mediatek/mt76/mt7603/init.c
index 78cdbb70e178..4e269044f8a4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/init.c
@@ -437,7 +437,9 @@ mt7603_regd_notifier(struct wiphy *wiphy,
struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
struct mt7603_dev *dev = hw->priv;
- dev->ed_monitor = request->dfs_region == NL80211_DFS_ETSI;
+ dev->region = request->dfs_region;
+ dev->ed_monitor = dev->ed_monitor_enabled &&
+ dev->region == NL80211_DFS_ETSI;
}
static int
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/main.c b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
index 0a0334dc40d5..e931af92af43 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
@@ -103,8 +103,7 @@ mt7603_remove_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
mutex_unlock(&dev->mt76.mutex);
}
-static void
-mt7603_init_edcca(struct mt7603_dev *dev)
+void mt7603_init_edcca(struct mt7603_dev *dev)
{
/* Set lower signal level to -65dBm */
mt76_rmw_field(dev, MT_RXTD(8), MT_RXTD_8_LOWER_SIGNAL, 0x23);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h b/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
index fa64bbaab0d2..944dc9a11a15 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
@@ -117,8 +117,11 @@ struct mt7603_dev {
u8 mac_work_count;
u8 mcu_running;
- u8 ed_monitor;
+ enum nl80211_dfs_regions region;
+
+ u8 ed_monitor_enabled;
+ u8 ed_monitor;
s8 ed_trigger;
u8 ed_strict_mode;
u8 ed_strong_signal;
@@ -241,4 +244,5 @@ void mt7603_update_channel(struct mt76_dev *mdev);
void mt7603_edcca_set_strict(struct mt7603_dev *dev, bool val);
void mt7603_cca_stats_reset(struct mt7603_dev *dev);
+void mt7603_init_edcca(struct mt7603_dev *dev);
#endif
--
2.20.1
^ permalink raw reply related
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb
From: syzbot @ 2019-05-13 10:23 UTC (permalink / raw)
To: andreyknvl, chunkeey, davem, kvalo, linux-kernel, linux-usb,
linux-wireless, netdev, syzkaller-bugs
In-Reply-To: <000000000000050c5f0588363ad6@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 43151d6c usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=16b64110a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234
dashboard link: https://syzkaller.appspot.com/bug?extid=200d4bb11b23d929335f
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1634c900a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com
usb 1-1: config 0 descriptor??
usb 1-1: reset high-speed USB device number 2 using dummy_hcd
usb 1-1: device descriptor read/64, error -71
usb 1-1: Using ep0 maxpacket: 8
usb 1-1: Loading firmware file isl3887usb
usb 1-1: Direct firmware load for isl3887usb failed with error -2
usb 1-1: Firmware not found.
==================================================================
BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a
drivers/net/wireless/intersil/p54/p54usb.c:936
Read of size 8 at addr ffff88809803f588 by task kworker/1:0/17
CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 5.1.0-rc3-319004-g43151d6 #6
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events request_firmware_work_func
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xe8/0x16e lib/dump_stack.c:113
print_address_description+0x6c/0x236 mm/kasan/report.c:187
kasan_report.cold+0x1a/0x3c mm/kasan/report.c:317
p54u_load_firmware_cb.cold+0x97/0x13a
drivers/net/wireless/intersil/p54/p54usb.c:936
request_firmware_work_func+0x12d/0x249
drivers/base/firmware_loader/main.c:785
process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
kthread+0x313/0x420 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Allocated by task 0:
(stack is not available)
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff88809803f180
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 8 bytes to the right of
1024-byte region [ffff88809803f180, ffff88809803f580)
The buggy address belongs to the page:
page:ffffea0002600f00 count:1 mapcount:0 mapping:ffff88812c3f4a00 index:0x0
compound_mapcount: 0
flags: 0xfff00000010200(slab|head)
raw: 00fff00000010200 dead000000000100 dead000000000200 ffff88812c3f4a00
raw: 0000000000000000 00000000800e000e 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88809803f480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88809803f500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88809803f580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff88809803f600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88809803f680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
^ permalink raw reply
* [PATCH] mt76: mt76x02: fix edcca file permission
From: Lorenzo Bianconi @ 2019-05-13 10:23 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka
In-Reply-To: <cover.1557742856.git.lorenzo@kernel.org>
Use 0600 as edcca file permission in mt76x02 debugfs
Fixes: 643749d4a82b ("mt76: mt76x02: disable ED/CCA by default")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c b/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
index f412c779d8e2..ffdba5ffc22d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
@@ -157,7 +157,7 @@ void mt76x02_init_debugfs(struct mt76x02_dev *dev)
debugfs_create_u8("temperature", 0400, dir, &dev->cal.temp);
debugfs_create_bool("tpc", 0600, dir, &dev->enable_tpc);
- debugfs_create_file("edcca", 0400, dir, dev, &fops_edcca);
+ debugfs_create_file("edcca", 0600, dir, dev, &fops_edcca);
debugfs_create_file("ampdu_stat", 0400, dir, dev, &fops_ampdu_stat);
debugfs_create_file("dfs_stats", 0400, dir, dev, &fops_dfs_stat);
debugfs_create_devm_seqfile(dev->mt76.dev, "txpower", dir,
--
2.20.1
^ permalink raw reply related
* [PATCH v2 01/12] NFC: nxp-nci: Add NXP1001 to the ACPI ID table
From: Andy Shevchenko @ 2019-05-13 10:43 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless, Sedat Dilek, Oleg Zhurakivskyy
Cc: Andy Shevchenko
In-Reply-To: <20190513104358.59716-1-andriy.shevchenko@linux.intel.com>
It seems a lot of laptops are equipped with NXP NFC300 chip with
the ACPI ID NXP1001 as per DSDT.
Append it to the driver's ACPI ID table.
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/nfc/nxp-nci/i2c.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index ba695e392c3b..fec904ad624b 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -407,6 +407,7 @@ MODULE_DEVICE_TABLE(of, of_nxp_nci_i2c_match);
#ifdef CONFIG_ACPI
static struct acpi_device_id acpi_id[] = {
+ { "NXP1001" },
{ "NXP7471" },
{ },
};
--
2.20.1
^ permalink raw reply related
* [PATCH v2 04/12] NFC: nxp-nci: Add GPIO ACPI mapping table
From: Andy Shevchenko @ 2019-05-13 10:43 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless, Sedat Dilek, Oleg Zhurakivskyy
Cc: Andy Shevchenko
In-Reply-To: <20190513104358.59716-1-andriy.shevchenko@linux.intel.com>
In order to unify GPIO resource request prepare gpiod_get_index()
to behave correctly when there is no mapping provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/nfc/nxp-nci/i2c.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 6f61368ae065..9a65dd6cd405 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -258,6 +258,15 @@ static irqreturn_t nxp_nci_i2c_irq_thread_fn(int irq, void *phy_id)
return IRQ_NONE;
}
+static const struct acpi_gpio_params firmware_gpios = { 1, 0, false };
+static const struct acpi_gpio_params enable_gpios = { 2, 0, false };
+
+static const struct acpi_gpio_mapping acpi_nxp_nci_gpios[] = {
+ { "enable-gpios", &enable_gpios, 1 },
+ { "firmware-gpios", &firmware_gpios, 1 },
+ { }
+};
+
static int nxp_nci_i2c_parse_devtree(struct i2c_client *client)
{
struct nxp_nci_i2c_phy *phy = i2c_get_clientdata(client);
@@ -280,9 +289,14 @@ static int nxp_nci_i2c_parse_devtree(struct i2c_client *client)
static int nxp_nci_i2c_acpi_config(struct nxp_nci_i2c_phy *phy)
{
struct i2c_client *client = phy->i2c_dev;
+ int r;
- phy->gpiod_en = devm_gpiod_get_index(&client->dev, NULL, 2, GPIOD_OUT_LOW);
- phy->gpiod_fw = devm_gpiod_get_index(&client->dev, NULL, 1, GPIOD_OUT_LOW);
+ r = devm_acpi_dev_add_driver_gpios(&client->dev, acpi_nxp_nci_gpios);
+ if (r)
+ return r;
+
+ phy->gpiod_en = devm_gpiod_get(&client->dev, "enable", GPIOD_OUT_LOW);
+ phy->gpiod_fw = devm_gpiod_get(&client->dev, "firmware", GPIOD_OUT_LOW);
if (IS_ERR(phy->gpiod_en) || IS_ERR(phy->gpiod_fw)) {
nfc_err(&client->dev, "No GPIOs\n");
--
2.20.1
^ permalink raw reply related
* [PATCH v2 03/12] NFC: nxp-nci: Convert to use GPIO descriptor
From: Andy Shevchenko @ 2019-05-13 10:43 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless, Sedat Dilek, Oleg Zhurakivskyy
Cc: Andy Shevchenko
In-Reply-To: <20190513104358.59716-1-andriy.shevchenko@linux.intel.com>
Since we got rid of platform data, the driver may use
GPIO descriptor directly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/nfc/nxp-nci/core.c | 1 -
drivers/nfc/nxp-nci/i2c.c | 60 ++++++++++----------------------------
2 files changed, 15 insertions(+), 46 deletions(-)
diff --git a/drivers/nfc/nxp-nci/core.c b/drivers/nfc/nxp-nci/core.c
index 1907b1fd57a7..b0b6db81a5e8 100644
--- a/drivers/nfc/nxp-nci/core.c
+++ b/drivers/nfc/nxp-nci/core.c
@@ -22,7 +22,6 @@
*/
#include <linux/delay.h>
-#include <linux/gpio.h>
#include <linux/module.h>
#include <linux/nfc.h>
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 549e09deb92f..6f61368ae065 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -32,8 +32,6 @@
#include <linux/module.h>
#include <linux/nfc.h>
#include <linux/gpio/consumer.h>
-#include <linux/of_gpio.h>
-#include <linux/of_irq.h>
#include <asm/unaligned.h>
#include <net/nfc/nfc.h>
@@ -48,8 +46,8 @@ struct nxp_nci_i2c_phy {
struct i2c_client *i2c_dev;
struct nci_dev *ndev;
- unsigned int gpio_en;
- unsigned int gpio_fw;
+ struct gpio_desc *gpiod_en;
+ struct gpio_desc *gpiod_fw;
int hard_fault; /*
* < 0 if hardware error occurred (e.g. i2c err)
@@ -62,8 +60,8 @@ static int nxp_nci_i2c_set_mode(void *phy_id,
{
struct nxp_nci_i2c_phy *phy = (struct nxp_nci_i2c_phy *) phy_id;
- gpio_set_value(phy->gpio_fw, (mode == NXP_NCI_MODE_FW) ? 1 : 0);
- gpio_set_value(phy->gpio_en, (mode != NXP_NCI_MODE_COLD) ? 1 : 0);
+ gpiod_set_value(phy->gpiod_fw, (mode == NXP_NCI_MODE_FW) ? 1 : 0);
+ gpiod_set_value(phy->gpiod_en, (mode != NXP_NCI_MODE_COLD) ? 1 : 0);
usleep_range(10000, 15000);
if (mode == NXP_NCI_MODE_COLD)
@@ -263,30 +261,18 @@ static irqreturn_t nxp_nci_i2c_irq_thread_fn(int irq, void *phy_id)
static int nxp_nci_i2c_parse_devtree(struct i2c_client *client)
{
struct nxp_nci_i2c_phy *phy = i2c_get_clientdata(client);
- struct device_node *pp;
- int r;
-
- pp = client->dev.of_node;
- if (!pp)
- return -ENODEV;
- r = of_get_named_gpio(pp, "enable-gpios", 0);
- if (r == -EPROBE_DEFER)
- r = of_get_named_gpio(pp, "enable-gpios", 0);
- if (r < 0) {
- nfc_err(&client->dev, "Failed to get EN gpio, error: %d\n", r);
- return r;
+ phy->gpiod_en = devm_gpiod_get(&client->dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(phy->gpiod_en)) {
+ nfc_err(&client->dev, "Failed to get EN gpio\n");
+ return PTR_ERR(phy->gpiod_en);
}
- phy->gpio_en = r;
- r = of_get_named_gpio(pp, "firmware-gpios", 0);
- if (r == -EPROBE_DEFER)
- r = of_get_named_gpio(pp, "firmware-gpios", 0);
- if (r < 0) {
- nfc_err(&client->dev, "Failed to get FW gpio, error: %d\n", r);
- return r;
+ phy->gpiod_fw = devm_gpiod_get(&client->dev, "firmware", GPIOD_OUT_LOW);
+ if (IS_ERR(phy->gpiod_fw)) {
+ nfc_err(&client->dev, "Failed to get FW gpio\n");
+ return PTR_ERR(phy->gpiod_fw);
}
- phy->gpio_fw = r;
return 0;
}
@@ -294,19 +280,15 @@ static int nxp_nci_i2c_parse_devtree(struct i2c_client *client)
static int nxp_nci_i2c_acpi_config(struct nxp_nci_i2c_phy *phy)
{
struct i2c_client *client = phy->i2c_dev;
- struct gpio_desc *gpiod_en, *gpiod_fw;
- gpiod_en = devm_gpiod_get_index(&client->dev, NULL, 2, GPIOD_OUT_LOW);
- gpiod_fw = devm_gpiod_get_index(&client->dev, NULL, 1, GPIOD_OUT_LOW);
+ phy->gpiod_en = devm_gpiod_get_index(&client->dev, NULL, 2, GPIOD_OUT_LOW);
+ phy->gpiod_fw = devm_gpiod_get_index(&client->dev, NULL, 1, GPIOD_OUT_LOW);
- if (IS_ERR(gpiod_en) || IS_ERR(gpiod_fw)) {
+ if (IS_ERR(phy->gpiod_en) || IS_ERR(phy->gpiod_fw)) {
nfc_err(&client->dev, "No GPIOs\n");
return -EINVAL;
}
- phy->gpio_en = desc_to_gpio(gpiod_en);
- phy->gpio_fw = desc_to_gpio(gpiod_fw);
-
return 0;
}
@@ -342,24 +324,12 @@ static int nxp_nci_i2c_probe(struct i2c_client *client,
r = nxp_nci_i2c_acpi_config(phy);
if (r < 0)
goto probe_exit;
- goto nci_probe;
} else {
nfc_err(&client->dev, "No platform data\n");
r = -EINVAL;
goto probe_exit;
}
- r = devm_gpio_request_one(&phy->i2c_dev->dev, phy->gpio_en,
- GPIOF_OUT_INIT_LOW, "nxp_nci_en");
- if (r < 0)
- goto probe_exit;
-
- r = devm_gpio_request_one(&phy->i2c_dev->dev, phy->gpio_fw,
- GPIOF_OUT_INIT_LOW, "nxp_nci_fw");
- if (r < 0)
- goto probe_exit;
-
-nci_probe:
r = nxp_nci_probe(phy, &client->dev, &i2c_phy_ops,
NXP_NCI_I2C_MAX_PAYLOAD, &phy->ndev);
if (r < 0)
--
2.20.1
^ permalink raw reply related
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