Re: 2^64 - 39 ...

[Otto Moerbeek]

On Mon, Sep 07, 2015 at 06:20:02PM -0400, Raul Miller wrote:

> On Mon, Sep 7, 2015 at 6:03 PM, Ted Unangst  wrote:
> > Michael Warmuth-Uhl wrote:
> >> On 2015-09-07, Otto Moerbeek wrote:
> >> It seems to fix the issues on amd64, but I'm not sure if the accuracy of
> >> long double and sqrtl is guaranteed to be enough in general.
> >
> > using floating point seems suspect. i think what's needed is an integer sqrt
> > function.
> 
> Floating point works fine for integers as long as your integers fit
> within the mantissa component of the floating point representation.
> 
> Assuming the usual IEEE-754 implementation:
> 
> For double, this means integers cannot exceed 2^53 (9007199254740992)
> without losing least significant bits (2^53-1 can be represented, 2^53
> can be represented but has lost the least significant bit so typically
> that means it's assumed to be zero - which is fine, but that means
> that 1+2^53 cannot be represented).
> 
> For long double, this means integers cannot exceed 2^113
> (10384593717069655257060992658440192) without losing least significant
> bits.
> 
> That said, you can implement integer square root using binary search.

My bet would be Newton iteration, which should converge faster than
binary search. ping(8) has an implementation of integer sqrt.

BTW, long double won't fix the problem on al platforms since it is not
guaranteed to be longer than double.

-Otto

Re: 2^64 - 39 ...

[Daniel Boulet]

Here’s a function that computes unsigned long square roots using Newton’s
method.

I believe that I have tested it quite carefully and am quite confident that it
works correctly.

It returns the unsigned long exact square root value if there is one.
Otherwise, it returns the closest unsigned long int which is less than the
exact real square root value.

For example, it would return

0 as the square root of 0
1 as the square root of 1, 2 and 3
2 as the square root of 4, 5, 6, 7 and 8
3 as the square root of 9, 10 … 15
4 as the square root of 16 … 24

etc.

I believe that it properly handles all unsigned long values of n from 0L to
((unsigned long)~0L) == 2^64 - 1.

There are probably ways of making it faster.

I am not including my test software because I would be much more confident
that the code works if it was independently tested.

-Danny

#define DELTA(a,b) ( (a) > (b) ? (a) - (b) : (b) - (a) )

unsigned long
ulong_sqrt( unsigned long n )
{

if ( n == 0 || n == 1 ) {

return n;

}

unsigned long guess = n >> 1;
unsigned long quotient = n / guess;

while ( 1 ) {

unsigned long gap = DELTA( guess, quotient );
if ( gap < 2 ) {

break;

}

guess = ( quotient + guess ) >> 1;
quotient = n / guess;

}

guess = guess > quotient ? quotient : guess;

return guess;

}

> On Sep 8, 2015, at 00:03 , Otto Moerbeek  wrote:
>
> On Mon, Sep 07, 2015 at 06:20:02PM -0400, Raul Miller wrote:
>
>> On Mon, Sep 7, 2015 at 6:03 PM, Ted Unangst  wrote:
>>> Michael Warmuth-Uhl wrote:
 On 2015-09-07, Otto Moerbeek wrote:
 It seems to fix the issues on amd64, but I'm not sure if the accuracy of
 long double and sqrtl is guaranteed to be enough in general.
>>>
>>> using floating point seems suspect. i think what's needed is an integer
sqrt
>>> function.
>>
>> Floating point works fine for integers as long as your integers fit
>> within the mantissa component of the floating point representation.
>>
>> Assuming the usual IEEE-754 implementation:
>>
>> For double, this means integers cannot exceed 2^53 (9007199254740992)
>> without losing least significant bits (2^53-1 can be represented, 2^53
>> can be represented but has lost the least significant bit so typically
>> that means it's assumed to be zero - which is fine, but that means
>> that 1+2^53 cannot be represented).
>>
>> For long double, this means integers cannot exceed 2^113
>> (10384593717069655257060992658440192) without losing least significant
>> bits.
>>
>> That said, you can implement integer square root using binary search.
>
> My bet would be Newton iteration, which should converge faster than
> binary search. ping(8) has an implementation of integer sqrt.
>
> BTW, long double won't fix the problem on al platforms since it is not
> guaranteed to be longer than double.
>
>   -Otto

