.
Signed-off-by: David Gnedt <david.gn...@davizone.at>
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
I'm resending this patch for review again as after two years there is no
nl80211 interface for bt coex and wl1251 on Nokia N900 needs it. Once
there will be common interface for b
ret = get_vendor_mac_passthru_addr(tp, );
You do not "get" (return) any mac address. Personally I would use "read"
word in function name (like above pla_ocp_read). What about?
ret = vendor_mac_passthru_addr_read(tp, sa.sa_data);
Or something similar... "Get" looks like function "get" something, but
instead it set address in structure.
> + if (ret < 0)
> + ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
> + }
>
> if (ret < 0) {
> netif_err(tp, probe, dev, "Get ether addr fail\n");
--
Pali Rohár
pali.ro...@gmail.com
On Tuesday 14 June 2016 18:40:17 Greg KH wrote:
> On Tue, Jun 14, 2016 at 06:28:10PM +0200, Pali Rohár wrote:
> > On Saturday 11 June 2016 19:42:26 David Miller wrote:
> > > From: Andrew Lunn <and...@lunn.ch>
> > > Date: Sat, 11 Jun 2016 17:39:21 +0200
> >
ddress for both those cards. But those addresses
are same. What will linux kernel do in this case?
This is very similar situation as those Dell usb network cards told us
"hey, use address which is in ACPI DSDT table".
Either we should trust what network card what told us, or not and then
"Invalid MAC when reading pass-thru MAC addr: "
> +"%pM\n",
> +buf);
> + goto amacout;
> + }
In case when hex2bin returns zero, but is_valid_ether_addr returns
false, this function returns
ry leak, you allocated buffer with ACPI_ALLOCATE_BUFFER
but you did not free it.
> +}
And my last question is: Are really all Dell docks comes with this one
realtek chip? I'm pessimist in this, because I see how other components
(like HDD vendor, touchpad type, smardcard chips, motherboards, display
panels, wifi chips) can be different in two laptops of same Dell model.
--
Pali Rohár
pali.ro...@gmail.com
h is chosen then I think there are only two solution
those satisfy above conditions:
First one is:
* all non-Dell devices have own MAC address
* all Dell devices have (one, same) AUX MAC address
Second one is:
* all devices (Dell and also non-Dell) have own address
* AUX MAC address is never used
So what do you (netdev maintainers) think about it?
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
your users have some chance to
> > implement a sensible policy based on e.g. usb port numbers.
>
> OK, if I can't come up with a way to key on the device being a Dell
> dock I'll scrap this entirely kernel approach.
E.g. PCI devices have ordinary PCI device & vendor IDs, but have Dell
specific subsystem IDs. And via subsystem IDs we can distinguish between
Intel graphics card on Dell laptop and on non-Dell laptop.
Does not you have some special/modified firmware in those Dell realtek
docks (and ability to check from OS some registers)?
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
On Thursday 21 January 2016 15:48:14 Kalle Valo wrote:
> Pali Rohár <pali.ro...@gmail.com> writes:
>
> > On Thursday 14 January 2016 10:16:54 Pavel Machek wrote:
> >> On Wed 2016-01-13 23:32:47, Arend van Spriel wrote:
> >> > On 12/26/2015 12:45 PM, Pali Roh
On Thursday 14 January 2016 10:16:54 Pavel Machek wrote:
> On Wed 2016-01-13 23:32:47, Arend van Spriel wrote:
> > On 12/26/2015 12:45 PM, Pali Rohár wrote:
> > >Port the bt_coex_mode sysfs interface from wl1251 driver version included
> > >in the Maemo Fremantle ker
On Thursday 21 January 2016 16:44:33 Kalle Valo wrote:
> Pali Rohár <pali.ro...@gmail.com> writes:
>
> > On Thursday 21 January 2016 15:48:14 Kalle Valo wrote:
> >> Pali Rohár <pali.ro...@gmail.com> writes:
> >>
> >> > On Thursday 14 January
n in userspace just via packet
injection radiotap (which is supported by wl1251).
So maybe using other firmware (filter) commands together with current
packet injection implementation could be possible to create AP mode
(usable for standard hostapd daemon)? Just thinking...
Anyway, other TI wilink
On Wednesday 06 April 2016 13:30:22 Machani, Yaniv wrote:
> On Mon, Apr 04, 2016 at 15:39:44, Pali Rohár wrote:
> > > In linux-firmware repository [1] is missing AP firmware for TI
> > > wl1251 chip. There is only STA firmware wl1251-fw.bin which
> > > sup
On Monday 21 March 2016 12:35:32 Kalle Valo wrote:
> Pali Rohár <pali.ro...@gmail.com> writes:
>
> > In linux-firmware repository [1] is missing AP firmware for TI wl1251
> > chip. There is only STA firmware wl1251-fw.bin which supports managed
> > and ad-hoc mode
this pull request [2].
[1] -
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ti-connectivity
[2] - http://thread.gmane.org/gmane.linux.kernel/1566500/focus=1571382
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
On Sunday 20 March 2016 00:40:25 Pali Rohár wrote:
> Hi!
>
> In linux-firmware repository [1] is missing AP firmware for TI wl1251
> chip. There is only STA firmware wl1251-fw.bin which supports managed
> and ad-hoc modes.
>
> For other TI wilink chips there are -
On Tuesday 31 January 2017 07:59:18 Tony Lindgren wrote:
> * Kalle Valo <kv...@codeaurora.org> [170130 22:36]:
> > Tony Lindgren <t...@atomide.com> writes:
> >
> > > * Pavel Machek <pa...@ucw.cz> [170127 11:41]:
> > >> On Fri 2017-01-27 17
On Monday 30 January 2017 18:53:09 Tony Lindgren wrote:
> * Pavel Machek <pa...@ucw.cz> [170127 11:41]:
> > On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
> > > Pali Rohár <pali.ro...@gmail.com> writes:
> > > > On Friday 27 January 2017 14:26:22 Kall
On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> Pali Rohár <pali.ro...@gmail.com> writes:
>
> > NVS calibration data for wl1251 are model specific. Every one device with
> > wl1251 chip has different and calibrated in factory.
> >
> > Not al
On Friday 27 January 2017 09:56:09 Kalle Valo wrote:
> Pali Rohár <pali.ro...@gmail.com> writes:
>
> > In case there is no valid MAC address kernel generates random one. This
> > patch propagate this generated MAC address back to NVS data which will be
> > upload
On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
> On 27-1-2017 10:43, Pali Rohár wrote:
> > On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> >> Pali Rohár <pali.ro...@gmail.com> writes:
> >>
> >>> NVS calibration data fo
On Friday 27 January 2017 11:19:25 Arend Van Spriel wrote:
> On 27-1-2017 11:10, Pali Rohár wrote:
> > On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
> >> On 27-1-2017 10:43, Pali Rohár wrote:
> >>> On Friday 27 January 2017 09:33:40 Kalle Valo wro
On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> Pali Rohár <pali.ro...@gmail.com> writes:
>
> >> So
> >> for those other platforms there will be a delay waiting for user-mode
> >> helper to fail, before trying to get n
On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> Pali Rohár <pali.ro...@gmail.com> writes:
>
> > On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> >> Pali Rohár <pali.ro...@gmail.com> writes:
> >>
> >> >> So
> >> >&g
On Friday 27 January 2017 13:53:28 Arend Van Spriel wrote:
> On 27-1-2017 13:26, Kalle Valo wrote:
> > Pali Rohár <pali.ro...@gmail.com> writes:
> >
> >> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> >>> Pali Rohár <pali.ro...@gmail.com>
On Friday 27 January 2017 17:23:07 Kalle Valo wrote:
> Pali Rohár <pali.ro...@gmail.com> writes:
>
> > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> >> Pali Rohár <pali.ro...@gmail.com> writes:
> >>
> >> > 2) It was already
orary address and it is ioctl. IIRC same as what ethtool
uses. (ifconfig is already deprecated).
> And I guess we should use similar mechanism for permanent
> address.
I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac
address. But here we do not want to change permane
On Thursday 24 November 2016 19:46:01 Aaro Koskinen wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > Proprietary, signed and closed bootloader NOLO does not support DT.
> > So for booting you need to append DTS file to kernel image.
> &
On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote:
> On 21 November 2016 at 16:51, Pali Rohár <pali.ro...@gmail.com> wrote:
> > On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
> >> Hi! I will open discussion about mac address and calibration data for
> &g
On Tuesday 22 November 2016 17:14:28 Michal Kazior wrote:
> On 22 November 2016 at 16:31, Pali Rohár <pali.ro...@gmail.com> wrote:
> > On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote:
> >> On 21 November 2016 at 16:51, Pali Rohár <pali.ro...@gmail.com>
&
ave
permanent mac address assigned.
We should assign permanent mac address before wlan0 of wl1251 is
registered into system.
--
Pali Rohár
pali.ro...@gmail.com
On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > Hi!
> > >
> > > > > "ifconfig h
On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> &g
On Thursday 24 November 2016 19:11:39 Sebastian Reichel wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> > > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> &g
e again stored
in proprietary format and I can write userspace parser for it.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
> Hi! I will open discussion about mac address and calibration data for
> wl1251 wireless chip again...
>
> Problem: Mac address & calibration data for wl1251 chip on Nokia N900
> are stored on second nand partitio
On Thu Dec 15 09:18:44 2016 Kalle Valo <kv...@codeaurora.org> wrote:
> (Adding Luis because he has been working on request_firmware() lately)
>
> Pali Rohár <pali.ro...@gmail.com> writes:
>
> > > > So no, there is no argument against... request_firmware() in
On Sunday 18 December 2016 12:54:00 Arend Van Spriel wrote:
> On 18-12-2016 12:04, Pali Rohár wrote:
> > On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
> >> On 16-12-2016 11:40, Pali Rohár wrote:
> >>> On Friday 16 December 2016 08:25:44 Daniel Wagner wro
On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
> On 16-12-2016 11:40, Pali Rohár wrote:
> > On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
> >> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
> >>> For the new API a solution for "fallbac
VAL;
>
> You have two copies of these. Does it make sense to move it to helper
> function?
I'm thinking if checks is really needed. But probably moving it to
separate function is good idea.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
-firmware repository and
contains MAC address 00:00:20:07:03:09. So this MAC address is marked as
invalid as it is not real device specific address, just example one.
Format of calibration NVS data can be found at:
http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt
Signed-off-by: Pali Rohár <pali
Nokia key/value format for nand
devices.
With this patch it is finally possible to load correct model specific NVS
calibration data for Nokia N900.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
drivers/net/wireless/ti/wl1251/Kconfig |1 +
drivers/net/wireless/ti/wl1251/main.c |
This function works pretty much like request_firmware(), but it prefer
usermode helper. If usermode helper fails then it fallback to direct
access. Useful for dynamic or model specific firmware data.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
drivers/base/firmware_class.c
In case kmemdup fails thne wl->nvs_len will contains invalid non-zero size.
This patch fixes it.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
drivers/net/wireless/ti/wl1251/main.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/
This patch series fix processing MAC address for wl1251 chip found in Nokia
N900.
Pali Rohár (6):
firmware: Add request_firmware_prefer_user() function
wl1251: Use request_firmware_prefer_user() for loading NVS
calibration data
wl1251: Update wl->nvs_len after wl->nvs is valid
address.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
drivers/net/wireless/ti/wl1251/main.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/main.c
b/drivers/net/wireless/ti/wl1251/main.c
index 8971b64..c
In case there is no valid MAC address kernel generates random one. This
patch propagate this generated MAC address back to NVS data which will be
uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
uses.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
drive
On Sunday 25 December 2016 21:15:40 Arend Van Spriel wrote:
> On 24-12-2016 17:52, Pali Rohár wrote:
> > NVS calibration data for wl1251 are model specific. Every one
> > device with wl1251 chip has different and calibrated in factory.
> >
> > Not all wl1251
On Saturday 24 December 2016 19:08:54 Pavel Machek wrote:
> On Sat 2016-12-24 17:52:59, Pali Rohár wrote:
> > Before this patch driver generated random MAC address every time
> > when was doing initialization. And after that random MAC address
> > could be overwritten with
On Saturday 24 December 2016 19:14:21 Pavel Machek wrote:
> On Sat 2016-12-24 17:53:00, Pali Rohár wrote:
> > @@ -1581,10 +1598,16 @@ int wl1251_init_ieee80211(struct wl1251
> > *wl)
> >
> > wl->hw->queues = 4;
> >
> > + if (wl->nvs =
251, but for instance have no
> > > userspace helper the request to userspace will fail (after 60
> > > sec?) and try VFS after that. Maybe not so nice.
> >
> > Currently support for those devices is broken (like for N900) as
> > without proper NVS data they do not work correctly...
>
> Is it expected to work at all, perhaps with degraded performance /
> range? Because it seems to work for me.
Yes, some degraded performance or problems with connecting is expected.
And random MAC address at every boot. Plus some regulatory problems in
FCC countries.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
On Friday 16 December 2016 03:03:19 Luis R. Rodriguez wrote:
> On Thu, Dec 15, 2016 at 2:12 PM, Arend Van Spriel
>
> <arend.vanspr...@broadcom.com> wrote:
> > On 15-12-2016 16:33, Pali Rohár wrote:
> >> On Thu Dec 15 09:18:44 2016 Kalle Valo <kv...@codeaurora.or
On Thursday 15 December 2016 21:12:47 Arend Van Spriel wrote:
> On 15-12-2016 16:33, Pali Rohár wrote:
> > On Thu Dec 15 09:18:44 2016 Kalle Valo <kv...@codeaurora.org> wrote:
> >> (Adding Luis because he has been working on request_firmware()
> >> latel
on for this project is the get movement back in
> stuck discussion on the firmware loader API. Luis was very busy
> writing up all the details on the current situation and purely from
> the amount of documentation need to describe the API you can tell
> something is awry.
>
> Thanks,
> Daniel
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
On Tuesday 20 December 2016 17:56:58 Tony Lindgren wrote:
> * Kalle Valo <kv...@codeaurora.org> [161220 03:47]:
> > Arend Van Spriel <arend.vanspr...@broadcom.com> writes:
> > > On 18-12-2016 13:09, Pali Rohár wrote:
> > >> File wl1251-nvs
ld generate some (random?).
So kernel driver should get NVS calibration data from userspace (which
know how where to get or how to prepare them) and in case userspace do
not have it, then we can try fallback to those example data (as people
reported us they can be useful instead of non-working WIFI
On Wednesday 17 May 2017 15:04:50 Johannes Berg wrote:
> On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
>
> > > In fact, why should the *driver* care either? IOW - why should
> > > "request_firmware_prefer_user()" even exist?
> >
> > There
On Friday 10 November 2017 21:26:01 Luis R. Rodriguez wrote:
> On Fri, Nov 10, 2017 at 12:38:27AM +0100, Pali Rohár wrote:
> > This function works pretty much like request_firmware(), but it prefer
> > usermode helper. If usermode helper fails then it fallback to direct
>
of patches as Pavel requested
Pali Rohár (6):
wl1251: Update wl->nvs_len after wl->nvs is valid
wl1251: Generate random MAC address only if driver does not have
valid
wl1251: Parse and use MAC address from supplied NVS data
wl1251: Set generated MAC address back to NVS data
firmwar
.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
Acked-by: Pavel Machek <pa...@ucw.cz>
---
drivers/net/wireless/ti/wl1251/main.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/main.c
b/drivers/net/wirele
-firmware repository,
contains MAC address 00:00:20:07:03:09. So this MAC address is marked as
invalid as it is not real device specific address, just example one.
Format of calibration NVS data can be found at:
http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt
Signed-off-by: Pali Rohár <pali
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
drivers/net/wireless/ti/wl1251/Kconfig |1 +
drivers/net/wireless/ti/wl1251/main.c |2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wl1251/Kconfig
b/drivers/net/wireless/ti/wl1251/Kconfig
index
This function works pretty much like request_firmware(), but it prefer
usermode helper. If usermode helper fails then it fallback to direct
access. Useful for dynamic or model specific firmware data.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
drivers/base/firmware_class.c
wl1251
correct mac address since beginning of chip usage.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
drivers/net/wireless/ti/wl1251/main.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/net/wireless/ti/wl1251/main.c
b/drivers/net/wireless/ti/wl1251/
If kmemdup fails, then wl->nvs_len will contain invalid non-zero size.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
Acked-by: Pavel Machek <pa...@ucw.cz>
---
drivers/net/wireless/ti/wl1251/main.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drive
Multicast Routing Daemon using only IGMP
signalling. It's intended for simple forwarding of Multicast traffic
between networks.
--
Pali Rohár
pali.ro...@gmail.com
On Friday 05 January 2018 02:45:10 Luis R. Rodriguez wrote:
> On Tue, Jan 02, 2018 at 08:23:45PM +0100, Pali Rohár wrote:
> > On Friday 10 November 2017 00:38:22 Pali Rohár wrote:
> > > This patch series fix processing MAC address for wl1251 chip found in
> > > Nokia
Hello, new version 0.2.1 of igmpproxy was released which fixes
compilation on FreeBSD systems and also fixes broken option -n.
It is just a minor version to address these problems.
https://github.com/pali/igmpproxy/releases/tag/0.2.1
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
On Friday 10 November 2017 00:38:22 Pali Rohár wrote:
> This patch series fix processing MAC address for wl1251 chip found in Nokia
> N900.
>
> Changes since v1:
> * Added Acked-by for Pavel Machek
> * Fixed grammar
> * Magic numbers for NVS offsets are replaced by defines
&
69 matches
Mail list logo
