Re: [OpenWrt-Devel] [PATCH 0/4] mvebu: Add support for the Globalscale Mirabox

[Rafał Miłecki]

On 29 October 2014 at 23:38, Rafał Miłecki  wrote:
> On 9 October 2014 22:30, Imre Kaloz  wrote:
>> On Thu, 09 Oct 2014 17:59:25 +0200, Maxime Ripard
>>  wrote:
>>
>>> This patch adds a new profile for the Mirabox, and fixes a few things
>>> along the way, mostly because of the Mirabox NAND page size that
>>> differs from the other mvebu boards (and most of the boards supported
>>> by OpenWRT apparently).
>>
>>
>> At first look they look fine, except the UBI* options in the profiles. We
>> always want to build images for all boards, so I would keep those in the
>> image Makefile and keep the profiles for the bare minimum like on other
>> targets.
>
> Imre, could you point/prepare a well-written target Makefile using
> multiple UBI_OPTS, please? I'm sure that would help a lot to
> understand how it should look like in the perfect scenario. And
> hopefully mvebu could follow it.

Imre, this isn't OK.

Maxime followed scenario used by other targets, but we refuse to apply
it, because there may be a better way. A way that no one implemented
and that no one described.

By ignoring patches for months we will only make ppl turn around
instead of getting more contributors.

Please *describe* how UBI options should be handled differently or
*accept* patches as they are and re-design that UBI thing later.

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] bridge doesn't forward eap frames

[Rafał Miłecki]

On 24 November 2014 at 01:07, Felix Fietkau  wrote:
> On 2014-11-23 21:10, Michael Markusch wrote:
>> Hi,
>>
>> my WRT54GL with OpenWrt 12.09 doesn't forward eap frames in bridged
>> ap-mode. Since kernel 3.2, there is a way to force a bridge forward eap
>> frames.
>>
>> http://www.gremwell.com/linux_kernel_can_forward_802_1x
>>
>> If I look in the patches of the 12.09, I found a patch
>> "bridge_no_eap_forward", which drops the eap frames.
>>
>> How can I forward eap frames?
> What do you need this for?

May I ask the other way? What do we need this patch for? When seeing
such a non described patches, I'm always afraid one day noone will
understand them ;)

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] kernel: Use defconfig instead of full fledged kernel configuration

[Florian Fainelli]

Le 18/11/2014 02:27, Maxime Ripard a écrit :
> Hi Felix,
> 
> On Sun, Nov 09, 2014 at 11:54:15AM +0100, Felix Fietkau wrote:
>> On 2014-11-07 11:58, Maxime Ripard wrote:
>>> Rely on the Kconfig defconfig mechanism to fill all the missing options,
>>> instead of needing to set them all in the kernel configurations like what 
>>> was
>>> previously done.
>>>
>>> This will allow to trim down a lot the configuration files, avoid carrying
>>> unused configuration options and preserve the developpers mental health.
>>>
>>> Signed-off-by: Maxime Ripard 
>> I think this is a very good idea. Did you verify on all relevant
>> architectures that the resulting kernel config stays the same with this
>> change?
> 
> I've given a test-run on all the supported architectures, both with
> and without the patch.
> 
> It pointed out that there was an incorrect assumption on my side that
> $(ARCH) would be the Linux architecture, which it isn't. A second
> version will follow shortly to address this.

I have not seen a v2 patchset which addresses that? Thanks!

> 
> Beside ramips that failed to build on my build machine, and um that
> was missing the needed exception to convert it to the linux
> architecture, the only change in *all* the generated configuration is
> CONFIG_INITRAMFS_SOURCE being at a different location in the file.
> 
> Note that this is just with this patch applied, so there was no
> trimmed version of the configuration files involved.
> 
> You can find the build logs and kernel configuration files there:
> http://free-electrons.com/~maxime/pub/openwrt/, both with and without
> the patch applied.
> 
> Maxime
> 
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kernel: 3.18: Fix kmod-ipt-nat

[Florian Fainelli]