Re: 2^64 - 39 ...

[Christian Weisgerber]

On 2015-09-07, Otto Moerbeek  wrote:

> The game is to fix the bugs

FWIW, FreeBSD has changed factor(6) to use libcrypto's BN functions.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Incoming packets arrives on an interface and outgoing packets takes another interface

[jean-yves boisiaud]

hello,

I'm using OBSD 5.7 as a firewall with carp and pfsync, more ipsec VPN used
with sasyncd.

I have two Internet interfaces, one is the default route (em1), the other
is for legacy traffic (em2). I also have a DMZ/LANs interface (em0).

Outgoing traffic from LANs (arriving on em0) to the Internet works
perfectly, whatever it takes em1 or em2 (depending on static routes or pf
rules with route-to).

Incoming traffic from the internet that arrives on em1 to the LANs (through
em0) is also ok.

But there is a problem with the incoming traffic from the internet when it
arrives on em2.

For example, from a host on the Internet, when I ping the external IP
(local or CARP) of the em1 interface, ICMP echo requests packets arrive on
em2 (correct). But echo replies take the em1 interface, with the IP source
of em2 (not correct).

I tried to use the if-bound in pf.conf, but nothing changes.

How could I resolve this routing problem ?

Thanks for your help.


-- 
Jean-Yves Boisiaud - Alcor Consulting
24, rue de la Glycine
49250 Saint Remy la Varenne

Re: Intel AMT serial-over-LAN with OpenBSD

[Joe Gidi]

On Tue, September 8, 2015 1:40 am, Jonathan Gray wrote:
> On Sun, Sep 06, 2015 at 09:50:10PM -0400, Joe Gidi wrote:
>> I recently bought a Lenovo ThinkServer TS140 to replace my aging HP
>> Microserver. Rather than using a standard serial console to admin the
>> machine, I've been playing around with the Intel AMT serial-over-LAN
>> capabilities. The following notes might help others who'd like to use
>> this
>> feature with OpenBSD; hopefully they'll save you some hair-tearing.
>>
>> The Intel AMT technology can piggyback on the onboard NIC, sharing the
>> same IP and MAC as the operating system. I'm not a fan of that idea, so
>> I
>> opted to leave the onboard NIC as a dedicated management interface and
>> add
>> another NIC for the OS. So, in my system, em0 (onboard) is used only for
>> serial-over-LAN administration, and em1 (PCI-E card) is used by OpenBSD.
>>
>> Lenovo published a pretty decent PDF on configuring AMT, available here:
>>
>> http://www.lenovo.com/images/products/server/pdfs/tech_resources/thinkserver_config_amt_ts140_ts440_tr.pdf
>>
>> To get serial-over-LAN working, you can largely follow that PDF, but for
>> steps 18 and 19, you can leave IDER and KVM disabled. For step 20,
>> Legacy
>> Redirection Mode needs to be enabled.
>>
>> The serial-over-LAN device is presented as a puc(4) card with com4
>> attaching to it:
>>
>> puc0 at pci0 dev 22 function 3 "Intel 8 Series KT" rev 0x04: ports: 1
>> com
>> com4 at puc0 port 0 apic 8 int 19: ns16550a, 16 byte fifo
>>
>> To get a working console, I edited /etc/ttys like so:
>> tty04   "/usr/libexec/getty std.9600"   vt220   on  secure
>>
>> Then, to get the console working at boot, I configured /etc/boot.conf as
>> follows:
>> machine comaddr 0xf0e0/0x0008
>> set tty com4
>>
>> The "machine commaddr 0xf0e0/0x0008" line was worked out by running
>> 'pcidump -v' and finding the BAR io addr for this device:
>>
>>  0:22:3: Intel 8 Series KT
>> 0x: Vendor ID: 8086 Product ID: 8c3d
>> 0x0004: Command: 0007 Status: 00b0
>> 0x0008: Class: 07 Subclass: 00 Interface: 02 Revision: 04
>> 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line
>> Size: 00
>> 0x0010: BAR io addr: 0xf0e0/0x0008
>> 0x0014: BAR mem 32bit addr: 0xf7d3e000/0x1000
>> 0x0018: BAR empty ()
>> 0x001c: BAR empty ()
>> 0x0020: BAR empty ()
>> 0x0024: BAR empty ()
>> 0x0028: Cardbus CIS: 
>> 0x002c: Subsystem Vendor ID: 17aa Product ID: 30a5
>> 0x0030: Expansion ROM Base Address: 
>> 0x0038: 
>> 0x003c: Interrupt Pin: 02 Line: 0a Min Gnt: 00 Max Lat: 00
>> 0x00c8: Capability 0x01: Power Management
>> 0x00d0: Capability 0x05: Message Signaled Interrupts (MSI)
>>
>> That completed the setup on the ThinkServer side. To connect to it from
>> my
>> workstation, I installed the amtterm-cli package and ran 'amtterm
>> 192.168.1.19' (the IP address I'd assigned to the AMT interface during
>> setup).
>
> It is worth pointing out that amtterm is only useable with AMT versions <=
> 8
> as AMT version 9 removed the SOAP interface that amtterm uses.  If anyone
> knows of anything that can talk the ws-man protocol variant AMT version 9
> uses I'd like to hear about it.

