[PATCH] drm/radeon: fix endian bugs in radeon_atom_get_clock_dividers()

[Dan Carpenter]

On Mon, Apr 22, 2013 at 10:18:09AM -0400, Alex Deucher wrote:
> On Mon, Apr 22, 2013 at 10:08 AM, Dan Carpenter
> <dan.carpenter at oracle.com> wrote:
> > On Mon, Apr 22, 2013 at 10:03:13AM -0400, alexdeucher at gmail.com wrote:
> >> From: Alex Deucher <alexander.deucher at amd.com>
> >>
> >> Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
> >> Signed-off-by: Alex Deucher <alexander.deucher at amd.com>
> >> ---
> >>  drivers/gpu/drm/radeon/atombios.h        |    2 ++
> >>  drivers/gpu/drm/radeon/radeon_atombios.c |    6 ++----
> >>  2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/radeon/atombios.h b/drivers/gpu/drm/radeon/atombios.h
> >> index 4b04ba3..de678dd 100644
> >> --- a/drivers/gpu/drm/radeon/atombios.h
> >> +++ b/drivers/gpu/drm/radeon/atombios.h
> >> @@ -459,6 +459,7 @@ typedef struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS_V3
> >>    {
> >>      ATOM_COMPUTE_CLOCK_FREQ  ulClock;         //Input Parameter
> >>      ATOM_S_MPLL_FB_DIVIDER   ulFbDiv;         //Output Parameter
> >> +    ULONG ulClockFbDiv;
> >
> > Why is this a long instead of an __le32 or u32?
> 
> atombios.h is shared across OSes and has it's own types.

Can ULONG be 64 bit?  It's ugly when ULONG, ulong and
"unsigned long" are different types.

> >
> > I'm confused by this patch as well.  I assumed the datatypes were
> > determined by the hardware spec.
> 
> I'm not sure I follow.  The atombios interpretor requires data in
> little endian format.

I was expecting that the code would stay the same and the
annotations would change is all...  I haven't tested this so I'm
sure it's right, but it just wasn't the change I was expecting.

regards,
dan carpenter