Le 07/11/2014 07:20, Maxime Ripard a écrit :
> The 3.18 kernel introduced new Kconfig options for the xt_nat and iptable_nat
> kernel modules, that both belong to the ipt_nat kernel package.
> 
> Enable this new options.
> 
> Signed-off-by: Maxime Ripard 

FWIW, applied in r43212.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ar71xxx + rtl8188eu

[Luis Soltero]

Anyone have any luck getting the realtek 8188eu USB WiFi chipset working on 
mips ar71xxx?

i am trying to get the following two devices to get an alfa hornet and and alfa AWUS036NHV long range USB WiFi adapter 
to communicate.


http://wiki.openwrt.org/toh/alfa.network/hornet-ub
http://www.amazon.com/Alfa-AWUS036NHV-802-11n-Wireless-N-Removable/dp/B00LU4D5N4/ref=sr_1_4?ie=UTF8&qid=1416790367&sr=8-4&keywords=alfa

I just downloaded a fresh copy of CC (r43350) and selected the rtl8188eu driver under kernel modules->wireless drivers.  
the kernel module compiles and loads.  dmesg shows that the device is detected.  However a wlan interface is not created 
for the device.


putting the module into debug mode shows that the driver can't read the EEPROM.


[ 1422.29] R8188EU: bFWReady == false call reset 8051...
[ 1422.29] R8188EU: => _8051Reset88E(): 8051 reset success .
[ 1422.31] R8188EU: efuse_read_phymap_from_txpktbuf bcnhead:0
[ 1422.32] R8188EU: efuse_read_phymap_from_txpktbuf len:3625, lenbak:109, 
aaa:3625, aaabak:109
[ 1422.37] R8188EU: efuse_read_phymap_from_txpktbuf read count:512
[ 1422.37] R8188EU: EEPROM ID(0x616c) is invalid!!
[ 1422.38] R8188EU: EEPROM ID = 0x616c
[ 1422.38] R8188EU: VID = 0x5678, PID = 0x1234
[ 1422.39] R8188EU: Customer ID: 0xAB, SubCustomer ID: 0xCD
[ 1422.39] R8188EU:  [0x8000,7]
[ 1422.39] Hal_EfuseParseMACAddr_8188EU: Permanent Address = 
00-e0-4c-81-88-02

the incorrect mac address is assigned to the device... the device never shows 
up in iwconfig or iw list


a similar problem is described for the lwfinger version of the driver discussed 
here.

https://github.com/lwfinger/rtl8188eu/issues/75

any ideas?

here is the full debug=8 log.

[ 1421.72] usb 1-1: new high-speed USB device number 7 using ehci-platform
[ 1421.88] R8188EU:  [0x0010,5]
[ 1421.88] +rtw_drv_init
[ 1421.88] R8188EU:
[ 1421.88] usb_endpoint_descriptor(0):
[ 1421.89] R8188EU: bLength=7
[ 1421.89] R8188EU: bDescriptorType=5
[ 1421.89] R8188EU: bEndpointAddress=81
[ 1421.90] R8188EU: wMaxPacketSize=512
[ 1421.90] R8188EU: bInterval=0
[ 1421.91] R8188EU: RT_usb_endpoint_is_bulk_in = 1
[ 1421.91] R8188EU:
[ 1421.91] usb_endpoint_descriptor(1):
[ 1421.92] R8188EU: bLength=7
[ 1421.92] R8188EU: bDescriptorType=5
[ 1421.92] R8188EU: bEndpointAddress=2
[ 1421.93] R8188EU: wMaxPacketSize=512
[ 1421.93] R8188EU: bInterval=0
[ 1421.93] R8188EU: RT_usb_endpoint_is_bulk_out = 2
[ 1421.94] R8188EU:
[ 1421.94] usb_endpoint_descriptor(2):
[ 1421.94] R8188EU: bLength=7
[ 1421.95] R8188EU: bDescriptorType=5
[ 1421.95] R8188EU: bEndpointAddress=3
[ 1421.96] R8188EU: wMaxPacketSize=512
[ 1421.96] R8188EU: bInterval=0
[ 1421.96] R8188EU: RT_usb_endpoint_is_bulk_out = 3
[ 1421.97] R8188EU: nr_endpoint=3, in_num=1, out_num=2
[ 1421.97]
[ 1421.97] R8188EU: USB_SPEED_HIGH
[ 1421.98] R8188EU: CHIP TYPE: RTL8188E
[ 1421.98] R8188EU: rtw_handle_dualmac(): pbuddy_padapter == NULL, Set 
pbuddy_padapter
[ 1421.99] R8188EU:  [0x0800,8]
[ 1421.99] +init_net_dev
[ 1422.00] R8188EU: register rtw_netdev_ops to netdev_ops
[ 1422.00] Chip Version Info: 
CHIP_8188E_Normal_Chip_TSMC_D_CUT_1T1R_RomVer(0)
[ 1422.01] R8188EU: RF_Type is 3!!
[ 1422.01] R8188EU: _ConfigNormalChipOutEP_8188E OutEpQueueSel(0x05), 
OutEpNumber(2)
[ 1422.03] R8188EU: EEPROM type is E-FUSE
[ 1422.03] R8188EU: > _ReadAdapterInfo8188EU
[ 1422.03] R8188EU: Boot from EFUSE, Autoload OK !
[ 1422.05] R8188EU:  [0x4000,8]
[ 1422.05] HalPwrSeqCmdParsing: offset(0x6) cut_msk(0xff) fab_msk(0xf) interface_msk(0xf) base(0x0) cmd(0x2) 
msk(0x2) value(0x2)