This box has AMT 9, actually.

amtterm-cli, the SOL client, still works with it. However, as you said,
the other components of the amtterm package don't work due to the SOAP
interface being deprecated.

There apparently is some open-source code for wsman, but I don't see any
sign that it's been ported to OpenBSD:

https://openwsman.github.io/
http://en.community.dell.com/techcenter/b/techcenter/archive/2012/08/03/wsmancli-package-for-ubuntu

Thanks,

-- 
Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried

Re: doas(1) and $PATH inheritance...

[Adam Jeanguenat]

tedu wrote:
> If you'd like to try current, it should work better for you.

Confirmed working as expected; thanks for the assistance.

Hopefully someone else will benefit from this change as well.

--avj

Re: late 2006 intel iMac no sound OpenBSD5.7

[Dave Turner]

Jonathan,

Thanks for the info.
I have spent all evening reading the OpenBSD faq and trying find out 
where I get the updated version of azalia_codec.c from...
I don't think it is in the 5.7 Patch series, so I set to and did the 
Upgrade to OpenBSD 5.8 which seemed OK until I tried to login.
Much reading and faffing to find I had to use CTRL-ALT-F1 to get a 
terminal to login and do the sysmerge.


uname -a and dmesg both show the iMac is now running OpenBSD 5.8.
and the audio still doesn't work but in an interestingly different way!
Even as root I can't change the play.rate to 44100, it stays at 48000.

audioctl play.{seek,samples,errors} now returns
audioctl: field play.seek does not exist
audioctl: field play.samples does not exist
play.errors=0

I might have a bit more cvs updating to do? The version of 
azalia_codec.c in /usr/src/dev/pci seems to be still at 1.165 dated 
2014/12/10.

But it is late now and I have had enough for today.

On 08/09/15 03:26, Jonathan Gray wrote:

On Tue, Sep 08, 2015 at 12:58:18AM +0100, Dave Turner wrote:

I have tried the various tests on the audio system from the faqs, and an
email search didn't find much on apple hardware and sound but it was
discouraging... The changes from 5.7 to the imminent 5.8 do mention changes
to the azalia driver but the description didn't appear to relate to my
problem, although 5.6 to 5.7 did mention the mac mini and 'quirks'.
My iMac is a version 6,1 from late 2006.
It uses the Intel 82801GB HD Audio chip and the Realtek ALC885 codec.
It uses the azalia audio driver.
I played with mixerctl and audioctl, used 'cdio cdplay' etc, nothing would
make a sound!
The base setttings for audioctl had the play.rate at 48000 so I changed that
to 44100 to test using cdio cdplay.
I changed various settings in mixerctl to increase audio from 0 to 255, no
sound.

