Kindly Respond
Dear Beneficiary, My name is Mr.Edward Adamu,the newly appointed deputy governor CBN.This is to bring the good news to you that I have been mandated by the President Federal Republic in conjunction with the Federal Executive Council (FEC), the Senate Committee on Foreign Debts Reconciliation and Implementation Panel on Contract/inheritance/compensation funds to complete all the unpaid Contract/inheritance/lottery fund. You are required as a matter of urgency to reconfirm your information including your name, phone number and your address for verification and immediate payment within 24 hours. To this effect, the sum of TEN MILLION, SEVEN HUNDRED THOUSAND UNITED STATES DOLLARS (US$10.7m) has been approved for you. I wish to inform you that all matters relating to the release of this payment is now under my control and supervision. This development has become necessary due to the activities of unpatriotic government/CBN officials and impostors who keep on frustrating every effort to settle our clients by making requests for unauthorized fees and levies from them. We apologize for any delay you might have encountered in the past; your payment is now 100% Guaranteed Kindly choose from these three modes of payment (wire transfer, diplomatic cash payment and ATM card). Best Regards, Mr.Edward Adamu Deputy Governor CBN ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: iio: ad7192: replaced bool in struct
On Mon, 7 Jan 2019 23:27:48 +0530
Himanshu Jha wrote:
> On Wed, Jan 02, 2019 at 01:25:27PM -0800, Matt Ranostay wrote:
> >
> > > On Dec 24, 2018, at 01:58, Himanshu Jha
> > > wrote:
> > >
> > >> On Fri, Dec 21, 2018 at 03:26:26PM -0800, Amir Mahdi Ghorbanian wrote:
> > >> Replaced bool in struct with unsigned int bitfield to conserve space and
> > >> more clearly define size of varibales
> >
> > Important thing to note is depending on padding, alignment, and position of
> > field it probably won’t save any space.
>
> Well, then what do you say about the following results ;-)
>
> Before:
> --
>
> himanshu@himanshu-Vostro-3559:~/gsoc/linux$ pahole -C ad7192_platform_data
> drivers/staging/iio/adc/ad7192.o
> struct ad7192_platform_data {
> u16vref_mv; /* 0 2 */
> u8 clock_source_sel; /* 2 1 */
>
> /* XXX 1 byte hole, try to pack */
>
> u32ext_clk_hz; /* 4 4 */
> bool refin2_en;/* 8 1 */
> bool rej60_en; /* 9 1 */
> bool sinc3_en; /*10 1 */
> bool chop_en; /*11 1 */
> bool buf_en; /*12 1 */
> bool unipolar_en; /*13 1 */
> bool burnout_curr_en; /*14 1 */
>
> /* size: 16, cachelines: 1, members: 10 */
> /* sum members: 14, holes: 1, sum holes: 1 */
> /* padding: 1 */
> /* last cacheline: 16 bytes */
> };
>
> After:
> -
>
> himanshu@himanshu-Vostro-3559:~/gsoc/linux$ pahole -C ad7192_platform_data
> drivers/staging/iio/adc/ad7192.o
> struct ad7192_platform_data {
> u16vref_mv; /* 0 2 */
> u8 clock_source_sel; /* 2 1 */
>
> /* XXX 1 byte hole, try to pack */
>
> u32ext_clk_hz; /* 4 4 */
> unsigned int refin2_en:1; /* 8:31 4 */
> unsigned int rej60_en:1; /* 8:30 4 */
> unsigned int sinc3_en:1; /* 8:29 4 */
> unsigned int chop_en:1;/* 8:28 4 */
> unsigned int buf_en:1; /* 8:27 4 */
> unsigned int unipolar_en:1;/* 8:26 4 */
> unsigned int burnout_curr_en:1;/* 8:25 4 */
>
> /* size: 12, cachelines: 1, members: 10 */
> /* sum members: 11, holes: 1, sum holes: 1 */
> /* bit_padding: 25 bits */
> /* last cacheline: 12 bytes */
> };
>
> > Also for internal unpacked structures it really makes little sense to save
> > a few bytes of data. Don’t read into that packed structures are good.. they
> > usually aren’t :)
>
> Yes, agreed, but I often see patches to save few bytes by marking
> array as static.
>
> There is some effort in this direction:
> https://lore.kernel.org/lkml/20181221235230.gc13...@ziepe.ca/
>
> Very likely to get more patches if the above patch gets merged.
>
The one additional thing that is relevant here is that we will probably
drop the whole structure anyway as part of moving it out of staging.
There might be some equivalent elements stored elsewhere, but quite
likely it won't be all of them. As a result I'm not particularly keen
on patches to clean platform data up.
+ we really are dealing with trivial amounts of data here..
J
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: iio: adt7316: Add regmap support
...
> > > diff --git a/drivers/staging/iio/addac/adt7316.h
> > > b/drivers/staging/iio/addac/adt7316.h
> > > index fd7c5c92b599..2c72cf3f71cd 100644
> > > --- a/drivers/staging/iio/addac/adt7316.h
> > > +++ b/drivers/staging/iio/addac/adt7316.h
> > > @@ -11,16 +11,13 @@
> > >
> > > #include
> > > #include
> > > +#include
> > >
> > > #define ADT7316_REG_MAX_ADDR 0x3F
> > >
> > > -struct adt7316_bus {
> > > - void *client;
> > > - int irq;
> > > - int (*read)(void *client, u8 reg, u8 *data);
> > > - int (*write)(void *client, u8 reg, u8 val);
> > > - int (*multi_read)(void *client, u8 first_reg, u8 count, u8 *data);
> > > - int (*multi_write)(void *client, u8 first_reg, u8 count, u8 *data);
> > > +static const struct regmap_config adt7316_regmap_config = {
> > > + .reg_bits = 8,
> > > + .val_bits = 10,
>
> I wonder if val_bits should be 8. The driver can read and write 8, 10,
> or 12 bit values. In the 10 and 12 bit cases, the driver currently
> (including with this patch) does two separate reads or writes and expects
> an 8 bit result from each. It then parses these two values to come up with
> the 10 or 12 bit value. I don't think the logic for this calculation is
> known to regmap, so with the current form of the patch, I think val_bits
> should be 8. Maybe there is a better way to do it though?
Good point. I would assume they should be 8 as well.
>
> I would have tested this but I couldn't get the patch to apply. Shreeya,
> I think if you rebase against iio/testing that might take care of it. I
> can then do some testing with v2.
>
Great.
Jonathan
> Jeremy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Библии да! Конституции нет!
subject: Библии да! Конституции нет! ПОКОЛЕНИЕ ИИСУСА ХРИСТА ПОКОЛЕНИЕ МУЧЕНИЦА учить умирать за Иисуса Христа ЭТО МИНИСТЕРСТВО ГОЛОСА ВОССТАНОВЛЕНИЯ, ТОЛЬКО ДВЕРЬ ДЛЯ РАПТУРЫ ЦЕРКВИ: https://thelastelijah.webs.com/ PR. ТУПИРАНИ, ПОСЛЕДНИЙ ЭЛИЯ. БИБЛИЯ ДА! КОНСТИТУЦИЯ НЕ! 2070: ИИСУС ВОЗВРАЩАЕТСЯ. МЫ НЕ МАСОНОВ! “Вот, Я пошлю к вам Илию пророка пред наступлением дня Господня, великого и страшного." (Малахия 4:5) “Иисус сказал им в ответ: правда, Илия должен придти прежде и устроить всё;" (Матфея 17:11) GENERATION JESUS CHRIST GENERATION OF MARTYRS TEACHING TO DIE FOR JESUS CHRIST. THIS IS THE MINISTRY OF THE VOICE OF RESTORATION, THE ONLY DOOR FOR THE RAPTURE OF THE CHURCH: https://thelastelijah.webs.com/ PR. TUPIRANI, THE LAST ELIJAH. BIBLE YES! CONSTITUTION NO! 2070: JESUS WILL RETURN. WE AREN'T FREEMASONS! “Behold, I will send you Elijah the prophet before the coming of the great and dreadful day of the Lord." (Malachi 4:5) “Elijah truly shall first come and restore all things." (Matthew 17:11) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