[ 1422.06] R8188EU:  [0x4000,8]
[ 1422.06] HalPwrSeqCmdParsing: PWR_CMD_POLLING
[ 1422.08] R8188EU:  [0x4000,8]
[ 1422.08] HalPwrSeqCmdParsing: offset(0x2) cut_msk(0xff) fab_msk(0xf) interface_msk(0xf) base(0x0) cmd(0x1) 
msk(0x3) value(0x0)

[ 1422.09] R8188EU:  [0x4000,8]
[ 1422.09] HalPwrSeqCmdParsing: PWR_CMD_WRITE
[ 1422.11] R8188EU:  [0x4000,8]
[ 1422.11] HalPwrSeqCmdParsing: offset(0x26) cut_msk(0xff) fab_msk(0xf) interface_msk(0xf) base(0x0) cmd(0x1) 
msk(0x80) value(0x80)

[ 1422.12] R8188EU:  [0x4000,8]
[ 1422.12] HalPwrSeqCmdParsing: PWR_CMD_WRITE
[ 1422.13] R8188EU:  [0x4000,8]
[ 1422.14] HalPwrSeqCmdParsing: offset(0x5) cut_msk(0xff) fab_msk(0xf) interface_msk(0xf) base(0x0) cmd(0x1) 
msk(0x80) value(0x0)

[ 1422.15] R8188EU:  [0x4000,8]
[ 1422.15] HalPwrSeqCmdParsing: PWR_CMD_WRITE
[ 1422.16] R8188EU:  [0x4000,8]
[ 1422.16] HalPwrSeqCmdParsing: offset(0x5) cut_msk(0xff) fab_msk(0xf) interface_msk(0xf) base(0x0) cmd(0x1) 
msk(0x18) value(0x0)

[ 1422.17] R8188EU:  [0x4000,8]
[ 1422.17] HalPwrSeqCmdParsing: PWR_CMD_WRITE
[ 1422.18] R8188EU:  [0x4000,8]
[ 1422.18

Re: [OpenWrt-Devel] bridge doesn't forward eap frames

[Felix Fietkau]

On 2014-11-23 21:10, Michael Markusch wrote:
> Hi,
> 
> my WRT54GL with OpenWrt 12.09 doesn't forward eap frames in bridged
> ap-mode. Since kernel 3.2, there is a way to force a bridge forward eap
> frames.
> 
> http://www.gremwell.com/linux_kernel_can_forward_802_1x
> 
> If I look in the patches of the 12.09, I found a patch
> "bridge_no_eap_forward", which drops the eap frames.
> 
> How can I forward eap frames?
What do you need this for?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)

[Felix Fietkau]