It seems almost all the apple audio devices need various quirks,
try this:

Index: azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.170
diff -u -p -r1.170 azalia_codec.c
--- azalia_codec.c  24 Aug 2015 04:50:40 -  1.170
+++ azalia_codec.c  8 Sep 2015 02:23:49 -
@@ -198,6 +198,7 @@ azalia_codec_init_vtbl(codec_t *this)
case 0x10ec0885:
this->name = "Realtek ALC885";
this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
+   printf("\n%s subid=%x\n", XNAME(this), this->subid);
if (this->subid == 0x00a1106b || /* APPLE_MB3 */
this->subid == 0xcb7910de || /* APPLE_MACMINI3_1 
(line-in + hp) */
this->subid == 0x00a0106b || /* APPLE_MB3_1 */
@@ -208,6 +209,10 @@ azalia_codec_init_vtbl(codec_t *this)
this->subid == 0xcb7910de || /* APPLE_MACMINI3_1 
(internal spkr) */
this->subid == 0x00a0106b)
this->qrks |= AZ_QRK_WID_OVREF50;
+   if (this->subid == 0x1000106b ||
+   this->subid == 0x3e00106b) {
+   this->qrks |= AZ_QRK_GPIO_UNMUTE_0 | 
AZ_QRK_GPIO_UNMUTE_1;
+   }
break;
case 0x10ec0888:
this->name = "Realtek ALC888";

openbsd.cs.toronto.edu seems to be down for me

[Bryan C. Everly]

