The memory pointed to by ns can be reallocated when checking mft records
Signed-off-by: Yousong Zhou
---
libblkid-tiny/ntfs.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libblkid-tiny/ntfs.c b/libblkid-tiny/ntfs.c
index 3a9d5cb..dfe22e2 100644
--- a/libblkid-ti
- CMIIT ID: 2019AP2581
- SoC: MediaTek MT7621
- Flash:16MiB NOR SPI (GigaDevice GD25Q128B)
- RAM: 128MiB DDR3 (ESMT M15T1G1664A)
- Serial: As marked on PCB, 3V3 logic, baudrate is 115200, 8n1
- Ethernet: 3x 10/100/1000 Mbps (switched, 2xLAN + WAN)
- WIFI0:MT7603E 2.4GHz 802.11b/
Hi,
On Sat, Aug 31, 2019 at 11:32:33PM +0200, m...@adrianschmutzler.de wrote:
> > + xiaomi,mir3g-v2)
> > + ucidef_add_switch "switch0" \
> > + "2:lan:2" "3:lan:1" "4:wan" "6t@eth0"
> > + ;;
>
> "6t@eth0" and "6@eth0" should be the same, so this can be merge
Hi Roger,
Thank you for the review!
On Fri, Oct 11, 2019 at 07:14:25PM +0200, Roger Pueyo Centelles | Guifi.net
wrote:
> + xiaomi,mir3g-v2)
> + wan_mac=$(mtd_get_mac_binary factory 0xe006)
> + ;;
>
> You may want to add "label_mac=$wan_mac" there, if the MAC
Hi,
> + led_power: power {
> + label = "rt-ac85p:blue:power";
> + gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy0tpt";
> + };
just found this, set for RT-AC65P and RT-AC85P. Any reason why th
The memory pointed to by ns can be reallocated when checking mft records
Fixes FS#2129
Signed-off-by: Yousong Zhou
---
v2 <- v1
-Fix bad DBG() call in previous patch missing volume_serial as arg
libblkid-tiny/ntfs.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --g
Dosfsck is only available when --enable-compat-symlinks was given when
configuring dosfstools. These symlinks are not enabled in OpenWrt
dosfstools package
Suggested by Reiner Otto in FS#2408
Signed-off-by: Yousong Zhou
---
block.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
dif
Hi,
> > > + xiaomi,mir3g-v2)
> > > + wan_mac=$(mtd_get_mac_binary factory 0xe006)
> > > + ;;
> >
> > This can be merged with elecom,wrc-1167ghbk2-s|\ etc.
>
> I rebased to current master and added label_mac (as per Roger's
> suggestion), and since I can not be sure about all the o
Hi,
> + partition@5 {
> + compatible = "denx,uimage";
> + label = "firmware";
> + reg = <0x05 0xF5>;
I'd prefer lower-case for the address (and for consistency with your other
defi
For several devices, wmac MAC address is set from art 0x1002
explicitly by using mtd-mac-address although mtd-cal-data is
pulled from art 0x1000.
With the MAC address in 0x1002, the driver should automatically
use it when reading caldata from 0x1000. Thus, remove the
redundant mtd-mac-address for
In mt7628an.dtsi, calibration data for wmac is already defined:
mediatek,mtd-eeprom = <&factory 0x0>;
Thus, this patch removes redundant entries of this property in
derived DTS files.
Signed-off-by: Adrian Schmutzler
---
Question:
While this is mediatek, several DTS files contained
ralink,mtd-
When caldata locations are defined with mediatek,mtd-eeprom the
MAC address is automatically read from offset +4. Thus, specifying
that location explicitly is redundant.
This patch removes those redundant definitions.
Signed-off-by: Adrian Schmutzler
---
Not tested on device.
---
target/linux
Dear all, dear John,
I have an issue with tmpfs on zram: according to this remark:
https://git.openwrt.org/?p=project/procd.git;a=commitdiff;h=7676df3226da5391c2dfda2ed29a40500e04e15b
Nathan (incl. in CC of this email) has a hardcoded value for zram0 for tmp.
With inreasing RAM sizes for
No. I think this is a bug.
Birger
On 25 October 2019 12:26:34 CEST, Adrian Schmutzler
wrote:
>Hi,
>
>> +led_power: power {
>> +label = "rt-ac85p:blue:power";
>> +gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
>> +linux,default-trigge
On 25/10/2019 14:08, alex1...@gmx.net wrote:
Dear all, dear John,
I have an issue with tmpfs on zram: according to this remark:
https://git.openwrt.org/?p=project/procd.git;a=commitdiff;h=7676df3226da5391c2dfda2ed29a40500e04e15b
Nathan (incl. in CC of this email) has a hardcoded value for zram
This patch removes a phy0tpt trigger from the power LED, which
seems to have been added by mistake.
WiFi LEDs using phy0radio and phy1radio triggers are present and
used correctly.
Cc: Birger Koblitz
Signed-off-by: Adrian Schmutzler
---
target/linux/ramips/dts/mt7621_asus_rt-acx5p.dtsi | 1 -
> Adrian Schmutzler wrote:
> > For several devices, wmac MAC address is set from art 0x1002
> > explicitly by using mtd-mac-address although mtd-cal-data is
> > pulled from art 0x1000.
> >
> > With the MAC address in 0x1002, the driver should automatically
> > use it when reading caldata fro
On 10/25/19 4:38 AM, Adrian Schmutzler wrote:
For several devices, wmac MAC address is set from art 0x1002
explicitly by using mtd-mac-address although mtd-cal-data is
pulled from art 0x1000.
With the MAC address in 0x1002, the driver should automatically
use it when reading caldata from 0x1000
Hi,
I wanted to check if you'd be interested in procuring records of
Radiologists?
If you are interested let me know your target geography so, that I can
revert with counts and pricing.
Awaiting for your quick response.
Regards,
Amber Burns
Marketing Manager
If you do not wis
Hello,
thank you for reviewing. I just changed the address and ART-Label to
lowercase in my source => fixed.
### Regarding the cal-data of the pcie-wifi (AR9382):
It seems to me it has some kind of EEPROM, from OEM-BootLog:
wmac-wifi: "Using Cal data from Flash 0xbfff"
pcie-wifi: "Using Ca
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Freitag, 25. Oktober 2019 13:39
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH] ath79: remove redundant mtd-mac-
> address for wmac
>
request_irq requires irq names to be static/allocated and not on the stack
Signed-off-by: Tim Harvey
---
...1-net-thunderx-workaround-BGX-TX-Underflow-issue.patch | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git
a/target/linux/octeontx/patches-4.14/0001-net-thu
22 matches
Mail list logo