On 2014-11-23 23:03, Weedy wrote:
> 
> On Nov 23, 2014 4:35 PM, "Weedy"  > wrote:
>>
>>
>> On Nov 19, 2014 8:47 AM, "John Crispin"  > wrote:
>> >
>> >
>> >
>> > On 19/11/2014 14:44, Weedy wrote:
>> > >
>> > > On Oct 30, 2014 5:08 PM, "Heiner Kallweit"  
>> > > >> wrote:
>> > >>
>> > >> Am 30.10.2014 um 07:22 schrieb Heiner Kallweit:
>> > >> > Am 30.10.2014 um 03:36 schrieb Florian Fainelli:
>> > >> >> Le 28/10/2014 11:46, Heiner Kallweit a écrit :
>> > >> >>> After a little more thinking about it and looking at the code I
>> > > basically have two questions:
>> > >> >>>
>> > >> >>> 1.
>> > >> >>> Is it actually needed to exclude certain phy's in
>> > > ar8xxx_phy_config_aneg?
>> > >> >>> (At least for AR8327 it doesn't get called with an addr != 0
> anyway)
>> > >> >>> Else we could remove ar8xxx_phy_config_aneg and directly register
>> > > genphy_config_aneg as
>> > >> >>> callback for autoneg configuration.
>> > >> >>
>> > >> >> Address 0 is special, since this is a MDIO broadcast address that
>> > > will usually be handled by switches as "write to all front-panel
> ports".
>> > >> >>
>> > >> >>>
>> > >> >>> 2.
>> > >> >>> Call sequence with regard to ar8216 is:
>> > >> >>> ar8216: ar8xxx_phy_probe
>> > >> >>> phy: phy_attach_direct
>> > >> >>> phy: phy_init_hw
>> > >> >>> ar8216: ar8xxx_phy_config_init
>> > >> >>> ar8216: ar8xxx_phy_config_aneg
>> > >> >>>
>> > >> >>> ar8216 driver handles AR8327/AR8337 different from the other
>> > > supported switch types.
>> > >> >>> ar8xxx_start incl. more detailed configuration is called from
>> > > ar8xxx_phy_probe already.
>> > >> >>> For the other switch types it's called from
> ar8xxx_phy_config_init.
>> > >> >>>
>> > >> >>> I wonder whether doing detailed configuration in the probe stage
>> > > might be too early.
>> > >> >>> phy_init_hw resets the switch anyway later.
>> > >> >>> Doing the detailed setup in ar8xxx_phy_config_init seems to be
>> > > more suited however
>> > >> >>> there might be good reason why it's handled the way it is.
>> > >> >>
>> > >> >> I suppose that you could re-advertise auto-negotiation by calling
>> > > genphy_config_advert() in the config_init routine.
>> > >> >
>> > >> > The actual problem is caused by BMCR_ANENABLE being cleared by the
>> > > reset in phy_init_hw.
>> > >> > As far as I can see genphy_config_advert doesn't bring back
> this flag.
>> > >> > What does genphy_config_aneg mainly do?
>> > >> >   - call genphy_config_advert
>> > >> >   - check if BMCR_ANENABLE is set
>> > >> >   - if it's not, call genphy_restart_aneg
>> > >> > Therefore, to bring back BMCR_ANENABLE, we have to call
>> > > genphy_config_aneg or genphy_restart_aneg.
>> > >> > genphy_restart_aneg most likely is sufficient, however I don't see
>> > > that genphy_config_aneg
>> > >> > can do any harm if being called with addr == 0.
>> > >> > At least for me it works perfectly fine to call genphy_config_aneg
>> > > for all addr's.
>> > >> >
>> > >> > Rgds, Heiner
>> > >> >
>> > >> >>
>> > >> >>>
>> > >> >>> Rgds,
>> > >> >>> Heiner
>> > >> >>>
>> > >> >>>
>> > >> >>> Am 27.10.2014 um 22:00 schrieb Heiner Kallweit:
>> > >>  With two different TPLINK routers (both with a AR8327N switch) I
>> > > faced the issue that with
>> > >>  kernel 3.14 certain switch ports used 10MBit/half only.
>> > >>  Under kernel 3.10 everything was fine and the same ports used
>> > > 1000MBit/full.
>> > >> 
>> > >>  As the ar8216 driver is the same I had a look at the common phy
>> > > code in drivers/net/phy.
>> > >>  In function phy_init_hw in phy_device.c kernel 3.14 resets the
>> > > phy whilst 3.10 does not.
>> > >> 
>> > >>  The issue turned out to be that when resetting only flag
>> > > BMCR_RESET is set, not BMCR_ANENABLE.
>> > >>  (In ar8216.c always both flags are set when the switch is reset)
>> > >>  Therefore autoneg was not enabled. Also later in the boot
> process
>> > > it doesn't get enabled.
>> > >>  Adding BMCR_ANENABLE solved the problem and now also under 3.14
>> > > all ports use 1000MBit/full.
>> > >> 
>> > >>  However I'm not sure whether it's a poper fix to add
>> > > BMCR_ANENABLE in this generic phy function.
>> > >>  It might not be appropriate for other phy's.
>> > >> 
>> > >>  After resetting the switch later in the boot process
>> > > ar8xxx_phy_config_aneg is called with
>> > >>  phydev->addr being 0.
>> > >>  In this case the function returns immediately. Otherwise it
> would
>> > > call genphy_config_aneg.
>> > >>  Calling genphy_config_aneg would also solve the problem as it
>> > > checks for BMCR_ANENABLE
>> > >>  being set and sets it if needed.
>> > >>  I don't know the reason why genphy_config_aneg isn't called in
>> > > case of addr 0.
>> > >>  Or is this a typo and the check actually should be addr != 0 ?
>> > >> >>

