Me and mainling bluetooth on my phone.

*Implement the bluetooth node*
Driver: FUCK YOU
*Replace the regulators names with proper ones according to new driver*
Driver: FUCK YOU
*Find that one regulator is wrong*
Driver: FUCK YOU
*Add max frequency to not go over that limit*
Driver: FUCK YOU

And this my friends is kernel development in short.
Driver cant read the data from the chip because its offline. And i have no clue why.
And it has no way of telling me why.
Cause it doesnt know.

  • 4
    You need to find the g spot and make the device aroused enough to listen to your demands.

    Don't know if it's true for Bluetooth, too. But from my _very_ small knowledge of embedded and reading Planet FDO (Free Desktop) and it's graphic driver specific entries, it sounds most of the time like that.
  • 1
    @IntrusionCM We *me and friend from team* think reset pin could be asserted. Tho I can't find it in downstream. It's weird. I will have to figure it out tho.
  • 2
    @Haxk20 lemme guess... Reset PIN as in some magic address?
  • 0
    @IntrusionCM nah true GPIO pin. Tho that should be pointed to the reset clock. Tho I really can't find anything like that in downstream kernel for the phone. Which really sucks.
  • 0
    If it isnt. Pointed to the clock and since the pin isn't even set up in kernel yet it is set to bootloader shit which may have set it to be 1 and it's asserted since kernel technically doesn't know it exists. I have to talk with a friend tomorrow about it and also ask him about hunch I have about the regulators.
  • 2
    @Haxk20 I'll do now the same my granny used to do...

    *Pats Haxk20 head*

    I have faith you'll solve the problem, as long as you don't give up.

    (I understood parts of the things you are talking about, but yeah... Finding technical document for specific problems is a PITA - be strong).
  • 0
    @IntrusionCM thanks man. I do hope I will fix it. Well I kinda have to.
Add Comment