I'm trying to get to http://openbsd.cs.toronto.edu/pub/OpenBSD/ and
failing.  I can get to other mirrors (i.e.
http://ftp.openbsd.org/pub/OpenBSD/ ) just fine.

Is it just me?

Thanks,
Bryan

Re: openbsd.cs.toronto.edu seems to be down for me

[Timo Buhrmester]

> Is it just me?
There are services for answering that exact questions, e.g. 
http://downforeveryoneorjustme.com/

That said it's just their httpd that seems gone; ftp access works.

--
Timo Buhrmester

Question - test lab

[Bryan C. Everly]

Hi

I'm trying to put together a multiple CPU architecture test lab for
work I'm doing on some ports and I have the following:

* Thinkpad T21 (i386)
* Powerbook G4 (32-bit PPC)
* Sun Blade 100 (sparc64)
* Thinkpad x220 (amd64)

I'm wondering if anyone could recommend a low-cost Alpha or PA-RISC
machine for me to add to this?  I'm planning on an EdgeRouter for the
MIPS 64-bit CPU.

Thanks,
Bryan

Re: openbsd.cs.toronto.edu seems to be down for me

[Nick Holland]

On 09/08/15 20:18, Bryan C. Everly wrote:
> I'm trying to get to http://openbsd.cs.toronto.edu/pub/OpenBSD/ and
> failing.  I can get to other mirrors (i.e.
> http://ftp.openbsd.org/pub/OpenBSD/ ) just fine.
> 
> Is it just me?

Not just you, it's been restarted.

Thanks!

Nick.

Re: openbsd.cs.toronto.edu seems to be down for me

[Bryan C. Everly]

Thanks Nick.  The fact that I could ping it confused me.  Should have
tried FTP.  Duh.

Thanks,
Bryan


On Tue, Sep 8, 2015 at 8:41 PM, Nick Holland
 wrote:
> On 09/08/15 20:18, Bryan C. Everly wrote:
>> I'm trying to get to http://openbsd.cs.toronto.edu/pub/OpenBSD/ and
>> failing.  I can get to other mirrors (i.e.
>> http://ftp.openbsd.org/pub/OpenBSD/ ) just fine.
>>
>> Is it just me?
>
> Not just you, it's been restarted.
>
> Thanks!
>
> Nick.

Re: late 2006 intel iMac no sound OpenBSD5.7

[Jonathan Gray]

The patch was against -current.  As it seems you've updated your system
to -current now, when running cvs up you can use "cvs up -PAd" to remove
any tags.  If /usr/src/CVS/Tag exists your src tree is tracking a stable
branch.

On Tue, Sep 08, 2015 at 10:03:35PM +0100, Dave Turner wrote:
> Jonathan,
> 
> Thanks for the info.
> I have spent all evening reading the OpenBSD faq and trying find out where I
> get the updated version of azalia_codec.c from...
> I don't think it is in the 5.7 Patch series, so I set to and did the Upgrade
> to OpenBSD 5.8 which seemed OK until I tried to login.
> Much reading and faffing to find I had to use CTRL-ALT-F1 to get a terminal
> to login and do the sysmerge.
> 
> uname -a and dmesg both show the iMac is now running OpenBSD 5.8.
> and the audio still doesn't work but in an interestingly different way!
> Even as root I can't change the play.rate to 44100, it stays at 48000.
> 
> audioctl play.{seek,samples,errors} now returns
> audioctl: field play.seek does not exist
> audioctl: field play.samples does not exist
> play.errors=0
> 
> I might have a bit more cvs updating to do? The version of azalia_codec.c in
> /usr/src/dev/pci seems to be still at 1.165 dated 2014/12/10.
> But it is late now and I have had enough for today.
> 
> On 08/09/15 03:26, Jonathan Gray wrote:
> >On Tue, Sep 08, 2015 at 12:58:18AM +0100, Dave Turner wrote:
> >>I have tried the various tests on the audio system from the faqs, and an
> >>email search didn't find much on apple hardware and sound but it was
> >>discouraging... The changes from 5.7 to the imminent 5.8 do mention changes
> >>to the azalia driver but the description didn't appear to relate to my
> >>problem, although 5.6 to 5.7 did mention the mac mini and 'quirks'.
> >>My iMac is a version 6,1 from late 2006.
> >>It uses the Intel 82801GB HD Audio chip and the Realtek ALC885 codec.
> >>It uses the azalia audio driver.
> >>I played with mixerctl and audioctl, used 'cdio cdplay' etc, nothing would
> >>make a sound!
> >>The base setttings for audioctl had the play.rate at 48000 so I changed that
> >>to 44100 to test using cdio cdplay.
> >>I changed various settings in mixerctl to increase audio from 0 to 255, no
> >>sound.
> >It seems almost all the apple audio devices need various quirks,
> >try this:
> >
> >Index: azalia_codec.c
> >===
> >RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
> >retrieving revision 1.170
> >diff -u -p -r1.170 azalia_codec.c
> >--- azalia_codec.c   24 Aug 2015 04:50:40 -  1.170
> >+++ azalia_codec.c   8 Sep 2015 02:23:49 -
> >@@ -198,6 +198,7 @@ azalia_codec_init_vtbl(codec_t *this)
> > case 0x10ec0885:
> > this->name = "Realtek ALC885";
> > this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
> >+printf("\n%s subid=%x\n", XNAME(this), this->subid);
> > if (this->subid == 0x00a1106b ||/* APPLE_MB3 */
> > this->subid == 0xcb7910de ||/* APPLE_MACMINI3_1 
> > (line-in + hp) */
> > this->subid == 0x00a0106b ||/* APPLE_MB3_1 */
> >@@ -208,6 +209,10 @@ azalia_codec_init_vtbl(codec_t *this)
> > this->subid == 0xcb7910de ||/* APPLE_MACMINI3_1 
> > (internal spkr) */
> > this->subid == 0x00a0106b)
> > this->qrks |= AZ_QRK_WID_OVREF50;
> >+if (this->subid == 0x1000106b ||
> >+this->subid == 0x3e00106b) {
> >+this->qrks |= AZ_QRK_GPIO_UNMUTE_0 | 
> >AZ_QRK_GPIO_UNMUTE_1;
> >+}
> > break;
> > case 0x10ec0888:
> > this->name = "Realtek ALC888";

Re: 2^64 - 39 ...

[Michael Warmuth-Uhl]

On 09/08/15 08:03, Otto Moerbeek wrote:
> My bet would be Newton iteration, which should converge faster than
> binary search. ping(8) has an implementation of integer sqrt.
> 
> BTW, long double won't fix the problem on al platforms since it is not
> guaranteed to be longer than double.

Newton is in general faster. Still I'd prefer the binary search as it 
is simpler and avoids issues with accuracy (LSB). Anyway, the 
factorization itself is the much slower part for products of big primes.

Regards,

Michael


--- /usr/src/games/factor/factor.c  Wed Oct 28 00:59:24 2009
+++ factor.cTue Sep  8 20:06:44 2015
@@ -192,6 +192,19 @@ pr_fact(u_int64_t val) /* Factor this value. */
(void)putchar('\n');
 }
 
+static u_int32_t
+int_sqrt(u_int64_t y)
+{
+int i;
+u_int32_t m_i;
+u_int32_t m = 0;
+ 
+for (i = 32; i >= 0; i--) {
+m_i = m | (1U << i);
+if ((u_int32_t)m_i * m_i <= y) m = m_i;
+}
+return m;
+}
 
 /* At this point, our number may have factors greater than those in primes[];
  * however, we can generate primes up to 32 bits (see primes(6)), which is
@@ -208,7 +221,7 @@ pr_bigfact(u_int64_t val)   /* Factor this value. */
char table[TABSIZE];/* Eratosthenes sieve of odd numbers */
 
start = *pr_limit + 2;
-   stop  = (ubig)sqrt((double)val);
+   stop  = int_sqrt(val);
if ((stop & 0x1) == 0)
stop++;
/*

Re: I354 initialization error on DFF 2220

[Jonathan Gray]

On Tue, Sep 08, 2015 at 09:38:23PM +, Paul Levlin wrote:
> Trying to install OpenBSD on a Netgate RCC-DFF 2220 system, but
> it seems like the Intel I354 interface has trouble initializing.
> 
> I've tried 5.7-release and -current, both show the same output
> while attempting to initialize.
> 
> As the I354 is listed in the supported adapters for em(4), I'm
> hoping it's a simple bug that I'd be happy to verify a fix for.
> 
> Pointers to how to provide better debug info for the devs
> 
> in this case (if needed) are also appreciated.
> 
> If I'm barking up the wrong tree, I'd be happy for a reality check
> too..

em supports the I354 mac but not every phy that can be hooked
up to it.  It seems likely that the 88E1514 phys in that board
have the same ids as the 88E1512 phy.  In which case the following
may help:

Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
retrieving revision 1.87
diff -u -p -r1.87 if_em_hw.c
--- if_em_hw.c  5 Aug 2015 18:31:14 -   1.87
+++ if_em_hw.c  9 Sep 2015 04:29:33 -
@@ -182,7 +182,7 @@ int32_t em_get_pcs_speed_and_duplex_825
 int32_tem_set_eee_i350(struct em_hw *);
 int32_tem_set_eee_pchlan(struct em_hw *);
 int32_tem_valid_nvm_bank_detect_ich8lan(struct em_hw *, 
uint32_t *);
-
+int32_tem_initialize_M88E1512_phy(struct em_hw *);
 
 /* IGP cable length table */
 static const uint16_t 
@@ -229,6 +229,7 @@ em_set_phy_type(struct em_hw *hw)
case M88E_I_PHY_ID:
case M88E1112_E_PHY_ID:
case M88E1543_E_PHY_ID:
+   case M88E1512_E_PHY_ID:
case I210_I_PHY_ID:
case I347AT4_E_PHY_ID:
hw->phy_type = em_phy_m88;
@@ -5272,6 +5273,12 @@ em_phy_reset(struct em_hw *hw)
em_gate_hw_phy_config_ich8lan(hw, FALSE);
}
 
+   if (hw->phy_id == M88E1512_E_PHY_ID) {
+   ret_val = em_initialize_M88E1512_phy(hw);
+   if (ret_val)
+   return ret_val;
+   }
+
return E1000_SUCCESS;
 }
 