Re: [OpenWrt-Devel] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)

[Weedy]

On Nov 23, 2014 4:35 PM, "Weedy"  wrote:
>
>
> On Nov 19, 2014 8:47 AM, "John Crispin"  wrote:
> >
> >
> >
> > On 19/11/2014 14:44, Weedy wrote:
> > >
> > > On Oct 30, 2014 5:08 PM, "Heiner Kallweit"  > > > wrote:
> > >>
> > >> Am 30.10.2014 um 07:22 schrieb Heiner Kallweit:
> > >> > Am 30.10.2014 um 03:36 schrieb Florian Fainelli:
> > >> >> Le 28/10/2014 11:46, Heiner Kallweit a écrit :
> > >> >>> After a little more thinking about it and looking at the code I
> > > basically have two questions:
> > >> >>>
> > >> >>> 1.
> > >> >>> Is it actually needed to exclude certain phy's in
> > > ar8xxx_phy_config_aneg?
> > >> >>> (At least for AR8327 it doesn't get called with an addr != 0
anyway)
> > >> >>> Else we could remove ar8xxx_phy_config_aneg and directly register
> > > genphy_config_aneg as
> > >> >>> callback for autoneg configuration.
> > >> >>
> > >> >> Address 0 is special, since this is a MDIO broadcast address that
> > > will usually be handled by switches as "write to all front-panel
ports".
> > >> >>
> > >> >>>
> > >> >>> 2.
> > >> >>> Call sequence with regard to ar8216 is:
> > >> >>> ar8216: ar8xxx_phy_probe
> > >> >>> phy: phy_attach_direct
> > >> >>> phy: phy_init_hw
> > >> >>> ar8216: ar8xxx_phy_config_init
> > >> >>> ar8216: ar8xxx_phy_config_aneg
> > >> >>>
> > >> >>> ar8216 driver handles AR8327/AR8337 different from the other
> > > supported switch types.
> > >> >>> ar8xxx_start incl. more detailed configuration is called from
> > > ar8xxx_phy_probe already.
> > >> >>> For the other switch types it's called from
ar8xxx_phy_config_init.
> > >> >>>
> > >> >>> I wonder whether doing detailed configuration in the probe stage
> > > might be too early.
> > >> >>> phy_init_hw resets the switch anyway later.
> > >> >>> Doing the detailed setup in ar8xxx_phy_config_init seems to be
> > > more suited however
> > >> >>> there might be good reason why it's handled the way it is.
> > >> >>
> > >> >> I suppose that you could re-advertise auto-negotiation by calling
> > > genphy_config_advert() in the config_init routine.
> > >> >
> > >> > The actual problem is caused by BMCR_ANENABLE being cleared by the
> > > reset in phy_init_hw.
> > >> > As far as I can see genphy_config_advert doesn't bring back this
flag.
> > >> > What does genphy_config_aneg mainly do?
> > >> >   - call genphy_config_advert
> > >> >   - check if BMCR_ANENABLE is set
> > >> >   - if it's not, call genphy_restart_aneg
> > >> > Therefore, to bring back BMCR_ANENABLE, we have to call
> > > genphy_config_aneg or genphy_restart_aneg.
> > >> > genphy_restart_aneg most likely is sufficient, however I don't see
> > > that genphy_config_aneg
> > >> > can do any harm if being called with addr == 0.
> > >> > At least for me it works perfectly fine to call genphy_config_aneg
> > > for all addr's.
> > >> >
> > >> > Rgds, Heiner
> > >> >
> > >> >>
> > >> >>>
> > >> >>> Rgds,
> > >> >>> Heiner
> > >> >>>
> > >> >>>
> > >> >>> Am 27.10.2014 um 22:00 schrieb Heiner Kallweit:
> > >>  With two different TPLINK routers (both with a AR8327N switch) I
> > > faced the issue that with
> > >>  kernel 3.14 certain switch ports used 10MBit/half only.
> > >>  Under kernel 3.10 everything was fine and the same ports used
> > > 1000MBit/full.
> > >> 
> > >>  As the ar8216 driver is the same I had a look at the common phy
> > > code in drivers/net/phy.
> > >>  In function phy_init_hw in phy_device.c kernel 3.14 resets the
> > > phy whilst 3.10 does not.
> > >> 
> > >>  The issue turned out to be that when resetting only flag
> > > BMCR_RESET is set, not BMCR_ANENABLE.
> > >>  (In ar8216.c always both flags are set when the switch is reset)
> > >>  Therefore autoneg was not enabled. Also later in the boot
process
> > > it doesn't get enabled.
> > >>  Adding BMCR_ANENABLE solved the problem and now also under 3.14
> > > all ports use 1000MBit/full.
> > >> 
> > >>  However I'm not sure whether it's a poper fix to add
> > > BMCR_ANENABLE in this generic phy function.
> > >>  It might not be appropriate for other phy's.
> > >> 
> > >>  After resetting the switch later in the boot process
> > > ar8xxx_phy_config_aneg is called with
> > >>  phydev->addr being 0.
> > >>  In this case the function returns immediately. Otherwise it
would
> > > call genphy_config_aneg.
> > >>  Calling genphy_config_aneg would also solve the problem as it
> > > checks for BMCR_ANENABLE
> > >>  being set and sets it if needed.
> > >>  I don't know the reason why genphy_config_aneg isn't called in
> > > case of addr 0.
> > >>  Or is this a typo and the check actually should be addr != 0 ?
> > >> 
> > >>  Rgds, Heiner
> > >> 
> > >>
> > >> The following rudimentary patch works fine for me with kernel
3.14.18 on
> > >> TP-LINK TL-WDR4900 (mpc85xx with AR8327Nv4)
> > >> TP-LINK TL-WDR4300 ( ar71xx with AR8327Nv2)
> > >>
> > >> Apart from using genphy_config_aneg also 