@@ -5410,7 +5417,8 @@ em_match_gig_phy(struct em_hw *hw)
hw->phy_id == I347AT4_E_PHY_ID ||
hw->phy_id == I350_I_PHY_ID ||
hw->phy_id == M88E1112_E_PHY_ID ||
-   hw->phy_id == M88E1543_E_PHY_ID) {
+   hw->phy_id == M88E1543_E_PHY_ID ||
+   hw->phy_id == M88E1512_E_PHY_ID) {
uint32_t mdic;
 
mdic = EM_READ_REG(hw, E1000_MDICNFG);
@@ -10894,5 +10902,94 @@ em_set_eee_pchlan(struct em_hw *hw)
ret_val = em_write_phy_reg(hw, I82579_LPI_CTRL, phy_reg);
 out:
return ret_val;
+}
+
+/**
+ *  em_initialize_M88E1512_phy - Initialize M88E1512 PHY
+ *  @hw: pointer to the HW structure
+ *
+ *  Initialize Marvell 1512 to work correctly with Avoton.
+ **/
+int32_t
+em_initialize_M88E1512_phy(struct em_hw *hw)
+{
+   int32_t ret_val = E1000_SUCCESS;
+
+   DEBUGFUNC("e1000_initialize_M88E1512_phy");
+
+   /* Check if this is correct PHY. */
+   if (hw->phy_id != M88E1512_E_PHY_ID)
+   goto out;
+
+   /* Switch to PHY page 0xFF. */
+   ret_val = em_write_phy_reg(hw, M88E1543_PAGE_ADDR, 0x00FF);
+   if (ret_val)
+   goto out;
+
+   ret_val = em_write_phy_reg(hw, M88E1512_CFG_REG_2, 0x214B);
+   if (ret_val)
+   goto out;
+
+   ret_val = em_write_phy_reg(hw, M88E1512_CFG_REG_1, 0x2144);
+   if (ret_val)
+   goto out;
+
+   ret_val = em_write_phy_reg(hw, M88E1512_CFG_REG_2, 0x0C28);
+   if (ret_val)
+   goto out;
+
+   ret_val = em_write_phy_reg(hw, M88E1512_CFG_REG_1, 0x2146);
+   if (ret_val)
+   goto out;
+
+   ret_val = em_write_phy_reg(hw, M88E1512_CFG_REG_2, 0xB233);
+   if (ret_val)
+   goto out;
+
+   ret_val = em_write_phy_reg(hw, M88E1512_CFG_REG_1, 0x214D);
+   if (ret_val)
+   goto out;
+
+   ret_val = em_write_phy_reg(hw, M88E1512_CFG_REG_2, 0xCC0C);
+   if (ret_val)
+   goto out;
+
+   ret_val = em_write_phy_reg(hw, M88E1512_CFG_REG_1, 0x2159);
+   if (ret_val)
+   goto out;
+
+   /* Switch to PHY page 0xFB. */
+   ret_val = em_write_phy_reg(hw, M88E1543_PAGE_ADDR, 0x00FB);
+   if (ret_val)
+   goto out;
+
+   ret_val = em_write_phy_reg(hw, M88E1512_CFG_REG_3, 0x000D);
+   if (ret_val)
+   goto out;
+
+   /* Switch to PHY page 0x12. */
+   ret_val = em_write_phy_reg(hw, M88E1543_PAGE_ADDR, 0x12);
+   if (ret_val)
+   goto out;
+
+   /* Change mode to SGMII-to-Copper */
+   ret_val = em_write_phy_reg(hw, M88E1512_MODE, 0x8001);
+   if (ret_val)
+   goto out;
+
+   /* Return the PHY to page 0. */
+   ret_val = em_write_phy_reg(hw,