Re: [OpenWrt-Devel] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)

[Weedy]

On Nov 19, 2014 8:47 AM, "John Crispin"  wrote:
>
>
>
> On 19/11/2014 14:44, Weedy wrote:
> >
> > On Oct 30, 2014 5:08 PM, "Heiner Kallweit"  > > wrote:
> >>
> >> Am 30.10.2014 um 07:22 schrieb Heiner Kallweit:
> >> > Am 30.10.2014 um 03:36 schrieb Florian Fainelli:
> >> >> Le 28/10/2014 11:46, Heiner Kallweit a écrit :
> >> >>> After a little more thinking about it and looking at the code I
> > basically have two questions:
> >> >>>
> >> >>> 1.
> >> >>> Is it actually needed to exclude certain phy's in
> > ar8xxx_phy_config_aneg?
> >> >>> (At least for AR8327 it doesn't get called with an addr != 0
anyway)
> >> >>> Else we could remove ar8xxx_phy_config_aneg and directly register
> > genphy_config_aneg as
> >> >>> callback for autoneg configuration.
> >> >>
> >> >> Address 0 is special, since this is a MDIO broadcast address that
> > will usually be handled by switches as "write to all front-panel ports".
> >> >>
> >> >>>
> >> >>> 2.
> >> >>> Call sequence with regard to ar8216 is:
> >> >>> ar8216: ar8xxx_phy_probe
> >> >>> phy: phy_attach_direct
> >> >>> phy: phy_init_hw
> >> >>> ar8216: ar8xxx_phy_config_init
> >> >>> ar8216: ar8xxx_phy_config_aneg
> >> >>>
> >> >>> ar8216 driver handles AR8327/AR8337 different from the other
> > supported switch types.
> >> >>> ar8xxx_start incl. more detailed configuration is called from
> > ar8xxx_phy_probe already.
> >> >>> For the other switch types it's called from ar8xxx_phy_config_init.
> >> >>>
> >> >>> I wonder whether doing detailed configuration in the probe stage
> > might be too early.
> >> >>> phy_init_hw resets the switch anyway later.
> >> >>> Doing the detailed setup in ar8xxx_phy_config_init seems to be
> > more suited however
> >> >>> there might be good reason why it's handled the way it is.
> >> >>
> >> >> I suppose that you could re-advertise auto-negotiation by calling
> > genphy_config_advert() in the config_init routine.
> >> >
> >> > The actual problem is caused by BMCR_ANENABLE being cleared by the
> > reset in phy_init_hw.
> >> > As far as I can see genphy_config_advert doesn't bring back this
flag.
> >> > What does genphy_config_aneg mainly do?
> >> >   - call genphy_config_advert
> >> >   - check if BMCR_ANENABLE is set
> >> >   - if it's not, call genphy_restart_aneg
> >> > Therefore, to bring back BMCR_ANENABLE, we have to call
> > genphy_config_aneg or genphy_restart_aneg.
> >> > genphy_restart_aneg most likely is sufficient, however I don't see
> > that genphy_config_aneg
> >> > can do any harm if being called with addr == 0.
> >> > At least for me it works perfectly fine to call genphy_config_aneg
> > for all addr's.
> >> >
> >> > Rgds, Heiner
> >> >
> >> >>
> >> >>>
> >> >>> Rgds,
> >> >>> Heiner
> >> >>>
> >> >>>
> >> >>> Am 27.10.2014 um 22:00 schrieb Heiner Kallweit:
> >>  With two different TPLINK routers (both with a AR8327N switch) I
> > faced the issue that with
> >>  kernel 3.14 certain switch ports used 10MBit/half only.
> >>  Under kernel 3.10 everything was fine and the same ports used
> > 1000MBit/full.
> >> 
> >>  As the ar8216 driver is the same I had a look at the common phy
> > code in drivers/net/phy.
> >>  In function phy_init_hw in phy_device.c kernel 3.14 resets the
> > phy whilst 3.10 does not.
> >> 
> >>  The issue turned out to be that when resetting only flag
> > BMCR_RESET is set, not BMCR_ANENABLE.
> >>  (In ar8216.c always both flags are set when the switch is reset)
> >>  Therefore autoneg was not enabled. Also later in the boot process
> > it doesn't get enabled.
> >>  Adding BMCR_ANENABLE solved the problem and now also under 3.14
> > all ports use 1000MBit/full.
> >> 
> >>  However I'm not sure whether it's a poper fix to add
> > BMCR_ANENABLE in this generic phy function.
> >>  It might not be appropriate for other phy's.
> >> 
> >>  After resetting the switch later in the boot process
> > ar8xxx_phy_config_aneg is called with
> >>  phydev->addr being 0.
> >>  In this case the function returns immediately. Otherwise it would
> > call genphy_config_aneg.
> >>  Calling genphy_config_aneg would also solve the problem as it
> > checks for BMCR_ANENABLE
> >>  being set and sets it if needed.
> >>  I don't know the reason why genphy_config_aneg isn't called in
> > case of addr 0.
> >>  Or is this a typo and the check actually should be addr != 0 ?
> >> 
> >>  Rgds, Heiner
> >> 
> >>
> >> The following rudimentary patch works fine for me with kernel 3.14.18
on
> >> TP-LINK TL-WDR4900 (mpc85xx with AR8327Nv4)
> >> TP-LINK TL-WDR4300 ( ar71xx with AR8327Nv2)
> >>
> >> Apart from using genphy_config_aneg also for addr==0 I replaced
> > msleep(1000)
> >> with a polling function inspired by phy_poll_reset in phy_device.c
> >> On AR8327 the reset actually takes less than 20ms. Sleeping for 1000ms
> >> seems to be a waste of time.
> >>
> >> Little more work would be needed to make it a pro

[OpenWrt-Devel] bridge doesn't forward eap frames

[Michael Markusch]

Hi,

my WRT54GL with OpenWrt 12.09 doesn't forward eap frames in bridged
ap-mode. Since kernel 3.2, there is a way to force a bridge forward eap
frames.

http://www.gremwell.com/linux_kernel_can_forward_802_1x

If I look in the patches of the 12.09, I found a patch
"bridge_no_eap_forward", which drops the eap frames.

How can I forward eap frames?

I hope, someone can clarify me.

Thanks,
Michael
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Need help understanding Ralink's dts config file and how it works

[Md Mahbubur Rasheed]

I spent the whole, exhausting day to understand how dts config file works.
I used MT7620A programming guide, and a MT7620A based router to try and
test different configurations. Although I understood few parts, such as
enabling registers to enable features like usb ohci, or sdhci. I also
understood memory and gpio configuration. But configurations, such as-
ethernet@1010 , pinctrl etc remain as foggy as it was 12 hours ago. My
problems are-

1. Why a single SoC has so many built in ethernet controllers/ drivers
(MT7530, RT2880, MT7620)? If a doesn't have any external ethernet
controller, then which one should we use?
2. How (and where) is the WAN port (i.e. phy4) mapped to gigabit bus rgmii?
Is it possible to map WAN port as a gigabit port? Or it always remains
100Mbps port?
3. In the following code, when should we use gmac and when ephy?
 gsw@1011 {
ralink,port4 = "gmac";
};
4. what does the following code do?
pinctrl {
state_default: pinctrl0 {
gpio {
ralink,group = "i2c", "uartf";
ralink,function = "gpio";
};
};
};
5. where are all the registers such as- rgmii1_pins, mdio_pins, phy4 etc
defined? Which code reads the dts file for config?

Finally, the MT7620A programming guide describes the registers, but it
doesn't explain the configurations or provides examples. I tried to use dts
files for other routers to understand, but it was not much fruitful either.
Is there any resource explaining the structure and programming model?

I very much appreciate your helping hand in advance. :)

Best regards,
M
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] I'd like to donate a Netgear N150 WNR1000 v3

[Rafał Miłecki]

On 20 November 2014 at 23:19, Rafał Miłecki  wrote:
> On 20 November 2014 18:03, Kristjan Onu  wrote:
>> I am attaching the output of nvram show from a WGR614v10. I think it is very
>> similar to the WNR1000v3.
>>
>> Please let me know if you have any questions.
>
> Could you send e-mails as text/plain, please?
>
> I've commited changes that should fix/improve WGR614 V10 situation, see:
> https://dev.openwrt.org/changeset/43336/
>
> Could you try booting OpenWrt version with these patches included? And
> provide us a boot log, please? Serial console may be required of
> course.

There is already a ready build you can try to install, see:
http://downloads.openwrt.org/snapshots/trunk/brcm47xx.mips74k/
(please remember to attach serial console and grab the boot log)

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel